[11:45] <Laney> once again I long for dw and nmu in Launchpad :'(
[11:52] <geser> "dw"?
[11:57] <Laney> depwait
[11:57] <Laney> so I could schedule the haskell rebuilds now without worrying that it's not finished on armel yet
[11:57] <geser> if you build-depend on the new ghc6 then the builds get into depwait
[11:58] <Laney> of course, but that requires changing every package
[11:59] <geser> is the Debian buildd "more" clever in this regard?
[11:59] <Laney> it has this 'dw' support
[12:00] <geser> so you can tell it to wait till a previous binnmu is done?
[12:01] <Laney> dw libghc6-mtl-dev . armel . -m 'ghc6 (>= 6.12.3-1ubuntu2)' or similar
[12:01] <Laney> will add a depwait with that constraint
[12:01] <geser> nice
[12:01] <tumbleweed> filed an LP bug? :)
[12:02] <geser> and since there seems now to be a massive armel give-back you need to wait till the queue is empty before starting with those haskell-rebuilds to be sure they get build in the right order
[12:02] <tumbleweed> doesn't give-back have 0 priority?
[12:03] <Laney> https://bugs.launchpad.net/launchpad/+bug/245594
[12:03] <Laney> my ghc6 build doesn't seem to be starting
[12:03] <geser> armel 1441 jobs (five days)
[12:04] <geser> the LP API doc mentions "build.dependencies" as writeable but I don't know what happens it one tries to write it
[12:06] <tumbleweed> aah, "private source" that wins all build-score wars by default
[12:19] <ari-tczew> Daviey: what's the point of your comment 16 in bug 700198 ?
[12:43] <tumbleweed> bdrung: poking my way through your u-d-t comments from yesterday. You suggested srcpkg.check(), but I can't really think of a decent API for it. It would need to return a list of mismatches for syncpackage, but that makes the function difficult to use anywhere else
[12:45] <bdrung> tumbleweed: let's call it verify instead. wouldn't true and false be enough?
[12:46] <tumbleweed> bdrung: hmm, that might actually be ok. IIRC the current code checks the filenames of the mismatches, to see if they are .orig... but I don't know why
[12:48] <bdrung> tumbleweed: because only the orig files can lead to problems. so a function verify_orig() would be nice.
[12:49] <tumbleweed> bdrung: what other mismatches will you get?
[12:49] <bdrung> tumbleweed: having mismatching .debian.* files doesn't matter with the next upload.
[12:50] <tumbleweed> but those contain version numbers, so they should be immune
[12:50] <tumbleweed> unless we are bumping epoch but not anything else
[14:11] <iulian> Hey bdrung.  I've just noticed the ubuntu-dev-team on Launchpad.  What was the reason behind registering it?  I apologies if this was already covered but I obviously was not aware of it.
[14:12] <tumbleweed> iulian: it's just to own the daily builds
[14:13] <iulian> Oh, alrighty.  Cheers tumbleweed!
[14:25] <bdrung> iulian: what tumbleweed said and to have a lp group for the ubuntu-dev-team@lists.alioth.debian.org team
[14:25] <bdrung> http://qa.debian.org/developer.php?login=ubuntu-dev-team@lists.alioth.debian.org
[14:26] <tumbleweed> err, I thought that was u-d-t dev (slap face)
[14:32] <bdrung> right, that are two different teams
[15:18] <ari-tczew> ScottK: I uploaded clementine to lucid-backports.
[15:19] <ari-tczew> ScottK: oh, I forgot about bug report.
[15:57] <tumbleweed> bdrung: u-d-t: all addressed, I believe (test suite is getting rather slow :/)
[16:13] <ScottK> ari-tczew: What bug?
[16:14] <ari-tczew> ScottK: bug 703292, but I have to update patch to fix ftbfs on armel in natty first.
[16:14] <ScottK> OK.  Let me know when it's ready.
[16:14] <ari-tczew> Sure.
[16:26] <ari-tczew> debfx: could you look on package rlplot? it's affected by FTBFS, you fixed last FTBFS, maybe you can fix it again.
[17:13] <bdrung> tumbleweed: why did you put all files into example_package.py? having the example package extracted into one directory would be enough.
[17:14] <debfx> ari-tczew: I've uploaded a fix for rlplot
[17:16] <tumbleweed> bdrung: I needed a non-native package, generating them on demand during build is probably also useful for testing syncpackage type behavior
[17:18] <bdrung> tumbleweed: that's not a reason for putting everything in example_package.py. you could create the orig and the source package from a directory in example_package.py
[17:29] <ari-tczew> debfx: thanks
[17:47] <tumbleweed> bdrung: and it's done
[18:00] <bdrung> tumbleweed: DebianSourcePackage._source_urls: Invalid name "it"
[18:00] <bdrung> tumbleweed: rmadison: Invalid name "p" (--> "process"?)
[18:02] <bdrung> tumbleweed: trailing space in d/rules in test-data
[18:02] <bdrung> tumbleweed: run wrap-and-sort in test-data :)
[18:03] <bdrung> tumbleweed: in ubuntutools.test.test_archive Method could be a function -> convert to private (leading _) functions
[18:05] <tumbleweed> pylint is a little too pedantic about variable names :/
[18:05] <tumbleweed> it is a perfectly good name for an iterator
[18:06] <bdrung> tumbleweed: having slightly longer names is a benefit.
[18:07] <bdrung> tumbleweed: having only one char variables making the code hard to read. example: https://answers.launchpad.net/libkibi/+question/139749
[18:08]  * tumbleweed agrees with that in general, but one or two of them are fine
[18:08] <bdrung> things like "i" are ok
[18:11] <bdrung> tumbleweed: you import SourcePackagePublishingHistory twice?
[18:13] <tumbleweed> re method could be function, I disagree, much neater like it is (4 very similar functions, some need to be methods)
[18:14] <tumbleweed> requestsync.lp and requestync.mail intentionally have the same names for different things
[18:15] <tumbleweed> bdrung: pushed r979
[18:21] <bdrung> tumbleweed: it makes to sense to me why archive.py uses ubuntutools.requestsync.mail. If functions from there are needed, they should be moved.
[18:22] <bdrung> tumbleweed: maybe an object for rmadison?
[18:25] <tumbleweed> it's not that they are needed, it's just convenient (it's only a tiny class that looks like a lpapicache SPPH)
[18:25] <tumbleweed> what would you add to an rmadison class?
[18:29] <bdrung> good question
[18:29] <tumbleweed> I guess I'll move that SPPH thing, it's neater
[19:11] <crying> Hey guys, where can I get grub help? I've messed it up a lot!
[19:14] <Bachstelze> crying: #ubuntu is the place for technical help
[19:40] <bdrung> tumbleweed: do you like writing man pages?
[19:45] <tumbleweed> bdrung: that's called a loaded question :P I write them when I need to
[19:47] <bdrung> tumbleweed: i hate writing (in general). that include writing man pages. there's a "byteprefix" man page on my todo list (last point before releasing libkibi)
[19:49] <tumbleweed> bdrung: heh, empty NEWS, README, TODO, I see :)
[19:50] <bdrung> tumbleweed: kibi/kibi.h is documented
[19:59] <bdrung> tumbleweed: and debian/copyright has some information
[20:01] <bdrung> tumbleweed: you don't want to help me writing the man page?
[20:07] <tumbleweed> bdrung: aren't .la files deprecated?
[20:12] <tumbleweed> bdrung: happy to help, just not too sure where to start, I'm probably more use as an editor
[20:17] <bdrung> tumbleweed: IIRC, .la are deprecated. i only use the .la file for building the test program, which shouldn't link to the system libkibi.
[20:19] <tumbleweed> bdrung: it's installed in the -dev package
[20:20] <bdrung> tumbleweed: i want to have a man page for byteprefix, which describes the configuration. there is the BYTEPREFIX env variable, /etc/byteprefix and $xdg_config/byteprefix
[20:20] <geser> bdrung: shouldn't a -L. (or whereever the build lib is) do it instead too?
[20:21] <bdrung> geser: let me try it.
[20:21] <tumbleweed> bdrung: ah, that's something I can work with. /me adds it to the weekend todo list
[20:21] <bdrung> geser: to which automake variable should i add that?
[20:22] <geser> LIBS I'd say, before the -lkibi
[20:22] <geser> or how the lib is named
[20:25] <geser> if you the test program you might need to set LD_LIBRARY_PATH so it uses your build lib instead of the system one (unless you do static linking)
[20:27] <bdrung> geser: that was the reason why i used static linking
[20:49] <hakermania> Guys, wallch is one step before advocating. Can someone please that uses Ubuntu with GNOME desktop to go and test it? Thank you, the link is Wallch
[20:49] <hakermania>  
[20:50] <hakermania> http://revu.ubuntuwire.com/p/wallch