[00:01] sarnold: excellent [00:02] xnox: of course your little script provides a nice abstraction around when we eventually do that. :) heh [00:04] sarnold: it's a bit shame there is no definitive extension name for the profiles, thus stending time filtering out ".dpkg-new" et. al. [00:05] sarnold: and each location is processed in parallel, however one still does the loop twice =( [00:07] xnox: heh, perhaps a decade or so back, we did have a .sd ('subdomain') extension on profiles, but we ditched that somewhere along the way as annoyingly redundant. heh. [00:39] sarnold, xnox: the parser isn't almost there, it is completely there. What it can't do yet is directly handle caching for multiple policy versions, so the old version is replaced when stale, and it doesn't handle profile removal on restart [00:40] it does the filtering for different extensions etc, you can point it at a directory and it loads the profiles from it [00:41] it handles the cache management, 90% of what the initscripts do could be dropped [00:42] oh I guess it doesn't do parallel compiles [00:43] but that is actually minor [00:44] when arekm ripped out the initscript stuff for pld it made things go something like 95% faster. /me would have to dig to get the actual figures === vibhav is now known as Guest46468 [01:03] jjohansen: cripes, that's impressive :) === testing1209347 is now known as chase3023 [01:31] sarnold: found it, scrapping the bash scripting and doing direct cache load for his 4500 profiles reduced the time from 1m22s to 1.5s [01:32] jjohansen: omg I want that [01:33] yeah, for a small profile count the bash scripting overhead is not so bad, but well its time to fix it [02:46] Can anyone please help me , I have started getting "Segmentation fault (core dumped)" on 12.04 desktop terminal? [03:22] It would appear the auto importer isn't picking up network-manager, it would appear the last run was 2012. (Also would be nice to have the systemd services installed, but guessing that won't happen any time soon.) [03:26] Unit193, you mean lp:debian branches? there are loads of branches in there that are pretty much broken [03:28] darkxst: No, I don't use those. https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/network-manager/trusty [04:34] B/c [05:24] Good morning [05:36] infinity, smoser: meh, doing daily reboot of wolfe-*; seems your magic from Friday didn't last long? [05:38] pitti: Yeah, I didn't expect it to fix it, I'd just hoped. :/ [05:39] pitti: If you get a VM in that wedged state and can live with it staying broken for a bit, apw said he'd like to have access to play/debug a bit. [05:40] infinity: sure; I'll take wolfe-05 offline in jenkins, and just reboot/fix the other three? [05:40] pitti: Sure, and give him ssh access to that one then, I guess. [05:40] pitti: I'm heading to bed, but I assume Andy will be up in an hour or two. [05:40] infinity: yep, will talk to him [05:40] pitti: Ta. [05:46] infinity: hmm, seems the other three don't come back from reboot [05:46] infinity: the host might need a reboot again, too? [05:58] * pitti sends his daily "screw you" jenkinswards [06:25] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges, pitti [06:26] good morning [06:27] hey dholbach [06:28] hey dholbach & pitt, good morning [06:28] hallo mvo, wie gehts? [06:30] pitti: good, thanks! still not fully awake, but I'm hopeful the tea will help with that :) and you? [06:30] mvo: pretty much the same :) [06:32] hey pitti, hey mvo [06:41] good morning [06:42] could someone enlighten me about the purpose of incoming.debian.org? I was under the impression that it's a place packages go to be built by all the arch builders [06:42] is my understanding correct? [06:43] zyga: not quite [06:43] zyga: it's the staging area where uploads and built packages are queued after accepting it from the upload queue, and publishing it into the archive [06:44] zyga: i. e. the publisher flushes incoming every 6 hours [06:44] zyga: but buildds look at incoming so that they don't need to wait for the publisher; but they also build sources which are already published [06:44] and then again upload the build (going through incoming again) [06:49] mvo: ah, are you already handling https://code.launchpad.net/~brian-murray/ubuntu-release-upgrader/bug-1302380/+merge/214349 ? [06:51] pitti: yeah, I have a slightly extended version of his branch, I hope he gets a chance to review that soon(ish) [06:53] pitti: so after a package gets accepted it goes to incoming, gets built by buildds, then gets back to incomin ? and then flushes to the archive? [06:53] pitti: and that happens four times a day [06:53] zyga: not "back" to incoming [06:54] zyga: upload -> accept (every 10 mins or so) -> incoming -> publisher -> archive [06:54] zyga: and buildds watch for new sources in incoming and archive -> build -> upload -> same as above [06:54] pitti: ah [06:55] pitti: I'm trying to understand when a few small packages that got uploaded there yesterday will make it into the archive [06:55] pitti: it's almost 24 hours now [06:55] that sounds like a bug [06:55] pitti: there are also packages from 7th of April [06:55] http://incoming.debian.org/ [06:55] or do I read that wrong? [06:56] hm; they might be NEW or something? [06:56] pitti: plainbox|checkbox packages aren't new [06:56] NEW I mean [06:56] and I cannot see them in https://ftp-master.debian.org/new.html [06:56] plainbox | 0.5.3-2 | sid | source, all [06:56] seems fine [06:57] oh! [06:57] zyga: so it seems incoming has some problems with cleaning up? [06:57] * zyga looks if requestsync sees that now [06:57] zyga: it's also already on https://launchpad.net/debian/+source/plainbox [06:57] zyga: so yes, requestsync ought to see it [06:57] right, I see [06:57] great :) [06:57] * zyga just saw that versiontools got packaged for python :-) [06:57] zyga: FYI: https://ftp-master.debian.org/dinstall.html [06:58] ohhh [06:58] zyga: dinstall is equivalent to what LP calls "publisher" [06:58] nice! [06:58] thanks [06:58] right [06:58] I know about it [06:58] zyga: after dinstall it usually takes about two hours to get imported into LP [06:59] pitti, oh no! bug 1302077 will break high contrast theme [06:59] bug 1302077 in nautilus (Ubuntu) "Hardcoded css style checks on GTK Theme instead of XGD_CURRENT_DESKTOP" [Undecided,Fix committed] https://launchpad.net/bugs/1302077 [06:59] well mess it up [06:59] darkxst: hm, that previous list actually seemed incomplete [07:00] (and Adwaita, but I doubt anyone uses that in unity) [07:00] darkxst: I thought we don't want the title bar under unity, period; not just under these two themes? [07:00] darkxst: but anyway, if this causes regressions I'm happy to reject from the queue and revert from the branch [07:00] darkxst: how does it cause regressions/ [07:00] ? [07:01] pitti, blueman branch is fixed. I'd just committed without .pc/ last time [07:02] hate hate hate tracking .pc/ in UDD; this is just utterly wrong [07:02] Noskcaj: thanks [07:04] pitti, that patch is overriding some theming issues with the ubuntu themes [07:04] I'd agree on the .pc/ thing - UDD on v3 source packages needs a serious rethink [07:04] pitti, there is a seperate patch to bring back titlebar [07:04] darkxst: can you please explain that in bug 1302077 so that Leon can adjust? [07:05] bug 1302077 in nautilus (Ubuntu) "Hardcoded css style checks on GTK Theme instead of XGD_CURRENT_DESKTOP" [Undecided,Fix committed] https://launchpad.net/bugs/1302077 === maclin_ is now known as maclin [07:05] darkxst: I reject the upload [07:06] pitti, ok [07:09] maxb, My suggestion to fix it would be the ubuntu branches don't have stuff applied by default, and .pc/applied-patches is force added [07:09] force added? [07:17] maxb, always there [07:17] pitti, thanks for the sponsorings [07:17] meh, I sponsor as fast as I can, and yet the queue *increases* :) [07:18] that's my goal. [07:23] 1 out of 1 hunk FAILED -- rejects in file blueman/plugins/applet/DhcpClient.py [07:23] Patch dhcpclient_priority can be reverse-applied [07:23] Noskcaj: ^ still no good :/ [07:23] really? wow. [07:24] Noskcaj: nevermind; I got the orig.tar.gz from the failed bzr bd and now use plain debuild [07:24] thanks [07:24] Noskcaj: I don't physically merge this anyway, I just upload and let the auto-importer sort it out [07:25] still, it's a pain [07:25] * pitti really prefers plain debdiffs on bugs [07:25] that seems to be the majority opinion. Maybe bzr could be hacked to give normal debdiffs [07:27] not sure if it's the majority; some folks seem to like it the way it is [07:28] zyga: can you handle https://code.launchpad.net/~brendan-donegan/ubuntu/trusty/checkbox/ffe_ui_custom_transport_ubuntu/+merge/214603 ? you seem to do this via debian and upstream [07:29] zyga: or, if you fine with an ubuntu upload, I can have a look at sponsoring, but maybe you'd like to cross-check [07:38] pitti, good morning :), could you take a look at libcdr 0.0.15 which is/will be the version supported by libreoffice 4.2.4 -- http://people.ubuntu.com/~ricotz/packages/libcdr/ [07:42] ricotz: does that new version work with cdr2odg (source: writerperfect)? [07:43] pitti: hey, this is a coordinated ubuntu+debian package set [07:43] pitti: everything except for checkbox-gui is in debian [07:43] pitti: and is a sync of the new package [07:43] ricotz: the dh_autoreconf change is already in Ubuntu, could you mark this as "Merge with Debian unstable, remaining Ubuntu changes:"? [07:44] pitti: checkbox-gui is using ubuntu-sdk so it's not in debian [07:44] pitti: I'll have a sanity-check look but we've been working on that for the past two weeks :) === oSoMoN_ is now known as oSoMoN [07:51] anyone familiar with ubiquity? how can I easily test the installer mode? [07:52] I want to debug bug 1284910 [07:52] bug 1284910 in ubiquity (Ubuntu) "Xubuntu Beta 1 and Beta 2 installer has debian background wallpaper" [Critical,Confirmed] https://launchpad.net/bugs/1284910 [07:53] pitti, yes cdr2odg runs and works, will update the changelog in a bit [07:54] hello [07:54] ah, +1 would be better for this [07:55] pitti, updated [07:57] mwhudson: hey :) [08:04] pitti: thanks for syncing most of the checkbox stuff over [08:04] zyga: yw; doing your most recent sync now [08:04] pitti: are you also going to sync checkbox-support (ppc64el bugfix) and plainbox-provider-resource-generic (a few fixes) [08:05] zyga: I don't see the latter in the queue yet, but yes, I'll get to it [08:05] pitti: ok, thanks [08:05] zyga: please note that they are in unapproved, so the release team needs to ack those, too [08:05] ok [08:05] https://bugs.launchpad.net/ubuntu/+source/plainbox-provider-resource-generic/+bug/1304850 is the critical one [08:05] Launchpad bug 1304850 in plainbox-provider-resource-generic (Ubuntu) "Sync plainbox-provider-resource-generic 0.3-1 (main) from Debian unstable (main)" [Undecided,New] [08:06] https://bugs.launchpad.net/ubuntu/+source/checkbox-support/+bug/1304191 less so [08:06] Launchpad bug 1304191 in checkbox-support (Ubuntu) "Sync checkbox-support 0.2-1 (main) from Debian unstable (main)" [Undecided,New] [08:06] pitti: I'll be in #ubuntu-release, do I need anything else to assist in reviewing/landing those? [08:06] zyga: ah, sponsors aren't subscribed to teh former [08:06] oh, weird? thanks [08:07] zyga: I looked at the linked bugs lists, so it seems bug fix only; so it ought to be fine [08:07] zyga: but syncs don't have a debdiff attached to them, so the release team might have questions about where to see the changes/NEWS/changelog/etc. [08:07] pitti: I see, I'll try to produce those [08:08] zyga: which combinations did you test? the full stack of all new versions together? [08:08] pitti: yes, along with the chcekbox-gui merge request (directly to ubuntu) [08:10] * zyga works on debdiffs [08:11] pitti: 'debdiff old.dsc new.dsc > pkg.debdiff' is sufficient? [08:11] zyga: yes [08:12] thanks [08:12] zyga: perhaps put them into a pastebin and point to that in #u-r? [08:12] right [08:12] probably helps to ask around who has time to review the whole stack [08:13] ricotz: uploaded libcdr [08:20] Noskcaj: so in bug 1300521 you said that both (i. e. also gnome-photos) just needs a new grilo-plugins dep, but your branch adds a gnome-online-miners dep? [08:20] bug 1300521 in gnome-photos (Ubuntu) "gom-flickr-miner crashed with signal 5 in _start()" [Undecided,New] https://launchpad.net/bugs/1300521 [08:20] Noskcaj: is gnome-online-miners a too big dependency, or does it actually use the miners index? [08:25] pitti, It was requested by darkxst [08:28] arges: pitti: Can you help me to do SRU for precise? https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819 [08:28] Launchpad bug 1303819 in bluez (Ubuntu Precise) "Bluetooth menu's content disappeared after resume." [Undecided,In progress] [08:28] FourDollars: too late, I already uploaded :) [08:28] (and updated the MP and bug) [08:29] pitti: haha. I see it. Thanks a lot. :D [08:29] pitti, upgrade to Trusty is still blocked on postgresql-server-dev removal even with the fix of krb5, bug 1304702 is the same on i386 [08:29] bug 1304702 in ubuntu-release-upgrader (Ubuntu) "update-manager fails because of postgresql-server-dev-9.1" [Undecided,New] https://launchpad.net/bugs/1304702 [08:30] jibel: hm, that ^ bug is still with the previous krb5 [08:30] pitti, right, gnome-photos does use gnome-online-miners now [08:30] jibel: oh wait, actually not [08:30] jibel: meh, that helped for me [08:30] pitti, 1.12+dfsg-2ubuntu3 is latest version right? [08:32] jibel: yes [08:32] so I'm afraid I ran out of ideas how to fix this; I might need to invoke the mvo joker card.. [08:32] pitti, thanks! [08:32] darkxst: thanks for confirming [08:34] pitti: ok, I have a look (bug 1304702, correct?) [08:34] bug 1304702 in ubuntu-release-upgrader (Ubuntu) "update-manager fails because of postgresql-server-dev-9.1" [Undecided,New] https://launchpad.net/bugs/1304702 [08:34] mvo: right; I tried to fix that yesterday in https://launchpad.net/ubuntu/+source/krb5/1.12+dfsg-2ubuntu3 by adding an additional Replaces: to the Breaks:, to nudge apt [08:35] mvo: that helped in a schroot, but apparenlty not for everyone still [08:35] mvo, 1304702 is from saucy to Trusty and 1304403 is from precise to trusty [08:35] I'll attach new logs for P->T [08:36] ok [08:39] jibel: oh, I missed that; so it does work for p->t now? [08:39] I didn't test s->t in a schroot [08:40] pitti, no it doesn't [08:41] pitti, but the format of apt.log changed, maybe it will be more clear [08:42] jibel: yeah, it should contain more debug info now [08:43] pitti, Would you mind checking the sra-sdk merge i put up? [08:43] Your review is wrong [08:43] Noskcaj: you mean a newer one than https://code.launchpad.net/~noskcaj/ubuntu/trusty/sra-sdk/ftbfs/+merge/214647 ? [08:45] that one is 2.3.3-4~dfsg-1ubuntu1 from Logan_, which is already in teh archive [08:45] pitti, never mind. It didn't commit my changes. I'd tried to merge from debian [08:46] which should fix ftbfs [08:46] jibel: if you get the chance could you run the upgrade with https://launchpad.net/~mvo/+archive/eglibc-trusty/+packages again? I uploaded a new version [08:46] apw: hey Andy [08:46] apw: infinity said you'd like to take a look at the dpkg segfaults on ppc64el? [08:47] apw: it keeps happening a few hours/a day after rebooting; I kept one box in that state (you can ssh) if you want to take a look [08:48] smoser: wolfe-{03,04,06} didn't come back after a reboot (needed to because of the dpkg segfaults); would you mind having a look? thanks! [08:50] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges [08:54] mvo, in progress [08:54] jibel: \o/ [08:55] pitti: quick question - its ok to remove postgresql-server-dev-9.1 I assume? its no longer in the archive so it can be removed on a trusty upgrade? [09:06] mvo: for -server-dev, yes [09:06] mvo: but not for postgresql-9.1, postgresql-client-9.1, postgresql-pl*-9.1, and postgresql-9.1- [09:06] mvo: our regexp catches -server-dev as well, we could also limit that to not catch that (but still catch extensions) [09:07] pitti: ok, I look at the krb-dev transition currently if we could get that under control that should fix the issue, but might still be worthwhile to relax the regexp a little bit [09:07] mvo: *nod* [09:09] pitti, i would indeed [09:23] pitti: was your change to network-manager supposed to fix the tests? [09:23] Laney: for ppc64 and armhf at least, yes (and that worked) [09:26] Laney: as for the x86 test, it seems the ubuntu5 install broke them; I'm looking at them tnow [09:27] pitti: okay, thanks - interesting that the failures are x86 specific [09:28] Laney: it's not really about the arch, it's about runing in LXC (which doesn't work as the test needs to fiddle with the kenrel) vs. Qemu [09:28] Laney: the "isolation-machine" thing just skips the test on LXC instead of failing === alkisg is now known as work_alkisg [09:30] mvo, no prompt with -0ubuntu4.1 [09:30] pitti: aha, so it passes on arm64/ppc64el because the tests aren't actually run there [09:30] jibel: \o/ [09:30] jibel: thanks a lot for the test [09:32] mvo: oh, you have an idea about the krb upgrade? [09:34] pitti: yeah, a transitional pkg fixes it, but I'm looking into the resolver right now, its a bit embarassing that it needs so much hand holding :/ [09:34] mvo: a transitional package for the old -8 library? eww; but thanks! [09:34] pitti: yes, exactly ewww :/ [09:35] pitti: it seems like it needs to penalize packages that disappear much stronger [09:39] pitti: UDD> let's not fix it and use git-dpm instead. :-) [09:39] * cjwatson trolls gently [09:40] cjwatson: it can't possibly be any more complicated than gitpkg :) (I think I managed to check out the old debian systemd git once, but forgot all about it again) [09:41] Not a fan of what I've read of gitpkg's approach [09:42] cjwatson: yeah, I'm quite happy that they replaced it with a standard git-buildpackage tree now [09:43] (or, at least there is one now which is supposed to become "the" tree soon) [09:51] pitti: what do we lose if we lose ProcMaps in error reports, post-submission? Isn't this what the Dependencies field ultimately provides? [09:51] context: ProcMaps is 71% of all the data in the error tracker :) [09:51] ev: we must have it for retracing [09:52] ev: after we computed the stack trace and the duplicate signature (although that alreayd happens client-side), we can drop it [09:52] cool, that seems easy enough to code [09:52] ev: for LP it's occasionally interesting to have it as an attachment, but we can surely kick it out of daisy's db [09:52] after retrace, go back to the bucket and drop the ProcMaps in each OOPS [09:52] *nod* [09:52] bdmurray: ^ [09:53] ev: effectively, you can treat ProcMaps.txt like the core dump; their lifetimes should be quite the same [09:55] pitti: I think I have some idea whats going wrong in the resolver, I will continue further after lunch [09:55] pitti: interesting. I wonder if we should store them in much the same way then. [09:56] ah, the client doesn't really allow that without some rearchitecting [09:56] this aforementioned approach should do for now [09:56] ev: yes, that's what I thought; treat (CoreDump, ProcMaps) as one thing for conditional submitting, and clean them both up after retracing [09:56] bdmurray: if you want to investigate both ^ [09:56] * ev creates an Asana task for this [09:57] https://app.asana.com/0/11345516654327/11523893065995 [10:11] cjwatson: around? I'm concerned about bug 1302192. Seems like a critical issue to me, perhaps installer related? [10:11] bug 1302192 in iputils (Ubuntu Trusty) "ping is not setuid root" [Undecided,Confirmed] https://launchpad.net/bugs/1302192 [10:12] Or xnox maybe? ^^ [10:12] how would that be installer-related? [10:13] It seems to be that the package is good, but an ISO based install mysteriously ends up with the file capability missing === tkamppeter_ is now known as tkamppeter [10:13] well, maybe capabilities aren't preserved in squashfs [10:13] or maybe ubiquity doesn't copy them, I guess that's possible [10:13] let me check [10:18] Ah. I didn't realise that ping switched from setuid to a file capability in Saucy -> Trusty [10:25] /usr/bin/gnome-keyring-daemon /usr/bin/arping /bin/ping /bin/ping6 <- potentially affected programs on my system [10:27] squashfs does seem to have xattr support though [10:27] and in particular supports the security namespace [10:28] so might just be that ubiquity's copying code needs to preserve xattrs [10:30] I should probably know this, but does the server iso even use ubiquity? [10:31] Should be debian-installer. [10:31] That's what I thought, but I am unsure. I use cloud images. [10:31] what he said, yes [10:32] still copying off squashfs in that case for the base system, but using live-installer instead [10:32] anyway, I'll check both [10:32] OK, thanks. [10:32] * rbasak needs to brush up in this area [10:33] ah, live-installer uses tar, we'd need to pass --xattrs I think [10:36] * mvo wonders what happend to his eglibc upload, no confirmation from the upload since ~1h [10:36] mvo: 10:37 -queuebot:#ubuntu-release- Unapproved: eglibc (trusty-proposed/main) [2.19-0ubuntu3 => 2.19-0ubuntu4] (core) [10:37] you should have had a Waiting for approval email [10:37] good, "getcap /bin/ping" in a live session returns "/bin/ping = cap_net_raw+p" [10:39] thanks cjwatson and Laney [10:40] cyphermox, Laney: NM> ah, it seems our apparmor workaround for bug 1244157 stopped working [10:40] bug 1244157 in linux (Ubuntu) "[3.11.0-12.18 regression] "Failed name lookup - disconnected path" in dhclient D-BUS access" [Low,In progress] https://launchpad.net/bugs/1244157 [10:42] mvo: accepted anyhow [10:42] thanks cjwatson [10:52] beisner: ^^ if you're interested. Thanks for your help. === MacSlow is now known as MacSlow|lunch [11:19] jodh: slangasek: looks like mounted events block mountall - instead of "--no-wait" =( === Sweetsha1k is now known as Sweetshark [12:00] xnox: yes, this is documented in mounted(7) since 'mounted' is a hook-type event (upstart-events(7)). [12:03] jodh: ack. Fair enough, used a different check/event so i'm all good. === MacSlow|lunch is now known as MacSlow [12:35] xnox: Anything I can do to help processing bug #1294858? Or will it have to wait? [12:35] bug 1294858 in ubiquity (Ubuntu) "Installer does not install all language support packages" [Undecided,Confirmed] https://launchpad.net/bugs/1294858 === apachelogger is now known as apakhelogger === apakhelogger is now known as apaKhelogger [12:55] GunnarHj: i didn't have time to look into it yet. if not this week, then it would be for U-cycle / SRU into trusty 14.04.1 release =/ [12:56] xnox: Ok thanks, then I know. === _salem is now known as salem_ === bfiller_afk is now known as bfiller [13:17] xnox: thanks for the apparmor job! question: because this is a task, it isn't possible for a console login, lightdm login, *dm login, etc to happen without this first running? [13:17] well a task and its start on line [13:19] jdstrand: it's a task, thus "started appararmor-loaded" event will only be emitted after it completes fully. [13:19] jdstrand: thus e.g. another jobs can do "and started apparmor-loaded" or in their pre-start do $ start apparmor-loaded, which will block until it's completed. [13:20] jdstrand: let me check the graphs to see where it's placed... 1sec. [13:20] xnox: ok, right. so in order to deploy this properly, we need an apparmor job and then adjust all other login jobs to use "and started apparmor-loaded" [13:21] xnox: what happens when apparmor is not installed on the system? [13:21] xnox: eg, someone wants to use selinux [13:23] pitti, deal [13:23] smoser: in case you need to reboot the host: apw is currently debugging the segfault on wolfe-05, so can you please wait with that a bit? [13:23] smoser: rebooting the other three VMs is fine at any time as they are essentially dead (at least with ssh) [13:24] jdstrand: there is a better way [13:24] xnox: I guess we could solve that by having upstart itself ship the job file [13:24] xnox: oh? [13:25] xnox: I also think we need something along the lines of: http://paste.ubuntu.com/7226194/ [13:26] so I can collapse the click-apparmor and apparmor jobs into one [13:26] jdstrand: so if we change it to "start on mounted MOUNTPOINT="/" " then that job will block reaching further significant events (e.g. local-filesystems, filesystems, runlevel, etc.) until apparmor profiles are compiled and fully loaded. [13:26] pitti, i bounced the guests. [13:26] and they should all be up now. [13:26] (along with short-circuiting some known situations) [13:27] smoser: cheers; I'll dist-upgrade them while they are still off jenknis, and then plug them back in [13:27] jdstrand: yeah, but will need to add a not-container check in the script itself, since we can't block on an "and" condition. [13:29] xnox: I'm not sure I understand the statement. are you saying that we should remove 'and not-container' and then uncomment the '#[ -x /bin/running-in-container ] && /bin/running-in-container && exit 0' ? === manjo` is now known as manjo [13:31] jdstrand: well running-in-container is shipped by upstart =) so yeah, we'd need to add a line which is "! running-in-container" [13:31] to the job. [13:33] xnox: ok, here is the updated job: http://paste.ubuntu.com/7226232/ [13:33] xnox: the 'better way' was referring to making sure console and display managers logins don't have to be modified? [13:34] jdstrand: that's way too much. [13:34] xnox: what is too much? [13:35] jdstrand: clicks are already handled by the click-apparmor.conf job [13:35] xnox: I know-- I want to remove that job [13:36] jdstrand: ok, "convergence" eh? =) [13:36] honestly, I'd like to find a better way than that hack I came up with to know when to run aa-clickhook, but that is for another day [13:36] rbasak - cool, thx. looks like it's just about tackled (ping getcap) [13:38] jdstrand: i don't like the gazzilion checks we do in shell. If the task fails, that's fine and the upstart job will stop, cause it's all running under set -e. [13:38] jdstrand: thus none of the upstart jobs typically do [ -x /usr/bin/foo ]; exec /usr/bin/foo [13:39] ehh [13:39] that makes me very unconfortable [13:39] jdstrand: if load_configured_profiles gracefully fails, when apparmor is not available that's all what we need. [13:39] jdstrand: i'd rather be aggressively loading the profiles. [13:40] xnox: load_configured_profiles is shell. I can move the checks there, but not sure what difference that would make [13:40] jdstrand: http://paste.ubuntu.com/7226258/ without any checks. [13:40] they are no-op code / asserts. [13:41] so, we actually do have these checks [13:41] ... because of $reasons ?! =) [13:41] look at /lib/init/apparmor-profile-load [13:41] right. [13:41] that is what something like mysql uses [13:42] we have these checks because over the years we've found they are needed [13:42] cyphermox, Laney: NM with adjusted tests uploaded; something in the DHCP client stack got slower, so I had to bump the DHCP timeout from 15 to 20 seconds to make them pass again; the other failure was due to the PE change in ubuntu5 [13:42] * xnox can't wait for "u-cycle" to switch all of these to apparmor stanza =))) [13:42] cyphermox: I disabled the negative test for the temporary IP with PE disabled, as I'm not sure whether that's intended [13:42] well, I figured we wouldn't do that too aggressively because of systemd [13:43] jdstrand: having all check in the upstart job is fine. as long as the conditions are correct. [13:43] pitti: I think the PE stuff was broken and is now fixed [13:43] jdstrand: e.g. check for /sys/kernel/security manually, as one cannot do "and mounted MOUNTPOINT=" reliable (mounted event blocks mountall and thus other portions of the and condition will not get emitted and deadlock mountall) [13:44] cyphermox: yeah, perhaps; before, you got a temp IP with PE enabled, and no temp IP with PE disabled, which sounded quite plausible [13:44] well, no that's the way it should be [13:44] jdstrand: hence "start on mounted MOUNTPOINT="/"" and this point it's past mounting "/sys/kernel/security" or try to mount it again. and all profile loading will block boot. [13:44] that's the way that it was until ubuntu5, now it always gets a temp IP [13:45] jdstrand: and it practice it's lightning quick, here on a typical laptop with an SSD. [13:45] pitti: must be that the fixes to some patches got done wrong [13:45] pitti: I'll take a look at it [13:46] cyphermox: ok, thanks; I disabled that test in r812 as you told me it's correct now; but please revert that if it passes again [13:46] xnox: sorry, you lost me. the apparmor job in my paste (http://paste.ubuntu.com/7226232/) doesn't currently check for /sys/kernel/security/apparmor (I missed that). are you saying it should or should not? [13:46] jdstrand: let me reply with a paste =) [13:46] sure [13:48] cyphermox: not sure where the slowdown comes from, but with the increased timeouts they at least pass again [13:51] right [13:51] pitti: you meant ubuntu6 for the patches no? [13:51] ubuntu5 contains a patch, but it should be irrelevant to PE [13:52] cyphermox: could be, yes; I meant reversion of the disabled "no temp IP" test (r812) [13:52] ok [13:52] if the previously checked behaviour was in fact right, and the test pointed out an actual regression [13:55] jdstrand: something like this: http://paste.ubuntu.com/7226316/ [13:55] jdstrand: changed "start on" and added "/sys/kernel/security" block. [13:56] xnox: ack [13:57] I wonder if mounting securityfs is enough to get /sys/kernel/security/apparmor [13:57] I guess it would be (would have to check) [13:58] mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html > your eglibc upload keeps my little minions busy :) [13:58] xnox: so, because this is 'start on mounted MOUNTPOINT="/"' and it's a task, does that mean other jobs/tasks will block until this is done? [13:59] pitti: hehe [13:59] xnox: ie, we don't have to adjust the lightdm job (et al) [13:59] jdstrand: correct it will block, and no changes are required in other jobs. [14:00] does anyone know under which circumstances /proc/sys/crypto/fips_enabled would be present and get EACCESS on fopen()? [14:00] I don't seem to have crypto/ at all [14:01] xnox: ok, cool. I've got this locally. I guess my team can figure out if we want to push this in 14.04 (it requires a lot of testing) [14:01] xnox: thanks for you help! it will definitely be in 14.10 [14:01] jdstrand: "in 14.10" as in, in just 9 days ;-) =))))) [14:02] :) [14:04] stgraber, when we setup lxc environments, what do we use to setup the network brigding for them ? [14:06] apw: most people just use the bridge that's setup by the lxc-net upstart job, or you can define extra bridges in /etc/network/interfaces or you can use libvirt's own bridges [14:07] rbasak: ok, hopefully wheels now mostly in motion - thanks for the heads-up [14:08] cjwatson: no problem. Thank you for looking at it at such short notice. I certainly wouldn't have been able to figure out all the pieces quickly enough. [14:08] I probably can't easily do much about systems that are already broken [14:08] dpkg-reconfigure of the relevant packages should sort them out, or possibly even ongoing upgrades [14:09] xnox: so, in theory, this upstart job would remove the need for the apparmor stanza? [14:09] or sudo apt-get --reinstall iputils-ping etc. (perhaps also iputils-arping, gnome-keyring) [14:09] pitti: thanks! [14:09] s/--reinstall/--reinstall install/ [14:09] --reinstall is what I was thinking. dpkg-reconfigure wouldn't fix the delivered binaries, would it? [14:10] dpkg-reconfigure has the side-effect of running the postinst and it's the postinst that sets the capabilities [14:10] but --reinstall is probably better, rather than perpetuating the meme of using dpkg-reconfigure for things other than debconf :) [14:10] xnox: please help! =S [14:10] Ah - I was under the impression that the binary package's archive magically contained the capabilities. [14:11] no, in a sane world it'd be that way, but I think it has to be in maintainer scripts because packages need to define fallbacks in the event of filesystems that don't support xattrs [14:11] I see - thanks. [14:11] xnox: the xubuntu installer background issue needs to be fixed and I would like to help debugging it [14:12] A no change rebuild of the affected packages would fix everything then, right? Not worth it? [14:13] stgraber, i am more asking by default what interface do you use to add things to the bridge [14:13] rbasak: it would, though no way to synchronise it with people who do installs from beta-2 media between now and release [14:13] stgraber, do you run external things, or talk netlink, or ... [14:13] apw: netlink [14:13]