[00:22] Not clear to me why upstart-app-launch is listed here [00:22] would someone be able to review? [00:24] I mean, I'm surprized it's help up [00:24] ah via liburl-dispatcher1 [00:24] via a Suggests?! [00:24] gah [00:24] click is in Ubuntu desktop supported too [00:24] Suggests are ignored [00:25] ah right click === plars_ is now known as plars [04:32] ^ for the upower sync, in the queue it's quite hard to review [04:32] we currently have a git snapshot, and the effective delta is just two commits plus some test suite updates [04:32] http://cgit.freedesktop.org/upower/commit/?id=db89e5a3 [04:33] http://cgit.freedesktop.org/upower/commit/?id=ecc4e37 [04:33] and we really really need those two fixes, they break a lot in GNOME [04:33] (that is, the bug that they fix :) ) [04:33] oh, and http://cgit.freedesktop.org/upower/commit/?id=03c4ab [05:26] cheers :) === rsalveti_ is now known as rsalveti [07:02] slangasek: ^-- If you're still around, care to give a once-over to those? New upstream version, but only a handful of bugfixes. The git log is only a few commits. [08:37] hiya, can somebody please take a look at bug 1235737? seems like another bug (already approved) in the sponsoring queue depends on it [08:37] Launchpad bug 1235737 in postbooks (Ubuntu) "FFe: Sync postbooks 4.1.0-2 (universe) from Debian sid (main)" [Undecided,New] https://launchpad.net/bugs/1235737 [08:49] cjwatson: Since you're awake now, want to poke at those gdb/gdb-doc uploads? bugfix-only, and rather minimal. [08:50] infinity: Was just starting on them, indeed [08:51] cjwatson: Sorry about the lazy copy/paste changelog from upstream, but, well. Lazy. I did test it, though. :P [08:53] Yeah, no problem [08:55] dholbach: sync away [08:56] I'll subscribe u-sponsors to some other ones [08:56] there's a little stack of postbooks things [08:57] thanks Laney [09:04] infinity, hmm, these touch kernels went through completely untested [09:05] ogra_: Who was meant to test them and how? [09:05] ogra_, they weren't untested, all of yesterday was spent testing them [09:05] (they were not supposed to be uploaded yet) [09:05] apw, well, touch images have no landings without the landing team nodding it off [09:06] infinity, i was supposed to test them with the autopilot tests before they get uploaded [09:06] the rest of the bits of the landing landed already yesterday [09:06] apw, which AP tests did you run ? do you have a test matrix or something, did all tests pass ? [09:07] ogra_, not me [09:07] ogra_, i waas more pointing out the process is opaque and confusing to those of us using it [09:07] the ychanges touch click package behavior, apps might misbehave [09:08] they are presumably stuck in -proposed anyhow by your britney block [09:08] they just went into the archive [09:08] there is no britney lock for universe packages [09:08] apw: It would if the touch landing team bothered to use the facilities I'd set up for them in any breadth [09:08] ogra_: Touch people have the power to block their packages. [09:09] infinity, which doesnt help us, since android (which consumes the kernel) builds from proposed [09:09] ogra_: Anyhow, if you're deeply concerned, test away. But these changes went into the master kernel yesterday, and the userspace side is all landed. [09:10] infinity, point is that per policy they would have gone through the spreadsheet stuff, which they didnt, without approval on that sheet nothing has to be uploaded [09:10] Point is that you lose. [09:10] I mean, it's inevitable with this process. [09:10] Or lack thereof. [09:11] well we'll change the process to something more sane after release [09:11] Pre-upload gating while choosing not to use the technical means available is infeasible. [09:11] ogra_: I've uploaded a lot of stuff that's on touch images without the spreadsheet. Why didn't you yell at me for glibc? :P [09:12] cjwatson, the technical means available will be used after release, i want that as much as you ... but currently all uploads are held for the Mir switch on touch ... if we need to fix a bug on the android side for this we cant rebuild it without pulling in the kernels now [09:13] infinity, i'm not yelling [09:13] Well I don't know what you propose to do about it now. [09:13] (And I will say: the arm64 porting work is not going to stop for this.) [09:13] nothing just pointing it out so it doesnt happen again [09:13] (I know that's not about the kernel, but it is about other uploads.) [09:14] ogra_: This was a change that was wanted. The userspace side landed. The kernel needed to. The idea of gating things one upload per image is insane. Full stop. [09:14] ogra_: But dropping process arguments, the kernels are in. Oh well. [09:15] infinity, discuss that with asac and lool ... i'm just pointing out something so it doesnt happen again [09:15] ogra_: security uploads trumps anything. [09:15] It's likely to happen again. [09:15] And again, and again. [09:15] ogra_: and it was security upload. [09:15] doko_: Curious. No dh_autotools-dev_{update,restore}config in libsigc++-2.0? [09:15] xnox, ?? [09:16] doko_: And no clean handling [09:16] xnox, i'm talking about the fout touch kernels that were uploaded to saucy [09:16] *four [09:16] ogra_: so do I. [09:16] cjwatson, clean handling is there [09:16] and they were supposed to be held back [09:16] using the existing one [09:16] until after Mir landed [09:17] doko_: Oh, right, generic code [09:17] cjwatson, didn't want to interfer with the manual autoreconf in this package [09:17] cjwatson: Problem here is that the kernels get copied into android; so we couldn't upload android anymore as soon as the kernels were uploaded to proposed (hints dont help this case) [09:17] ogra_: have you seen the bug they are fixing together with the matching apparmor uploads? (ps it's 6 kernels, goldfish and normal as well) see bug #1208988 [09:17] Launchpad bug 1208988 in AppArmor "AppArmor no longer mediates access to path-based AF_UNIX socket files" [High,Triaged] https://launchpad.net/bugs/1208988 [09:17] Also: if these were supposed to be held back, why did nobody tell the release team? [09:17] so completely not related to hints [09:17] lool: Or, you could upload android and get the new kernels. This is bad, why? [09:17] xnox, no, and thats not what this is about ... [09:17] You can't not communicate about specific things that were supposed to be held back and then expect that to happen. [09:17] infinity: I might have to upload android and not want the new kernels [09:17] Since pre-upload gating is infeasible. [09:17] infinity: but I can't technically stop that [09:18] and we had agreed to coordinate the uploads later today [09:18] but well [09:18] I guess there was a hiccup in this part [09:18] cjwatson, i just did ... for the next time :) [09:18] lool: I understand that you might want that, I don't understand WHY you want that. This apparmor change is, AFAIK, necessary. [09:18] cjwatson: I didn't expect anything to be held back [09:18] lool: It's bizarre to slow yourself down by only testing one tiny thing at a time. [09:18] ogra_: lool: apparmor changes went in (security bug) and if kernels didn't go in, your userspace and containment would be borked. Taking one without the other, means borked images. [09:19] infinity: it is, but there are other changes (ureadahead for instance) in the kernels, the toolchain changed, we need to test the kernels and we might have to land android to fix tests before we take new kernels [09:19] xnox: No, we actually confirmed they could go in in this order [09:19] xnox: and separately [09:19] ogra_: lool: and android package makes it's own sources where it downloads the kernels from, so you can easily change it to pull kernels from -release pocket if you wish to do so. And then hints would gate keep it. [09:19] xnox: yeah, I can workaround this specific case [09:19] lool: Erm, the ureadahead commit already existed in 2/4 kernels. You intentionally want them to behave differently? [09:20] lool: And that's literally the only change other than the apparmor stuff. [09:20] infinity: and being rebuilt [09:20] ogra_: lool: but multiple times, i've been requested to pull from -proposed to speed up image respins with updates (e.g. hybris, initramfs-tool-ubuntu-touch, etc) [09:20] it's not like toolchains broke kernels in the past :-) [09:20] xnox, infinity, cjwatson: I am personally fine with what just happened [09:20] I would like us to use hints more next cycle [09:20] Then why are we talking about it? [09:20] they wouldn't help in this case [09:20] lool: touch kernels are build with toolchain that doesn't change any more (4.6 and 4.7) [09:20] infinity: exactly :-) [09:22] right the toolchain changes do not affect these kernels at all, because the kernle doens't work if you compile it with those; which of course is an epic recommendation for the compiler you are building the rest of the stuff with [09:23] apw: =))))) [09:23] also, I think we actually copied the kernel binaries [09:23] which got tested [09:24] apw: do you know if cking tested on Mir too? [09:24] I did copy with binaries, yes. [09:24] lool, I tested with Mir enabled on maguro + manta [09:25] cking: awesome [09:25] infinity: great [09:27] * seb128 scratches head [09:27] why did I receive an "[ubuntu/saucy] gtk+3.0 3.8.4-0ubuntu3 (Accepted)" email this night when that version as already in saucy for a while [09:27] e.g https://launchpad.net/ubuntu/+source/gtk+3.0/+publishinghistory [09:28] seb128: Probably arm64 port -> new copy [09:29] Known to produce somewhat confusing mails when proposed-migration copies the new binary into the release pocket === doko_ is now known as doko [09:30] cjwatson: maybe it's useful to send an email to ubuntu-devel about the emails? cause pretty much every uploader of everything that gets build on the new port will receive these confusing emails? [09:31] Actually no that's not true [09:31] The bulk of builds are happening in the release pocket (because reasons) [09:31] The only cases where you get confusing mails are uploads to -proposed after the port was initialised [09:31] * xnox has been getting a lot of emails already and FTBFS emails as well, wrt arm64. [09:32] Yeah, I realise that but that's tied up with details of hardware and I'm not sure what I can say publicly on that [09:32] did you just say arm64? [09:33] I don't want to accidentally slag off a partner on a public mailing list. :-P [09:33] ok. [09:33] cjwatson, ok, thanks [09:33] (And hopefully the major cause of odd build failures will be fixed soonish ...) [09:34] lool: Yeah. :-) === exekias_ is now known as exekias [11:27] hud in unapproved has notably a workaround for when upstart mis-sets the dbus env vars in user sessions (this is apparently an upstart bug with set-env -g that we're still looking into); hud crashing is causing lots of test failure noise on touch, so greatly appreciated if we can land this :-) [11:27] there's a complex hud change coming up in the next hours/days to address deeper problems with it, but this one should help quite a bit already [11:34] Is a binary-only promotion still OK to do? [11:34] Should be [11:34] I want to make sessioninstaller dep on python-commandnotfound for bug #1102434 [11:34] Launchpad bug 1102434 in gnome-control-center (Ubuntu) ""System settings -> Colour", fails due to missing "gnome-color-manager" package." [Low,Triaged] https://launchpad.net/bugs/1102434 [11:34] ta [11:34] Laney, did you get the apturl fix tested/uploaded? [11:34] No Python 3? :-( [11:36] seb128: yeah [11:36] Laney, great ;-) [11:36] cjwatson: apparently not [12:10] the linux and linux-signed uploads are to fix the arm64 linux-libc-dev (and other cross environments) builds [12:13] lool: where is the workaround? [12:20] Laney: in user-session's init hud.conf.in [12:20] xnox: Maybe I have the wrong diff [12:21] Laney: the hud thing? [12:21] Laney: in unapproved [12:21] I don't believe that change is in the upload [12:22] lool: Laney: well, we want http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.13.10/revision/326 which doesn't seem to be included in the unapproved upload. [12:22] (sync) [12:22] Laney: checking [12:22] queue -Q unapproved -s saucy-proposed fetch hud [12:22] Laney: you're right, it's not there [12:22] :-) [12:22] want to re-upload? [12:23] Laney: yes [12:23] * Laney rejects [12:23] need to figure out by cu2d didn't pick up though [12:23] Laney: thanks [12:35] xnox: fyi, regarding borked images because userspace was updated but the kernels weren't-- that actually wasn't the case this time. the userspace could go in before or at the same time. it was just the kernels couldn't go in before [12:36] ah, I see someone mentioned that already [12:37] jdstrand: right the argument was that whilst apparmor can have block and not migrate to release pocket, android package is built with pulling kernels from -proposed (avoiding all blocks) [12:38] jdstrand: thus when everything is in -proposed, one had to take apparmor or otherwise be stuck with updated kernel & out of date apparmor. [12:39] sure. I am not going to participate in that conversation except to say that while I understand the desire and utility to gate the touch images, the process needs improvement and I'm glad that it is on the agenda for the next sprint [12:39] xnox, that hud fix will not have your filtering i guess ... can we have that too ? [12:39] jdstrand: ack. [12:39] ogra_: upstart upload? [12:40] xnox, for the dbus bridge filtering [12:40] wasnt that upstart ? [12:40] ogra_: there was no dbus bridge filtering, i had a patch for upstart-udev-bridge to drop that one event and not generate any upstart events for it. is that what you mean? [12:41] * ogra_ checks the bug again [12:42] xnox, oh, righ t [12:42] thats what i mean [12:44] ogra_: ok. jodh doesn't want it upstream, but it can be uploaded into the ubuntu package. [12:45] i think that would make sense [12:45] (so would having the udev side fixed too i guess) [12:46] ogra_: it is unknown if mir needs the udev event or not. [12:46] ogra_: as far as I understood yesterday's discussions. [12:46] ogra_: but i guess that can be tested. [12:46] yeah :) [12:47] ogra_: since kernel was changed to emit them.... [12:47] well, it is only emitted on maguro [12:47] mako runs without it [12:47] so i dont think we need it outside of the kernel [12:47] ogra_: yes, but propbably maguro's binary blobs want it. [12:47] right [13:04] Laney: ^ === vila is now known as vila-laaaate-lun [13:05] ogra_: if you want about upstart upload, please make it go through all the right processes. [13:05] ogra_: as you wish =) [13:10] can i get a release team meber to ack https://bugs.launchpad.net/ubuntu/+source/python-cinderclient/+bug/1236901 [13:10] Launchpad bug 1236901 in python-cinderclient (Ubuntu) "FFE for python-cinderclient 1.0.6" [High,New] === vila-laaaate-lun is now known as vila-late-lunch [13:33] Laney: Still around for the hud thing? :-) === vila-late-lunch is now known as vila [13:35] lool: back now, was lunching === arges_ is now known as arges [13:46] that workaround :( [13:49] Laney, well, look at the original start process of thge HUD [13:49] Laney, it fits well :P [13:49] I like my eyes unbled :P [13:50] Laney, did you accept it? [13:50] ya [13:50] that seems buggy [13:50] http://launchpadlibrarian.net/153097115/hud_13.10.1%2B13.10.20131002.1-0ubuntu1_13.10.1%2B13.10.20131009-0ubuntu1.diff.gz [13:50] (a dbus service, that calls a shellscript (with -hack- in its name actually) to trigger upstart to start an upsart job [13:50] ) [13:50] what is that apport hack [13:50] it's not even documented in the changelog [13:50] the printf line [13:51] (dropping the author as well seems weird) [13:51] I divined that they want to report when this situation happens [13:52] "and reporting a bug" [13:52] looks like debug logging [13:52] that should be documented in the changelog... [13:52] shrug [13:52] well, pete-woods is in -touch [13:53] it's coming from ted [13:53] http://launchpadlibrarian.net/153097115/hud_13.10.1%2B13.10.20131002.1-0ubuntu1_13.10.1%2B13.10.20131009-0ubuntu1.diff.gz [13:53] i think they cross review their MPS [13:53] oh well, hacks on hacks [13:53] *MPs [13:53] * seb128 uninstall huds [13:53] yeah [13:54] I thought about arguing that they should be using normal dbus activation instead of this weird stuff [13:55] but then I decided to stay away from the battlefield [13:56] http://paste.ubuntu.com/6213176/ [13:56] thats the current hud startup process [13:56] so the patch fits in well :P [13:57] its all about keeping the style right :) [14:01] hehe [14:07] ogra_: well at least i patched it to use "sh" instead of "bash" =/ [14:07] heh yeah [14:07] that will buy us precious bootspeed [14:07] every nanosecond counts [14:08] * ogra_ would like ot get back under 30sec === barry` is now known as barry [14:22] ogra_, jibel: could you try https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1235649/comments/44 ? [14:22] Launchpad bug 1235649 in upstart (Ubuntu Saucy) "uevent spam causes session upstart to consume massive amounts of memory on Ubuntu Touch" [Critical,Confirmed] [14:22] jodh, yes (see #ubuntu-touch) will do soon [14:22] ogra_: thanks [14:23] jodh, i fear it wont help on maguro with the uevent spam though [14:23] ogra_: right. There are a few problems going on here :) [14:23] yeah [14:23] well xnox fix works pretty well [14:24] apart from the fact that udevd consumes a bit more CPU afterwards [14:24] jodh, what do I need to do? patch Panel.qml and Shell.qml and verify if I can reproduce? [14:25] jibel, yeah, see if the session init ram consumption raises still ... on mako [14:28] ogra_, okay, doing that now [14:29] Probably → #-touch :-) [14:30] stgraber: queuebot went away [14:30] having lunch too :) [14:34] please could somebody review python3.3 and openjdk-7 ? just needed for the aarch64 bootstrap [14:37] python3.3 accepted, waiting for diff for openjdk-7 [14:38] oh, it's there [14:38] really must apiify diffs [14:57] * ogra_ hugs xnox [14:57] YAY !!!! [14:59] ogra_: can I have MIR on grouper please? =) [14:59] xnox, so be it ... [14:59] xnox, upgrade to 89 [14:59] ;) [14:59] ogra_: i do system image, is 89 published in devel-proposed channel? or which channel do I want? [15:00] saucy-proposed, yeah [15:00] (or devel-proposed) [15:14] ricmm_: ^ once it gets approved [15:16] rsalveti: great [16:05] (would be nice to get the libhybris upload reviewed; just adds a header) [16:11] queued cleaned up [16:13] stgraber, thanks! [16:13] excellent [16:14] I loaded the ubuntukylin-default-settings diff and had to go off to mop up my tears [16:14] ;) [16:15] not the change itself, but the context in the diff [16:15] cp /some/logo /the/ubuntu/logo/in/g-c-c [16:15] * seb128 pokes Laney in the eyes [16:15] or maybe not [16:15] then I get to have it read to me by a screen reader [16:16] that seems worse :( [16:16] Laney, yeah, sorry about that :/ [16:16] right, I accepted the change because it wasn't making things any worse, actually it made things slightly better, but the context looked pretty scary indeed [16:16] indeed [16:16] but yeah, the kylin setting has quite some hacks [16:16] Hi all, at what time will saucy be frozen? [16:25] and this wallpaper package needs approval, for ubiquity to recognize the new wallpaper [16:25] I think cjwatson did not modified the settings in ubiquity so a link must be created for it here. [16:26] well, I meant about what time the final freeze will be in effect [16:26] Laney: well, yes, I tried to revert as many changes as possible in previous upload, if you looked at that version, you'll be scared even more... [16:27] thanks for your efforts :-) [16:27] ypwong: usually 2100 UTC [16:27] Laney, thx [16:27] oh, gosh, I need to upload another version of -default-settings, it ftbfs... [16:28] happyaron, the patch in the bug doesn't work? [16:29] it works, but removing the unity.mo make it fail [16:29] sorry everyone I'm in a big rush cuz I'll have no network in 2min... [17:21] is there any way to tell who accepted a particular upload to saucy? [17:41] dobey: no [17:41] this causes great consternation for the team [17:42] :( [17:43] slangasek: can i convince you to accept the 3 uploads of mine that you rejected last night? [17:44] dobey: well, you can try, but I don't see why I would be persuaded that we should do no-change rebuilds of packages just to get 13.10 as the version number [17:45] slangasek: because we want to have versioning consistency across the ubuntuone projects/packages. we have been doing this for several cycles now. [17:45] with freeze exceptions? [17:46] freeze exceptions? [17:46] we're in post-beta freeze [17:46] and the RC is tomorrow [17:46] and package version number consistency is very low on my list of priorities [17:48] well, the other 6 packages i uploaded were accepted without problem, with only a version number bump. [18:01] haha, looks like we've got a conflict here :) [18:01] I'll reject them both and re-upload one with both changes [18:05] dobey: right, I guess that's why you want to know who accepted a particular package? But I presume those other packages were uploaded earlier [18:05] I guess if you can figure out who did the other accepts and talk them into un-rejected, I won't stand in your way [18:07] those were accepted by me as they weren't really causing any harm and there weren't too many of them, I then changed my mind after mentioning the problem to dobey so I'm not going to accept any more of those [18:08] (I wasn't the one who rejected the rest though) [18:08] no slangasek rejected them [18:09] * slangasek nods [18:10] i don't see why it is a "problem" [18:11] you're wasting review time, buildd resources and libraring space for nothing [18:14] i didn't even know they had to be reviewed until after i uploaded stuff and was getting "waiting for review" messages. final freeze isn't until tomorrow [18:14] we've been freezing the archive between the final beta and release for the past 2-3 cycles now [18:14] and i wouldn't really call a very short build time on an emtpy build queue a "waste of resources" [18:24] I uploaded that lxc so would be nice if someone else could review it in the queue [18:41] can someone look at apparmor-easyprof-ubuntu real quick? it is required for (at least) grouper with mir [18:47] could someone also approve user-manager ( has a bug fix that allows setting the user avatar ) and soprano ( fixes a bug when the db gets corrupted and causes problems in nepomuk ) [18:48] ScottK doesn't seem to be around [18:50] shadeslayer: looks like you're adding/changing strings in there... [18:50] stgraber: which package? [18:50] whoever did accept exempi, thanks and please accept exiv2 too [18:51] shadeslayer: user-manager [18:53] stgraber: okay [18:56] stgraber: can we get it in either way? because apparently Riddell asked for some UI modifications which resulted in string changes [18:56] stgraber: we just didn't upload the updated git snapshot [18:57] shadeslayer: if you get a UIFe, then sure (you usually need whoever works on your documentation and translations to ack the change for that) [18:57] okay [19:02] stgraber: lxc, there are no linked bugs for either of the changes; verbose++ please? [19:02] stgraber: 0011-ubuntu-cloud-prep-hook-fix-debug-helper-to-not-inapp.patch at least is self-explanatory from the shell, but the apparmor change I feel I need context for [19:04] slangasek: bug 1237543 is for that cherry-picked patch (the bug was filed after hallyn fixed it upstream and in the package, that's why we don't have a LP:#xxxxx in there) [19:04] Launchpad bug 1237543 in lxc (Ubuntu) "lxc-create (or clone) of cloud template with '--cloud' exits failure" [Low,In progress] https://launchpad.net/bugs/1237543 [19:04] slangasek: the other one was reported by vila on IRC. Basically the new apparmor blocks dbus by default. [19:04] slangasek: so a standard saucy container would be unable to use dbus with our current profile. [19:05] can someone look at python-cinderclient FFE please (#1236901) [19:05] slangasek: fixing that needs adding "dbus," to our default profile, but we can't just do it unconditionaly since the same source package is backported to all releases down to precise [19:05] slangasek: and any release < saucy will fail to parse an apparmor profile containing "dbus" [19:07] stgraber: ok. So I'm generally pretty opposed to applying per-version hacks in debian/rules instead of just expressing those differences in different per-release VCS branches in the natural way. Is there a reason that couldn't be done here, even though it's a backport? [19:09] slangasek: I'd rather avoid having to update 8 packaging branches and having to change all our automatic build scripts to know which branch to pick up when pushing new builds... [19:10] sure; whereas I'd rather avoid having debian/rules doing magic like applying dpkg --compare-versions to lsb_release ;) [19:10] (we support precise, quantal, raring, saucy in both upstream-daily and ubuntu form, so I alrady have to sync between two branches every time we change something, having to maintain per-series would be a bit of a pain) [19:11] in practice this delta would only require two extra branches (saucy vs. pre-saucy) if you wanted to do it that way [19:11] and effectively it would be safe to auto-merge [19:11] (except when it wasn't safe, which would probably be a clue to look at it :) [19:12] yeah but that'd still prevent us from using requestbackport since the automated backporting tools just take from a release and automatically spit out an updated source package ready for upload [19:12] there were provisions for sourceful backports, I thought. requestbackport doesn't handle that workflow? [19:13] requestbackport takes a source series, a destination series and a source package [19:13] *source package name [19:13] yah [19:14] so I'll allow this, because my objections don't really have anything to do with the release freeze [19:14] but at minimum, I would recommend that you invert the debian/rules handling, to make the backports the special case so that 'dbus' is part of the actual source [19:14] (not for saucy, but for the future) [19:15] slangasek: well, my plan for the future is to move the apparmor profiles upstream and have it be a .in file [19:16] ok [19:16] since we already detect most distros in our configure.ac and I believe also export the distro version as a variable [19:17] anyway, the point I want to express is that I don't think it's a good idea for part of the "source" of the package to be hidden in debian/rules [19:17] and now I'll get off my soapbox :) [19:19] slangasek: oh I agree and I was pretty annoyed by it when I got the report today as none of the apparmor abstractions would give me something that worked on all the releases I care about... so I basically ended up with 3 choices 1) hackish debian/rules 2) separate source package for backports 3) only support session+system bus and block accessibilty bus [19:20] 2) meant quite a bit of time to invest in the coming years, 3) meant breaking the desktop QA test environment at least and 1) was just ugly, so ugly it ended up being :) [19:21] stgraber: you supposed to pitch a fit at us and tell us how much this sucks so we are motivated to fix it [19:21] stgraber: truth is this is bad, and something we need to fix, but I don't have a good solution atm [19:22] jjohansen: oh, I certainly wanted to blame you ;) but short of having the parser accept any invalid keyword, I'm not sure what you could have done differently. [19:24] block by default is always how apparmor worked, so that makes sense and the dbus keyword was only introduced this cycle, so any older parser will fail... I guess if we had a all-dbus abstraction around since precise that would have been mapped to "dbus," in saucy, then I could have used that, but you'd have had to be pretty good at predicting the future a couple years ago to do that ;) [19:24] * mdeslaur hands jjohansen a crystal ball [19:25] well, actually there was a 4th alternative in my list above, backport apparmor to all releases where we backport lxc, but I figured this would probably cause even more problems ;) [19:25] stgraber: well 2 things [19:25] 1. the parser should be setting some conditional variables, then at the very least you could have wrapped the rule in if $COND_X in the policy (this should have been done a long time ago) [19:25] 2. there are plans to extent the parser so you can tell it how to parse new rules as part of policy, and a little rule to ignore dbus could have been done that way. [19:25] Of course either of those mean backporting the changes [19:25] mdeslaur: well its a problem we have known about for years [19:26] stgraber: yeah, backports are a pita [19:26] jjohansen: yeah [19:26] jjohansen: ah, those two sound pretty nice, can we have that for 14.04? :) [19:26] I'll answer that with 'unlikely' [19:26] hehe [19:26] ok :) [19:27] stgraber: we have a pretty big pile of stuff for 14.04 which includes lxc [19:27] stgraber: well if you can find us some resources to work on it ... :) [19:27] anyway, on my personal apparmor priority list, stacking is way more important than that stuff for 14.04 [19:27] stgraber: *perhaps* 14.10 would get something like that, we'll see [19:27] stgraber: you would say that :) [19:28] stgraber: yeah-- stacking is coming and planned. I know we've been saying that for a while, but a lot of work was done for that already and we hope to deliver it in 14.04 [19:28] at least something quite a bit better than what we have now [19:37] stgraber: done differently> they could also have backported support for the 'dbus' keyword to older releases [19:37] even if it was a no-op [19:48] oh, apparently I'm TIL on irssi, I didn't know that (just got a build failure for arm64) [19:52] Yeah, I've been discovering all sorts of things I forgot I was TIL on. :) [19:52] doko: Erk, why are up updating config.{sub,guess} in patches? [19:53] doko: That's just a recipe for failure next time. [19:54] doko: Something like http://launchpadlibrarian.net/152821294/bind9_1%3A9.9.3.dfsg.P2-4_1%3A9.9.3.dfsg.P2-4ubuntu1.diff.gz is much saner, and doesn't lead to a painful-to-rebase patch. [19:54] I saw a few done with dh-autoreconf though I didn't check if there was a pattern there (!doko => dh-autoreconf, doko => massive ugly patch) [19:54] infinity, well, for two or three packages, I tried to introduce autoreconf, and it did fail [19:54] infinity, stgraber: you're both slackers, you should be more like me and make sure everything you touch gets in sync with Debian so that you can stop being TIL ;) [19:54] so I assume at this stage the patch is the safest way not interfer with a build system [19:54] doko: Hence my pointing at the above that uses autotools-dev, not autoreconf. [19:55] doko: (--with autotools-dev, if it's dh(1), or as above, if it's old-style) [19:55] slangasek: I'm TIL because I fixed a utf-8 related bug a while back, that got merged upstream so I've been doing standard Debian merges since as we patch irssi to suggest irc.ubuntu.com apparently... [19:55] stgraber: right :) [19:56] infinity, and this does work when files are in subdirs? [19:56]