=== _salem is now known as salem_
=== salem_ is now known as _salem
[01:55] <kirkland> so unity --reset is deprecated as is ctrl-alt-backspace;  so how do I unfsck unity when it's fscked?
[06:44] <Mirv> is anyone else seeing what camako is seeing at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-017/+packages - that the publisher run(s) seems broken?
[06:44] <pitti> Good morning
[06:46] <pitti> tedg, didrocks: FTR, sessions are running in a cgroup writable (i. e. "subgroupable") to the user, so in principle session upstart or UAL or whatever could do this by itself
[06:46] <pitti> once we move the session to systemd-user as well, this will be moot of course
[06:46] <didrocks> good morning pitti!
[06:47] <Mirv> good morning pitti, didrocks
[06:47] <pitti> hey didrocks, hello Mirv
[06:47] <didrocks> hey Mirv!
[06:50] <pitti> didrocks, tedg: btw, in principle cgmangager does run under systemd, they are just potentially clashing by doing things differently
[06:50] <pitti> but we'll need it for the "fake" cgroup fs for session LXC in any case
[06:51] <didrocks> ah, so it's not an orthogonal discussion
[07:20] <pitti> Riddell: FYI, yesterday's KDE uploads are mostly stuck on uninstallability on i386: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[07:20] <pitti> (email notifications still don't work, arhg)
[07:21] <pitti> Riddell: perhaps related to the depwait of https://launchpad.net/ubuntu/+source/plasma-framework/5.6.0-0ubuntu1
[07:55] <pitti> Riddell: ah, it got retried three times yesterday, but now it works again, so I guess some archive admin did whatever was necessary
[07:57] <sitter> wgrant, cjwatson: as observed by Mirv, launchpad publisher seems to have severe problems .... e.g. https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable/+sourcepub/4653416/+listing-archive-extra <= built 7 hours ago, still pending publication
[08:03] <dholbach> good morning
[08:04]  * Mirv filed RT ticket about publisher
[08:16] <wgrant> Looking.
[08:18] <seb128> hey there
[08:18] <seb128> is anybody else having issue booting with yesterday's kernel update?
[08:19] <seb128> I see the plymouth logo and screen empty screen
[08:19] <seb128> boots fine if use recovery or boot an old kernel
[08:19] <seb128> that's on a dell e6410 i5 with intel video
[08:20] <pitti> I haven't rebooted yet after dist-upgrade, will try
[08:43] <stevenm> Hey anyone about?  I'm trying to figure out a bug with the packaging of libqt5core5
[08:45] <seb128> apw, ^ do you know about my kernel issue maybe?
=== ara is now known as Guest15321
=== dholbach_ is now known as dholbach
[09:19] <Mirv> I seem to be running the latest kernel, no problems. i5-2557m era machine.
=== rcj is now known as Guest49344
=== lionel_ is now known as lionel
=== vrruiz_ is now known as rvr
[10:57] <cjwatson> sitter: That's published now.
[11:22] <Laney> Need help analysing this: https://jenkins.qa.ubuntu.com/job/vivid-adt-floodlight/lastBuild/ARCH=amd64,label=adt/console
[11:22] <Laney> The problem is that the java alternates aren't in place when the floodlight job is started
[11:23] <Laney> But AFAICS they should be, because floodlight Depends: default-jre-headless, which Depends: openjdk-7-jre-headless, but that is configured after default-jre-headless is, as you can see in the log.
[11:26] <svenx> starting around Trusty, i386 is not added as a multiarch on amd64 systems by default. it definitely was on Precise. What's the rationale, if any?
[11:28] <cjwatson> svenx: It's still supposed to be enabled.  Perhaps you aren't installing via a standard method?
[11:28] <svenx> cjwatson: i'm using debootstrap, indeed
[11:29] <svenx> perhaps the mechanism to enable it was moved
[11:29] <svenx> for example if the package 'multiarch-support' made the modifications before, but not any longer
[11:29] <cjwatson> No.
[11:29] <cjwatson> dpkg used to force it in a different way.
[11:29] <svenx> aha
[11:29] <cjwatson> But the whole multiarch config mechanism changed in precise.
[11:30] <cjwatson>         if dpkg --compare-versions "$2" lt 1.16.0.3ubuntu4; then
[11:30] <cjwatson>             new_installs_multiarch
[11:30] <cjwatson>         fi
[11:30] <svenx> this could explain it.
[11:30] <cjwatson> infinity: ^- I suspect this doesn't work right with debootstrap, perhaps, because it's extracted the first time through and the status file faked up.  I think.
[11:30] <cjwatson> Anyway, debootstrapped installs aren't guaranteed to have the fully standard config in all ways.
[11:31] <cjwatson> s/changed in precise/changed in quantal/ above
[11:31] <svenx> that's okay. i was merely digging into the details to figure out the difference in behaviour, so i can document it in the configuration for my FAI-based installer
[11:32] <svenx> thanks for the quick pointer
[11:32] <cjwatson> No problem.  I think this is probably a slight bug.
=== _salem is now known as salem_
[12:07] <Laney> well then
[12:07] <Laney> Seems to be a bug in dpkg
=== MacSlow is now known as MacSlow|lunch
[12:35] <syockit> Referring to http://packaging.ubuntu.com/html/security-and-stable-release-updates.html#stable-release-updates, it says that "We also allow updates … such as a severe regression … or a bug which could cause data loss."
[12:38] <syockit> Does this mean paper cuts like LP #1322925 are likely to not be accepted for an "updates" channel release?
[12:38] <ubottu> Launchpad bug 1322925 in nautilus (Ubuntu) "Copy, paste stops working randomly in Ubuntu 14.04 nautilus" [Undecided,Confirmed] https://launchpad.net/bugs/1322925
[12:48] <rbasak> syockit: given how many are affected by the bug, an SRU for that may be reasonable. I can't speak for the SRU team though.
[12:48] <rbasak> It also depends on the fix, since that affects regression risk.
[12:49] <rbasak> syockit: I wouldn't rule it out for an SRU, anyway.
[12:49] <rbasak> syockit: see https://wiki.ubuntu.com/StableReleaseUpdates if you haven't read that page.
[12:54] <syockit> rbasak: I haven't. Thanks for the link!
[12:55] <syockit> What's the channel for SRU discussion?
[12:56] <rbasak> syockit: here and #ubuntu-release are both appropriate.
=== MacSlow|lunch is now known as MacSlow
=== oSoMoN_ is now known as oSoMoN
[14:05] <pitti> stgraber: wrt. "bond/vlan/bridges interfaces do not work because they're fully virtual and do not have udev events" -- do you have some details about those?
[14:05] <pitti> stgraber: we call ifup -a, so I assume it's more complicated than just putting those into /etc/network/interfaces
=== Guest49344 is now known as rcj
=== rcj is now known as Guest58831
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
[16:30] <pitti> infinity, smoser: does wolfe need to be powered back on after the move or so? allegedly IPs didn't change
[16:31] <smoser> let me chekc
[16:33] <aquarius> stgraber, ping if you're around about unprivileged lxc failing to attach
[16:34] <smoser> pitti, i think you're up now
[16:34] <stgraber> aquarius: hi. I'm around though mostly stuck in meetings today. What kernel, LXC and what kind of error are you getting?
[16:35] <pitti> smoser: yay, all except wolfe-06
[16:36] <smoser> wolfe-06 thinks its up
[16:37] <aquarius> stgraber, Ubuntu 14.04 amd64 3.13.0-43-generic. lxc-start works and gives a login prompt, but I can't log in because I've set no user. lxc-attach fails with: lxc_container: call to cgmanager_move_pid_abs_sync failed: invalid request  // lxc_container: Failed to enter group /aquarius/rnr  //  lxc_container: error communicating with child process
[16:37] <aquarius> stgraber, lxc-start --version says 1.0.6.
[16:37] <pitti> ssh_exchange_identification: Connection closed by remote host
[16:38] <pitti> smoser: ^ hmm, no luck here
[16:38] <smoser> rebooted him
[16:40] <pitti> smoser: thanks for prodding, works now!
[16:40] <rbasak> pitti: is it Testsuite: autopkgtest now? No XS- any more?
[16:40] <smoser> i had fat-fingered' the bringup of 07
[16:40] <pitti> rbasak: right; XS- still works of course, but it's an official field
[16:40] <smoser> and that resulted in 06's tun device getting whacked
[16:41] <pitti> rbasak: moreover, you don't need to explicitly set it at all
[16:41] <pitti> rbasak: if there's a debian/tests/control, dpkg-source will add it automatically
[16:41] <rbasak> pitti: great, thanks. So is that best practice now? Not setting it at all?
[16:41] <rbasak> pitti: what about backports to Trusty?
[16:42] <rbasak> I'm still using dpkg-source on Trusty, so I guess I'll leave it XS- for now.
=== Guest74344 is now known as iulian
[16:44] <rbasak> pitti: one more question. I'm writing a test that needs "sudo" to work. So not quite needs-root, but almost. Will this work in the current environment (Ubuntu-only)? If not, I presume I need to write a wrapper and use needs-root?
[16:44] <rbasak> pitti: this is isolation-machine as it will create LXC containers.
[16:46] <stgraber> aquarius: hmm, sounds like a bug that we had a while back but I thought hallyn resolved that
[16:48] <hallyn> aquarius: what is /proc/self/cgroup before you do lxc-attach?
[16:48] <hallyn> say, is there a way to add comments to reports on errors.ubuntu.com?
[16:49] <aquarius> hallyn, http://pastebin.ubuntu.com/9693666/ -- it did at one point not have my username in it but I fixed that after reading a github issue report
[16:49] <hallyn> (https://errors.ubuntu.com/problem/9d8b1bc865eba0604b89ca1f7a24f0a1a0186290 should be fixed in 0.34)
[16:49] <didrocks> jpds: hey, any reason apart from "nobody got the time for this" for strongswan to not having been merged with debian and moved to 5.2.1? I see we diverged a long time ago from debian (dec 2013) and I was thinking merging back to bring the systemd service as part of this
[16:50] <pitti> rbasak: ah, for backports you have to use XS-* still, if you actually care for having the tag there
[16:50] <pitti> rbasak: back in 30 mins, sorry
[16:50] <hallyn> aquarius: you did an unprivileged container, or privileged?  Can you pastebin the full set of commands?
[16:50] <stgraber> aquarius: how are you logging into that system? cgmanager combined with systemd-logind on 14.04 should set everything up for you
[16:51] <hallyn> stgraber: yes, but in 14.04 you have to restart systemd-logind after installing cgmanager and the nlog back in
[16:51] <stgraber> aquarius: and if you just installed LXC, you need to completely logout and login again (or better, reboot) to have it properly setup
[16:51] <stgraber> hallyn: right, was getting there :)
[16:51] <aquarius> hallyn, unprivileged container. stgraber, erm, I don't understand the question about how I log in; it's a desktop Ubuntu machine so I log in with lightdm, presumavly.
[16:51] <hallyn> stgraber: :)
[16:51] <aquarius> Oh! I have to log out and in?
[16:51] <aquarius> right, that'll be the problem then :)
[16:51] <stgraber> if you just installed LXC, reboot and try again, that should make systemd-logind less stupid
[16:52] <hallyn> i cringe at 'reboot' :)
[16:52] <aquarius> right, fantastic, I'll do that next time I don't have anything I need open :)
[16:52] <hallyn> aquarius: you can do it manually,
[16:52] <hallyn> 'sudo restart systemd-logind', then ssh localhost and work from the ssh shell
[16:53] <stgraber> hallyn: yeah, I don't like it either but that's what I put in my blog posts because well, that's foolproof :)
[16:53] <hallyn> true
[16:53] <aquarius> hallyn, restarted systemd-logind; sshed localhost; lxc-attach -n rnr; same error that I got before
[16:54] <jpds> didrocks: Mostly time, and I'm still thinking about how all the plugins should be handled in future.
[16:55] <hallyn> aquarius: is /proc/self/cgroup still showing / for most controllers?
[16:55] <aquarius> hallyn, nope; it now has /user/1000.user/1.session for all of them
[16:56] <jpds> didrocks: I play to revamp it all soon.
[16:56] <didrocks> jpds: do we have a huge diff? Maybe I should just try to insert 5.2.0-2 for not diverging on the system service if you think it's safer (I'm not really sure how to test it)
[16:56] <jpds> didrocks: Huge diff.
[16:56] <didrocks> jpds: ah ok, so better for me to only stick in 5.2.0-2 meanwhile
[16:56] <didrocks> thanks for your feedback, doing that!
[16:59] <hallyn> aquarius: and you stopped and restarted the container?
[17:00] <aquarius> hallyn, I hadn't, hang on
[17:00] <aquarius> ahaha!
[17:01] <aquarius> I have to start it in the ssh session. And now it works. hallyn, you rock.
[17:01] <aquarius> I'll reboot at some point.
[17:01] <aquarius> superb.
[17:02] <hallyn> aquarius: great.  wish that hadn't been necessary, but later releases do fix it (or at least aresupposed to) - ttyl
[17:08] <rbasak> stgraber, hallyn: lxc-templates only recommends cloud-image-utils, so the ubuntu-cloud template doesn't work out of the box with --no-install-recommends. Do you consider this expected behaviour, or should it be a hard dependency?
[17:08] <rbasak> (if it's expected, then I need juju-local to depend on cloud-image-utils I guess)
[17:09] <stgraber> rbasak: looking at the other Recommends, I think that's expected and fine, assuming that the template in question gives you a clear error message in that case
[17:09] <hallyn> yeah, that's basically what '--no-install-recommends' means...
[17:10] <rbasak> stgraber: the error tells me that ubuntu-cloudimg-query doesn't exist, which was good enough for me. OK - I'll add it to juju-local - thanks.
[17:10] <hallyn> and yeah if error msg isn't clear then we need to fix that
[17:11] <hallyn> ok
[17:17] <infinity> cjwatson: I'd be inclined to consider that a bug in how debootstrap works if it can't guarantee that maintscript snippets with a null comparison don't trigger.
[17:18] <infinity> cjwatson: But maybe it's a bug for essential packages to have such a condition.  Could go either way.
[17:19] <cjwatson> Hard to say
[17:20] <infinity> cjwatson: Although, there's got to be more to this than just debootatrap sucking.
[17:20] <infinity> cjwatson: Cause debootstrap is how we install our livefses, and they're configured right.
[17:21] <infinity> cjwatson: Unless they really aren't, and ubiquity/d-i are fixing it.
[17:21]  * infinity grabs an ISO.
=== roadmr is now known as roadmr_afk
[17:24] <pitti> rbasak: if you only care about our ubuntu CI ones, they can use (passwordless) sudo
[17:25] <pitti> rbasak: it would be nice if the test would skip itself if "sudo -n true" fails, instead of hanging forever
[17:25] <pitti> rbasak: I mean images run on the standard adt-release-arch-cloud.img QEMU ones
[17:29] <rbasak> pitti: OK, thanks. I can test with "sudo -n true" easily enough. Is there an exit status code for a test skip?
[17:31] <pitti> rbasak: no, just echo an appropriate message and exit 0
[17:31] <pitti> rbasak: tests skipped due to unsatisfiable restrictions have a particular code, but that's one level down; once your test runs, it must succeed
[17:32] <pitti> rbasak: it's not that important anyway, mostly for manual runs on arbitrary targets
[17:32] <pitti> rbasak: in our CI, QEMU should work and LXC (armhf, ppc64el) will skip the test due to isolation-machine
[17:34] <rbasak> pitti: I don't like to exit 0 here. Then if I've made a mistake, my problem will silently succeed. Can I exit 1 instead?
[17:35] <pitti> rbasak: sure; cf. the above "not that important'
[17:35] <rbasak> OK
[17:35] <rbasak> Thanks for your help.
[17:35] <pitti> rbasak: just print something sensible like "this test needs passwordless sudo to be available"
[17:35] <pitti> ?
[17:35] <rbasak> ack
[17:35] <pitti> rbasak: ok, great
[17:41] <cjwatson> infinity: apt-setup fixes it
[17:41] <cjwatson> infinity: (and should continue to do so, since it has configuration knobs for this)
[17:41] <infinity> cjwatson: Indeed, `dpkg --print-foreign-architectures` in a trusty squashfs returns nothing.
[17:41] <infinity> cjwatson: I wonder how noboy noticed or cared before.
[17:41] <infinity> nobody, too.
[17:43] <infinity> cjwatson: Given that we no longer care about that upgrade path, I wonder if it wouldn't be best to just remove that block entirely from our dpkg delta now, and say (rightly, IMO) that setting up extra arches is up to the installer.
[17:44] <infinity> cjwatson: All our installers must DTRT here anyway, since it's obvious that debootstrap alone doesn't. :P
=== charles_ is now known as charles
=== roadmr_afk is now known as roadmr
[17:59] <cjwatson> infinity: Yeah, I don't mind hugely
[18:06] <staylor> Wanted to clarify that if I follow the method defined at https://wiki.ubuntu.com/KernelTeam/GitKernelBuild for generating kernel deb packages that these will work fine for distribution using apt-get for various boards?
[18:22] <infinity> cjwatson: Excellent.  Always good to have concensus from Launchpad people.
[18:22] <infinity> cjwatson: PS: traitor.
[18:29] <infinity> staylor: Should do, just remember to also distribute the source packages that match, for legal reasons.
[18:30] <infinity> staylor: Also, if you're not altering the upstream source, but rather just adding CONFIG options to enable new boards for the -generic kernel, it might be nice to file bugs to get that fixed in the Ubuntu kernel, rather than distributing your own fork.
[18:38] <staylor> infinity: it's a separate fork from what's in Ubuntu, basically our fork of the Freescale fork for i.MX6 ARM support.  A bit of a mess thanks to Freescale ;-)
[18:39] <staylor> infinity: so what I'm hoping to do is distribute our kernel deb packages in a way that most closely resembles the way Ubuntu does it, linux-image, linux-headers, etc, along with modules and of course the source package.
[18:39] <infinity> staylor: Hrm.  Kay.  The Ubuntu kernel is known to work on at least some i.MX6 devices, so I'd be curious what we (and upstream) are missing.
[18:40] <staylor> infinity: though the Ubuntu kernel works on i.MX6 to get the GPU binary blob drivers working correctly we need to use the Freescale kernel unfortunately.
[18:40] <infinity> staylor: Oh, right.  Yay blobs. :(
[18:41] <infinity> staylor: In that case, I would make sure that your forked kernel package is also a different flavour, since you might be maintaining it for a while and don't want upgrade hassles.
[18:42] <infinity> staylor: ie: instead of linux-image-generic, it should be linux-image-imx6-nonfree or something, so it's (a) obvious what it's for, and (b) won't confuse apt and users if we release a newer version of -generic that threatens to upgrade.
[18:42] <staylor> infinity: yes, I think that's the part that I'm missing as I'm not really clear on these details.  Ubuntu support is newer to us we've in the past just used very specific "distros" and yocto.
[18:42] <infinity> staylor: Not sure how well the kernel team has out-of-tree flavours documented, but if you ask apw nicely, he can talk you through it.
[18:43] <infinity> apw: ^--- If you're feeling helpful.
[18:43] <staylor> infinity: so I could define say linux-image-companyname-imx6 for example?
[18:43] <infinity> staylor: Yeah.
[18:44] <infinity> staylor: Like in trusty, you'll see that we have -generic and -generic-lpae from the mainline "linux" source, but we also have -keystone from an out-of-tree build, for a specific system that isn't entirely upstreamed.
[18:44] <infinity> staylor: Ideally, you'd want to maintain your stuff the same way that keystone kernel is.
[18:45] <staylor> infinity: yeah, that's sort of what I was originally thinking but pulling the apt-source of the kernel packages seems to be very different from other "standard" packages so I'm curious the correct way to build my own effectively.
[18:47] <apw> staylor, yeah waht keystone or lowlatency are doing are pretty good delta kernels which can be soimply rebased on to each release the main kernel takes
[18:47] <apw> rather than trying to understand the packaging to much, looking at the debdiff from the main kernel to one of those
[18:47] <infinity> staylor: To be fair, for one-off builds, pretty much anything works, but if you want to actually rebase with our kernel updates and keep your kernel maintainable and supportable in some fashion, doing it the way keystone is done will help you a lot.
[18:48] <apw> concur
[18:48] <apw> staylor, feel free to bring questions to #ubuntu-kernel
[18:49] <staylor> alright thanks I'll take a look at that, we'll be tracking Freescale's linux-imx git going forward with this package as well as our additional patches for drivers specific to this processor so we'd be maintaining it (as we do today for our yocto based BSP).
[18:49] <cjwatson> infinity: you're welcome ;-)
[19:26] <bdmurray> tkamppeter: the fix for bug 1400232 was included in your upload to Utopic, but not to Trusty. Was this an accident?
[19:26] <ubottu> bug 1400232 in system-config-printer (Ubuntu Trusty) "system-config-printer crash UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 1441: invalid continuation byte (only UTF-8-encoded PPD files can be used)" [Undecided,In progress] https://launchpad.net/bugs/1400232
[19:30] <bdmurray> tjaalton: could you respond to the comment in bug 1401788 regarding the SRU of xserver-xorg-video-intel?
[19:30] <ubottu> bug 1401788 in xserver-xorg-video-intel (Ubuntu Utopic) "backport BDW/CHV sna BLT fix" [Undecided,New] https://launchpad.net/bugs/1401788
=== salem_ is now known as _salem
[19:42] <tjaalton> bdmurray: hmm yeah I forgot to add the header before holidays..
[19:43] <tjaalton> I'll add it tomorrow
[19:43] <bdmurray> tjaalton: alright, thanks
=== roadmr is now known as roadmr_afk
[20:16] <tkamppeter> bdmurray, seems that I have simply forgotten it in the package uploaded to trusty-proposed.  Can you reject the uploaded package and I will upload a new one with the patch added. Thanks.
[20:19] <bdmurray> tkamppeter: rejected, let me know when the new one is ready for review.
[20:42] <tkamppeter> bdmurray, new package uploaded.
=== roadmr_afk is now known as roadmr
=== _salem is now known as salem_
=== Guest58831 is now known as rcj
=== rcj is now known as Guest69248
=== salem_ is now known as _salem
=== Elimin8r is now known as Elimin8er
[21:47] <chiluk> lamont, I'm looking at bug 583216 and noticed that there wasn't a track for trusty... do you intend to upload the fix into trusty as well?
[21:47] <ubottu> bug 583216 in postfix (Ubuntu) "inet_protocols can't be preseeded" [Medium,In progress] https://launchpad.net/bugs/583216
[21:53] <lamont> chiluk: I might be talked into that
[21:54] <lamont> chiluk: tell you what.  I'll upload it to trusty-proposed, you deal with the SRU?
[21:57] <chiluk> lamont the SRU template is already kinda -filled out.
[21:57] <chiluk> I can clean it up though.
[21:57] <chiluk> and twist arges' arm to push the SRU button.
[21:59] <lamont> I guess this means I'll have to do the uploads this weekend, he/
[21:59] <lamont> eh?
[22:05] <chiluk> lamont yeah probably.
[22:05] <chiluk> lamont if you don't have time I can push it through the process