=== salem_ is now known as _salem [06:09] Noskcaj_: merge flashplugin-nonfree-extrasound> am I touched-it-last? sure, please do [06:10] pitti, You were the last to look at it. oneric i think [06:25] apachelogger, ScottK: do you mind if I upload kde-workspace to put back the init.d script? (needed for insserv compatibility, it won't actually ever run on Ubuntu) [06:25] for bug 1323274, blocking https://code.launchpad.net/~ubuntu-core-dev/ubuntu/utopic/sysvinit/unreviewed/+merge/219999 [06:25] bug 1323274 in kbd (Ubuntu) "Restore Debian's init.d script for insserv compatibility" [Low,Triaged] https://launchpad.net/bugs/1323274 === tedg is now known as ted === Ursinha-afk is now known as Ursinha [06:39] good morning [06:39] apachelogger, ScottK: well, I'll just do and take the bullets (it's just reverting that particular delta to Debian) [06:56] greyback: happy to meet up with you out where the coffee break is held. [06:57] TheMuso: ok, see you there === ted is now known as tedg [07:21] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, infinity [07:21] pitti: I'll only mind if you break something, that's my job :P [07:22] apachelogger: hehe; yes, of course [07:22] apachelogger: if it ever finishes building :) [07:33] jjohansen1, is there a bug for those lxc test failures? [07:36] mterry: 1323528 === shijing_ is now known as shijing [07:40] xnox, where are you hiding ? [07:41] mterry: btw I am testing and will submit the fix for it soon [07:41] jjohansen1, cool, thanks [07:42] pitti: can you take a look at bug #1247584 and tell me if there's anything else I need to do or I can consider it done? [07:42] bug 1247584 in systemd (Ubuntu) "[keymap] Since upgrade to Ubuntu 13.10, udev doesn't map middle mouse button." [Undecided,Confirmed] https://launchpad.net/bugs/1247584 [07:42] Shock: hey! yes, I saw your response yesterday [07:42] Shock: thanks for your patch! [07:42] pitti: sure [07:42] Shock: I probably won't get around it this week (sprint), but it's on my TODO list now [07:43] Shock: so from your POV it's "done" [07:43] pitti: cool, thanks [07:43] ogra_: studio 8 at the moment [07:43] (on the sunset strip) [07:44] wgrant: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.utopic/touch.sources ~ 226 source packages [07:45] xnox, we need to talk if you are not in a meeting anymore [07:45] xnox: Plus core, I suppose? [07:45] wgrant: yeah. [07:46] Right, vaguely manageable. [07:46] wgrant: yeah, i would have thought some of kde ppas are bigger. [07:47] They're a bit of a problem, but yeah. [07:51] doko: Would you mind having a look at the wxwidgets3.0/arm64 build failure? ICE, I'm seeing something that looks similar in redeclipse/arm64, but am in meetings and haven't had a chance to investigate properly yet [07:52] xnox,wgrant: touch inherits from sdk-libs, so I think you need to count that too [07:53] xnox: could you put a quick look at http://paste.ubuntu.com/7527535/ ? [07:53] little things like qtbase there [07:53] xnox: in particular, for the "shim" nfs-common upstart job I supposed I should add a "stop on" for maybe runlevels 0 and 6? [07:54] So more like ~600 ... [07:54] xnox: stop on runlevel [016] ? [07:58] pitti: no, no stop on needed. [07:58] pitti: let me double check. [08:00] pitti: actually it should be "stop on (stopped idmapd and stopped gssd and stopped statd)" no? [08:01] cjwatson: That'll be in the top 10, and might end up kicking me into making NMAF suck slightly less, but shouldn't be fatal. Thanks for the details. [08:01] xnox: ah, I think an "or" in that case [08:01] xnox: stop on (stopped idmapd or stopped gssd or stopped statd) [08:01] wgrant: ok, sorry to accidentally blindside you [08:02] xnox: cause if either is down, nfs-common is not "fully" running any more [08:02] pitti: ack. [08:02] wgrant: I think I tacitly assumed "will probably fit within default quota => not a problem" [08:02] It's number of packages rather than size of packages. [08:02] NMAF index generation is unbelievably terrible. [08:03] pitti: i'm ok with that, and that's a good state approximation. [08:03] xnox: ack, thanks; testing now [08:05] wgrant: yeah, that's obvious now you say it [08:05] hmm. struggling to think of an alternative, all the same [08:06] Nah, it's easy to make it not suck. [08:06] derived distros obviously wouldn't work, and I don't think we should be creating extra distroseries for vendor-specific RTM projects [08:06] But if you were looking at more than a couple of thousand packages I would have died :) [08:06] yeah, I think it will be impractical to make the PPA build entirely standalone for that reason [08:06] ara: my desktop died [08:06] Imight get bored on the plane and fix it. [08:06] does anyone know about docs on how to do ubuntu online accounts integration? [08:06] (i.e. full germinate-speak depends+build-depends closure) [08:07] ara: I managed to log in to see a stream of kernel errors related to NMI and USB [08:07] ara: I need to have a look at it, maybe the fan is stuck or something [08:07] wgrant: benefit of living in .au, lots of plane time to get bored in? [08:07] I attempted it back in '09, but that was before anybody cared about performance, so it was never acceptable to people who could land it. [08:07] Indeed. [08:08] evfool, try asking mardy maybe, he can probably point you to the right direction [08:09] thanks seb128, I'll ask mardy [08:09] evfool: hi! There aren't many docs at the moment, but I can hopefully help you :-) [08:10] slangasek: do you have a minute to review http://paste.ubuntu.com/7527609/ ? that's a nontrivial (but not too complicated either) diff for nfs-utils [08:10] evfool: do you want to add support for a new service, or are you developing an application? [08:10] mardy: I have found an html5 tutorial [08:10] slangasek: I tested it in a VM (upgrade, various start/stop), and it works fine here [08:10] mady: would like to add uoa integration for an existing app [08:10] mardy^ [08:13] evfool: OK. What application is it? Is it a HTML5 one? [08:14] mardy: that would be straightforward based on the HTML5 tutorial, it's Vala, but C code would also help me [08:18] mardy: just found your signong-glib-google-demo, trying to decipher it :) [08:19] evfool: there's a patch for shotwell (it's written in Vala) to add support for Online Accounts [08:19] evfool: you could do "apt-get source shotwell" to get it [08:21] mardy: found it on launchpad already, in the deb folder, I assume 06_uoa.patch is the thing to look at ;) [08:21] evfool: yep :-) [08:27] mardy: thanks, I'll try some stuff, and will ping you if I get into trouble [08:36] cjwatson, arm64 recently has issues with precompiled headers, not reliably reproducible. as a workaround build without pch. would like to wait until 4.9 is the default and see if this persists [08:43] dholbach, infinity while your piloting would be nice if you could look at the mega cleanup of g-s-d! seems no one else wants to! [08:43] https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1318539 [08:43] Launchpad bug 1318539 in gnome-settings-daemon (Ubuntu) "Vanilla gnome-settings-daemon 3.8" [Undecided,Confirmed] [08:46] 4~/exit === zyga_ is now known as zyga [08:50] darkxst, I'll have a look, but I could imagine that I won't know enough about it to make a good decision [08:52] mardy: hi, I'm trying to add a SSO provider for vimeo [08:52] but the process doesn't quite complete [08:53] I have logging output from the signon-ui: https://pastebin.canonical.com/110741/ [08:53] it seems to get most of the way through the process [08:54] but the https://wiki.ubuntu.com/?=&code=4ee3705aabf48607fb237a925f9fd68b4a0f2d7a URL looks a bit weird to me [08:54] I can provide the provider / service files if that will help [08:55] jdstrand: hi. Would you know how to debug why dbus on my laptop doesn't seem to be handling apparmor? [08:55] pete-woods: hi! It's not clear from the logs what's happening; do you get to enter your username and password? [08:55] pete-woods: yes please, so I can try here [08:55] mardy: yes, I enter the credentials on the first page, it then does the usual "would you like to authorise this app" stuff [08:56] mardy: but then when I click accept it dumps me out with no error [08:56] pete-woods: it actually seems that the process completed successfully, I can see an authentication token in line 89 [08:56] mardy: I passed on your debug tips to pete-woods. It is handling the authorize workflow, but never converting the access code into a token [09:00] doko: this one seems pretty reliable, FWIW ... [09:00] cjwatson, ok, will try a local build === vrruiz_ is now known as rvr [09:01] doko: I don't see a gcc option to disable precompiled headers - am I missing it? [09:04] cjwatson: would you happen to know why this isn't in -proposed yet? it got uploaded yesterday: https://launchpad.net/ubuntu/+source/autopilot-gtk/1.4+14.10.20140526-0ubuntu1 [09:04] pitti: the langing hasn't completed yet [09:04] it seems LP doesn't want to publish it? [09:04] *landing [09:05] thomi: oh wow, you can upload something to Ubuntu and then kind of hold it back in limbo somehow? [09:05] pitti: check silo 19 on the SS [09:05] pitti: it didn't get uploaded to ubuntu [09:05] yet [09:05] ah, so that LP page is just utterly confusing then [09:06] hmmm, yeah, it's odd that LP shows it has been uploaded [09:06] pitti: The build was 22 hours old, but it was only very recently copied to -proposed [09:06] surely that doesn't include PPAs? [09:06] pitti: https://launchpad.net/ubuntu/+source/autopilot-gtk/+publishinghistory makes it clearer [09:06] thomi: Sure it does :) [09:06] oh, ok, cool [09:06] The buildd still has to upload builds for PPAs [09:06] cjwatson: aah, that makes much more sense now; thanks! [09:07] And indeed in this case it was uploaded by the jenkins bot [09:07] jamesh, pete-woods: the token is there, but somehow after receiving it, the authentication plugin gets an error serverReply : "{"error":"application/vnd.vimeo.auth"}" [09:07] You have to get the source into LP somehow at some point [09:07] jamesh: I am going to point you at tyhicks [09:07] Though you can then copy it around as much as you like later [09:08] cjwatson: yeah, I was confused by "uploaded by ps-jenkins bot 22 hours ago" [09:08] Right, that was the original source upload to the PPA [09:08] But yeah, I tend to reach for +publishinghistory pretty quickly [09:08] Since that's comprehensible :) [09:08] jamesh: though, I'm curious what you mean by 'handling apparmor' [09:09] jdstrand: I'm getting errors when trying to execute org.freedesktop.DBus.GetConnectionAppArmorSecurityContext [09:09] jamesh: is this on utopic or trusty? [09:09] e.g. "dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionAppArmorSecurityContext string::1.1" returns an error [09:10] jdstrand: utopic. [09:10] jamesh: and you said on desktop? [09:10] that command returns "unconfined" on my phone hardware, and an error on desktop [09:10] actually, I don't think tyhicks is needed after all [09:11] how up-to-date is your utopic desktop? apparmor hasn't been adapted to the changes in the new 3.15.x kernel yet [09:11] jamesh: the utopic desktop kernel does not yet have all the apparmor patches (it has what is upstream, not the additional stuff we are in the process of upstreaming) [09:11] ahh. [09:11] and the phone has a completely different kernel [09:11] jamesh: that coming. if you boot a trusty kernel, that should unblock you [09:11] jamesh: yes [09:12] s/that/that is/ [09:12] thank you. [09:13] jdstrand: fyi: we should have the mediascanner QML bindings going through D-Bus shortly. I'm now working on adding the apparmor hooks to it [09:13] the next step is to get every client of the mediascanner going through d-bus [09:15] jamesh: nice! that sounds great :) [09:16] jdstrand: I'm a little concerned about encoding security policy directly into the daemon though (in particular, making decisions for particular security context labels) [09:16] jamesh: that is a workaround until there is trusted session support [09:16] okay [09:17] jamesh: in mir. that isn't intended to be there forever. we don't now have a way to prompt the user if the access is ok (ie, you can't use trust-store) and we don't want to break the music-app, so we just do this [09:17] it is icky, but temporary [09:18] cjwatson, it should be in the packaging. configure.in: bk_use_pch=no [09:18] but I'll try to reproduce it first [09:19] jdstrand: I was thinking more about the way media-hub encodes knowledge that an app has access to ~/.local/share/$package and ~/.cache/$package [09:19] which presumably wouldn't invoke a trust-store dialog [09:19] let me look at the code real quick [09:20] pitti: hmm, so, nfs-utils is a mess. Are you readding the nfs-common init script because something depends on it? [09:20] slangasek: yes [09:20] slangasek: yeah. [09:20] pitti: because we need to split this init script for proper systemd integration too, so I'd greatly prefer to move the other direction [09:20] ah, what depends on it? [09:21] * pitti tries to find the pastebin again, hang on [09:21] slangasek: but pitti only created a dummy upstart job (ala mountall.sh) [09:21] right [09:21] but IIRC, idmapd may not always start? [09:21] ditto statd [09:21] slangasek: should it be just or'ed ? [09:21] utopic/etc/init.d/umountnfs.sh:# Should-Stop: $network $portmap nfs-common [09:21] utopic/etc/init.d/nfs-kernel-server:# Required-Start: $remote_fs nfs-common $portmap $time [09:21] utopic/etc/init.d/nfs-kernel-server:# Required-Stop: $remote_fs nfs-common $portmap $time [09:21] slangasek: ^ [09:22] ah, nfs-kernel-server, hah [09:22] slangasek: (sure the dependnecy will fire earlier then.....) [09:22] so we at least could fix that in one place ;) [09:22] slangasek: so, not that much, but these could still creep in with syncs/merges from other packages, so I thought it'd be cleaner to keep Debian's and shadow it [09:22] doko: oh, you meant turn off pch in the gcc build, I thought you meant turn it off in the wxwidgets3.0 build [09:22] pitti: right, but as nfs-utils comaintainer ;P, I'm planning to move this in the other direction in Debian [09:22] jamesh: ok, right. the point of media-hub and mediascanner is that they are trusted helpers. they are purposefully there to enforce access controls beyond the static apparmor policy. since media-hub and mediascanner2 allow access to other files, they need to be careful about how they do so [09:23] slangasek: other direction sounds even better, of course [09:23] jdstrand: http://bazaar.launchpad.net/~phablet-team/media-hub/trunk/view/head:/src/core/media/player_skeleton.cpp#L153 <- that's the code [09:23] slangasek: do you plan to do that "soon", or can/should we use this to unblock the insserv transition (it [09:24] 's the last affected package) [09:24] pitti: I was certainly planning on doing it "soon", and think it would be easier if we didn't then have to unpick another Ubuntu-specific upstart job in the process [09:24] jdstrand: It just seems a bit weird to be repeating these parts of the security policy in each daemon (determining package names based on apparmor contexts, what files those contexts automatically have access to, etc) [09:24] jamesh: every trusted helper will be a little different. some, like location service, won't need to have more logic because they don't give out more access [09:24] because if we change details of the policy, we'd need to go through each of these services and update it [09:26] jamesh: most trusted helpers don't have to do this [09:26] okay [09:26] jamesh: and we don't expect the paths to change, cause the specification is using standard XDG directories [09:26] slangasek: so the other option which wouldn't introduce blocking right now is to drop that shim upstart job and just drop the dependency in nfs-kernel-server? [09:27] pitti, xnox: anyway, I'm not exactly sure which of the components of nfs-common is a prereq for nfs-kernel-server, but each of these is possibly not going to start on boot and could block [09:27] pitti: I wouldn't want to just drop the dep either [09:29] slangasek: ATM we only have an init.d for nfs-kernel-server and upstart jobs for nfs-"common"; how is that dependency being enforced right now? [09:31] cjwatson, no, turn it off in the wxwidgets build [09:32] pitti: because the nfs-kernel-server init script starts in runlevel 2 and the upstart jobs 'start on local-filesystems'. If you have both nfs mounts and nfs-kernel-server there's guaranteed ordering, if you don't have nfs mounts there's a race but nfs-common has a head start [09:32] slangasek: ah, ok; so isn't that the same with changing nfs-kernel-server to either drop the nfs-common dep or drop it to should-start? [09:33] slangasek: (to avoid having to clean up nfs-common.conf later on after you do the split) [09:33] doko: oh, ok. let me know if you want me to upload that then [09:34] (--disable-precomp-headers apparently) [09:34] pitti: as long as you're on upstart, yes; will do the wrong thing on systemd, but that's a deeper problem which I suppose we can deal with a little bit later [09:34] slangasek: *nod* [09:34] hmm, so did you already upload this? [09:35] slangasek: yes, but with block-proposed, so easy to change [09:35] mmk [09:37] slangasek: so the total delta to what's currently in utopic would just be th drop the LSB header dep of kernel-server [09:37] s/th/to/ [09:37] thomi: "Jenkins Fixed - utopic-adt-autopilot-gtk 13" \o/ [09:38] pitti: makes sense [09:38] pitti: virtual high-five! o/ [09:38] slangasek: ack [09:38] thomi: ^5s [09:38] :-/ [09:40] thomi: I think that warrants a :-) [09:40] ... === charles_ is now known as charles_quassel === charles_quassel is now known as charles__ [09:53] ogra_, any objections if I make /var/lib/lightdm (the greeter user's HOME dir) persistent? [09:53] ogra_, in touch [09:54] is there much stuff in it ... ? [09:57] mterry__, (also do we need to wipe it for factory reset ? if so, please tell sergiusens ) [09:57] ogra_, just some typical cruft from being a user (some junk in .cache/.config) [09:58] ogra_, for factory reset... hmm I guess -- I had assumed we just wipe disk and reinstall base system image? [10:00] stgraber: how does system image update [10:01] stgraber: does shutdown? [10:01] (reboot) [10:04] cjwatson, please do. is not reproducible, and segfaults on a different file each time [10:20] Hi pitti [10:20] hey GunnarHj [10:20] pitti: Did you see this: [10:20] anyone come across this error before? dpkg-source: error: cannot represent change to trunk/.bzr/repository/packs/9245e3e3055bac62bf0c407a72389cbc.pack: binary file contents changed [10:20] https://lists.ubuntu.com/archives/ubuntu-translators/2014-May/006512.html [10:20] why does debuild care about what's in .bzr? [10:21] use the exclude option [10:21] debuild -S -i -I [10:21] or call bzr bd if it's that kind of branch [10:21] $ grep BUILDPACKAGE .devscripts [10:21] DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -uc -us" [10:21] or that yeah [10:26] doko: which room are you in? [10:27] there is something weird going on with gcc -dbg package dependencies [10:29] jdstrand: thanks for your help. I've got an MP for mediascanner here: https://code.launchpad.net/~jamesh/mediascanner2/dbus-apparmor/+merge/221058 === Ursinha is now known as Ursinha-afk === tedg is now known as ted === Ursinha-afk is now known as Ursinha [11:36] hey seb128 - I'm sure you're busy sprinting, but do you think somebody could take a look at https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1318539? attente seems to have ACKed it already, but I personally can't judge if it should be uploaded or not [11:36] Launchpad bug 1318539 in gnome-settings-daemon (Ubuntu) "Vanilla gnome-settings-daemon 3.8" [Undecided,Confirmed] [11:36] dholbach, go for it [11:36] dholbach, it's basically up to the GNOME remix team and it has been acked by attente [11:36] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [11:37] +1 on the principle from me, but I didn't do a detailed review [11:38] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [11:38] seb128, we could probably take a look and see what still depends on gnome-settings-daemon [11:39] seb128, I had to "dpkg -P gnome-settings-daemon gnome-packagekit-session gnome-session ubuntu-system-settings gnome-control-center gnome-packagekit ubuntu-system-settings-online-accounts account-plugin-ubuntuone unity-scope-click" - I probably still had it installed from some older installation === ted is now known as tedg [12:08] pitti: That's fine, the only thing is to please commit the changes to our bzr repo. [12:08] (didn't check if you did already) [12:09] sergiusens, talk to me about factory reset when you get a chance [12:09] sergiusens, on the phone [12:10] mterry__: sure, just come by 2c... I have only one meeting today; everything else is adhoc [12:11] dholbach, sorry, I got disconnected, not sure you got my reply (guess so from your upload) === Mez_ is now known as Mez [12:12] ScottK: ah, will do [12:12] pitti: Thanks. [12:19] slangasek: nexus 5 works [12:19] slangasek: bregma is not online =) [12:30] infinity: argh, I just noticed that I didn't bump the copy limits of eglibc, which explains the timeouts [12:31] pitti: Meh, it'll be "fixed" after I merge from Debian anyway. [12:31] infinity: while I'm at it, if I give the VM 4 CPUs, does the build make use of that? [12:31] pitti: Yeahp, the build will happily eat more cored. [12:31] pitti: cores, too. [12:32] infinity: ack, config pushed (with 4 cores) [12:32] infinity: current build cancelled and restarted, I think/hope it'll succeed now [12:33] argh, I thought we already had an override; for that it held up surprisingly well.. [12:39] ... or I would if jenkins wouldn't be nasty again === _salem is now known as salem_ [12:47] pete-woods: hi! According to https://developer.vimeo.com/api/authentication, it should be possible to find the authorization header on the application webpage [12:47] pete-woods: could you please tell me the code? I'm generating it according to the instructions, but vimeo stills gives me an error, so maybe I'm doing it wrong [12:54] hmm, I'm getting chroot error on amd64, i386 and ppc64el builders: https://launchpadlibrarian.net/176409150/buildlog_ubuntu-utopic-amd64.qtbase-opensource-src_5.3.0%2Bdfsg-2ubuntu1~utopic1~test1_CHROOTWAIT.txt.gz [12:57] jdstrand: the d-bus AppArmor stuff doesn't seem to work in Jenkins builds. Do you have any suggestions on how to handle that? [12:58] jdstrand: allowing everything when the AA check fails would work, but sounds like something that could be used in an exploit. [13:02] jamesh: are they perhaps using the 3.15-ish kernels? [13:03] sarnold: I don't know. [13:04] IIRC, it runs the tests in a chroot so I don't know what the host system is [13:06] pitti: re autopkgtests , what happens if a autopkgtest fails? Does it block package migration from proposed to release? [13:10] jamesh: can you give me more detail on why you think dbus mediation isn't working with jenkins? [13:11] shadeslayer: if it ever succeeded, i. e. it's a regression, then yes [13:11] aha [13:11] shadeslayer: if it always failed, we consider the test broken and ignore it [13:12] cool, thanks [13:12] pitti: Did you forget about the link I posted? [13:12] pitti: and just so I understand correctly, autopkg tests are run separately from the actual build on launchpad correct? [13:12] shadeslayer: yes [13:12] ack, thanks [13:12] GunnarHj: sorry, probably drowned (sprint/discussions here) [13:13] pitti: https://lists.ubuntu.com/archives/ubuntu-translators/2014-May/006512.html [13:13] GunnarHj: yep, got your mail, just didn't find time to respond yet [13:13] pitti: Ok. [13:14] pitti: One thing I wonder about is who is supposed to initiate translation updates. I haven't found any schedule for when things are copied to -proposed for testing. [13:15] tyhicks: https://jenkins.qa.ubuntu.com/job/mediascanner2-utopic-amd64-ci/19/consoleFull <- right at the bottom one of the erros is "Error getting apparmor context: org.freedesktop.DBus.Error.AppArmorSecurityContextUnknown: Could not determine security context for ':1.1'" [13:15] GunnarHj: there's nobody right now; it used to be dpm, but he works on other stuff now [13:15] pitti: Just as I feared, then. [13:15] tyhicks: which is the error I was getting locally with the Utopic kernel (I reverted locally to the trusty kernel at jdstrand's suggestion) [13:29] xnox: Where are you? [13:29] looks like something went kaput https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu4 [13:29] xnox: Making everything in the archive have a versioned upstart dependency seems like exactly the opposite of what we want. [13:30] seems like what I'm facing ^^ [13:30] shadeslayer: Oh, fun. [13:34] xnox: thanks for breaking the archive [13:46] jamesh: I suspect that securityfs is not mounted (or bind mounted) in the chroot [13:47] jamesh: the apparmor dbus mediation sees that and can't determine if it should enforce rules so, by default, it disables the apparmor checks [13:48] (there is an option in the bus config file to not fall open like that, but that's not the issue here...) [13:48] jamesh: the only issue is when you're asking for the apparmor confinement context of a given connection [13:49] jamesh: IMO, it is currently doing the right thing by returning a DBUS_ERROR_APPARMOR_SECURITY_CONTEXT_UNKNOWN error [13:50] jamesh: I think the best fix here would be to get securityfs mounted in the chroot [13:53] infinity: sorry........... =) [13:59] jamesh: but... it is completely possible that the jenkins kernel is the 3.15 utopic kernel that doesn't have the necessary apparmor patches [13:59] jamesh: I just don't know enough about that environment or how to find more info on it [14:01] tyhicks: okay, I'll try following up there. Thanks for the help. [14:01] tyhicks, jamesh: the 3.15 utopic kernel is missing the necessary patches, that will be fixed soon [14:05] xnox: oh, you still want to block sysvinit? kde-workspace went in [14:06] GunnarHj, pitti, exactly. A community member used to help creating the schedule in later times, but he got busy with other stuff too. Here's an example of the release schedule we set up for releases a while ago: https://wiki.ubuntu.com/Translations/NattyLanguagePackReleaseSchedule [14:08] dpm, pitti: Thanks, that's exactly what I had in mind. Would you recommend that we basically copy it for trusty? [14:11] infinity: https://launchpad.net/ubuntu/utopic/+source/systemd/204-10ubuntu5 -> "Broke the world from the new upstart dependency" ? [14:12] infinity: do you have some details on that? I've run this for 2 days now [14:13] or did that interact badly with the dh_installinit upload or something? [14:16] pitti: See the build log for https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu4 for instance. [14:16] What do people use to get the source package name of a binary package? chdist bin2src is crashing on me. [14:16] pitti: Dep loop that triggered an apt bug. [14:16] pitti: But, apt bug notwithstanding, having everything with an upstart job have a dep on upstart is just plain wrong. [14:17] pitti: So, we're moving that lsb init snippet to lsb-base, and moving the dep there instead. [14:17] infinity: ah, perhaps we could turn this into a Breaks: upstart (<<) [14:17] pitti: And rebuilding everything with the upstart dep. [14:17] pitti: We thought about a breaks, but can't quite sort out WHAT would break upstart. [14:17] infinity: ah, even better [14:18] infinity: with breaks: we'd need sourceful changes, so depends: indeed would be better [14:18] infinity: are xnox and you already at it? anything I should do now? [14:18] pitti: stgraber and I are on it. [14:20] pitti: How did you notice the systemd deletion, BTW? :P [14:20] pitti: Oh, I guess you nogticed me copying in the old one. [14:20] infinity: I got a "released to utopic" mail for ubuntu4, and wondered where ubuntu5 went to [14:23] hmm, I thought we were all going to ditch upstart for systemd but now it seems things are going the other way around... [14:23] diwic: how so? [14:23] diwic: it's just a rather long dependency chain [14:24] pitti, you were adding empty upstart scripts and infinity talks about systemd deletion? :-) [14:24] diwic: fixing our packages to comply to Debian init.d/upstart/systemd policy → moving from legacy init.d ordering to insserv → merging sysvinit → adding systemd equivalents to upstart jobs === timrc is now known as timrc-afk [14:24] diwic: ah, I didn't see the implied :) [14:25] it's kind of weird that we have to fix sysvinit first, but overall that's the path of least resistance/work/delta to Debian [14:25] (in fact it's mostly "remove some Ubuntu delta") [14:26] pitti, okay, looks like you have it all under control then ;-) [14:27] kind of, except for details like breaking all builds (thanks infinity for quick action!) [14:27] diwic: so, let's say we know the path now :) [14:27] pitti, all right then :) [14:29] infinity: I suppose we can retry https://launchpad.net/ubuntu/+source/debhelper/9.20140228ubuntu3/+build/6045112 now :) [14:30] so is the brokenness fixed now? [14:30] shadeslayer: AFAICS, yes [14:30] udev | 204-10ubuntu4 | utopic | amd64, arm64, armhf, i386, powerpc, ppc64el [14:30] and nothing in -proposed [14:30] hm [14:30] i. e. the apt dependency loop should be gone [14:31] and debhelper is happily installing its build deps now [14:31] rebuilding kdelibs, lets see [14:31] because it doesn't work locally [14:31] shadeslayer: wait [14:31] oh [14:31] https://launchpadlibrarian.net/176413792/buildlog_ubuntu-utopic-i386.debhelper_9.20140228ubuntu3_CHROOTWAIT.txt.gz still failed, hmm [14:32] pitti: http://paste.ubuntu.com/7529745/ [14:32] GunnarHj, sorry for the delay. I'd say yes, but let me find you a more recent template than the one for natty [14:32] Unpacking udev (204-10ubuntu5) over (204-10ubuntu1) ... [14:33] shadeslayer: ^ your build log still has the ubuntu5 version which infinity removed [14:33] pitti: yeah, trying to figure out why [14:33] shadeslayer: probably just mirror lag; the LP buildds use ftpmaster.internal [14:33] yeah [14:33] pitti: https://launchpadlibrarian.net/176413830/buildlog_ubuntu-utopic-amd64.kde4libs_4%3A4.13.0-0ubuntu4_CHROOTWAIT.txt.gz < plymouth issue [14:33] yes, same as debhelper [14:34] yep [14:34] GunnarHj, here's the raring one: https://wiki.ubuntu.com/Translations/RaringRingtail/ReleaseSchedule [14:35] dpm: It says raring in the URL, but it's actually precise. ;) === tedg is now known as ted [14:36] probably this: [14:36] initscripts depends on upstart (>= 1.12.1-0ubuntu6); however: [14:36] Package upstart is not configured yet. [14:36] GunnarHj, I guess it was copied from Precise and we never actually used that one :) [14:36] thus we need to rebuild the latest sysvinit upload against the reverted debhelper, and need the rebuilt sysvinit to build debhelper; yay loops [14:37] dpm: I see. So there hasn't been any systematic translation updates since 12.04? [14:40] GunnarHj, most probably no. I know we've done some updates, but as you're saying, not systematically [14:40] dpm: Ok. Anyway, thanks for the link. I'll make a proposal for trusty based on it. [14:41] GunnarHj, sounds great, thanks! === salem_ is now known as _salem [14:42] pitti: hah :D [14:43] pitti: sysvinit must depend on new upstart though.... [14:43] pitti: if that's bad, we'd need to move the hook elsewhere. [14:43] pitti: sysvinit is currently blocked from migrating. [14:43] xnox: the hook is being moved to lsb-base AFAIUI [14:43] xnox: hm, it did migrate already [14:43] I can't reproduce the upgrade failure in a schroot [14:44] I got this while accessing errors.ubuntu.com for a little while http://pastebin.com/2s4ud5rk as an error message, it look as a hack, might not be the brightest idea ever [14:44] pitti: ok, i hread that mentioned, but it was not definitive at the time, i don't think. [14:44] slangasek: infinity: stgraber: what's the current plan for unbreaking & steps that we need to do to land insserv? [14:45] pitti: cause e.g. adding in sysv-rc breaks upstart << (version with hook) was also offered. [14:45] which shouldn't have any side-effects if upstart is not installed to begin with, and triggers the update otherwise. [14:46] infinity, stgraber, xnox: so I'm trying to understand the current failure, did you already reproduce this somehow? [14:46] [-upstart,-] {+upstart (>= 1.12.1-0ubuntu6),+} [14:46]