[00:59] bdrung: tided up, rebased, and fixed that issue [00:59] tumbleweed: too late [01:01] tumbleweed: http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git [01:01] http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commitdiff;h=ea7efb510344868dced804baa9b21aae5ed6b3a8 [01:02] gaah, just wasted an hour then [01:03] tumbleweed: sorry for that. i incorporated your recommends/suggests stuff [01:03] tumbleweed: we can finally sync devscripts [01:04] \o/ [01:04] and i am currently fixing bug #723715 [01:04] Launchpad bug 723715 in devscripts (Ubuntu) "dch -D doesn't recognize unstable" [Wishlist,New] https://launchpad.net/bugs/723715 [01:23] tumbleweed: please check http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commitdiff;h=4e37799e18b218a3247fdcb4559cf53cc7487e84 [01:24] my perl foo isn't that good [01:28] it looks reasonable [01:29] arguably displaying a warning when using a distribution from a different vendor isn't a terrible idea [01:30] * tumbleweed isn't much of a perl fan either [01:32] tumbleweed: feel free to tune that code [01:33] (and add more tests) [01:46] tumbleweed: i plan to do a devscripts upload soon. anything that should be fixed / go into the next upload? [03:28] bdrung: before you upload devscripts, I think the man page should be updated to reflect the new (more proper on Ubuntu) behaviour of dch -i if that's possible [07:02] good morning [07:07] good morning [07:24] hey geser [07:24] hi geser, dholbach [07:25] Hi ajmitch [07:25] hey ajmitch [07:26] hi ajmitch [07:26] hi micahg [07:26] and dholbach and geser :) [07:26] hey micahg :) [07:26] and Hi micahg [07:26] so many greetings... [07:27] dholbach: I see you've reached the coveted more than 50 items reviewed level: http://reqorts.qa.ubuntu.com/reports/1glance-sponsoring/ [07:27] woo! :) [07:27] impressive [07:27] I'm sure there were a few easy ones I did ;-) [07:27] * micahg used to have above 20, but seems to be slacking [07:29] * ajmitch needs to do some work to get back on that list [07:29] ajmitch: well, you have at least 1 upload this cycle already ;) [07:29] micahg: I need to do a bit more than that [07:31] ajmitch: top uploader list for quantal bottom spot is 10 uploads ATM [07:32] Morning. [07:32] hi iulian [07:33] How's it going, ajmitch? [07:33] good, just waiting for dinner to cook :) [07:33] hi iulian, I guess I'm joining you on the regular membership board [07:33] micahg: oh yes, forgot to congratulate you on your sentence ;) [07:34] ajmitch: heh, somehow I got signed up for the 12:00 slot [07:34] micahg: Congrats. [07:34] * micahg guesses the CC couldn't tell what timezone I work from either [07:34] micahg, I'm sure there's a way to get that changed :) [07:35] dholbach: heh, it's ok, I can wake up early once a month (already do for the DMB) [07:36] micahg: this is why I was dubious of putting my name forward - both times didn't really suit well [07:36] not so much of a problem for someone who doesn't sleep [07:38] micahg: What timezone do you live in? [07:38] UTC-5/-6 [07:38] wrong question to ask [07:38] Err, how lazy you are in the mornings? [07:38] Better ajmitch? :) [07:39] more like "at what hour of the morning do you go to sleep?" [07:39] since he seems to be on irc rather late [07:39] Oh, I see. [07:41] so, it varies :) [09:02] micahg: do you have a suggestion (patch) how the man page should be changed? [09:04] bdrung: a third line saying something like "On Ubuntu, this will also change the suffix from buildX to ubuntuX. Use -R, --rebuild for a no change rebuild increment. [09:05] s/a third line/insert at the third line/ [09:08] tumbleweed, done [09:09] micahg: "third line" is a bit unspecific, because the formatting is not fixed [09:10] before 'This creates a new section at the beginning' [11:09] micahg: thanks and pushed. anything else that should be documented? [13:53] hey === sagaci_ is now known as sagaci === tumbleweed_ is now known as tumbleweed === dutchie_ is now known as dutchie [15:11] I need to upload an SRU change for 12.04 that has the same package version as the latest package in quantal -- should I add ~precise to the SRU package version? === ScottK2 is now known as ScottK [17:35] bregma: no, fix it in quantal first and then use the usual SRU versioning [17:42] what could be the reason kmod is missing in quantal? its not blacklisted and not in the new queue (if I looked at the right queue) [17:45] good question. what happens when you try to sync it? [17:47] didn't try that [17:47] shouldn't that be automatic? [17:51] I'm not sure if it's already included in the daily(?) auto-sync [17:51] and I've no idea why it didn't got synced in the last manual run either [18:54] bdrung: if I run into anything else, I'll let you know, that change (-i behaviour) might be a shocker for some, so I figured it worth documenting [19:00] perhaps also add a NEWS entry? [19:01] hrm, does Debian have -R or is it Ubuntu specific? [19:03] debian doesn't need it, rebuilds should go over the release team [19:03] micahg: it's more ubuntu specific [19:03] right, so, technically, anyone using -i for a rebuild is not doing it right anyways [19:04] sorry, not awake yet, leading me to saying that it's not worth a NEWS entry if people are doing it wrong [19:06] -i is used for arch all rebuilds, but -release should know about it [19:07] jtaylor: well, if regular devs aren't doing rebuilds, that's a very small subset anyways [19:10] jtaylor: sync-source New is a separate process than the regular syncs and is run less often. [19:10] I though so, but there was a new sync a few days back, maybe it was just not done in that run [19:12] shouldn't it be in the new queue then? [19:13] ScottK: is it still true? I remember cjwatson wanting to merge it into the normal auto-sync but I don't know if it already happened or not [19:13] I'm not sure. [19:14] and even the previous version was long enough in testing to get picked up by one of the new syncs, so I've no idea why it didn't get synced till now [19:16] jtaylor: ah, the reason is probably that we have already a binary package "module-init-tools" (build from module-init-tools) and syncing kmod need investigation [19:17] yes it is my understanding kmod is supposed to replace that [19:17] and also checking which of our module-init-tools delta needs to get adopted to kmod [19:21] what I actually want to know if its some queue or blacklisted on an unknown list [19:21] we need to sync or merge dntools to not pull in dnet into quantal [19:21] kmod (source package) builds now module-init-tools (transitional package) and as that would "conflict" with the current one (two source packages build the same binary package => the highest version wins and upload of the other will fail after build), so it needs investigation if syncing the package is the right thing and the new sync script aborts on those [19:21] which needs kmod [19:23] not sure, who can answer the question what is planed about this package, perhaps ask the ubuntu-release team === jalcine is now known as Jacky [19:41] ScottK,geser: new packages are now synced as part of normal auto-syncing, unless there's something that requires manual resolution [19:42] jtaylor: kmod overwrites a module-init-tools binary with Ubuntu changes - it requires somebody to merge the m-i-t changes into kmod [19:43] it's not on a manual blacklist, auto-sync detects the situation [19:43] slangasek said he was going to have a look at kmod [19:44] cjwatson: thx, I'll wait with dntools a bit longer then [19:44] yes, there are bits to port [19:46] anyway the headline is that new syncs are no longer artificially delayed vs updated syncs, which is yay [19:46] \o/ [19:50] things which can delay new packages: building a binary which already has an Ubuntu version string; having had previous publication records in Ubuntu [19:51] or of course being manually blacklisted === liquid is now known as Guest38268