[12:55] <Abom> anyone know where the settings for "desktop effects" are in the configuration editor?
[09:39] <Elephantman> hello :)


[00:00] <jdong> kees: http://jdong.mit.edu/~jdong/usnramble.txt (WARNING: HUGE FILE)
[00:01] <kees> jdong: *rofl*  so I guess it doesn't do highest-rated output? heheh
[00:01] <wgrant> I think you need slightly longer chains.
[00:01] <jdong> wgrant: that's what she said.
[00:01] <jdong> I mean... working on it.
[00:03] <wgrant> Some of it looks quite real.
[00:04] <ajmitch> jdong: you were bored, I take it
[00:04] <jdong> ajmitch: isn't that when I'm the most dangerous? :)
[00:05] <jdong> Chuck McAuley reported that the
[00:05] <jdong> security context of the function XULDocument.persist() did not sufficiently
[00:05] <jdong> check the length of netbios packets
[00:05] <ajmitch> that's when we start running for cover
[00:35] <leslieviljoen> Ok, my packages are built!
[00:36] <leslieviljoen> http://ubuntuforums.org/showthread.php?p=6163764#post6163764
[00:36] <leslieviljoen> now I am a bit tired
[00:37] <leslieviljoen> goodnight everyone and thanks for all the help!
[00:59] <maco> i need some packaging help.  i ran debuild -S -sa and it failed saying secret key not available even though my private key is visible in Seahorse
[00:59] <wgrant> maco: With an identical UID to that mentioned in your changelog?
[01:00] <maco> wgrant: um, do you mean the email address listed?
[01:01] <maco> yes, the email address used in debian/changelog is on my private key
[01:02] <StevenK> maco: The full name, the comment and the e-mail address all need to match
[01:02] <maco> the name and the email address do, though i dont believe the comment goes anywhere in debian/changelog
[01:02] <StevenK> maco: Compare the uid lines from gpg --list-secret-keys to the Changed-By field in the .changes
[01:03] <StevenK> They need to match exactly
[01:03] <StevenK> If not, add -k<gpg id> to debuild
[01:04] <maco> .changes?
[01:04] <StevenK> maco: Yeah, such as krecipes_0.9.1-4_source.changes
[01:05] <StevenK> maco: I'm not sure if debuild actually generates one, sorry.
[01:05] <maco> the Changed-By field matches my uid
[01:05] <StevenK> maco: If you're not sure, comparing what's in debian/changelog versus gpg --list-secret-keys should be fine
[01:05] <maco> well, except for the comment
[01:06] <maco> are you supposed to include the comment somewhere?
[01:06] <wgrant> yes.
[01:06] <maco> and yeah, now that you mention -k, i do recall having to specify my key id whenever the last time i made a package was
[01:06] <wgrant> The strings must match precisely.
[01:06] <maco> oh. where's the comment supposed to go? in changelog?
[01:06] <StevenK> Because your key has a comment and your entry in debian/changelog doesn't.
[01:07] <StevenK> maco: Your Name (Comment<EMAIL_ADDRESS>[01:07] <wgrant> The same place it goes in your secret key.
[01:07] <maco> i just meant, is it supposed to go directly in changelog or is it supposed to be in some config file
[01:07] <maco> but ok, sounds like you mean in the changelog
[01:10] <maco> thanks guys
[01:10]  * StevenK kicks nm-applet for hiding
[01:11] <wgrant> StevenK: Probably means that NM isn't running.
[01:11] <StevenK> root      5603  0.0  0.0  54652  1324 ?        Ss   Nov03   0:00 /usr/sbin/NetworkManager
[01:11] <StevenK> I ignore NM on this machine, so I suspect I told the applet to go away and stop bothering me, but now I want it back
[01:12] <wgrant> What does nm-applet say if you run it in a terminal? The service is already taken?
[01:12] <wgrant> Ah.
[01:12] <StevenK> wgrant: Yup, the service is already taken
[01:13] <wgrant> Is nm-applet already running, or is this a case of NM being crap like it is on one of my upgraded boxes?
[01:13] <StevenK> It's running
[01:13] <wgrant> Kill NM dead. /etc/init.d/NetworkManager stop might not kill it hard enough.
[01:13] <wgrant> NM 0.7 can be very strnage....
[01:13] <StevenK> My feeling is there might be a gconf key
[01:15] <StevenK> Seems I'm wrong
[01:15]  * StevenK gets out the Big Hammer
[01:15] <wgrant> Which big hammer?
[01:16] <StevenK> Killing NM dead
[01:16] <wgrant> Ah.
[01:19] <mok0> StevenK: yeah get rid of the mofo
[01:42] <ethana2> How do I go about finding whether a given package has different versions in backports and proposed repos?
[01:42] <ethana2> If this version of uvcvideo has an update in proposed, I may just want to enable those, and if it doesn't, I'll probably end up compiling the driver
[01:43] <ethana2> ...but then, that's probably in some big package with all the other kernel drivers...
[02:35] <psusi> question... isn't SIGHUP supposed to be sent to the processes attached to a pty whenever the master side is closed?  no matter how it is closed?
[02:37] <psusi> for some reason it looks like SIGHUP is not sent to background processes when you exit from the shell, but IS if you close the terminal.. I could swear it should be sent no matter what causes the controlling process to exit
[03:03] <sjdurfey> are there plans to update the version of Eclipse in the repos anytime soon? the repo is two releases behind
[03:05] <nhandler> sjdurfey: 3.2.2-6.1 is in Debian unstable. We should probably have that in the repositories in the next few weeks. We just need someone to merge/sync it
[03:06] <sjdurfey> why another 3.2? eclipse is on release 3.4
[03:06] <nhandler> sjdurfey: I doubt that Debian will upgrade to 3.4 until after Lenny is released.
[03:07] <sjdurfey> is there any particular reason for that?
[03:07] <wgrant> Eclipse isn't known for being trivial to package, nor overly stable, I suspect.
[03:08] <wgrant> And it's not likely to get a release freeze exception.
[03:09] <sjdurfey> that makes sense
[03:12] <ScottK> sjdurfey: If someone wanted to package 3.4 for Ubuntu, it's probably get in.  So far no one has.
[03:13] <wgrant> I don't think we've got anybody strange enough to package Eclipse...
[03:13] <sjdurfey> i dont have the slighest idea on how to package
[03:14]  * ajmitch will refrain from putting his hand up for it
[03:15] <ScottK> Right, well that's been the general consensus.
[03:15] <sjdurfey> its so hard to package eclipse that no one will volunteer to do it?
[03:18] <RAOF> Does eclipse still build the swt-gtk libraries that other java apps use?
[03:18] <ScottK> It's not so much hard as unique and very resource intensive.  Last time I looked at it it wouldn't even compile on a box with less than (IIRC) 2GB of RAM.
[03:18] <ScottK> RAOF: One way to find out ...
[03:19] <sjdurfey> wow, thats a whole lot of ram
[03:19] <ScottK> As I said, painful.  It might have been 1, not 2.  I don't remember for sure.
[03:20]  * ScottK did some work on it about a year ago and learned his lesson.
[03:20] <sjdurfey> haha
[03:24] <sjdurfey> how is packaging done?
[03:32] <ScottK> sjdurfey: https://wiki.ubuntu.com/PackagingGuide
[03:33] <sjdurfey> thanks
[03:35] <sjdurfey> wow, there is quite a bit to read there
[03:43]  * ajmitch wonders why gcc just doesn't want to work in pbuilder on the laptop
[03:44] <ajmitch> probably some package missing, but build-essential is there at leasy
[03:49] <sjdurfey> hmmm, i found out what motu stands for, and im thinking learning how to package and helping where i can would be a great learning experience for me
[03:55] <jmarsden> sjdurfey: https://wiki.ubuntu.com/MOTU/Contributing
[03:56] <sjdurfey> thanks
[03:57] <jmarsden> No problem :-)  There is also https://wiki.ubuntu.com/MOTU/GettingStarted
[03:58] <sjdurfey> does a motu just deal with packages, or is there also coding going on as well?
[03:58] <jmarsden> Fixing bugs => coding
[03:59] <jmarsden> If you are a pure coder, there is Ubuntu Core Developer, the other tech role in Ubuntu...
[04:00] <sjdurfey> yeah, im def. not to the point where i can contribute patches and what not. hopefully i will be, i just need to find the time
[04:01] <jmarsden> Fixing documentation and packaging bugs is very much needed ... do what you can!
[04:02] <sjdurfey> ill read the guides and what not to see what i can do to contribute, i very much want to be part of the open source community
[04:03] <jmarsden> It's big enough that there's room for everyone, if you're willing to make the effort to actually contribute.  Writers, graphic artists, translators, ... lots of roles other than the traditional coder/developer/network admin stuff
[04:05] <sjdurfey> i would like to stick with the coding, bug fixing, patching, etc. im a CS major and would def. love to learn more about coding for linux
[04:06] <jmarsden> In that case... jump in :-)
[04:06] <sjdurfey> i will, i guess school work will have to be pushed to the side a bit :P its keeping me from more important things
[04:07]  * jmarsden graduated with a B.sc in Computing and Information Systems... back in 1983 :-)
[04:08] <sjdurfey> mines going to be a B.A. i was originally a psych major so i had tons of arts & humanities built up when i switched to CS, so a B.A. would have been quicker to complete rather than a B.S.
[04:08] <ScottK> Ohhh.  Someone even older than me ....
[04:08] <bddebian> Watch it :)
[04:08] <ajmitch> that cannot be possible!
[04:08] <ScottK> Bah.  You youngsters.
[04:08] <ajmitch> ScottK: don't worry, I saw a DD in the street yesterday, I think he's about 70+
[04:08] <sjdurfey> DD?
[04:09] <ajmitch> debian developer
[04:09] <sjdurfey> ahhh ok
[04:10] <jmarsden> sjdurfey: If you decide the MOTU path is the one you want to take there is a mentoring program you can use if you want... https://wiki.ubuntu.com/MOTU/Mentoring
[04:11] <sjdurfey> ill look into that, thanks a lot. i think a mentoring program is a great idea for beginners! there is so much information out there it can be duanting
[04:11] <ajmitch> bddebian: I'm sure you remember the name philip charles
[04:11] <ScottK> sjdurfey: Plus there are generally people here to answer questions.  The formal mentoring program is not at all required.
[04:12] <ScottK> Feel free to roll up your sleeves, dive in and ask questions as they occur.
[04:12] <AnAnt> persia: thanks !
[04:12] <sjdurfey> thats awesome. i love how nice the people in the ubuntu chans are. i certainly cannot say the same for the programming channels however....
[04:13] <sjdurfey> i listened to Jono Bacon give a speech about that very thing a couple months ago at the Ohio Linux Fest
[04:13] <bddebian> ajmitch: Absolutely, I was just going to ask if that was who you were talking about :)
[06:49] <dholbach> good morning
[06:50] <iulian> Morning Daniel.
[06:50] <dholbach> hi Iulian
[07:11] <\sh> moins
[07:11] <iulian> 'ey
[07:44] <iulian> Does anyone have any ideas why I get this lintian error: dpkg-awk: shell-script-fails-syntax-check ./usr/lib/awk/dpkg-awk.lib ?
[07:44] <iulian> Running sh -n dpkg-awk.lib gives me dpkg-awk.lib: 34: Syntax error: word unexpected (expecting ")")
[07:44] <iulian> But it doesn't seem right.
[07:45] <iulian> dpkg-awk.lib file contains http://paste.ubuntu.com/71254/plain/
[07:53] <jmarsden> iulian: Does running it with sh -nv help at all to see where the error is?
[07:54] <huats> morning !
[07:59] <iulian> jmarsden: Not really, this is what I got http://paste.ubuntu.com/71263/
[08:00] <jmarsden> iulian: Me too, but that's not the 34th line according to http://paste.ubuntu.com/71254/ line numbering...
[08:00] <jmarsden> iulian: I'm editing t down to try and find exactly what it complains about...
[08:00] <iulian> jmarsden: Awesome, thanks a lot.
[08:10] <jmarsden> iulian: The problem is the line:   option_parse(opt_list, opt_link, help, ARGC, ARGV)
[08:10] <jmarsden> I think because option_parse has not been defined yet so the shell does not treat it as a function?
[08:11]  * iulian is looking
[08:13] <jmarsden> Yes, this line is being treated by sh as a function definition for option_parse but that would have syntax option_parse () stuff
[08:13] <jmarsden> SO it complains about the missing closing )
[08:17] <iulian> jmarsden: And how can I do that? My sh coding skills are awful.
[08:18] <jmarsden> Mine are a bit rusty... I'm not sure what this is really trying to do... are we defining option_parse here, or calling it?
[08:22] <iulian> Hmm, no idea.
[08:23] <jmarsden> iulian: I think the scrpit may not really be an sh script... should the first line be #!/bin/awk  ??
[08:23] <jmarsden> There is code here that does not look like sh code to me.
[08:24] <iulian> Let me try that.
[08:24] <jmarsden> The more I look at it the more I think this is awk code or something very like it.  But I've never programmed in awk :-)
[08:25] <persia> Some parts look like awk, but some parts look like shell, which makes it extra confusing.
[08:27] <jmarsden> Agreed.
[08:30] <iulian> jmarsden, persia: It's indeed AWK code.
[08:30] <iulian> Thanks a lot!
[08:30] <jmarsden> So who or what put !#/bin/sh at the top of it?  :-)  Anyway, no problem, glad we figured it out.
[08:31] <iulian> I've no idea ;)
[08:32]  * jmarsden needs to get some sleep... goodnight all
[08:32] <iulian> Sleep well, jmarsden.
[08:55] <DktrKranz> wgrant: axiom is still racy with new gcl, pushing it won't harm too much, but it won't solve problems for every package, but at least it should for maxima.
[08:56] <wgrant> DktrKranz: I haven't been able to test maxima too much today, but my first impression is that it's slightly broken in wxmaxima.
[08:56] <wgrant> Oh.
[08:56] <wgrant> And it doens't event start on the CLI.
[08:57] <DktrKranz> my impression was right, then
[08:57] <wgrant> It might well not be due to your gcl change, of course.
[08:58] <DktrKranz> it took too fast to build
[08:58] <wgrant> It seems to give the right results.
[09:37] <Hobbsee> now, with a bit of luck, i won't get moderated...
[09:38] <Hobbsee> ooh, i don't :)
[09:39] <Hobbsee> ScottK: added a bit to that u-d-d madness thread.
[09:41] <ajmitch> Hobbsee: oh dear
[09:42] <Hobbsee> ajmitch: it's not that bad
[09:42] <ajmitch> yes, yes it is!
[09:44]  * ajmitch stabs flash, again
[09:44] <ajmitch> having it crash firefox repeatedly is annoying
[09:47] <NCommander> heh
[09:47] <NCommander> hey Hobbsee
[09:49] <Hobbsee> hey NCommander
[09:49] <NCommander> how goes it?
[09:49] <Hobbsee> going OK
[09:55] <Laibsch> Hi, I am trying to rebuild openoffice.org3 for hardy
[09:55] <Laibsch> I believe "debuild -S" overflows /tmp
[09:55] <Laibsch> http://rafb.net/p/8qQk5i67.html
[09:56] <Hobbsee> Laibsch: yeah, you'd probably need a huge system to do that...
[09:56] <Laibsch> line 19
[09:56] <Laibsch> Hobbsee: I am using the PPA
[09:56] <Hobbsee> Laibsch: not on that pastebin...
[09:56] <Hobbsee> Laibsch: even building the source, i believe you need a pretty huge system. calc would know more.
[09:57] <Laibsch> But just debuild -S seems to run out of space, I think probably on /tmp, although I can never catch it
[09:57]  * Hobbsee wonders if your  /  ran out of space, too
[09:57] <Laibsch> Hobbsee: I just want to package the unchanged source for uploading to my PPA
[09:58] <Laibsch> Hobbsee: I have /usr/, /usr/src, /var and a bunch of other things on separate partitions
[09:58]  * Hobbsee notes that's probably against the TOS?
[09:58] <Laibsch> Building OOo on the PPA?
[09:58] <Laibsch> I don't think so
[09:58] <wgrant> Hobbsee: Why would uploading an unchanged source be against the TOS?
[09:58] <Hobbsee> We will not accept uploads of packages that are unmodified from their original source in Ubuntu or Debian, only packages that include your own changes. We ask that people include useful changelogs for each package so that users and other developers can understand what new features they are exploring in their work. Read the PPA Terms of Use for more information.
[09:58] <Laibsch> My quote was specifically enlarged so I can do this
[09:58] <Hobbsee> FAQ on https://help.launchpad.net/Packaging/PPA?action=show&redirect=PPA#Frequently%20asked%20questions
[09:59] <wgrant> Aha.
[09:59] <Laibsch> Hobbsee: Well, I do rebuild debian experimental packages for hardy
[09:59] <Laibsch> So, at least the changelog changes ;-)
[09:59] <joaopinto> Laibsch, isn't there already an OOo PPA for Hardy ?
[09:59] <Laibsch> I haven't heard anybody complain, yet
[09:59] <Laibsch> Not that I am aware of
[09:59] <Laibsch> There is one for intrepid
[09:59] <Laibsch> We are talking about OOo3, not OOo2
[10:00] <Hobbsee> Laibsch: either way, i'd expect you ran out of space on whatever partition has /tmp, so it died.  You'll need a machine with more space, most likely, to even rebuild the source.
[10:00] <joaopinto> Laibsch, https://launchpad.net/~openoffice-pkgs/+archive
[10:00] <joaopinto> ops, ignore me, intrepid only :P
[10:00] <Laibsch> OK
[10:01] <Laibsch> I was aware of that group PPA
[10:01] <Laibsch> Last I looked it had only Intrepid
[10:01] <Laibsch> Seems to be still the case
[10:01] <mok0> Hobbsee: Hmm, I have sometimes thought about using my PPA as a test build device before uploading to "the real thing"...
[10:01] <ajmitch> talked to the people in the group about it?
[10:01] <Laibsch> Hobbsee: I was wondering if there is no way to somehow get around that problem
[10:01] <Laibsch> I have tmpfs and thus RAM/2
[10:01] <Laibsch> Usually that is sufficient
[10:02] <wgrant> mok0: I think that's reasonable.
[10:02] <Hobbsee> mok0: I do that.  Of course, at that point, they're not unmodified from their ubuntu counterparts, because teh new ubuntu counterparts haven't been uploaded yet.
[10:02] <wgrant> Laibsch: OOo is not in any way usual.
[10:02] <Laibsch> ajmitch: Were you talking to me?
[10:02] <Hobbsee> wgrant: ++
[10:02] <ajmitch> Laibsch: yes
[10:02] <mok0> Hobbsee: Heh, yeah
[10:03] <Laibsch> What would that help?  I can build the source fine myself (and then possibly share my work with them)
[10:03]  * Hobbsee thought you couldn't build the source by yourself, and this was the original problem...
[10:03] <Laibsch> except for space constraints of course ;-)
[10:03] <Hobbsee> right
[10:03] <Laibsch> I prefer to be independent, here
[10:03] <Laibsch> Well, I must have been able to pull it off once
[10:03] <ajmitch> some coordination is useful, especially when you're about to DoS the PPA buildds
[10:03] <Laibsch> I have rc2 source in my PPA
[10:04] <Laibsch> ajmitch: That is not the case
[10:04] <Laibsch> And as I said, the admins are aware of my activities
[10:04]  * Hobbsee agrees with slangasek.  Open Office needs to be downsized to Open Cubicle.
[10:04] <Laibsch> My quota was enlarged specifically for OOo builds
[10:05] <Laibsch> Hobbsee: I hope that will eventually happen
[10:05] <ajmitch> right, but the point still stands about some coordination of work being a Good thing
[10:05] <Laibsch> Until then, lots of test builds by people like me will be needed
[10:05] <Laibsch> ajmitch: I never questioned that
[10:05] <Laibsch> And I am doing that
[10:05] <Laibsch> Take a look at my profile: r0lf
[10:05] <Laibsch> I'm not a loner
[10:05] <Laibsch> But I'm impatient
[10:05] <ajmitch> right, you had just said you wanted to be independent
[10:06] <Laibsch> impatient -> wish for independency
[10:06] <Laibsch> fix things myself, then feed them back
[10:06] <Laibsch> better?
[10:06] <Laibsch> coming back to my original question
[10:07] <Laibsch> Is there no way to divert the tmpdir for a single command?  I think, earlier I "mount -o bind" /tmp to someplace else before "debuild -S"
[10:07] <Laibsch> Works, but not really pretty
[10:08] <Hobbsee> haven't seen anything to do it
[10:08] <Hobbsee> man page doens't show anything of that nature.
[10:24] <Hobbsee> james_w: I presume you're going to deal with rrdtool?
[10:24] <Laibsch> rrdtool?
[10:24] <Laibsch> I was just looking at https://bugs.launchpad.net/ubuntu/+source/mailgraph/+bug/221010
[10:25] <Laibsch> Should to be easy to backport the fixes to releases pre-hardy
[10:25] <Laibsch> I was just about to try and prepare a debdiff for sponsorship
[10:34] <Laibsch> When I fix that package, should I also fix small errors along the way, like updating the standards version to 3.8.0?
[10:34] <Laibsch> Or should I rather prepare a minimally invasive debdiff?
[10:36] <wgrant> Minimal, unless it's a package only in Ubuntu.
[10:57] <NCommander> anyone from SRU awake?
[11:24] <wgrant> dholbach: Finally!
[11:24] <dholbach> wgrant: yeah
[11:24] <wgrant> Although it would be nice to have component subscriptions directly in LP, this is nice.
[11:25] <dholbach> it was partly my fault that this was stalled for so long - I wrestled with mailman a bit, gave up, tried again months later, gave up, then Barry told me that we need a handler installed, then it took him some time to work it out, then I was busy with other stuff, then I prodded the IS team and they were quite quick to sort it out
[11:26]  * wgrant is a bit confused at 'IS' and 'quick' near each other.
[11:26] <wgrant> But anyway, it's sorted out now. Good work.
[11:26] <dholbach> that's what I want to avoid, that's why I said it
[11:28] <dholbach> but yeah, I'm happy too that it's working now :)
[12:11] <slytherin> Laibsch: your debdiff says distribution intrepid, shouldn't it read dapper-proposed? Also check version number.
[12:11] <slytherin> Laibsch: and you don't want the fix for feisty, it is not supported anymore.
[12:13] <Laibsch> slytherin: Thanks for taking a look
[12:13] <Laibsch> The intrepid thing is certainly just a glitch
[12:13] <slytherin> !sru | Laibsch
[12:13] <Laibsch> feisty not supported anyomre?
[12:14] <slytherin> Laibsch: no. it had only 18 months of support.
[12:14] <slytherin> 7.04 + 18 is 8.10 :-)
[12:14] <Laibsch> Well, I still see it on ubuntu.com
[12:14] <NCommander> Sylphid, 7.04 + 18 is 25.04
[12:14] <Laibsch> OK, must be a grace period, then
[12:14] <NCommander> er, slytherin
[12:15] <Laibsch> alright, feisty still supported, then
[12:15] <NCommander> Laibsch, it's not
[12:15] <NCommander> Laibsch, all SRU bugs for Feisty were declined
[12:15] <NCommander> It just hasn't been archived yet
[12:15] <slytherin> NCommander: I was talking about Ubuntu math. :-P
[12:15] <NCommander> oh
[12:15] <NCommander> lol
[12:27] <handschuh> hi. How does a revu-day work?
[12:27] <handschuh> Do the users have to request a review or will all packages will be reviewed?
[12:28] <RainCT> handschuh: Hey. Asking here for a review helps
[12:29] <handschuh> RainCT: ok, thanks. I will ask tomorrow then.
[12:30] <RainCT> handschuh: (you can also ask when it isn't REVU Day, btw)
[12:30] <handschuh> RainCT: so whats different on REVU Day?
[12:31] <persia> handschuh, On REVU day, more MOTU allocate time to do REVUs.
[12:32] <handschuh> persia: ah, thanks
[12:33] <handschuh> so as RanCT suggested: I would kindly ask to review two of my small libraries (http://revu.ubuntuwire.com/details.py?package=libauvitoapiaxis-java, http://revu.ubuntuwire.com/details.py?package=libballoontip-java) that are needed for a larger project of mine (http://revu.ubuntuwire.com/details.py?package=jaolt)
[12:33]  * RainCT notices that it's Friday already
[12:34] <broonie> I wish :)
[12:38] <persia> It's been Friday for almost 4 hours (at least in select parts of Kiribati)
[12:39] <lifeless> 20 minutes
[12:39] <lifeless> tick
[12:39] <lifeless> tock
[12:39] <lifeless> tick
[12:39] <lifeless> tock
[12:40] <RainCT> persia: I see.. UTC+14, nice
[12:40] <RainCT> o.O there's UTC+12:45, UTC-3:30.. XDDD
[12:40] <persia> RainCT, It mostly exists so that you can't get to tomorrow without leaving the country.
[12:42] <RainCT> persia: Uhm.. How long is REVU Day then? 50 (24+12+14)?
[12:43] <persia> When I was REVU Coordinator, I didn't know about UTC+14, and only ran it for 49 hours.  I'd suggest 50.
[12:55]  * slytherin notices word java in the links pasted by handschuh 8-)
[12:56] <handschuh> :-)
[13:01] <Laibsch> slytherin: What is the problem with the version number?
[13:01] <Laibsch> Should it have dapper in the version number?
[13:01] <Laibsch> like 1.12-1~dapper1
[13:02] <Laibsch> instead of 1.12-1ubuntu1 ?
[13:02] <slytherin> Laibsch: No. I guess the version should be ubuntu0.1. Please confirm from someone in SRU team.
[13:03] <Laibsch> ubuntu0.1 until it is officially uploaded?
[13:03] <Laibsch> ping SRU team
[13:03] <geser> Laibsch: are you preparing a SRU?
[13:03] <Laibsch> Well, not sure if it actually is a real SRU
[13:03] <Laibsch> But it is a patch for a package in dapper
[13:03] <Laibsch> and others
[13:04] <Laibsch> mailgraph
[13:04] <Laibsch> The homepage has changed
[13:04] <Laibsch> so, a rather simply and straight-forward change without regression potential
[13:05] <Laibsch> geser: are you a member of the SRU team?
[13:05] <geser> if you plan to get it to dapper-updates: the version should be  1.12-1ubuntu0.1 and the target in the changelog: dapper-proposed
[13:05] <geser> Laibsch: no
[13:05] <Laibsch> Alright
[13:05] <Laibsch> Can you explain the reason for ubuntu0.1?
[13:05] <slytherin> Laibsch: SRU is stable release update, no matter how small or bug the change is. Whether it will go in or not will be evaluated by SRU team. And since the package is in universe, it will be motu-sru.
[13:06] <Laibsch> OK
[13:07] <geser> Laibsch: the version should be larger than the current one and smaller than the one in $release+1 (which might have an "ubuntu1"), so usually "ubuntu0.1" is added
[13:10] <Laibsch> hm, that leads to endless recursion, doesn't it?
[13:10] <Laibsch> Let's say I did an SRU to hardy with ubuntu0.1
[13:10] <geser> no, the next one would be ubuntu0.2 (which is still < ubuntu1)
[13:11] <Laibsch> Then somebody else would do an SRU (unrelated) to gutsy again with ubuntu0.1
[13:11] <Laibsch> Problem not solved
[13:11] <RainCT> Laibsch: there are rules for this on the wiki
[13:11] <Laibsch> So, I kind of fail to see the need for introducing 0.
[13:11] <persia> Laibsch, No, they'd just have to pick a version string between the two.
[13:12] <persia> Laibsch, It's a convention we follow, rather than a hard rule.  It makes the versions predictable, so we can use standard techniques to determine how to handle exceptions.
[13:12] <Laibsch> persia: OK, so why is that not possible without introducing 0.1?  Right now there is no ubuntu1 package
[13:12] <persia> (and the vast majority of packages won't have the same base version for both gutsy and hardy anyway)
[13:13] <RainCT> Laibsch: using Xubuntu<IP_ADDRESS>,Xubuntu<IP_ADDRESS>, etc. for different releases is an option
[13:13] <persia> Laibsch, It's not that it's not possible, it's that we have a convention we use.
[13:13] <persia> The convention is to use .X to indicate SRU uploads.  When there isn't a base ubuntu variation, that becomes ubuntu0.X
[13:13] <persia> (because we need to have the string "ubuntu" for a variety of reasons)
[13:14] <Laibsch> I understand the reason for 0.1, but while that is mostly for cornercases, I don't think it catches them all, sort of invalidating the whole idea of it.  You get my point?
[13:14] <persia> Laibsch, Yes, but that the system isn't complete doesn't mean it's not useful.
[13:14] <Laibsch> persia: IOW, all packages ubuntuX where uploaded before the release was made public?
[13:14] <persia> It's a very rare case that we SRU packages that have the same version in two different releases, especially for different issues.
[13:14] <persia> Laibsch, huh?
[13:15] <RainCT> Laibsch: if you do a SRU for a version 1.0-1 using 1.0-1.1 then this would be confusing as we would think that it's a NMU from Debian. So, naming it 1.0-1ubuntu0.1 makes it clear that it's a SRU or security upload
[13:15] <persia> No, that indicates it was modified by someone for Ubuntu.
[13:15] <Laibsch> But once the release is made, the thing becomes an SRU, right
[13:15] <persia> The version string doesn't change between -proposed and -updates
[13:15] <Laibsch> And then you are not allowed to use ubuntuX anymore, but use ubuntu0.X instead
[13:15] <Laibsch> AFter release data
[13:16] <Laibsch> date
[13:16] <persia> Yes, after release date we use the .X notation to indicate a version change.
[13:16] <Laibsch> Oh, wait a minute
[13:16] <Laibsch> Does this 0.X thing also apply to gutsy?
[13:16] <persia> Every change should be updated in the development repo first, so the changes in the .X versions don't contribute towards trunk.
[13:16] <Laibsch> or would that be ubuntu1?
[13:17] <persia> It applies to all types of SRU.
[13:17] <persia> On the other hand, in the rare case that the version in gutsy is the same as the version in hardy, you need to work around it by picking different version numbers so gutsy < hardy < intrepid < jaunty continues to apply.
[13:18] <Laibsch> OK, then in the general case it is $nothing, ubuntu1, ubuntu2, ... before release and ubuntu$i.1, ubuntu$i.2, ubuntu$i.3, ... for SRU uploaded after the release, right?
[13:18] <Laibsch> public release
[13:18] <persia> (in which case constructions like <IP_ADDRESS>, 01..7.10, 01..8.04 can be useful.
[13:19] <persia> Laibsch, Loosely, yes.
[13:19] <Laibsch> alright
[13:19] <persia> (although remember to upload to the new development release *before* the SRU)
[13:19] <Laibsch> Intrepid is already fixed
[13:19] <persia> That counts :)
[13:20] <Laibsch> Closes: LP#221010
[13:20] <Laibsch> correct format?
[13:20] <persia> Don't use "closes:", that's for Debian.
[13:20] <persia> Format is "LP: #nnnnnn"
[13:20] <Laibsch> (LP:#221010)
[13:20] <Laibsch> alright
[13:20] <persia> Many people use parentheses after describing the specific thing changed.
[13:21] <Laibsch> too complicated ;-)
[13:21] <Laibsch> so many conventions
[13:21] <persia> Most of them grew from problems we had in the past.
[13:21] <Laibsch> understood
[13:37] <Laibsch> bug 221010 looks OK now?
[13:40] <persia> Laibsch, Looks good.  I think I need to wait for someone from MOTU SRU to ACK before I can upload though.
[13:47] <vorian> revu day huh?
[13:51] <slytherin> RainCT: any idea why isn't .diff on revu opened inline in firefox?
[13:53] <RainCT> slytherin: how big is it?
[13:53] <slytherin> RainCT: 5KB
[13:54] <slytherin> handschuh: ping
[13:55] <Laibsch> slytherin: I think that is a FF "issue"
[13:55] <handschuh> slytherin: pong ( did I miss something)
[13:56] <Laibsch> I have worked around such things by installing an extension
[13:56] <Laibsch> http://www.spasche.net/mozilla/
[13:56] <slytherin> handschuh: not yet, I was reviewing libballoontip-java.
[13:58] <RainCT> slytherin: not sure, perhaps there's something missing in Apache's config
[13:58] <handschuh> slytherin: thank you (did you commet it already)
[13:58] <slytherin> handschuh: not yet.
[13:59] <slytherin> RainCT: may be you could return type as text/plain
[14:01] <RainCT> slytherin: if this works, won't it break normal downloads (eg, with dget)?
[14:02] <slytherin> RainCT: I am talking about just .diff, not .diff.gz.
[14:02] <RainCT> slytherin: ah. what's a .diff?
[14:02] <RainCT> :P
[14:03] <slytherin> RainCT: I see both .diff and .diff.gz here - http://revu.ubuntuwire.com/details.py?package=libballoontip-java Is that something you haven't done. .diff contains extracted .diff.gz.
[14:05] <RainCT> ah, didn't even know that XD  (/me isn't really familiarized with the post-upload scripts, yet)
[14:07] <slytherin> handschuh: are you one of the upstream authors?
[14:08] <handschuh> no
[14:08] <handschuh> slytherin: if you complain about the missing licenses in the source-code; I already mailed to the upstream authors
[14:09] <slytherin> handschuh: Good. I will still add that in comments so we have it on the record.
[14:09] <handschuh> slytherin: ok thanks (I do forget things very fast, so this is a help)
[14:10] <slytherin> handschuh: there you go. You have day's work ahead. :-)
[14:11] <handschuh> slytherin: thanks a lot!  :-)
[14:11]  * slytherin celebrates first revu review by eating an apple. :-)
[14:14]  * RainCT gives slytherin MOTU rights and remembers that he should finally write a script to do this automatically
[14:15] <RainCT> slytherin: and I don't get that stupid mimetype-file extension association working :S
[14:15] <RainCT> s/don't/can't
[14:15] <NCommander> RainCT, wait what?
[14:16] <RainCT> lol
[14:16] <RainCT> NCommander: you remember me of popups *g*
[14:16] <NCommander> no, I mean giving slytherin MOTU rights
[14:17] <RainCT> NCommander: on REVU, that is
[14:18] <RainCT> oh, he isn't a MOTU? o.O
[14:18] <NCommander> Unless I missed a memo
[14:18] <RainCT> I thought he was lol
[14:18]  * RainCT undoes
[14:19] <RainCT> NCommander: thx for catching this :P
[14:19] <NCommander> We need a script that syncs up privilleges from LP
[14:20] <RainCT> indeed. feel free to write it ;P
[14:22] <NCommander> is the PPA importer active yet?
[14:24] <RainCT> NCommander: there's no cronjob, if that's what you mean
[14:24] <NCommander> any reason why that is the case?
[14:25] <RainCT> NCommander: there's still no code to check if the package has build
[14:26] <NCommander> I dunno if thats important unless we restrict upload rights to REVU
[14:26] <RainCT> NCommander: the description shouldn't mention this if it isn't done
[14:27] <RainCT> but I can set up the cronjob if you want
[14:27] <NCommander> you have the source :-)
[14:27] <RainCT> NCommander: one word: time *g*. I've been busy with school (and with trying weird stuff like writing something in C/C++ or getting my webcam to work with touchlib XD)
[14:44] <slytherin> RainCT: NCommander: What is the code for revu written in?
[14:45] <RainCT> slytherin: Python (and some bash)
[14:45] <slytherin> hmm
[14:45] <slytherin> some day ... :-(
[14:46] <NCommander> I was going to say superglue and duct tape
[14:46] <NCommander> RainCT, I think we need to pin the revu source repo
[14:46] <NCommander> source packages from REVU replace packages from the repo
[14:46] <RainCT> NCommander: then pin it in /etc/apt/preferences
[14:47] <NCommander> But should that be the default behavior?
[14:47] <slytherin> RainCT: You gave me MOTU rights? Is that the indication that I should apply for MOTU. :-D
[14:48] <RainCT> NCommander: everyone is free to decide if he wants to pin it or not. -proposed isn't neither pinned by default
[14:48] <NCommander> proposed isn't enabled by default.
[14:48] <RainCT> NCommander: revu neither
[14:48] <NCommander> toche
[14:49] <RainCT> ^^
[14:49] <ScottK> RainCT: Proposed porbably should be though.
[14:49] <ScottK> porb/prob
[14:49] <RainCT> slytherin: dunno, I'm not one of your sponsors :)
[14:49] <iulian> NCommander: Hey, I already merged svk (see bug #297502), you obviously didn't see it. Bug 282793 was already fixed in Debian as well so all we needed to do is to merge.
[14:50] <slytherin> RainCT: Was just kidding. I am planning to apply before year end. :-)
[14:50] <NCommander> iulian, lol
[14:50] <slytherin> \sh: ping
[14:50] <NCommander> iulian, I did get the fix into proposed
[14:52] <iulian> NCommander: Yes, I can see that. The only Ubuntu change is the fix for tab completion.
[14:53] <iulian> NCommander: OK, I will close the bug I reported then.
[14:53] <NCommander> iulian, no, don't
[14:53] <NCommander> iulian, the bug will be autoclosed once the fix is accepted into intrepid <g>
[14:53] <slytherin> handschuh: most of the comments about balloontip apply to your other package as well.
[14:53] <NCommander> iulian, if you wish to redo the merge, your welcome to dit
[14:54] <NCommander> iulian, I'll sponsor
[14:54] <slytherin> handschuh: if you plan to package many java packages, make cdbs your friend. Life will be easier.
[14:55] <handschuh> slytherin: damn ... I wanted to skipp this  ;-)
[14:55] <slytherin> handschuh: skip what?
[14:55] <handschuh> slytherin: cdbs
[14:56] <iulian> NCommander: Well, I don't think it's worth it. Next time we'll just drop your change (which is in Debian as well) and keep the tab completion fix.
[14:56] <slytherin> handschuh: It is really easy once you get to know it. :-)
[14:56] <handschuh> slytherin: ok, I will give it a try
[14:57] <handschuh> slytherin: you don't need to add this onto the other packages
[14:57] <handschuh> slytherin: I will use the libballoontip as a template for the other ones
[15:00] <slytherin> handschuh: yes, I am not adding any comments to other.
[15:01] <ScottK> When you call your ISP and say, "I'm having trouble with DNS." and they say "What's that?", I have a feeling it's not a good thing.
[15:01] <_ruben> ouch :p
[15:01] <handschuh> slytherin: one question is left: I have a package that original source package is just a plain wsdl file ...
[15:01] <iulian> ScottK: It happend to me too.
[15:02] <handschuh> slytherin: is there a get-orig-source rule needed?
[15:02] <slytherin> ScottK: The word 'that' refers to 'trouble' or 'DNS' ? :-P
[15:02] <ScottK> DNS
[15:02] <slytherin> handschuh: yes very much.
[15:02] <ScottK> Turns out I hadn't actually reached tech support, so I haven't abandoned all hope yet.
[15:03] <handschuh> slytherin: ok, but what about its license ... it is not written in the wsdl-file but in a seperate website
[15:04] <ScottK> "If you want, we can arrange for someone to call you back?" - Like I'm going to fall for that trick.
[15:04] <slytherin> handschuh: I haven't ever packaged a wsdl file. So can't really comment on that. Why are you packaging wsdl file by the way?
[15:05] <handschuh> to create the java beans from it on compile
[15:07] <\sh> slytherin: pong
[15:07] <slytherin> \sh: I wanted to discuss the jigdo debdiff you sponsored. But got to go home. Will ping later.
[15:07] <iulian> NCommander: Anyway, the tab completion patch was already forwarded to Debian so that we can sync next time. It seems that the maintainer doesn't look at his bugs which is a bad thing :\
[15:08] <\sh> slytherin: when I'm not responding...tomorrow morning again...:)
[15:08] <slytherin> handschuh: hmm, it has been really long time since I did anything with wsdl.
[15:08] <slytherin> \sh: tomorrow then.
[15:08] <\sh> slytherin: cool :)
[15:08] <ScottK2> Anyone got a DNS server I can use?
[15:09] <broonie> For what?
[15:09] <RainCT> ScottK2: <IP_ADDRESS>  <IP_ADDRESS>  but that's faaar away from you :P
[15:11] <ScottK2> Probably better than what I got right now.
[15:11] <ScottK2> broonie: ISP DNS is very flacky.
[15:12] <broonie> Ah, I tend to install bind locally when I need to work around that.
[15:12] <handschuh> slytherin: you can create the java classes to call the webservice directly from its wsdl-file
[15:13] <ScottK2> Yeah, they're generally very reliable, so I'm unprepared.
[15:13] <RainCT> ScottK2: OpenDNS may also be an option
[15:14] <ScottK2> RainCT: Thanks.
[15:14]  * ScottK2 jumps off IRC so parts/joins don
[15:14] <ScottK2> don't get too anoying.
[15:16] <\sh> jdong: are you filing the sync for fpc?
[15:17] <RainCT> OT, anyone knows what "being down the rabbit hole" means? (they say this at the start of the Matrix on Win video)
[15:17] <jdong> \sh: not that I know of; I really don't have any knowledge of fpc/pascal and would rather have someone with familiarity deal with it
[15:18] <\sh> jdong: k...I'll take it then
[15:18] <jdong> I only got involved because someone had what looked like a trivial patch to fix a bug
[15:18] <jdong> thanks, \sh :)
[15:18] <\sh> RainCT: alice in wonderland
[15:18] <RainCT> \sh: d'oh! thx
[15:19] <\sh> RainCT: could be wrong though, but the last I remember of matrix (orig) was that many statements made by morpheus were coming from alice in wonderland ;)
[15:19] <ScottK2> RainCT: Much better (even far away).  Thanks.
[15:20] <persia> \sh, Your understanding matches mine.
[15:21] <persia> RainCT, Might also reference a Siouxsie Sioux lyric.
[15:24] <\sh> RainCT: http://www.imdb.com/title/tt0133093/trivia :)
[15:25] <\sh> "The film pays a huge homage to Lewis Carroll's "Alice in Wonderland", although there are also references to Marx, Kafka, Zen and Homer's Odyssey. One of the main featured works of literature is "Simulcra and Simulation" by the French philosopher Jean Baudrillaud. The book can be seen lying open in Neo's apartment and was required reading for all the principal cast and crew."
[15:26] <RainCT> OK, thanks all :)
[15:52] <sylvaing> hi i have some problem on upgrade script for mysql database (myisam to innodb) to obm-storage package. because of bug of mysql the upgrade script crash ramdomly. So i would like know if in packaging i must use while pattern, while pattern on 10 try or do not make upgarde on packaging?
[15:54] <persia> sylvaing, The while script to try 10 times sounds like an awful hack.  Better to test if it was successful, and if not, try something differently.  Much better to fix the relevant mysql bug so you don't have to work around it.
[15:56] <jdong> we use this script in our packaging?
[16:02] <gnomefreak> any reason<EMAIL_ADDRESS>gets the merge requests for Lp branches to ~ubuntu-dev branches? it auto rejects atleast my request but shouldnt at all ubuntu-dev and lp branches are not related
[16:03] <sylvaing> persia: yes it's an awfull hack, the mysql bug is the following : the sql update script add foreign keys on existing tables with the Alter table instruction. There is a lot of alter table .. add constraint..  in this script, and once in a while, the innodb engine return a random error on a random line
[16:06] <sylvaing> jdong: now no, but i work on futur upstream version of obm
[16:06] <persia> gnomefreak, ubuntu-dev is very closely related to ~ubuntu-dev branches.
[16:07] <gnomefreak> persia: but the mailing list should not reject merge requests at all its missleading
[16:07] <gnomefreak> asac: got the request but i got reject email
[16:07] <gnomefreak> mailing list should take all or take none
[16:07] <persia> sylvaing, Well, I still think that if you7re encountering issues you'd do best to understand where you had a failure, rather than just blindly trying again.  Even if it's just a timing issue, there are ways to bundle the commands to be sane, and detect the difference between a successful transaction and an unsuccessful transaction.
[16:08] <persia> gnomefreak, That would make sense, but it's complicated.  It was only yesterday that that list was able to properly accept all bugmail.
[16:09] <gnomefreak> persia: maybe fixed in future?
[16:09] <persia> Essentially, LP pretends to be sending from the person who requested the merge, rather than from LP, so it needs whitelisting, except that the list wants to avoid whitelisting everyone, to avoid spam.
[16:09] <persia> gnomefreak, Maybe.  If you've good ideas about how to fix it, I'm sure that those who manage the systems would be interested.
[16:09] <gnomefreak> than maybe make a Lp mailing list for these?
[16:10] <gnomefreak> that way its all inside LP persia ?
[16:10] <persia> That wouldn't help, and in fact, be less good, as there's no way to moderate an LP list easily, and no way for non-members to join a list.
[16:10] <ScottK> So either I'm to believe that my router spontaneously picked a new primary and secondary DNS for me or the ISP changed it without telling me.
[16:10]  * ScottK is voting for #2, but who knows.
[16:11] <persia> ScottK, What OS do you run on your router?  Is it one that permits vendor updates?  Was there a DNS server update recently?  If the answer to the latter two aren't yes, it's very likely the latter.
[16:11] <persia> s/.$/ of your presented options./
[16:12] <ScottK> I don't think it allows vendor updates, but I also got it from the ISP and it's a customized version.
[16:12] <ScottK> All's well that ends well I guess.
[16:12] <persia> Well, if it's from the ISP, #1 and #2 are the same :)
[16:12] <ScottK> True.
[16:22] <bddebian> Heya gang
[16:24] <james_w> http://revu.ubuntuwire.com/details.py?package=libtuxcap looks like it shouldn't be "Needs Work"
[16:25] <james_w> is there a way to undo that?
[16:25] <persia> No simple way : it's a side effect of the test for the email feature.
[16:26] <persia> Essentially, any comment by a reviewer is considered a rejection.
[16:26] <persia> siretart, Do you need that comment?  Maybe it could be removed from the DB?
[16:27] <siretart> do I need what comment?
[16:27] <nxvl> NCommander: k, ACK'd
[16:28] <persia> siretart, The last comment at http://revu.ubuntuwire.com/details.py?package=libtuxcap
[16:28] <persia> Essentially, it's marking the package rejected, which is counter to the "please ignore" part.
[16:30] <siretart> woah, that was ages ago, no?
[16:30] <siretart> no, i don't need that comment
[16:30] <persia> Are you able to delete it?
[16:30] <siretart> not easily, not right now
[16:30]  * persia doesn't know precisely how to do so, and fears breaking things
[16:30] <persia> RainCT, Are you around?  Could you delete the comment?
[16:33] <ScottK> Wouldn't it be simplest for him just to upload it again.
[16:34] <persia> ScottK, Who?  The original packager?
[16:34] <ScottK> Anyone really.
[16:35] <ScottK> At least anyone who's got authority to upload a package.
[16:35] <persia> Well, best to be someone not ubuntu-dev, as uploads by ubuntu-dev has different status.
[16:35] <ScottK> AFAIK REVU works off of who's in debian/changelog, not the key.
[16:35] <ScottK> OK.
[16:35] <persia> Oh, you're right.
[16:35]  * persia double-checks the code
[16:36] <ScottK> Of course now that ubuntu-dev uploads get treated differently, that might be considered a weakness in the system.
[16:37] <persia> Well, it's usually expected that the ubuntu-dev who uploaded will push to NEW, which protects against that to some degree, but that's an interesting point.
[16:39] <persia> Yep.  You're right.  It checks the signature of .changes to make sure the upload is OK, and then trusts changed-by
[16:47] <persia> Nope I'm wrong.  It does look at the uploading user (and now I feel like I should find a problem with the package to again reject it)
[16:47] <geser> Hi bddebian
[16:48] <bddebian> Heya geser
[16:49] <ScottK> OK.  I guess it got changed at some point.
[16:51] <persia> Unfortunately, from a quick review of the code, it looked like you were right the first time, although it's not bad that I review it: I did mean to do some REVU today.
[17:00] <RainCT> persia: Yep. Can't you remove comments yourself?
[17:00] <persia> RainCT, I don't know how, but don't bother deleting it now.  I've already made a mess.
[17:01] <persia> RainCT, I believe I'd have to dig out the password for the DB, and then run the DB client, and mangle stuff.
[17:01] <RainCT> persia: admins have a "delete" link  next to each comment
[17:01]  * persia feels especially abashed, and needs better eyes.
[17:02] <persia> I don't support you could do something so that I wasn't usually logged out of REVU when I click a link?
[17:02] <persia> s/support/suppose/
[17:02] <persia> Anyway, this package hasn't had a review in a while, and probably deserves one anyway.
[17:03] <RainCT> persia: My attempt to fix the sessions didn't work. I think I'll ask on the mod_python ML tomorrow or so (I've to study now)
[17:04] <persia> RainCT, Thanks.  Doing it now isn't essential, but it would likely reduce my confusion level :)
[17:04] <mok0> I lost my "paste-on-middle-mouse-button" on the upgrade to Intrepid... any suggestions on how to get it back??
[17:05] <persia> mok0, Which flavour?
[17:05] <mok0> persia: I run KDE
[17:06]  * persia isn't sure how mouse properties are set in KDE
[17:21] <ScottK> mok0: You're welcome in #kubuntu-devel.
[17:22] <mok0> ScottK: Oh, thanks, but we're having dinner soon. I will come later though
[17:22] <ScottK> OK.
[17:24] <Romario> hello folks, i am using the perlmagick package in one of my programs. Today one of my users contacted me complaining about some errors related to my program. after some research i've found out that the package graphicsmagick-libmagick-dev-compat is the culprit because it provides perlmagick as well. can anybody help me in this case?
[17:25] <Romario> i am not sure if this package should really provide perlmagick because it is a package of graphicsmagick (imagemagick fork)
[17:25] <Romario> and there seem to be some incompatibilites
[18:15] <slytherin> Can anyone please tell me how can I attach a file to a debian bug?
[18:18] <NCommander> slytherin, attach it to your email.
[18:18] <slytherin> NCommander: Ok.
[18:19] <mrooney> Does anyone know a simple python package I could check out with a setup.py? I am looking for an example of how to make mine, where to put the binary, desktop file, etc
[18:20] <slytherin> NCommander: Can I do it at the time of submitting the bug?
[18:20] <NCommander> slytherin, yeah
[18:22] <persia> !packaging
[18:23] <mrooney> thanks persia I will see if that can assist me
[18:24] <persia> mrooney, Once of https://wiki.ubuntu.com/PackagingGuide/Complete#Reference%20Packages ought be a good choice.
[18:24] <persia> s/Once/One/
[18:37] <slytherin> persia: Do we usually sync packages from experimental?
[18:41] <geser> slytherin: default is to sync from unstable but it's possible to sync from experimental on request
[18:42] <slytherin> geser: Ok. Was thinking about syncing batik/fop from experimental. But just found few problems and reported them. I will wait for these packages to enter unstable.
[18:42] <persia> slytherin, I'd recommend only doing so post-DIF or if there's some special reason.  Especially with the Lenny freeze, experimental is full of stuff that will drop into unstable and get autosynced (unless you're syncing over Ubuntu variation).
[18:43] <geser> slytherin: it's possible that it only get into unstable after the lenny release
[18:44] <slytherin> persia: My main purpose is to drop Ubuntu changes. But as I said I will wait for them to enter unstable.
[18:44] <ScottK> The key with Experimental is to understand why something is in Experimental.
[18:44] <geser> and there is currently still(?) a discussion about non-free firmware in Debian main ongoing which might delay the release
[18:44] <persia> slytherin, In the case of syncing to drop Ubuntu changes, pulling from experimental sounds useful to me, although as ScottK points out, understanding is key.
[18:59] <mrooney> persia: thanks for the links, the jokosher package looks like a great reference for a setup.py!
[19:05] <NCommander> hola DktrKranz
[19:07] <DktrKranz> hey NCommander
[19:07] <NCommander> DktrKranz, are you running intrepid?
[19:08] <DktrKranz> jaunty, but I've VM
[19:13] <NCommander> DktrKranz, want to test svk in proposed (it makes it installable)
[19:14] <DktrKranz> does it need GUI? or just CLI?
[19:16] <slytherin> persia: right. I have understood it now when I tested fop. :-)
[19:17] <slytherin> NCommander: I am running intrepid. If all I need to test is if it installs or not then I can try. Of course if download size is more than 5 MB then not.
[19:18] <NCommander> DktrKranz, CLI
[19:18] <NCommander> slytherin, its small, but it pulls in a good chunk of perl modules deps
[19:19] <DktrKranz> NCommander, I'll fire up a chroot then
[19:19] <NCommander> cool
[19:19] <DktrKranz> bug number?
[19:22] <bmm> Any MOTU: I will happily accept any comment on http://revu.ubuntuwire.com/details.py?package=metalink :)
[19:23]  * persia rejects metalink
[19:23] <slytherin> persia: why?
[19:23] <persia> I'm writing that up now :)
[19:28] <DktrKranz> NCommander, anyway, it's still building, so I need to postpone testing
[19:29] <superm1> i clearly haven't been to revu in a while.  it looks nice and useful now :)
[19:30] <persia> bmm, Commented.
[19:30] <slytherin> NCommander: tell me bug number
[19:31] <bmm> persia: cool, thanks!
[19:32] <DktrKranz> slytherin, still building, you can't test it for now
[19:32] <slytherin> oh, ok
[19:32] <persia> bmm, It's looking better.  #1 is probably just a side effect of earlier adjustments, #2 is minor.  #3 needs a bit of upstream work, and #4 should be trivial.
[19:33] <bmm> persia: already on it, I'll let you know if I hit any walls ;)
[19:33] <persia> bmm, OK.  I'm a big believer in lots of eyes, so I'll recommend you get someone else for the next look.
[19:33] <bmm> persia: will do
[19:37] <slytherin> persia: pm?
[19:40] <sebner> persia: what do you think about point 6?
[19:41] <persia> sebner, -ECONTEXT
[19:42] <sebner> persia: /me likes that -E stuff :P, metalink, first comment, point 6
[19:44] <persia> sebner, That's been fixed.
[19:45] <sebner> persia: I know but what do you think about this point? I've had a discussion if that's: a must have, optional, nonsense
[19:47] <persia> I believe the short description should complete the sentence "$(package) is a $(short description)." which would make it redundant.
[19:47] <sebner> persia: so more like a "must have" right?
[19:48] <sebner> persia: you might also have seen this point in my REVU example revie
[19:48] <sebner> +w
[19:52] <bmm> persia: thanks for the comments. I've posted the licensing problem upstream and went with debhelper 7, removed TODO and NEWS but left README because it contains the caveats description.
[19:53] <sebner> bmm: if you don't need dh7 you should use a lower version to make backporting easier
[19:53] <sebner> it seems you don't use any of it's features (e.g debian/rules)
[19:54] <persia> bmm, My apologies if I included README.  I thought that was end-user interesting.
[19:55] <persia> bmm, Also, although I haven't looked, I agree : either use the debhelper 7 features, or don't require it.
[19:55] <sebner> persia: though the backporting argument isn't that valid anymore. it's not very likely to backport from jaunty to hardy since intrepid has debhelper7
[19:56] <bmm> sebner: backporting shouldn't make a difference, as debhelper 7 has been backported. So dh7 should work, even when backporting.
[19:56] <bmm> sebner: but you are right about the features not being used.
[19:57] <persia> sebner, Well, it's as valid as it's ever been.  To me, it's that one should declare the version of debhelper one actually uses, rather than some random version because it seemed like a good idea.
[19:57] <bmm> persia: you didn't include README inthe comment, I just mentioned it as it was the last file left.
[19:57] <persia> bmm, Good.  I was afraid I made a mistake :)  Keeping README is essential for users to be able to understand the limitations.
[19:57] <sebner> persia: of course it makes no sense to use debhelper 7 if you don't use it's features but besides backporting issues were always a top argument
[20:00] <bmm> I must admit that I'm not really sure about the whole debhelper verioning. Isn't using a higher version also showing that your package has no problems with the new features?
[20:00] <ScottK> We have debdhelper 7 in hardy-backports.
[20:00] <persia> sebner, To me it's always been about accuracy, rather than backporting.  Declaring >=5 and then using dh_iconcache is just as bad as declaring >= 7 and not using 7's features.
[20:00] <ScottK> bmm: It's the opposite.  Using the lower version to say you don't require the newer features.
[20:00] <bmm> ScottK: it's not about backporting anymore, it's about wether you use a higher version when you don't use the new features :)
[20:01] <ScottK> And persia is correct about that.
[20:01] <ScottK> You should describe the minimum version required for your package given the debhelper features you use.
[20:01] <persia> bmm, It's never been about backporting.  It's always been about accuracy.  Declare what you need to build.  Declare it accurately.  The rest is unimportant.
[20:01] <sebner> persia: hehe, I know what you mean. personally I started with 5 as lowest but I can remember merges that FTBFS because of dh_iconcache =)
[20:04] <sebner> persia: btw, does lintian still complains about dh7 (about missing things in debian/rules)?
[20:05] <bmm> sebner: no
[20:05] <bmm> sebner: I've just uploaded dh7 onto revu and the lintian is clean :)
[20:05] <sebner> bmm: no I mean a dh7 debian/rules file. that uses it's minimalistic style
[20:06] <bmm> sebner: ah, then I don't know :)
[20:08] <bmm> persia: I'm reading the debhelper manual and it seems like I can just use v4. Should I try that?
[20:09] <bmm> Hmmm... the debhelper manual state that "V7" is the "recommended mode of operation".. I'm only getting more and more confused here :S
[20:09] <persia> bmm, Check the debhelper changelog carefully, but maybe.  Most people don't like to go below 5 because 5 made several things easier.
[20:10] <persia> V7 is recommended, but not required.  If you want to use the older debhelper, it's OK, but it will get out of date sooner.  If you want to use V7 that's OK, but you should use it.
[20:11] <bmm> persia, then I should just go with 5 as a minimum version and up as the features require me to. Ok, sounds good. I'll change to 5 and do a pdebuild check.
[20:12] <pochu> V4 isn't deprecated yet...
[20:13] <bmm> pochu: no, but it will be sooner then 5, so that is the main reason to go with 5.
[20:13] <pochu> ah, 5 is fine :)
[20:13] <bmm> good... finally... yes.... 5 it is :D
[20:13] <persia> 6 or 7 is also fine: it's mostly a matter of how you want to do your package.
[20:13] <sebner> dh-make automatically uses 5 it has to be fine :P
[20:13] <leonel> ScottK: make a single  diff  for all the patches ???
[20:13] <sebner> persia: I suppose between 5->6 happened that much?
[20:14] <pochu> I'd only go for 6/7 if I'm using new features from them
[20:14] <pochu> If not, I'd go with 5
[20:14] <bmm> pochu, thanks! Then I'm  still sticking with 5 for my new upload
[20:14] <sebner> persia: * not that much
[20:14] <sebner> bmm: it's fine
[20:16]  * mok0 thinks you should use the minimum required compat number
[20:17] <persia> sebner, Read the changelog.  There were lots of good improvements, like better mkshlibs support, dh_icons, dpkg triggers, --ignore, dh_desktop becoming sane, dh_installudev stuff, etc.  The basic format of debian/rules didn't change though.
[20:17] <sebner> persia: I see, thx
[20:18] <persia> I'd not want to do a GUI app with less than dh6, as it means careful checking to make sure one gets the right version of dh5.
[20:23] <rrittenhouse> I have a question it seems nobody knows anything else about. If I go to "Places --> Connect to Server" and I connect to my webserver (which I use an ssh key to access with user www-data) I am not able to create folders or even edit anything because it mounts as read only. Any ideas before I file a bug report?
[20:25] <joaopinto> rrittenhouse, this is the wrong channel to ask, ask on #ubuntu
[20:26] <rrittenhouse> Sorry. I understand it's the wrong channel but it just seems nobody really knew the answer so I thought someone here might have more experience with it or maybe have ran into it.
[20:27] <joaopinto> rrittenhouse, I didn't saw your question there :)
[20:27] <rrittenhouse> I've been asking for 3 days :D
[20:28] <joaopinto> and I don't see much sense on assuming the 200 users here have more experience with nautilus/ssh than the 1500 there :)
[20:28] <persia> rrittenhouse, #ubuntu-bugs is probably a better place to ask where to file a bug.  I'd personally select gvfs as a starting point.
[20:28] <rrittenhouse> Maybe thats the problem.. too many people lol
[20:28] <mok0> rrittenhouse: perhaps your webserver is exporting its filesystem readonly
[20:29] <joaopinto> persia, you are assuming that it is a bug, and not lack of understanding on how privilege works :)
[20:29] <mok0> rrittenhouse: It's most likely not a bug
[20:29] <persia> joaopinto, Yep.  I always assume it's a bug.
[20:29] <rrittenhouse> That's why I don't want to file a bug report. The perms appear to be correct though.
[20:30] <joaopinto> I always assume is an user error, statistically they are more than bugs :P
[20:30] <rrittenhouse> I can do it through the terminal just fine. It's the nautilus thing that can't do it :P
[20:31] <joaopinto> rrittenhouse, have you searched on launchpad ?
[20:31] <joaopinto> (if you believe it's a bug)
[20:32] <mok0> or Ubuntu Forums
[20:32] <rrittenhouse> I've searched LP and Google, and UF. My friend and I have both had this problem even in Hardy. Besides in hardy you could edit the files and not create any dirs. Now you can't do either!
[20:36] <joaopinto> rrittenhouse, maybe it's bug 244779 ?
[20:48] <handschuh> why do I have to specify JAVA_HOME or JAVACMD when using cdbs and the ant.mk ?
[21:00] <persia> handschuh, Because we've not yet reached the point of having one true Java in Ubuntu.
[21:00] <handschuh> persia: but why doesn't it use the default one if specifyed in system?
[21:01] <persia> handschuh, Because there isn't a default one specified on the buildds in a sane way.
[21:01]  * laga has had his share of making eclipse use the correct JVM today
[21:02] <persia> laga, You're tackling the new upstream?
[21:02] <handschuh> persia: well as it is an ant class why dont you let ant decide
[21:03] <persia> handschuh, Well, sometimes it doesn't decide in the way you want (see note above about eclipse)
[21:04] <handschuh> persia: eclipse has a strange start-script, thats it  anyways do I really HAVE to use cdbs?
[21:05] <persia> handschuh, No.  Some people find it easier.  Our currently most active Java maintainer (slytherin) is one of them.
[21:06] <handschuh> persia: slytherin told me to use it so it seems I have to use it
[21:06] <laga> persia: no, just doing development on hardy and intrepid
[21:07] <laga> persia: java development*
[21:07] <persia> handschuh, It's a choice.  Slytherin recommends using it, but if you really don't want to, that's OK as well.
[21:07] <laga> handschuh: ... and the startup script for eclipse is full of crack, at least in hardy.
[21:07] <persia> laga, Ah.  I was hoping.  There's two big names in Java environments, and currently we're well out of date on one of them.
[21:08] <laga> eclipse is outdated, but i'm not sure how bad it is
[21:08] <handschuh> laga: here is no real debian package of eclipse ... otherwise they would have used "update-alternatives" in their script
[21:10] <handschuh> slytherin: ping
[21:19] <miik> when nvidia 177.82 in repo?
[21:21] <miik> yo dudes put firefox 3.0.4 in the repo
[21:22] <laga> handschuh: so the ubuntu maintainer broke it? ;)
[21:22] <persia> miik, You may be better served by investigating the relevant packages, and sending appropriate patches to achieve the results you want to the frequent uploaders of the packages that interest you in bug reports.
[21:22] <handschuh> laga: he just has not fixed this
[21:23] <laga> handschuh: where does the package come from?
[21:23] <miik> persia, you say nobody will put 3.0.4 in repo????????? GRRRRRRRRRRRRRRRRRRRRRRr
[21:23] <handschuh> laga: i think its a sync from debian
[21:23] <miik> and about 177.82, what if it dont come, and then my 177.80 dont work with new kernel -8 ?
[21:24] <persia> miik, No, I'm saying that "yo dudes put firefox 3.0.4 in the repo" doesn't help achieve that goal.
[21:24] <miik> oh
[21:24] <miik> well, can you put 3.0.4 in repo, please?
[21:26] <pwnguin> miik: why the repo?
[21:26] <persia> miik, Thanks for that, but it's not about being polite, it's that the work needs doing :)
[21:26] <pwnguin> someone already publishes 3.1
[21:26] <pwnguin> in a ppa
[21:28] <miik> pwnguin, so it can fall from there into my computer
[21:29] <miik> persia, well someone packaged 3.0, 3.0.1, 3.0.2, 3.0.3, etc there must be an automated script that does it
[21:31] <persia> miik, There are scripts, but no, it's not automatic.  You're seeing the results of human effort.
[21:31] <miik> what is it that human does?
[21:31] <miik> it should be fully automated scripted
[21:32] <pwnguin> only if you want it to fail fully automatically
[21:33] <persia> miik, The humans make sure it's not broken before deploying it to millions of users.
[21:36] <miik> persia, well there should be some automatic QA too
[21:36] <miik> though, its good with human look at it too
[21:38] <persia> miik, There is automated QA, but it's not considered sufficient.
[21:38] <persia> That's why I suggested you could help.  The more people who help, the faster the QA can be done, and the sooner things reach the repos.
[21:43] <pwnguin> there's also the mozilla branding dilligence
[21:43] <pwnguin> i dont recall what the terms were
[21:45] <miik> ok, how i can help?
[21:47] <pwnguin> well 1, join the right channel ;)
[21:48] <pwnguin> #ubuntu-mozillateam
[21:50] <miik> aye
[21:51] <miik> when nvidia 177.82 in repo?
[22:00] <handschuh> finally I am using cdbs, but I am getting the following error: http://paste.ubuntu.com/71519/  (line 60 ist important)
[22:01] <azeem> handschuh: it's better to set LANG to C if you want help from non-germans as well
[22:01] <handschuh> azeem: how to?
[22:01] <directhex> LANG=C before doing things?
[22:01] <persia> miik, I think the nvidia drivers are pulled by jockey.  I'm not sure whether it needs an adjustment to jockey directly, or to some online DB.  You'd probably do best to check the jockey code, and then either offer to help the local package or upstream point at the new drivers.
[22:02] <azeem> handschuh: pastebin your debian/control
[22:02] <superm1> persia, i think it's just a matter of whether 177.82 goes into proposed or backports at this point
[22:02] <superm1> once it's updated for jaunty of course
[22:02] <wgrant> persia: It actually just needs the new driver package. I heard it was going into backports, but it's still undecided.
[22:03] <handschuh> directhex: thx -> http://paste.ubuntu.com/71524/
[22:03]  * persia doesn't keep track of these things, and appreciates the data.
[22:03] <persia> My goal was mostly just pointing towards things that might be more helpful than asking for an update.
[22:03] <miik> im using proprietary nvidia driver, but my jockey is empty :s
[22:08] <pwnguin> i never see a lot of nvidia on the ubuntu-x channel; so i guess tseliot mainly inherited that mess
[22:08] <tseliot> pwnguin: yes, I did
[22:09] <tseliot> milk: try installing nvidia-common
[22:10] <superm1> crimsun, how were the defaults for the various mixers (front, master, pcm) chosen to be set at 80%?  was it an arbitrary selection?
[22:10] <azeem> handschuh: eh, did you see what I suggested?
[22:11] <pwnguin> superm1: i would be amazed if there was some formula that worked out to exactly 80 percent ;)
[22:11] <handschuh> azeem: sry overred -> http://paste.ubuntu.com/71526/
[22:11] <azeem> that's not a debian/control
[22:12] <handschuh> azeem: again, i am sorry: http://paste.ubuntu.com/71528/
[22:12] <azeem> but anyway, I guess you're missing at least one code CDBS class, like debhelper.mk
[22:12] <azeem> s/code/core/
[22:12] <azeem> cause besides ant running install, nothing else being done, like the creation of a .deb
[22:13] <superm1> crimsun, pwnguin,haha. well i guess a better way to put it, was there a lot of experimentation done to determine 80% was optimal?  It seems that a lot of the mixers i've seen that have a front and master, setting front to 100 but leaving others at 80 gives a better starting result particularly because then the hotkeys can adjust the volume range to it's full potential
[22:13] <azeem> handschuh: why the Conflicts: gij?
[22:14] <handschuh> azeem: great hint! thanks a lot
[22:14] <handschuh> azeem: because it wont run on gij (swing)
[22:17] <azeem> handschuh: are you aware that this means none of your users can install any gij-using application then?
[22:18] <handschuh> azeem: yes I am ... I havn't found an other way
[22:18] <azeem> handschuh: what is the error message when gij is installed?
[22:19] <handschuh> azeem: it will show no error ... but it will also show no jframe
[22:19] <azeem> and shouldn't there be a more specialized dependency for swing than just java5-runtime?
[22:20] <handschuh> azeem: the problem is that gij claims to provide java5-runtime
[22:20] <azeem> is swing part of java5-runtime?
[22:21] <handschuh> azzem: on openjdk-jre and the sun jre it is
[22:21] <azeem> did you try with libswt3.2-gtk-java or so?
[22:21] <handschuh> azeem: because it does not depend on swt
[22:22] <azeem> handschuh: that wasn't the question; I assume "java5-runtime" is a well-defined set of things
[22:22] <azeem> handschuh: well, I suggest you ask one of the Ubuntu java experts
[22:24] <handschuh> azeem: unfortunatly there is no such thing as a "java5-runtime-swing"-package
[22:24] <azeem> how about depending on a specific java5-runtime which supports swing then
[22:25] <handschuh> azeem:that was forbidden
[22:25] <azeem> by whom?
[22:26] <handschuh> by slytherin
[22:26] <azeem> did you tell slytherin that you're conflicting with gij?
[22:27] <handschuh> did not
[22:27] <azeem> it looks like the wrong solution to me
[22:28] <handschuh> well ... it half is bad and half is good because cij and swing is a real pain
[22:29] <azeem> isn't gij useful for other stuff besides swing?
[22:29] <handschuh> maybe
[22:29] <handschuh> but if gij is declared as the default jre, gij will try to start a gui
[22:30] <handschuh> wich fails quite often
[22:30] <handschuh> e/wich/which
[22:31] <handschuh> assuming that the user has no jre installed and wants to install the library I am working on, apitude might offer gij to be installed
[22:32] <handschuh> that is what i want to prevent
[22:33] <azeem> handschuh: 23:18 < azeem> handschuh: well, I suggest you ask one of the Ubuntu java experts
[22:34] <handschuh> azeem: will do that!
[22:34] <azeem> handschuh: having alternatives in there should probably be fine, like openjdk-jre | java5-runtime
[22:34] <handschuh> azeem: thanks again for helping me with my rules file
[22:34] <handschuh> azzeem: that might work!
[22:34] <handschuh> -z
[22:35] <persia> handschuh, Be warned that for several architectures, there is no openjdk, so it needs to use gcj.
[22:36] <handschuh> persia: hm.
[22:36] <handschuh> persia: is there a tag "works sometimes with"? :-)
[22:37] <leslieviljoen> Hi everyone! My powerpc packages for Thunar seem to be preventing the segfault problem. I have uploaded them to mediafire, but how would one get fixed packages distributed via "apt-get upgrade" for powerpc? Mediafire is a pain. I am thinking of making a website for them, but the apt repos are really the proper place.
[22:37] <persia> No, although one can set architecture-specific dependencies if needed.
[22:37] <persia> Generally it's best to depend on the default, and work to make sure the default does what is needed.
[22:37] <azeem> this is an Arch: all package
[22:38] <persia> leslieviljoen, Create a debdiff, attach it to a bug describing the problem in detail, and subscribe ubuntu-universe-sponsors to the bug.  Someone will probably tell you to fix several things, and it can be included.
[22:39] <persia> azeem, Yes, but it may not work with the same set of dependencies on all architectures, because the architectures have different sets of JREs available.
[22:39] <persia> azeem, It's about ensuring the package has the right environment for each architecture, even though the package itself is unchanged.
[22:39] <azeem> right, but how do you express arch-specific Depends for an arch: all package?
[22:40] <leslieviljoen> I'd ask how to create a debdiff, except that there is no source change between the broken and working packages. I think they were built with some wrong version of a library, possibly libglib.
[22:40] <persia> I think it's the same syntax, although I could be mistaken.
[22:40] <azeem> or do you mean some run-time architecture detection
[22:40] <persia> No, in packaging, not in the code.
[22:40] <azeem> [!i386] only works for Build-Depends
[22:40] <azeem> at least AFAIK, maybe Ubuntu changed that
[22:40] <leslieviljoen> I tried compiling them to debug them, but they went from constant immediate segfaults to working without any source changes
[22:40] <persia> Worked for depends last I checked, but maybe only in the source package, and it gets determined at package build time.
[22:41] <azeem> well, there is type-handling
[22:41] <persia> leslieviljoen, In that case, just file a bug describing the situation, and that a rebuild is required, and subscribe the sponsors.  No debdiff required.
[22:41] <azeem> but it's considered quite ugly
[22:41] <persia> azeem, Let's pretend there isn't :)
[22:41] <leslieviljoen> great, who are the sponsors and how to I subscribe them?
[22:42] <persia> When you file the bug, there's a link to subscribe someone else.  Subscribe "ubuntu-universe-sponsors"
[22:42]  * persia peers about for some Xubuntu-dev who might want to look at this.
[22:42] <leslieviljoen> ok, will do. is it always "ubuntu-universe-sponsors"?
[22:44] <persia> Most of the time.  About 10-15% of the time it's #ubuntu-main-sponsors".   It depends on whether the package is in universe or main.
[22:53] <NIK> Hello... anybody here knows if the MOTU 896 woks on linux??
[22:56] <persia> NIK, Firstly, #ubuntustudio is probably a better place for that question, and secondly MOTU is actively anti-linux, so if it works it's not well supported.  Consider another vendor, or if you already have it, try with a liveCD and test.
[22:56] <NIK> ok!! thanks!
[22:56] <pwnguin> now theres something that needs context
[22:57] <pwnguin> "MOTU is actively anti-linux"
[22:57] <persia> pwnguin, It's a audio interface.
[22:57] <wgrant> Heh.
[22:57] <persia> Mark of the Unicorn vs. Masters of the Universe
[22:57] <NIK> jejej...
[22:58] <ajmitch> much like plone is anti-sanity </complaint> :)
[23:03] <leslieviljoen> persia: thanks, done
[23:04] <leslieviljoen> bye all!
[23:13] <LimCore> hi, is there a quick instruction how to get sources, apply my fix, and rebuild/test/etc one of applications with an annoying bug (https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/296741) ?  Some wiki url or something?
[23:27] <persia> LimCore, If you're not much fussed about how you apply your fix, just apt-get source $(package), edit stuff to meet your needs, run debuild -b, and test the result.
[23:27] <persia> If it works, you probably want to look at the right patch system to use when applying the changes, etc.
[23:27] <persia> !patch
[23:34] <jdong> consipracy theories begin: http://jdong.mit.edu/~jdong/gates_bldg_linux_curse.jpg
[23:35] <jdong> photo quality isn't great, but the computer on the right is running XP.
[23:38] <jdong> to make matters worse, I just logged into the other Linux machine and it hardlocked.


