[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.here>
[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 Xubuntu0.7.10.1,Xubuntu0.8.04.1, 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 0.1.7.04, 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: 212.73.32.3  212.73.32.67  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 universe-bugs-owner@lists.ubuntu.com 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.