[05:34]  * micahg wonders how tumbleweed got cairo-dock-foo to build
[08:06] <benonsoftware> This is proberly a silly question but if I wanted to package a Java program could I just folllow the Packaging Guide?
[08:07] <geser> sure
[08:08] <benonsoftware> geser: Thanks
[08:08] <geser> just make sure that you recompile any .jar files instead of using the prebuild upstream ones
[08:09] <benonsoftware> Ok, thank you very much
[08:50] <tumbleweed> micahg: given its dependencies, it gave me no trouble (they're in NEW)
[08:50] <micahg> tumbleweed: ah, I looked :)
[08:50] <micahg> didn't see them there, but I trust you
[08:51] <tumbleweed> otoh, bug 923688 is pretty high on the annoyance list atm
[11:31] <azeem> so how many hours till feature freeze, or is it frozen already?
[11:31] <ajmitch> 2100UTC
[11:31] <azeem> thx
[11:32] <azeem> requestsyncs from Debian NEW are not possible, right?
[11:32] <ajmitch> I don't think they are, because it's not accessible
[11:34] <micahg> well, the only way they certainly are
[11:34] <micahg> s/only/old/
[11:35] <ajmitch> if you've got the source package itself, then it's possible
[11:36] <micahg> you can dget from NEW
[11:36] <ajmitch> oh you can now?
[11:36]  * ajmitch guesses it's been this way for awhile :)
[11:37]  * micahg thinks you can at least
[11:52] <Laney> ubuntu new, yeah
[11:53] <Laney> actually that might be the case in which you still need dgetlp
[11:53] <Laney> there is still one, I forget what it is
[11:53] <micahg> Laney: no, was referring to Debian NEW
[11:53] <Laney> but debian new, no I don't think so
[11:54] <Laney> even if I ssh to ries I can't access the files
[11:59] <micahg> hmm, must have been confusing it with something else
[12:10] <tumbleweed> you can get thnigs from incoming.debian.org, but that's not NEW
[12:10] <tumbleweed> and of course, many packages are in VCS...
[13:11] <Laney> I would much prefer people to wait and FFE than do fakesyncs
[13:12]  * tumbleweed too
[13:13] <tumbleweed> btw, any opinions on the tesseract FFe? Its in the grey area for me
[13:13] <tumbleweed> much better OCR, but have to remove a reverse-dep
[13:14] <Laney> will look later
[13:20]  * Laney begins writing an annoucement of the uninstallable packages challenge
[13:20] <Laney> http://debian.titanpad.com/7
[13:22] <tumbleweed> err, requires login
[13:22] <Laney> i made it public
[13:22] <Laney> and I am editing it without being logged in right now
[13:23] <tumbleweed> aha
[13:23] <Laney> yah boo
[13:23] <Laney> nigelb deleted his blog post for the ftbfs jam
[13:23] <Laney> oh, no, just broke old links
[13:24] <Laney> (or the link in tumbleweed's original email was wrong :P)
[13:25]  * tumbleweed refuses to beleive that possibility
[13:25] <Laney> hmm
[13:25] <Laney> the graphs aren't that convincing that the jam made a difference
[13:27] <tumbleweed> we were at ~300 FTBFS packages at the time...
[13:28] <Laney> as in
[13:28] <Laney> there's a steady downward trend that seemed to start before the jam happened
[13:29] <tumbleweed> we got one or two new people in, working on it. And they mostly evaporated again
[13:30]  * tumbleweed discovers a qa-ftbfs cronjob still running on his server, and kills it
[13:32] <Laney> is there a better link for oneiric-historical.html?
[13:32] <tumbleweed> no, I couldn't find one
[13:33] <Laney> didn't know if it moved to ubuntuwire
[13:33] <tumbleweed> it did, but not at that time
[13:33] <tumbleweed> http://people.ubuntuwire.org/~stefanor/lp-ftbfs-report/historical/
[13:33] <Laney> huh, sub-50?
[13:34] <tumbleweed> primary archive, not rebuilds
[13:34] <Laney> i suppose the archive rebuild would be worse
[13:34] <Laney> but still that's better than i would have necessarily thought
[13:34] <tumbleweed> wgrant isn't using my graph additions in his rebuild-ftbfs-test reports
[13:35] <tumbleweed> (poke poke)
[13:37] <tumbleweed> I don't think we should do automated bug filing for the uninstallability issues, just for the jam. So collaborate with an etherpad?
[13:38] <Laney> ye
[13:46] <adhorden> Hi all, having a few issues updating a package for Precise, build log is here https://launchpadlibrarian.net/93036528/buildlog_ubuntu-precise-i386.ruby-rvm_1.10.2-0ubuntu4_FAILEDTOBUILD.txt.gz, i am getting permission errors but not sure where to look to get to the bottom of the problem
[13:48] <Laney> you can't write to the 'real' filesystem when building a package; make the build system install to pkgbuilddir/debian/tmp
[13:48] <tumbleweed> adhorden: it's no trespecting the DESTDIR provided
[13:49] <tumbleweed> also, it should not be installing to usr/local at all
[13:49] <Laney> it's probably a broken install script in this case
[13:54] <adhorden> Laney: this is what I was thinking the install script seems to be breaking things here, might have to hack that up so that it uses DESTDIR
[13:55] <Laney> yes, that is the standard interface
[13:55] <adhorden> I was thinking this would be an easy script to package up, its been nothing but headaches
[13:56] <Laney> life is made much easier when people use standard build systems
[13:56] <tumbleweed> ruby packages also seem to have that affect on people
[13:57] <Laney> i have still managed to avoid it completely
[13:57]  * tumbleweed too
[13:57] <adhorden> yup, and in this case rvm does not use a standard build system it uses its own install shell script
[13:58] <tumbleweed> I thought iamfuzz promisdet o look after rvm? (I seem to remember being hesitant to want it in the archive at all)
[14:01] <adhorden> not sure who the maintainer is, there was a bug in the package so I took a look into it and bumped the upstream version as it was really out of date, I was going to submit my patches to bring it upto date
[14:02] <tumbleweed> adhorden: ubuntu packages don't have maintainers, and this one needs some maintainance
[14:02] <adhorden> ah right, well I am taking a look into it as I am using precise on my systems at present and would be nice to have a native working package for rvm
[15:47] <pabelanger> tumbleweed: re: bug 408757, I talked to the upstream maintainer and they don't have a problem with what you suggested. I already submitted the patch into Debian, working on updating the debdiff
[15:48] <pabelanger> it's actually bug 897006 but the debdiff is in the other issue (trying to close both of them in one shot(
[16:01] <tumbleweed> we've got through "grave" in rcbugs. It'd be nice if we could get through all the serious bugs that are fixed in new upstream versions, but that's a lot for one evening :P
[16:29] <nigelb> Laney: I did? Looking
[16:29] <Laney> nigelb: nah, I think it was a wrong link in the initial mail
[16:29] <nigelb> ah, quite possible.
[16:30] <nigelb> Laney: http://nigelb.me/ubuntu/2011/06/27/fix-ftbfs-jam.html
[16:31] <Laney> the link said /07/
[16:32] <tumbleweed> draft maybe?
[16:33] <nigelb> Hrm, interesting.
[16:51] <tumbleweed> ok, I'm through all the low-hanging serious-severity rcbugs that are fixed with new upstream versions (well, one still test-buliding)
[16:52] <tumbleweed> poor non-x86 buildds
[18:05] <ajmitch> tumbleweed: nice work with the rc bugs
[18:07] <ajmitch> tumbleweed: so you did decide to sync yaws in the end? I wasn't sure what the changelog was meaning by removing erlang patches
[18:14] <jtaylor> so, time for some last minute merging ;)
[18:15] <ajmitch> still a couple of hours let I think
[18:15] <ajmitch> s/let/left/
[18:16] <jtaylor> yes 21:00 utc I was told
[18:17]  * ajmitch is still getting his laptop back to usable
[18:18] <jtaylor> meh scipy built a couple minutes to early and did not pick the new numpy :(
[18:18] <jtaylor> on armel
[18:22] <ajmitch> ouch
[18:22] <ajmitch> how long did it take to build?
[18:23] <jtaylor> 4 hours
[18:23] <jtaylor> scipy numpy less
[18:25] <jtaylor> rebuilds of -ubuntuX just increase X? or add a buildY to the version?
[18:28] <pabelanger> merge, merge!
[18:29] <jtaylor> hm ok how do I merge a 13.5 mb package with my 11kb/s upload connection?
[18:29] <jtaylor> I could sync it and then add the diff in a second upload ;)
[18:30] <stefanct> do you have a time machine at hand? :)
[18:30] <jtaylor> hm can I dput from alioth? (after I signed it locally?)
[18:31] <stefanct> what's the latest possible time i could file a sync request and get it merged into 12.04 without exception? also 21:00 utc or does it need to be processed already by that time?
[18:32] <ajmitch> jtaylor: I don't see why you shouldn't be able to dput from alioth
[18:33] <broder> stefanct: my understanding is that we will be accepting sync requests without FFes if they are filed before FF
[18:35] <stefanct> am i allowed to file a sync request even though the debian package has not hit the archives yet? (yes i am quite desperate :/)
[18:36] <jtaylor> if its new ffe's are usually easier to get
[18:36] <stefanct> ic
[18:36] <stefanct> we are preparing a release upstream atm... but i doubt that it gets ready in time
[18:37] <jtaylor> oh its only an update not completely new?
[18:37] <ajmitch> what are you updating?
[18:37] <stefanct> flashrom, app to flash bios chips etc. last release was last summer
[18:37] <stefanct> jtaylor: not a completely new package, no
[18:42] <valdur55> Hey. i is possible to patch one package?
[18:49] <pabelanger> don't want to rock the boat, but another other sponsors care to comment on bug 408757
[18:49] <pabelanger> and bug 897006
[18:50] <broder> pabelanger: do you have any sense of when the debian maintainer is planning to release their new version with the split?
[18:52] <pabelanger> broder: not sure, just pinged him but waiting to hear back.
[18:53] <pabelanger> The package is not very active, last release was Dec. 2010
[18:53] <pabelanger> Now that I am using it more for a customer site, I suspect I'll be pushing upstream to help keep it active
[18:55] <broder> pabelanger: oh, i see. the client just isn't getting shipped at all currently? i assumed that you were taking a monolithic package and splitting it up into smaller packages
[18:56] <broder> i'm much less opposed to what you're doing
[18:56] <broder> (splitting up a package - especially when you know debian's about to do it too - has enough risk of introducing subtle differences between debian's split and ubuntu's split that it always makes me uncomfortable)
[18:57] <broder> pabelanger: anyway, the patch seems conceptually reasonable, but i can't do a full review right now
[18:57] <pabelanger> Okay, thanks for the look
[19:55] <jtaylor> hm I want to sync the new plplot, but it requries a mini transition
[19:55] <jtaylor> 3 packages
[19:55] <jtaylor> one of them ftbs but fix available in debian testing
[19:56] <jtaylor> should I file a sync request instead of syncing that? because plplot will not be done building until freeze
[20:00] <Ampelbein> jtaylor: Is the fix for testing a new upstream version? If not, you are fine, sync plplot now and do the rebuilds after plplot finished on all architectures.
[20:00] <jtaylor> it is
[20:00] <jtaylor> new upstream
[20:00] <jtaylor> though a minor, not sure how extensive
[20:07] <Ampelbein> It isn't too hard to get a FFe shortly after freeze, especially when it's only a minor update.
[20:48] <jtaylor> phew all done
[20:49] <jtaylor> all remaining numpy packages had new versions in debian..., so I pulled them all hopefully I don't have to much mess to clean up this weekend xD
[20:50] <jtaylor> (they all have very extensive test suites which were successful, so its unlikely)
[20:57] <tumbleweed> ajmitch: I probably should have tested it, but it built...
[20:57] <ScottK> jtaylor: Re should you wait on syncing stuff: There's a long (unfortunate) tradition of tons of crap getting uploaded right at feature freeze, so I wouldn't suggest handicapping yoursef.
[20:58] <tumbleweed> don't know if tulp is worth sneaking in. There's a much newer upstream verison in debian which builds unmodified, but maybe not on all archs...
[21:00] <tumbleweed> broder: the nsca client is currently being shipped, just in the server pakage
[21:00] <tumbleweed> *package
[21:00] <broder> oh, i see
[21:00] <broder> well, it's still using pre-existing packaging to do the split
[21:03] <tumbleweed> the pre-existing rules allows building a client-only package
[21:03] <tumbleweed> but if it's going into the archive, I say let's split it properly...
[21:04] <ajmitch> so, feature freeze in effect now?
[21:04] <tumbleweed> yup, but FFes are cheap for the first few days :)
[21:07] <tumbleweed> ah, I see someone hit the Debian NEW queue this evening
[21:14] <ajmitch> tumbleweed: so we can bug you or any other friendly release team member? :)
[21:14] <tumbleweed> that's what we're here for (/me hides)
[21:17] <ajmitch> Laney: thanks :)
[21:17] <Laney> DENIED
[21:17] <ajmitch> :'(
[21:17]  * ajmitch shall go back to lurking instead
[21:17] <Laney> ♥
[21:18]  * Laney → pub
[21:18]  * tumbleweed just got back from the pub
[21:18] <ajmitch> bit early for the pub for me
[22:41] <aboudreault> hi, hey how can I pass the -j option (dpkg-buildpackage) via debuild...
[22:41] <aboudreault> I did it.. but can remember how...
[22:41] <aboudreault> -j8 directly just fails.
[22:41] <jtaylor> works for me
[22:42] <aboudreault> jtaylor, debuild -us -uc -j8
[22:42] <aboudreault> something similar?
[22:42] <jtaylor> yes
[22:42] <jtaylor> it passes it to dpkg-buildpackage which has the option in its manpage
[22:43] <aboudreault> dpkg-buildpackage -rfakeroot -D -us -uc -j8 failed
[22:43] <aboudreault> if I remove the -j8... I see it begins the compilation
[22:43] <jtaylor> which package?
[22:43] <jtaylor> no further information?
[22:44] <aboudreault> shouldn't be related to any package
[22:44] <aboudreault> general question. using this with our packages.
[22:44] <aboudreault> will use dpkg-buildpackages directly
[22:45] <aboudreault> oh well.... even the dpkg-buildpackages fails. will build slowly then
[22:52] <jtaylor> hm how do I fix this: http://paste.ubuntu.com/845099/
[22:54] <jtaylor> a figured it out, had to remove a -build-deps