[14:31] <tseliot> apw, rtg: hey, which branch shall I use to have code included in 16.04? master-next?
[14:31] <apw> tseliot, you should base pull-requests on master-next yes
[14:31] <tseliot> apw: ok, thanks
[14:32] <apw> tseliot, i don't suppose i want to know what this vomit it, but if it is what i expect then we'll want a bug for it please to tie the gazillion commits together
[14:33] <tseliot> apw: it's all (upstreamed) open source code for amdgpu, and yes, I can file a bug report about it
[14:33] <apw> tseliot, that'd be lovely, put the buglink in all the commits please too,
[14:33] <tseliot> apw: sure
[16:10] <manjo> rtg, apw looks like the patches to support http://is.gd/0GhbMU are in 4.1/4.2 any idea if we have this feature in xenial ?
[16:13] <apw> manjo, i have not, i'd refer you to slangasek or whoever is working it
[16:13] <manjo> yeah
[16:13] <manjo> I will check with slangasek
[17:43] <niluje> is there a way to set isolcpus without rebooting and change the cmdline?
[17:43] <niluje> I need to exclude several cores from the scheduler
[17:47] <apw> it depends what that actually does, does it unplug them or just ignore them
[17:47] <niluje> apw: was that for me?
[17:48] <apw> niluje, yes
[17:49] <niluje> I want to ignore them
[17:49] <niluje> I have a DPDK application that calls setaffinity to use four cores
[17:49] <niluje> I dont want something else to run on these cores
[17:51] <apw> niluje, anyhow the only thing that appears to update that is the early kernel parmeter, so i suspect not
[17:53] <niluje> :(
[17:53] <niluje> thanks a lot apw
[18:16] <hallyn> apw: sforshee; so cgroup namespaces are now in linux-next.  Do I nee dto do anything to request them going into xenial kernel?  (I assume so...)  just an email to ubuntu kernel list?
[18:48] <apw> hallyn and they need to be in before tomorrow, so dont wait
[18:49] <hallyn> apw: don't wait with what?
[18:49] <hallyn> email to kernel list?
[18:49] <hallyn> or something else?  Pull request?
[18:49] <hallyn> (i guess i used the wrong list last week and earlier this week)
[18:58] <arges> hallyn<EMAIL_ADDRESS>[19:01] <hallyn> arges: thanks, just sent it there
[19:02] <arges> hallyn: it may help to have a pull-request of a tree where the specific patches are applied on top of hte xenial tree
[19:02] <arges> or just [PATCH] emails ifs its short and they cleanly git am on xenial
[19:02] <hallyn> arges: ...  yeah, xenial is already pretty out of date so a pr may be worthwhile
[19:02] <hallyn> grumble
[19:03] <hallyn> i wonder whether my kernel.ubuntu.com git acct access is still valid - haven't used it since it migrated i dont' think
[19:04] <arges> hallyn: i see a /home/serge on that machine
[19:04] <hallyn> http://kernel.ubuntu.com/git/?ofs=500  should really provide a [from-to] range under each # at the bottom of the page :)
[19:05]  * hallyn shuts up before someone drafts him to web hack
[19:05] <hallyn> arges: last touched 3 years ago :)
[21:17] <lamont> jsalisbury: next rock, pls?
[21:18] <jsalisbury> lamont, ack, I'll let you knwo when the next one is ready
[21:21] <lamont> ta
[22:21] <lamont> jsalisbury: bad.  next ?
[22:26] <jsalisbury> lamont, ack
[22:53] <jsalisbury> lamont, next kernel is ready
[22:55] <lamont> jsalisbury: should I be concerned that it's 4.2.0rc8 when the last known good was 4.3.0-7?
[22:56] <jsalisbury> lamont, no, the naming is kind of weird.  The last kernel was bad, so this build is now back in time
[22:57] <lamont> np
[22:57] <lamont> it just means that Ihave to actually interrupt the boot process and pick one
[22:57] <jsalisbury> lamont, the bisect bounces around allot, especially when there are merges
[22:57] <lamont> ah
[22:58] <lamont> jsalisbury: good kernel.  next?
[22:58] <jsalisbury> lamont, great, I'll start the next build
[23:00] <lamont> jsalisbury: and not that we care, but one monitor is screaming about "Out of Range"
[23:00] <lamont> h 48.2KHz V 44.3Hz
[23:01] <lamont> (yes the one that disappears in the bad kernels)
[23:01] <lamont> there is just something satisfying about: sudo apt-get purge linux-image-$(uname -r) && reboot


