[05:54] Hello everybody, [05:54] Any one knows how to get some code from git repo, then send it to bzr branch [05:57] ashams: bzr branch git://wherever.the.git/is ; bzr push lp:wherever/you/want ? [05:57] RAOF: that easy?, thank you :) [05:58] ashams: What exactly do you want to achieve here? [05:58] You'll need bzr-git installed for that to work, but that's a quick apt-get away if you don't already have it. [05:58] I want to help with X org team [05:58] there's a lot of things to get from freedesktop [05:59] repos [05:59] to lp [05:59] Ah. Most of those should already be mirrored. [05:59] But LP can do that sort of thing automatically. [06:00] And we don't generally use Launchpad for hosting the X stuff; we use git.debian.org :) [06:00] wow, I've missed a lot :( [06:00] great, so no need for this now === almaisan-away is now known as al-maisan [06:01] Greatings :) [06:02] wgrant, RAOF, Thank you === al-maisan is now known as almaisan-away [06:40] good morning [06:51] mornin [06:55] bdrung: ping [07:19] * micahg fishes for an awake DMB member other than himself... [08:02] bdrung: unping === jamespag` is now known as jamespage === almaisan-away is now known as al-maisan [09:52] hi, anyone knows if we can sync from unstable from launchpad? (I mean, here: https://launchpad.net/ubuntu/precise/+localpackagediffs) [09:53] gaspa: Not at the moment, unfortunately. The multi-parent support isn't quite finished enough yet. [09:53] wgrant: k, thanks :) [09:54] use syncpackage for that [09:55] gaspa: the LP web interface doesn't check things like sync blacklists or for ubuntu deltas that may be overwritten, so one should always use syncpackage [09:55] uh, pity, I found it very attractive :D [10:46] http://paste.debian.net/137307/ ← here's my current lp-udd script, which ~works. I get EPIPE at line 136 though with py2.6 but not py2.7… why? :( [10:58] Laney: maybe because you are trying to write to a /dev/null that was opened for reading? [11:01] A new, easier, procedure involving the Backports Tester Team PPA is in the works. Stay tuned for info. [11:01] That's from the UbuntuBackports wiki page - anything done along that lines already? [11:03] And when I do a test build, should I mark the backport bug as confirmed already myself, or is that only up to someone from the backports team? [11:04] What's the proper versioning for a backport again? :) [11:06] Rhonda: backportpackage takes care of the versioning. AFAIK there is a PPA, andI can't remember the procedures.... /me waits for a backporter Laney? broder? [11:07] for i in lucid natty maverick; do sudo nice ionice -c3 cowbuilder --update --basepath /var/cache/pbuilder/cow/$i; sudo nice ionice -c3 cowbuilder --build --basepath /var/cache/pbuilder/cow/$i --pkgname-logfile tmux_1.5-1~$i~ppa1.dsc; dcmd mv /var/cache/pbuilder/result/tmux_1.5-1~$i~ppa1_i386.* .; done [11:08] * Rhonda hides for doing long commandline foo. :) [11:08] tumbleweed: I think only the backporters are allowed to upload to the backports PPA, it's only described under Source Change Backports anyway. [11:09] Rhonda: well yes, you need to be in the team to upload to the PPA [11:46] Rhonda: the packages need source changes? [11:47] append ~release1 [11:47] tumbleweed: no, it even happens if I don't redirect stderr [11:48] Laney: Nope, they don't. [11:49] I appended ~natty1~ppa1 for the time being. [11:49] … see my "oneliner" ;) [11:49] ok, well someone (can be the requester) needs to confirm it builds/installs/runs as well as any rdeps [11:50] of which there don't appear to be any [11:51] doh, error in there, not ~$i~ppa1 but ~${i}1~ppa1 :) === al-maisan is now known as almaisan-away [12:12] Laney: http://bugs.python.org/issue10963 ? [12:13] hmm === almaisan-away is now known as al-maisan [12:52] is there a workaround for that? [13:04] Laney: looks like catching the OSError would be a workaround [13:04] yeah I tried that, but parsed_changelog is unset [13:06] is there some fancy streaming to incrementally set it? [13:07] * Laney flails around [13:09] oh, it wasn't that it failed, just *really* short lived [13:09] run command; cat? :) [13:10] tumbleweed / Laney - Either of you got a chance to propose a session about challenges? [13:10] I won't be there or I'd have proposed one [13:10] Laney: Yeah. Use Python 2.7. [13:11] nigelb: challenges? [13:11] soren: I don't admin the box it will run on [13:11] tumbleweed: The dev challenges which we tried to do this cycle but failed [13:11] nigelb: not if it's this week [13:11] the box it will run on presumably runs squeeze [13:12] I'm assuming he's talking about UDS [13:12] oh [13:12] Yeah, I'm talking about UDS :) [13:12] not the open week? [13:12] No :P [13:12] dunno, I can be there [13:12] (sorry, I should've been clearer) [13:12] we should have one about recruitment [13:12] * tumbleweed can too, but I can't really drive any challanges next cycle. I'm spread too thin as it is [13:13] quite [13:13] so we need to do a session about recruiting to recruit people to do recuriting? [13:13] So meta. [13:13] like how do we make motu less dead [13:14] challenges are well and good but there needs to be people to do them [13:14] we definitly need a session on that [13:14] but I don't know what we'll get out of it... [13:14] :( [13:14] we need more new blood to handle it. [13:14] I'm spread thin as well. [13:15] the QA session at debconf was also pretty sad, lots of "so this 1 persion is doing foo, who can help him/her", and nobody responds. Repeat 10 times [13:15] :( [13:15] Are we losing too many people to burn out? [13:16] I don't know. This is partly why I did http://people.ubuntu.com/~stefanor/upload_activity/ this weekend. Which showed more activity in universe than I expected [13:17] Neat. [13:17] what are the spikes? [13:17] probably pre-freeze ;) [13:17] or post freezes [13:17] the y axis is uploads per week [13:17] transition uploads? [13:18] tumbleweed: minus syncs? [13:18] it should exclude syncs. Yes probably transitions [13:18] could be perl at the start of O [13:18] There was a perl thing, a python thing, and an ftbfs thing. [13:18] I wonder if the little activities that were planned had a good effect. [13:18] if anyone knows a good way to exclude canonical, that would be interesting [13:19] excluding cjwatson and doko would get us 50% there, though :P [13:19] lol [13:19] is there an lp team? [13:19] No [13:19] you'd have to manually pick people out. [13:19] there is a ~canonical LP team, but it's private [13:19] (which doesn't help you) [13:19] well, so we can get a canonical person to run the script :D [13:19] well, it's questionable how much value that would have anyway [13:20] Laney: I'm just trying to see how dead MOTU actually is [13:21] just looking at the list would probably be ok [13:21] ha, I just realized I did have 3 uploads to Oneiric. [13:24] (you should probably exclude universe seeded packages if you want to know how dead motu is) [13:24] micahg: pong; unpong ;) [13:25] Laney: next job: import packagesets into udd:) [13:26] heh [13:26] should be easy [13:27] * tumbleweed doesn't even know how to examine packagesets (short of reading edit_acl.py) [13:27] stgraber wrote a script to list them all recently [13:27] ah, that too [13:28] http://bazaar.launchpad.net/~developer-membership-board/+junk/packageset-report/view/head:/make_report.py [13:29] Laney, got lucid and natty test of tmux up and running, maverick still compiling, but I don't expect any issues. Set them both to confirmed already. If you are familiar with tmux, would be great if you could check: bug #876381 (natty) bug #876382 (maverick) bug #876383 (lucid) [13:29] Launchpad bug 876381 in natty-backports "please backport tmux" [Undecided,Confirmed] https://launchpad.net/bugs/876381 [13:29] Launchpad bug 876382 in maverick-backports "please backport tmux" [Undecided,New] https://launchpad.net/bugs/876382 [13:29] Launchpad bug 876383 in lucid-backports "please backport tmux" [Undecided,Confirmed] https://launchpad.net/bugs/876383 [13:29] Rhonda: nice, that's all the confirmation i need [13:30] Laney: do we need something in u-d-t to query packagesets? I found myself running edit_acl a lot during final freeze, to verify that I could sync something [13:30] but we need to backport them in order, so i'll approve natty and then the others when maverick turns out to work [13:31] tumbleweed: maybe, don't know how often listing them is needed per se, rather than "can I upload x?" [13:31] release team requirements are a bit specialised [13:31] maybe make syncpackage list the packagesets as well as the changelog? [13:32] "is this seeded?" is the more important question? [13:32] yeah. But that's harder to determine... [13:33] mmm [13:34] the sponsors page also equates packagesets with seeds [13:35] "can I upload this?" is a sensible question something in u-d-t should be able to answer [13:35] pretty sure it can [13:35] possibly followed by "who can upload this?" [13:36] in freezes, there's also "I can upload this, but is it safe?" [13:36] true [13:40] I suppose listing (component, sets, seeded?) would be nice [13:41] * tumbleweed files a wishlist bug before he forgets [13:42] can you query LP to see if the archive is frozen? [13:43] looks like distro_series.status can tell us that [13:44] could use that to enable some extra fear [13:44] like a small electric shock [13:44] lol [13:46] tumbleweed: should we wait six days for the distro-info 0.3 migration to testing? [13:47] * cjwatson pro-forma objects again to exposing the "seeded" concept anywhere that humans might be expected to understand it [13:47] but we already do expect people to understand it for freezes? [13:48] or do you think /that/ is a mistake? [13:48] yes, I do [13:48] it's a hopelessly ambiguous term [13:49] (a) actually listed in seed files (b) contained in the dependency-expansion of seeds (c) on some CD images (d) in some package sets ... [13:49] we should say whatever we actually mean [13:51] yes, I agree it needs defining. writing this code could actually prompt that... [13:51] cjwatson: the most useful thing for freezes is "on some CD images", is there any reasonable way to query that? [13:52] bdrung: yeah, I'm thinking we do a minimal SRU now, and copy-it-up. Then do the sync-from-testing-for-LTSs change when distro-info is available [13:52] tumbleweed: copy-it-up? [13:53] get the SRU copied from oneiric-updates to precise [13:53] proposed [13:54] yeah, that [13:54] :-) [13:58] tumbleweed: in practice it's probably best to grep the .list/.manifest files [13:58] which is unfortunately not especially reasonable, but ... [13:58] precise already has a newer distro-info than oneiric [13:58] that sounds out of the question for something we do regularly, but the way to go for a can-i-upload-this-during-freeze tool [13:58] including the packaging reorganisation [13:58] I doubt that a copy-up from oneiric-updates would work [13:59] ah, copy-up of u-d-t, not distro-info. The change I want from there for the long term solution is only in git [13:59] ah, ok [13:59] sorry [13:59] np, thanks for checking :) === al-maisan is now known as almaisan-away [15:14] this as-needed change is really screwing users ._. [15:14] all their crappy apps don't compile anymore ^^ [15:15] * tumbleweed sees that as a good thing :P [15:15] almost a dozen threads in the ubuntu forums already and its not even a week released [15:15] anyone can drive me a bit on a backport? (seems strange but I never did one) [15:15] I'm after #858361, it is a no-source-change. may I upload by myself or should I subscribe some -backporter? [15:15] well gcc is a bit unfriendly in that respect, its counterintiutive to ahve stuff depend on ordering on command line [15:15] I don't really get why gcc can't do reordering itself by default [15:16] gaspa: file a bug against $release-backports. Build it with backportpackge yourself, and test it. Report on the results in the bug [15:16] then poke backporters here [15:16] and all rdepends [15:16] and no need to poke, i'm keeping up with it [15:16] (so far) [15:16] * tumbleweed is impressed :P [15:17] Laney, tumbleweed: so we should not upload by ourselves, I guess. right? [15:17] no [15:18] uh, it's already in. [15:19] that's happy [15:20] ok, so it's all done. [15:20] * gaspa bows [15:30] jtaylor: the problem is that gcc in the past the ordering could be ignored (by developers) as all libs got linked in (even the unused by the application) so all the symbols from the libs were available [15:30] yes I understand why as-needed is good [15:31] its just not really apparent why gcc can't just scan all files for needed symbols and then for libraries providing them, no matter what order they are [15:32] kind of what --start-group --end-group does === med_out is now known as medberry [15:32] is performance really an issue nowadays? [15:36] I guess this question is better asked the gcc/ld gurus [15:37] gaspa: you should use the new syncpackage (using LP API) for syncs [15:39] are autosyncs already running? [15:39] yep [15:39] nice [15:40] time to sync all as-needed fixes that are in debian now, too bad I did not keep proper track of them ._. [15:40] usertagged though? [15:41] yes [15:41] doable then [15:41] jtaylor: the next time you will :) [15:41] yes but it would ahve been easier if I noted for each branch I made when it was fixed in debian :/ [15:47] is the branch status selector in the personal code section on lp broken? [15:49] "personal code section" ? [15:49] * tumbleweed made a rough first pass at affiliation, for everyone doing > 100 uploads in 'select count(*) as count, signed_by from ubuntu_upload_history group by signed_by order by count;' http://people.ubuntu.com/~stefanor/upload_activity/ [15:50] of course, canonical hires community developers, which skews the numbers... [15:51] the black lines are release dates and the red ones FF? [15:51] Laney: ack. next time :P [15:51] gaspa: yeah [15:52] err geser [15:53] err, that'll also be skewed by patch pilots [15:53] I was looking at signed by, not changed by [15:53] hmm, was oneiric so good that it didn't need many uploads since a couple of weeks before FF? [15:53] oneiric was really quiet near the end [15:53] in the previous release the amount of uploads was pretty constant even after FF [15:54] * tumbleweed probably granted less than 10 FFes [15:56] it'd be interesting to see the distribution of uploads [15:56] on an individual level [15:56] run the query I just pasted [15:56] in a nice graph :P [15:56] * micahg didn't ask for as many this cycle :) [15:56] * Laney ties a bow around micahg [15:57] * micahg didn't sign up for the dog and pony show... [15:58] tumbleweed> "personal code section" ? < the code tab in your profile [15:58] * micahg hopes to do a lot of uploads at the end of precise to clean up stuff (had no time for oneiric) [15:58] I can't see any but those with active status :/ [15:58] jtaylor: aah, does branch status make sense for personal UDD branches? [15:59] yes merged and active [15:59] I set them all to merged when I'm done so they don't clutter the list [16:00] * Laney is in the list twice [16:00] (using changed_by) [16:00] with the side effect that I know can't reach any of them ._. [16:01] worked yesterday [16:01] should probably file a bug [16:01] jtaylor: oh, I thought you were talking about the thing in the bzr client that telss you if a UDD branch is up to date [16:02] Laney: you can get around e-mail address variance with changed_by_name [16:02] yep [16:03] haskell transitions: good for karma [16:03] heh [16:04] ah its filed already :) bug 876533 [16:04] Launchpad bug 876533 in Launchpad itself "changing the values in Comboboxes on my code page does not update the branch-list shown" [Critical,Triaged] https://launchpad.net/bugs/876533 [16:04] if someone helps me (with a patch ...) to fix the problem I talked about ^ then I'll roll out the new importer ASAP [16:05] if DSA don't mind installing lplib that is [16:06] Laney: lucas has root on it, IIRC [16:06] * Laney knows not how it works [16:07] i emailed d-admin last time [16:07] ah, I did that too, and my request was never installed :) [16:07] tumbleweed: are you sure you are talking about the same UDD? [16:07] samosa [16:07] ah, ok [16:08] I don't have root, you need to go through DSA [16:08] ah, sorry, misremembered [16:08] that is what i thought, np [16:09] \3\\\\\/win 13 [16:09] sorry [16:09] nice! [16:43] Laney: from the look of the patch against python, you can use process.stdout.read() to avoid .communicate() throwing the data on the floor [16:48] can we sync stuff from unstable when the reason for it not being in testing is that it does not build on e.g.hurd? [16:48] e.g. flightgear 2.4 is ~40 days in unstable but not in testing due to hurd [16:49] jtaylor: as long as it has no rdepends, sure :) [16:52] jtaylor: that can't possibly be the reason it isn't in testing; hurd-i386 isn't a Debian release architecture [16:53] hm maybe it needs some kind of hints [16:53] it built on all arches except hurd and has no rc bugs [16:53] neither do its rdeps [16:53] deps [16:55] simgear is marked as not considered, I believe due to simgear2.0.0 still being in the archive and out of date [16:55] which in turn appears to be because fgrun and fgfs-atlas are still built against it [16:55] even if I have multiverse enabled apt-cache policy avidemux says there is no such package. but it should be there: https://launchpad.net/ubuntu/+source/avidemux [16:56] c_korn: failed to build everywhere with new libav and nobody fixed it, so the binaries were removed. bug 831096 [16:56] Launchpad bug 831096 in avidemux (Ubuntu) "avidemux version 1:2.5.4-0ubuntu7 failed to build in oneiric" [High,Triaged] https://launchpad.net/bugs/831096 [16:56] c_korn: it's source only in precise [16:56] hm I'll wait for the maintainers to sort that out [16:57] c_korn: feel free to fix it in precise and SRU it to oneiric [16:59] cjwatson: I see what I can do. [17:08] tumbleweed: how dirty is this? http://paste.debian.net/137409/ :-) [17:08] works ... [17:35] Laney: err why do you need to echo the changelog? [17:35] how about just using .stdout.read instead of .communicate? [19:04] any opinions on bug 873984? I don't know anything about OpenSSL ABI stability... [19:04] Launchpad bug 873984 in proftpd-dfsg (Ubuntu) "mod_tls and mod_sftp complain about OpenSSL version mismatch" [Undecided,Won't fix] https://launchpad.net/bugs/873984 [19:16] tumbleweed: I was wondering about that, it seems weird that it would require a rebuild w/out a soname bump in openssl, but maybe proftpd is doing something it shouldn't or needs a stricter depends [19:30] micahg: I suspect they just don't trust OpenSSL (or users who compile it themselves) [19:39] micahg: I suppose a rebuild doesn't hurt... [19:40] tumbleweed: well, if it's not really needed, maybe that should be fixed, if it is needed, then either proftpd needs stricter depends or libssl needs a soname bump [19:41] my thoughts too [19:41] given the number of things that link to libssl, I'd have thought that its ABI was well understood... [19:41] indeed, although there was a change in 1.0.0e that wreaked havoc [19:43] the SSLv2 drop? [19:45] tumbleweed: no, we did that in natty, I forgot what it was exactly [20:06] \o/ mass sync == mass build failures :) [20:08] the list grows long? [20:08] * ajmitch tries to recall where the graph of FTBFS numbers is [20:10] * tumbleweed is trying to persuade geser to merge it into the FTBFS table [20:11] I really hope to find time to review it soon [20:12] most of the ones I've looked at so far have been gnutls fallout [20:12] * ajmitch should see if there are any merges he can do [20:12] ajmitch: so far, it's flat: http://corelli.tumbleweed.org.za/ubuntu-qa/qa-ftbfs/precise-historical.html. Wait until it runs tonight... [20:13] so all syncs should be filed [20:13] geser: it'll be nice if we can land it before doko kicks off any rebuilds, but besides that, there's no hurry [20:13] nice [20:13] not as many as hopped :/ [20:13] cjwatson: so it's not 300 failures in universe ATM? === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [20:14] micahg: no, I gave back a load, haven't been keeping count [20:15] cjwatson: ok, that's a relief :) [20:15] tumbleweed: how do i pass the changelog in then? [20:15] it needs to go on stdin [20:15] or else i write it to a temp file [20:16] Laney: stdin.write? [20:16] okies [20:16] * Laney somehow missed the python boat [20:17] what are you using that requires it goes on stdin? [20:17] easier than saving to a temporary file isn't it? [20:17] bah, that gets broken pipe again [20:18] yeah, you'll need to catch that [20:18] but you won't lose the output (as far as I can tell) [20:19] whatever you're doing, it looks interesting :) [20:20] i preferred the old way [20:21] aha, works [20:21] * ajmitch wants to look at the whole code for it now, got a branch? [20:21] will you promise not to be mean? [20:21] when am I ever mean? [20:21] and instead make improvements [20:22] it is pretty severely slow [20:22] yeah you said that yesterday, I'm sure I've written worse [20:22] http://paste.debian.net/137499/ [20:25] what specifically do you need from dpkg-parsechangelog output? just the Launchpad-Bugs-Fixed & Closes? [20:25] yep [20:25] distribution is useful but you can reconstruct that [20:25] the commented out bit [20:25] once you are already talking to launchpad, the overhead of shelling out to dpkg-parsechangelog is tiny... [20:25] indeed [20:25] right, it just looks messy [20:25] I'm just checking what python-debian can do [20:25] i think it's probably the duplicate checking [20:44] geser: just realised a potential bug in the historical graph support. diff line 229 deletes data points within the last 12 hours. That won't work if it's cronned more frequently than that. How fast do you usually run it? [20:46] wgrant runs it hourly on qa.ubuntuwire.com [20:47] maybe I should store a date instead of a timestamp [20:47] I think one graph point per day is sufficient [20:48] do you store then the min or max or the last value per day? [20:49] I want all the timestamps for a single run to be the same, so that we can use SQL GROUP BY easily, so I take the current timestamp before we start inserting rows [20:49] I'll take the timestamp of midnight that day instead [20:50] the reason I do the deletion is that I didn't want partial runs in the data [20:51] actually, that's not a danger. I didn't want uneven datapoint frequency when it's occasionally run by hand === yofel_ is now known as yofel === emma_ is now known as emma === emma is now known as EMMA === EMMA is now known as emma [20:54] Rhonda: any news on maverick [20:54] ? [20:55] oh, the script finished === emma is now known as em [20:55] can't be /that/ slow then [20:55] that was quick? [20:55] err [20:55] no, it's not right [20:55] :) [20:55] no precise uploads === Quintasan_ is now known as Quintasan [20:57] * ajmitch is fairly sure that people have been uploading to precise already [20:58] yes [21:30] wow [21:30] I made it even slower? [21:33] Laney: well done? [21:34] give me mboxes or give me death [21:34] https://lists.ubuntu.com/archives/precise-changes.mbox/precise-changes.mbox [21:35] there you go, have fun [21:35] that only works if all the changes that happen make it to the list, of course [21:35] :( [21:35] * cjwatson should probably wait for the world to build a bit better before trying to deal with NBS [21:36] or transitions for that matter [21:36] archive admins plan to be a bit more ruthless with purging packages for the LTS? [21:39] I have some plans to marshal people such that we hopefully won't need to [21:45] Laney: It's on my workplace computer, can tell you tomorrow :) [22:45] guys, how to rename a file during the instalation of a deb? [22:45] the source has it like "abcd.sh" but i want to install it as "abcd" [22:51] r3pek: rename it during the build, after it's been installed to debian/packagename/usr/bin/abcd.sh [22:51] so i have to put that path? the full path? starting with debina/ ? [22:52] dh_install can do it too [22:52] dh_install doesn't do renames afaik [22:52] no, it can't rename [22:52] r3pek: well, that's where it gets installed to, so yes [22:53] ok... i just didn't knew the correct path so my "mv"s were failling :) [22:54] hummm :/ [22:54] still errored out :( [22:55] that's when you go and see what it did and why it didn't work [22:56] that's the easy part :P [22:56] mv: cannot stat `debian/sispmctl/etc/bash_completion.d/gemplug-completion.sh': No such file or directory <--- :) [22:57] so go and see what is there [22:58] i can be doing something wrong on my rules file [22:58] build/sispmctl:: <---- [22:59] ^^ i have that and then the mv [22:59] r3pek: build is too soon [23:00] so when? during install? [23:00] you can't move it until it's there [23:01] IIRC the cdbs manual gives a good description of the hook points [23:01] hummm ok. one mor try :) [23:01] * cdbs has a manual? [23:01] :) [23:02] cdbs: you're still using that nick? :P [23:02] ajmitch: I really want to switch over, after a long legal (lol) battle I managed to win over the nick "bilal" [23:02] feeling lazy to make another move [23:03] since, I was "bilalakhtar" earlier, and since "bilal" was occupied I moved to "cdbs" [23:03] just use /nick :) [23:03] ajmitch: Its not that easy, you need to tell everyone to call you by this nick [23:03] they'll manage [23:04] better than you getting highlights from people ranting about how cdbs sucks :) [23:04] that's actually okay [23:04] it gives me a chance to kick into the discussion [23:04] heh [23:04] and then tell people to move to dh [23:04] since /me hates cdbs [23:04] lol [23:05] with that, I think I shall find lunch :) [23:05] bye ajmitch [23:05] * tumbleweed gets hilighted when people notice channels are dead. Not sure which is more interesting :P [23:06] i still don't reallu understand the debian packaging system :) [23:06] from a user pov, it's cool. for a dev pov, looks a nightmare so far :X [23:07] r3pek: it's actually pretty simple, but people have written some rather complex tools to automate most of it, and learning the tools and all their oddities ends up being the nightmare [23:08] Also, cdbs *is* unnecessarily arcane. [23:10] r3pek: http://cdbs-doc.duckcorp.org/en/cdbs-doc.xhtml#id465030 you'll notice that the hook you want is probably install/package [23:11] tumbleweed, yes, it's working on install :) [23:12] RAOF, i'm just upgrading a package. and trying to learn the package system along the way... [23:12] but i'm not even aware what i'm using... cdbs or any other thing :X [23:16] [PPA r3pek-sispmctl] [ubuntu/oneiric] sispmctl 3.0-nmu2 (Accepted) [23:16] ^^ #win :) [23:52]