[00:01] <superm1> mterry: i've got patches that sort out the rest of test suite problems that are upstream now.  upstream is about to cut a new release so i'll just wait on that to do it all in one swoop tomorrow
[00:09] <nacc> slangasek: for php-pinba, upstream has a branch that is testing successfully with php7, but not yet in a release. I've pinged them to see if they will release. Would it be ok to put that in the "broken needing SRU category", potentially?
[00:11] <nacc> at the sametime, it's a leaf package and we can probably delete it :/
[00:12] <slangasek> nacc: it /could/ be put in the "broken, SRU later" pile; but I think we should be realistic about how much time we want to spend on all of these leaf packages post-release
[00:13] <nacc> yep, agreed, hence my amendment just now; i think we're better off just deleting it
[00:13] <nacc> i'll file the bug
[00:39] <Pharaoh_Atem> nacc: why are you trying to get drupal7 working on php7?
[00:40] <Pharaoh_Atem> afaik, upstream isn't working on this, and has recommended drupal8 for php7
[00:41] <nacc> Pharaoh_Atem: because drupal8 isn't packaged and i'm being told it's not acceptable to not have a drupal
[00:41] <nacc> Pharaoh_Atem: upstream *is* working on this, fwiw
[00:41] <Pharaoh_Atem> oh, they are?
[00:41] <nacc> yes
[00:41]  * Pharaoh_Atem didn't find an issue when he searched for it
[00:41] <Pharaoh_Atem> good to know, though
[00:42] <nacc> https://www.drupal.org/node/2483571
[00:42] <nacc> https://www.drupal.org/node/2454439
[00:42] <nacc> rather
[00:46] <Pharaoh_Atem> nacc: so on a slightly unrelated note, the code change work has been finished for libvirt-php, and now we're going through testing
[00:46] <Pharaoh_Atem> it might actually get done within the next two weeks :)
[00:46] <nacc> cool
[00:52] <sarnold> "not acceptable to not have a drupal"???
[00:52] <sarnold> what darkness befalls us
[00:52] <sarnold> madness envelopes us
[00:53] <sarnold> our sanities and our humanities sundered
[00:53] <Pharaoh_Atem> :(
[00:54] <Pharaoh_Atem> well, it's been far too long since I've heard "Linux for Human Beings"... maybe this is why? :(
[00:55] <sarnold> it may be a vicious cycle
[00:55] <sarnold> no one updates drupal
[00:55] <sarnold> so no one uses drupal
[00:55] <sarnold> no one uses drupal
[00:55] <sarnold> so no one updates drupal
[00:55] <sarnold> http://people.canonical.com/~ubuntu-security/cve/pkg/drupal7.html
[00:55] <sarnold> it pants a sad sad picture.
[00:56] <nacc> sarnold: for s&g, i am trying to to uscan & uupdate to drupal8, which at least will be more current ... not sure that's really a better way to go, but curious if it will work
[02:54] <mwhudson> does someone want to read a strange tale of compiler warnings? my comment #10 on https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1557852
[02:58] <sarnold> that's a good one
[05:14] <cpaelzer> good morning
[05:21] <pitti> Good morning
[06:00] <cpaelzer> wgrant: I just realized you are online atm - if I would have known I would have asked
[06:00] <cpaelzer> wgrant: so you didn't like the title change on bug 1564513 clarifying
[06:01] <cpaelzer> wgrant: sorry, I thought reading your great explanations that would make it more clear - but I'm fine with the shorter title as well
[06:07] <wgrant> cpaelzer: Had a longer reply penned, forgot to hit send. It's there now.
[06:07] <wgrant> Happy to discuss further here.
[06:07] <cpaelzer> wgrant: ok great  - let me digest all of that ...
[06:10] <cpaelzer> wgrant: ok nice, details are good now
[06:10] <cpaelzer> wgrant: so to quote you I think the current state and actual thing to tackle with the bug is "that's why it would be good to split out series targeting"
[06:11] <wgrant> Yep, that's why I retitled the bug.
[06:11] <wgrant> The problem is that only drivers can target bugs.
[06:11] <cpaelzer> ack
[06:12] <ginggs> morning pitti, julia's autopkgtest failed on i386 again and i can't see why - it ran the same tests successfully during the build. would you have a look please?
[06:14] <cpaelzer> wgrant: thanks, I think we can keep the bug at that state until somebody finds time to really work at it
[06:14] <sarnold> I couldn't get the xenial beta2 server "memory test" to run; does anyone know which component should get the bug report?
[06:14] <cpaelzer> wgrant: maybe triage it away from status new now that it is kind of clear what would need to be done, but clearly that is your call to make
[06:17] <wgrant> cpaelzer: Done.
[06:23] <pitti> ginggs: it's very flaky on i386; I thought i386 was mostly broken/utterly slow due to some known llvm regression
[06:23] <ginggs> pitti: that was fixed in llvm 3.8
[06:25]  * pitti retries it
[06:28] <ginggs> pitti: thanks. i was about to say you can see from the test durations when it went from >5hrs to 20min, but I see the very last duration was 5hrs again. :(
[06:28] <pitti> yeah, it timed out
[06:36] <ginggs> pitti: from what i can see, it seems to have run against the correct versions of openlibm and openspecfun. i'll wait to see what happens with the retry
[06:48] <dholbach> good morning
[06:48] <dholbach> @pilot in
[07:20] <dholbach> mhall119, Laney: so there are a bunch of svg icons in the sponsoring queue... what am I supposed to do with these? can I just assume they're under the same license as the source of the packages?
[07:43] <tjaalton> doko: hi, bug 1558820 is assigned to you, and mesa will build depend on libva next week. do you have time to look at the MIR before that happens?
[08:16] <oSoMoN> Mirv, good morning! oxide in xenial is affected by https://bugreports.qt.io/browse/QTBUG-47940 and there doesn’t seem to be any activity upstream, do you think you could escalate it, or maybe we could try and distro-patch it?
[08:45] <Mirv> oSoMoN: if you have suggestion of a distro patch we should suggest it to upstream, but otherwise let's see if we can get some attention to it
[08:47] <doko> tjaalton, not today, errands. will have to wait 'til next week
[08:48] <tjaalton> doko: that's fine
[08:48] <doko> ginggs, boinc-client-nvidia-cuda/ppc64el unsatisfiable Depends: libcuda1 | libcuda1-any | libcuda-7.5-1 | libcuda-7.0-1 | libcuda-6.5-1 | libcuda-6.0-1 | libcuda-5.5-1 | libcuda-5.0-1
[08:51] <oSoMoN> Mirv, ok
[08:53] <ginggs> doko: we will need http://www.nvidia.com/download/driverResults.aspx/100747/en-us packaged for ubuntu before that will be installable (in Debian it is packaged with the video driver)
[08:53] <ginggs> doko: does that block boinc?
[09:46] <dholbach> nacc, can you maybe upload the roundcube upload you want to sponsored to a ppa and link to it?
[09:46] <dholbach> nacc, the problem with the long diff is that removals of files can't easily be applied like this - here's the errors I'm seeing: http://paste.ubuntu.com/15575439/
[10:44] <ginggs> doko: nvm, I see the missing libcuda1 on ppc64el is blocking boinc. I emailed PlagueOfLocusts and he's uploaded a new version dropping ppc64el again
[10:48] <ginggs> pitti: i think that julia test on i386 is going to fail again. can we ignore that failure please?
[10:52] <dholbach> @pilot out
[11:17] <Saviq> pitti, hey, can you please recycle https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-046/excuses.html for me? also... any idea what happened here https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-046/excuses.html ?
[11:27] <GunnarHj> dholbach: Don't think upstream would need my hackish patch at bug #1563553. I suspect that there is a more 'correct' way to define ENABLE_NLS, e.g. in debian/rules, but I don't know how. Hence my patch to simply make it work in 16.04.
[11:35] <rbasak> slangasek: may I have your opinion on 1564856 please? Can we bump that?
[11:37] <rbasak> bug 1564856
[11:52] <dholbach> GunnarHj, ok... I wasn't sure if the upstream project had the same issue with translations
[11:53] <GunnarHj> dholbach: I'm not *100%* sure either. But I doubt it.
[11:53] <dholbach> ok
[11:59] <dholbach> GunnarHj, https://git.gnome.org/browse/gnome-calendar/commit/?id=4e735ef3cef514a7fda1e5b94cd64941dbd2507d
[11:59] <dholbach> (landed in master 3 days ago)
[12:01] <dholbach> maybe we should backport that or wait for the .1 release?
[12:01] <dholbach> what do you think?
[12:02] <GunnarHj> dholbach: So I was wrong. :( Well, if we cherry pick that patch, it adds to our collection of patches which need to be dropped later on. Same as the patch I proposed. So for practical reasons it doesn't matter.
[12:03] <dholbach> ok, wfm - I can add a note to the changelog about this
[12:03] <GunnarHj> dholbach: Sounds like a smart compromise to me. ;)
[12:50] <asac> hmmm. my cups-browsed package doesnt really upgrade for days
[12:50] <asac> Preparing to unpack .../cups-browsed_1.8.3-2ubuntu2_amd64.deb ...
[12:50] <asac> Failed to execute operation: Failed to activate service 'org.freedesktop.systemd1': timed out
[12:50] <asac> it hangs there
[12:51] <asac> i ctrl-c eventually and then the package is in bad inconsistent state
[12:51] <asac> so i cannot remove it :)
[12:59] <pitti> xnox, infinity: I landed the "lolz number of jobs/failed units" fix upstream and pulled it into our tree
[13:07] <asac> pitti: how do i best hack things so that purging a package does not try to stop the systemd job? in my case cups-browsed
[13:08] <asac> just remove the service file in /etc/systemd?
[13:08] <xnox> pitti, that makes sense
[13:11] <pitti> asac: that rather sounds like its postrm getting stuck in systemctl daemon-reload; but that's guarded with a || true
[13:13] <pitti> asac: i. e. sounds like dbus-daemon got restarted or something such?
[13:17] <asac> ok let me see if i can hack up postrm
[13:18] <asac> pitti: hmm. sudo systemctl --system daemon-reload indeed hangs
[13:18] <asac> how can i debug this?
[13:18] <asac> oh it times out with : Failed to execute operation: Failed to activate service 'org.freedesktop.systemd1': timed out
[13:19] <asac> so yeah thats what i see in postrm
[13:22] <pitti> asac: no off-hand idea how you got there; was this recently dist-upgraded, and you didn't reboot by any chance?
[13:24] <asac> pitti: i didnt reboot for 2 days i think
[13:24] <asac> dist-upgraded twice/three times a day
[13:24] <asac> think it started yesterday
[13:25] <asac> pitti: how can i find what the service having problems is?
[13:25] <asac> or you say i should rather reboot first
[13:26] <pitti> asac: that will help for sure
[13:26] <pitti> I don't really know what else could help, though
[13:27] <asac> ok
[13:27] <asac> then lets ignore ... /me reboots
[13:30] <Saviq> pitti, hey, any idea what happened here https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-046/excuses.html ?
[13:34] <pitti> Saviq: err, no -- britney's idea of April's fool?
[13:34] <pitti> ginkgocadx only exists in xenial-proposed
[13:34] <pitti> but tpm2-tools exists in xenial
[13:36] <pitti> the corresponding britney log would be interesteing
[13:36] <pitti> https://requests.ci-train.ubuntu.com/static/britney/log_20160401_114001.txt
[13:36] <pitti> oh, might be related to the removal of Packages.bz2
[13:37] <pitti> http://archive.ubuntu.com/ubuntu/dists/xenial/multiverse/source/Sources.bz2:
[13:37] <pitti> 2016-04-01 11:40:01 ERROR 404: Not Found.
[13:37] <pitti> robru: ^ your script to retrieve the archive package indexes needs to move from .bz2 to .xz (with a fallback to .gz)
[13:38] <cjwatson> For some reason it's using Packages.gz but Sources.bz2
[13:38] <cjwatson> The simplest fix would be to just use .gz for both
[13:41] <cjwatson> pitti,robru,Saviq: https://code.launchpad.net/~cjwatson/bileto/no-bzip2/+merge/290736
[13:42] <pitti> cheers
[13:44] <Saviq> tx :)
[13:46] <rbasak> doko: I'm seeing a bunch of "error: ‘isnan’ was not declared in this scope" errors when rebuilding things for MySQL. Is this a common pattern that you're aware of - due to a new toolchain maybe? And if so, is there a standard pattern for a fix?
[13:48] <cjwatson> Is it any more exotic than forgetting to #include <math.h>?
[13:48] <infinity> rbasak: That's glibc 2.23 being more correct than you are.
[13:48] <cjwatson> I mean, this kind of thing happens all the time when people sloppily rely on transitive header inclusion and then one of the links in the chain stops including something they actually needed directly.
[13:48] <cjwatson> Oh and there's also some feature test macros required for isnan.
[13:49] <rbasak> Yeah sure, I can just patch in include directives. I just wanted to check that there wasn't some more common understanding to fix it better.
[13:50] <infinity> It's not indludes.
[13:50] <infinity> It's namespaces.
[13:50] <rbasak> http://stackoverflow.com/a/18129007/478206 suggests that it depends.
[13:51] <rbasak> If they're already including <cmath> I guess I'll patch to use a qualified std::isnan.
[13:51] <infinity> If my browser would wake up, I'd give you some references. :P
[13:51] <cjwatson> Oh, sure, you didn't say it was C++ :)
[13:52] <infinity> FWIW, https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=2.23;users=debian-glibc@lists.debian.org
[13:52] <infinity> That's my list to fix before release.
[13:52] <infinity> rbasak: ^-- Are your failing packages on that list?
[13:53] <rbasak> libreoffice and hhvm are, yes. Maybe some others. I need to assemble a proper list.
[13:53] <rbasak> I already have a separate patch to hhvm for a different MySQL issue.
[13:54] <infinity> rbasak: https://sourceware.org/bugzilla/show_bug.cgi?id=19439 is the upstream discussion of why this now happens.
[13:54] <rbasak> infinity: BTW, I did a test transition for MySQL in a PPA. It's looking fairly good, but there are a few sticky issues.
[13:54] <rbasak> infinity: I'd like your opinion as to whether to go ahead. I'm not done summarising the issues yet though.
[13:54] <infinity> rbasak: Comment #10 basically has the TLDR.
[13:56] <rbasak> infinity: got it, thanks.
[13:56] <infinity> rbasak: If you feel the urge to fix things in Ubuntu ahead of Debian, please do forward patches to the already-open Debian bugs.
[13:56] <infinity> (And, to save yourself time, look there for patches first. :P)
[13:57] <ginggs> infinity: hi, should i file a bug about fpc / powerpc for that glibc 2.23 list?
[13:57] <infinity> ginggs: No.
[13:57] <infinity> ginggs: The fpc/ppc issue is kinda special, and I'm still looking at it, but it's not technically FTBFS, per se, it's that the old binary fails to run. :P
[13:57] <rbasak> infinity: well, I feel the urge to get MySQL 5.7 landed :)
[13:58] <infinity> ginggs: I can rebootstrap it by hand, but I'd sort of like to figure out WTF they're doing that broke it like this.
[13:58] <infinity> rbasak: Right.
[13:58] <infinity> rbasak: As for opinions on the transition, I'm going to grab a coffee, if you have a summary of the issues by the time I get back, let's chat.
[13:58] <rbasak> infinity: ack, thanks.
[13:59] <ginggs> infinity: ok thanks
[14:04] <rbasak> configure.ac:105: error: possibly undefined macro: AC_BAKEFILE
[14:04]  * rbasak wonders if the author had a cold that day
[14:05] <pitti> rbasak: robert_ancell actually used to work on https://launchpad.net/bake :)
[14:06] <rbasak> Hmm
[14:06] <rbasak> Yeah, seems like AC_BAKEFILE is actually a thing
[14:07] <rbasak> infinity: ready. I've updated the description at https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1528583
[14:19] <jtaylor> is there a place where release note info is collected?
[14:20] <rbasak> jtaylor: http://launchpad.net/ubuntu-release-notes
[14:20] <jtaylor> thx, just file a bug?
[14:21] <rbasak> Yep, or add a task to an existing bug if there already is one that tracks an issue.
[14:25] <infinity> Or just edit the release notes.
[14:34] <xnox> jtaylor, for xenial -> just edit https://wiki.ubuntu.com/XenialXerus/ReleaseNotes there was a call to start gathering release notes a while back
[14:34] <jtaylor> uh I do actually have rights to do that
[14:34] <jtaylor> I'll add the vim/python2 and a point on docker image migration then
[14:39] <jtaylor> hm I guess the vim default to python3 would go under new features? its not really new but the openssh entry is kind of in the same vain
[14:49] <jtaylor> added some stuff, feel free to rewrite/move
[14:56] <nacc> dholbach: sure, i can do that!
[14:57] <jdstrand> pitti: hey, do you have a few minutes to talk about udev tags/properties in the context of snappy?
[14:59] <pitti> jdstrand: what's up? (still finishing something else, but I'll respond)
[15:00] <jdstrand> pitti: why don't you finish up-- it will be a discussion. shouldn't be more that 15 minutes
[15:04] <pitti> jdstrand: done
[15:04] <pitti> HO?
[15:06] <jdstrand> pitti: yes
[15:06]  * jdstrand creates link
[15:06] <jdstrand> actually, give me two minutes I want to check one more thing so we don't have to in the meeting
[15:10] <jdstrand> ok
[15:11] <mhall119> dholbach: did Laney answer your question from this morning?
[15:11] <jdstrand> pitti: pasted HO link in privmsg
[15:13] <dholbach> mhall119, no
[15:13] <dholbach> maybe he's on holidays?
[15:13] <mhall119> could be
[15:14] <dholbach> in any case sponsors won't know what to do with them
[15:14] <mhall119> dholbach: in my blog I asked for CC-BY-SA for new icons, but didn't specify anything for using existing ones
[15:15] <dholbach> I don't know where to put those files
[15:15] <dholbach> or what exactly needs to be uploaded or adapted
[15:15] <mhall119> if the icons come from upstream, I would assume they use the same license as other assets from that upstream, but I don't know if we can go on that assumption
[15:16] <mhall119> hmmm, ximion would be able to answer that, but he's at the GNOME sprint this weekend I think
[15:16] <dholbach> it'd be good to update the bugs accordingly
[15:16] <dholbach> there's quite a few on http://reqorts.qa.ubuntu.com/reports/sponsoring/
[15:18] <mhall119> dholbach: how can I help? I can ask the bug creator to specify the license for the icon file, but I'm not knowledgeable enough to tell you where it should go in the package
[15:19] <dholbach> mhall119, I don't know where the image needs to be put
[15:19] <dholbach> how does appstream pick this up?
[15:21] <nacc> Pharaoh_Atem: what should we do about php-doc ?
[15:21] <mhall119> from a couple of places I think, either an appdata.xml file or from the .desktop
[15:21] <mhall119> does anybody know when Laney will be back?
[15:22] <dholbach> no idea
[15:24] <dobey> mhall119: calendar says monday
[15:24] <dholbach> ok cool
[15:24] <dobey> mhall119: or rather, it says he's at some gnome-software/appstream sprint next week
[15:26] <mhall119> oh, is he there too?
[15:27] <mhall119> dholbach: we can make him fix them while he's at the sprint about fixing them :)
[15:34] <slangasek> rbasak: 1564856> define 'bump'?
[15:35] <rbasak> slangasek: update to latest upstream version + patches, AIUI.
[15:35] <rbasak> Skuggen: ^
[15:36] <Skuggen> Unfortunately it looks like the latest version also has issues with this. A patch to make it work would probably be significant (though the devs on the package itself are working on finding a solution)
[15:36] <Skuggen> this=MySQL 5.7
[15:41] <nacc> slangasek: we might need to delete php5-{pecl-http,propro,raphf}{,-dev} to let those migrate?
[16:15] <jdstrand> pitti: fyi, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1564976
[16:17] <nacc> slangasek: kirkland: so i was able to get a drupal8 build to succeed finally; i'm not trying to claim it's a great solution, but might be "better" than waiting on drupal7 -- opinions? I need to review the build, of course, but it was done with uscan/uupdate (with an update to the watch file) and will need to consider the upgrade path
[16:18] <rbasak> Skuggen: I thought Fedora had it working? Or did that turn out to not be the case?
[16:18] <nacc> rbasak: fyi (and not meant as anything other than that!), a few php7 migrations are blocked by mysql as well
[16:18] <rbasak> Skuggen: after speaking to infinity, our priorities are to figure out what's happening with myodbc, mysql-proxy and mysql-workbench. All the MySQL-related stuff basically. Once we've got timelines on that, we can start the transition.
[16:19] <rbasak> nacc: OK, thanks. Hopefully we'll clear this Real Soon Now.
[16:19] <nacc> rbasak: :) good luck!
[16:21] <nacc> down to 91 revdeps on php5!
[16:23] <slangasek> rbasak: right, so myodbc, not part of the day job ;)  I'm aware that the current package is broken because of unexported symbols and have not tried to deal with it.  If someone wanted to take over Debian maintenance of myodbc that would be fine with me
[16:24] <Skuggen> rbasak: The patch we had for Fedora wasn't enough, it seems. It needs more work, and would likely cause conflicts with what would be in /usr/include :|
[16:25] <slangasek> nacc: actually, looks like it mostly just needed a bit of binary NEW processing (done)
[16:26] <nacc> slangasek: ah ok, wasn't sure which way it iwas, thanks!
[16:26] <slangasek> nacc: once the new binaries are in, proposed-migration can usually be a bit clever about noticing the old ones should go away with the old source
[16:26] <nacc> slangasek: awesome
[16:41] <linuxperia> Hi all. Can somebody tell me why nmcli does not return anymore when its called in the console? i have nmcli Version 1.0.4 and since yesterday when i try to stablish a connection using nmcli up uuid xyz the command never returns ...
[16:51] <jdstrand> pitti: the add_match_tag() with add_match_property() issue I mentioned is not an issue. I made a mistake it is working fine (note, bug #1564976 is a different issue and I just subscribed you)
[16:59] <sil2100> pitti: hey! You have a minute to help me figure out what happened?
[16:59] <sil2100> pitti: I fixed something in the 15.04 langpack creation and did a manual run of langpack-o-mating on snakefruit
[17:00] <sil2100> pitti: the logs show everything should be fine
[17:01] <Pharaoh_Atem> nacc: that's currently unpackaged, right?
[17:01] <sil2100> pitti: hm, actually I see l-o-m didn't change the version number...
[17:01] <nacc> Pharaoh_Atem: what is?
[17:01] <Pharaoh_Atem> php-doc
[17:01] <Pharaoh_Atem> or are you talking about something else
[17:01] <nacc> Pharaoh_Atem: no, it's there,
[17:01] <nacc> 20140201-1
[17:02] <nacc> which is the php5 documentation
[17:02] <Pharaoh_Atem> oh, that
[17:02]  * sil2100 fixes it manually
[17:03] <Pharaoh_Atem> nacc: is it simple enough to regenerate with the php7 ones?
[17:04] <Pharaoh_Atem> if not, just drop it
[17:04] <Pharaoh_Atem> that's one of those packages that usually isn't worth the hassle
[17:12] <linuxperia> Hi All. I could isolate the Problem related to nmcli freezing hanging after establishing a connection that is also Reported in this Bug Report here => https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1536077
[17:13] <linuxperia> when i run the nmcli command with root rights aka sudo nmcli now it works
[17:13] <linuxperia> but if i do it like allways it freezes / hangs
[17:15] <linuxperia> not sure also but my syslog is getting heavy spammed with this error message here that i think is related to this problem too => gnome-session[1791] could not identify all Prozesses
[17:16] <linuxperia> Root can show them
[17:16] <linuxperia> hmmmm
[17:20] <infinity> slangasek: FWIW, I'm not entirely opposed to just dropping myodbc if it's not fixable.  The one rdep is ORed.  But as the Debian maintainer, I'd leave that decision to you, I think.
[17:22] <infinity> slangasek: (Or demoting it to -proposed to let the transition happen, and hoping we can fix it before release)
[17:25] <kirkland> nacc: slangasek: looks like you guys got that sorted out?
[17:25] <nacc> kirkland: re: drupal8? no, not yet
[17:26] <nacc> kirkland: not yet discussed, i mean
[17:26] <kirkland> nacc: ah so short recap?
[17:27] <kirkland> nacc: drupal8 is needed for php7 compat?
[17:27] <nacc> kirkland: drupal7 upstream is still not php7 compliant; we could leave it in the archive as broken until/if they get to it (it's unclear the priority the drupal7 community is applying to it, as they have released drupal8).
[17:27] <nacc> kirkland: drupal8 is released upstream, but not yet in debian
[17:27] <nacc> kirkland: i was able to uscan and repackage it
[17:28] <nacc> kirkland: but need to verify that it is correct, and that it will dtrt
[17:28] <nacc> kirkland: drupal8 is php7 compliant
[17:28] <kirkland> nacc: rock!
[17:28] <kirkland> nacc: so let's put out a call for testing of your drupal8/php7 packages
[17:28] <kirkland> nacc: post to the ubuntu-server list?
[17:30] <robru> pitti: cjwatson: Saviq: ok that fix is in production, should see train britney working again in 40 minutes or so
[17:31] <cjwatson> thanks
[17:32] <robru> also https://bugs.launchpad.net/bileto/+bug/1565019
[17:32] <nacc> kirkland: will do, thanks
[17:33] <nacc> kirkland: yeah, there are a handful of packages that we are upgrading for php7 compat, i'll send out an e-mail today with those and ask for testing
[17:39]  * lamont really misses his keyboardFocusPolicy=strict ...
[17:41] <robru> pitti: cjwatson: Saviq: ah yeah, looking good so far https://requests.ci-train.ubuntu.com/static/britney/log_20160401_173001.txt
[20:44] <dannf> pitti: http://paste.ubuntu.com/15580835/ <- is there new magic for that?
[20:57] <infinity> dannf: Run it in C.UTF-8?
[21:08] <Saviq> can someone please rerun http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#qtmir with the new unity8 in proposed? thanks
[21:13] <slangasek> Saviq: rerunning with -proposed requires release team privs, #ubuntu-release is a better place to get attention generally - anyway, looking
[21:15] <Saviq> slangasek, noted, thanks
[21:15] <slangasek> Saviq: and it'll take me a little bit, I have to get openvpn to pass packets instead of eating 100% CPU first
[21:15] <Saviq> slangasek, no rush :)
[21:20] <slangasek> Saviq: triggered
[21:23] <Saviq> tx
[21:44] <slangasek> nacc: 140-ish packages to go for php5 removal?
[21:44] <slangasek> hmm where did we get to on swig?
[21:44] <slangasek> oh and that's a count of binary+source packages, so way high
[21:45] <nacc> slangasek: yeah, my count is at 95 as of this morning, iirc
[21:45] <slangasek> (as well as lagging behind the archive)
[21:45] <slangasek> cool
[21:45] <nacc> slangasek: swig is still no progress; i've been just trying to get our packages going as far as i can
[21:45] <nacc> it's a pretty big change and i have to go and learn the internals of php a bit :)
[21:45] <nacc> slangasek: 88 currently
[21:45] <slangasek> swig was supposed to be removals, I thought?
[21:45] <nacc> slangasek: sorry, for that big
[21:46] <nacc> i think we're pretty close to done with those that needed packages removed/disabled
[21:50] <slangasek> nacc: php-sabre-vobject-3 ftbfs
[21:52] <nacc> slangasek: grr, sorry! you're right, i meant to move it to the other list
[21:58] <slangasek> nacc: php-sabredav has php-horde-dav as a revdep (LP: #1565025).  What's the compatibility story for that?  (Please provide details on the FFe bug)
[22:09] <nacc> slangasek: urgh, ok, let's hold off on that, i don't think we can move just one piece of horde around
[22:09] <nacc> slangasek: will investigate
[22:10] <slangasek> nacc: ok, commented on the bug in the meantime, thanks
[22:12] <nacc> slangasek: thanks, might be able to avoid upgrading by just fixing the tests
[22:12] <nacc> verifying that now
[22:17] <slangasek> nacc: and php-net-ldap2 uploaded, if you can't reproduce the autopkgtest failure I'm going to not care about it unless it reproduces on the production infra
[22:18] <slangasek> let's not waste time debugging idiosyncracies of /my/ autopkgtest setup
[22:21] <nacc> slangasek: sure, thanks ... i'm really not sure; i did see it before i fixed the deps
[22:21] <slangasek> nacc: I saw a /different/ failure before I fixed the dep
[22:21] <nacc> funny
[22:21] <slangasek> one that very clearly pointed to PEAR.php not being on the include path :)
[22:21] <nacc> heh, yeah, i did see that one earlier too
[22:22] <slangasek> ah, php-radius, two of my favorite technologies in one small package
[22:25] <nacc> heh
[22:33] <slangasek> nacc: question for you in the bug on php-radius, whenever you have a chance to look
[22:35] <nacc> slangasek: will do; fyi for the FFe just refrenced, i think we can get away with some testcase updates and updated deps
[22:36] <nacc> testing it now
[22:36] <nacc> will modify the bug
[22:55] <nacc> slangasek: fyi, php-xml-serializer FTBFS in wily too; not sure why yet, it seems to be a path issue with phpunit
[22:55] <nacc> it's very confusing, as some tests are clearly passing during build
[23:02] <nacc> slangasek: nm, found advice from debian in some bugs
[23:46] <slangasek> nacc: does the patch on bug #1565025 for php-sabre-vobject mean no further update is required for php-sabredav?  or are you still working through that part?
[23:48] <nacc> slangasek: just posted that part too
[23:48] <nacc> slangasek: sorry, shoudl have mrked the state properly as i was working on it
[23:49] <slangasek> nacc: no worries, it just means you wind up having to talk to me more
[23:50] <nacc> slangasek: yep, sorry, i've bene pretty quiet today just trying to figure those last two out
[23:53] <slangasek> nacc: php-pecl-http has unsatisfiable versioned deps on php-raphf and php-propro, because something said '2.0.0dev' and the actual versions are '2.0.0-' which is lower so the dep is not satisfied.  something (pkg-php-tools?) needs to translate 'dev' to '~dev', or else something needs to be manually fixed in a package.xml or such
[23:55] <nacc> slangasek: ah i see it now -- i'll send an update right now; not sure why they did that to pakcage.xml
[23:55] <nacc> and not sure why it built here ... strange
[23:55] <slangasek> it builds, it's just uninstallable after
[23:55] <nacc> oh i see
[23:55] <nacc> yeah
[23:55] <nacc> ok
[23:59] <nacc> slangasek: new diff posted in LP: #1564566