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