[14:54] <ypwong> dpm, ping
[14:56] <ypwong> is there a schedule for language pack update so we can have the latest translations for final beta?
[14:56] <dpm> hi ypwong
[14:57] <dpm> ypwong, for the development release language packs are uploaded regularly except for the freezes
[14:57] <dpm> that said, I've not been involved in language packs this cycle, so I'll need to make sure that's still the case
[14:58] <ypwong> dpm, who's responsible for this cycle now?
[14:59] <ypwong> as we think without latest translation update for final beta, it's difficult to spot missing translations or errors
[15:00] <dpm> ypwong, there is no direct responsible for now, that's the issue we've got. It falls in the domain of the desktop or foundations guys probably.
[15:05] <ypwong> dpm, I see, let me ask slangasek
[15:09] <dpm> ypwong, or jasoncwarner or seb128 for desktop
[15:10] <ypwong> dpm, got it, thanks


[07:36] <smb> Morning .+
[07:41] <diwic> smb, good morning. How is ssh towards kernel.ubuntu.com working for you this morning?
[07:41] <smb> diwic, The same it did the previous weeks. Not
[07:42] <diwic> smb, okay - then the error is not on my side. Is there currently any way to push to a git tree there?
[07:42] <smb> diwic, Not that I am aware of.
[07:42] <diwic> smb, ok.
[07:44] <jjohansen> err doesn't it just work if you push through zinc?
[07:45] <smb> jjohansen, If master is up again
[07:45] <smb> Oh
[07:45] <smb> diwic, Sorry not enough coffee
[07:45] <smb> I read kernel.org
[07:46] <jjohansen> smb: no kernel.org isn't backup, and it will be done different when it is
[07:46] <smb> diwic, kernel.ubuntu.com works for me
[07:46] <jjohansen> me too
[07:47] <diwic> jjohansen, interesting, zinc.canonical.com works but kernel.ubuntu.com does not
[07:47] <smb> diwic, Have you changed some keys? Maybe different entries in ssh/config
[07:48] <diwic> smb, yeah, that's probably it. Thanks.
[07:48] <jjohansen> diwic: hrmm, not sure why, I don't think I actually ever use kernel.ubuntu.com for ssh, only zinc
[07:49] <smb> jjohansen, Its just another name for the same machine
[07:50] <jjohansen> smb: I am never sure what gets multiple eithernet interfaces and haven't bothered checking that they are the same
[07:51]  * diwic happily pushes an update to a tree on kernel.ubuntu.com, thanks for the assistance
[07:57] <diwic> btw, linuxfoundation.org is up now, it was down among the others last time I checked (a week ago or so?)
[07:57]  * smb thinks that one also had an incident
[07:58] <jjohansen> yep, separate incident
[07:58] <diwic> smb, I think so too, but at least they seem to be working on something
[07:58] <diwic> if something comes back up :-)
[08:40] <janimo> hello, how can I get (should I?) access to the git servers to host a new tree - the ac100 ARM kernel published in the archives in oneiric
[08:40] <janimo> which currently is only available as a source package
[10:13] <apw> janimo, cirtainly it seems reasonable that the kernel is stored somewhere if its master source is git
[10:14] <apw> (i assume thats hwat you are saying)
[10:14] <janimo> apw, so what do you suggest, how do I go about getting an account on the ubuntu kernel machine?
[10:15] <janimo> apw, what I say is I suppose there's a policy of stroring ubuntu kernel trees on the same server
[10:15] <janimo> as opposed to me keeping it on github
[10:15] <janimo> even if the later would be much sweeter :)
[10:16] <apw> actually we don't have any particular policy, the ubuntu ones are on kernel.u.c, the linaro ones are on a linaro server i believe, github is fine as long as people know it is there
[10:16] <apw> janimo, indeed if it is there we probabally could mirror it as well if you like to have it on githum
[10:18] <janimo> apw, whatever the kernel team thinks is better really
[10:18] <janimo> even if you guys are not very likely to need to touch this particular tree
[10:19] <ogra_> well, ppisati expressed intrest on a 3.0 port
[10:19] <janimo> I just thought it would be weird to have a kernel for an ubuntu shipped arm image reside on github
[10:19] <janimo> ogra_, well not sure if needed, it is being done upstream and we may just need to get it for free in P
[10:19] <ogra_> and given that we ship this kernel on images we build, i think at least mirroring the packaging bits to k.u.c should happen
[10:19] <ogra_> so you can find it in the place you expect to find ubuntu kernels
[10:20] <ogra_> work can for sure happen on github if you prefer, but we should make it accessible through an ubuntu channel
[10:22] <Kano> apw: why dont you add the 3 dvb fixes?
[10:22] <Kano> it is in YOUR launchpad
[10:22] <Kano> so...
[10:22]  * ogra_ wasnt aware apw is responsible for launchpad
[10:22] <apw> why don't you trust me to proritise my time appropriatly
[10:23] <Kano> because you released one kernel without that fix
[10:23] <apw> while you think a dvb issue is important, i personally think security issues which affect the entire userbase are more important, that you don't agree is a worry for your users
[10:24] <Kano> well there are simpler ways to attack linux users than exploiting kernel issues
[10:25] <janimo> a baseball bat for instance
[10:26] <apw> and they are only $15 on amazon, we'd better ban them
[10:27] <janimo> that would just make the black market for bb bats more active
[10:27] <apw> Kano, seems i have lost the reference to the bug
[10:27] <janimo> ogra_, I would use gitorious too as upstream hosts it there, but gitorious sometimes has availability issues
[10:28] <janimo> hmm, and .git is > 500M would not fit in a github free plan
[10:29] <apw> janimo, depends, if you fork linus' tree you may be ok
[10:29] <janimo> apw, it is fork of a tree on gitorious
[10:29] <janimo> a 2.6.38 one
[10:29] <apw> ick
[10:29] <janimo> exactly
[10:29] <janimo> well, it is the best among the free services probably
[10:30] <apw> well if you want kernel.u.c access then the best place to start is by bringing it up on kernel-team@ ...
[10:31] <janimo> apw, ok thanks
[10:53] <Kano> apw: http://lists.debian.org/debian-kernel/2011/08/msg00932.html
[10:54] <Kano> somewhere should be a reference in launchpad too to that link
[10:54] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/838130
[10:54] <ubot2> Ubuntu bug 838130 in linux "Kernel 3.0 breaks DVB-T (ISDB-Tb) in DiBcom 8000" [Undecided,Confirmed]
[10:55] <Kano> tjaalton: did you try a patched kernel yet?
[10:56] <tjaalton> Kano: yes, but not sure if my device is affected after all
[10:56] <tjaalton> i need to try again to be sure
[10:57] <tjaalton> it works after the patches, but it might've been "broken" for other reasons (PEBKAC mostly)
[10:58] <Kano> most likely not
[10:58] <Kano> there are definitely cards which require the patches
[10:58] <tjaalton> i had issues with the antenna too
[10:58] <Kano> they work with 2 patches already, the 3rd does not have got that heavy impact
[10:59] <Kano> but as you say it works with all 3 too
[10:59] <Kano> there are 2 kanotix users who i know personally which need that fix
[11:00] <Kano> most likely there are even more u users...
[11:22]  * ppisati -> out for lunch
[12:22] <lamont> ppisati: dunno why, but the current natty kernel on some (apparently video enabled) pandas hates the network far more than the maverick kernel
[13:02] <ppisati> lamont: uhm, what you mean for video enabled?
[13:03] <ppisati> lamont: does it have a video connected?
[13:04] <lamont> no actual monitor / etc connected that I know
[13:06] <ppisati> lamont: so what you mean for "video enabled"?
[13:07] <lamont> not sure, 'twas a comment the arm guys made based on the panic we saw
[13:07] <lamont> Nafallo: anything diff about habitat vs the other pandas?
[13:08] <ogra_> ppisati, in a past kernel we had an issue with the kernel locking up if the system triggers suspend on console without monitor attached
[13:08] <ogra_> i havent seen that since maverick though
[13:08] <lamont> anyway, afk for a whil
[13:08] <ppisati> ogra_: AFAIK suspend is still broken now (with or without monitor)
[13:09] <ppisati> ogra_: but i don't think it's the case for lamont
[13:09] <ogra_> ppisati, i'm talking about dpms on console
[13:10] <ppisati> ogra_: ah k
[13:22] <ppisati> ogra_: btw, i upgraded my panda this morning
[13:22] <ppisati> ogra_: and i noticed that if you don't use it for a while
[13:22] <ppisati> ogra_: $someone suspend it
[13:23] <ppisati> ogra_: http://paste.ubuntu.com/697869/
[13:23] <ogra_> ppisati, complain to #ubuntu-desktop
[13:23] <ppisati> never happened before
[13:23] <ogra_> ppisati, known bug, gnoem-power-manager defaults to suspend after 30min
[13:23] <ppisati> but i noticed it when i came back from lunch
[13:23] <ogra_> regardless if you are on battery or AC
[13:23] <ppisati> ah
[13:23] <ogra_> did you manage to resume actually ?
[13:24] <ppisati> ogra_: nope
[13:25] <ppisati> ogra_: LAN as no WOL
[13:25] <ppisati> ogra_: keyboard doesn't affetc it
[13:25] <ppisati> ogra_: and even setting the rtc doesn't help
[13:25] <ogra_> yeah, and there is no resume button anywhere :)
[13:25] <ppisati> ogra_: :)
[13:26] <ogra_> btw, did you hear that we have suspend working fine on ac100 ?
[13:26] <ogra_> and sound through headphones
[13:26] <ppisati> nope
[13:26] <ppisati> cool
[13:26] <ppisati> i'm stiil waitingh for the ac42 cable
[13:26] <ppisati> i want to solder it on the motherboard to get a serial console
[13:26] <ericm|ubuntu> apw, do you know how can I completely disable the kernel-wedge thing to produce d-i udebs?
[13:30] <tgardner> ericm|ubuntu, it is the kernel-wedge thing that produces the udebs
[13:30] <ericm|ubuntu> tgardner, the problem is we don't necessarily need those udebs
[13:30] <tgardner> ericm|ubuntu, so, you'd like to bypass udeb generation altogether ?
[13:31] <apw> udebs are only made if your architecture is mentioned in machines.in
[13:31] <ericm|ubuntu> tgardner, yes if that's possible
[13:31] <apw> debian.master/d-i/kernel-versions.in
[13:31] <apw> i should say kernel-versions.in
[13:31] <ericm|ubuntu> apw, let me check
[13:32] <ericm|ubuntu> apw, what can we do to that file?
[13:32] <ericm|ubuntu> apw, to disable generating udebs?
[13:33] <tgardner> apw, I think CONFIG_MODULE_UNLOAD=n for mainline builds. Do you recall if there was a specific reason for that?
[13:33] <tgardner> ericm|ubuntu, simply comment out the armel line
[13:33] <diwic> ogra_, sound through headphones?
[13:33] <ericm|ubuntu> tgardner, ah all right - stupid me
[13:34] <diwic> ogra_, on 2.6.38?
[13:34] <ogra_> diwic, yep :D
[13:34] <diwic> ogra_, congratulations!
[13:35] <ogra_> not my work :) but thanks :)
[13:40] <Nafallo> lamont: not that I'm aware. want me to go check revisions etc?
[13:57] <apw> tgardner, are you saying we are wacking _UNLOAD to n in mainline ?
[13:58] <tgardner> apw, I think so.
[13:59] <tgardner> apw, though I'm not sure how just yet.
[13:59] <apw> hmm not intentionally now
[14:07] <apw> tgardner, so whats not working ?
[14:08] <tgardner> apw, http://stackoverflow.com/questions/7482469/why-is-this-kernel-module-marked-at-permanent-on-2-6-39
[14:11] <apw> tgardner, well he mentions they are marked permenant
[14:14] <tgardner> apw, is that a different config option?
[14:15] <tgardner> hmm, not taht I can find
[14:16] <apw> it is possible they broke  module unload in those mainline kernels
[14:16] <tgardner> are we carrying a patch for that? I sure don't remember anything
[14:16] <apw>         if (mod->init != NULL && mod->exit == NULL) {
[14:16] <apw>                 printed_something = 1;
[14:16] <apw>                 seq_printf(m, "[permanent],");
[14:16] <apw> no we have nothing to fix it for sure
[14:16] <apw> so i'd have to guess his module is compiled wrong somehow
[14:18] <apw> tgardner, have you reproduced the effect ?
[14:18] <tgardner> apw, not yet. I'll work on it.
[14:18] <tgardner> I'll get a VM going
[14:21] <bjf> ##
[14:21] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:21] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[14:21] <bjf> ##
[14:21] <apw> tgardner, i will point out he is using some random snapshot of the kernel so i am not going to be supprised if it is reporoducible, but not in a release tag for mainline
[14:29] <tgardner> apw, well, I can add and remove fat.o in a mainline Lucid kernel.
[14:30] <apw> he seems to be using 2.6.39-02063904-generic wich would be a specific days tip
[14:30] <tgardner> I'll try that one
[14:30] <apw> if it fails, i'd recommend finding 2.6.39 tag version and see if its gone, as for the described use case i cannot see why that would not be a more appropriate test version
[14:31] <tgardner> apw, I'm just gonna try <IP_ADDRESS> and if it works, then its not our problem
[14:56] <herton> ppisati: are you able to verify/test the -proposed kernel for bug 709245 on maverick? (or if you know who could test it)
[14:57] <ubot2> Launchpad bug 709245 in linux-linaro "ARM SMP scheduler performance bug" [Medium,Confirmed] https://launchpad.net/bugs/709245
[15:05]  * ogasawara back in 20
[15:06] <ogra_> herton, i'm pretty sure it will land in the next set of GrueMaster's tests
[15:08] <herton> ogra_: ack, being tested this week it's fine
[15:09] <ogra_> herton, no idea if its this week, better ask GrueMaster ... he is the arm QA person for such stuff (and should be notified in advance)
[15:11] <herton> ogra_: it's not QA, it's just the bug verification. There is only this bug waiting to be verified for linux-ti-omap4 on maverick, once someone does it it'll go to testing/QA
[15:11] <apw> herton, any idea why natty ti-omap4 is lagging so far behind the others in getting out to -updates ?
[15:11] <herton> apw: I think it went to -updates, let me check
[15:11] <apw> ahh is that just security being lax then
[15:11] <bjf> skaet, cjwatson tells me that bug #790240 should not be part of the rls-mgr-o-tracking-bugs report, do you concur ?
[15:11] <ubot2> Launchpad bug 790240 in gnome-mag "at-spi needs demotion for oneiric (at-spi2-core in main)" [Medium,Confirmed] https://launchpad.net/bugs/790240
[15:12] <bjf> skaet, it has no "open" oneiric tasks
[15:12] <skaet> bjf,  otp,  will review in about an hour.
[15:13] <bjf> skaet, np, no rush
[15:13] <herton> apw: yep, everything fine, 2.6.38-1209.15 was released (rmadison shows it on -updates, 2.6.38-1209.15, bug 837761)
[15:13] <ubot2> Launchpad bug 837761 in linux-ti-omap4 "linux-ti-omap4: 2.6.38-1209.15 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/837761
[15:24] <lamont> Nafallo: if you have a few minutes, I'd be extremely interested in the difference between say habitat and algol
[16:06] <bjf> ##
[16:06] <bjf> ## Kernel team meeting in one hour
[16:06] <bjf> ##
[16:15]  * apw wanders out to enjoy the sun ... back in 30
[16:20] <skaet> bjf,  re: 790240,  yeah given it won't be fixed in oneiric,  and nothing is planned for SRUs for it,  makes sense for it not to show up on the list.   I've gone and altered the tag to "rls-mgr-p-tracking".
[16:54] <cking_> you heard it from apw, sunshine in the UK is possible
[16:57] <Sarvatt> 30 whole minutes of it a day yeah
[16:58] <cking> that's enough to get a small tan on the top of one's head
[17:08] <apw> one cannot expose ones soft southern skin to the sun for more than 30m anyhow, else it peels off
[17:09] <apw> cking, any good experiences with s/r on sandybridge ?
[17:12]  * tgardner hopes he doesn't toast his Emerald by installing a xen hypervisor
[17:15] <cking> apw, kinda works, we pushed it passed 250 on quite a few occasions, but generally a pass level of 30 iterations seems possible most times
[17:17] <cking> it depends on a lotta factors though, why? you seeing problems?
[17:22] <apw> cking, yeah this one s but not r
[17:24]  * ppisati -> gym
[17:24] <cking> well, that's 50% OK then ;-)
[17:24] <cking> you willing to try that S3 stap script to see if you get insight
[17:56]  * tgardner -> lunch
[18:01]  * jjohansen -> runs an errand
[18:15]  * jjohansen back
[19:58] <BarkingFish> Good evening guys.  I wonder if you could help me please.  I've been trying to use a kernel module from 2.6.38-11-generic to make my HP iPAQ RX1950 register, but the USB Ident wasn't in the module.  So I got the code, wrote a makefile, and rebuilt the module against that kernel.
[19:59] <BarkingFish> Modinfo will read the details, and clearly now shows the usb ident for my device in the alias list.  But it won't insmod into the kernel - I get the following error: FATAL: Cannot insert /home/thor/Downloads/ipaqsrc/ipaq.ko - Unknown symbol in module (-1)
[20:00] <BarkingFish> I have no idea what i've done wrong, but building the module produced no errors
[20:01] <BarkingFish> Could anyone possibly give me some advice as to what I might do about this issue please? It's vital that i get this module working
[20:33] <dhunt> anybody here have compiled linux 3.0 with "make deb-pkg" succesfully?
[20:41] <BarkingFish> Hi again. Sorry, I've sorted out the kernel module now.  Is there anyway of getting hold of the source code of the .ko that was used to build the kernel module which came with a particular kernel, please?
[20:41] <BarkingFish> I'd like to see how it compares to the one I built this end.
[20:44] <dhunt> how do you build it?
[20:45] <BarkingFish> I got the original code of ipaq.c from a git repository on the net, and wrote a basic makefile for it to turn it into a module, ran it and wound up with a .ko including the usbident for my iPAQ.
[20:46] <BarkingFish> I tested it using insmod and it went in, and it's appearing in lsmod
[20:46] <BarkingFish> i already have the ipaq.h file in my kernel headers
[20:51] <BarkingFish> dhunt, the issue with the original version of the module was that my iPAQ's USBID (03f0:1c1d) wasn't included in it, so I edited the code to add the ident in and rebuilt it.
[21:00] <dhunt> BarkingFish: can't help on that sorry, I misunderstood you before,  I'm trying myself to compile 3.0 with make deb-pkg since kernel-package does not works
[21:01] <BarkingFish> Thanks anyway.  All I need is the .c file for the code that was used to make the current ipaq.ko module in 2.6.38-11-generic-pae, so that I can compare how it looks.  Anyone else have any ideas on how to get it please?
[21:06] <dhunt> oh that, go to the kernel git and get a regression to that revision
[21:08] <BarkingFish> dhunt, brilliant!  I just need to find the git repo for the kernel now :)
[21:08] <dhunt> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
[21:08] <dhunt> BarkingFish: change the version depending of the one you use
[21:09] <BarkingFish> do I have to specify the name of the kernel exactly, like 2.6.38-11-generic-pae or will 2.6.38-11 suffice?
[21:10] <dhunt> no no, 2.6 is the branch I guess
[21:10] <dhunt> the exact revision depends
[21:10] <dhunt> anyway forget that
[21:11] <dhunt> download the source of the version you use
[21:11] <BarkingFish> so git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.38-11-generic-pae would work?
[21:11] <dhunt> is faster than git
[21:11] <dhunt> the second parameter is just the name you´re putting locally
[21:12] <dhunt> you can do git clone git:/.....linux.git BarkingFish and it works
[21:12] <BarkingFish> ah ok. Thanks a load dhunt, I appreciate it.
[21:13] <dhunt> ur welcome ;)
[21:13] <BarkingFish> Nice! I wouldn't mind building a barkingKernel :)
[21:13] <BarkingFish> anyhow, I have to go for a bit, got some other stuff to do.
[21:13] <BarkingFish> See you later
[23:48] <hallyn> i'll try to come up with a tigher way to reproduce this, but when I create 4 lxc containers through openstack, which creates their filesystems on qemu-nbd block devices as ext4, I frequently get oopses like http://people.canonical.com/~serge/20110927_001.jpg
[23:49] <hallyn> after which clean shutdown is impossible