[01:24] <pabs3> hi folks. I discovered that 91.189.94.232, which is part of assets.ubuntu.com has an SSL cert that is invalid and is different to the other assets.ubuntu.com IPs. where should I report this?
[01:27] <sarnold> hey pabs3 :)
[01:31] <sarnold> pabs3: I've passed it along to IS, thanks
[01:39] <pabs3> oh, cool, thanks sarnold :)
[06:03] <pitti> tjaalton: yes, tag them with "systemd-boot"
[06:04] <Unit193> Not 'systemd-doesnt-boot'? /me ducks
[06:04] <pitti> rlaager: cron.service, like most *.service has DefaultDependencies=yes (that's the default) and hence runs way after local-fs.target and basic.target; see bootup(7) and systemd.special(7)
[06:04] <pitti> Unit193: hehe
[06:05] <rlaager> pitti: How can I verify that cron.service is starting after local-fs.target. I'm pretty sure it is not, but again, I'm new to systemd.
[06:06] <pitti> rlaager: it is, but feel free to look at systemctl list-dependencies cron.service
[06:07] <rlaager> One of the suggestions the other guy made was that maybe we have a loop, and systemd is breaking it in some non-optimal way.
[06:07] <pitti> rlaager: if you have a dependency loop, you can see that in journalctl; perhaps do "journalctl -p warning" to filter out the noise, there you see them quite nicely
[06:13] <rlaager> What do I need to specify in a service to make local-fs.target depend on it?
[06:17] <rlaager> pitti: You are correct. It seems I had a completely unrelated problem. I'm sorry for the noise.
[06:18] <pitti> rlaager: you do DefaultDependencies=no, Before=local-fs.target, and [Install]\nWantedBy=local-fs.target (unless you enable it statically, i. e. ship the symlink in the package)
[06:19] <rlaager> pitti: So an unrelated, and still reproducible problem... The initramfs complains about "Target filesystem doesn't have requested /sbin/init" unless I specify init=/lib/systemd/systemd on the Linux command line.
[06:19] <pitti> rlaager: you need to be careful with these services, though: they can rely on pretty much nothing except that you have a r/o root fs and /proc, /sys/, /dev mounted (and lo)
[06:20] <pitti> rlaager: what is your /sbin/init ?
[06:23] <rlaager> From the initramfs after that error, if I ls /sbin/init, I get: /sbin/init -> /lib/systemd/systemd
[06:23] <rlaager> I wonder if I have a mismatch between the root filesystem and the initramfs.
[06:24] <pitti> rlaager: that sounds like bug 1421117
[06:24] <pitti> but it was fixed a week ago already
[06:24] <rlaager> I updated today before joining this channel.
[06:25] <pitti> rlaager: if you have current initramfs-tools (i. e. current vivid), please give me the output of "lsinitramfs /initrd.img|grep chroot"
[06:28] <rlaager> pitti: The output was the empty string. I rebuilt the initramfs and now I have one. And of course it works now. So I guess that was more noise. Thanks.
[06:28] <pitti> rlaager: weird that updating initramfs-tools didn't update the initramfs then
[06:29] <pitti> "sudo apt-get install --reinstall initramfs-tools" -> rebuilds it here, hmm
[06:29] <pitti> rlaager: anyway, if you can reproduce that somehow, a bug report is appreciated
[06:31] <tjaalton> pitti: done
[06:34] <rlaager> pitti: It rebuilds for me with apt-get install --reinstall. So I can't reproduce it.
[06:45] <tjaalton> pitti: looks like the apache fail is actually related to mod_nss, if it's enabled apache2 restart fails
[06:45] <pitti> tjaalton: there's also a ton of test regressions, that might be related?
[06:45] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apache2
[06:45] <tjaalton> I'll check
[06:46] <pitti> sh: 1: gcc: not found
[06:46] <pitti> well, that's something different obviously
[06:46] <pitti> ah, and doesn't make it fail,it's just a sloppy test
[06:46] <pitti> test ssl-passphrase failed
[06:46] <pitti> Job for apache2.service failed. See "systemctl status apache2.service" and "journalctl -xe" for details.
[06:47]  * pitti fixes ofono-phonesim
[06:57] <pitti> ... and goes on to udisks2
[06:57] <pitti> AH00015: Unable to open logs
[06:57] <pitti> tjaalton: oh, does apache require /var/log to be "syslog" writable?
[06:58] <pitti> (but systemd in -proposed fixes that, hmm
[06:58] <tjaalton> not sure
[06:58] <tjaalton> I'm still trying to verify if it's just mod_nss that causes my error.. leaves a socket behind or such
[07:16] <mitya57> Mirv, you can now sync qtwayland & sip4 & pyqt5 to landing-012
[08:18] <dholbach> good morning
[08:20] <seb128> hey dho
[08:20] <seb128> hey dholbach
[08:20] <dholbach> hi seb
[08:20] <dholbach> hi seb128
[08:20] <seb128> :-)
[09:50] <tsdgeos> who do i need to tell so that our gcc packages are updated with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309 ?
[10:06] <cjwatson> tsdgeos: File a bug on the Ubuntu gcc-4.9 source package, and give doko_ a heads-up if it's urgent
[10:07] <Laney> bluesabre: did you file a bug about that wrong icon in dialog issue?
[10:09] <flexiondotorg_> pitti, What time will you be piloting today?
[10:13] <tsdgeos> cjwatson: tx
[10:21] <pitti> jamespage, zul: I checked why heat's autopkgtest fails, and it is because debian/rules is apparently missing a dh_systemd_enable call
[10:22] <pitti> it's easiest to do this with "--with systemd"
[10:22] <jamespage> pitti, ack
[10:22] <pitti> flexiondotorg_: RSN I hope, still firefighting
[10:22] <doko> tsdgeos, better check first if it's already fixed
[10:23] <tsdgeos> doko: well it was not fixed yesterday when i filled the bug
[10:23] <tsdgeos> i'm sorry i didn't check again
[10:29] <flexiondotorg_> pitti, I've got a couple of thorny package updates. When you're piloting feel free to ping me if you have questions.
[10:30] <didrocks> flexiondotorg_: just put them in the queue, I'll co-pilot this afternoon
[10:30] <didrocks> so first one who gets it will pick them :)
[10:30] <flexiondotorg_> didrocks, They are in the queue :) But your will see a couple have some history now. So if you have questions please ask.
[10:31] <didrocks> flexiondotorg_: we always do that (asking if we have questions), don't worry :)
[10:57] <geser> pitti: I read your announcement on switching to systemd by default on monday. Is it planned that booting with upstart as a fallback should continue to work on newly installed systems (fresh installed with systemd as default)? If yes, then perhaps someone should fix bug #1422681 before release.
[10:57] <pitti> geser: less urgent, but indeed we should fix that
[10:57] <pitti> xnox: ^ would you be able to look into this?
[11:02] <xnox> pitti: i thought it was all good. let me check.
[11:04] <xnox> pitti: right i remember that now. So we didn't want to move config files to upstart-bin, because there is no sensible way to move config files to a new package.
[11:04] <xnox> or so I thought.
[11:06] <pitti> xnox: it's going to require a lot of mv_conffile stanzas, yeah :/
[11:06] <pitti> is there a way to ship them in /lib somewhere? or only /etc?
[11:06] <xnox> pitti: but one cannot mv_conffile between packages.
[11:07] <xnox> pitti: there is, but it was never in use on non-touch
[11:07] <pitti> xnox: ah, so perhaps just a Replaces: ought to do?
[11:07] <xnox> as long as it doesn't cause dpkg conffile prompts....
[11:18] <infinity> xnox: Replaces won't cause conffile prompts on non-modified conffiles, the only gotcha is that using Replaces to move conffiles can cause modified files to revert to unmodified in an upgrade-with-purge scenario if the unpack order is unexpected.
[11:18] <xnox> infinity: lovely =)
[11:19] <infinity> (Because you completely remove the old one, then install the new one)
[11:21] <infinity> xnox: If upstart pre-depended on upstart-bin intead of just depending, that would probably close that loophole, but at a bit of an ugly cost, given that adding new pre-deps in the required set can be scary unless you're positive there are no loops anywhere.
[11:22] <xnox> infinity: everytime i did any upstart pre-depends or depends when shuffling this split, i ended up exploding upgrades or the buildds....
[11:22] <infinity> xnox: Because a pre-dep would make sure upstart-bin unpacked and took over the files before upstart got a chance to purge the old modified ones.
[11:25] <infinity> xnox: There are other violent ways to do it too, like having the preinst for both intentionally move modified files out of the way and then put them back on postinst.
[11:25] <infinity> xnox: Obviously version-guarded, so it doesn't happen on every upgrade forever.
[11:25] <LocutusOfBorg1> thanks ginggs for the vbox upload!
[11:35] <ginggs> LoctutusOfBorg: no worries :)
[11:36] <ginggs> LocutusOfBorg: no worries :) and I spelled your name correctly this time
[11:38] <pitti> infinity: hm, if you purge upstart, isn't that saying "screw my conffile changes" anyway?
[11:41] <infinity> pitti: If you do "apt-get --purge dist-upgrade", and a "clever" maintainer has decided to move conffiles between packages, the expected result isn't that your conffiles get reset to default.
[11:42] <infinity> pitti: If you manually do "apt-get purge upstart && apt-get install upstart-bin" to upgrade, sure, you get to keep both pieces.
[11:44] <geser> xnox: perhaps move /sbin/init (and the other programs) into upstart-sysv and let systemd-sysv conflict with that if that's easier to do than to move conf files around
[11:46] <xnox> geser: we already have that....
[11:46] <xnox> geser: we have upstart-bin and upstart. upstart ships init/reboot/halt and etc/jobs.
[11:47] <xnox> geser: upstart-bin ships /sbin/upstart which one can use for e.g. user session.
[11:47] <infinity> xnox: Yes, but it also ships the conffiles, which has this problem.  I can see where he's coming from with the solution.
[11:47] <xnox> infinity: geser: oh, make upstart ship the conffiles only?
[11:48] <bluesabre> Laney: not yet, got really busy last night after noticing it
[11:48] <geser> xnox: yes
[11:48] <infinity> xnox: upstart-sysv ships init/reboot/halt and depends on upstart, which ships /etc/init, which depends on upstart-bin
[11:48] <Laney> bluesabre: no worry, I think I fixed it
[11:48] <Laney> test with the gtk that's going to appear in a couple of hours?
[11:48] <bluesabre> sure, will do
[11:48] <xnox> infinity: geser: how will not screw over people who have upstart? i will not able able to put "upstart depends on upstart-sysv"
[11:49] <infinity> xnox: And a dep loop between upstart and upstart-sysv to give smooth upgrades and allow other deps on "upstart" to continue to Just Work would probably be fine.
[11:49]  * xnox ponders i could do "upstart -> depends {systemd-sysv | upstart-sysv}"
[11:50] <infinity> Other way around, I imagine, but yes.
[11:50] <infinity> Ugly, no matter how you slice it.  But prevents you having to move conffiles.
[11:51] <geser> is the split between upstart (conf-files only) and upstart-bin then still needed?
[11:51] <bluesabre> Laney: would you mind ack'ing the other components on here: https://bugs.launchpad.net/ubuntu/+source/xfce4/+bug/1424887 - and with the libxfce4util bump from 6 to 7, we'll need to rebuild a few packages. Should I do the rebuilds after libxfce4util releases from -proposed or do a dep wait for the packages so they can go at once?
[11:52] <bluesabre> (sorry to hijack your attention) :)
[11:52] <infinity> geser: No, probably not.
[11:52] <infinity> geser: They could be re-unified, and upstart-sysv could ship the conflicting bits.
[11:52] <infinity> Which would make the upstart split look like the systemd split, which would be pleasant.
[11:52] <infinity> xnox: ^
[11:54]  * xnox wants to swtich user session to systemd, like right now.
[11:54]  * xnox also wants to bastertise systemd source code to run on touch kernels
[11:54] <infinity> xnox: That'll be a fair bit more work. :/
[11:54] <infinity> xnox: Re-unifying the uptart split and breaking the sysv bits out, though, sounds elegant enough.
[11:55] <xnox> infinity: that's to pam_systemd in vivid all desktops have both systemd & upstart user session running in parallel =)
[11:55] <xnox> infinity: geser: are you volunteering to resplit usptart package then =)
[11:55] <ogra_> pitti, xnox, i heard jolla uses systemd 208 with 3.4 kernel
[11:55] <infinity> xnox: I could do the packaging work if you ask me next week.
[11:55] <infinity> xnox: It would be nice to land the changes in jessie too, though, and I'm not sure how open the Debian release team will be to that.
[11:56] <ogra_> not sure if they patched the kernel for this though
[11:56] <xnox> ogra_: i know, we tool too recent systemd, which dropped bits that let it run on older kernels.
[11:56] <xnox> imho they should be re-introduced.
[11:56] <xnox> pitti: ^
[11:56] <xnox> s/tool/took/
[11:56] <ogra_> we'd carry that forever though
[11:56] <ogra_> is there a way to convince upstream ?
[11:57] <pitti> most certainly not
[11:57] <infinity> Upstream believes that old kernels don't matter, and everyone runs tip of everything always.
[11:57] <pitti> it'd be a huge patch
[11:57] <infinity> There was a very long argument about how this breaks distros upgrading.
[11:57] <xnox> pitti: why the libattr code path was dropped?
[11:57] <infinity> And upstream didn't care.
[11:57] <xnox> (that's just the first bit that i found)
[11:57] <xnox> pitti: what's the lowest kernel version number we have on touch?
[11:57] <pitti> xnox: why dropped? it was fixed upstream
[11:57] <pitti> xnox: 3.4 I suppose
[11:58] <ogra_> xnox, 3,4 ... but porterrs might even go back to 3.2 or some such
[11:58] <infinity> xnox: 3.1, unless we finally dropped that one.
[11:58] <infinity> But mostly 3.4
[11:58] <ogra_> i dont think kitkat has a minimal kernel req. so for ports it could even be older
[11:58] <xnox> infinity: you talk to me like i still remember what "that one" was. =)
[11:58] <infinity> I don't remember either. :P
[11:59] <xnox> ogra_: i don't care for the porters that much, i care for currently supported phones by canonical. i.e. the nexus and the whatever is shipping.
[11:59] <ogra_> xnox, well, i do care for porters
[12:00] <ogra_> if they port todays rootfs and get an upgrade that makes their phones not work at all anymore that would be bad
[12:00] <ogra_> we have a handfull new ports, would be bad to just break them
[12:01] <infinity> Ahh, grouper is the one that's 3.1, and it's still in the archive.
[12:02] <infinity> ogra_: Should it be?
[12:02] <ogra_> nope, wipe it :)
[12:02] <infinity> ogra_: Is that an official request? :P
[12:03] <infinity> remove-package -m "Obsolete and buggy, removed at ogra's request" linux-grouper
[12:03] <ogra_> yes :)
[12:03] <infinity> ^
[12:03] <ogra_> cool, do it
[12:03] <ogra_> grouper is long dead
[12:04] <ogra_> mir wont properly work on it
[12:04] <cjwatson> infinity: linux-meta-grouper too
[12:05] <infinity> And linux-firmware-grouper
[12:05] <infinity> And maybe linux-firmware-nexus7 ?
[12:05] <ogra_> yeah
[12:05] <ogra_> why is that there at all ?
[12:05] <cjwatson> For that matter linux-nexus7 is still there
[12:05] <ogra_> that originally came from the linux-nexus7 source
[12:05] <ogra_> heh, remove it too
[12:06] <cjwatson> Oh, that's a binary from the linux-meta-grouper source
[12:06] <ogra_> ah
[12:07] <infinity> ogra_: http://paste.ubuntu.com/10550064/
[12:07] <ogra_> infinity, thanks !
[12:08] <ogra_> wow, that was quite some naming mess between nexus7 and rouper
[12:08] <ogra_> *grouper
[12:09] <infinity> ogra_: I think we started with nexus7, then the nexus7 v2 happened, and we realied codenames were better and renamed the world.
[12:09] <ogra_> yeah, but never cleaned up the old stuff it seems
[12:09] <infinity> Well, most of that was transitional packages.  Except for -firmware-nexus7, which was just dead code.
[12:10] <ogra_> yep
[12:11] <infinity> ogra_: mako/nexus4 had the same renaming shuffle, just didn't have the external firmware problem.
[12:11] <ogra_> ah
[12:13]  * infinity sideeyes lubuntu-nexus7-extra-files and lubuntu-nexus7-default-session too.
[12:14] <infinity> Where's gilir when you need him?
[12:14] <ogra_> where do these come from ?
[12:15] <infinity> ogra_: lubuntu-default-settings
[12:15] <ogra_> interesting
[12:16] <infinity> They don't build an armhf+nexus7 image, so it's almost certainly dead and forgotten code from an attempt long ago.
[12:16] <pitti> jamespage, xnox, dannf: open-iscsi doesn't start on installation; that was fixed in http://anonscm.debian.org/cgit/pkg-iscsi/open-iscsi.git/commit/?id=b517ebb5a8f, but is that actually on purpose, or are we just behind on merging?
[12:17] <pitti> (you were the last uploaders)
[12:17] <ogra_> right, i wonder if that was me initially
[12:17]  * ogra_ cant remember
[12:18] <infinity> ogra_: It may well have been, since we were doing lubuntu ac100, and you might have been playing on the nexus7 with an environment you knew would work, pre-touch days?
[12:18] <ogra_> yeah
[12:19] <infinity> ogra_: Feel free to take ownership of commiting a fix to lp:lubuntu-default-settings to drop those packages, I suspect you probably can write to it.
[12:19] <xnox> pitti: well in upstart world we don't need it that explicit start, do we?
[12:19] <ogra_> infinity, not without hearing from the lubuntu guys though
[12:19] <infinity> ogra_: Yeah, core-dev is in lubuntu-dev, so you can totally fix it. :P
[12:19] <xnox> pitti: we have native job, it gets auto-enabled, and hooks into /etc/network/if-up.d/upstart
[12:20] <pitti> xnox: it's an init.d script either way, but postinst wasn't starting it on install; so it's not init system specific
[12:20] <pitti> xnox: ah, ok
[12:20] <ogra_> i know, but i dont want to steal them the package without any feedback
[12:20] <xnox> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/open-iscsi/vivid/view/head:/debian/open-iscsi.iscsi-network-interface.upstart
[12:20] <xnox> pitti: ^
[12:20] <pitti> xnox: but we'd still run the init.d script as well under upstart after booting, just not on package installtion
[12:22] <xnox> pitti: correct.
[12:22] <pitti> ack, thanks for confirming
[12:22] <xnox> pitti: well, however downloading the deb in vivid
[12:23] <xnox> pitti: # Automatically added by dh_installinit
[12:23] <xnox> if [ -x "/etc/init.d/open-iscsi" ]; then
[12:23] <xnox> 	if [ ! -e "/etc/init/open-iscsi.conf" ]; then
[12:23] <xnox> 		update-rc.d open-iscsi start 45 S . stop 81 0 1 6 . >/dev/null
[12:23] <xnox> 	fi
[12:23] <xnox> fi
[12:23] <xnox> pitti: which is unconditional. which bits are we missing?
[12:23] <xnox> oh, invoke
[12:24] <xnox> pitti: i'd rather drop "--no-start" in the dh_installinit call rather than adding manual invoke-rc.d call.
[12:25] <pitti> I now did what Debian did, to reduce our delta
[12:25] <pitti> (bbl)
[12:25] <xnox> right.
[12:27] <xnox> emailed maintainer
[12:32] <cjwatson> pitti: So for exporting the "Request a full language pack export" setting on the webservice, do you literally just need to check that every so often, or do you also have to adjust the other settings on that form at the same time?
[12:33] <cjwatson> pitti: (The former is easy, the others are potentially rather more complex)
[12:34] <pitti> cjwatson: I just tick the box; with full exports it's not really important to update the "last used:" ones that the deltas are built against
[12:35] <cjwatson> pitti: That is the right answer, thank you. :-)
[12:35] <pitti> haha
[12:35] <cjwatson> Saves me having to figure out how to export the language pack objects ...
[12:37] <pitti> I'll take the afternoon off, I'm feeling really crappy
[12:37] <pitti> see you on Monday!
[12:37] <pitti> seems I got most of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html under control now
[12:38] <pitti> perhaps jamespage can add the missing dh_systemd_enable to heat/neutron
[12:41] <cjwatson> pitti: get well soon
[12:48] <tjaalton> doko: hey, the binutils upload to trusty has a weird version (2.24-5ubuntu9 vs. 2.24-5ubuntu3.1 in -updates now)
[12:50] <doko> tjaalton, yes, already used some version numbers in the ubuntu-toolchain-r/ppa before
[13:10] <Riddell> pitti: systemd working great on kubuntu for me and others
[13:10] <Riddell> pitti: where does stdout from startkde go to?
[13:11] <Riddell> pitti: presuambly people doing an upgrade will also have upstart replaced by systemd?
[13:14] <infinity> Riddell: People with ubuntu-standard installed or using do-release-upgrade should get forcefully switched.
[13:14] <infinity> Riddell: If you're mising that metapackage and do a standard apt-get dist-upgrade, not so much.
[13:14] <infinity> Riddell: do-release-upgrade or update-manager, or anything that uses ubuntu-release-upgrader, I should say.
[13:16] <Riddell> gotcha
[13:16] <infinity> Riddell: So, people with debootstrapped minimal systems won't get the forced switch (but they might be the sorts who wouldn't want it anyway), and people who intentionally removed ubuntu-standard.
[13:16] <ogra_> wow, user-mode-linux still exists ?
[13:16] <infinity> Not sure if we can do much better than that, though.
[13:16] <infinity> ogra_: It's an amazingly handy debugging tool.
[13:17] <ogra_> heh
[13:17] <infinity> ogra_: Being able to run the kernel in gdb without having to do serial debugging is A++
[13:17] <ogra_> but wasnt the project dead even before ubuntu started to exist ?
[13:17] <Riddell> weirdly, people still confuse user-mode-linux for unified modelling language and e-mail my umbrello mailing list
[13:17] <infinity> ogra_: Dead?  It's part of the kernel.  It Just Works.
[13:17] <ogra_> oh
[13:17] <Riddell> ogra_: you're thinking of UserLinux
[13:18] <Riddell> the bruce perens idea to make an enterprise debian
[13:18] <ogra_> right, i thought uml was part of that
[13:18] <Riddell> they're as unrelated as user-mode-linux and unified modelling language :)
[13:18] <ogra_> haha, ok
[13:18] <infinity> ogra_: No, no.  uml is kernel-as-an-executable.  A sycall interface to itself, essentially.  Super handy.
[13:19] <infinity> ogra_: It was also the best way to do cheap VM-like things before containers happened.
[13:19] <ogra_> right, i remember that one
[13:19] <infinity> But now that LXC won that war, UML is pretty much just a cool debugging tool.
[13:31] <jorge_> pitti, I think I found a systemd upgrade bug but I'm not sure
[13:31] <jorge_> moving from 14.04 to 14.10 to 15.04 in steps
[13:31] <jorge_> `Failed to mount /etc/machine-id: Not a directory` when installing systemd in 15.04
[13:32] <jorge_> which throws off dpkg and the entire upgrade failed. However if I remove the machine-id directory and replace it with a file with a uuid it finished the upgrade properly
[13:38] <didrocks> @pilot in
[13:42] <alexbligh1> I'm trying to push https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1366174 to completion. There's a fix in trusty-proposed which I have marked verification-done, but looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html there is allegedly a regression in svn. Last build is here: https://jenkins.qa.ubuntu.com/job/trusty-adt-subversion/lastBuild/ARCH=amd64,label=adt/ and indeed the build
[13:42] <alexbligh1> log shows a failure here: https://jenkins.qa.ubuntu.com/job/trusty-adt-subversion/lastBuild/ARCH=amd64,label=adt/artifact/results/log but I'm having difficulty working out what the failure might be. Possibly due to failure to verify GPG keys. I suspect this is not an apache issue. Any ideas?
[13:44] <alexbligh1> "adt-run [18:49:20]: build not needed" / "tar: Unexpected EOF in archive" is not fantastically helpful ...
[13:44]  * dholbach hugs didrocks
[13:45] <cjwatson> alexbligh1: Probably transient, I'll retry it
[13:45] <alexbligh1> cjwatson, thanks
[13:45] <cjwatson> The i386 failure looks more real though
[13:45]  * didrocks hugs dholbach back. Just doing some extras as the queue is quite full :)
[13:46] <cjwatson> https://jenkins.qa.ubuntu.com/job/trusty-adt-subversion/lastBuild/ARCH=i386,label=adt/console
[13:46] <dholbach> :)
[13:46] <dholbach> yes, it is
[13:46] <cjwatson> Setting up libapache2-mod-svn (1.8.8-1ubuntu3.1) ...
[13:46] <cjwatson> dpkg: error processing package libapache2-mod-svn (--configure):
[13:46] <cjwatson>  subprocess installed post-installation script returned error exit status 1
[13:48] <cjwatson> So there's probably no point in me retrying the amd64 one
[13:49] <alexbligh1> cjwatson, indeed. I don't have an i386 environment to hand so would be useful to see whether amd64 does the same thing. Do we have a way of knowing whether i386 passed with 2.4.7-1ubuntu4.1 (i.e. the previous release)?
[13:49] <cjwatson> Probably not, we only brought up autopkgtest for stables relatively recently
[13:50] <cjwatson> Well, I've retried it
[13:51] <cjwatson> alexbligh1: This might just mean that the fix for https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1393832 needs to be cherry-picked as well, but I'm not sure.  Perhaps rbasak can investigate.
[13:51] <alexbligh1> cjwatson, apt-get install libapache2-mod-svn works fine here (on amd64). Possibly it's broken (and was always broken) on i386.
[13:51] <cjwatson> I doubt this is architecture-specific.
[13:51] <cjwatson> It's more likely to be something relatively subtle about ordering like in the bug above.
[13:53] <alexbligh1> cjwatson, yes, that looks like a good candidate for an explanation. Which would mean it's no more broken than before :-)
[13:53] <cjwatson> If it is that same issue then it would be better to cherry-pick that fix, I think, rather than trying to identify relative brokenness
[13:54] <cjwatson> "no more broken than before" is sometimes OK but you have to be quite careful with it.
[13:54] <alexbligh1> cjwatson, indeed. Presumably someone should nominate https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1393832 for SRU in that case.
[13:54] <cjwatson> Well, investigate it first.
[13:55] <cjwatson> I don't remember whether that only happened due to new dpkg or some other apache2 change.
[13:56] <cjwatson> alexbligh1: I expect it would not be too hard to reproduce using http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
[13:57] <flexiondotorg_> cjwatson, Can you outline how the 14.04.2 image build are configured to grab the HWE kernel and X stack?
[13:57] <alexbligh1> cjwatson, interesting. I'll have to look at that over the w/e.
[13:59] <flexiondotorg_> didrocks, Please consider #1427182 #1427742 #1427744 while you're piloting ;)
[14:01] <cjwatson> flexiondotorg_: No, sorry, try somebody else :)
[14:01] <cjwatson> (I'm not up to date)
[14:01] <flexiondotorg_> cjwatson, :)
[14:01] <didrocks> flexiondotorg_: I go over bugs as I feel it. I'm already doing some extra rounds, but yeah, I'm reviewing some now :)
[14:05] <cjwatson> alexbligh1: Yep, now you get the same failure on amd64 too.
[14:06] <alexbligh1> cjwatson, ok, given it installs fine in a 'normal' situation, I guess it's your difficult-to-reproduce bug. I'll have a look at a chroot over the w/e.
[14:06] <cjwatson> Like I say it may or may not be the same thing, but that might be a starting point.
[14:06] <mardy> pitti: hi! I want to write a dbusmock template for my service; can I ship it in my package, or does it have to be included in python-dbusmock itself?
[14:08] <flexiondotorg_> didrocks, Saw you comments about #1427182. Updated accordingly.
[14:10] <desrt> didrocks: did anyone mention to you lately that you're a really swell guy?
[14:11] <desrt> didrocks: because i just thought i'd let you know that
[14:19] <didrocks> flexiondotorg_: mind providing a debdiff for bug #1427742 (see bug #1427744 for some info), that will make the reviewer's life easier and avoid as well fo you to forget listing some changes
[14:19] <didrocks> also, in the future, better bug title would be appreciated :)
[14:23] <flexiondotorg_> didrocks, What should the bug title be?
[14:24] <didrocks> flexiondotorg_: describing why we need the new version in vivid
[14:24] <flexiondotorg_> didrocks, Understood
[14:26] <flexiondotorg_> didrocks, Are you asking for debdiffs for these existing bugs or for future requests?
[14:27] <didrocks> flexiondotorg_: for this ones (well, not the one I commented on with the missing changelog entry, as I did it), but for the remaining ones, please
[14:27] <didrocks> flexiondotorg_: of course, when you are not doing a merge proposal
[14:28] <flexiondotorg_> didrocks, OK so for non merge proposals supply a debdiff. Correct?
[14:28] <didrocks> flexiondotorg_: exactly, that's better than "look at this git with multiple commits where you are not even sure it matches what's the in repo"
[14:38] <Saviq> pitti, hey, could you point me to some reading about using adt to run autopilot tests on devices?
[14:44] <flexiondotorg_> didrocks, I am still new to Debian packaging. Therefore, confused.
[14:46] <flexiondotorg_> didrocks, Please can you tell me the best way to build a new .deb in order to debdiff against it?
[14:46] <infinity> flexiondotorg_: debdiff the source packages, not binaries.
[14:47] <ericsnow> pitti: regarding https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1347020
[14:47] <infinity> flexiondotorg_: debdiff old.dsc new.dsc > file.diff
[14:47] <flexiondotorg_> infinity, Thank you. Fogs clears :)
[14:47] <ericsnow> pitti: it's still the case that you cannot run a vivid image in a container under trusty, right?
[14:47] <didrocks> flexiondotorg_: however, please always ensure that your package is building before asking for sponsoring (see my comment on oem-slideshow) :)
[14:48] <flexiondotorg_> didrocks, Understood.
[14:48] <flexiondotorg_> didrocks, I checked my build only to discover is was from before I introduced that change. Appologies.
[14:49] <didrocks> no worry ;)
[14:51] <infinity> flexiondotorg_: The best documentation of how the 14.04.2 HWE stack is installed is reading the livecd-rootfs source.
[14:52] <flexiondotorg_> infinity, Yep, found that now thanks :)
[14:54] <infinity> flexiondotorg_: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trusty-proposed/revision/910?remember=886&compare_revid=886 would be the entire changeset to make it go.
[14:55] <flexiondotorg_> infinity, Thanks. That's great.
[15:21] <jamespage> pitti: heat fixed up
[15:32] <flexiondotorg_> didrocks, Please could you take a look at my last comment in https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1427742
[15:33] <flexiondotorg_> didrocks, Please let me know if this is what you are expecting. If so, I'll prepare the other debdiffs. Thanks for helping.
[15:43] <jamespage> pitti: well it would be if it did not ftbfs - that's a bit embarrasing
[15:49] <doko> directhex, could you have a look at https://launchpadlibrarian.net/196773289/buildlog_ubuntu-vivid-amd64.mono_3.2.8%2Bdfsg-4ubuntu2_FAILEDTOBUILD.txt.gz (GCC 5)
[15:51] <directhex> doko: can you mail jo.shields@xamarin.com and i'll take a look? mid-crisis right now
[15:52] <doko> directhex, ok, will do
[15:58] <didrocks> flexiondotorg_: yeah, perfect! sponsored
[16:23] <didrocks> @pilot out
[16:29] <flexiondotorg_> didrocks, Thanks.
[16:29] <didrocks> yw ;)
[16:50] <flexiondotorg_> didrocks, So is the one correct now? ;)
[16:50] <flexiondotorg_> didrocks, https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1427744
[16:52] <didrocks> flexiondotorg_: the debdiff is, however, my comments about debian/copyright changes not listed in changelog and the upstream script changes are still valid
[16:52] <flexiondotorg_> didrocks, So close ;) One sec...
[16:59] <flexiondotorg_> didrocks, This? https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1427744/comments/3
[16:59] <flexiondotorg_> didrocks, Thanks for your patience and understanding. I'm reading and learning some of this as I go.
[17:03] <didrocks> flexiondotorg_: that's good, no worry! always think as rule 0 to ensure your package is building and that the changelog reflects what you change, so it looks good here, let me build it now :)
[17:07] <didrocks> flexiondotorg_: sponsored (just note that you forgot to reference the bug # in the changelog, please close it manually) :)
[17:08] <flexiondotorg_> didrocks, Thanks. Adding to my notes about referencing the bug :)
[17:21] <doko> Riddell, https://launchpadlibrarian.net/196789814/buildlog_ubuntu-vivid-amd64.qca2_2.1.0-0ubuntu3_FAILEDTOBUILD.txt.gz (GCC 5) ... I don't understand the versions for the symbols, why  +git20141126.2258 ?
[17:47] <doko> kenvandine, bregma: other GCC 5 ftbfs are: unity-scope-home, unity-lens-applications, signon-ui, libdbusmenu, indicator-keyboard
[17:47] <doko> do you look at any of these?
[17:54] <kenvandine> doko, mardy handles signon-ui and tedg handles libdbusmenu
[17:54] <kenvandine> not sure about the rest
[17:55] <kenvandine> indicator-keyboard is likely the desktop team
[17:55] <tedg> I think those scopes are bregma's
[17:55] <kenvandine> yeah
[17:55]  * tedg tries to convince bregma libdbusmenu is his too
[17:55] <tedg> :-)
[17:56] <kenvandine> good luck with that
[17:56] <bregma> indicator-keyboard is desktop, we'll take care of the scope and lens and libdbusmenu
[17:57]  * tedg drops mic
[17:57]  * bregma like to have something mindless to do on a Friday
[17:57] <doko> GCC 5 fixes are mindless
[17:58] <tedg> bregma, I looked at that one and it seem the gtk2 tests are breaking. I'd look to see if you can just drop the gtk2 package.
[17:58] <bregma> numbingly so
[17:58] <tedg> bregma, I think the xfce folks are moving to gtk3
[18:00] <infinity> tedg: They are, but not this cycle.
[18:00] <infinity> tedg: xfce 4.12 is still gtk2.
[18:01] <tedg> infinity, This is for gcc5 though, so it's next cycle.
[18:01] <infinity> tedg: Well, "moving to gtk3" has been on the xfce uptream roadmap for 4 years.  I refuse to believe it until I see it land in a stable branch.
[18:02] <tedg> Heh, well, there is that.
[18:02] <tedg> I saw it on the Internet, I'm sure it'll happen.
[18:04] <infinity> tedg: From the 4.12 release engineers:
[18:04] <infinity> Xfce 4.12 will still use gtk2, with some support of gtk3 for better integration.
[18:04] <infinity> Port to gtk3 will maybe be done for the next version.
[18:04] <infinity> ^-- "maybe be done" isn't all that comforting. :P
[18:06] <ochosi> infinity: will be done
[18:06] <ochosi> s/maybe be/will be/ :)
[18:07] <ochosi> https://wiki.xfce.org/releng/4.14/roadmap
[18:07] <ochosi> we've ported the first component already, so chill out folks ;)
[18:08] <infinity> ochosi: Ahh, excellent, I hadn't seen the 4.14 roadmap yet.
[18:08] <infinity> ochosi: Halleluja.
[18:08] <ochosi> infinity: that's cause i put it up yesterday, maybe? ;)
[18:08] <infinity> ochosi: Hahaha.
[18:08] <infinity> ochosi: That would do it. :)
[18:08] <ochosi> also, if you're referring to gtk2 indicators (not sure from the backlog), we haven't been using those since trusty
[18:08] <ochosi> our panel has had support for gtk3 plugins for a while now
[18:09] <ochosi> we even use symbolic icons already for two of our plugins, so you could say we're slightly ahead of the indicators there ;)
[18:09] <ochosi> anyway, if you have xfce-related questions, feel free to ping me
[18:09] <ochosi> (or xubuntu-related)
[18:09] <doko> kenvandine, tedg,, bregma: libdbusmenu, indicator-keyboard, unity-scope-home, signon-ui also fail in vivid (default GCC)
[18:11] <tedg> Cool, thanks ochosi
[18:11] <ochosi> np
[18:11] <infinity> ochosi: "We should have no need for Feature Freeze if we don't add features."
[18:11] <infinity> ochosi: You're very optimistic about everyone playing your game, I see. :)
[18:12] <ochosi> infinity: well, that's for -core ;)
[18:12] <ochosi> and yeah, i can be very strict!
[18:12]  * ochosi goes to the cabinet and gets the elephant whip...
[18:12] <infinity> I need one of those.
[18:13] <tedg> infinity, Ringling Brothers garage sale?
[18:14] <ochosi> infinity: while i have your attention...
[18:14] <infinity> ochosi: 'sup?
[18:14] <ochosi> would you mind ack'ing the other components on here? https://bugs.launchpad.net/ubuntu/+source/xfce4/+bug/1424887 - and with the libxfce4util bump from 6 to 7, we'll need to rebuild a few packages.
[18:14] <infinity> ochosi: Can you lend me your whip?
[18:14]  * ochosi hands infinity the elephant whip
[18:14] <infinity> Such a trusting fellow.
[18:15] <ochosi> :]
[18:15] <ochosi> very
[18:16] <infinity> ochosi: So, I'm quite fine with just saying that, IMO, we can extend Scott's ACK to cover any 4.12 updates you need to do for the next week or two.
[18:16] <ochosi> nice, thanks a bunch!
[18:16] <infinity> ochosi: If things end up close to the wire, we'll want to think hard about it, but for now, I'd rather you get it all in than have half a version bump in xfce.
[18:17] <ochosi> yeah, in fact we've been stuck with several 4.11 components for a few releases now
[18:17] <ochosi> so it'd be great to finally be on a stable one for a change :)
[18:17]  * infinity nods.
[18:17] <infinity> Go forth and stabilise.
[18:17] <ochosi> should we do the rebuilds after libxfce4util releases from -proposed or do a dep wait for the packages so they can go at once?
[18:17] <infinity> ochosi: Why the rebuild?  ABI changes?
[18:18] <infinity> ochosi: And if ABI changes, does that mean a new SOVER?
[18:18] <infinity> ochosi: Cause if there's a new SOVER, it'll be stuck in -proposed until it all rebuilds anyway, you have no choice in the matter.
[18:18] <ochosi> yeah, but lemme quickly check what changed exactly in libxfce4util
[18:18] <ochosi> bluesabre was handling all that...
[18:19] <ochosi> (also, i'm not really a packager)
[18:19] <infinity> ochosi: But no need for a bunch of versioned build-deps, just wait until it's published on all arches according to rmadison, then go to town.
[18:19] <ochosi> righty
[18:19] <ochosi> bluesabre: copy that ^
[18:20] <ochosi> so yeah, SONAME bump from 6 to 7
[18:20] <infinity> ochosi: Right, so that will just happily sort itself and stage correctly.
[18:21] <infinity> ochosi: Just so long as the rebuilds are all uploaded after "rmadison libxfce4util7" shows 6 happy published binaries.
[18:21] <ochosi> yup, dropped some symbols, took me a bit to find that now :)
[18:21] <ochosi> ok, perfect
[23:17] <flexiondotorg_> Evening.
[23:18] <flexiondotorg_> I've just been testing 14.04.2
[23:18] <flexiondotorg_> Seems a bit busted to me. Is this known about?
[23:18] <flexiondotorg_> For example, it is impossible to install ubuntu-sdk in a fresh Ubuntu 14.04.2
[23:49] <xnox> how do I view _my_ repositories on gitorious.org?