[05:08] <DerRaiden> morning/morgen
[06:11] <pitti> Good morning
[07:05] <twb> Dumb question: is it normal for EOLd packages to still have .dscs linked from packages.u.c ?  Because http://packages.ubuntu.com/lucid/cups links to http://archive.ubuntu.com/ubuntu/pool/main/c/cups/cups_1.4.3-1ubuntu1.14.dsc but the files *that* references are 404d (presumably because they're moved to the EOL server)
[07:05] <twb> oh wait, I misread the error message
[07:06] <twb> Ignore me, I'm just an idiot.
[07:13] <jibel> pitti, where are the logs now with systemd? it used to be in /var/log/upstart/ is everything in syslog? I'm searching why whoopsie doesn't upload crash files on vivid
[07:13] <pitti> jibel: it should be in syslog too, but everything goes into the journal
[07:14] <pitti> jibel: "journalctl" -> everything; "journalctl -u whoopsie" -> everything from whoopsie
[07:14] <jibel> pitti, thanks. I'll check that.
[07:14] <pitti> (there's lots of more filters, but those are probably the two most common ones)
[07:14] <pitti> jibel: so journalctl -u <servicename> is the direct equivalent of /var/log/upstart/<servicename>
[07:20] <jibel> Cannot reach: https://daisy.ubuntu.com is a good reason to not upload crash files :/
[07:31] <dholbach> good morning
[08:31] <pitti> cjwatson: do you want a Debian bug for bug 1440070 / the patch in http://launchpadlibrarian.net/202605250/openssh_1%3A6.7p1-5_1%3A6.7p1-5ubuntu1.diff.gz ?
[08:58] <cjwatson> pitti: Yes please
[08:58] <cjwatson> pitti: Or I can give you git commit access if you like
[08:59] <pitti> cjwatson: I'll file a bug then
[09:09] <LocutusOfBorg1> Does anybody know how to contact Chris Arges?
[09:09] <LocutusOfBorg1> about bug 1129409
[09:10] <LocutusOfBorg1> seems he didn't upload the utopic fix :(
[09:38] <pitti> infinity: FYI: https://tracker.debian.org/news/676575
[10:44] <Riddell> tseliot: sddm today should make the /etc/X11/default-display-manager file
[10:46] <tseliot> Riddell: ok, will it also come with an entry in sddm.conf?
[10:47] <Riddell> tseliot: it'll use the default which points to the Xsetup script which does run /sbin/prime-offload
[10:48] <tseliot> Riddell: ok, that would work. I'll push my change for gpu-manager in ubuntu-drivers-common, so that it doesn't abort when it finds sddm
[10:49] <Riddell> tseliot: lovely :)
[10:55] <tseliot> Riddell: done
[10:55] <Riddell> tseliot: awooga, thanks for your help
[10:56] <infinity> pitti: Excellent, now it just needs an unblock?
[10:56] <tseliot> Riddell: you're welcome. If they ever add support for restarting X on log out, I'll be glad to complete support for hybrid graphics in sddm
[10:57] <pitti> infinity: yes; I'd like to keep this in unstable for two days or so to get some field testing, so I was going to file the request on Sat
[11:01] <infinity> pitti: Fair enough.  Since I uploaded sysvinit with a medium urgency, I figured that would take care of me anyway and filed the unblock with the upload.  That's 5 days for someone to file an RC bug and keep it out.
[11:01] <infinity> pitti: And, indeed, you were a medium too, so...
[11:14] <tjaalton> LocutusOfBorg1: that would be tseliot then, who packaged them
[11:16] <tseliot> LocutusOfBorg1: I haven't backported the fix to utopic. It's only in trusty and in vivid for now
[11:34] <LocutusOfBorg1> tseliot, I provided the debdiff in the bug
[11:34] <LocutusOfBorg1> the fix is trivial
[11:39] <tseliot> LocutusOfBorg1: right. I can upload that later
[11:49] <LocutusOfBorg1> thanks
[12:07] <shadeslayer> mvo: poke
[12:07] <shadeslayer> mvo: Kubuntu core ?
[12:09] <flexiondotorg> If there is someone piloting would they be good enough to look at the following please?
[12:09] <flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1439388
[12:10] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1439380
[12:10] <flexiondotorg> They are updated translations and bugs fix. I think today is the deadline for translations.
[12:16] <Odd_Bloke> mvo: Thanks for the merge!
[12:42] <ginggs> hi, anyone one in ubuntu-archive able to look at LP: #1432576 please?
[13:01] <cjwatson> ginggs: done
[13:02] <ginggs> cjwatson: thanks!
[13:39] <flexiondotorg> Is there someone scheduled to pilot today?
[13:42] <seb128> flexiondotorg, mvo and cjwatson
[13:42] <flexiondotorg> seb128, Thanks.
[13:43] <flexiondotorg> mvo, cjwatson When you're piloting I have some stuff that I think is time critical for today.
[13:43] <cjwatson> I'm unlikely to do it today, sorry.  Doesn't fit very well into my LP work
[13:44] <cjwatson> Trying to follow a long chain of stuff for new-style ddebs right now
[13:44] <flexiondotorg> cjwatson, OK. Understood :)
[14:00] <caribou> Any trick to investigate build failures caused by dependancies not being installed ?
[14:00] <caribou> The Build-Depends-Indep: dblatex is correctly installed when I build with sbuild, but PPA builder doesn't want to include itg
[14:00] <caribou> s/itg/it
[14:01] <caribou> (on precise btw)
[14:05] <geser> have you a link to a build log?
[14:08] <caribou> geser: https://launchpadlibrarian.net/202635957/buildlog_ubuntu-precise-amd64.openafs_1.6.7-1ubuntu1.12.04.1_BUILDING.txt.gz
[14:11] <caribou> geser: doesn't seem to install the Build-Depends-Indep
[14:11] <caribou> geser: dkms & the other are not there either
[14:16] <geser> caribou: but only for amd64, the build succeeded for i386
[14:17] <geser> the amd64 build should only build arch-dep packages (indep is build by i386) and shouldn't need  B-D-I in the first place
[14:17] <infinity> caribou: B-D-I is only installed when building arch:all packages.
[14:18] <infinity> caribou: For local tests, that's "dpkg-buildpackage -B" versus "dpkg-buildpackage -b"
[14:18] <cjwatson> Or sbuild --no-arch-all vs. -A
[14:21] <caribou> cjwatson: -A is the answer, I got into the habit of *always* using this switch
[14:21] <caribou> geser: infinity: thanks for the info
[14:23] <infinity> caribou: Yeah, you should generally test once with -A, once without, if you're paranoid about getting it right.
[14:24] <caribou> infinity: well, in that case, I'm paranoid about asking stoopid questions :-)
[14:26] <LocutusOfBorg1> doko, hi, you there?
[14:26] <LocutusOfBorg1> talking about the virtualbox gcc-5 build failure
[14:26] <LocutusOfBorg1> I got the regression fixed tonight (I'm still testing the fix)
[14:27] <LocutusOfBorg1> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693
[14:27] <LocutusOfBorg1> do you think you can include in your next upload? do you fetch from trunk, right?
[14:39] <LocutusOfBorg1> I'm building it locally ATM, not sure if I did everything correctly :)
[14:43] <doko> LocutusOfBorg1, sure, but not this week
[14:46] <LocutusOfBorg1> no problem, thanks!
[14:47] <LocutusOfBorg1> the question was "do you fetch from trunk?" I'm wondering if they branched gcc-5 somewhere, and I don't want to look at svn jungle :)
[14:50] <flexiondotorg> mvo, Please can you let me know when are you scheduled to pilot?
[14:51] <infinity> doko: Is cgo disabled on powerpc intentionally, or is that an oops?
[14:51] <Riddell> tseliot: david from sddm says they do restart X, pier says they do not but david says pier is wrong
[14:51] <Riddell> sounds like a difficult topic :)
[14:52] <ogra_> lol
[14:57] <tseliot> Riddell: all I know is that XorgDisplayServer::stop() is not being called on log out, or I would see "Display server stopping..." in the log
[14:57] <tseliot> Riddell: that's only called on shutdown, at least this is what I saw in my tests
[15:01] <tseliot> Riddell: they stop X when they stop the greeter (in Display::stop() )
[15:01] <mvo> flexiondotorg: what can I do for you?
[15:02] <Riddell> tseliot: but not on logout?
[15:02] <flexiondotorg> mvo, Hi :)
[15:02] <flexiondotorg> mvo, Some sponsoring for Ubuntu MATE if possible. Got the time?
[15:03] <mvo> flexiondotorg: I can squeeze it in, can you point me to the branches please?
[15:03] <flexiondotorg> mvo, https://bugs.launchpad.net/ubuntu-mate/+bug/1439388
[15:03] <flexiondotorg> mvo, https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1439380
[15:04] <flexiondotorg> mvo, https://bugs.launchpad.net/bugs/1441030
[15:06] <tseliot> Riddell: all I see is the Display::login() function, I really can't find the relevant logout function anywhere in the code
[15:13] <tseliot> Riddell: so, either they have a hidden log out function that I can't find, or they simply stop X when they destroy the greeter object which, in turn, tells X to stop. It would help if somebody from sddm could confirm either theory
[15:17] <hallyn> stgraber: https://bugs.launchpad.net/bugs/1392176
[15:18] <hallyn> odd thought that having kernel fix it would be uglier hack than quickly writing a hotplug listening daemon
[15:25] <rbasak> Anyone have issues with Alt+<number> being swallowed since an upgrade to Vivid?
[15:26] <rbasak> Anyone have issues with Alt+<number> being swallowed since an upgrade to Vivid? Esc <number> works but makes irssi pretty frustrating to use.
[15:28] <Laney> rbasak: Check the "Switch to tab" keybindings in the preferences
[15:28] <Riddell> tseliot: (alberto) meet sddm's d_ed (david)
[15:28] <tseliot> hi d_ed
[15:29] <infinity> rbasak: Terminal -> Preferences -> Shortcuts, to be exact.
[15:29] <infinity> And I agree that eating Alt-anything is a dumb default. :/
[15:30] <rbasak> Laney, infinity: that worked. Thanks!
[15:30] <d_ed> tseliot: hey, my laptop died last week, so I don't have SDDM code at the moment. Cloning and looking now
[15:31] <tseliot> d_ed: thanks. I was wondering what happens on log out and where the relevant code is, since I can't find a logout function, only login()
[15:31] <d_ed> tseliot: so I can catch up, why should we be restarting X on logout?
[15:32] <d_ed> yeah, logout is when the user session closes
[15:33] <tseliot> d_ed: the thing is that, when switching between GPUs (hybrid graphics), we also need to switch to different libraries, and restart X to either enable or disable the discrete card, or X won't like it
[15:33] <d_ed> m_auth is used to wrap both the greeter and the session environment
[15:35] <d_ed> sorry, m_auth only wraps the session
[15:35] <tseliot> d_ed: so what currently happens is that X is stopped only on shutdown (i.e. when the greeter stops), not on log out
[15:36] <mvo> flexiondotorg: I uploaded both, thanks
[15:36] <d_ed> yeah, there's a code comment here that makes no sense; we restart X depending on the return code of the session we started
[15:36] <flexiondotorg> mvo, I just saw mate-menu and mate-control-center in #ubuntu-release. Many thanks!
[15:37] <flexiondotorg> mvo, Anytime to look at mate-tweak too? - https://bugs.launchpad.net/ubuntu-mate/+bug/1439388
[15:37] <tseliot> d_ed: where is that?
[15:39] <mvo> flexiondotorg: sure, one sec
[15:39] <flexiondotorg> mvo, Thank you :)
[15:42] <d_ed> tseliot: Display::slotHelperFinished
[15:42] <d_ed> this is called when the user session finishes
[15:42] <d_ed> yet the comments don't reflect that
[15:51] <infinity> doko: Nevermind my cgo question, was a gccgo-go thing.  Oops.
[15:53] <tseliot> d_ed: so slotHelperFinished() is called when m_auth emits the finished signal i.e. when m_auth exits. Does m_auth exit on log out?
[15:57] <d_ed> yes
[16:22] <tseliot> d_ed: I don't see anything other than a black screen and a mouse pointer when I log out. Nothing in sddm.log either: http://paste.ubuntu.com/10783826/
[16:22] <d_ed> oh
[16:22] <tseliot> d_ed: [18:17:30.535] (II) DAEMON: Session started - was from when I logged in
[16:22] <d_ed> you should have said
[16:22] <d_ed> yeah, it's a bug I fixed last week
[16:22] <d_ed> in
[16:22] <d_ed> gnome keyring!
[16:23] <tseliot> d_ed: oh, we need that fix then. Riddell ^
[16:23] <d_ed> he's fixed it
[16:23] <d_ed> I think
[16:23] <d_ed> I assumed the fix was out
[16:23] <d_ed> might be in ubuntu's staging or something
[16:23] <d_ed> worst case remove the gnome-keyring line from /etc/pam.d/sddm
[16:24] <tseliot> I'm updating my packages list to see if we have a new gnome-keyring...
[16:42] <tseliot> d_ed: it seems to start even if I remove it from /etc/pam.d/sddm and there are problem upgrading here. But yes, the new package seems to be in the archive: https://launchpad.net/ubuntu/+source/gnome-keyring
[16:44] <doko> infinity, cgo should be fully functional on powerpc now
[16:47] <infinity> doko: Yeah, I had gccgo-go installed, which breaks the world.
[16:47] <infinity> doko: Should probably have a Conflicts/Replaces from gccgo-5 to gccgo-go to force it off on upgrades.
[17:14] <stgraber> infinity: so touchpad on the x240 works as it used to in trusty and utopic. If I turn off the touchpad, I can't click anymore at all. If the touchpad is on, I get the 3 buttons working but I can't scroll by using middle button + trackpoint.
[17:18] <infinity> stgraber: Huh.  Is any of that a regression, or just a disappointing lack of progression?
[17:18] <infinity> stgraber: Either way, I'd love to play with it in Austin when we both get there.
[17:19] <infinity> stgraber: I have a feeling the top-button-touchpad models might just be problem children we can't enirely fix kernel-side, but I'd like to prove that theory wrong, given that we managed to fix the next generation.
[17:20] <infinity> stgraber: And if we can fix just those ones via the X driver without messing with the new models, we should do that in the distro and ditch your hacks.
[17:21] <stgraber> infinity: I don't think it's a regression, looks similar to what I had on stock trusty before going with the hacked up X driver. But yeah, we can certainly play with it in Austin and see if we can get something saner in the distro
[17:22] <stgraber> infinity: my current hack is certainly unsuitable for the distro as it's about merging the synaptics and evdev code together in a single driver (which is about as ugly a hack as you can get :))
[17:25] <infinity> stgraber: Yeah, I think I've seen some slightly more elegant hacks from synaptics upstream, we'll see if we can come up with something suitably targeted that obviously doesn't break the rest of the world in the process.
[17:25] <infinity> stgraber: Do we know which models have that gross touchpad combo?  240, 440, 540, and X1C2?
[17:26] <stgraber> infinity: yeah, sounds right. All the Haswell thinkpads
[17:28] <hallyn> pitti: we need an equiv systemd unit to /etc/init/container-detect.conf.  whichnpkg should that go into? or does systemd already provide that?
[17:28] <infinity> stgraber: FWIW, wgrant speaks rather highly of the *40 + *50 touchpad hybrid hack.  If you like real buttons.
[17:28] <infinity> stgraber: But glad you have a non-hybrid to test on for now. :P
[17:28] <infinity> hallyn: systemd has a check for containers.
[17:28] <stgraber> infinity: yeah, still considering whether to do the hack or just ditch the 240 and switch to a 250 (just got to sell the 240 for that first)
[17:29] <infinity> hallyn: ConditionVirtualization=container
[17:29] <hallyn> ideally /bin/running-in-container could go inti init-shstem-helpers and work for both systemd and upstart
[17:29] <infinity> hallyn: rgrep Virtual /lib/systemd/system
[17:29] <hallyn> ideally /bin/running-in-container could go inti init-shstem-helpers and work for both systemd and upstart
[17:30] <hallyn> grr
[17:30] <hallyn> infinity: ill take a look at that thx
[17:31] <hallyn> maybe running-in-container can use thT
[17:31] <hallyn> and then apparmor can keep using that
[17:32] <infinity> hallyn: If apparmor has a .service file, it should be using the Condition, not a hack.  If it's shipping an init script, I'd expect the current running-in-container to still work?  Or does it depend on upstart?
[17:32] <infinity> Oh, it does.  status container-detect.  Ick.
[17:33] <infinity> hallyn: So, a container-detect.service that only runs on the right condition would probably work.
[17:33] <infinity> I guess.
[17:33] <infinity> Gross hack, though.
[17:53] <hallyn> infinity: yes, it seems just as well to move /bin/running-in-container to init-system-helpers and have it first check the systmd conditions, then the upstart ones
[17:55] <hallyn> oh, i see.  systemd doesn't export htat information anywhere.
[17:56] <infinity> hallyn: Probably, yes.  Bonus points if there's a sysvinit fallback too, but not really necessary in Ubuntu.
[17:56] <infinity> hallyn: It could "export" it via having a unit with the right conditions that either starts or doesn't, so you could do the same status check.  But still feels super gross.
[17:57] <hallyn> systemd-detect-virt
[17:57] <infinity> Ah-ha.
[17:57] <infinity> I assume that calls back to the same things that set those Conditions.
[17:57] <infinity> So, that would be the "right" way.
[17:58] <infinity> From outside the init system.
[17:58] <infinity> Inside init, obviously the Conditions are the correct way.
[17:58] <hallyn> right
[17:58] <hallyn> but so i'll probably use that in running-in-container and move running-in-container from upstart->init-system-helpers.  That sound ok?
[17:59] <infinity> Right.  And guard calling it with the usual [ -d /run/systemd/system ] check.
[17:59] <infinity> Remember to bump the Breaks/Replaces on upstart/upstart-bin to the version where you remove the binary.
[17:59] <infinity> And make it a << this time. :)
[18:00] <hallyn> yup :)
[18:00] <hallyn> thx, i'll do that in a bit when i have better internet
[18:01] <infinity> hallyn: This has the potential side-effect that a bunch more packages might have grown an undeclared dep on init-system-helpers.  Do you have a handle on how many things call running-in-container?
[18:01] <infinity> hallyn: (Granted, they probably all had undeclared deps on upstart before, so they're not getting much more broken, but we should still fix it)
[18:06] <hallyn> i don't.  i was going to make upstart depend on init-system-helpers, but that's not perfect
[18:07] <tseliot> d_ed: I've just reinstalled Kubuntu and log out works now (with today's image). I'll follow up on github for the merge request, as we can get hybrid graphics to work now. Riddell ^
[18:07] <d_ed> thanks
[18:07] <hallyn> infinity: it'll all do [ -x /bin/running-in-container ] && /bin/running-in-container as it does now, so nothing will be completel broken
[18:07] <tseliot> d_ed: thanks for your help
[18:08] <hallyn> just silently broken.  yay
[18:16] <infinity> hallyn: Don't make upstart depend on i-s-h.  I'm running out the door, but we can talk about this more later this afternoon.
[18:33] <hallyn> k
[18:44] <hallyn> infinity: as far as the actual script, http://paste.ubuntu.com/10784798/ seems to work
[18:45] <tseliot> d_ed: we're not quite there yet. sddm seems to stop. I'm not sure why http://paste.ubuntu.com/10784812/
[18:50] <tseliot> d_ed: that's even before the greeter shows up (which it never does)
[22:06] <hallyn> arges: time to scrap bug 1366868 ?
[22:07] <hallyn> oh, heh, you submitted it.  i was thinking you uploaded it
[22:16] <infinity> hallyn: I'd probably write that as "if type=$(systemd-detect-virt -c); then echo $type; exit 0; else exit 1; fi", but to each their own.
[22:16] <infinity> hallyn: Which allows them to add new container types without you having to fix the case statement.
[22:20] <hallyn> infinity: oh, -c, hadn't noticed that.  sounds good
[22:20] <infinity> hallyn: Double-check that -c exits non-zero under, say, qemu, but that's what I'd expect from the option and manpage.
[22:22] <hallyn> infinity: yeah, it does
[22:25] <hallyn> (fwiw this is bug 1442228)
[22:26] <hallyn> anyway it's getting late here so  i will either upload late after dinner, or tomorrow
[22:27] <infinity> hallyn: Not sure you needed to keep my one-liner on a single line, that was just for the benefit of IRC. :P
[22:29] <infinity> hallyn: Also, I realise it's cargo-cult from the previous iteration, but "if status foo; then thing; fi" is generally saner shell than "foo; if $?; then", since the latter is begging someone to miss the flow and insert a command between the call and the test.
[22:35]  * hallyn looks
[22:35] <hallyn> oh, that
[22:36] <hallyn> yeah i'll re-flow it before uploading
[22:37] <hallyn> at leset the one-liner;  the status one does get unwieldy if merged
[22:37] <hallyn> well, not really i guess
[22:41] <hallyn> so maybe http://paste.ubuntu.com/10786678/.
[23:41] <infinity> hallyn: Yep, that looks nice.
[23:41] <infinity> hallyn: The only other complaint would be the inconsistency between "type" and "[ -x", but pretty sure no one cares for a 23-line script. :P
[23:42] <hallyn> infinity: upstart currently is Depends: init-system-helpers (>= 1.22ubuntu6) .  are you sure we dont' want to update that to make sure ppl don't lose /bin/running-in-container?
[23:43] <hallyn> infinity: the -x is bc there are other 'status' programs
[23:43] <infinity> hallyn: That guarantees nothing, as upstart isn't required to be installed.
[23:43] <hallyn> so we really want to -x that path, whereas with the systemd tool i don't trust its path to never change
[23:43] <hallyn> ok
[23:43] <hallyn> not touching that then
[23:46] <hallyn> ok, quick test build ... (http://paste.ubuntu.com/10787092/ and http://paste.ubuntu.com/10787094/)
[23:48] <infinity> hallyn: Looks good, x2.
[23:49] <infinity> hallyn: And the Breaks/Replaces will ultimately have the same effect as if you'd bumped the versioned dep anyway.  *shrug*
[23:49] <hallyn> ok, this build test won't be very quick :(
[23:50] <infinity> export DEB_BUILD_OPTIONS="parallel=$(nproc) nocheck"
[23:51] <infinity> Because if you managed to break upstart's testsuite with this, lolz?
[23:51] <hallyn> heh, no it's just that my vivid container is apparently behind and has huge update waiting
[23:52] <hallyn> sigh, still going