[02:57] <hyperair> does anyone here frequently hotplug monitors into an ivb laptop?
[06:32] <pitti> slangasek: thanks for the PAM bug analysis!
[06:32] <pitti> infinity: ah, good to know; I'll fix that
[06:33] <infinity> pitti: Thanks.
[06:33] <pitti> infinity: filed bug 1300031 as a reminder
[06:33] <pitti> Noskcaj: if there isn't too much difference to g-i-t 3.10, sure
[06:34] <infinity> pitti: I imagine the easiest way is just to grep -v '^#' before parsing debian/control.
[06:34] <infinity> pitti: Unless it also has issues with comments at the end of lines (didn't check).
[06:35] <infinity> pitti: In which case, maybe the equivalent of sed 's/#.*$//'
[06:35] <pitti> infinity: not sure whether you got my psql comment from Friday; but I guess today we can release the lot?
[06:35] <pitti> infinity: yep, should be simple
[06:35] <infinity> pitti: Yeah, we'll release it all today.  Your comment came a bit too late for me to be comfy releasing pre-weekend.
[06:36] <infinity> I guess we can just let it fly now, there will be enough people (including you) around to deal with something if it explodes.
[06:37] <infinity> pitti: Do these go to both updates and security, or is the psql-8.4 publishing history special?
[06:37] <pitti> infinity: no -security this time, just -updates
[06:37] <infinity> Kay.  For all of them?
[06:38] <pitti> infinity: yes
[06:38] <pitti> infinity: back in 30 mins
[06:40] <RAOF> pitti: Any chance of a umockdev release with the “don't wait for 48 days when given an evemu trace from a device that doesn't report events in chronological order” bug? :)
[06:58] <dholbach> good morning
[07:06] <zyga> good morning
[07:07] <pitti> RAOF: yes, I was going to do that
[07:08] <pitti> RAOF: sorry, forgot about it on Friday
[07:08] <pitti> RAOF: dinstall runs in 43 mins, I should catch that; so I can sync around noon
[07:14] <pitti> RAOF: umockdev 0.8.1 released and uploaded to sid
[07:59] <doko> tvoss, I think you / the phone team is the biggest user of valgrind (as a build dependency). I want to propose a new valgrind for trusty (having support for AArch64), maybe as a sru after the release. but it would be nice to check the valgrind package in the ubuntu-toolchain-r/test PPA.
[08:00] <tvoss> doko, cool, thanks for the heads up. I think the Mir team is using it in quite sophisticated ways, also the unity scopes team. I will dispatch your rfc for testing to them
[08:00] <doko> tvoss, let me file the bug, then the replies can be tested there
[08:00] <doko> posted ...
[08:00] <tvoss> doko, got a link for me?
[08:05] <doko> tvoss, https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1300070
[08:06] <doko> so maybe subscribe to the issue
[08:06] <tvoss> doko, ack
[08:18] <tvoss> doko, will ask the Mir and unity-scopes-api team for feedback specifically and extend the heads up to ubuntu-phone upstreams
[08:27] <seb128> shrug
[08:27] <seb128> update-manager stopped to debconf prompt me about openssh-server configuration
[08:27] <seb128> it displays a checkbox "disable ssh password authentification for root?"
[08:28] <darkxst> yeh I saw that too, imported from debian ?
[08:28] <seb128> cjwatson_, hey, is that ^ known/wanteD?
[08:29] <darkxst> seems rather odd when we don't have root accounts by default!
[08:29] <infinity> s/accounts/passwords/
[08:38] <infinity> cjwatson_: Maybe you could skip the debconf question and JFDI if '$(getent shadow root | cut -d: -f2) = "!"'
[08:40] <infinity> cjwatson_: That is, if root doesn't currently have a password, you won't be locking me out of my machine by surprise by not allowing password logins.  If I set one later, I can debug why it no workie myself.
[08:46] <infinity> seb128: ^ That seem like an acceptable compromise between no default prompting and not locking people out on upgrade?
[08:47] <seb128> infinity, seems fine to me, I'm unsure what changed though/how we were handling things before
[08:47] <seb128> (e.g why is that prompt showing up today)
[08:48] <seb128> k, the changelog answers that question :p
[08:48] <infinity> seb128: Our default config has/had PermitRootLogin yes.  The new default is without-password, which is saner, but automatically upgrading would lock out people who rely on the password auth.
[08:48] <seb128> right
[08:49] <infinity> (At least, I assume it used to be yes... Maybe it used to be no, and all of us hitting the prompt manually changed it at some point and forgot...)
[08:50] <infinity> No, it was definitely yes, I have a fresh precise VM with that setup.
[08:51] <seb128> I'm sure I didn't change that config
[08:52] <pitti> smoser, infinity: wolfe-05 and -06 are offline; do you know what happened to them?
[08:52] <infinity> pitti: I have no idea.  Lemme see if I remember how Scott's setup works.
[08:53] <infinity> ... and which IP wolfe is.
[08:55] <infinity> pitti: 06 looks alive to me.  05 is in an rcu_sched hang.
[08:55] <infinity> Oh, wait.  06 is spewing on the console too.  Whee.
[08:55] <infinity> pitti: Bouncing both.
[08:56] <infinity> pitti: Should be back.  I don't have accounts on either, so you'll have to confirm.
[08:59] <jibel> infinity, thanks, they are both back
[09:01] <jibel> pitti, I'll bring 3 down, because dpkg segfaults and it cannot provision a new container
[09:01] <jibel> s/down/offline/
[09:01] <infinity> jibel: A reboot should fix that.
[09:02] <infinity> jibel: I've never been able to reproduce that bug to try to figure out WTF is happening. :/
[09:02] <infinity> jibel: You're seeing that on one of wolfe's VMs?
[09:03] <jibel> infinity, yes on wolfe-03 but I just rebooted it
[09:03] <pitti> infinity: thanks for bouncing
[09:03] <infinity> jibel: Yeah, that's fine, I don't think I can get anything useful out of the VM anyway.  Just odd that you've seen it on another host.  I've only ever seen it on postal, and was close to blaming the machine.
[09:04] <infinity> (I've seen it on all of postal's VMs, but never on denneed or fisher, which is confusing as heck)
[09:04] <seb128> @pilot in
[09:04] <jibel> infinity, indeed it's dpkg'ing happily after a reboot.
[09:06] <infinity> jibel: It might act up again at some point.  It seemed to happen to postal's VMs every few hundred builds or so (couldn't ever identify any specific thing as the trigger, though), which is why those buildds are on manual right now. :/
[09:07] <infinity> As bugs go, it's pretty much my least favourite kind.  Not enough useful info to report to kernel (or qemu?) people, and no sane way to make it happen to try to get useful info.
[09:07] <infinity> And it may well just be a bug in the qemu endian-flip madness, which would make it something that really doesn't matter once we get off POWER7 hardware.
[09:08] <infinity> At least the symptom is so catastrophic that it doesn't cause any subtle bugs elsewhere. :P
[09:13] <jibel> infinity, yes hard to say, first failure of this type started 2 days ago but without any specific thing done to the VM
[09:18]  * hyperair wonders if he's the only one experiencing black-screen-on-monitor-plugged-in syndrome.
[09:33] <GunnarHj> cjwatson_: ping?
[09:43] <seb128> GunnarHj, you might want to let some context with pings ;-)
[09:44] <GunnarHj> seb128: Makes sense...
[09:45] <GunnarHj> cjwatson_: Time to talk about bug 1294858?
[09:46] <GunnarHj> seb128: Do you have time for a package question?
[09:47] <seb128> GunnarHj, sure
[09:48] <GunnarHj> seb128: What's the best way to distinguish Ubuntu from Debian in debian/rules?
[09:48] <GunnarHj> dpkg-vendor --is ubuntu
[09:48] <GunnarHj> ?
[09:49]  * apw feels this new ssh message is confusing, and the name of the option it tells you about just fuels that, and i don't feel advised as to the right option; i felt compelled to read the manual for it to decide
[09:49] <seb128> GunnarHj, yes
[09:49] <infinity> apw: See backscroll.
[09:49] <infinity> apw: About an hour ago.
[09:50] <GunnarHj> seb128: So the builders will always understand?
[09:50] <apw> infinity, ahh thanks
[09:50] <infinity> GunnarHj: The buildds have the same dpkg installed that you do.
[09:50] <seb128> GunnarHj, why wouldn't they? that's what e.g udisks is using
[09:50] <seb128> (just giving an example of package where we are using that if you want to check it out)
[09:51] <infinity> GunnarHj: You might want --derives-from though, if you want Ubuntu and all derivatives to get the setup.
[09:51] <pitti> didrocks: apport with that crash fix uploaded, now waiting in unapproved
[09:51] <infinity> GunnarHj: (Depends on if it's legitimately Ubuntu-specific, or rather just "not the Debian way")
[09:51] <didrocks> pitti: ok, I'll keep an eye to kick an image once available
[09:52] <GunnarHj> infinity, seb128: It's basically 'not the Debian way' in this case. Most important is that it works for Ubuntu Kylin.
[09:53] <infinity> GunnarHj: Well, kylin is "just Ubuntu", from the POV of them using the same dpkg from the same archive.
[09:53] <infinity> GunnarHj: But if Ubuntu derivatives should also default to the same setup (eg: because our packaging is forked in other fun ways, and derivatives should inherit that default), then you want --derives-from.
[09:54] <infinity> Thing, eg: Mint.
[09:54] <infinity> s/Thing/Think/
[09:54] <infinity> Not sure if Mint actually bothers to fork dpkg origin, but they should if they don't. :P
[09:54] <GunnarHj> infinity: Does --derives-from include all the 'normal' *ubuntu flavours?
[09:55] <infinity> GunnarHj: Flavours are all Ubuntu.
[09:55] <infinity> GunnarHj: They all use the same dpkg, cause they build from the same archive.
[09:55] <GunnarHj> infinity, seb128: Ok, think I've got it. Thanks!
[09:55] <infinity> GunnarHj: It's only derivatives (ie: people with their own archives) who can be different in this case.
[09:57] <infinity> GunnarHj: So, basically, antyhign built from ftp.debian.org both --is and --derives-from debian.  Anything built from archive.ubuntu.com --is ubuntu and --derives-from both debian and ubuntu.  Other out-of-archive derviatives might derive from debian or both (or, if they're weird, neither).
[09:58] <cjwatson> seb128: It's wanted in general, but infinity's suggestion seems like a nice option.
[09:59] <GunnarHj> infinity: Then it's indeed --is in this case (i.e. not Debian). Thanks for the lesson. :)
[10:02] <cjwatson> GunnarHj: I only work on ubiquity at the moment when it's an emergency and nobody else is available.
[10:02] <cjwatson> GunnarHj: Too many other plates to juggle.
[10:03] <GunnarHj> cjwatson: Anybody else I could talk to? (It's not exactly an emergency, but would be nice to have it fixed in 14.04.)
[10:03] <cjwatson> GunnarHj: Slightly reluctant to unconditionally volunteer him, but maybe xnox has time?
[10:03] <infinity> GunnarHj: I think I was trying to point out that you want "--derives-from ubuntu" so that both ubuntu and downstreams who use our packages mostly unmodified would get the same thing, but if it's really Ubuntu-specific, you want --is (like, say, Apache server tokens).
[10:04] <GunnarHj> cjwatson: Can't hurt to ask. :) Thanks!
[10:07] <GunnarHj> infinity: It's code intended to be added in debian/rules upstream (Debian) but only take effect when built for Ubuntu.
[10:07] <infinity> GunnarHj: Right, I get that.  But if someone were to build the package on an Ubuntu derivative that is mostly Ubuntu, but with a few tweaks, would they want the Ubuntu rules behaviour, or the Debian?
[10:08] <infinity> GunnarHj: If you use --is, they'll get the Debian behaviour.  Would that be wrong in the context of all their other packages being Ubuntuish?
[10:09] <GunnarHj> infinity: Maybe, maybe not. It's not a very Ubuntuish think. It's just that we (unlike Debian) want fcitx to be the default before ibus if fcitix is installed. :)
[10:10] <caribou_> cjwatson: I saw that you fixed the btmp bug in Debian (Debian bug #341883), thanks
[10:11] <GunnarHj> infinity: Still appreciate your clarifications.
[10:12] <cjwatson> caribou_: you're welcome
[10:12] <caribou_> cjwatson: now how should I proceed for Ubuntu ? This will not be automatically synced in Trusty
[10:12] <cjwatson> caribou_: I already synced it.
[10:13] <caribou> cjwatson: thanks!
[10:13] <infinity> cjwatson: Hrm.  That btmp thing didn't really address the "might use password as username" issue, though.  I'm still not super keen on root having a log of unhashed passwords in the clear.
[10:14] <caribou> cjwatson: then looks like I should get going with the SRU work
[10:14] <infinity> cjwatson: I liked login's solution of logging UNKNOWN for accounts that don't exist.
[10:14] <cjwatson> infinity: Yeah, that's cute, though really ought to be done upstream
[10:14] <cjwatson> caribou: Be my guest
[10:14] <infinity> Though, login fails in other ways, it would seem...
[10:15] <infinity> UNKNOWN  tty1                          Mon Mar 31 04:14   still logged in
[10:15] <infinity> test123  ssh:notty    localhost        Mon Mar 31 04:12    gone - no logout
[10:15] <infinity> Still logged in, my ass. :P
[10:15] <pitti> Laney: does bug 1278284 sound ok to you? Otherwise I'll need to fork off Ubuntu and upload the other fixes without that new debugging option
[10:15] <pitti> Laney: (I suppose it's ok, but asking early before I sync it)
[10:15] <pitti> Laney: sorry, bug 1300092
[10:15] <infinity> Oh, fun, it continues to say that until the getty dies (ie: due to a successfuly login)
[10:16] <infinity> s/successfuly/successful/
[10:16] <Laney> pitti: Yeah, new feature you have to opt in to use in a QA-ish package sounds fine
[10:16] <Laney> go wild
[10:17] <pitti> Laney: thanks
[10:17] <Laney> thanks for committing that sessioninstaller fix too ;-)
[10:46] <seb128> dholbach, hey, is https://bugs.launchpad.net/ubuntu/+bug/1294891 ready for upload? ;-)
[11:03] <highvoltage> froztbyte/win 13
[11:03] <highvoltage> (oops)
[11:03] <Laney> nice password :P
[11:03] <zyga> heh :)
[11:08] <tkamppeter> xnox, hi
[11:13] <xnox> tkamppeter: hello!
[11:27] <Sweetshark> doko: libreoffice update is in main, -voikko build against it here ...
[11:27] <Sweetshark> s/build/builds/
[11:28] <Sweetshark> pls ping me if there are issues remaining.
[11:39] <dholbach> seb128, I didn't look at it after my pilot shift again
[11:40] <seb128> dholbach, can you upload it? if I do it I need to find another archive admin to do the NEWing...
[11:40] <dholbach> seb128, ok, I'll review it again
[11:40] <seb128> dholbach, danke!
[11:52] <dholbach> seb128, followed up: https://bugs.launchpad.net/ubuntu/+bug/1294891/comments/8
[11:53] <seb128> dholbach, thanks
[11:59] <tkamppeter> xnox, can you have a look at bug 1276713 and also at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742666. It is abot getting equal Upstart support with socket activation in both Debian and Ubuntu.
[12:00] <tkamppeter> xnox, can you especially answer Cameron's questions in the Launchpad bug.
[12:00] <xnox> tkamppeter: ack.
[12:04] <xnox> tkamppeter: responded
[12:13] <tkamppeter> xnox, thanks.
[12:18] <seb128> @pilot out
[13:01] <seb128> doko, hey, do you have any openjdk upload coming? there is a patch in the sponsoring queue that would be nice to get in trusty, but since openjdk takes ages to build better to batch that with other changes if you have some ;-)
[13:02] <doko> if this is 937200, then yes
[13:17] <seb128> oh, seems like pitti is attacking the sponsoring queue from the other side ;-)
[13:17] <pitti> seb128: sorry, I saw your @pilot out and thought to run through some items
[13:17] <pitti> seb128: i. e. sorry if I stepped on your toes
[13:17] <seb128> pitti, no worry, help is welcome ;-)
[13:18] <mardy> Mirv: hi! Do you think you can add the fix to bug 1299712 as a patch against qt 5.2?
[13:18] <seb128> pitti, no, I'm glad you got some, I stopped for lunch and I was planning to get a few extras, but I would probably not have reached the most recent ones
[13:19] <pitti> seb128: grabbing light-locker* and gnome-documents MP, ok?
[13:20] <pitti> seb128: I try to do the easy syncs and some "5-a-day"ish these days
[13:20] <seb128> pitti, yes please, I just synced the audiocity ones and tali, sponsored gnome-online-account and I'm doing easytag
[13:20] <psusi> the ddebs for libparted0debian1 are empty in the last 3 revisions.  anyone have any idea what went wrong? or how to figure it out?
[13:20] <seb128> pitti, just stating the ones I'm touching so we don't duplicate
[13:21] <seb128> pitti, 5 a day ftw ;-)
[13:28] <psusi> cjwatson: re: the loop regression: I think you had some magic in partman to deal with lvm volumes, which parted used to report as having a single partition on them named /dev/mapper/xxxp1.  The patch dropped the incorrect p1 suffix.  Could that have broken partman?
[13:29] <xnox> psusi: partman used to report /dev/mapper/volume-group-name with volumes under that device name (as if they are partitions)
[13:31] <pitti> seb128: grabbing https://code.launchpad.net/~noskcaj/ubuntu/trusty/gnome-video-effects/0.4.1/+merge/212248, then finishing
[13:32] <pitti> RAOF: umockdev 0.8.1 is now in trusty, with the timestamp going backwards fix
[13:33] <seb128> pitti, danke
[13:35] <psusi> xnox: not how I remember it... it reported each /dev/mapper/vg-lv as a disk, with a single partition on it named /dev/mapper/vg-lv1
[13:36] <psusi> partman apparently knew it had to strip off the bogus 1 to refer to the actual device name... I fixed libparted to not add the bogus 1 in the first place
[13:44] <cjwatson> psusi: None of that rings a bell
[13:46] <psusi> cjwatson: darn.. was hoping it would.  Guess I'll just have to play around with it tonight.
[13:47] <pitti> didrocks: the apport cgroup crash fix landed in trusty now, FTR
[13:47] <cjwatson> psusi: thanks
[13:48] <seb128> doko, thanks ;-)
[13:48]  * davmor2 rings his bell to see if helps cjwatson remember
[13:49] <pitti> stgraber, kirkland: byobu's keys (F2 etc.) don't work in a container, i. e. with "lxc-start"; is there a trick how to get this functionality?
[13:50] <kirkland> pitti: hmm, interesting, is this screen or tmux backend?
[13:51] <pitti> kirkland: hm, both screen and tmux are installed (I think I just did "apt-get install byobu"), how do I tell?
[13:51] <pitti> tmux -f /usr/share/byobu/profiles/tmuxrc new-session -n - /usr/bin/byobu-shell
[13:51] <pitti> kirkland: ah, tmux
[13:51] <kirkland> pitti: tmux
[13:51] <kirkland> pitti: yeah, the easy visual queue is "1 line, or 2 of status at the bottom"
[13:51] <pitti> kirkland: ah, heh; yes, one line
[13:51] <kirkland> pitti: otherwise, its ps -ef | grep byobu
[13:52] <pitti> kirkland: I'm fairly sure it's nothign with gnome-terminal or my unity config etc, I use F2/F3 etc. on ssh sessions all the time
[13:52] <pitti> kirkland: curiously, F9 works
[13:53] <kirkland> pitti: right;  oh, now that is weird
[13:53] <kirkland> pitti: I was thinking something might be wrong with how lxc handles the tty...but if F9 works...
[13:53] <pitti> kirkland: shift-f2/f3 etc. seem to work, too
[13:53] <kirkland> pitti: this is latest/greatest trusted?
[13:53] <pitti> kirkland: yes, trusty du jour on both host and container
[13:54] <stgraber> pitti: what's F2 supposed to do?
[13:54] <kirkland> pitti: is this a recent regression in lxc?
[13:54] <kirkland> stgraber: create a new window in byobu
[13:54] <stgraber> ok, then it works fine here
[13:54] <pitti> kirkland: I'm not sure, but it's at least like that for two weeks or longer
[13:54] <pitti> stgraber: interesting
[13:54] <stgraber> I'm sshed into a trusty container on a trusty host running byobu and F2 gets me a new window
[13:54] <stgraber> using terminator as my terminal emulator here
[13:54] <pitti> stgraber: so maybe ssh sets up the terminal differently in some way than a direct "lxc-start" in gnome-terminal?
[13:55] <stgraber> pitti: that's entirely possible, yes
[13:55] <pitti> anyway, it seems this isn't already known
[13:55] <pitti> I can do lxc-attach to get a second shell in it, it's just way more cumbersome
[13:55] <stgraber> though both should be pts devices in the end, maybe tmux special-cases devices called /dev/ttyX somehow?
[13:57] <ochosi> pitti: thanks for sponsoring light-locker* !
[13:57] <pitti> kirkland: FTR, broken in byobu-screen as well
[13:57] <pitti> ochosi: yw!
[14:00] <kirkland> pitti: okay, I'm trying to reproduce this now
[14:00] <kirkland> pitti: what's your escape key?  the default ctrl-a?
[14:01] <kirkland> pitti: can you try this... ctrl-a then ":" then type "new-window" and hit enter
[14:01] <kirkland> pitti: does that create a new window?
[14:01] <pitti> kirkland: hm, I think I set it to emacs mode, so that ctrl+a = go to beginning of line
[14:01] <kirkland> pitti: okay, so ctrl-b then
[14:02] <pitti> kirkland: argh, that's taken by my window manager; can I reset ctrl+a somehow?
[14:02] <pitti> ah, byobu-ctrl-a :)
[14:02] <pitti> F12 doesn't work, FTR
[14:02] <pitti> kirkland: :new-window works fine; F3 doesn't switch
[14:03] <kirkland> pitti: okay, now, ctrl-b then ":" then "bind-key -n F2 new-window"
[14:03] <kirkland> pitti: then try pressing F2
[14:04] <pitti> kirkland: no change
[14:06] <kirkland> pitti: okay, and you're in a shell on your container using lxc-attach?
[14:07] <pitti> kirkland: not lxc-attach, lxc-start (not sure if that's any different)
[14:07] <pitti> sudo lxc-start -n debci
[14:07] <pitti> and then log into that through the usual getty
[14:08] <pitti> kirkland: a local byobu on my VT1 works fine, btw
[14:09] <didrocks> pitti: yeah, we kicked an image as soon as it was promoted (building), thanks for the head's up
[14:13] <seb128> xnox, hey, could you review https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1298220 ?
[14:14] <seb128> xnox, I'm asking you because I know you had a look at some of the issues with the new bash
[14:15] <seb128> doko, ^ or maybe that's something you are interested in as well
[14:16] <xnox> seb128: damn, did I forget to revert bash ?! *sigh*
[14:17] <seb128> xnox, now I'm unsure if you are trolling me :p
[14:17] <seb128> xnox, well, doko is back at least, so you can talk to him about fixing it
[14:18] <xnox> seb128: i think we can sync bash-completion, but it will not solve all the bash problems.
[14:18] <seb128> :-(
[14:19] <pitti> xnox: FTR, there's a sync request in the sponsoring queue; but I checked the diff between D and U and it's horribly long, so that would need to be done with some care
[14:19] <pitti> I found a few fixes/changes which aren't in Debian yet
[14:19] <pitti> (i. e. maybe better merge/sync that next cycle?)
[14:21]  * dholbach hugs seb128 and pitti
[14:21] <xnox> pitti: yeah, i also see that some things need to be merged.
[14:21]  * seb128 hugs dholbach and pitti
[14:21] <xnox> pitti: agree, that it's better to post-pone this.
[14:21] <cjwatson> slangasek: Can you advise on where bug 1298653 should be reassigned?
[14:24] <xnox> seb128: hm, although doko did upload two bugfixes.
[14:24] <seb128> xnox, right
[14:24] <bdmurray> pitti: did you see I updated my apport-retrace package versions merge proposal?
[14:25] <xnox> seb128: i think we are all good. major bugs in bash-completion and bash are fixed.
[14:25] <pitti> bdmurray: ah no, I didn't; thanks! (LP doesn't send out notifications for new commits)
[14:25] <seb128> xnox, if you say so
[14:25] <pitti> at least ~/... completion shows files again
[14:30] <kirkland> pitti: okay, I've reproduced your issue
[14:31] <kirkland> pitti: I'm checking saucy now
[14:32] <pitti> kirkland: I can't say whether this is a regression at all; I never used byobu with lxc before
[14:32] <kirkland> pitti: k
[14:42] <kirkland> pitti: I do see this error, "<4>init: setvtrgb main process (409) terminated with status 1"
[14:42] <kirkland> pitti: just before the login prompt
[14:43] <pitti> kirkland: yes, me too
[14:43] <kirkland> pitti: confirmed on saucy too
[14:45] <bdmurray> infinity: could you have a look at bug 1298393?
[14:47] <ogra_> cjwatson, hmm, i just noticed that i can start sshd even if there are no existing host keys, is that wanted (i remember the old sysv init script had a check and created keys on demand)
[14:49] <cjwatson> ogra_: I'm afraid your memory is faulty.
[14:49] <ogra_> was that always a postinst thing ?
[14:49] <cjwatson> We've never created host keys in the init script, and if it ever checked it would only have been by way of sshd -t.
[14:49] <cjwatson> Yes.
[14:50] <ogra_> hmm, kay
[14:50] <cjwatson> I would expect sshd to exit early if it has no host keys.
[15:17] <bdmurray> barry: were you looking at gdebi recently?
[15:18] <barry> bdmurray: yes, i have a branch wip for switching it to py3
[15:18] <bdmurray> barry: might that fix bug 1295872?
[15:18] <barry> bdmurray: not directly
[15:21] <bdmurray> barry: okay, looking at the errors bucket it seems to occur pretty frequently
[15:22] <barry> bdmurray: i'll try to take a look when i'm working on the new branch
[15:23] <bdmurray> barry: thanks
[15:39] <hallyn> holy cow.  unity is just losing windows left and right...  they're still running, but they don't show up in the switcher
[16:01] <rbasak> cjwatson: triaging bug 1300133: Won't Fix?
[16:04] <cjwatson> rbasak: I've left it in the state I intend
[16:04] <cjwatson> rbasak: (i.e. it's OK for there to be discussion)
[16:05] <cjwatson> rbasak: (I don't understand this thing where the server team feels obliged to triage openssh bugs but doesn't contribute to maintenance, TBH)
[16:05] <cjwatson> seems weird :)
[16:11] <balloons> ping xnox
[16:13] <rbasak> cjwatson: to try and keep a handle on bugs, I end up triaging far more bugs than I do deep dives into.
[16:14] <xnox> balloons: hey
[16:14] <rbasak> cjwatson: for some reason our triage process involves handling New/Undecided bugs, but IMHO that's never really been right. It's just on the queue, and I thought we could do something about it.
[16:14] <rbasak> I suppose set the Importance at least, since then it doesn't appear on the first triage report we have.
[16:14] <balloons> xnox, hey. So a couple things to discuss with you.
[16:14] <xnox> balloons: shoot! =)
[16:14] <balloons> xnox, first, can you push stuff to the store now? Can you build clicks on s-jenkins? did that get sorted out?
[16:15] <cjwatson> rbasak: importance something less than high would be fine, yeah
[16:16] <rbasak> thanks
[16:16] <xnox> balloons: i have access to upload clicks into the store, i can download them from s-jenkins. I don't have any special privilidges on s-jenkins (e.g. triggering/controlling jobs etc)
[16:17] <xnox> balloons: e.g. i was the one who uploaded gallery app click fetched from s-jenkins for the last upload.
[16:17] <balloons> xnox, good enough. Ok, would you be willing to work with fginther this week on having those builds be autotested after building?
[16:17] <balloons> xnox, I'll be out and he wants to get it in ;-)
[16:18] <xnox> balloons: sure. All I do locally is: $ click-run-checks on the generated .click.
[16:18] <balloons> xnox, secondly, I'd think your opinion on this issue popey is seeing. https://bugs.launchpad.net/music-app/+bug/1300230
[16:18] <xnox> fginther: can we integrate "click-run-checks" on the generated .click? it's about equivalent to running "lintian" against a deb.
[16:19] <xnox> balloons: right, let me look into that music-app error.
[16:19] <balloons> xnox, I'm wondering if the new phablet-tools release might have impacted the bug I linked from popey. The tldr is, there are now unicode errors running tests that used to work
[16:23] <xnox> balloons: if a click declares autopilot directory in the manifest, it must be python3 compliant tests.
[16:23] <xnox> balloons: one way to solve this is to remove that stanza from the manifest, and then the tests will revert to using python2.
[16:23] <balloons> did we miss music in the conversion?
[16:23] <xnox> balloons: or I'll look into fixing this.
[16:23] <balloons> xnox, ahh.. kk..
[16:23] <xnox> balloons: to make it python3 compatible again.
[16:24] <balloons> xnox, I'd prefer the latter if you are willing
[16:24] <xnox> balloons: it did pass under python3 a week ago =)
[16:24] <balloons> xnox, wild.. I haven't checked the revision history to see what all got changed
[16:24] <balloons> let's look
[16:25] <fginther> xnox, adding click-run-checks is do-able
[16:26] <xnox> fginther: having that output as artifact should be sufficient. Possibly bail/fail the job if that has errors. Warnings are harder, as some of them are expected.
[16:27] <balloons> fginther, xnox please just keep me in the loop on what's implemented. I'll be back at the end of next week
[16:27] <fginther> xnox, I'll let you know once I have something started so you can have a peek at the results
[16:28] <xnox> fginther: thanks!
[16:31] <Laney> bah
[16:31] <Laney> keeping build-deps cross-installable is a right pain, isn't it?
[16:36] <tarpman> doko, seb128: thanks very much for uploading 937200 :) super pleased to have that in trusty.
[16:37] <seb128> tarpman, yw!
[16:43] <xnox> balloons: commented on the bug report about music-app. It works and passes correctly on the current trusty-proposed channel, with current 389 music-app, latest phablet-tools, under python3.
[16:43] <xnox> balloons: how is popey running that music-app tests that shows errors?
[16:44] <popey> xnox: phablet-test-run -v  music_app
[16:46] <balloons> xnox, I'll leave you to popey as it works for me too :-)
[16:46] <popey> thanks ☻
[16:46] <balloons> popey, well, which version are we running
[16:46] <balloons> xnox answered that v369 or earlier don't work
[16:47] <popey> 369 of what?
[16:47] <balloons> I see 389 right?
[16:47]  * balloons opens myapps
[16:47] <popey> i have tried 389 and 403
[16:48] <balloons> popey, ahh right then. indeed
[16:50] <popey> xnox: feel free to ping if you need me to test anything, or need more detail.
[16:50] <balloons> biab
[16:54] <psusi> cjwatson: so do you have any idea why the ddebs for the last 2-3 releases of parted are broken?
[16:58] <xnox> popey: 389 works fine.
[16:58] <xnox> popey: how do you build, install and test 403?
[16:59] <slangasek> cjwatson: bug #1298653> err, I honestly have no idea, it's not supposed to be a boot menu option
[16:59] <popey> xnox: i got 403 from the store,  uploaded by balloons, installed using "pkcon install-local foo.click"
[17:00] <popey> xnox: I test using 4 lines... phablet-config autopilot --dbus-probe enable, phablet-click-test-setup --click  com.ubuntu.music, adb reboot, then phablet-test-run -v music_app
[17:00] <popey> xnox: which is what I've been doing for all apps. I ran the tests on gallery earlier on the same device and it was fine.
[17:00] <cjwatson> psusi: hm, broken how?
[17:01] <xnox> popey: right, let me wipe my device clean, to make sure i'm clean.
[17:01] <psusi> cjwatson: it's empty
[17:01] <cjwatson> psusi: there are -dbg packages
[17:01] <psusi> for libparted that is...
[17:01] <cjwatson> psusi: IIRC pkg-create-dbgsym doesn't bother to create contentful -dbgsym packages if -dbg is meaningful
[17:02] <psusi> ohh... didn't realize -dbg got added... and that makes the ddebs still there, just empty?
[17:02] <cjwatson> think so, they should have a dependency?
[17:02] <Laney> dbgsym should have a dependency
[17:02] <psusi> I would have thought it wouldn't create them at all... weird
[17:07] <xnox> popey: can you get me output of $ click list --manifest ?
[17:08] <popey> xnox: http://paste.ubuntu.com/7185790/
[17:09] <xnox> popey: and when running as a user phablet I guess as well, so $ sudo -u phablet -i click list --manifest ?
[17:09] <popey> that was as phablet
[17:09] <xnox> popey: cool, thanks.
[17:10] <xnox> popey: so autopilot/python blows up on one of those =)
[17:10] <popey> oh nice
[17:10] <xnox> popey: in particular with the fact that it's not running in UTF-8 locale, I think.
[17:10] <xnox> popey: (same as all other locale based problems recently reported)
[17:10] <popey> makes sense ☻
[17:12] <ogra_> hmm, is the randomization of PIDs a kernel feature ? and if so, is there wa way to switch it off ?
[17:13] <ogra_> it just struck me how helpful it would be to have the processes visually ordered in a bootchart
[17:13] <ogra_> (which proper ordering of the PIDs would achieve)
[17:16] <sarnold> ogra_: yes, it would be a kernel feature if it exists; are you confident you're seeing that behaviour? to my knowledge, linux has never had it..
[17:16] <sarnold> (and my week-old-ish uuntu touch image doesn't show that behaviour..)
[17:18] <ogra_> well, looking at bootcharts i see things started with a lower PID than the process starting it ... it seems to start randomizing at some point
[17:20] <sarnold> crazy thgh, running 'ps ; ps' in terminal shows 10151 and 10156. that's far more intervening processes than I would have expected
[17:21] <Snow-Man> or it just wrapped?
[17:22] <mdeslaur> sarnold: if I run it a couple of times, I get sequential pids once in a while
[17:22] <sarnold> iirc cking mentioned some new tool recently, a fork-tracker... it'd be worth tracking that down
[17:22] <sarnold> mdeslaur: heh, I never got two consecutive pids
[17:23] <mdeslaur> sarnold: you need to stop running the fork bomb in the other window :)
[17:24] <sarnold> mdeslaur: oh is -that- why my battery life is not so good? :)
[17:26] <mdeslaur> sarnold: hehe :)
[17:26]  * sarnold mumbles "last time I trust an article that says you can speed up your phone with this one simple trick..."
[17:29] <balloons> xnox, popey so what's the synopsis?
[17:35] <popey> balloons: xnox was reflashing his device, but seems maybe one of the apps I have installed on my phone was triggering the issue. But we don't know which one (yet)?
[17:37] <zyga> ogra_: IIRC kernel has PID reuse but the way it reclaims dead pids is unclear to me
[17:37] <ogra_> it seems slightly random ...
[17:38] <ogra_> but not completely
[17:38] <zyga> ogra_: probably next free from a rotating counter *but* given that this is the kernel I woudn't be surprised if there are some multi-core features to avoid any locking on next
[17:39] <ogra_> yeah
[17:46] <xnox> popey: i think i do know what's triggering this.
[17:46] <xnox> popey: working on a fix.
[17:47] <xnox> popey: please don't change your phone =)
[17:49] <popey> ok
[17:55] <xnox> popey: make your phone RW (if not already) then do:
[17:55] <xnox> adb shell "echo exec su - -c adbd > /etc/init/android-tools-adbd.override"
[17:55] <xnox> adb reboot
[17:55] <xnox> popey: then try running music-app tests again and it should work.
[18:02] <xnox> popey: right, the UTF-8 app is tradera that you have installed, and i've now reproduced your bug and the fix for it.
[18:07] <leftyfb> paul_1: can you hop onto the webex and login to the local 12.04 install for me?
[18:08] <leftyfb> paul_1: in a meeting at the moment so can't talk on the webex call
[18:12] <leftyfb> paul_1: thank you
[18:23] <popey> xnox: sorry, was on a call..
[18:23] <xnox> popey: no worries. Fix uploaded into unapproved queue. Hopefully would be reviewed and accepted soon.
[18:38] <infinity> bdmurray: Yup.
[18:39]  * popey hugs xnox 
[18:39] <popey> xnox: so just removing Tradera will allow me to run the tests?
[18:41] <xnox> popey: or doing: adb shell "echo exec su - -c adbd > /etc/init/android-tools-adbd.override"
[18:41] <xnox> popey: and rebooting
[18:42] <popey> xnox: i went for removing the app
[18:42] <xnox> popey: you might have other apps installed which would also affect the results....
[18:42] <xnox> popey: it's the first problematic one, not sure if there are others =)
[18:42] <popey> is there an easy way to tell?
[18:43] <popey> which was the problematic app?
[18:46] <xnox> freeciv, airbnb, baboom, bytesjack, ....
[18:46] <xnox> popey: is your phone not in RW mode?
[18:47] <xnox> in that case wait for adbd fix to get accepted.
[18:50] <popey> no, not rw, I dont really want to do that
[18:50] <ogra_> xnox, did you run any AP tests for this ? would be good to know that still works with the multiple sudo hoops they jump through in adb
[18:50] <xnox> popey: well, it got accepted now. So in one of the next images it should be available via channel updates ;-)
[18:51] <xnox> ogra_: all works correctly, tested with click and non-click AP tests.
[18:51] <ogra_> cool
[18:51]  * ogra_ wishes we could drop that some day .... it is awful
[18:55] <slangasek> drop which?
[19:01] <ogra_> slangasek, the sudoing to become phablet
[19:01] <slangasek> what's awful about it, and what are you wanting to drop it in favor of?
[19:02] <ogra_> proper pam integration of adbd ... or running adbd as user by default
[19:03] <slangasek> well, I don't think that's an "or"; running it as a user by default still doesn't give you a pam session unless you add the pam integration
[19:04] <slangasek> I'm unconvinced that there's anything wrong with the current solution that's worth the effort of adding pam integration to adbd
[19:06] <ogra_> adb shell "sudo -u phablet -i 'bash -i -c $command'" ...
[19:07] <ogra_> i still find it awful and ugly :)
[19:07] <ogra_> not to mention it gets you into quoting hell with a little complex commands
[19:10] <slangasek> ogra_: well, there's certainly some redundancy there
[19:11] <slangasek> but that should be fixed directly
[19:12] <ogra_> well, we have plenty different vesions of that command in different plases and tools ...
[19:12] <ogra_> phablet-test-run has: adb $ADBOPTS shell sudo -u $USER -i sh -lc \'"$@"\' ...
[19:12] <ogra_> slightly less ugly
[19:12] <slangasek> no, that's even more ugly
[19:13] <ogra_> oh ?
[19:13] <slangasek> '-i sh -lc'?
[19:13] <slangasek> you want 'sudo -u $USER -i -c "$@"'
[19:14] <ogra_> that somehow didnt work for the people writing the tests
[19:14] <slangasek> then they should've asked for advice from someone who knows how sudo and the shell work
[19:15] <hallyn> hm, maybe i'm having a pulseaudio bug.  mplayer keeps saying 'audio device got stuck.'  banshee last night seemed to keep completely hanging my laptop (to the point that sysrq didn't work)
[19:15] <ogra_> i think that doesnt process profile.d
[19:15] <ogra_> which we need to get the proper env
[19:15] <hallyn> i'll test some more witih banshee tonight after a reboot ...
[19:15] <slangasek> and actually, I'm wrong, what you actually want is 'sudo -u $USER -i "$@"'
[19:15] <slangasek> ogra_: 'sudo -i' is all you need in order to get a login shell
[19:16] <slangasek> all the other crufty arguments here are cruft, but that has nothing to do with adbd supporting pam, that just has to do with people piling on commandline arguments without understanding them
[19:16] <ogra_> well, there was a reason for the bash call in there
[19:16] <slangasek> not a good reason
[19:16]  * ogra_ cant remember anymore, thats nearly a year old 
[19:17] <ogra_> but i know that the SDK ads well as the automation uses it like that
[19:17] <slangasek> it's possible that the phablet user had the wrong login shell.  That should have been fixed by fixing the phablet user's login shell.
[19:17] <slangasek> (and if that was the problem, it has been fixed since)
[19:18] <ogra_> i dont think it ever changed from /bin/bash
[19:19] <ogra_> what i remember is that it had something to do with the environemnt not being proper
[19:23] <slangasek> regardless, this is unnecessary complexity.  phablet-test-run should just be 'adb $ADBOPTS shell sudo -u $USER -i $@', and the other invocations likewise
[19:24] <ogra_> right, i was promoting that back then ... but for some reason it didnt work
[19:35] <slangasek> ogra_: ok, so the issue within phablet-test-run is that it's trying to run a sequence of commands under sudo, so yes, that requires sh -c.  It certainly doesn't require 'bash -ic', however... 'sh -c' is fine and it will inherit the environment from the login shell that's already been launched
[19:44] <Justanick> Hello, is it useful, that an upgrade from the last LTS did not remove the packages
[19:44] <Justanick> linux-image-generic-lts-quantal
[19:44] <Justanick> linux-headers-generic-lts-quantal
[19:45] <Justanick> Also the new gcc is not added to update-alternatives
[19:45] <Justanick> Still showing the old gcc 4.6
[19:46] <cjwatson> gcc is intentionally not managed in update-alternatives, to avoid determinism problems in builds
[19:47] <leftyfb> paul_1: Would you mind joining us on that call? Having some issues.
[19:47] <cjwatson> A normal upgrade should simply repoint the /usr/bin/gcc symlink directly at gcc-4.8, assuming that you upgraded gcc
[19:48] <Justanick> cjwatson: The gcc 4.6 has been still installed after the update. I have just purge it with apt-get purge
[19:50] <Justanick> This has also delete the gcc 4.6 entry on update-alternatives
[19:50] <Justanick> The new entry for gcc 4.8 is still missing
[19:51] <Justanick> The binaries are at /usr/bin/
[19:51] <cjwatson> There has never been a gcc-4.6 entry in update-alternatives at all, as far as I'm aware
[19:51] <cjwatson> I suggest "sudo apt-get install gcc"
[19:57] <Justanick> cjwatson: The message is "newest version is installed". I will add the entry manually.
[19:59] <infinity> Justanick: There should be no "entry", there should be a straight symlink, as provided by the "gcc" package.
[19:59] <infinity> Justanick: If you had alternatives before, that was not from the Ubuntu packaging, but perhaps something you added yourself?  In which case, you should expect that to break.
[20:01] <Justanick> infinity: I could be added by myself. I have used the older LTS a bunch of time with a bunch of compiler versions.
[20:03] <cjwatson> Perhaps at some point you used dpkg-divert?
[20:03] <cjwatson> dpkg-divert --list | grep gcc
[20:03] <Justanick> I don't think so.
[20:04] <Justanick> Does the return nothing
[20:04] <Justanick> Does return nothing
[20:04] <cjwatson> well, gcc 4:4.8.2-1ubuntu4 here ships the file /usr/bin/gcc, so I have no other ideas why it wouldn't be installed if that package is installed on your system.
[20:05] <cjwatson> symlink, not file, that is.
[20:05] <Justanick> I will simple add it to update-alternative
[20:05] <cjwatson> Don't compound your mistake.
[20:06] <cjwatson> It isn't supposed to be an alternative.  Installing it as an alternative locally is going to lead to trouble.
[20:06] <cjwatson> Try 'dpkg -L gcc' and see whether it lists /usr/bin/gcc.
[20:07] <cjwatson> And in future use CC=gcc-4.8 or whatever if you need to switch versions rather than mucking around with system-level alternatives.
[20:08] <Justanick> cjwatson: Yes it is on the list.
[20:09] <cjwatson> Then I might try "sudo apt-get --reinstall install gcc" to see if that resurrects /usr/bin/gcc.
[20:09] <cjwatson> And make sure that you have no alternatives for gcc now.
[20:09] <Justanick> gcc -v returns now the ubuntu build of 4.8.2
[20:09] <cjwatson> I don't really want to think about what an alternative for a file name also shipped directly in a package would do to dpkg, but it wouldn't be good.
[20:10] <cjwatson> It certainly isn't a valid configuration.
[20:11] <cjwatson> There are alternatives for c89, c99, and cc, those are OK (they're for switching between gcc and clang)
[20:11] <cjwatson> Though CC= is still usually preferable
[20:12] <Justanick> Okay.
[20:13] <cjwatson> I think it's probably more or less expected that linux-*-generic-lts-quantal aren't removed, not sure; might be nice to sort that out via an upgrade quirk in ubuntu-release-upgrader
[20:14] <cjwatson> Clearing out old kernels requires care ...
[20:16] <infinity> cjwatson: The release-upgrader already violently tears out old kernels, I thought.  Maybe it's being fooled by the lts backports.
[20:16] <Justanick> cjwatson: Or a question to the customer, if the older kernel should be removed?
[20:18] <doko> xnox, thanks for taking care about the python3.3 drops
[20:19] <xnox> doko: no problem.
[20:19] <xnox> doko: need to make up uploads since missing in action for a wekk =)
[20:31] <Justanick> Should scons work on the daily?
[20:38] <Justanick> g++ has not been valid
[20:42] <jtaylor> xnox: whats different in the headless builders? or why is stuff suddenly failing to build after beta freeze?
[20:42] <Justanick> At the boot grub2 shows me 3 times error:file not found. What the source of the problem could be?
[20:43] <xnox> jtaylor: it has also been failing in all test rebuilds.
[20:43] <jtaylor> it didn't fail in february
[20:43] <xnox> jtaylor: the errors are comming from X server, on initial inspection, maybe the problem is somewhere else.
[20:44] <xnox> jtaylor: it did fail in early march. http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html
[20:45] <xnox> jtaylor: well, march 16th.
[20:45] <xnox> ~ 2 weeks ago.
[20:46] <jtaylor> ah, mixed it up with pytables that still build a week ago
[20:46] <jtaylor> I'll check it out
[21:02] <jtaylor> xnox: oh I remember, its nose thats broken
[21:02] <jtaylor> fixed in debian svn
[21:03] <jtaylor> want to sponsor :)
[21:03] <jtaylor> oh been done today, so just needs syncing
[21:04] <xnox> jtaylor: which package? =)
[21:04] <jtaylor> python-nose
[21:05] <xnox> jtaylor: done - https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=nose
[21:05] <jtaylor> thx
[21:06] <xnox> jtaylor: thanks for tracking this down =)
[21:06] <jtaylor> mitya57 tracked it down, I just reported :)
[21:12] <slangasek> ogra_: so I proposed a fix to phablet-test-run, and the testsuite fails CI because of unrelated bashisms in phablet-screenshot :-P https://jenkins.qa.ubuntu.com/job/phablet-tools-trusty-amd64-ci/67/console
[23:04] <hallyn> hi - could someone on sru team please look at https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=libvirt?
[23:05] <hallyn> the version currently in -proposed failed to build, 8.9 in unapproved fixes that
[23:33] <bdmurray> infinity: nag about bug 1296386