[03:09] <TheMuso> c
[05:23] <soaringsky> can someone please review my package packtools in revu?
[06:55] <soaringsky> can someone please review my package packtools in revu?
[07:52] <dholbach> good morning
[08:19] <iulian> Morning dholbach.
[08:19]  * iulian yawns.
[08:20] <dholbach> hi iulian
[08:20]  * dholbach yawns too
[09:07]  * Laney stretches
[09:37] <Laney> dholbach: hey! how are you?
[09:38] <dholbach> Laney, excellent - thanks - how about you?
[09:38] <Laney> I came across the packaging tutorial of lucas the other day http://people.debian.org/~laney/packaging-tutorial/
[09:38] <Laney> I wonder if we could rob the (concept of) exercises
[09:38] <Laney> yeah good, enjoying a bank holiday :-)
[09:38] <dholbach> nice
[09:38] <dholbach> yeah, sounds good to me - can you file a bug about it?
[09:39] <Laney> i shall try
[09:39] <lucas> it would be better if you contributed to it, rather than robbing from it;)
[09:40] <hrw> morning
[09:41] <hrw> can someone tell me what for revu-uploaders group exists?
[09:41] <hrw> it is listed as 'no longer necessary' but each 'ubuntu contributor' becames member of it.
[09:41] <Laney> lucas: heh, it's not exactly the same
[09:41] <Laney> presentation vs. html guide
[09:41] <Laney> it's in the same ball park though (learning material), so ...
[09:43] <geser> hrw: just ignore it, it was used in the past before REVU could import gpg keys from LP for fresh uploaders
[09:44] <Laney> can we delete it?
[09:45] <geser> sure but better get an ACK from a REVU admin
[09:45] <Laney> well they'll need to do it anyways
[09:45] <Laney> as the team owner
[09:46] <Laney> RainCT ajmitch siretart: ^^^ (should ~revu-uploaders be deleted?)
[09:50] <hrw> geser: I am ignoring it but it took me 1h to find out why I got emails from launchpad abouting rejecting adding group XY to group ZD.
[09:51] <hrw> geser: when I was never added directly either to XY or ZD one.
[09:52] <AnAnt> Hello
[09:52] <AnAnt> Laney: congrats !
[09:57] <hrw> btw - can someone tell me did I got my PPU permissions or should I just check with dput?
[09:58] <Laney> use the edit_acl.py line I gave you before
[09:58] <hrw> Laney: it gives me python backtrace only
[09:58] <Laney> doesn't look like it was applied
[09:59] <Laney> you can poke someone on the TB to do it
[09:59] <hrw> TB?
[09:59] <Laney> tech board
[09:59] <hrw> ok
[10:00] <hrw> thx
[10:05] <sladen> hrw: PPA?
[10:06] <geser> sladen: PPU = Per-Package Upload rights != PPA
[10:23] <nigelb> Laney: hi
[10:23] <nigelb> The other day when I was fixing the FTBFS, I used the packaging guide.
[10:23] <nigelb> I was inside the UDD thing, and I couldn't see the other options
[10:24] <nigelb> The confusing bit was getting to see the main item before and after the item I was in.
[10:24] <nigelb> I'd rather have the entire TOC on the left sidebar
[10:26] <Laney> that would quickly get huge
[10:26] <Laney> unless it collapsed the other sections or something
[10:27] <Laney> anyway I think we use whatever sphinx gives us for this — maybe you could see if it's possible to change it?
[10:27] <nigelb> yeah, I'm looking to see if I can have collapsed list of the TOC
[10:28] <nigelb> Its not immediately apparent that the "Table of Contents" is clickable.  This is despite the fact that I use sphinx a lot.
[10:28] <nigelb> Also, I'm thinking of having an activity to get all the FTBFS that are due to the as-need change, list them somewhere and blog about how they need fixing and folks interested can pop in here and ask for help.
[10:29] <nigelb> This involves going through all the build logs, so I'd take some time to build that list :)
[10:29] <Laney> sounds good
[10:29] <Laney> you might be able to grep them a bit
[10:31] <nigelb> ah, that might help.  My idea was to open all the build logs from the ftbfs page and look at their reason for failure
[10:35] <Laney> I imagine downloading them can be scripted :-)
[10:37] <nigelb> I believe, yes. I'll take a look when I get home. If I'm stuck I guess I can ask for help :)
[11:27] <geser> nigelb: http://qa.ubuntuwire.com/ftbfs/oneiric.csv might help you a little bit with this task, it contains one line for each package and failure type
[11:28] <geser> as the linking error will affect all architectures looking into one logfile per package should be enough
[11:29] <nigelb> geser: woah, yes! I could just filter out all the build failures that fails on archs and then pick up the i386 logs and compile the list :D
[11:29] <siretart> Laney: I think RainCT should answer this. I think so, but I haven't looked at REVU implementation for quite some time now
[11:29] <nigelb> *on all archs
[11:33] <geser> nigelb: that file was meant as a source for "harvest" but I don't know if it ever was used
[11:34] <nigelb> geser: ah!
[11:35] <nigelb> geser: I was looking forward to a night of reading BeautifulSoup, this makes it simpler :)
[15:11] <RainCT> Laney, siretart: Yeah, ~revu-uploaders isn't used for anything. I'm fine with removing it.
[15:15] <Laney> RainCT: cool, (one of) you will have to do it then ;-)
[15:27] <RainCT> Laney: done
[15:27] <Laney> nice
[15:27] <Laney> cheers
[15:27]  * Laney enjoys cruft busting
[15:30] <iulian> Of course you do. :)
[15:30]  * Laney fluffles iulian 
[15:31]  * Laney looks at haskell-pkg-graph.pdf
[15:31]  * DktrKranz looks at it too
[15:31] <Laney> so close!
[15:31] <DktrKranz> \o/
[17:47] <micahg> Laney: bdrung_ : instead of dropping syncpackage, can we rename it to fakesync?  it's very useful for that still
[17:49] <Laney> when sync-in-soyuz comes it can just DTRT automatically
[17:49] <micahg> Laney: even for fakesync?  cool
[17:49] <Laney> doesn't it already detect that?
[17:50] <micahg> bdrung_: I test built eclipse 3.6 on amd64  yesterday, can I sync it over from experimental
[17:50] <micahg> Laney: synchelper doesn't allow it ATM, so they have to be done manually still, idk about sync-in-souyz
[17:51] <Laney> I thought syncpackage did detect it, hmm
[17:51] <micahg> Laney: no, it does, that's why I suggested the rename :)
[17:52] <Laney> ah
[17:52] <Laney> basically I think that it's not worth removing/renaming only to resurrect in the near future when sync-in-soyuz lands
[17:54] <micahg> k, I didn't know that "feature" will be there as well
[17:55] <Laney> makes sense to provide the same interface
[17:56] <ScottK> If you've seen the LP blog post that mentioned 'derived distributions', that's the thing that will have the magic sync button.
[17:58] <Laney> yep, all signs indicate it is close
[17:59] <cjwatson> Laney: I don't think sync-in-soyuz will replace fakesync
[18:00] <cjwatson> but it's true, having syncpackage do the API thing for sync-in-soyuz rather than having to go through the website would be a useful thing to do
[18:00] <Laney> cjwatson: no I wasn't saying that — just that the 'syncpackage' tool will be able to detect what to do
[18:00] <cjwatson> agreed
[18:00] <Laney> one interface for (fake)syncing
[18:01] <cjwatson> since the LP UI for it will (from what I've seen) be oriented around synchronising one distribution with another, more than around individual source packages
[18:01] <cjwatson> I'd rather recommend that developers use the API for it, and then we can provide tools that advise on Ubuntu policy
[18:01] <cjwatson> the LP UI will be more generic
[18:01] <cjwatson> (so I think I'm agreeing with you, just verbosely)
[18:03] <Laney> I wasn't thinking about the Launchpad UI at all (as I have no idea what that will be beyond what you've said)
[18:04] <Laney> but it sounds like only a small part of this work is about 'syncing' as we know it
[18:05] <Laney> ...lost my thread on this haskell update
[18:05]  * Laney scrabbles around a bit
[18:08] <cjwatson> I don't think it's secret or anything, but I don't have a screenshot
[18:08] <cjwatson> you might be able to find it on staging.launchpad.net
[18:09] <cjwatson> sorry, I mean dogfood
[18:09] <cjwatson> https://dogfood.launchpad.net/ubuntu/oneiric/+localpackagediffs
[18:10] <cjwatson> usual disclaimers on use of dogfood.lp.net apply though, and I seriously doubt changes there go anywhere near the production database :)
[18:10] <cjwatson> I gave bigjools lots of feedback at UDS; I don't know how much of it has been implemented
[19:22] <evaluate> micahg, ping?
[19:23] <micahg> evaluate: pong, I haven't forgotten about you :)
[19:23] <evaluate> ok, wasn't sure if you've seen my previous message.
[19:23] <micahg> evaluate: which one?
[19:24] <evaluate> I was wondering because I've noticed that 1.4.0 has been merge to oneiric, but the patch hasn't been applied to natty, or does that just need a bit more time?
[19:24] <micahg> evaluate: no, that's just waiting for me to upload which I'll do this week
[19:24] <evaluate> ohh, ok. That was all, thank you! :-)
[19:26] <micahg> evaluate: you're welcome, should be uploaded by wed at the latest
[19:27] <evaluate> No hurry here, like I said I was just wondering and thought you may have forgotten about the natty SRU after upgrading oneiric.
[20:17] <c_korn> can I simulate dpkg -i somehow?
[20:18] <evaluate> Define simulate...
[20:19] <jtaylor> c_korn: if you want to keep your system clean use a chroot
[20:19] <c_korn> no, like apt-get -s install. I only want to see whether installation would fail or not
[20:19] <paultag> c_korn: --dry-run
[20:19] <paultag> or --simulate
[20:19] <paultag> c_korn: check the man page, type "/simulate"
[20:19] <c_korn> I already use a chroot but thanks for the tip
[20:19] <paultag> c_korn: it's the first hit
[20:20] <c_korn> oh, my bad. thanks.
[20:20] <paultag> c_korn: no problem. good luck
[20:21] <evaluate> paultag, hi :-)
[20:21]  * paultag waves to evaluate 
[21:14] <highvoltage> that sounds so meta
[21:14] <ajmitch> highvoltage: hm?
[21:14] <paultag> highvoltage: hehehehe
[21:14] <highvoltage> (paultage waving to evaluate)
[21:15] <paultag> highvoltage: How's things?
[21:16] <highvoltage> paultag: good and you?
[21:16] <paultag> highvoltage: not too shabby. Just moving home and stuff. Finally "settled", but my development machine is still offline :(
[21:17] <paultag> so just hacking on the netbook while I figure out what to make a table out of
[21:17] <paultag> I'm wicked in-and-out
[21:18] <highvoltage> where did you move to?
[21:19] <paultag> highvoltage: back home, from Ohio. I have one photo up on my fb if you want to check out the view
[22:47] <Laney> bdrung_: can uupdate use (or get its own version of) DEBCHANGE_DISTRIBUTOR?
[22:47] <Laney> it's a bit annoying to get 0ubuntu1
[22:48]  * Laney hassles the new devscripts comaintainer :-)
[22:50] <bdrung_> Laney: i think we should standardize it somehow. maybe DEB_VENDOR which can be overridden by --vendor=X or --debian or --ubuntu (same for dch)
[22:51] <Laney> that would be better indeed
[22:51] <bdrung_> Laney: the next item on my devscripts todo list is to merge the debchange changes in a sane way and make it usable for both targets
[22:52] <bdrung_> Laney: the problem with debchange is that all short parameter are already taken (-d, -u)
[22:57] <Laney> --distributor works fine for me now, not so fussed about a short name; I'd rather have a way to turn off all of the ubuntu specifics
[22:57] <stgraber> bdrung_: I'm sure there's plenty of utf-8 chars that haven't been used yet ;)
[22:57] <Laney> yes!
[22:57] <Laney> dch -☹
[22:59] <stgraber> -★ ? :)
[22:59] <bdrung_> stgraber: ansi is preferred.
[22:59] <bdrung_> how about -\n or --
[23:00] <stgraber> \0 ?
[23:00] <bdrung_> -\0 for Debian and -\1 for Ubuntu :D
[23:00] <stgraber> yeah1
[23:00] <stgraber> !
[23:01] <paultag> dch -♥
[23:01] <bdrung_> paultag: impossible. some will say that this maps to --debian, but other to --ubuntu ;)
[23:01] <stgraber> that's for --force right ? :)
[23:02] <paultag> bdrung_: :)
[23:02] <Laney> that's for --nmu
[23:02] <paultag> Oh jeez. `dch -→'
[23:03] <stgraber> doh, why is it always Debian who gets the fancy utf-8 options? (we'll have to introduce the concept of maintainers and NMU to Ubuntu then ...) :)
[23:03] <paultag> I'm pretty sure ♥, → are both ASCII :)
[23:03] <cjwatson> dch -– (look closely ...)
[23:03] <paultag> cjwatson: that's a goodun :)
[23:03] <paultag> thank the FSM for monospace fonts :)