[02:25] *sigh* who writes these depressingly wrong reviews in the Ubuntu Software Centre :( [02:25] In the past I had admired the ones we had for prior versions of Ubuntu... [02:25] http://m8y.org/hw/ubuntu.png [02:26] Well written, nice appreciation of the game, detailed [02:26] Sooo, I go to Ubuntu 12.04 [02:26] And I get Brendon King saying that you should install and run it under Windows instead because it is a little more stable [02:26] Sooooooo totally wrong! [02:26] We have way more problems with our Windows users [02:26] Qt problems, OpenGL problems [02:27] It was only recently that we even managed to get fullscreen to *work* in windows [02:27] and we still have IFDEFs to work around issues [02:27] * nemo sighs [02:27] well, $users :) [02:27] lifeless: so it *is* users? It isn't microsoft astroturfing spreading to top entries in your software centre? [02:28] lifeless: I wonder 'cause there's been increasing Microsoft astroturning on /. [02:28] Admittedly the SNR on /. is not great, but the astroturfing for major companies is kind of obvious. Long posts that appear the instant an article goes up [02:29] eh. guess I'm being paranoid. still. sad. hopefully quality of the reviews improves over time. I guess 12.04 has only been out for a month [02:34] I think there is a voting system :) [02:44] lifeless: what I really want is a way to e-mail him to talk some sense [02:45] but unfortunately google wasn't forthcoming :) [02:46] lifeless: hm. something else I just noticed. total size on disc is totally wrong too [02:47] looks like it isn't including hedgewars-data [02:47] weird I thought it was correct before [02:49] 8.5MiB instead of closer to... 150MiB I guess - the ogg files really take up space [02:50] $ du -hs /usr/share/games/hedgewars/ [02:50] 122M /usr/share/games/hedgewars/ [02:50] aaand 8.0M/usr/lib/hedgewars/ [02:50] ok. just 130MiB - still :) [02:54] Base-2 unit prefixes aren’t very useful for us humans. :-P [03:07] ion: eh? is all relative anyway. and 2^10 ~ 10^3 [03:08] anyway. nowhere near 8½MiB :-p [04:34] Good morning [04:39] you're late this morning ;p [04:39] hehe [04:39] doko: are you still in Taipei, or also up early? [04:40] pitti, no Hongkong now [04:40] ah [04:40] doko: time for a quick python question? [04:40] sure [04:41] doko: has it ever been discussed to provide a python version with --enable-valgrind? [04:42] doko: e. g. could we at least build -dbg with it, if the runtime check is considered unnecessary overhead? [04:43] without it, it's practically impossible to use valgrind to debug leaks in your extension, as python itself throws hundreds of those due to its own allocator [04:43] pitti, afaik, no. sure, that sounds doable. otoh, I would like to know how much it slows down the execution [04:43] doko: I'm perfectly fine with only building -dbg with it [04:44] doko: it incurs an extra check if the program is running under valgrind (not much, but might cost a few thousand cycles), and an extra "if" check on a boolean for every object allocation [04:45] doko: do you know a standardized test for this? if not, I could just run the pygobject test suite with the two builds and compare the times [04:45] doko: so if that hasn't been discussed, I guess I'll open a bug and do some performance comparison; would you prefer a Debian or LP bug? [04:46] pitti, let's do LP first. won't be for the next debian release anyway [04:46] no? ok [04:48] doko: danke [05:39] Guten Morgen - Good morning :-) === smb` is now known as smb [07:06] good morning [07:07] ev: hey, good morning! is there a way for errors.ubuntu.com to show me only report for the "last-seen" version? the top bug there should be fixed with 5.2.2.1 and I would love to see a stacktrace from the 5.2.2.1 version (if its really not fixed there) [07:07] hey dholbach, good morning! [07:08] hey mvo [07:12] mvo: getting a stacktrace for a binary program for a specific version is impossible right now. We only ask for one per stacktrace address signature. However, it's definitely something to look at in the future. [07:12] mvo: I could make it so clicking on the "last seen" version takes you to a report for that version. mpt, what do you think? [07:12] mvo: we chatted about 5.2.2.1 last night. In precise, we still get reports from users where the running binary does not match the installed version (they upgraded while running). This is fixed in quantal (thanks pitti!) and being backported to precise. [07:12] I'm preparing the SRU right now [07:13] ev: oh, awsome [07:13] unfortunately someone else than me still needs to verify bug 989698, to unblock precise-proposed for apport [07:13] Launchpad bug 989698 in apport (Ubuntu Precise) "Data collection progress window is still appearing post-release" [High,Fix committed] https://launchpad.net/bugs/989698 [07:13] ev: yeah, it would rock to be able to click on the latest ver and get taken to the stracktrace [07:13] ev: and thanks pitti for this fix, that is a relief :) [07:13] * mvo was a bit worried about a overlooked case in this fix [07:14] mvo: actually, the fix only applies to signal crashes, not to Python stack traces -- is that a signal crash? [07:14] its a python stack trace [07:14] oh -- I'm afraid that's not fixed yet then [07:15] * mvo nods [07:15] just curious that people keep s-c open for such a long time [07:16] this fix was actually aimed at things like gnome-settings-daemon, which run all the time [07:16] and you might still have a 30 day old process running after upgrading twice in between [07:16] yeah, indeed [07:17] but for 5.2.2.1 the update is just 17h old, so that would explain why the frequency is still relatively high [07:22] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks [07:26] * dholbach hugs didrocks [07:28] * didrocks hugs dholbach back [07:28] :) [07:32] didrocks should join https://launchpad.net/~dholbach-huggers/+members :p [07:33] dupondje: heh, kind of old good time ;) [07:34] hug mob Prague? [07:36] :-) [07:38] the interweb provides: http://www.youtube.com/watch?v=4jzGIaZcGcM [08:33] micahg, ping [08:37] ev: errors.ubuntu.com is already collecting quantal crashes I assume, right? [08:38] ev: aha, unquestion, just found it I think [08:39] jamespage: hey, FYI, https://code.launchpad.net/~gleichsnerd/ubuntu/precise/mountall/fix-for-805509/+merge/107908 has been resubmitted, I guess you directly want to take it upstream, isn't it? [08:40] * jamespage looks [08:41] didrocks, wrong james - you want jodh :-) but I agree that it should go upstream [08:42] didrocks: actually, no - mountall is a native package. [08:44] Could anybody nominate https://bugs.launchpad.net/ubuntu/+source/shogun/+bug/1006039 for natty ? [08:44] Launchpad bug 1006039 in shogun (Ubuntu) "missing libatlas-dev dependency for libshogun-dev" [Undecided,Fix released] [08:44] that doesn't sound like a good SRU === NCommand1r is now known as NCommander [08:45] HAVE_ATLAS triggers [08:45] Which is in libatlas-dev [08:46] pitti: why? [08:46] that's only necessary to build packages [08:46] because you can easily fix it by doing $ apt-get install libatlas-dev [08:46] and we won't start a mass rebuild in natty now [08:47] vibhav: is missing that dependency causing other SRU's to FTBFS? Has the dependency been removed in Natty, since Natty was released? (Regression) [08:48] if that was a problem, it would have come up by now [08:48] But a program using HAVE_ATLAs could get this problem [08:49] again: trivial workaround, not a run time bug problem -> very far away from SRU criteria [08:49] it's not worth spending anyone's time on this really [08:49] didrocks: the mountall change looks good to me. [08:49] fine, thanks [08:53] jodh: do you want me to sponsor it? [08:53] jamespage: sorry for the wrong ping :) [08:53] hum, I can't push to lp:ubuntu/precise/qwt weird… [08:53] didrocks, np :-) [08:54] didrocks: precise-proposed? [08:56] ah, the branch name as well, yep, didn't notice thanks pitti [08:56] pitti: can you mark https://code.launchpad.net/~l3on/ubuntu/oneiric/qwt/fix-921430/+merge/107534 and https://code.launchpad.net/~l3on/ubuntu/precise/qwt/fix-921430/+merge/107533 as merged or reject? I'll add a comment and push to the right branch === tkamppeter_ is now known as tkamppeter [08:58] didrocks: done [08:59] thanks pitti :) [09:00] pitti: it seems to only have worked on the precise MR, not the oneiric one: https://code.launchpad.net/~l3on/ubuntu/oneiric/qwt/fix-921430/+merge/107534 [09:01] didrocks: perhaps I mis-clicked; done [09:01] * didrocks hugs pitti [09:03] doko: pong [09:07] pitti: can you reject as well https://code.launchpad.net/~gleichsnerd/ubuntu/precise/mountall/fix-for-805509/+merge/107908 please? [09:07] doko: I saw the E-Mail, I haven't gotten as far as a test build for Chromium 19 (having some issues with source generation), about to go to sleep, will try to have a look later toady [09:07] *today [09:09] didrocks: thanks for the offer, but I'd like to give that one a go if you don't mind? [09:09] didrocks: oh - is there a problem with that mp? [09:10] jodh: no, I just merged into lp:ubuntu/mountall (it's your trunk, right?) [09:10] jodh: the target is wrong: lp:ubuntu/precise/mountall [09:10] jodh: but the manpage is now merged, I won't upload it and let you this pleasure ;) [09:10] didrocks: ah, right. thanks! :) [09:11] yw ;) [09:13] didrocks: done [09:26] micahg, ok, thanks [09:26] pitti, sorry to bother you with administrivia, but could you reset the slope lines on the quantal burndown charts? The current lines start from before most work items were approved. [09:26] (or tell me who I should badger about it instead:-) [09:26] mpt: I can't, sorry; I have no access to status.u.c. [09:26] mpt: cjohnston knows how the process works now [09:27] pitti, ok, thanks. Will bug 1002828 be similarly a configuration problem rather than a bug? [09:27] Launchpad bug 1002828 in work-items-tracker "All ubuntu-precise burndown charts are squashed and the target date is wrong" [Undecided,New] https://launchpad.net/bugs/1002828 [09:27] mpt: cjohnston told me that we'd do this at FeatureDefinitionFreeze; the release schedule says that's tomorrow [09:28] right, was just going to suggest taht [09:28] we should just trash the db [09:28] it's rather late in the cycle to do that, but better than starting with totally wrong WIs [09:28] I don't see anything wrong with the WIs, just with the slope lines [09:29] oh, if you mean start from a new zero date for Quantal [09:29] right [09:29] makes sense [09:29] well, trash the db so that we discard all the history [09:30] I'm slightly confused.. I'm trashing the quantal db for feature def freeze... [09:30] do we get dpkg >= 1.16.2 for quantal? [09:30] I don't think doing that with precise will provide the desired output [09:31] The precise issue, I believe, is because we are still running the scripts for the precise release cycle [09:31] and so it picked up the further milestones [09:31] righth, that'll require some db surgery to remove again [09:31] we have to fix the process by which we run the scripts to where we arent doing all releases prior to doing anything with precise [09:31] geser: as soon as someone sorts out how to not break the world with the upgrade [09:31] and I think we can just stop this; it's taking many hours a day for little (or even negative) purpose [09:32] pitti: there are some backups, so I will maybe be able to figure out how to get back close to what it should be [09:32] pitti: the issue is because we want to be able to change the config files at will, IS wrote a script that pulls the bzr branch with the configs, then runs the all script [09:33] so the script needs to be rewritten to where the config files that it runs are defined somehow [09:33] right, the precise config should be renamed to .disabled or so [09:33] micahg: Not much to sort out except migrating dpkg.cfg multiarch configs to the New World Order... [09:33] that wouldnt have any effect on the site or the data that is already there pitti ? [09:34] * infinity wonders if he just volunteered to do this. [09:34] cjohnston: in addition to the db surgery [09:34] infinity: right, but someone has to do it (and I thought you already volunteered) [09:34] micahg: Oh, did I? In that case, I should do that. :P [09:34] pitti: right.. but not a negative effect on the actual site as it sits today [09:35] if so, would you mind making that change to all of the config files in the branch except quantal and summit-2012? [09:35] hello [09:35] geser: I guess the answer is that we get a new dpkg when I do the migration. :P [09:35] I'm looking to work on an issue in network-manager, but I am getting lost in the various branches on launchpad.net [09:36] penguin359, cyphermox is the person to ask about that [09:36] infinity: *applause* [09:36] It looks like lp:network-manager represents a branch of the upstream version [09:38] penguin359: if you want to work on the upstream branch, I recommend using http://cgit.freedesktop.org/NetworkManager/NetworkManager/ instead [09:38] penguin359: that way you can use format-patch for upstream submission, and have the current version [09:38] pitti: no, it's a file only in Ubuntu. [09:39] I'm trying to figure out what the packaging branch is [09:39] penguin359: if you want to work on the package, use "debcheckout network-manager" to get the right branch [09:39] penguin359: see Vcs-Bzr: field on apt-cache showsrc (that's what debcheckout uses) [09:41] pitti: are you ok with that? [09:42] cjohnston: you mean disabling all non-current files? sure, I think that's what I used to do back in the days [09:42] ok.. great.. thanks.. I'm off to dinner in a few minutes.. :-) [09:44] cjohnston: committed [09:45] thanks pitti [09:45] I'll try working with IS to see if there is a good db backup [09:46] any idea when the change happened so that I can try to find one after release but before the change that broke the charts? [09:46] I'd use the release date, April 28 [09:46] cjohnston: i. e. end of april/may 1 or so would do fine [09:46] ok.. I don't think they are doing daily backups, so I'll look around but after that time.. [09:47] if not, we can apply a little sql [09:47] :-) [09:48] I'd also be quite interested in seeing how much of a change there is to the update time [09:50] Doesn't Vcs-Bzr: represent the most current version that is on it's way to become Quantal? What would I checkout if I was working on a patch for Lucid that no longer applies in more recent Ubuntu releases? [09:51] penguin359: If in doubt, apt-get source on lucid. [09:52] penguin359: (There may or may not be lucid branches for everything, but the archive is authoritative regardless) [09:54] I do regularly use apt-get source for modifying packages for my system, but that has always been for private use and hasn't involved source control. I'm trying to better understand the various release patterns and branches now that I am working on patching a bug that might affect others in my situation. [09:55] I can just produce a patch with that, but I recently tried using Bazaar and I got a disapproval mentioning that I applied it to the wrong branch. [09:55] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [09:56] penguin359: we don't really have a good story for old stable branches so far; debdiffs should always work and be appreciated for sponsoring [09:56] penguin359: if you find someone who tells you "I won't sponsor that debdiff, do a branch instead", there's something wrong [09:56] (particularly for an SRU) [09:57] ok, thankx [10:01] Could you take a quick look at http://bit.ly/Kb5DpC and tell me what he's referring to as the packaging branch? [10:02] I thought he meant lp:~network-manager/network-manager/ubuntu, but that looks like what I used in the first place [10:03] penguin359: yes, that comment seems wrong [10:03] penguin359: I suggest to ping cyphermox about it, that MP looks fine [10:04] ok [10:33] ogra_: So, regarding f-k... If you're willing to clean up the mess, let's just sync it. [10:33] ogra_: But clean fast. :P [10:33] well, i planned to at least have omap, ac100 and omap4 for A1 ... [10:34] in the realese meeting we said arm is a nice to have for A1, so everything extra would be fine but missing it wouldnt be a disaster [10:34] Yeah, I wasn't sure we'd make the live switch by A1 anyway. [10:34] i just dont want to inverst a minute in the old f-k after switching to live ... that would be waste [10:34] But syncing/merging f-k is a good first step. [10:34] yeah [10:35] Alright. Sync away, then. I'll just become remarkably silent here in HK if it explodes. ;) [10:35] k, i'll try to have it in by EOD [10:35] HK uses quantal images ? [10:35] If you're just syncing, we can have it in by.. Now. [10:35] well, i cant sync, can just file a bug :) [10:35] ogra_: No, I just mean that I'll ignore you when it breaks. ;) [10:36] ogra_: Sure you can. [10:36] oh, thats fine ... [10:36] i can ? you mean i can do more than running requestsync ? [10:36] * ogra_ wasnt aware [10:36] ogra_: syncpackage --force -d unstable flash-kernel [10:36] oh my [10:36] how did i miss that [10:37] oh, probably because i never use ubuntu-dev-tools :P [10:37] * ogra_ installs [10:37] Pretty sure that works off of upload rights, not queue permissions. You can tell me if I'm wrong. :P [10:38] You're correct. [10:38] ogra_: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000923.html [10:39] cjwatson, yeah, i remember having read that, but u-d-t has such a lot of messy deps i never use [10:39] Even with --no-install-recommends? [10:39] Meh, most of the heavy ones are Recommends. [10:39] I didn't think it was that bloated... [10:39] * infinity looks. [10:39] 43M here [10:39] The Depends are sane enough. [10:40] better than devscripts for sure [10:40] Mostly stuff you'd have on a development system (at least one with launchpadlib) anyway. [10:40] * ogra_ doesnt want an MTA on his ac100 ... [10:40] ubuntu-dev-tools Depends: devscripts ;-) [10:40] devscripts is also really lightweight with --no-install-recommends. [10:40] argh ! [10:41] so let me install devscripts first omitting recommends [10:41] But yeah, with --no-install-recommends I wouldn't expect either to pull in an MTA. [10:41] it wouldnt be that annoying if the apt option wouldnt be half a novel to type :) [10:42] It's muscle memory here. [10:42] if it actually becomes muscle memory i would start using a config option [10:42] ;) [10:42] though we dont have the inverse of this option, do we ? [10:42] Nah, I like to try without the switch first, see what it wants, then do the opposite. :P [10:43] heh [10:43] --install-recommends may well exist to invert configs. [10:43] It does seem like a good case for a short option. I think -r is unused. [10:43] Dunno, never tried. [10:43] infinity: I think it does, yes. [10:43] cmdline/apt-get.cc:3464: {0,"install-recommends","APT::Install-Recommends",CommandLine::Boolean}, [10:43] aha [10:46] phew, what a changelog [10:47] and there is also "apt-get install --fix-policy --install-recommends" to fix it afterwards [10:47] heh, even more typing [10:47] and you can apt-get install foo bar- to negate a specific recommends [10:48] Laney: Or apt-get remove foo+ bar JUST TO CONFUSE YOURSELF. [10:48] haha [10:48] that works?!?!?! [10:49] anyway, time for an announcement mail, i wonder if ubuntu-devel is enough [10:49] ogra_: More than enough. [10:49] k [10:49] ogra_: As is usually the case with such announces, the people who read it won't care, and the people who need to know won't read it. ;) [10:50] Laney: of course that works, apt has super cow powers [10:50] heh, indeed, i even doubt they are subscribed to u-d [10:50] but at least i have something to point to if someone complains [10:56] ogra_: "But Mr Dent, the plans have been available in the local planning office for the last nine months." [10:56] -- Quotes From Hitchhiker's Guide To The Galaxy [10:57] * ogra_ has his towel [10:57] so dont panic ;) === ara is now known as Guest64238 [12:35] Hi, when do we create a -dbg package? Are there some defaults for this ? [12:35] jdstrand: as far as you know is there anything under /proc/device-tree that qemu under libvirt shouldn't read? (bug 1006149) [12:35] Launchpad bug 1006149 in libvirt (Ubuntu Quantal) "PowerPC needs access to /proc/device-tree/ in apparmor perms" [Medium,Triaged] https://launchpad.net/bugs/1006149 [12:35] dupondje: It's up to each package. [12:36] dupondje: I'd recommend only doing so when the -dbg package is built in a different build pass with some different configure or compiler options. Otherwise, the automatically-generated -dbgsym packages on ddebs.ubuntu.com are usually adequate. [12:37] cjwatson: oh ok, didn't know there were auto-generated [12:37] thats fine enough indeed === _salem is now known as salem_ [12:42] hallyn: no, I don't. the 'davis' porting machine has /proc/device-tree [12:43] hallyn: if libvirtd needs access to /roc/device-tree, that is fine, but the bug is asking for libvirt-qemu to be updated, which is every guest === MacSlow is now known as MacSlow|lunch [12:44] hallyn: we have quite restricted files for guests, so I would prefer that only specific entries or limited globs to libvirt-qemu be added [12:45] hallyn: in other words, demonstrated denials [12:45] jdstrand: ok, thanks [12:48] i wonder if device-tree will ever show up on x86 (if not i guess this minimizes the worry at least a bit) [12:49] I doubt it. I see /proc/device-tree/openprom [12:49] but that is just a hunch [14:09] didrocks, heyo. Can I bug you for a review of that quickly branch sometime this week? [14:10] pitti, does apt-cache rdepends not cover build-depends? [14:21] mterry: no. use reverse-depends from ubuntu-dev-tools [14:21] xnox, ah, thanks! [14:24] mterry: yeah, it's in my TODO :) [14:24] mterry: sorry, just had a meeting [14:25] didrocks, no probs! thanks! [14:25] mterry: probably tomorrow will be the day! [14:37] cjwatson: sorry to bother you again, but it looks like there are still some kernel pkgs in universe... [14:38] henrix: let me recheck [14:38] cjwatson: thanks [14:38] henrix: I can't find them - can you give me examples? [14:38] Or a list [14:38] cjwatson: 1 sec [14:39] cjwatson: for example: block-modules-3.0.0-21-generic-di 3.0.0-21.35~lucid1 [14:39] cjwatson: you can have the complete list on bug #1005456 [14:39] Launchpad bug 1005456 in linux-lts-backport-oneiric (Ubuntu) "linux-lts-backport-oneiric: 3.0.0-21.35~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1005456 [14:39] Oh, lucid [14:40] ah, right... yesterday i may have referred oneiric only :-/ [14:42] henrix: Fixed, sorry about that === mbarnett` is now known as mbarnett [14:42] cjwatson: thanks a lot === MacSlow|lunch is now known as MacSlow === jbicha is now known as Guest70781 [14:54] pitti: where is the code for the pending-sru page? [14:57] bdmurray: sru-report in lp:ubuntu-archive-tools [14:57] In fact it says that in the HTML [14:59] cjwatson: heh, thanks [15:02] cjwatson: is there no API way to get the queue count? [15:03] >>> ubuntu = lp.distributions["ubuntu"] [15:03] >>> quantal = ubuntu.getSeries(name_or_version="quantal") [15:03] >>> len(quantal.getPackageUploads(status="New")) [15:03] 4 [15:03] Like that you mean? === Guest70781 is now known as jbicha_ [15:10] cjwatson: exactly, thanks [15:11] Hi all! === elleuca_ is now known as Guest20629 [15:11] bdmurray: wow, I had no idea it was screen-scraping that [15:12] cjwatson: I'll have a branch in a bit [15:13] cjwatson: the count also includes backports which I'd like to exclude [15:14] you can supply pocket too [15:14] bdmurray: hm, not sure about that, we should be able to process all the backports more or less immediately and if we aren't doing so that's kind of rubbish [15:14] separate table or something maybe? [15:14] but is the SRU report not backports report [15:14] true but we have so many reports as it is ... [15:14] * cjwatson isn't going to look at another one, realistically [15:14] okay, it should be easy to separate them out anyway [15:15] I dunno, it's kind of cheesy I know but it's handy [15:59] @pilot on [15:59] (pilot (in|out)) -- Set yourself an in or out of patch pilot. [15:59] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand [16:07] doko, when you are around please could you review the openjdk-7 debdiff on bug 888129? [16:08] Launchpad bug 888129 in xmlgraphics-commons (Ubuntu Quantal) "xmlgraphics-commons version 1.4.dfsg-3ubuntu1 failed to build with openjdk-7" [High,In progress] https://launchpad.net/bugs/888129 [16:08] I've tested it locally and it fixes this bug and bug 888123 [16:08] Launchpad bug 888123 in openjdk-7 (Ubuntu Quantal) "erlang version 14.b.2-dfsg-3ubuntu2 failed to build with openjdk-7" [High,In progress] https://launchpad.net/bugs/888123 [16:24] kees: heya, just noticed that hardening-includes uses readelf but doens't depend on binutils (lxc containers really don't contain much by default ;)) [16:25] why are you using hardening-includes without build-essential? [16:26] for hardening-check [16:26] I'm doing a quick sru verification of bug 986314 [16:26] Launchpad bug 986314 in squid3 (Debian) "squid3 missing pie and bind-now hardening options" [Unknown,New] https://launchpad.net/bugs/986314 [16:26] ah [16:26] and the test case uses hardening-check which I installed in my test container but failed because it tries to call readelf which I don't have :) === Pici is now known as Guest55530 [16:54] mvo, hello! Got a moment to talk about "update-manager --no-update" ? === Pici` is now known as Pici [17:03] pitti: your precise apport -proposed upload doesn't mention bug 1002535 which is included in the changelog [17:03] Launchpad bug 1002535 in apport (Ubuntu Precise) "'not a debian format' package install failures should be Unreportable" [Medium,Triaged] https://launchpad.net/bugs/1002535 [17:05] mterry: I'm about to call it a day, is it urgent? could we do it tomorrow your morning maybe? [17:06] mvo, sure, no rush [17:06] thanks! [17:08] mterry: please ping me when you go online, I should be around and have time then [17:09] mvo, ok [17:09] ta [17:11] mpt, what is your opinion of the badge on the update-manager launcher icon that shows the number of updates? The new design seems to de-emphasize the specific number elsewhere [17:11] mterry: no opinion, I'm fine killing it [17:11] mterry: if mpt thinks that is the right way forward [17:12] mvo, cool [17:24] lool: timezones notwithstanding, would you be able to verify the correctness of my SRU change for bug #986183? [17:24] Launchpad bug 986183 in update-notifier (Ubuntu Precise) "Broken timedate handling for failed hook runs" [Medium,Fix committed] https://launchpad.net/bugs/986183 [18:06] * xnox today I learned $ man dh-exec [18:06] it's total crack, but it's tasty crack :) [18:10] slangasek, other SRU people: did you read my comment about emailed about the (new) SRU rules? [18:10] (that was yesterday) [18:10] seb128: yes, I am drafting a mail [18:10] slangasek, thanks [18:11] slangasek, I got several other people a bit puzzled about the change again today, it will be good to have some public email out ;-) [18:11] well [18:11] slangasek, will spare work on both sides [18:11] it's a change to enforce the rules that were always documented [18:11] so I'm not too sympathetic towards people not knowing these were the rules - but yes, a mail will save us all time in the end :) [18:11] slangasek, right, well the rules were not enforced for years so people are surprised that what they have been doing for ages get bounced back from one day to the next one [18:12] slangasek, I've to admit I prefer less paperwork, I liked better when we were focussed on getting things done rather than on writing but I guess we need a balance there ;-) [18:14] seb128: the test cases make the getting the verification done easier [18:15] bdmurray, right, the "[Stable Fix] section pointing out a minimal patch applicable to the stable version of the package" just doesn't make sense to me though for example [18:15] is that "attach the debdiff to the bug"? [18:15] if so it's weirdly formulated [18:15] seb128: that section is going away [18:15] as part of the mail I'm drafting :) [18:15] slangasek, well it's being asked on bugs which get commented on this week [18:15] it is? [18:15] well the comment point to that wiki [18:15] https://wiki.ubuntu.com/StableReleaseUpdates [18:15] well, yes [18:16] but the comment doesn't say that you need to add that section, does it? [18:16] I will fix the wiki and send out mail [18:16] let me read it again ;-) [18:16] and if the comment needs fixing after the email I'll fix it [18:16] " To be more succinct, make sure the bug description lists these [18:16] fields: "Impact, Dev Fix, Stable Fix, Regression Potential, Test case"." [18:16] slangasek, ^ that's what the comment says [18:16] so yes, it does [18:16] ah [18:16] well those were comments from SpamapS [18:17] right and I don't think he made the UDS session where this change was discussed [18:17] right [18:17] we should all be on the same page real soon now [18:17] slangasek, and to fair I've no clue wat to write in "stable fix" out of copying the diff inline ... good to know it's being addressed ;-) [18:17] SpamapS: ^^ so we should probably brief you on the changes to ubuntu-sru, rather than you reading about it on ubuntu-devel-announce ;) [18:17] bdmurray, slangasek: thanks [18:18] it's a bit backward that those rules are randomly applied before the SRU team got the documentation updated [18:18] or its things together [18:18] seems a bit backward [18:18] doh, I already said that :p [18:18] well anyway enough on the topic from me, thanks for addressing the issues ;-) [18:19] slangasek: that would be great. :) [18:19] I'm just going by the wiki page. [18:20]