=== alexlist` is now known as alexlist
[01:53] <nacc> slangasek: can i get your opinion on something? debian (and yakkety, which is merged up at this point) have switched the first alternative for php7.0 from 'php7.0-fpm | libapache2-mod-php7.0 | php7.0-cgi' to 'libapache2-mod-php7.0 | php7.0-fpm | php7.0-cgi'. This is becuase of Debian Bug #822774. Would it be best to have 16.04 match 16.10 (for easier future upgrading and minimizing delta)? Is that even
[01:53] <ubottu> Debian bug 822774 in php7.0-common "Prefer libapache2-mod-php7.0" [Normal,Open] http://bugs.debian.org/822774
[01:53] <nacc> an SRU-able thing (we've been affected in 16.04 already in at least one package, LP: #1577916
[01:53] <ubottu> Launchpad bug 1577916 in ganglia-web (Ubuntu Xenial) "Missing dependencies" [Undecided,In progress] https://launchpad.net/bugs/1577916
=== JanC is now known as Guest34481
=== JanC_ is now known as JanC
[02:25] <kirkland> jderose: likewise, I'm going to look at it too -- thanks so much for sending it our way!
[02:27] <jderose> kirkland: no problem, and thank you very much for looking at it! we've tested that patch with "extreme paranoia" and thus far haven't found any issues... but i'm eager for any feedback you might have
[04:28] <slangasek> nacc: I don't think switching php7.0's dependency ordering is something we should SRU; and more to the point, any webapp package that's broken with the current dependency is still broken if you change it, since the admin may have selected a different php alternative locally.  So anything that has a requirement on a particular sapi but doesn't specify in its dependencies has buggy dependencies
[04:29] <slangasek> nacc: (I reserve the right to change my opinion on whether to accept an SRU to change the dependency order, depending on how widespread this problem appears to be; but I will stand by the claim that any affected package is buggy and should /also/ be SRUed)
[04:55] <jbicha> my understanding is that php-fpm is broken without at least manual configuration but libapache2-mod-php7.0 just works out of the box
[05:04] <jbicha> so I believe this affects *all* php webapps
[05:05] <jbicha> we could and should release note it, we could attempt to workaround it in php7.0 itself but I think it's too much to try to SRU all affected apps individually
[05:13] <slangasek> jbicha, nacc: ok, if it's the case that you can't use /any/ webapp with php-fpm without manual configuration, that's an argument for changing the dependency order (or possibly dropping it as an alternative dep altogether?)
[05:16] <jbicha> yes, I unknowingly tried verifying bug 1582340 (see cmnt 4) and I had to google to figure out why drupal didn't work
[05:16] <ubottu> bug 1582340 in drupal7 (Ubuntu Xenial) "[SRU] Sync drupal7 7.43-3 (universe) from Debian unstable (main)" [High,Fix committed] https://launchpad.net/bugs/1582340
[05:20] <cpaelzer> good morning
[05:21] <cpaelzer> stgraber: as we said in the past - if I see you online when I join it might be time for you to call it a day :-)
[05:55] <pitti> jderose: this is a well-known bug by now
[05:56] <pitti> jderose: ah, and you found the master bug yourself
[06:07] <pitti> flexiondotorg: I just moderated your alpha-1 mail on u-d-announce@; please ping somebody after sending an announcement so that it appears timely
=== cpaelzer_ is now known as cpaelzer
[08:11] <seb128> pitti, hey, I see that you already did you morning SRU round, could you just have a look to libwnck? it's a no change rebuild to get translations back since it's universe
[08:12] <pitti> seb128: I only did trusty this morning, not xenial :) (and I released srus)
[08:12] <pitti> seb128: mostly as part of my patch piloting
[08:12] <pitti> oh, forgot..
[08:12] <pitti> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
[08:13] <pitti> seb128: trivial, done
[08:13] <seb128> pitti, oh, right, I saw a bunch of xenial-changes updates with your name but it's copy to -updates ... I though we didn't do that on fridays? ;-)
[08:13] <pitti> oh, crap
[08:14] <pitti> seb128: for some weird reason I thought "it's Thursday, so let's rather do it today than on a Friday"
[08:14]  * pitti needs holidays, obviously
[08:14] <pitti> sorry -- I'll check IRC and bug mail tomorrow morning
[08:15]  * seb128 hugs pitti
[08:15] <seb128> thanks for libwnck
[08:15] <seb128> don't worry much, those were not big/risky SRUs it seems
[08:15] <seb128> and it's early european friday so still plenty of hours to get feedback today
[08:19] <flexiondotorg> pitti, Thanks for the mail moderation. I did request that last night in #ubunutu-release after I posted :-)
[08:19] <cpaelzer> pitti: hi, was there any external trigger for your comment in bug 1546565?
[08:19] <ubottu> bug 1546565 in openvswitch (Ubuntu Xenial) "Ownership/Permissions of vhost_user sockets for openvswitch-dpdk make them unusable by libvirt/qemu/kvm" [High,Triaged] https://launchpad.net/bugs/1546565
[08:20] <pitti> cpaelzer: I'm patch piloting and this is sitting in the sponsoring queue
[08:21] <cpaelzer> pitti: ah ok good to understand
[08:21] <pitti> cpaelzer: and it's a bit confusing; dpdk is already done, there's only an openvswitch SRU patch, but no yakketypatch
[08:21] <cpaelzer> pitti: ther is no debian DPDK to sned this to
[08:21] <pitti> cpaelzer: no, for the openvswitch part
[08:21] <cpaelzer> pitti: the debian DPDK package that is currently in the making is based on my packaging which contains the patch
[08:22] <cpaelzer> pitti: ah - now I got it - the ovs part
[08:24] <flexiondotorg> rbasak, I've been working on a new component for Ubuntu MATE.
[08:24] <cpaelzer> pitt: you mean this then right ? https://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/commit/?id=4f6e2ca2512e298faf17b1db532625132623a628
[08:24] <flexiondotorg> It is Ubuntu specific.
[08:24] <flexiondotorg> The required libraries are not availabe in Debian.
[08:24] <flexiondotorg> So I'd like to upload to Ubuntu only.
[08:25] <flexiondotorg> rbasak, Can my packageset be extended?
[08:26] <flexiondotorg> I'll file bug for the ITP in a few days when I'm ready.
[08:26] <cpaelzer> pitti: I agree it is confusing - openvswitch in debian is still way too old (not dpdk compatible) so the patch makes no sense for them yet
[08:26] <LocutusOfBorg> pitti, can I ask a quick test?
[08:26] <pitti> cpaelzer: ah, ok
[08:26] <LocutusOfBorg>  syntax error at /usr/share/perl5/Sbuild/ResolverBase.pm line 970, near "USER"
[08:26] <cpaelzer> pitti: it also would require a packaged dpdk with the respective fix to be available in debian
[08:26] <pitti> hey LocutusOfBorg
[08:26] <LocutusOfBorg> well, missing a ","
[08:26] <LocutusOfBorg> :)
[08:26] <LocutusOfBorg> hi ;)
[08:26] <cpaelzer> pitti: I'll try to summarize in the bug so the next one reading it knows
[08:27] <pitti> LocutusOfBorg: oh, I see it
[08:28] <cpaelzer> pitti: your request to submit to debian is correct as soon as they have adpdk package and openvswitch >=2.5
[08:28] <cpaelzer> pitti: which is both coming somewhen this year
[08:28] <pitti> LocutusOfBorg: testing again
[08:29] <LocutusOfBorg> works for me
[08:29] <LocutusOfBorg> I can upload if you agree
[08:30] <pitti> LocutusOfBorg: yes, works fine now; upload away
[08:30] <LocutusOfBorg> you upload or me? :)
[08:31] <pitti> LocutusOfBorg: please do
[08:31] <LocutusOfBorg> done thanks!
[08:32] <LocutusOfBorg> thanks for double checking, thanks for making me setup an sbuild chroot, I'll use it a lot I presume :)
[08:32] <LocutusOfBorg> I'm more a pbuilder guy, but I know I'll have to switch one day :)
[08:32] <pitti> haha
[08:32] <pitti> LocutusOfBorg: mk-sbuild is pretty great
[08:32] <Unit193> pbuilder is activly maintained.
[08:33] <pitti> the only annoying thing is that one has to edit the generated config a bit for --type=file, but other than that mk-sbuild DTRT
[08:33] <LocutusOfBorg> pbuilder-dist is so far the easier
[09:06] <ricotz> pitti, hi, could you reject and remove this package from xenial proposed? -- https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-361/361.45.11-0ubuntu0.16.04.1
[09:07] <ricotz> https://bugs.launchpad.net/snappy/+bug/1588192/comments/31
[09:07] <ubottu> Launchpad bug 1588192 in nvidia-graphics-drivers-304 (Ubuntu Xenial) "GL interfaces seem wedged for Krita on nvidia" [Critical,In progress]
[09:08] <pitti> ricotz: sure
[09:08] <ricotz> pitti, thanks, tseliot ^
[09:11] <pitti> cpaelzer: bug 1524526 is also confusing for me
[09:11] <ubottu> bug 1524526 in dovecot (Ubuntu Xenial) "Crashes with undefined symbol" [High,Triaged] https://launchpad.net/bugs/1524526
[09:12] <pitti> cpaelzer: so does the merge apply to yakkety, and the "rebuild only" patch (which says yakkety) shoudl be for xenial?
[09:12] <pitti> cpaelzer: and the dovecot tasks shoudl be invalid?
=== clobrano is now known as clobrano_
[09:50] <doko> LocutusOfBorg, any update on the virtualbox SRU?
[09:56] <tseliot> ricotz, pitti: thanks!
[09:57] <LocutusOfBorg> doko, what should I do? upload and see it on queue for months?
[09:57] <LocutusOfBorg> I can do, but I need to also upload virtualbox-guest-additions-iso and virtualbox-ext-pack
[09:58] <LocutusOfBorg> and I'm uploading them right now in my ppa
[09:58] <LocutusOfBorg> at least I uploaded them some minutes ago
[09:58] <LocutusOfBorg> I had to add a -2, because the debhelper in trusty is not aware of dbg-migration
[10:03] <doko> LocutusOfBorg, did you SRU virtualbox in the past?
[10:03] <doko> I mean, new upstream versions?
[10:04] <LocutusOfBorg> yes, as security upload
[10:05] <LocutusOfBorg> and I have two virtualbox pending in queue since... who remembers?
[10:05] <LocutusOfBorg> https://launchpad.net/ubuntu/trusty/+queue
[10:05] <LocutusOfBorg> oh yeah, months
[10:07] <doko> ok, I'll fix the ftbfs for now in the current version
[10:11] <LocutusOfBorg> as you wish
[10:11] <LocutusOfBorg> I plan to SRU it to new releases, but not right now, I'm not enough confident
[10:15] <ricotz> doko, hi, is defaulting to gcc-6 happening soon?
[10:18] <rbasak> flexiondotorg: yes - email devel-permissions with details. I believe it just needs one +1 from a DMB member to check that the requested package meets the packageset description and so it can be added without a meeting.
[10:18] <flexiondotorg> rbasak, Thanks. Will do.
[10:20] <rbasak> nacc: for bacula I'd prefer to fix the multiple bugs in a single upload if possible, unless it'll be a while to resolve that way and an immediate fix would be more helpful. Are we ready for that yet?
[10:20] <rbasak> nacc: (and also in a single SRU)
[10:34] <doko> ricotz, not yet determined. probably end of July
[10:37] <ricotz> doko, alright
[11:05] <LocutusOfBorg> sbuild migrated, the testsuite should be buggy
[11:06] <LocutusOfBorg> or my merge was good...
[11:09] <Odd_Bloke> Hmm, we're seeing cloud image build failures that I think are caused by the e2fsprogs that just synced to yakkety.
=== fginther is now known as fginther`
[11:09] <Odd_Bloke> Specifically on armhf and powerpc.
[11:10] <Odd_Bloke> But I don't have a good way of testing anything on those architectures; can anyone suggest how I might do so?
[11:11] <Odd_Bloke> (The error I see is http://paste.ubuntu.com/18226469/ which I wasn't getting yesterday, and don't see on 64-bit or Intel arches)
=== _salem is now known as salem_
=== hikiko is now known as hikiko|bbl
=== fginther` is now known as fginther
[11:50] <pitti> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[11:53] <pitti> mwhudson: there's still something wrong with the docker test: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/d/docker.io/20160630_230250@/log.gz
[11:54] <pitti> mwhudson:  just the warning on stderr
[11:59] <doko> jamespage, will you fix migrate in xenial as well?
[12:13] <LocutusOfBorg> any core-dev around for a quick llvm-toolchain-3.8 upload^
[12:14] <pitti> LocutusOfBorg: debdiff?
[12:15] <LocutusOfBorg> http://paste.ubuntu.com/18229738/
[12:15] <LocutusOfBorg> between the current ubuntu proposed version
[12:15] <LocutusOfBorg> the -2 is going in unstable in a few minutes, I grabbed from svn :)
[12:17] <pitti> patching file debian/rules
[12:17] <pitti> patch unexpectedly ends in middle of line
[12:17] <pitti> Hunk #1 succeeded at 240 with fuzz 1.
[12:17] <pitti> meh
[12:17] <pitti> go pastebin
[12:18] <pitti> +update-maintaner
[12:19] <LocutusOfBorg> mail :)
[12:19] <pitti> LocutusOfBorg: no, it's ok, final verification and about to upload
[12:19] <LocutusOfBorg> oh... ok!
[12:19] <pitti> LocutusOfBorg: done
[12:20] <LocutusOfBorg> you were faster than my ppa :D
[12:20] <LocutusOfBorg> thanks!
[12:20] <LocutusOfBorg> btw congrats for the systemd sync
[12:20] <pitti> LocutusOfBorg: err, thanks; anything you were waiting for in particular?
[12:20] <pitti> LocutusOfBorg: it's autosynced, so I didn't have much to do with it :)
[12:21] <LocutusOfBorg> xnox, a new btrfs-progs nmu :( #829205
[12:21] <pitti> oh, you mean *getting* it syncable? thanks
[12:21] <LocutusOfBorg> ^^ this one
[12:21] <LocutusOfBorg> :)
[12:21] <pitti> yeah, was some work and tech debt cleanup, but totally worth it
[12:21] <pitti> after all, reducing pointless difference between distros is one of its goals :)
[12:22] <LocutusOfBorg> :D and also *my* goals ;)
[12:23] <pitti> I got init-system-helpers syncable too, although with one substvars (so a bit cheating)
[12:23] <LocutusOfBorg> did you see my pbuilder sync?
[12:23] <pitti> LocutusOfBorg: since xenial already, right? that's great too
[12:23] <LocutusOfBorg> https://sources.debian.net/src/pbuilder/0.225.1/debian/rules/
[12:23] <pitti> I wish we could sync sbuild oto, but not quite
[12:23] <LocutusOfBorg> this is cheating
[12:23] <LocutusOfBorg> :p
[12:24] <pitti> haha
[12:24] <LocutusOfBorg> 	sed "s/#DISTRIBUTION=sid/DISTRIBUTION=yakkety/" -i pbuilderrc
[12:24] <LocutusOfBorg> terrible mapreri is terrible!
[12:24] <LocutusOfBorg> fortunately he uploads a lot
[12:25] <LocutusOfBorg> :p
[12:38] <Odd_Bloke> mdeslaur: o/ I noticed that you sync'd e2fsprogs from Debian the other day; I think we've started seeing https://bugs.launchpad.net/cloud-images/+bug/1598136 as a result of that.
[12:38] <ubottu> Launchpad bug 1598136 in cloud-images "Fails to produce a loop-mountable FS on powerpc/armhf" [Critical,New]
[12:40] <jamespage> doko, yes - on my list
[12:40] <doko> ta
[12:44] <Odd_Bloke> mdeslaur: (I guess I'm most interested in whether the "Use the autotools-dev dh addon to update config.guess/config.sub for new ports." changes should have been dropped on sync :)
[12:49] <mapreri> LocutusOfBorg: *g*
[13:10] <cjwatson> Odd_Bloke: Do you know why https://cloud-images.ubuntu.com/xenial/ hasn't had a new daily build for a few days?  I was hoping to check to see if my live-build fix worked.
[13:13] <Odd_Bloke> cjwatson: Ah, we disabled the automatic triggers during a CVE run, and missed xenial when turning them back on.
[13:13] <Odd_Bloke> cjwatson: Turned back on, and build kicked off.
[13:13] <Odd_Bloke> Apologies for the delay!
[13:17] <cjwatson> Odd_Bloke: cool, thanks!
[13:29] <doko> LocutusOfBorg, can't find your virtualbox paste / message anymore. could you repaste it?
[13:31] <LocutusOfBorg> replying on the bug itself
[13:32] <doko> already have it
[13:34] <LocutusOfBorg> oops
=== lilstevie_ is now known as lilstevie
=== hikiko|bbl is now known as hikiko
[14:06] <LocutusOfBorg> cjwatson, any idea about llvm-toolchain-3.8 on z13-009?
[14:06] <LocutusOfBorg> it seems stuck in a stupid place
[14:08] <LocutusOfBorg> seems uploading now
[14:10] <pitti> LocutusOfBorg: looks fine to me; uploading can take two or three minutes, it's a big package
[14:11] <LocutusOfBorg> pitti, yesterday llvm-3.8 got stuck on arm64 for ~20 hours
[14:11] <LocutusOfBorg> ginggs, had to retry the build
[14:11] <LocutusOfBorg> BTW it wasn't stuck in "Uploading" but in "build finished"
[14:12] <LocutusOfBorg> anyway, glad it wasn't stuck
[14:25] <LocutusOfBorg> pitti, give back i386? :(
[14:25] <pitti> /usr/bin/ld.gold: out of memory
[14:25] <pitti> collect2: error: ld returned 1 exit status
[14:25] <pitti> hmm -- not sure if that will help, aren't these buildds all the same these days?
[14:26] <LocutusOfBorg> maybe they needs some cleanup?
[14:26] <pitti> that might need some special handling by infinity or so, to route it to some bigger iron?
[14:26] <LocutusOfBorg> or maybe retrying will make it be picked up by another builder machine?
[14:27] <LocutusOfBorg> with some extra space/memory?
[14:27] <LocutusOfBorg> don't know
[14:27] <cjwatson> No
[14:27] <cjwatson> They're all the same, and they're reset from a VM image every time
[14:28] <LocutusOfBorg> mmm how did it succeed yesterday and failed today
[14:28] <pitti> new upstream version
[14:28] <LocutusOfBorg> no
[14:28] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8.1-1ubuntu1/+build/10188620
[14:28] <pitti> ah, actually not
[14:28] <LocutusOfBorg> this one is good, and is on 3.8.1
[14:28] <cjwatson> Lots of builds are a little bit nondeterministic in ways that don't usually matter
[14:28] <cjwatson> Especially when parallel builds are involved
[14:29] <pitti> so, *shrug*, we don't have a queue ATM, I can retry it once
[14:29] <LocutusOfBorg> :(
[14:30] <LocutusOfBorg> and the situation will go worse
[14:30] <pitti> except lcy builders seem to have gone into the weekend already :)
[14:30]  * pitti checks his autopkgtest minions
[14:30] <cjwatson> I'll try resetting them
[14:31] <pitti> seems to WFM
[14:33] <pitti> cjwatson: my current approach with dealing with our flaky clouds is: (1) in case of a temporary failure, wait 5 mins and try again; (2) after three tmpfails in a row, kill the worker process; (3) every 6 hours, clean up orphaned instances and restart all workers
[14:34] <pitti> this seems to work well enough with "oh crap our cloud broke" downtimes without needing manual intervention
[14:34] <pitti> the "phoenix" cron job :)
[14:34] <pitti> where a tmpfail is stuff like "nova boot failed/timed out" or "timed out waiting for ssh"
[14:46] <ackk> hi, packaging question about systemd config files. I have a python app I'm trying to package. the package.service file gets correctly included, but package.socket isn't by default. is there something I need to set to get it included? or should I do it manually?
[14:48] <jrwren> what is package.socket?
[14:48] <jrwren> is it actually a socket file?
[14:49] <pitti> supposedly a systemd unit file that defines a socket (man systemd.socket)
[14:49] <ackk> jrwren, what pitti said
[14:49] <ackk> for socket service activation
[14:50] <jrwren> ok, sorry. I don't know about that. I do know we packaged a python app and didn't include this socket
[14:52] <LocutusOfBorg> today I did some sdnotify from java to systemd, with a keepalive watchdog notify method :)
[14:52] <LocutusOfBorg> I'm always impressed by systemd
[14:53] <jrwren> +1 i'm very happy with systemd
[14:53] <LocutusOfBorg> in automotive and embedded systems is a must
[14:53] <LocutusOfBorg> :)
[14:53] <LocutusOfBorg> boot time < 2 sec
[14:53] <LocutusOfBorg> but lets stop talking about systemd
[14:54] <cjwatson> ackk: dh_installinit installs service files by default but not socket files.  Just install it with dh_install or whatever.
[14:55] <cjwatson> (see their manual pages)
[14:55] <ackk> cjwatson, I see, thanks
[14:55] <cjwatson> Oh, actually, I think dh_systemd_enable installs them automatically these days.
[14:56] <pitti> worth a bug report, if that's a common case
[14:56] <cjwatson> Are you using --with=systemd?
[14:56] <pitti> ah right, it does now
[14:57] <pitti> mount path service socket target tmpfile
[15:04] <slangasek> pitti: hi, you rejected the grub2 upload because it doesn't include the 2.02~beta2-9ubuntu1.9 upload, but that upload was withdrawn
[15:05] <pitti> slangasek: oh, ok; dropping the call to update-secureboot-policy looked wrong to me, as all the other SRUs *added* that call
[15:06] <pitti> so if this is deliberate, I can review/accept it from the rejected queue
[15:09] <slangasek> pitti: the SRUs that added that call have all been dropped, yes
[15:09] <slangasek> so I guess LP still gave you a diff against a version of the package no longer in the archive :)
[15:11] <pitti> accepted and bug updated
[15:11] <slangasek> pitti: thanks :)
[15:11] <pitti> yes, it's usually against the most recent upload, not the most recent published version
[15:11] <pitti> which is actually a good thing in most cases
=== King_InuYasha is now known as Son_Goku
[15:30] <bdrung_work> infinity, https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1598212
[15:30] <ubottu> Launchpad bug 1598212 in base-files (Ubuntu) "/etc/os-release: Please specify VERSION_CODENAME" [Undecided,New]
[15:30] <bdrung_work> you did the last merge
[15:31] <infinity> bdrung_work: Will look after I get to Cape Town.
[15:31] <pitti> ^ commented on the bug
[15:32] <bdrung_work> pitti, valid point
[15:32] <slangasek> pitti: jinx
[15:33] <pitti> :)
[15:33] <infinity> pitti: "the other day" being November? :)
[15:33] <pitti> infinity: sounds about right
[15:33] <slangasek> snappy wasn't using os-release until last month, fwiw ;)
[15:34] <infinity> slangasek: Sure, but he added it in Nov. :P
[15:34] <slangasek> yes
[15:34] <slangasek> but him adding it and snappy using it may be unconnected
[16:01] <nacc> rbasak: yes, they are all fixed in one upload right now ... i'm still waiting for testing results, so we can hold off, that' sok
[16:01] <nacc> rbasak: in my testing, the fixes work for both cases, but I'm not an active user, so I'd like a 3rd party confirmation
[16:26] <nacc> rbasak: assuming you're not around, but have a mysql question for you, if you are
[16:30] <nacc> rbasak: nm, figured it out
=== dpm is now known as dpm-afk
=== JanC_ is now known as JanC
=== nturner is now known as nturner|away
=== dobey_ is now known as dobey
[18:02] <slangasek> I: Base system installed successfully.
[18:02] <slangasek> cp: '/etc/localtime' and '/var/lib/schroot/chroots/xenial-ppc64el/etc/localtime' are the same file
[18:02] <slangasek> ok wut
[18:03] <slangasek> ah, bug #1569400
[18:03] <ubottu> bug 1569400 in ubuntu-dev-tools (Ubuntu) "mk-sbuild fails with cp: /etc/localtime... are the same file" [Undecided,Fix released] https://launchpad.net/bugs/1569400
[18:12] <slangasek> infinity: you have u-d-t sitting in -proposed awaiting verification on bug #1579619 for 52 days, and requires an arm64 system. do you have one of those handy?  I would also like to fix bug #1569400
[18:13] <ubottu> bug 1579619 in ubuntu-dev-tools (Ubuntu Xenial) "[mk-sbuild] treats armhf as foreign to arm64" [Undecided,Fix committed] https://launchpad.net/bugs/1579619
[18:13] <ubottu> bug 1569400 in ubuntu-dev-tools (Ubuntu) "mk-sbuild fails with cp: /etc/localtime... are the same file" [Undecided,Fix released] https://launchpad.net/bugs/1569400
[19:10] <nacc> slangasek: trying to figure out this php-horde-activesync issue. We fixed a similar issue in php-horde-db by updating the SQL configs to have a password for root and setting that password in the debian/tests/phpunit file. I have done that with php-horde-activesync as well, but when it runs via adt-run, it fails (same error). If I pass -s so adt-run drops to a shell, and immediately run
[19:10] <nacc> ./debian/tests/phpunit, it passes. Any idea what is going on or how to debug?
[19:11] <slangasek> nacc: what's your full adt-run commandline in each case, and can I see your debdiff?
[19:11] <nacc> slangasek: yeah, one sec
[19:12] <nacc> slangasek: debdiff: http://paste.ubuntu.com/18259801/
[19:13] <nacc> slangasek: adt-run -U --setup-command='apt-get update' php-horde-activesync_2.34.0-1ubuntu1.dsc -s --- adt-virt-lxd adt-yakkety
[19:14] <slangasek> nacc: so the only difference between the adt-run invocations was the '-s'?
[19:15] <nacc> well, i mean it fails either way; but -s just lets it drops to a shell
[19:15] <nacc> slangasek: sorry, that was unclear before
[19:15] <slangasek> nacc: ah; so you get a shell, you run ./debian/tests/phpunit, it passes; you exit the shell, adt-run runs the tests, it fails?
[19:16] <nacc> slangasek: yeah, to be clear, i'm dropped to the shell because adt-run already failed with the prior error ("ERROR 1698 (28000): Access denied for user 'root'@'localhost'")
[19:17] <slangasek> huh
[19:17] <nacc> slangasek: i am at a loss on how to debug it, right now, as it seems like it *should* work (esp. given that php-horde-db works)
[19:18] <slangasek> nacc: yeah, I don't have an explanation for this
[19:19] <slangasek> I particularly don't see any reason the automated test would fail, but manually running it would succeed
[19:19] <nacc> slangasek: np, i'll keep digging; yeah, that's the confusing part to me :)
[19:29] <nacc> slangasek: i might have found it, the tests might 'needs-root'  now
[19:29] <slangasek> ah
[19:29] <nacc> slangasek: was just comparing against the php-horde-db d/t/control
[19:40] <nacc> slangasek: is simply stating it fixes the autopkgtests a sufficient SRU impact? it's a no-op to the code itself, just fixes the packaging, essentially
[19:48] <nacc> slangasek: i submitted it as such anyways, we'll see :)
[19:48] <slangasek> nacc: yes, that's sufficient for me
[19:49] <nacc> slangasek: i did have a more relevant question for you, we've had two SRU 'regression' bugs come through for php7.0 so far (LP: #1597597 and LP: #1598166). They are both debconf issues, though, and I don't see how they are related to php7.0 itself (and jbicha has marked one a dupe of another bug showing the same issue). Have you seen anything like it?
[19:49] <ubottu> Launchpad bug 1567291 in debconf (Ubuntu) "duplicate for #1597597 package phpmyadmin 4:4.4.13.1-1 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 128" [Undecided,Confirmed] https://launchpad.net/bugs/1567291
[19:49] <ubottu> Launchpad bug 1598166 in php7.0 (Ubuntu) "package php7.0-fpm 7.0.8-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128" [Undecided,New] https://launchpad.net/bugs/1598166
[19:49] <hallyn> hm, are ppa builders having issues?
[19:49] <hallyn> https://launchpad.net/~ubuntu-virt/+archive/ubuntu/ppa/+build/10307662/+files/buildlog_ubuntu-trusty-ppc64el.qemu_2.0.0+dfsg-2ubuntu1.25~ppa1_BUILDING.txt.gz
[19:50] <hallyn> /«BUILDDIR»/qemu-2.0.0+dfsg/fpu/softfloat.c:4272:1: internal compiler error: Segmentation fault
[19:52] <cjwatson> hallyn: our ppc64el guests unfortunately have very occasional random corruption - just retry
[19:52] <hallyn> ok thx
[19:53] <slangasek> yeah, if only those guests running on top of qemu were stable so that you could build qemu?
[19:53] <slangasek> yo dawg I heard you like virtualization
[19:53] <slangasek> nacc: 128 is not a typical debconf failure exit code, fwiw
[19:54] <nacc> slangasek: true, i think it's actually a perl failure, but not sure
[19:59] <slangasek> nacc: I do think it's clearly not an SRU regression, given the output - where was this being tagged as a regression?
[20:00] <nacc> slangasek: LP: #1569128
[20:00] <ubottu> Launchpad bug 1569128 in phpmyadmin (Ubuntu Xenial) "php7.0-common provides incompatible php-gettext [16.04 Xenial]" [Undecided,New] https://launchpad.net/bugs/1569128
[20:00] <slangasek> ah
[20:01] <slangasek> ok, bug state mangled
[20:02] <nacc> slangasek: thanks for confirming
[20:04] <nacc> slangasek: re; php-horde-activesync, i've also sent the same to debian, so we hopefully will be able to sync again in 16.10 shortly
[20:05]  * slangasek nods
[20:05]  * nacc has finally learned to just do that right away :)
[20:08] <slangasek> nacc: uploaded, thanks!
[20:08] <nacc> slangasek: thank you!
=== Elimin8r is now known as Elimin8er
=== balkamos_ is now known as balkamos