[02:42] <bluesabre> hello sponsors!
[02:42] <bluesabre> ah
[02:42] <bluesabre> nvm
[02:42] <bluesabre> :)
[03:46] <slangasek> hallyn, stgraber: the debian/rules Vcs-* fields are defined as pointing to the branch where the package lives; please drop this field from the cgmanager package if the packaging isn't actually going to live there
[04:11] <hallyn> slangasek: is there a field we can use for where the usptream lives?
[04:11] <hallyn> (I assume you mean the debian/control Vcs-*)
[04:13]  * hallyn pushing an update without that field
[04:14] <hallyn> thanks
[04:34] <slangasek> hallyn: yeah, debian/control is what I meant.  There's no such debian/control field for upstream Vcs, you could put it in debian/copyright
[04:47] <Mirv> @pilot in
[04:47] <Unit193> Mirv: Happy piloting.
[04:49] <Mirv> thanks, let's see what I can do today. it's the last day before final freeze at least.
[05:57] <pitti> Good morning
[05:57] <pitti> bdmurray: we don't use procmaps for automatic processing of python crashes; they are occasionally useful to look at in bug reports for developers, though
[05:58] <pitti> bdmurray: like, finding out python extensions, third-party extensions/plugins, etc.; our client-side hooks check for that
[06:01] <pitti> infinity: -base langpack refresh next Monday: does that sound ok? or rather tomorrow?
[06:01] <infinity> pitti: Are those my only two options?
[06:02] <pitti> infinity: any other option would involve prodding wgrant to do a manual LP export
[06:02] <infinity> I imagine he has the skills to do that.
[06:02] <infinity> But I can't think too many translations will change between tomorrow and Monday, so tomorrow would be fine.
[06:02] <pitti> infinity: actually, scratch that; the other chance to enable "full langpack" would have been yesterday
[06:02] <infinity> Monday, we should be well into RC-land, and hopefully only respinning for criticals.
[06:02] <infinity> Hopefully.
[06:03] <pitti> infinity: ack
[06:03] <pitti> infinity: we've done it on Monday in the past few releases, so I assumed that was ok; but let me do the prodding
[06:04] <infinity> pitti: Did we?
[06:04] <wgrant> pitti, infinity: We can do it manually, but tomorrow seems to make sense to me.
[06:04] <pitti> wgrant: I requested a full export on https://translations.launchpad.net/ubuntu/trusty/+language-packs now; could you please kick the cronjob so that it builds one in the next day or two?
[06:04] <pitti> (I can also start the build on Saturday if necessary)
[06:04] <infinity> pitti: So, if I get to pick timing, "over the weekend" would be best.
[06:04] <pitti> infinity: ack
[06:04] <wgrant> loganberry.canonical.com-launchpad:30 10 * * 2,4 nice -16 $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu trusty --force-utf8-encoding -q --log-file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log
[06:04] <infinity> pitti: The first RCs won't spin until Sunday night or Monday morning.
[06:05] <pitti> wgrant: right, that matches with my "3,5" cronjob to build/upload the packages
[06:05] <wgrant> Won't it automatically do its thing in 5 hours?
[06:05] <wgrant> 4 hours
[06:06] <pitti> wgrant: oh, right; I was off by a day
[06:06] <bluesabre> hey pitti, are you running the show currently?
[06:06] <pitti> wgrant: ok, then I'll check tomorrow morning, and ask you if it failed (as sometimes it just doesn't produce anything)
[06:06] <pitti> bluesabre: "the show"?
[06:06] <wgrant> pitti: Well, it doesn't not produce anything. It spams my inbox.
[06:06] <wgrant> :)
[06:06] <bluesabre> :)
[06:06] <pitti> heh
[06:06] <bluesabre> as in, are you up for doing uploady things?
[06:07] <bluesabre> xubuntu-meta needs a refresh to take in one final change we rolled in last night
[06:07] <pitti> bluesabre: I've been sponsoring half a day yesterday
[06:08] <pitti> bluesabre: I can do some sponsoring, but not that much -- I've got to do some work, too :)
[06:08] <bluesabre> right
[06:08] <pitti> linux-exynos5 | 3.13.0-3.3    | trusty/universe         | source
[06:08] <pitti> oh, so this came back? we removed the package some time ago
[06:08] <pitti> or is that an error of some kind (bad sync)
[06:12] <bluesabre> ok, looks like it may have been taken care of after all, sorry to bother you guys
[06:12] <Mirv> yay for new -base langpacks, to get help translations in
[06:14] <infinity> pitti: No, it's back, that's based on the current trusty kernel.
[06:16] <Mirv> bluesabre: I'm the crippled pilot sort of since I don't have upload rights. what I tend to do is testing etc as needed, and then ping someone with upload rights.
[06:16] <bluesabre> Mirv: ok, good to know.
[06:17] <Mirv> today it seems I'm pretty crippled today by final freeze related work too, but I'll help at least if asked to help somewhere
[06:18] <Mirv> the fact that pitti has a pilot turn scheduled a day before tends to also mean the queue is shortish :S
[06:18] <infinity> Mirv: If one of your uploads is 5 minutes late because you were being nice and helping someone else, I think we'll cut you some slack.
[06:19] <pitti> Mirv: I got it down from 34 to 14 yesterday, but there was some stuff which needed FFEs or fixing
[06:19] <infinity> Realistically, actionable items in the queue should be pretty much 0 right now, unless there are some obvious, auditable, and simple bugfixes in there still.
[06:19] <pitti> infinity: speaking of FFEs, do you have a feeling about bug 1305135?
[06:21] <Mirv> pitti: yes, waiting UIFe, FFe, and already uploaded stuff in there. only a couple that could use some work/testing.
[06:21] <infinity> pitti: Looks sane to me.
[06:21] <pitti> Mirv: already uploaded? I can help with setting stuff to "merged" (although by now core-devs ought to be able to)
[06:22] <pitti> infinity: thanks
[06:24] <Mirv> pitti: in unapproved queue, xfce4-indicator-plugin. I guess it's not right to set it merged before it leaves that queue.
[06:24] <pitti> Mirv: *shrug*, there's nothing left to sponsor really
[06:24] <pitti> Mirv: but your call
[06:25] <pitti> Mirv: bug  1304214 looks like something which should still get in (but haven't checked)
[06:28] <Mirv> it does, but it'd need that approval. although it's ubuntustudio specific, I could probably discuss with them directly since they're probably handling the docs by themselves too.
[06:28] <Noskcaj> lp:~noskcaj/ubuntu/trusty/xfce4-xkb-plugin/lp-733563 still needs sponsoring
[06:32] <Mirv> Noskcaj: thanks, it seems it's missing from the sponsoring report page (http://reqorts.qa.ubuntu.com/reports/sponsoring/). I'll look at it
[06:33] <Noskcaj> micahg, thanks. Sponsors got unsubscribed after the first review for some reason
[06:52] <dholbach> good morning
[07:35] <Mirv> ok, I've verified this one, so if some core-dev would be kind to dget https://launchpad.net/~timo-jyrinki/+archive/ppa/+files/ubuntustudio-lightdm-theme_0.7.dsc and upload?
[07:35] <didrocks> Mirv: doing
[07:35] <Mirv> didrocks: thanks!
[07:39] <pitti> stgraber: still here by any weird chance?
[07:47] <pitti> stgraber: question for you in bug 1305395; not sure if slangasek wants that in trusty still, but in case he does it's a bit urgent (and the change is otherwise fairly straightforward)
[08:13] <jamespage> pitti, fd 6 is a pipe
[08:16] <pitti> jamespage: the strace doesn't say to where? i. e. not a named fifo?
[08:17] <jamespage> pitti, looking at that now
[08:17] <pitti> jamespage: if the strace doesn't reveal it, it might also help to attach gdb to the process and get a bt to see where it's spinning
[08:18] <zyga> bdrung_work: hey, I noticed you've packaged versiontools
[08:19] <jamespage> pitti, nothing in strace
[08:19] <jamespage> pitti, gdb'ing now
[08:19] <pitti> jamespage: you mean you don't see a call that opens fd 6?
[08:19] <jamespage> pitti, no
[08:20] <pitti> jamespage: oh wait, you attached strace to logind, you didn't start logind under strace, right?
[08:20] <pitti> if that happens only after some hours, that would produce a lot of output indeed, so let's try with gdb
[08:20] <jamespage> pitti, cgmanager_ping_sync
[08:22] <pitti> jamespage: ah, so I suppose your cgmanager process might have died?
[08:22] <pitti> root       310  0.0  0.0  23656  1440 ?        Ss   07:54   0:00 /sbin/cgmanager --sigstop -m name=systemd
[08:22] <pitti> you shoudl have something like that
[08:22] <pitti> jamespage: but even then it shoudln't loop
[08:22] <jamespage> root       327     1  0 Apr09 ?        00:00:12 /sbin/cgmanager --sigstop -m name=systemd
[08:22] <jamespage> I do
[08:23] <pitti> jamespage: ok; at this point I'd hand this to stgraber, he knows much better what cgmanager_ping_sync() is supposed to do
[08:24] <pitti> jamespage: thanks so far!
[08:25] <bdrung_work> zyga, yes
[08:25] <jamespage> pitti, np
[08:25] <zyga> bdrung_work: thanks for doing that, I was interested in working on it myself as I wanted to use it in my work soon
[08:26] <zyga> bdrung_work: is the module maintained in DPMT?
[08:26] <jamespage> pitti, stgraber: I'll leave it spinning - if either of you want access and have IPv6 I can enabled that fairly easily
[08:27] <bdrung_work> zyga, no. i put it under collab-maint. i don't mind moving it to DPMT (if they use git)
[08:27] <zyga> bdrung_work: I noticed you provided a python3 version as well, thanks
[08:27] <zyga> bdrung_work: I was working on 1.10 release
[08:27] <bdrung_work> you're welcome
[08:28] <zyga> bdrung_work: I could co-maintain the package if you want to
[08:28] <zyga> bdrung_work: do you have any packages that depend on it?
[08:28] <bdrung_work> zyga, help is appreciated
[08:28] <bdrung_work> zyga, yes. gevent-socketio depends on it. that was the reason for packaging it
[08:29] <zyga> I see, thanks
[08:41] <apachelogger> pitti: ahoy, does that look sound to you: https://code.launchpad.net/~apachelogger/lightdm/pam-kwallet/+merge/215108
[08:42] <pitti> apachelogger: superficially yes
[08:43] <pitti> (but I don't know how kwallet works)
[08:43] <apachelogger> almost exactly like gnome-keyring, the pam thingy was pretty much modeled after the gnome-keyring one from what I have been told
[08:44] <pitti> apachelogger: ah, ok; so it's not related to money or bitcoins or so :)
[08:46] <apachelogger> pitti: oh god no :P
[08:47] <pitti> $ bzr whoami
[08:47] <pitti> Your Name <name@example.com>
[08:47] <pitti> WTH?
[08:47]  * pitti uncommits, fixes that, and re-commits
[08:48] <zyga> pitti: bzr test suite perhaps?
[08:48] <pitti> zyga: yes, I did run that a couple of times
[08:48] <pitti> but I didn't expect it to change my actual config
[08:49] <zyga> pitti: it also gives you a gpg key you may want to get rid of
[08:49] <pitti> eww!
[08:49] <pitti> it should really set HOME=`mktemp -d` ..
[08:50] <pitti> zyga: not that I can see; at least nothign with "bzr" or "example"?
[08:51] <zyga> pitti: perhaps it managed to clean up for you, I saw some failures and it's still here (the gpg key)
[08:51] <pitti> apachelogger: should I also upload the lightdm change to trusty?
[08:51] <apachelogger> pitti: would be lovely
[08:53] <pitti> apachelogger: hm, there are more changes in trunk than just that
[08:53] <apachelogger> pitti: I can do an isolated upload then
[08:54] <pitti> apachelogger: sounds better then
[08:54] <pitti> I don't know how well these changes got tested, and whether they are meant for trusty
[08:54] <apachelogger> aye, uploaded :)
[09:28] <Laney> ISTR that update-manger wants Conflicts/Replaces to remove packages & Breaks/Replaces isn't enough
[09:28] <Laney> is that right?
[09:33] <cjwatson> Laney: yes
[09:34] <Laney> ta
[09:34] <Laney> Do reject mails from syncs work? :-)
[09:36] <ScottK> Laney: If it's CI syncs, definitely not.  Debian syncs, not sure.
[09:38] <Laney> ScottK: It's a Debian one in this case. You don't get "Waiting for approval", but do get "Accepted" (https://bugs.launchpad.net/launchpad/+bug/830614)
[09:40] <cjwatson> there definitely seems something wonky about syncs and mails, not sure about rejected but I'd expect that to be the same code path as accepted ...
[10:18] <zyga> bdrung_work: do you intend to get versiontools in to trusty?
[10:18] <zyga> bdrung_work: or are you fine with u-series?
[10:19] <bdrung_work> zyga, i synced it to trusty (i need it to fix the build failure of gevent-socketio)
[10:20] <zyga> bdrung_work: it's still in the new queue
[10:20] <bdrung_work> yes
[10:24] <cjwatson> *clicketyclick* no it isn't
[10:38] <bdrung_work> cjwatson, thanks
[10:49] <xnox> sergiusens: fginther: looking at https://code.launchpad.net/~xnox/notes-app/py32/+merge/210254/comments/510398 => http://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/6378/console it appears that the tests are executed with python2, yet python3 should have been used.
[10:50] <xnox> sergiusens: fginther: am i missing any declaration to trigger the jobs to use python3?
[11:59] <Mirv> I can't work on the piloting anymore, but if some core-dev wants to tinker a bit lmms would be "ready" aside from lintian non-cleanness also present in the current version in archives: bug #1291675 / lp:~timo-jyrinki/ubuntu/trusty/lmms/1.0.0_packaging
[12:00] <Mirv> it builds fine, was tested, and contains all the fixes Ubuntu Studio folks want to have there + matches upstream sources
[12:00] <Mirv> @pilot out
[12:15] <jibel> pitti, any idea why apport tried to run 'system-image-cli' on a desktop in bug 1305804 ?
[12:32] <pitti> jibel: /usr/share/apport/general-hooks/ubuntu.py calls it if there's a /var/log/system-image/client.log
[12:32] <pitti> jibel: so apparently this got installed once
[12:32] <pitti> and then removed again
[12:32] <pitti> jibel: that's when you run apport on a phone
[12:33] <jibel> pitti, right, that's why I was surprised to see it when run on a desktop
[13:17] <ev> stgraber: is there some trick to passing a loopmounted filesystem to a lxc container? I've tried lxc-device but I'm getting the rather helpful "cannot mount block device /dev/loop0 read-only" message inside the container.
[13:18] <ev> pitti: how were you arranging some block devices for swift in your lxc deployment?
[13:20] <pitti> ev: I don't; I just use /srv/swift/1 and just one volume
[13:20] <pitti> ev: http://people.canonical.com/~pitti/scripts/setup-swift.sh
[13:21] <ev> ah, so it uses the local fs? The charm doesn't seem to support that. Drat.
[13:21] <pitti> ev: yes, it's not a charm; lxc-local doesn't currently work for me, and I don't really need it; see http://www.piware.de/2014/03/creating-a-local-swift-server-on-ubuntu-for-testing/
[13:22] <ev> yeah, I did have a read through
[13:22] <pitti> ev: it's just a script which you run as root in a fresh container or VM
[13:22] <ev> though juju local does work for me, so I'm trying to get swift, glance, and rabbit in that :)
[13:22] <ev> works as of trusty, that is
[13:22] <ev> it was a car crash in saucy
[13:23] <pitti> ev: I didn't bother with rabbit, as that's really just apt-get install rabbitmq-server
[13:23] <pitti> bother to write some kind of setup script, that is
[13:23] <ev> yeah, there's also lp:rabbitfixture, so I might leave that part off as well
[13:39] <stgraber> hey pitti
[13:39] <pitti> bonjour stgraber, ça va ?
[13:40] <stgraber> pitti: très bien et toi ?
[13:40] <pitti> stgraber: je vais bien aussi, merci !
[13:40] <pitti> stgraber: as-tu vu mon question dans le bug 1305395 ?
[13:41] <stgraber> pitti: so wrt, bug 1305395, both changes look good to me. systemd will indeed talk through cgmanager if it's available, so the mount is unneeded and indeed blocked in containers
[13:41] <pitti> stgraber: ah, good
[13:41] <stgraber> pitti: though instead of keying on container_type, we could key on /sys/fs/cgroup/cgmanager/sock
[13:41] <pitti> stgraber: but we should still mount it for "real" systems, right?
[13:41] <pitti> stgraber: keying on /sys/fs/cgroup/cgmanager/sock would mean that we don't mount it on real iron any more either, though?
[13:42] <pitti> that sounds quite a bit more regression prone, as I'm not sure that all software has been fixed to look into /run/systemd/ instead of /sys/fs/cgroup/
[13:42] <pitti> stgraber: but in principle, cgmanager is being used on real iron now as well, right?
[13:43] <stgraber> pitti: hmm, yeah, probably better to keep the mount around for old software and in the event where cgmanager fails, so yeah, let's go with container_type
[13:43] <pitti> stgraber: ack, thanks for the review!
[13:43] <stgraber> cgmanager isn't installed by default and won't be for 14.04, as the upstart cgroup support won't make it
[13:44] <stgraber> it is however installed by default on any system that has LXC
[13:44] <pitti> stgraber: ah, that's why I have it
[13:44] <pitti> stgraber: can't live without LXC these days, really
[13:44] <pitti> stgraber: (in other words, many thanks for this!)
[13:45] <stgraber> thanks :)
[13:45] <stgraber> yeah, once you adapt your workflow to use containers, it's hard to get back :)
[13:48] <pitti> stgraber, slangasek: systemd_204-5ubuntu18_source.changes uploaded for your reviewing pleasure then
[13:48] <stgraber> pitti: cool, will review it in a minute then
[13:59] <infinity> stgraber: Dangit, I was going to trade pitti a systemd review for a kmod one. ;)
[13:59] <infinity> stgraber: Now, I guess you get to review both.
[14:00] <pitti> infinity: happy to review kmod anyway :)
[14:01] <stgraber> infinity: you know that Martin isn't in ~ubuntu-release anymore right? :)
[14:02] <infinity> stgraber: Yeah, but he can pretend.
[14:02] <infinity> stgraber: I'm not concerned about a release ack, just a second set of sane eyes on the change.
[14:03] <infinity> pitti: FWIW, yes, I did install that job locally, play with throwing modules in various files, move /etc/modules out of the way, etc, and check upstart logs.  It seems to DTRT.
[14:03] <pitti> yes, scrutinizing the modules-load.d/ bits
[14:04] <pitti> so that'll modprobe lp, ppdev, and parport_pc everywhere again due to /etc/modules-load.d/cups-filters.conf
[14:04] <infinity> pitti: The run-parts bit is cargo-cult from the Debian sysv script, pretty much the rest is us, to be less forky and ugly.
[14:04] <pitti> I doubt that anyone was missing the parallel port bits, but not having lp sounds strange
[14:04] <infinity> pitti: If that's not something we want, we shouldn't be shipping that file, not relying on our kmod being broken WRT upstream, IMO.
[14:04] <pitti> oh, that's also just for parallel port printers?
[14:05] <pitti> infinity: yes, of course; just thinking aloud here
[14:05] <pitti> infinity: and wondering how people could print without that; but I guess no dev has a parallel printer any more
[14:05] <pitti> or a parport, for that matter :)
[14:05] <infinity> Or something else loaded it anyway.
[14:05] <infinity> Hard for me to tell now that it's loaded. :P
[14:06] <infinity> Oh, no, one of them was verbose.
[14:06] <infinity> [1244710.379097] ppdev: user-space parallel port driver
[14:06] <infinity> That definitely happened when I was testing.
[14:06] <pitti> infinity: ah, haha
[14:06] <pitti> /etc/init/cups.conf also loads it
[14:06] <pitti> oh, and /lib/modules-load.d/fuse.conf
[14:07] <pitti> that will be new
[14:07] <infinity> fuse.conf is a no-op, it's builtin.
[14:07] <pitti> ack
[14:07] <infinity> (A no-op with our distro kernels, that is, probably wanted when not running one)
[14:07] <pitti> infinity, stgraber: so, kmod should not change the behaviour in the default install, and it looks ok to me
[14:08] <stgraber> good because I accepted it already :)
[14:10] <infinity> Oh, hrm, the only thing I didn't test is if that'll behave weirdly if $files is empty before entering the while loop.
[14:10]  * infinity tests quickly to see if he needs a followup.
[14:11] <infinity> Nah, seems fine.
[14:27] <zequence> Any core-dev around, that could lend us some upload rights? Bug 1291675
[14:28] <zequence> This package has some major improvements to the released one. Has been tested and is pretty much ready to go.
[14:29] <wgrant> pitti: Langpack export is about half done, so seems like it will work this time.
[14:37] <bdmurray> mvo: are you planning on SRU'ing the fix for bug 1202754?
[14:39] <pitti> wgrant: splendid, thanks
[14:55] <bdmurray> jibel: have you had a chance to test bug 1286161?
[15:12] <mvo> bdmurray: I think that is a good idea
[15:12] <bdmurray> mvo: Yes, I agree. I was more asking do you want to do it or should I?
[15:13] <mvo> bdmurray: oh, if you have some spare cycles, you are very welcome to do it
[15:13] <mvo> bdmurray: the aptdaemon upload from some minutes ago may also be worth getting
[15:16] <bdmurray> mvo: okay, we'll see
[15:22] <mvo> dobey: do you think there is a chance to get  lp:~mvo/software-center/lp1225885  reviewed and a upload before the final freeze? I'm happy to do the upload if you give me a hand with the current process of building the package
[15:24] <dobey> mvo: how many hours 'til freeze?
[15:25] <dobey> mvo: for upload, just deb-patch it
[15:25] <xnox> dobey: 21:00 UTC on the dot (+ slippage)
[15:25] <Laney> haha
[15:25] <Laney> on the dot (not on the dot)
[15:26] <dobey> it's a constantly moving, pale blue dot
[15:26] <mvo> dobey: deb-patch? as in apt-get source / patch / dpkg-buildpackage -S / upload?
[15:26] <dobey> mvo: yeah, as in drop it in debian/patches/
[15:26] <mvo> ok
[15:27] <dobey> mvo: if you're in a hurry, go for it. i'm not going to fight you on it :)
[15:27] <mvo> dobey: muuuarrhhh :)
[15:27] <mvo> dobey: will do it
[15:27] <dobey> mvo: there was a patch from robert_ancell too, if you could go ahead and throw it in (if he didn't already)
[15:29] <mvo> dobey: yeah, I was about to include both patches
[15:30] <dobey> mvo: great, thanks. and welcome back :)
[15:31] <mvo> dobey: thank you!
[15:31] <dobey> now, to get some lunch. bbiab :)
[15:39] <bdmurray> pitti: ddebs seem to be missing for libcairo-perl 1.104-1, libglib-perl 3:1.304-1, libgtk2-perl 2:1.249-2, and libpango-perl 1.224-2
[15:47] <cjwatson> I moved those all to universe recently, if that helps track down the problem
[15:58] <bdmurray> cjwatson: oh, hmm
[16:08] <apachelogger> cjwatson: uefi stuff on kubuntu has regressed again
[16:14] <bdmurray> cjwatson: Have you seen bug 1287222?
[16:19] <cjwatson> bdmurray: yes, can't do anything about it
[16:19] <cjwatson> apachelogger: ...
[16:20] <apachelogger> cjwatson: I am going to drop that dreadful distributor override
[16:20] <cjwatson> apachelogger: um
[16:20] <cjwatson> apachelogger: what package(s) exactly do you intend to change?
[16:21] <apachelogger> cjwatson: kubuntu-settings-desktop, which ships /etc/default/grubd./yayaydayda which sets GRUB_DISTRIBUTOR to kubuntu
[16:21] <cjwatson> apachelogger: hm, right, I can't say that would make me sad
[16:21] <cjwatson> apachelogger: remember to do the rm_conffile thing in a .maintscript file
[16:22] <apachelogger> aye
[16:36] <tgm4883> Are there any ubiquity heroes around? Mythbuntu is dangerously close to not being able to ship because Ubiquity is crashing in the live mode
[16:37] <xnox> tgm4883: i've testing mythbuntu yesterday and ubiquity did work.
[16:37] <xnox> tgm4883: did apport crash report appear and did you file a bug report?
[16:37] <xnox> tgm4883: what's the bug number?
[16:37] <tgm4883> xnox, did you check ubiquity in live mode, or just the installer?
[16:38] <tgm4883> because it only crashes in live mode, which is weird
[16:38] <tgm4883> superm1, is there a bug number on this?
[16:38] <superm1> no crash reporter shows up
[16:39] <superm1> it only crashes in live mode, removing they myth-services plugin fixes it, but i can't figure out why
[16:40] <xnox> superm1: thanks, i can take a look debug this. But probably around 22-24 UTC, after my volleyball match.
[16:40] <superm1> xnox: thanks for helping, i'll let you know if i figure it out
[16:40] <tgm4883> xnox, any off the top of your head pointers to look at?
[16:40] <tgm4883> we aren't seeing much in terms of logs and such
[16:40] <xnox> slangasek: ^ can we get a post-FFF slippage exception for above critical mythbuntu issue by the looks of things
[16:41] <slangasek> xnox: this falls under "critical installer bugs that are the only thing you're allowed to touch post-final-freeze", yes
[16:42] <xnox> slangasek: ack. =)
[16:42] <superm1> thanks
[16:43] <tgm4883> thanks slangasek
[16:51] <apw> Laney, you touched whoopsie-preferences last, seems we have missing/wrong B/R for P->T upgrades: bug #1306122
[16:51] <Laney> you touch it, you own it? :)
[16:52] <mvo> bdmurray: thanks for the apt upload for saucy! I was thinking we probably want to pick https://bugs.launchpad.net/ubuntu/+source/apt/+bug/957231 soonish too, what do you think? seems to be high on errors.u.c
[16:52] <apw> Laney, heh something like that, but you might have a better view for the recent touchingness
[16:52] <apw> i am happy to fix it up as well
[16:53] <bdmurray> mvo: that was me just releasing it to -updates, yes I agree with fixing that apt bug in saucy
[16:54] <Laney> apw: Nope, I'd bet is a straight B/R missing
[16:54] <mvo> bdmurray: cool, I will see what I can do tomorrow morning then
[16:54] <apw> Laney, it has one on another packge from the same source, so i wondered if they fatfingered the name
[16:54] <Laney> I think the split was done post-precise, when a-l-m-c-c was the thing
[16:54] <apw> ahh
[16:54] <Laney> which has since been renamed to a-l-m
[16:55] <Laney> so we want both I guess
[16:55] <apw> so both needed then
[16:55] <apw> yeah
[16:55] <bdmurray> mvo: we might need a test case, otherwise I'll have to query the database to find out if it is happening with the new version of apt. this is possible just some more work.
[16:55] <Laney> apw: You do, I review in unapproved queue?
[16:55] <apw> Laney, sure
[16:55] <Laney> great
[16:55] <mvo> bdmurray: aha, ok. I'm not sure if there is good way to create one, but I will scratch my head a bit about it
[16:56] <bdmurray> mvo: well, if not we can just use errors to validate it - I've been surprised how many people use -proposed
[16:57]  * mvo nods
[16:58] <apw> Laney, the vcs link in this thing seems to be junk, did you find an appripriate branch
[16:58] <Laney> apw: no, it is junk
[16:58] <Laney> I think robert_ancell is/will/was/considered/smelt getting that back into shape
[16:59] <apw> ok ...
[16:59] <Laney> but in the meantime just use the archive
[17:02] <apw> yep, will do
[17:07] <bulletxt> Hi, Cups 1.7.2 came out today. Do you think ubuntu 14.04 will be able to get it into it ? I filled a bug on launchpad
[17:08] <bulletxt> Please it's very important for me! There are some blocking bugs on 1.7.1 that is blocking my work
[17:08] <bulletxt> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1306141
[17:08] <seb128> tkamppeter, ^
[17:09] <seb128> bulletxt, not sure if the update is safe enough to get it, you might want to give specifics about your issue, selected fixes might be backportable if the update can't be done
[17:10] <seb128> bulletxt, it's also possible that the update is done as a SRU after release
[17:10] <bulletxt> this is the change log  https://www.cups.org/blog.php?L717      the worst bug for me is STR #4401
[17:11] <bulletxt> it's only a bug fix release and security
[17:11] <bulletxt> as clearly stated at the top (at least thats what they say)
[17:11] <tkamppeter> seb128, thanks for the hint, I also got the mail notification of this bug some minutes ago. How many hours are left to final freeze for getting this done before?
[17:11] <Laney> just under 4-ish
[17:12] <seb128> tkamppeter, even if you don't make the freeze it might still be ok to upload
[17:12] <seb128> they might approve it tomorrow
[17:12] <seb128> or it can be recycled to a SRU
[17:15] <pitti> doko: FYI, new python3.4 has (real) test failures and thus is stuck in -proposed: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-python3.4/ARCH=i386,label=adt/78/console
[17:16] <tkamppeter> seb128, I will package it now ...
[17:16] <seb128> tkamppeter, thanks
[17:17] <Laney> Till Kamppeter set my printer on fire 10 seconds before Final Freeze
[17:19] <doko> pitti, otp, will look later
[17:19] <tkamppeter> Laney, what did I do?
[17:20] <bulletxt> Laney:  don't worry I'm testing something like 8 printers connected to my server, from dyesub sublimination to professional Epson 3880 and others . So I'll let you know if 1.7.2 sets on fire my printer :)  I really need 1.7.2 lp command with 1.7.1 and below is broken
[17:20] <Laney> tkamppeter: Was joking about the last minute update :P
[17:21] <bulletxt> Well I have to go now hopefully I'll be back tomorrow.... tkamppeter thanks for the miracle  in advance :)   goodbye
[17:22] <tkamppeter> bulletxt, np
[17:29] <MacSlow> re
[17:34] <dobey> well, guess we might need to move final freeze a bit :)
[18:04] <delinquentme> Hey all! Wondering if anyone has a suggestion for a newbie to OS programing who happens to be a bit upset with the non-functional shortcut-key bindings in the default 12.04
[18:04] <delinquentme> Is this something simple to fix?
[18:10] <robru> delinquentme, what shortcut keys? System settings has a panel for changing keyboard shortcuts.
[18:14] <delinquentme> robru, yeah it allows them to be changed ... but on reboot they're wiped
[18:15] <dobey> delinquentme: eh? works fine here
[18:15] <dobey> delinquentme: file a bug
[18:23] <tkamppeter> seb128, new CUPS uploaded.
[18:39] <tkamppeter> seb128, CUPS 1.7.2 is accepted now.
[18:44] <ypwong> slangasek, regarding the new ubuntu kylin archive, will the debian source packages be published into the archive as well?
[18:44] <ypwong> happyaron ^^
[18:44] <seb128> tkamppeter, thanks
[18:44] <slangasek> ypwong: they certainly should be
[18:45] <ypwong> gotcha
[19:26] <mwhudson> is it possible that do-release-upgrade says "no release available" when it should say "your network is broken"?
[19:48] <sarnold> hrm, a friend is hitting bug 1302158 without using maas. he says he's "passing a loopmount of ubuntu-14.04-beta2-server-i386.iso to virt-install --location"
[19:49] <cjwatson> in general your base image and your kernel have to be in sync
[19:50] <sarnold> makes sense, I'm just surprised simplestreams (appears?) to be involved for an iso-based install
[19:52] <cjwatson> I haven't looked at the bug 'cos should be going, just saying, "No kernel modules were found" is a standard d-i message for "your kernel and the pool on your image are out of sync"
[19:52] <cjwatson> and doesn't involve simplestreams
[19:52] <sarnold> ah! :) thanks
[19:53] <sarnold> time for me to run too, lunch beckons. thanks cjwatson :)
[20:14] <LBo> I'm trying to use `backportpackage` + `pbuilder-dist` to backport a packge for a different arch (i386)
[20:14] <LBo> I can't find out how to specify the architecture
[20:14] <LBo> I'm now using this command: `backportpackage -b -B pbuilder-dist modsecurity-apache -u ppa:leonbo/servers`
[20:15] <LBo> Does anyone know how I can specify that it should build for i386?
[20:20] <Noskcaj> LBo, use pbuilder-dist i386
[20:22] <LBo> Noskcaj: thanks. backportpackage then gives this error: `Error: Unsupported builder specified: pbuilder-dist i386`
[20:22] <Noskcaj> try pbuilder-dist trusty md64
[20:24] <LBo> That doesn't work. It only accepts some parameters for -B:
[20:25] <LBo> `Error: Supported builders: cowbuilder, cowbuilder-dist, pbuilder, pbuilder-dist, sbuild`
[20:34] <barry> pitti: i guess we just have to accept two python interpreters on touch... for now
[20:35] <Logan_> LBo: > the ARCH  and  DIST  environment is read by pbuilderrc(5) to select the correct base image
[20:35] <Logan_> from backportpackage(1)
[20:36] <LBo> Yeah, I tried that
[20:36] <Logan_> so export ARCH=i386 and DIST=whatever in /etc/pbuilderrc
[20:36] <Logan_> oh, that didn't work?
[20:40] <LBo> Logan_: then when I did an `env` in my .pbuilderrc, it showed the ARCH & DIST env's but not with the values I set
[20:40] <LBo> It looked like something overruled those
[20:41] <Logan_> weird
[20:41] <LBo> But I didn't set it in /etc/pbuilderrc.
[20:41] <Logan_> oh, try that then
[20:41] <Logan_> the manpages know all 😛
[20:41] <LBo> DIST=precise ARCH=i386 backportpackage -b -B pbuilder-dist modsecurity-apache -u ppa:leonbo/servers
[20:41] <LBo> That was what I tried
[20:41] <Logan_> I don't think you can set them in the command
[20:41] <Logan_> because they're not environment variables, per sé
[20:42] <LBo> I'll try the /etc/pbuilderrc way
[20:52] <LBo> I've added a static $DIST & $ARCH to my .pbuilderrc
[20:52] <LBo> I get this message: `E: File /home/leon/pbuilder/precise-base.tgz does not exist`
[20:53] <LBo> I don't think backportpackage passes the arch to pbuilder-dist
[20:56] <LBo> I'll have another go at pbuilder plain
[21:05] <LBo> Logan_: plan pbuilder works now
[21:05] <LBo> I have no idea what went wrong when I did that a few hours ago
[21:05] <Logan_> oh sweet
[21:05] <LBo> Thanks for the help!
[21:05] <Logan_> no problem 😊
[21:07] <LBo> For history's sake: this is the command I'm using know (and that seems to be working): ARCH=i386 backportpackage -b -B pbuilder -s trusty -d precise modsecurity-apache -u ppa:leonbo/servers
[21:51] <doko> barry, stgraber: http://people.canonical.com/~doko/tmp/python3.4.debdiff
[22:40] <tgm4883> superm1, do we know anything more on that live disk issue?
[22:44] <maxb> 1ep[1;3D[1;3D[1;3D
[22:44] <maxb> 11p1
[22:49] <tgm4883> xnox, I know you said you were going to look at it. I was able to figure out that running ubiquity with sudo resolved the issue, so it looks like a priviledge issue. Not sure why it's failing to get that level of access in the live environment though
[22:50] <superm1> tgm4883: i haven't figured much more out on it
[22:50] <tgm4883> ok
[22:51] <tgm4883> I've had to work on some vmware stuff for work, so I haven't looked at it in the last few hours
[23:02] <slangasek> tgm4883, superm1: policykit/logind problem?
[23:02] <superm1> i remember there was one that affected xfce based distros in the past, but i thought xnox fixed that
[23:22] <xnox> superm1: well, the environment is different. previously all variables were kept - now pkexec is used so all envrionemnt variables are cleared.
[23:23] <xnox> superm1: thus i band-aid in a few things (e.g. GTK_MODULES=overlay-scrollbar to get ubuntu scrollbars, etc.)
[23:23] <xnox> tgm4883: thanks for the hint.
[23:24] <tgm4883> xnox, yw, just doing what I can in between things at work
[23:24] <superm1> the page is really simple page, just a few checkboxes, so I wouldn't expect it to be missing an environment variable to affect it, but maybe i'm nieve
[23:25] <tgm4883> heading home now, ping me if you need somehting