=== _salem is now known as salem_
[00:35] <psusi> cyphermox, I'm looking for someone other than cjwatson to pester about this and you seem to have done some work on ubiquity lately... could you have a look at bug #1418706?  It seems to be a very nasty bug in how ubiquity is executing the partman scripts and seems to me to be rather release critical, with 15.04 coming up fast... I suspect the underlying bug will cause many serious problems other than the one named in the bug.
[00:35] <ubottu> bug 1418706 in ubiquity (Ubuntu) "Vivid: UEFI: blank drive incorrectly detected as existing BIOS-mode install" [Critical,Triaged] https://launchpad.net/bugs/1418706
[00:41] <infinity> psusi: I think I already heaped that on his TODO over the weekend.
[00:42] <psusi> hehe... ok, good, as long as it gets taken care of before release... I just get nervous that something this serious will be released ;)
[00:49] <cyphermox> psusi: I'm already aware of it, and that's what I was looking at when you pinged
[00:49] <psusi> whoohoo ;)
[00:49] <cyphermox> it's kind of suspicious
[00:49] <psusi> I'm available if you have any questions about it ;)
[00:49] <cyphermox> but I need to setup my qemu to boot with EFI
[00:50] <psusi> already did some preliminary tracing, just don't have the familiarity with ubiquity or the time to fix it myself... been real busy lately with my day job... damn FDA and silly MISRA requirements...
[00:51] <psusi> here's the command I used to reproduce it: sudo qemu-system-x86_64 -enable-kvm -drive if=ide,file=/home/psusi/Music/isos/vivid-desktop-amd64.iso,media=cdrom -drive if=ide,file=/dev/faldara/test -vga std -m 1024
[00:51] <cyphermox> thanks, that's helpful
[00:51] <psusi> sorry, that was bios mode... make it this one: sudo qemu-system-x86_64 -enable-kvm -bios /usr/share/qemu/OVMF.fd -drive if=ide,file=/home/psusi/Music/isos/vivid-desktop-amd64.iso,media=cdrom -drive if=ide,file=/dev/faldara/test -vga std -m 1024
[00:52] <psusi> after installing the ovmf package of course
[00:52] <infinity> Yeah, I was going to mention the lack of '-bios /usr/share/qemu/OVMF.fd' on that first line.
[00:52] <cyphermox> I already know the details for EFI bios :)
[00:52] <psusi> kk ;)
[00:53] <psusi> I looked over the partman logs and added a few set -x's and found that the visual.d script from partman-efi was actually creating the new partition prior to running the init.d scripts, which then detected the new, unformatted partition as an existing bios mode install.. the scripts are NOT supposed to be run in that order
[00:54] <psusi> then of course, even when the condition is detected and the prompt displayed, ubiquity needs to wait for the reply instead of proceeding to the next task and leaving the prompt window orphaned/hung
[00:58] <psusi> hrm... that reminds me... maybe a topic we might discuss at the next uds: debian now has support for running d-i under Xwin for a graphical install.. this may be a good replacement for ubiquity entirely?
[01:01] <infinity> psusi: Using live-installer instead of base-installer, perhaps, but it would need some (a lot of) tweaking.
[01:02] <infinity> psusi: Plus, ubiquity also doubles as oem-config, which bare d-i doesn't have an equivalent for.
[01:02] <infinity> psusi: So, while convergence of the installers would be nice, it's non-trivial.
[01:05] <psusi> ahh, didn't know about oem-config... yea.. convergence would be really nice ;)
[01:06] <psusi> especially given some of the long standing and unfixed bugs in ubiquity, such as the fact that whenever grub-install fails, and you get the dialog box asking to pick an alternate location to install it to, any subsequent tries are doomed to failure because /proc, /sys, and /dev have already been unmounted from /target
[01:06] <psusi> and the lack of raid support in ubiquity
[01:07] <psusi> and the lvm support is really sad
[01:08] <cyphermox> psusi: if you have a list of the bugs you feel are important, I can add them to some form of a todo list for me to get to eventually
[01:09] <psusi> probably a good foundation for a discussion on whether to proceed with fixing those bugs, or converge with debian and abandon ubiquity instead.
[01:11]  * psusi misses having beer time at face to face UDS
[01:14] <psusi> anyone remember when it was called espesso instead of ubiquity?  Christ, how the years do go by...
=== salem_ is now known as _salem
=== doko_ is now known as doko
[04:59] <pitti> Good morning
[04:59] <Unit193> Howdy.
[05:04] <pitti> infinity: did you already talk to mbiebl about http://paste.ubuntu.com/10752817/ ? (I'd rather have his consensus for uploads to jessie)
=== jamesh_ is now known as jamesh
[06:20] <Mirv> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
=== marcusto_ is now known as marcustomlinson
=== marcusto_ is now known as marcustomlinson_
=== marcustomlinson_ is now known as marcustomlinson
[07:53] <LocutusOfBorg1> good morning developers
[07:57] <seb128> hey LocutusOfBorg1
[08:12] <Laney> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv, Laney
[08:31] <zyga> good morning
[08:31] <zyga> vivid still prefers wifi over ethernet today
[08:34] <mgedmin> very modern
[09:09] <flexiondotorg> didrocks, Do you have a moment to help clear to fog in my mind regarding - https://bugs.launchpad.net/ubuntu-mate/+bug/1439388
[09:09] <ubottu> Launchpad bug 1439388 in mate-tweak (Ubuntu) "Updated translations for mate-tweak [debdiff attached]" [Low,Incomplete]
[09:11] <didrocks> flexiondotorg: what fog? did you try to apply the patch yourself?
[09:11] <flexiondotorg> didrocks, I don't understand the remark about translators.txt not being in the patch. translators.txt is the output from a utility script and not intended for packaging. This is why it is missing from the debdiff.
[09:11] <didrocks> not sure how you generated your patch, but it wasn't against upstream ones
[09:12] <didrocks> flexiondotorg: it's in the pathc
[09:12] <didrocks> diff -Nru mate-tweak-3.4.6/translators.txt mate-tweak-3.4.7/translators.txt
[09:12] <didrocks> --- mate-tweak-3.4.6/translators.txt2015-03-10 19:29:50.000000000 +0000
[09:12] <didrocks> +++ mate-tweak-3.4.7/translators.txt2015-04-01 21:01:28.000000000 +0100
[09:12] <didrocks> flexiondotorg: open it and look :p
[09:12] <flexiondotorg> I used dget -u -x to grab the existing package from Ubuntu. I created a new package locally and ran debdiff.
[09:13] <didrocks> flexiondotorg: seems you didn't do that with the upstream tarball you provided, see my remark about the diffs
[09:13] <didrocks> I took the time to list them all on purpose
[09:15] <flexiondotorg> didrocks, Right. No idea how translators.* got in there. I'll re-create the diff.
[09:15] <didrocks> flexiondotorg: translators isn't the only one to be wrong
[09:15] <didrocks> flexiondotorg: so yeah, please always double check :p
[09:16] <didrocks> flexiondotorg: once you have your debdiff, you need to:
[09:16] <didrocks> dpkg-source -x <old_package>
[09:16] <didrocks> wget your tarball, mv tarball_version.orig.tar.gz
[09:16] <didrocks> cd old_package_dir/
[09:16] <didrocks> patch -p1 < /path/to/your/debdiff
[09:16] <didrocks> debuild -S
[09:16] <didrocks> and that should succeed
[09:17] <didrocks> if not, you did something wrong in the generation
[09:18] <Mirv> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
[09:22] <flexiondotorg> didrocks, Thanks for the explanation. Very helpful.
[09:23] <didrocks> flexiondotorg: yw ;)
[09:58] <Laney> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[09:58] <Laney> fail... retry later :(
[10:13] <Odd_Bloke> I'm seeing failures of the CPC image builds on the buildds because cpio is missing; does anyone have any insight in to this issue?
[10:13] <Odd_Bloke> mvo: ogra_: ^ ?
[10:14] <ogra_> Odd_Bloke, i saw a fix for that uploaded somewhere
[10:14] <ogra_> i think slangasek did it
[10:15] <Odd_Bloke> ogra_: We're still seeing the failures at the moment; was the fix in livecd-rootfs, or somewhere else?
[10:15] <ogra_> Odd_Bloke, https://launchpad.net/ubuntu/+source/live-build/3.0~a57-1ubuntu16
[10:16] <Odd_Bloke> Ah, yeah, just got there.
[10:16] <Odd_Bloke> Urgh, looks like we have a version of live-build lying around in our PPA; that'll be the problem.
[10:17] <ogra_> hah, yeah
[10:28] <tseliot> Riddell: switching between GPUs won't work in sddm, as it doesn't restart X on log out. So, for now, you might just want to add an entry with the DisplayCommand line in sddm.conf. No further patches are needed. Just make sure that /etc/X11/default-display-manager comes with sddm. I'll simply update gpu-manager not to exit when dealing with sddm
[10:36] <pitti> hey tseliot, happy birthday!
[10:39] <ogra_> oh !
[10:39] <ogra_> happy birthday tseliot !
[10:39] <tseliot> pitti, ogra_: thanks :)
[10:49] <flexiondotorg> didrocks, Could you give this a once over and let me know if this suitable? https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1439380/comments/5
[10:50] <ubottu> Launchpad bug 1439380 in mate-menu (Ubuntu) "Updated translations for mate-menu [debdiff attached]" [Low,Incomplete]
[10:50] <flexiondotorg> didrocks, Test the patch applies cleanly and if this is suitable I'll prepare the other patch in the same fashion.
[10:50] <flexiondotorg> didrocks, *I've tested the patch applies cleanly
[10:50] <didrocks> flexiondotorg: please check with the patch pilot first rathe than direct ping :)
[10:50] <didrocks> rather*
[10:51] <flexiondotorg> didrocks, OK
[10:51]  * flexiondotorg waits for a pilot.
=== LocutusOfBorg is now known as LocutusOfBorg1
[11:02] <shadeslayer> mvo: any news on the rootfs for Kubuntu Plasma 5?
=== LocutusOfBorg1 is now known as LocutusOfBorg
=== LocutusOfBorg is now known as LocutusOfBorg1
[11:42] <Odd_Bloke> mvo: Any idea who I can poke to get a live-build patch looked at?  (Specifically https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1411310)
[11:42] <ubottu> Launchpad bug 1411310 in live-build (Ubuntu) "[PATCH] Enable tuning of EXT images produced by lb_binary_rootfs" [Undecided,New]
[11:53] <flexiondotorg> didrocks, I know you said not to ping directly. Sorry. But I've hit a snag. Need some advice, because I'm guessing this is something that has been seen before.
[11:53] <flexiondotorg> https://launchpad.net/ubuntu/+source/mate-tweak/
[11:53] <flexiondotorg> Has a patch accepted into the Ubuntu package.
[11:54] <flexiondotorg> That patch was never shared with upstream (me).
[11:54] <flexiondotorg> I have incorporated the fix upstream and have a new upstream tarball.
[11:55] <flexiondotorg> But creating a debdiff between 3.4.6-0ubuntu2 and the new 3.4.8-0ubuntu1 results in a rejection.
[11:55] <didrocks> hum? what rejection?
[11:55] <flexiondotorg> One sec...
[11:55] <didrocks> you need to remove the patch
[11:55] <didrocks> after unapplying it
[11:55] <flexiondotorg> didrocks, I have.
[11:55] <didrocks> quilt pop -a
[11:55] <didrocks> rm debian/patches/<your_patch>
[11:56] <flexiondotorg> Oh, this is new information :)
[11:56] <didrocks> vim debian/patches/series -> remove your patch
[11:56] <flexiondotorg> didrocks, I don't have any patches. The patch has only ever existed in Ubuntu.
[11:57] <didrocks> 13:53:48  flexiondotorg | Has a patch accepted into the Ubuntu package.
[11:57] <didrocks> this contradicts yourself? ^
[11:58] <flexiondotorg> didrocks, The patch was accepted into Ubuntu. Yes. I didn't not submit it.
[11:58] <flexiondotorg> didrocks, The 'debian' packaging for mate-tweak is maintained in alioth
[11:58] <didrocks> double negation "didn't not submit" -> you did submit?
[11:59] <flexiondotorg> I did not submit the patch to Ubuntu.
[11:59] <didrocks> flexiondotorg: I still don't get what you mean at all, if the patch wasn't in the ubuntu package, why talking about it?
[11:59] <didrocks> and how would it interfere in your update?
[11:59] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1433562
[11:59] <ubottu> Launchpad bug 1433562 in mate-tweak (Ubuntu) "Translations are not reflected" [Undecided,Fix released]
[12:00] <didrocks> so
[12:00] <didrocks>   * debian/patches/translationfix.patch: added for fixing a wrong path.
[12:00] <didrocks>     (LP: #1433562)
[12:00] <didrocks> you did add the patch
[12:00] <didrocks> right?
[12:00] <flexiondotorg> No.
[12:00] <flexiondotorg> I only saw that bug after it had been uploaded.
[12:01] <didrocks> http://launchpadlibrarian.net/201198800/mate-tweak_3.4.6-0ubuntu1_3.4.6-0ubuntu2.diff.gz
[12:01] <didrocks> -> the patch is in the package
[12:01] <didrocks> so ubuntu has this patch
[12:01] <didrocks> hence, follow what I told above to remove it, before updating ^
[12:02] <Odd_Bloke> mvo: (I just resubmitted our livecd-rootfs MP as well)
[12:04] <flexiondotorg> didrocks, OK. I will follow what you've explained. Thank for helping.
[12:04] <flexiondotorg> didrocks, One last question though.
[12:04] <flexiondotorg> didrocks, I am maintaining the package in Debian and, in general, syncing to Ubuntu.
[12:05] <flexiondotorg> didrocks, Would a syncrequest from Debian (where that Ubuntu patch has never existed) still work?
[12:05] <didrocks> flexiondotorg: sure, just justify why the diff between Debian and Ubuntu can be dropped in the bug report, and we can override the sync request with it
[12:06] <flexiondotorg> didrocks, I'm not going to sync on this occasion. I think it is important I learn all these techniques.
[12:06] <flexiondotorg> didrocks, Also forgive my typos. I have a badly mashed right hand and sometime my text prediction is a little off.
[12:06] <didrocks> flexiondotorg: ah ok, so when you sync request, there is a process to read: https://wiki.ubuntu.com/SyncRequestProcess
[12:07] <didrocks> heh, no worry :)
[12:07] <flexiondotorg> didrocks, I'm familiar with the syncrequest process. I've used it quite extensively :)
[12:08] <didrocks> flexiondotorg: see the lines about the diff between Ubuntu and Debian
[12:08] <didrocks> or reread them rather :)
[12:08] <flexiondotorg> didrocks, Will do :)
[12:21] <flexiondotorg> didrocks, I've got this this - dpkg-source: info: you can integrate the local changes with dpkg-source --commit
[12:37] <flexiondotorg> didrocks, I'm clearly missing a step here.
[12:41] <flexiondotorg> didrocks, http://paste.ubuntu.com/10761683/
[12:41] <flexiondotorg> What next?
[12:52] <cyphermox> good morning!
[12:54] <mdeslaur> hi cyphermox!
=== _salem is now known as salem_
[13:50] <didrocks> flexiondotorg: well, then, update your package with uupdate as you usually do
[14:48] <wuzhongcheng> i need help
[14:48] <wuzhongcheng> i"m a chinese
[14:48] <wuzhongcheng> now i use puppy 5.7.1
[14:58] <wuzhongcheng> i like ubuntu
[15:00] <flexiondotorg> didrocks, I've never had to use uupdate before. I have just used it yet I am still in the position where I have rejections :(
[15:03] <wuzhongcheng> hoe do you do
[15:03] <wuzhongcheng> how do you do
[15:04] <infinity> pitti: I'd had a long discussion with him on IRC about it, and he was on CC in my response to you afterward and didn't object to the "belt and bracers" approach of implementing both options, but it never hurts to ask again, I suppose.
[15:04] <wuzhongcheng> :)
[15:04] <wuzhongcheng> :)
[15:05] <wuzhongcheng> sorry my english is bad
[15:06] <didrocks> flexiondotorg: seems you need to read some packaging documentation :)
[15:06] <flexiondotorg> didrocks, Well, I am doing :)
[15:07] <flexiondotorg> didrocks, But I have rebuilt the debdiff about 4 different ways now and end up at the same place.
[15:07] <rbasak> hallyn: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1439988
[15:07] <ubottu> Launchpad bug 1439988 in init-system-helpers (Ubuntu) "package init-system-helpers 1.22ubuntu4 failed to install/upgrade: trying to overwrite '/lib/init/apparmor-profile-load', which is also in package upstart-bin 1.13.2-0ubuntu9" [High,Confirmed]
[15:07] <rbasak> hallyn: this was my mistake that you spotted - s/upstart/upstart-bin/ needed in Breaks/Replaces.
[15:08] <rbasak> hallyn: I guess I'll just upload this fixed?
[15:08] <dobey> wuzhongcheng: i think you are looking for #ubuntu as itis the general help channel
[15:08] <hallyn> rbasak: oh?  but after i had said that i checked the pkg again and it actually was coming from upstart, not upstart-bin
[15:09] <dobey> wuzhongcheng: i think there might be another channel for kylin too
[15:10] <hallyn> rbasak: hm.  maybe i looked at the upstart version when i was doing that
[15:10] <hallyn> rbasak: yes, please do, thx
[15:10] <hallyn> grrr
[15:10] <hallyn> s/upstart/utopic/
[15:10] <hallyn> !4:s/upstart/utopic
[15:12] <rbasak> hallyn: no, I think you were right.
[15:12] <rbasak> So I'm confused now. I see it present in upstart_1.13.2-0ubuntu10_amd64.deb
[15:12]  * rbasak checks 9
[15:12] <hallyn> rbasak: changelog says it got moved, but maybe the changelog lied?
[15:15] <rbasak> hallyn: I also see it in upstart_1.13.2-0ubuntu9_amd64.deb but also in upstart-bin_1.13.2-0ubuntu9_amd64.deb.
[15:15] <rbasak> Only in upstart in ubuntu10.
[15:15] <hallyn> weird
[15:15] <rbasak> Easiest to just declare Breaks/Replaces against both in ubuntu10 I guess.
[15:15] <hallyn> bc debian/upstart.install:debian/apparmor-profile-load lib/init/
[15:15] <hallyn> yeah
[15:16] <rbasak> I'll do it.
[15:16] <hallyn> you'd think ppl would have gotten conflicts between upstart and upstart-bin then
[15:17] <hallyn> rbasak: upstart-bin seems to be an empty package though, and depends on upstart.
[15:17] <rbasak> Indeed. I don't see B/R across ubuntu9 upstart and upstart-bin that is relevant. Yeah - upstart-bin is an empty package now, but it wasn't in ubuntu9.
[15:18] <hallyn> ok so b/r both is safest.  thanks
[15:18] <rbasak> Anyway, I'll just fix it in init-system-helpers and not worry about the upstart side of things. That would be a separate temporary bug that is gone now.
[15:20] <hallyn> right - again surprised there were no upgrade bugs due to that
[15:20] <infinity> pitti: To be fair, when talking to him about it, he said he didn't want to do anything without your opinion.  You're like two parents who are never home at the same time. :P
[15:25] <infinity> rbasak: You're seeing things, it wasn't in upstart_1.13.2-0ubuntu9_amd64.deb
[15:26] <rbasak> infinity: now I look again and you're right.
[15:27] <rbasak> The fix I uploaded should still be good. I presume having a slightly higher than necessary version for one of the Breaks/Replaces shouldn't matter.
[15:28] <infinity> rbasak: Yeah, it'll be fine.  If LP ever gives me a diff.
[15:28]  * infinity downloads it from the queue instead.
[15:31] <infinity> rbasak: Minor complaint that (<= 1.13.2-0ubuntu10) is more safely written as (<< 1.13.2-0ubuntu11) in case people are building derivative packages from ours.
[15:31] <infinity> rbasak: But since upstart has moved on to -0ubuntu12 since then, and it's unlikely anyone picked that day to fork, the point's probably moot.
[15:32] <rbasak> infinity: point taken, thanks.
[15:32]  * rbasak will amend his ways
[15:46] <hallyn> 15:31 < infinity> rbasak: Minor complaint that (<= 1.13.2-0ubuntu10) is more safely written as (<< 1.13.2-0ubuntu11) in case people are building derivative packages from ours.
[15:46] <hallyn> ah.  i've been looking for reasons to go one way or th eother
[15:46] <hallyn> that makes sense
[15:48] <infinity> hallyn: It's not exactly foolproof, as someone could build a 1.13.2-0ubuntu10billy02 that cherrypicks our changes from 11, but it's statistically safer to assume they didn't.
[15:48] <infinity> hallyn: (much like it's statistically safer to assume 1.2.3-3ubuntu1 is similar to 1.2.3-3)
[15:49] <rbasak> Also if they're going to cherry-pick changes from the future then they should get to keep the pieces when it breaks (since nobody else can).
[15:49] <rbasak> cf. it makes sense to make things work by default when there are no related changes
[15:49]  * infinity nods.
[15:49] <pitti> infinity: haha; sounds good then :)
[15:50] <hallyn> well, yeah, i am also inconsistent about whether i do 1.13.2-2test1 or 1.13.2-3~test1
[15:50] <hallyn> but both are << 1.13.2-3, so taht's ok
[15:50] <hallyn> i guess
[15:50] <infinity> hallyn: Right.
[15:51] <rbasak> 1.13.2-3~test1 is useful before 1.13.2-3 is published if you want 1.13.2-3~test1 to eventually upgrade to 13.2-3.
[15:51] <rbasak> Say I'm testing something before upload in a PPA for example.
[15:51] <infinity> Both upgrade, though.  So, meh.
[15:51] <rbasak> Oh. -*2*. I see.
[15:52] <pitti> infinity: so that change is in vivid-proposed now, FTR
[15:52] <pitti> infinity: I'm just not sure whether we should squeeze it into jessie still
[15:52] <infinity> My personal non-concrete rule for such things is "-2test1" is for a package that is "-2 with a quick patch on top" and "-3~test1" is "the package that will eventually be -3, but not quite ready yet".
[15:52] <infinity> pitti: Well, I intend to file an unblock for the sysvinit upload I did to jessie, unblocking both together would make sense.
[15:53] <hallyn> heh, logical
[15:53] <infinity> pitti: It doesn't catch a lot of extra cases, but it still catches some different cases, so feels reasonable.
[15:53] <pitti> infinity: ack
[15:53] <infinity> pitti: I still would prefer doing it "right" in C, but at least this is provably non-invasive.
[15:55] <Anupkumar> pitti: ping
[15:56] <infinity> pitti: Oh, and I see you (hopefully) fixed your racy tests.  \o/
[15:57] <mitya57> cyphermox, hi, can you please take a look at https://code.launchpad.net/~mitya57/network-manager-applet/lp1440009/+merge/255224 ?
=== matsubara__ is now known as matsubara
[15:58] <mitya57> I understand that it is an ugly hack, but it will be only for this cycle — the patch to solve it properly on our side is quite large to apply it during the final freeze.
[15:59] <cyphermox> isn't there a way to integrate this better into the shell test?
[16:02]  * mitya57 looks
[16:02] <rbasak> pitti: could you respond to https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1436691/comments/19 please? I take it this isn't an issue as the manifest file doesn't reflect what will actually get installed?
[16:02] <ubottu> Launchpad bug 1436691 in upstart (Ubuntu) "Essential files are missing" [High,Confirmed]
[16:03] <rbasak> pitti: the only issues I've seen are on systems I suspect didn't use the normal installer path, which is why I asked for apport-collect. But I don't think that's the case here. It might just be that the user has a heavily customised system.
=== MacSlow is now known as MacSlow|latelunc
[16:09] <infinity> rbasak: An upgrade should be pulling in systemd-sysv.  If that's not true for ubuntu-gnome, we've messed up somehow.
[16:10] <rbasak> infinity: I don't think we're seeing enough bug reports for that to be the case. The few we're getting are I think users who have heavily modified their systems in some way, where we can't really expect to support the upgrade path.
[16:11] <rbasak> I just want to get the bugs resolved and invalidated where appropriate.
[16:11] <mitya57> cyphermox: Currently nm_shell_watcher thinks that if ShellVersion is not present, then it is gnome-shell but it is not properly initialized. I don't think I want to break that behaviour.
[16:11] <infinity> Right, so #1436956 is clearly a non-standard install, but the sort we were afraid of...
[16:12] <mitya57> cyphermox, So checking the XDG_CURRENT_DESKTOP is the easiest temporary solution.
[16:12] <cyphermox> fair enough
[16:12] <infinity> pitti: What was the reason we decided not to make init Essential, like Debian did?
[16:12] <cyphermox> mitya57: can you upload or do you need sponsoring?
[16:13] <mitya57> I can upload if you ack it
[16:13] <infinity> pitti: It does seem to be biting people on upgrades without -minimal installed, as we feared would be the case.
[16:13] <cyphermox> mitya57: just did :)
[16:13] <mitya57> Thanks!
[16:19] <pitti> Anupkumar: hello
[16:19] <infinity> rbasak: I dunno, I might be in the minority, but I still see this as a real bug.  We can jump up and down and say "we don't support systems without ubuntu-minimal installed" all we want, but that doesn't make their upgrades less broken.
[16:19] <infinity> pitti: ^
=== quadrispro is now known as alessio_test
[16:21] <pitti> rbasak, infinity: "init" should be essential, and pull in either systemd-sysv or upstart-sysv
[16:21] <pitti> ah no, it's "required"
[16:21] <infinity> pitti: Okay, so we just messed up and forgot to mark it Essential?
[16:22] <pitti> maybe for schroots or so, where neither is required; xnox?
[16:22] <infinity> pitti: Sure, neither is actually required in a chroot, but a tiny bit of chroot bloat to make upgrades actually work is a small price to pay (my Debian chroots have init installed).
[16:23] <pitti> infinity: yes, I'm fine with making it essential
[16:24] <pitti> +    - init: Drop Essential:yes, in Ubuntu upstart is not essential.
[16:24] <pitti> was the changelog entry
[16:25] <pitti> infinity: fixing race conditions> apparently not hard enough, argh
[16:25] <infinity> pitti: D'oh.
[16:26] <infinity> pitti: Alright, let's try making it Essential again and see if that blows up any of our carefully-orchestrated ubuntu/ubuntu-touch madness.
[16:26] <infinity> It shouldn't, since we never remove "init", only swap its deps.
[16:26] <pitti> infinity: right
[16:26] <infinity> pitti: I'll toss that upload at the archive.
[16:34] <infinity> pitti: Yeah, so, my vague recollection is that we actually intended to make it Essential as part of the systemd switch and just kinda maybe forgot. :P
[16:34] <infinity> pitti: But I'm old, so I could be fabricating memories to make my life more pleasant.
[16:39] <infinity> pitti: I suppose the other gross hack that would sort of work would be to have upstart "Recommends: systemd-sysv | upstart-sysv", but that would also break people who install without recommends (and a Depends would be a lie).
[16:39] <infinity> pitti: So, meh.  One wart or the other, we can drop init out of Essential after 16.04, don't really care.  upstart was transitively Essential for years too, entirely by accident. :P
=== salem_ is now known as _salem
=== _salem is now known as salem_
[16:52] <teward> is jenkins broken again?
[16:53] <strikov> Hi pitti. We have juju-1.22.0 uploaded to -proposed which passes juju team's QA tests (it can provision trusty and precise) and my manual adt-run against vivid image with upstart installed. It doesn't pass automatic adt-run due to the lack of systemd support. I made decision not to update autotests because we'll be required to revert all these changes back while packaging 1.23. Could you help us to manually move the package to release pocket?
[16:53] <strikov> pitti: Additional information can be found in the bug: https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1416051 Thanks!
[16:53] <ubottu> Launchpad bug 1416051 in juju-core (Ubuntu Trusty) "juju-core 1.22.0 is not packaged in Ubuntu" [Undecided,New]
[16:56] <infinity> strikov: I thought the whole reason we weren't letting in was because of the lack of systemd support, and we were told that was happening ASAP.
[16:57] <strikov> infinity: that is fixed in 1.23 which is in beta; my plan is to upload 1.22 and start to work on 1.23
[16:57] <strikov> infinity: it usually takes some time because d/copyright is pretty complex for golang package
[16:57] <infinity> strikov: "Start work on" doesn't sound as "ASAP" as we were promised weeks ago. :/
[16:59] <strikov> infinity: well, we can't upload 1.23 until juju team releases it :) i can do *some* licensing checks earlier but we need to wait until the release anyway I think
[16:59] <infinity> strikov: Anyhow, the bug log looks "good enough" for letting it in.
[17:00] <infinity> strikov: But gating on juju upstream to polish off 1.23 rather than backporting/cherrypicking the required bits to support systemd is going to make the release team very grumpy with all of you, given that the release is 2.5 weeks out.
[17:01] <infinity> strikov: Of course, the problem with your tests not passing in any way is also that your deps (like lxc) could break juju completely, and we'll never catch it.
[17:01] <infinity> Well, not until it's too late.
[17:04] <strikov> infinity: adt tests pass when i use vivid image with upstart installed; i may misunderstood your point but i run these tests that way to avoid missing anything which is verified by tests
[17:04] <infinity> strikov: My point is that we re-run the tests automatically when your dependencies change.
[17:04] <infinity> strikov: You miss out on the benefit of that when your tests can't be run automatically.
[17:05] <strikov> infinity: Ah, that's a good point. I agree. The only argument I have is that I plan to upload 1.23 very soon. it won't have systemd issue.
[17:11] <teward> hey infinity, do you have access to see whether a job that jenkins emailed me about actually exists?
[17:12] <infinity> teward: Maybe.
[17:13] <infinity> teward: Depends on the job, I suppose. :P
[17:15] <infinity> pitti: So, making init essential plumps up my chroots by ~20-30 MB (depending on arch) after I'd just cleaned them out to make them init system free, but I don't think that's world-ending.
[17:15] <infinity> Besides, chubby chroot is pleasantly alliterative.
[17:16] <teward> infinity: well jenkins mailed me on a failure at https://jenkins.qa.ubuntu.com/job/vivid-adt-nginx/47 but I get 404s.
[17:17] <infinity> teward: Ahh, the public mirror seems to be a bit behind reality.
[17:17] <infinity> teward: 47 exists and did indeed fail, and 48 is in progress as a retry.
[17:18] <infinity> And I completely forget who's in charge of the public mirror bits.
[17:18] <teward> mmm
[17:18] <teward> infinity: ok.  i don't have the private access so i have no idea what's up with the failures, if anything.
[17:19] <teward> kinda curious every time i see those emails xD
[17:19] <infinity> Ugh.  The failure was not yours, if that's comforting.
[17:19] <teward> that's a positive.
[17:19] <teward> 'tis all i really worried about :0
[17:19] <teward> :) *
[17:20] <infinity> I'm less enthused.
=== FunnyLookinHat_ is now known as FunnyLookinHat
[17:20] <teward> mmm
[17:20] <teward> well i'm more comforted, but still curious, alas that's my nature :P
[17:22] <infinity> mvo: test-apt-download-progress really, really, really doesn't like you.
[17:24] <infinity> teward: Not sure what it was that broke your tests, actually.  It smells like an apt bug, but on a retry it was fine, so maybe just a weird archive inconsistency...
[17:24] <teward> infinity: i've had nondeterministic failures in nginx builds too, so i'm used to seeing that every once in a while.
[17:25] <teward> infinity: if it failed twice i'd be more concerned, but one fail and one complete on retry makes me even less concerned
[17:25] <infinity> teward: Yeah.  Well, any failures concern me, because it's hard to have a stable baseline to compare to when none of the tests (or the infrastructure) are stable.  Getting there, though.  Slowly.
[17:39] <pitti> strikov: yes, I already unblock packages which are held up by the failing juju
[17:40] <pitti> strikov: why would you need to revert the changes? I thought you wanted to update the tests so that they work on any relese?
[17:40] <pitti> infinity: sounds ok to me, especially as we can revert it in 16.10 if we care
[17:40] <strikov> pitti: they will work w/o any changes at all :) on trusty they will test upstart (because it's default init there), on vivid they will test systemd
[17:43] <strikov> pitti: i had an idea to test both systemd and upstart on vivid but came to conclusion that it's not needed
[17:44] <strikov> pitti: because it leads to some corner cases when host runs vivid/upstart but juju-local lxc container runs vivid/systemd
[17:44] <strikov> pitti: and i came to conclusion that simplest option is the best one
[17:45] <infinity> strikov: FWIW, I already (grudgingly) let it in.
[17:45] <pitti> strikov: ack
[17:45] <infinity> strikov: But please push your upstream to get us 1.23 ASAP, like actually ASAP, and if you can work on the packaging from their current trunk, rather than waiting for the code to drop, that would be great too.
[17:48] <strikov> infinity: pitti: thanks; i'll start looking into 1.23 tomorrow morning; will be using what i have for now
[17:49] <pitti> strikov: yay
[18:04] <mdeslaur> cyphermox: can you take a look at my debdiff in bug 1440166 when you get a minute?
[18:04] <ubottu> bug 1440166 in network-manager-applet (Ubuntu) "network indicator displays notifications for virtual devices" [Undecided,New] https://launchpad.net/bugs/1440166
=== MacSlow|latelunc is now known as MacSlow
[18:05] <infinity> pitti: FWIW, the occasional apt failures on systemd-sysv/systemd are probably because of the Pre-Depends, which should just be a Depends.
[18:05] <infinity> pitti: Not that that isn't an apt ordering bug (it is), but making apt's life less painful there might be nice.  Unless systemd-sysv actually has a preinst that requires systemd.
[18:06] <infinity> pitti: Which it doesn't.
[18:09] <infinity> mbiebl: Was there a reason why systemd-sysv Pre-Depends on systemd instead of just Depends, or just an oops/misunderstanding of how dpkg deps work?
[18:11] <teward> infinity: indeed.  i can understand that
[18:14] <infinity> Ahh, eww.
[18:14] <infinity>   * Add Pre-Depends on systemd to systemd-sysv, to avoid risking that the
[18:14] <infinity>     sysv-compatible symlinks become dangling on a partial install.
[18:17] <stormbrew-> infinity: I was told to bring this up with you (or doko? Who doesn't appear to be in here right now): There's a pretty severe bug in the libstdc++6 version 5 package in ubuntu-toolchain-r/test where std::error_codes are all comparing unequal: https://gist.github.com/stormbrew/e877b39aa060f19f16dc
[18:18] <stormbrew-> (told by ogra_ in the #ubuntu-bugs channel)
[18:19] <infinity> stormbrew-: Probably best to file a bug upstream or email doko, or both.
[18:28] <infinity> stormbrew-: FWIW, it looks like it's an ABI break.  If you recompile with g++-5 from the same PPA, it returns 0 as you expect, it's only compiling with 4.9 and running with 5.0 that breaks.
[18:29] <infinity> stormbrew-: But, yeah, I'd take that knowledge and file an upstream bug report and email doko about it before he decides to unleash that compiler on the world.
[18:30] <infinity> stormbrew-: Upstream's answer might be "sucks to be you, we warned you that -std=c++11 was experimental", but still worth reporting.
[18:36] <stormbrew-> ah, interesting. That's good to know. I'll do that as soon as I have the cycles for it, thanks.
[19:20] <cyphermox> mdeslaur: yup
[19:21] <cyphermox> mitya57: did you already upload your gnome flashback fix?
[19:21] <mdeslaur> cyphermox: cool, thanks!
[19:21] <cyphermox> nevermind, I see it was
[20:20] <mvo> infinity: meh, is that test still failing?
[20:27] <hallyn> ok, systemd continues to confound me:
[20:27] <hallyn> ubuntu@lv1:~/new$ sudo systemctl stop libvirt-bin
[20:27] <hallyn> ubuntu@lv1:~/new$ ps -ef | grep libvirt
[20:27] <hallyn> ubuntu   19003   908  0 16:26 pts/1    00:00:00 grep --color=auto libvirt
[20:27] <hallyn> root     25509     1  0 15:58 ?        00:00:00 /usr/sbin/libvirtd -d
[20:27] <ubottu> Ubuntu bug 19003 in xorg (Ubuntu) "Error when trying to use other keyboard layout than us in breezy" [Medium,Fix released] https://launchpad.net/bugs/19003
[20:27] <hallyn> systemctl stop doesn't seem to work
[20:29] <hallyn> oh, bc systemd thinks that /etc/init.d/libvirt-bin stop is the way to stop it
[20:30] <hallyn> pitti: ^ i guess we really do need a systemd unit for libvirt, or at least a aysvinit script back, bc the current way really is broken
[20:33] <mbiebl> hallyn: http://paste.debian.net/165569/
[20:33] <mbiebl> the sysv init script and the service file should have the same name
[20:34] <mbiebl> or if they use different names, provide a symlink
[20:35] <mbiebl> which package does provide /etc/init.d/libvirt-bin?
[20:35] <mbiebl> is that an obsolete conffile?
[20:38] <dobey> mbiebl: dpkg -S tells you what installed package owns it, if any
[20:38] <mbiebl> dobey: I do know that
[20:39] <mbiebl> (I do run Debian here, which doesn't ship /etc/init.d/libvirt-bin)
[20:39] <Unit193> !find /etc/init.d/libvirt-bin vivid
[20:39] <ubottu> Found: W:, W:, W:
[20:39] <Unit193> !find /etc/init.d/libvirt-bin vivid
[20:39] <ubottu> File /etc/init.d/libvirt-bin found in libvirt-bin
[20:47] <infinity> mvo: It sure it.
[20:47] <infinity> mvo: is...
[20:47] <hallyn> mbiebl: hm, i was thinking that /etc/init.d/libvirt-bin was a wrpaper around the /etc/init/libvirt-bin (as it used to be at one point),
[20:48] <hallyn> still i think it's better to provide a proper systemd unit for it than to figure out why the sysv script isn't working under systemd :)
[20:54] <infinity> hallyn: Stopping works for me...
[20:55] <hallyn> infinity: ok, good to know - must be something i've got locally then, thanks
[20:55] <infinity> hallyn: http://paste.ubuntu.com/10766403/
[20:57] <hallyn> infinity: i have no clue what's going on then, but on this instance it's 100% reproducible that libvirt doesn't die, and after the fact, systemctl status libvirt-bin shows:
[20:57] <hallyn>   Process: 20817 ExecStop=/etc/init.d/libvirt-bin stop (code=exited, status=0/SUCCESS)
[20:58] <hallyn> oh COME ON
[20:58] <hallyn> now its gone away
=== salem_ is now known as _salem