[06:25] <Laibsch> cjwatson, xnox: I guess you've seen my application for PPU?  I haven't heard a thing about it since.  Is everything on track?
[08:06] <dholbach> good morning
[08:10] <pitti> jodh: FYI, I add some bugs to https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration which correspond to some of the WIs, so we don't need to duplicate all of those as textual WIs
[08:10]  * didrocks is listening to the session
[08:13] <jodh> pitti: thanks!
[08:25] <pitti> jodh: so everything in "Blockers for switching the default in vivid" is now covered by linked bugs, your automatic list, and one remaining WI which I just added
[08:26] <pitti> jodh: I also added two "nice to have" WIs for me, but the WI list is of course not complete yet
[08:26] <pitti> jodh: I don't want to meddle too much with your BP (you are the drafter, after all), so feel free to move around the milestones etc.
[08:44] <LocutusOfBorg1> wow I triggered a bug in launchpad https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1393202
[08:44] <LocutusOfBorg1> I can't change the status
[08:44] <LocutusOfBorg1> lol
[08:51] <pitti> LocutusOfBorg1: try the expander on the left and then change the status with the combobox
[08:52] <pitti> (I don't see the AJAXy change status either)
[08:57] <LocutusOfBorg1> pitti, yes, I already did the workaround, I was just reporting a bug :)
[08:57] <LocutusOfBorg1> thanks
[09:07] <didrocks> pitti: 2 things while I'm thinking about them: during the systemd session, you are talking about session not properly shutting down, this is I guess the timeout I'm seeing (like 30s with no screen refresh) before having the system brutally stopping?
[09:08] <pitti> didrocks: I sometimes get the 90 s timeout on user@1000.service shutdown (something is hanging there); but there's nothing about "brutally" stopping, it's just killing that user@1000.service
[09:09] <didrocks> pitti: I get it at each shutdown it seems, didn't find a bug about it though?
[09:09] <pitti> didrocks: oh? I don't get this
[09:09] <pitti> didrocks: I sometimes see it in an nspawn'ed vivid instance
[09:09] <didrocks> ok, will be a nice next-step exercise for debugging it seems
[09:10] <didrocks> ah, if I can reproduce it here, would be easier to debug
[09:10] <pitti> didrocks: right; enabling the debug shell, and while it's hanging check systemctl about what it's hanging on?
[09:10] <didrocks> pitti: will do (opening http://freedesktop.org/wiki/Software/systemd/Debugging/ for enabling the debug shell)
[09:11] <didrocks> pitti: second thing is that we don't enable journald persistency across reboots (there isn't the /var/log/journald IIRC directory created)
[09:11] <didrocks> is that on purpose?
[09:12] <pitti> didrocks: I haven't thought about this yet TBH; I guess we shoudl only have that *or* rsyslog by default, otherwise we waste twice the amount of log file space?
[09:12] <didrocks> exactly
[09:13] <didrocks> so, something to discuss, I find it weird for users that they can see only current journald boot, and have to go to rsyslog for older entries (and less info)
[09:13] <didrocks> but the opposite is true as well anyway :)
[09:14] <pitti> yeah; but I think I'd rather have it this way around, and then decide at some point to drop rsyslog by default and switch on persistant journal
[09:14] <pitti> didrocks: even more clever would be to auto-enable persistant journal dependeing on whether rsylog is enabled :)
[09:14] <didrocks> good idea!
[09:14]  * didrocks notes down as an easy one
[09:17] <jodh> pitti: I don't mind - feel free - it's going to have to be a team effort after all :)
[09:24] <pitti> hm, I was about to test LVM+encrypted, but this seems broken in vivid :( (bug 1393341)
[09:25]  * pitti downloads an utopic ISO and tries with that
[10:31] <pitti> slangasek, jodh: yay, cryptsetup+systemd works fine; both the full LVM with root (thus asking in initramfs), and only /home on LUKS (thus asking in the real system)
[10:46] <caribou> Laney: I just created a backport bug for tcpdump; should I assign it to myself while I complete some of the testing ?
[10:46] <Laney> caribou: sounds reasonable
[10:46] <caribou> Laney: k, will do
[11:13] <LocutusOfBorg1> seb128, sorry for the typo on bug 1367260
[12:49] <seb128> LocutusOfBorg1, no worry
[13:00] <cjwatson> pitti: question for you in bug 1393341, since you're unfortunate enough to have touched lvm2 last :-)
[13:02] <pitti> cjwatson: ah yeah, thanks; yeah, I fixed the init.d script once and it seems now I need to maintain it forever without understandin a thing about our delta :/
[13:03] <caribou> Laney: I tested everything required for the tcpdump backport  & everything is ok. So I'm leaving the bug unassigned
[13:03] <cjwatson> heh, well, it was a question more than a request :)
[13:03] <cjwatson> I don't claim to understand our delta either
[13:03] <pitti> but yes, "we should merge LVM2" indeed
[13:08] <pitti> cjwatson: everyone who did (kees, xnox) left, so I guess we'll have to make-do; I'll try to have a look at it soon, but I can only test it in a rather limited fashion
[13:14] <cjwatson> pitti: if it can't be done in some reasonably short period (by which I don't mean to rush you), then I guess the alternatives are to cherry-pick that option into lvcreate, to patch it out of partman-lvm (but then we risk forgetting about it and it'll likely break again later), or to figure out if partman-lvm can be made to work with both old and new lvm2
[13:14] <cjwatson> the problem was IIRC that new lvm2 broke partman-lvm differently without that option
[13:32] <xnox> cjwatson: pitti: partman-lvm & lvm2 need merging?
[13:32]  * xnox can look at that in the evening.
[13:34] <cjwatson> partman-lvm is in sync.  lvm2 needs merging.
[13:34] <xnox> ack.
[13:34] <xnox> slangasek: you should pinch hallyn into foundations team ;-)
[15:23] <pitti> zul: hah! got it
[15:23] <pitti> zul: adt-run --apt-pocket=proposed -U keystone --- qemu /srv/vm/adt-vivid-amd64-cloud.img --cpus 2
[15:23] <pitti> zul: that's the bit that the wiki page is missing; we run with 2 virtual CPUs by default, thus SMP
[15:24] <pitti> zul: with that I can reproduce the segfault fairly reliably (4 out of 5 runs)
[15:24] <pitti> zul: sorry, not segfault, it's a SIGKILL
[15:24] <zul> ah ok :)
[15:25] <pitti> zul: it also happens in vivid-release (adt-run keystone --- qemu /srv/vm/adt-vivid-amd64-cloud.img --cpus 2), so not a regression
[15:25] <pitti> zul: but "fails on machines with more CPU" still sounds rather serious?
[15:25] <zul> pitti:  so is there something i can do
[15:27] <pitti> zul: I'm ok with letting python-babel and python-keystoneclient in, as this isn't a regression from those two; but this will still hit the next time, of course
[15:28] <zul> pitti:  eventlet as well?
[15:29] <pitti> zul: yes
[15:30] <zul> pitti:  ok thanks
[16:35] <pitti> zul: FYI, keeping track/notes in bug during autopkgtest
[16:35] <pitti> bah, weechat
[16:35] <pitti> or, rather, bah firefox
[16:35] <pitti> zul: bug 1393474
[16:37] <zul> pitti: ack
[16:56] <chiluk> hey infinity I know you are sprinting and stuff but can I get some upload love on https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1391662
[18:00] <tkamppeter> Does someone know about the Python3 support of pyqt4? There is a python-qt4-dbus but no python3-qt4-dbus for example.
[18:01] <cjwatson> tkamppeter: I think you want python3-pyqt4.
[18:02] <cjwatson> IIRC they took the opportunity of adding python3-* to fix some naming mistakes.
[18:03] <tkamppeter> cjwatson, and pyqt4-dev-tools?
[18:04] <jtaylor> those are binaries and don't need modules
[18:04] <jtaylor> *provide
[18:05] <tkamppeter> What replaces python-imagin in Python3
[18:05] <jtaylor> python3-pil
[18:07] <tkamppeter> jtaylor, if hplip build-depends on pyqt4-dev-tools, what does it need when ported to Python3?
[18:07] <jtaylor> the same package
[18:08] <tkamppeter> python3-gobject-2?
[18:08] <jtaylor> you shouldn't need to care if binaries need python2 or 3
[18:08] <jtaylor> unless there is a packaging mistake of course
[18:08] <panbalag>  Looking for any developer who has updated the fields "when, Confirmed, Assigned, Started work, Completed" in launchpad while working on a bug... Please reply back if you have updated any of these fields. I would like to clarify the definition for these fields.
[18:09] <cjwatson> python3-gi would be more usual for gobject-related stuff
[18:09] <cjwatson> python-gobject-2 is the deprecated old-style bindings that AFAIK weren't updated to Python 3 (see python-gi for the new-style ones in Python 2)
[18:10] <tkamppeter> python3-notify?
[18:10] <tkamppeter> python-notify
[18:12] <tkamppeter> What replaces python-notify in Python3?
[18:14] <ScottK> mitya57: Why did we not make a python3-pyqt4-dev for the sip files?  Did we conclude they were the same for python/python3?
[18:15] <cjwatson> It looks as though python-notify has never been ported to Python 3, but there's a separate python-notify2 package (slightly different API, apparently) that has been, as python3-notify2.
[18:21] <dobey> panbalag: those sound like blueprint fields, not bug fields
[18:23] <tkamppeter> cjwatson, jtaylor, ScottK: Thank you very much.
[19:11] <mitya57> ScottK: they are the same
[19:11] <mitya57> http://www.riverbankcomputing.com/pipermail/pyqt/2014-August/034612.html
[19:11] <ScottK> mitya57: Thanks.
[19:33] <undRmindcntrlX2>  Does ubuntu error reporting send error data encrypted?
[20:01] <dobey> Unit193: it's uploaded over https, yes, if that's what you're asking
[20:42] <dj> hello
[20:43] <dj> i have a question to ask?
[20:43] <Noskcaj> !ask | dj
[20:45] <dj> How the installation process goes on ubuntu?
[21:33] <rbasak> arges: https://issues.apache.org/bugzilla/show_bug.cgi?id=56919#c6 is the deep dive / full description of the issue.
[21:33] <arges> rbasak: cool reading through all that now
[21:52] <Unit193> dobey: I'm not the droid you're looking for. ;)
[21:54] <dobey> oh. bloody people asking questions and then quitting five minutes later
[21:56] <Unit193> Yep. :/
[21:56] <dobey> oh well