[00:22] <nacc> slangasek: actually, we'll need some updates, nm
[00:51] <slangasek> nacc: dns resolution failures of ftpmaster.internal are transient failures and should be retried. was that a package build or autopkgtest?
[00:57] <cyphermox> tsimonq2: I'm around, mostly. just took an hour to get food and get my mind off upgrades for a big
[00:57] <tsimonq2> cyphermox: hey, I have an idea on bhow to solve 4 FTBFSes, a build-dep error
[00:58] <tsimonq2> *how
[00:58] <tsimonq2> cyphermox: I'm willing to bet the FTBFS on oxide-qt has been solved (waiting on build-deps) as the build was tried on 3-10 and the latest upload of the dependency it was waiting on is 3-16, could you please trigger a rebuild? https://launchpad.net/ubuntu/+source/oxide-qt/1.13.6-0ubuntu1/+build/9329555 and https://launchpad.net/ubuntu/+source/libhybris/0.1.0+git20151016+6d424c9-0ubuntu7 for proof, the (2) dependencies it were waiting on have
[00:59] <tsimonq2> cyphermox: 4 different build-dep FTBFSes caused by it, media-hub, oxide-qt, unity-webapps-qml, and webbrowser-app, so if it works on oxide-qt, it should work on the others as well
[01:00] <tsimonq2> cyphermox: mind confirming or denying my hunch?
[01:01] <cyphermox> denying right away
[01:02] <cyphermox> libhybris isn't built on arm64, that's a long time issue
[01:02] <sarnold> iirc when I looked at the code it had issues that'd keep it from working correctly on 64 bit platforms
[01:02] <nacc> slangasek: it was a packge build
[01:03] <cyphermox> sarnold: seems to be build on amd64 in any case
[01:03] <cjwatson> tsimonq2: It's very easy to check this using "rmadison libhybris-dev" and noting the absence of arm64.
[01:03] <cyphermox> sarnold: not that it's very useful there ;)
[01:03] <tsimonq2> cjwatson: oh thanks :)
[01:03] <cjwatson> tsimonq2: Also, dep-waits like that are automatically given back if the dependency becomes available.
[01:03] <cjwatson> tsimonq2: It's only necessary to do anything with them by hand if something has gone wrong with Launchpad.
[01:04] <tsimonq2> cjwatson: makes sense, sorry, thanks :)
[01:04] <sarnold> cyphermox: hah :) surprising..
[01:04] <cyphermox> haha, not really
[01:04] <cyphermox> it's weird android magic, IIRC
[01:04] <sarnold> yeah
[01:05] <tsimonq2> while I have some people here, what's holding up bug 1547395 ?
[01:05] <sarnold> I'd expect it to build on arm32 and only arm32..
[01:05] <cyphermox> it builds on amd64, but won't do anything and might in fact blow up if you try to use it
[01:05] <cyphermox> yeah
[01:05] <tsimonq2> so then why do we have it in Ubuntu?
[01:05] <tsimonq2> JUST for those people?
[01:05] <cyphermox> tsimonq2: it is necessary on armhf for some ubuntu touch stuff
[01:06] <tsimonq2> ohh I see :)
[01:06] <tsimonq2> cyphermox: so then should we expect those guys to take a look?
[01:06] <TJ-> Do we have any Network Manager code-huggers or is it all upstream?
[01:07] <cjwatson> tsimonq2: not until it becomes important to port Ubuntu Touch to arm64
[01:07]  * cyphermox whistles innocently
[01:07] <cjwatson> tsimonq2: we don't *have* to clear all arch-specific dep-waits
[01:07] <nacc> Pharaoh_Atem: can you also sync with remi & ondrej on php-mysqlnd-ms (https://bugs.php.net/bug.php?id=70371)
[01:07] <cjwatson> sometimes things are just hard to port
[01:07] <tsimonq2> cjwatson: I see :)
[01:08] <cjwatson> it's only any kind of blocker if it results in a package's architecture support regressing
[01:08] <tsimonq2> now, I went on a tangent, I'll ask this for the last time (so I don't annoy people further), but bug 1547395 ?
[01:08] <cyphermox> tsimonq2: that's kind of why I suggested you look at the red things before the orange ones on the ftbfs report; unbreaking the red might unblock some orange by itself (and for others it's because deps aren't targetted for that arch at all)
[01:09] <tsimonq2> cyphermox: that bug would unblock the only red in main, FYI, so yes, I took your recommendation ;)
[01:09] <tsimonq2> (only all-arch)
[01:10] <tsimonq2> (and the only one I even have a sight hope of fixing)
[01:11] <tsimonq2> *slight
[01:25] <nacc> slangasek: is there a good way for me to fix the false positives in `reverse-depends` with php-pear (which used to come from src:php5, but now is from src:php-pear) ?
[01:26] <nacc> slangasek: fwiw, it does seem like our list is going well and reduced quite a bit, the ones that are still present that i've marked as done in my list are due to php-pear or due to allowing php5(*) | php(*)
[01:27] <nacc> down to 125 packages in my list! :)
[01:27] <slangasek> nacc: we can remove php5 from the archive, and then the false positives will disappear
[01:27] <slangasek> at the cost of other packages becoming immediately uninstallable
[01:28] <nacc> slangasek: it's ok, i just am making notes to myself
[01:28] <nacc> slangasek: i think we're looking good to be very close by friday at this rate
[01:29] <nacc> slangasek: i might just try to write a wrapper for the tooling that handles the few cases i know about
[01:30] <slangasek> right, you can also reverse-depends | grep -v php-pear :)
[01:30] <nacc> slangasek: that's true, but i've been using reverse-depends src:php5
[01:30] <nacc> nad the problem is php-pear is in that list, i'm guessing :)
[01:31] <slangasek> nacc: yes, but the output of reverse-depends indicates what binary package the reverse-dependency is on.  So 'grep -v php-pear' should DWIM
[01:31] <Pharaoh_Atem> nacc: yeah, I'll check into it
[01:32] <nacc> slangasek: oh i see what you're saying! yeah, i've been using -l, but w/o it, i can do what you suggested
[01:32] <slangasek> nacc: ah yes - grep -v and then postprocess, to reproduce the -l style list :)
[01:32] <nacc> yep :)
[01:32] <slangasek> I only learned about -l recently, and already forgot it again ;)
[01:34] <nacc> slangasek: fair enough :)
[01:35] <nacc> nice that gets me down to 199 src packages, plus the ones still going through right now, which is closer to my list
[01:35] <nacc> will need to do some more post-processing to ensure that if something depends on php5* and php*, it doesn't show up in the list :)
[01:36] <nacc> slangasek: thank! i'm done for the day again
[01:37] <mwhudson> ho boy i can no longer remember how to use bzr
[01:38] <sarnold> mwhudson: heh, same happened to hallyn earlier today. he went to play in the sun instead... :)
[01:38] <mwhudson> funnily enough it's basicaly time to take my daughter swimming
[01:38] <sarnold> have fun :)
[01:39] <slangasek> mwhudson: schroot -c trusty -c 'apt-install bzr-git; ...'
[01:39] <slangasek> except obviously not that ;)
[01:39] <mwhudson> yeah how about no
[01:49] <nacc> Pharaoh_Atem: thanks!
[04:17] <Pharaoh_Atem> nacc: Remi seems to believe that mysqlnd_{ms,qc} modules are dead projects, due to Oracle not matching up to their promises on updating it
[04:25] <Pharaoh_Atem> and he's got no idea about whether php-horde-mongo is even being maintained/updated
[04:25] <Pharaoh_Atem> a little poking around indicates nothing particularly good: https://github.com/horde/horde/commits/master/framework/Mongo
[04:54] <sarnold> superm1: dude, 1536871, beautiful work.
[04:54] <superm1> sarnold: thanks
[04:54] <sarnold> superm1: you have no idea how nuts this was driving me.
[04:55] <superm1> sarnold: i should have trusted the fact that the test suite failed meant something.  i bet this is also causing weird problems for other apps that use gpgme1.0
[04:55] <sarnold> superm1: oh hell.
[04:55] <sarnold> I bet you're right.
[04:56] <superm1> at least for 16.04 the answer is to update to gnupg2 2.1 (which I just uploaded to -proposed)
[04:57] <sarnold> mdeslaur: ^^^ is there a reason we were on gnupg2 2.0 still? i've got a vague feeling that there was something Important but I can't recall what I am thinking of
[05:02] <sarnold> superm1: well, good news, looks like only ruby-gpgmg and fwupd in the debian codesearch archives use that function.
[05:14] <superm1> sarnold: ok that's good news indeed.  i'm surprised seahorse doesn't also use it because running into failures with it is what led me down this rabbit hole.  must be completely separate problems :)
[05:14] <sarnold> superm1: or the version of seahorse where you ran into it isn't indexed in DCS :/
[05:15] <sarnold> it's a great tool but only approximate to what we ship.. :(
[05:15] <superm1> yeah
[05:16] <Unit193> I'm missing the source browser. :/
[05:20] <ScottK> superm1: If you update gnupg2 to 2.1, you'll need to sync pygpgme from Debian too.
[05:21] <superm1> ScottK: OK thanks for the heads up
[05:22] <ScottK> yw
[06:10] <cpaelzer> good morning
[06:46] <pitti> Good morning
[06:47] <pitti> Saviq: I'll mark them as bad tests for this version for now
[06:49] <dholbach> good morning
[08:40] <Saviq> pitti, morning, did you manage to get ssh-into-britney going? we have another case of WTH with a failure we can't reproduce locally https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-046/excuses.html (any of the Regression ones, really)
[08:41] <pitti> Saviq: what is "ssh into britney"?
[08:41] <pitti> oh, ssh into a failing test? yes, that works
[08:41] <pitti> testbed, I mean
[08:41] <Saviq> pitti, yeah, that
[08:41] <pitti> Saviq: I thought you asked me two weeks ago, but then wanted to try something else first
[08:42] <Saviq> pitti, yeah we found the issue then
[08:42] <Saviq> pitti, but now we have another one we can't reproduce locally and it might be most time-effective to just get in the failing testbed
[08:45] <pitti> Saviq: I started the test manually with -s
[08:45] <Saviq> pitti, ack, thanks
[10:29] <pitti> cjwatson: hmm, snakefruit is still precise and its apt-ftparchive does not yet know xz; but I don't even see the option documented in xenial; does LP just pack them manually, or do you use apt-ftparchive?
[10:30] <pitti> err, germanium, but same thing
[10:31] <cjwatson> pitti: LP uses a backport of trusty's apt (slightly patched to add source caching)
[10:31] <cjwatson> it's in precise-cat-lp or some such
[10:32] <cjwatson> and we do use apt-ftparchive, yes
[11:13] <mdeslaur> superm1, sarnold: yeah, we were waiting for debian bug 796931 to be resolved before switching to gnupg 2.1
[11:18] <doko> mdeslaur, ugh, it looked to me that seth was fine with approving qnupg 2.1 ... so should we remove it from -proposed?
[11:21] <pitti> cjwatson: http://ddebs.ubuntu.com/dists/xenial/main/binary-amd64/
[11:22] <doko> mdeslaur, superm1: ^^^it's dep-wait for now anyway
[11:22] <mdeslaur> superm1, sarnold, doko: I'm not exactly sure what the exact impact of that is going to be, or if that bug will get resolved at some point...I do think it's going to break some use-cases, but perhaps those use-cases need to be adjusted
[11:23] <cjwatson> pitti: ah, excellent; will it also now cope with bz2 being absent from the Ubuntu archive?
[11:23] <mdeslaur> superm1, sarnold, doko: I'm not sure what the right answer is
[11:23] <doko> mdeslaur, I was looking at https://bugs.launchpad.net/ubuntu/+source/npth/+bug/1536871
[11:24] <pitti> cjwatson: ah, not yet, but that's a simple change; is there any format that will be always present, i. e should I just switch .bz2 to .gz? (while .xz isn't yet available for all series)
[11:24] <cjwatson> pitti: the best approach is to try .xz .bz2 .gz uncompressed in succession
[11:25] <cjwatson> pitti: Debian is flirting with getting rid of .gz and we might eventually do the same
[11:25] <pitti> ok; that's an extra urlopen/error check, but I'll do that after lunch then
[11:25] <cjwatson> pitti: but at the moment .gz is always present, so if trying more than one is too hard then it's ok to just use .gz
[11:25] <cjwatson> for now at least
[11:26] <pitti> not too hard, just a bit more work than a single-letter change
[12:01] <caribou> xnox: got a minute ?
[12:02] <xnox> caribou, sure
[12:02] <caribou> well, I can ask in the room, maybe somebody else will have an opinion :
[12:03] <xnox> in the room is best =)
[12:03] <caribou> The debian maintainer for vsftpd thinks it's a good idea to leave the package in a state that cannot start ( Bug#819546)
[12:04] <caribou> they reverted listen_ivp6 from YES to NO to match the manpage default and now the systemd job will not start
[12:04] <caribou> (between wily & xenial)
[12:05] <caribou> my guess is that he/we should at least add a prompt to ask to enable it otherwise disable the systemd job
[12:06] <xnox> i believe we too, do not start vsftpd by default.
[12:06] <xnox> as one must configure it to start
[12:07] <xnox> e.g. #ubuntu-hardened default is no open ports by default. And hence e.g. we never install openssh-server by default.
[12:07] <caribou> xnox: let me recheck but it was set to YES in wily
[12:07] <xnox> i'd rather look at e.g. trusty
[12:07] <xnox> there is loads of flux in init/startup between there and now.
[12:07] <caribou> xnox: well we didn't do anything, it was set to YES in the uptream package
[12:09] <caribou> xnox: it starts by default on W
[12:09] <caribou> lemme check trusty
[12:09] <xnox> caribou, right and on trusty
[12:09] <xnox> it does start and does listen
[12:09] <xnox> tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      23463/vsftpd
[12:10] <xnox> caribou, imho it should listen on ::* by default
[12:10] <xnox> sorry [::]:21 that is
[12:10] <xnox> (any ipv4/6 on port 21)
[12:11] <xnox> annonymous access is disabled, and we don't install it by default so i think it's what we intended for it to be.
[12:11]  * xnox is also looking at e.g. ftp server docs
[12:11] <caribou> xnox: I think it is how it was done on Debian as well, until Bug: #803999
[12:11] <caribou> nah debian bug
[12:12] <caribou> I mean taking something that works on install and leave it broken because this is the manpage default doesn't look good to me
[12:13] <xnox> imho it's the manpage that is broken.
[12:13] <caribou> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819546
[12:13] <xnox> but default should listen on _both_ ipv4 and ipv6 from a single daemon
[12:13] <caribou> listen_ipv6 will do both
[12:13] <xnox> that's a debian ipv6 goal
[12:14] <xnox> but that's (a) regression (b) deviation from debian policy
[12:14] <xnox> e.g. installing apache2 on debian does bring it up and start serving pages
[12:14] <xnox> ditto ftp.
[12:15] <xnox> caribou, patch it in ubuntu, and then comment more on the bug report.
[12:16] <caribou> xnox: fine by me.
[12:16] <caribou> xnox: on another topic, I've been testing zfcpdump
[12:17] <caribou> xnox: as inaddy said, we do need a small footprint kernel in order to get it to work
[12:19] <xnox> caribou, talk to kernel people about it =)
[12:19] <xnox> kernel team maintains all kernels on s390x.
[12:19] <caribou> xnox: yes, been doing so, just wanted to keep you posted
[12:19] <xnox> (well the one kernel)
[12:19] <xnox> cool.
[12:35] <pitti> cjwatson: ok, done; it now does the xz → gz → uncompressed fallback
[12:50] <cjwatson> pitti: could you then do https://paste.ubuntu.com/15567519/ and we'll see if everything works with bz2 indexes dropped from xenial?
[12:51] <cjwatson> pitti: in lp-shell production devel
[12:52] <pitti> cjwatson: done
[12:56] <cjwatson> pitti: thanks, let's see how that works out
[12:57] <doko> ginggs, do you know about the background for the different wine packaging in Debian/Ubuntu ?
[12:58] <ginggs> doko: yeah, i did some digging a few weeks ago
[12:58] <ginggs> so I know a little
[12:59] <doko> ?
[13:00] <ginggs> what is it you want to know? I put some of the info I found here LP: #1558480
[13:01] <highvoltage> Scott Ritchie (YokoZar) did a large amount of work on wine in ubuntu but that didn't make it back to debian.
[13:01] <ogra_> he always did it directly upstream instead
[13:01] <doko> ginggs, I'm more curious why 1.8 was not uploaded
[13:01] <ogra_> skipping debian in the chain
[13:02] <doko> the packages in the ppa were last touched in December
[13:03] <doko> ginggs, highvoltage, ogra_: the easy way would be to upload the debian package, bumping the epoch for the wine binary package
[13:03] <ogra_> afaik upstream was always unhappy about some splits debian did ... YokoZar is originally more of an upstream guy than a debian dev
[13:03] <doko> yeah, but if nothing is happening ...
[13:04] <ogra_> the prob will likely be upgrades here
[13:04] <ginggs> doko: lack of time? interest? i don't know... I tried contacting both members of wine team
[13:05] <ginggs> doko: i don't think it is as easy as that, there are some packages in debian/ubuntu wine that have different names and some that have the same names
[13:05] <highvoltage> might be a good idea to get in touch with scott: https://wiki.ubuntu.com/ScottRitchie - maybe he would like to pick it up again or maybe he wants to retire from it for good.
[13:05] <ogra_> right
[13:05] <doko> ginggs, not afaics
[13:05] <highvoltage> ginggs: aah
[13:06] <ginggs> doko: i had an idea for a transitional package, that i was testing in my ppa, it sort of worked, but then keeps wanting to upgrade one of the packages, I think because wine1.6 still exists in the archive
[13:06] <ginggs> doko: i think removing wine1.6 is the first step
[13:07] <doko> ginggs, reverse-depends tells you otherwise
[13:07] <doko> Reverse-Recommends
[13:07] <doko> [13:07] <doko> * q4wine [amd64 arm64 armhf i386 powerpc]  (for wine)
[13:07] <doko> * q4wine [amd64 i386]           (for wine1.6)
[13:07] <doko> * winetricks                    (for wine)
[13:07] <doko> Reverse-Depends
[13:07] <doko> [13:07] <doko> * dssi-vst [i386]               (for wine1.6-i386)
[13:07] <doko> * playonlinux                   (for wine)
[13:07] <doko> * pq                            (for wine)
[13:07] <doko> Reverse-Build-Depends
[13:07] <doko> [13:07] <ginggs> doko: if it is not possible to have a transitional package to deal with the epoch bump, I can try working with the debian packagers to do it there
[13:07] <doko> * dssi-vst                      (for wine1.4-dev)
[13:08] <doko> ginggs, did you try to use the wine1.8 packages in the ppa?
[13:10] <ginggs> doko: no, i have been using the debian packages for some time now
[13:11] <TJ-> anyone know how to prevent the Network Manager build from failing due to testsuites not workable, on a local 'fakeroot' build ?
[13:12] <ginggs> doko: since november last year, there is another "wine team" PPA https://launchpad.net/~wine/+archive/ubuntu/wine-builds
[13:12] <TJ-> specifically: "ERROR: test-nm-client - too few tests run (expected 9, got 0)"
[13:12] <cyphermox> TJ-: typically you want to run that in autopkgtests
[13:12] <cyphermox> or in a vm, or in a chroot
[13:13] <cyphermox> the tests are dependent on the interfaces on your system, so that may explain why they fail
[13:13] <doko> ginggs, ogra_: sent email
[13:13] <TJ-> cyphermox: any way to simply disable the tests with an env-var for the 'debian/rules binary' build process; I'm wanting to test some patches and don't need the testsuite right now
[13:14] <doko> ginggs, only devel builds
[13:14] <cyphermox> TJ-: override_dh_auto_test to not contain anything
[13:15] <TJ-> cyphermox: so "override_dh_auto_test: > dbus-test-runner -m 300 -t dh_auto_test" becomes just "override_dh_auto_test:" ?
[13:16] <cyphermox> TJ-: precisely
[13:16] <TJ-> cyphermox: thank you :)
[13:16] <TJ-> cyphermox: for reference I'm working up a patch for bug 1533631
[13:18] <TJ-> ah, that needs renaming to be accurate, it's now "dhclient killed when DHCPv6 lease is out-of date"
[13:19] <ginggs> doko: i think it was mlankhorst who did the last wine ppa upload
[13:19] <cyphermox> TJ-: have you tried git master? it likely already has a patch
[13:20] <TJ-> cyphermox: I'm working from master; there's no handling of deprefer upstream at all
[13:20] <cyphermox> ok
[13:20] <TJ-> cyphermox: I gen the patch on master, then import into the Ubuntu package for testing
[13:46] <pabelanger> morning, did openjdk-7-jdk get removed from ubuntu xenial?
[13:47] <pabelanger> it was installable up until last night
[13:49] <pitti> pabelanger: yes, see bug 1563986
[13:49] <pabelanger> pitti: thanks for confirming
[13:52] <pitti> arges, tjaalton: would you mind reviewing/accepting the postgresql SRUs for p, t, and w? (should just be a formality, but self-acceptance is bad)
[13:54] <tjaalton> pitti: I will tomorrow, if arges doesn't beat me to it before that
[13:54] <arges> working on something now, may have time later today
[13:54] <pitti> thanks
[14:35] <Saviq> pitti, hey, we managed to find a way to repro locally, you can release, thanks!
[14:46] <rharper> slangasek: I updated https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691 ; the previous upload (1ubuntu3) resolved the removal of squid3 service file; 1ubuntu4 addresses your second comment (remove logic around service name and just use restart squid);
[14:56] <pitti> Saviq: cool, thanks
[14:57] <pitti> arges: thanks
[15:04] <nacc> Pharaoh_Atem: i filed https://bugs.horde.org/ticket/14309 for php-horde-mongo
[15:04] <nacc> Pharaoh_Atem: so do you think we're safe to remove them? i'll check revdeps
[15:05] <nacc> Pharaoh_Atem: ok, no revdeps, will schedule for removals
[15:09] <doko> apw, infinity: are these expected failures? autopkgtest for linux 4.4.0-16.32
[15:11] <pitti> we have a hint for 4.4.0-15.31 as -15 broke the apparmor test; looks like that's still true for -16?
[15:12] <chiluk> infinity xnox  https://bugs.launchpad.net/ubuntu/+source/quassel/+bug/1506550
[15:25] <nacc> woo, down to 131 packages blocking removal of src:php5, src:php-json, src:dh-php5!
[15:44] <tyhicks> pitti: hi - are you talking about a kernel failure?
[15:45] <Son_Goku> nacc: I think we’re good on removals for them
[15:45] <Son_Goku> I’ve not encountered anything that uses either of them
[15:45] <pitti> tyhicks: yes, on http://autopkgtest.ubuntu.com/packages/l/linux/xenial/amd64/
[15:45] <tyhicks> I think I know the issue
[15:45] <tyhicks> give me a sec to confirm
[15:45] <Son_Goku> nacc: bbs as Pharaoh_Atem
[15:45] <nacc> Son_Goku: thanks
[15:47] <tyhicks> 14:37:07 ERROR| [stderr] Error: changeprofile failed. Test 'CHANGEPROFILE (no target, /tmp/sdtest.14571-11349-vxV2zx/file)' was expected to 'fail'. Reason for failure expect errno 13 != 2
[15:47] <tyhicks> 14:37:07 ERROR| [stderr] Error: changeprofile failed. Test 'CHANGEPROFILE (no target, /tmp/sdtest.14571-11349-vxV2zx/file2)' was expected to 'fail'. Reason for failure expect errno 13 != 2
[15:48] <tyhicks> pitti: the apparmor 2.10.95 upload (currently awaiting FFe approval) adjusts the CHANGEPROFILE test to match the behavior found in the -15 and -16 kernels
[15:48] <tyhicks> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1561762
[15:49] <pitti> tyhicks: ah, that should fix the test again? thanks for the heads-up
[15:49] <tyhicks> pitti: yes, I'm 100% sure that'll fix the test
[15:50] <slangasek> rharper: fwiw on squid, stgraber's dpkg-maintscript-helper changes were incomplete and wrong.  I'll follow up today
[15:59] <doko> superm1, online?
[15:59] <superm1> doko: Yep
[15:59] <ice799> Hi there. I'm seeing quite a few Hash Sum mismatch errors when using APT against an APT repository I generated. I've verified manually with curl shasum and md5sum on the commandline that the hash sums are correct.
[16:00] <ice799> I found this bug filed: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1373598 but it appears not to be assigned yet
[16:00] <ice799> I was mostly curious what the process is for bugs that are marked high,confirmed to be assigned if there is one
[16:00] <doko> superm1, any idea what would go wrong when updating to the new gnupg2 version?
[16:01] <superm1> doko: the only that came to mind was what mdeslaur raised regarding the difference in behavior with the agent
[16:01] <superm1> there was quite a bit of discussion on the debian bug about it
[16:03] <doko> superm1, do you know about packages which would depend on this?
[16:04] <ice799> a similar bug was reported for XZ compressed APT repositories, against APT here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744758 which was fixed in APT version 1.0 and newer
[16:05] <superm1> doko: depend on the new command line arguments that came in version 2.1?
[16:07] <superm1> or you mean the difference in behavior with the agent?
[16:07] <doko> superm1, the debian bug talks about the changed filename, not command line options
[16:08] <cjwatson> ice799: if it's a repository you generated yourself I'd still suspect the repository before suspecting apt.  there are various debugging options under the "DEBUG OPTIONS" section of "man apt.conf" that you should try first to determine precisely which checksums it's complaining about
[16:10] <cjwatson> ice799: bug 1373598 seems a lot more likely to be some kind of proxy handling bug, it's unlikely you in fact ran into that with a local repo
[16:10] <superm1> doko: right i was meaning the impetus that got into pulling gnupg 2.1 in the first place.  on that bug i think it would really  affect expected behavior from previous versions of gpg-agent
[16:11] <cjwatson> (and we're working on a general solution to that class of problem, hopefully for 16.04, but that's on the server side and won't apply to a locally-generated repository)
[16:11] <superm1> so it might affect what gets passed through on say an SSH login
[16:13] <doko> so maybe people need adjust, but no packages need adjustments
[16:14] <superm1> right
[16:14] <superm1> if anything at some point it might be worthwhile to SRU the outcome of that debian bug
[16:15] <nacc> slangasek: just filed LP: #1564492, which is a FTBFS due to a debhelper issue (patch for debhelper attached)
[16:18] <slangasek> nacc: er, is non-ascii allowed in description fields under Debian policy?
[16:19] <nacc> slangasek: the fix is from Debian, so I assumed so, let me see if i can find it i the policy
[16:21] <nacc> slangasek: hrm, good point...
[16:21] <doko> superm1, mdeslaur, https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1536871  subscribing foundations. can you subscribe security too? same as currently for gnupg2
[16:21] <nacc> "The field name is composed of US-ASCII characters excluding control characters, space, and colon (i.e., characters in the ranges 33-57 and 59-126, inclusive)."
[16:21] <nacc> slangasek: so names can't have non-ASCII, but it's unclear if the value can
[16:22] <slangasek> nacc: it's allowed these days in /some/ fields, but I'm not sure if Description is one or if it makes sense to
[16:22] <cjwatson> I'm fairly sure Description can be UTF-8 and non-ASCII
[16:23] <nacc> slangasek: ok, reading https://www.debian.org/doc/debian-policy/ch-controlfields.html I don't see anything specifying it, but maybe looking in the wrong place
[16:23] <cjwatson> It seems like one of the most obvious fields that would want to be non-ASCII
[16:23] <slangasek> ok
[16:23] <slangasek> cjwatson: I knew we'd allowed it for Maintainer, but for description I wasn't sure if it was allowed or if that was only permitted in translated fields
[16:23] <cjwatson> The policy language seems a bit woolly on it though
[16:24] <nacc> "All control files must be encoded in UTF-8" and it only explicitly mentions "field name" as being in ASCII
[16:24] <nacc> afaict
[16:25] <nacc> slangasek: i mean, i think it's the "long dash" character in teh description, which we could also change ... whatever you'd prefer
[16:25] <cjwatson> There are examples that already do, e.g. cvs, deja-dup
[16:25] <cjwatson> cvs is a bit gratuitous but deja-dup is IMO reasonable
[16:26] <cjwatson> or firefox-locale-nb which is definitely reasonable
[16:26] <superm1> mterry: when you did a local test suite run for fwupd (that presumably had libtool-bin installed), did you see something like this in your output log [ Fu:ERROR:fu-self-test.c:219:fu_provider_func: assertion failed (error == NULL): Error creating directory                : Permission denied (g-io-error-quark, 14) ]?
[16:26] <doko> superm1, both promoted
[16:26] <superm1> doko: okay thanks
[16:26] <mterry> superm1: uh my test failure just said something like Aborted, as if there was a segfault...  let me run it again
[16:27] <superm1> does launchpad drop permissions for the build?  i can only seem to reproduce it on launchpad, not in pbuilder locally
[16:28] <superm1> mterry: src/test-suite.log unfortunately isn't automatically output, so you need to apply something like this to get it to output in an automated build: http://pastebin.com/z1aRQBSf
[16:29] <mterry> superm1: ah yes, in test-suite.log: Fu:ERROR:fu-self-test.c:219:fu_provider_func: assertion failed (error == NULL): Error creating directory: Permission denied (g-io-error-quark, 14)
[16:29] <cjwatson> superm1: Launchpad uses sbuild which runs the build as a non-root user
[16:29] <superm1> ah OK.  I'll dig further into this then
[16:34] <ricotz> could someone take care of https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1557955
[16:35] <nacc> ricotz: wouldn't it need a FFe?
[16:35] <teward> it would at this point
[16:35] <teward> past FeatureFreeze
[16:36] <nacc> ricotz: https://wiki.ubuntu.com/FreezeExceptionProcess
[16:36] <ricotz> nacc, it does, I was about to file a bug, and found about that one
[16:39] <ricotz> filed a proper one https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1564510
[16:40] <Odd_Bloke> cjwatson: pitti: I'm not 100% sure what's happening with Packages.(bz2|xz), but http://archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.xz doesn't exist (which is breaking some of our scripting :).
[16:44] <Odd_Bloke> (I am fixing the script(s) to handle failing over to different compression types)
[16:45] <cjwatson> Odd_Bloke: your scripting is indeed just buggy, since that file isn't advertised in .../xenial-security/Release
[16:45] <cjwatson> Odd_Bloke: Packages.xz will appear next time xenial-security is actually published :)
[16:46] <Odd_Bloke> cjwatson: OK, cool.
[16:47] <ice799> cjwatson: may i ask what the proposed server-side solution is for 16.04? Is it documented somewhere?
[16:47] <ice799> cjwatson: its not a proxy bug -- no proxy is being used and the repo is being transmit over HTTPS
[16:48] <ice799> cjwatson: i've manually verified all checksums, but i agree that getting APT to be more verbose about what it thinks is wrong would be helpful
[16:51] <cjwatson> ice799: Basically https://wiki.debian.org/RepositoryFormat#indices_acquisition_via_hashsums_.28by-hash.29, but this is only applicable if your problem is a race condition between clients and repository updates; if you're seeing problems when the repository is at rest then this is not relevant.
[16:51] <cjwatson> ice799: You very much need to not conflate a ton of different possible causes for hash sum mismatches.
[16:52] <ice799> ah finally
[16:52] <ice799> indexes with hash sums in the URL
[16:52] <cjwatson> ice799: -o Debug::Acquire::https=true -o Debug::Hashes=true is probably a good place to start/
[16:52] <cjwatson> s,/,.,
[16:58] <mterry> doko: fwupd tests weren't sorted out yet man
[16:58] <doko> mterry, ohh, sorry
[16:58] <doko> superm1, ^^^
[16:58] <mterry> doko: it's ok, superm1 is working on them
[16:59] <mterry> superm1: please continue to work on them, even though fwupd is in main now  :)
[16:59] <superm1> yeah i'll get something in next upload
[16:59] <superm1> the test suite is just referring to stuff outside the build dir, i'd like to fix it the right way upstream first
[17:06] <ice799> cjwatson: Debug::Hashes doesn't seem to tell me anything but I do see some HTTP 416s come back
[17:08] <ice799> looks a bit like this one: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/798023
[17:15] <cjwatson> ice799: I think I'd get further seeing the raw apt-get update output with those debug options than guessing at bugs
[17:16] <cjwatson> (though am about to go for dinner)
[17:16] <ice799> cjwatson: ah i see
[17:16] <ice799> i had a typo
[17:16] <ice799> yea so
[17:17] <ice799> i see a "201 URI Done" with a list of hashes that all match
[17:17] <ice799> followed by a "[6 Packages store 0 B]"
[17:17] <ice799> with hashes that mismatch
[17:17] <cjwatson> I'm not promising to debug it, but if I were you, I would put the output on paste.ubuntu.com rather than summarising it in prose
[17:18] <cjwatson> a paste of the relevant Release file would probably be useful too
[17:18] <ice799> the release file is right
[17:19] <cjwatson> that doesn't mean it isn't useful for debugging
[17:19] <ice799> agreed
[17:19] <ice799> the actual APT error appears to be: W: Failed to fetch store:/var/lib/apt/lists/partial
[17:19] <ice799> with a long path
[17:19] <ice799> i need to read the apt source to see what failed to fetch store really means
[17:19] <ice799> because from the output it looks like what apt is downloading is right, but after the download it tries to unpack it and then fails to verify
[17:19] <cjwatson> also there are some subtleties that are not obvious, like handling of uncompressed files
[17:20] <cjwatson> that's why I'm asking for the Release file
[17:20] <ice799> im gathering all of this information now
[17:21] <Saviq> slangasek, bad news, we've another cmake-3.5-related problem - the latest failure in http://autopkgtest.ubuntu.com/packages/u/unity8/xenial/amd64/ is caused by new cmake building/linking the test differently (I confirmed - downgraded cmake and test passes again)... not yet sure what the exact difference is :/
[17:24] <doko> Saviq, what's the error?
[17:24] <Saviq> doko, "QObject::connect: signal not found in DirectionalDragArea"
[17:24] <Saviq> when running the test
[17:24] <doko> Saviq, how do you know that's a link error?
[17:25] <Saviq> doko, I don't, I just know the error goes away and test passes when I downgrade cmake...
[17:26] <Saviq> doko, or, it's a red herring...
[17:26] <cjwatson> dinner bell, EOD
[17:27] <doko> Saviq, a little more investigation would be nice, or maybe ask LocutosOfBorg (currently not online)
[17:28] <Saviq> doko, yeah, I'm trying to get as much data as possible (I'm not saying we're doing everything right), but I can confirm that downgrading cmake makes it work again...
[17:37] <Saviq> doko, slangasek, OK unping, it's not about how it's built, but how the test is invoked - and it was invoked incorrectly before
[17:39] <Saviq> or not, /me is lost completely
[17:42] <Saviq> ok no, it is really how it is built
[17:45] <ginggs> Saviq: LocutusOfBorg having trouble with irc lately, but drop him an email
[17:46] <ginggs> doko: do you have any opinion on LP:  #1562287 ?
[17:48] <doko> ginggs, no :-/
[17:58] <slangasek> nacc: debhelper uploaded; are there other source changes needed in the packages that are FTBFS without this?
[17:59] <nacc> nope, they just rebuild fine w/ that debhelper fixlet
[18:00] <nacc> slangasek: --^
[18:00] <ginggs> doko:  oh well, if you have any ideas, please give me a shout :)
[18:00] <slangasek> nacc: ok, then please close the other tasks
[18:01] <doko> ginggs, well, you could try to lower optimization
[18:01] <nacc> slangasek: will do
[18:02] <nacc> slangasek: are they goign to be rebuilt then, or do you want me to keep them in my next rebuild list?
[18:02] <slangasek> nacc: put them in the rebuild list, please
[18:02] <nacc> slangasek: ok, thanks!
[18:03] <ginggs> doko: i'll try that, thanks
[18:04] <nacc> slangasek: fyi, figured out the lintian issue with php-opencloud, i think .. working on it now
[18:19] <Saviq> doko, slangasek, ok I found where cmake 3.2 and 3.5 differ: http://pastebin.ubuntu.com/15570003/
[18:19] <Saviq> 3.5 does not pass "-Wl,-soname,libUbuntuGesturesQml.so"
[18:20] <doko> Saviq, and which macro is this passed in?
[18:20] <slangasek> that's fair, it's not a very good soname ;P
[18:21] <doko> well, seems to be a plugin?
[18:21] <Saviq> doko, yeah, this is likely where this whole issue stems from - it is a plugin but is linked to by the test executable
[18:22] <Saviq> so I'm perfectly willing to accept we're Doing it Wrong™
[18:23] <doko> LoB identified some macros which were not used anymore. Is this one of them?
[18:24]  * Saviq emails LoB
[18:24] <doko> Saviq, better file a bug report and tell him the number
[18:24] <Saviq> right, or that
[18:26] <doko> ginggs, ohh, Scott Ritchie replied
[18:34] <Saviq> ughh
[18:41] <ginggs> doko: emailed you and ogra
[19:08] <doko> superm1, can https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1564234 be closed?
[19:08] <superm1> doko: yes
[19:08] <superm1> doko: once proposed migration finishes it should close
[19:10] <Saviq> so, bug #1564571 FWIW
[19:55] <lamont> stgraber: around?
[19:56] <lamont> stgraber: I want to confirm that (for xenial) I can still run the squid binary as 'squid3' (in that you are not dropping that symlink that I saw in the 3.5 package a few days ago)
[20:00] <rharper> lamont: AFAICT, /usr/sbin/squid3 is still present, we removed  /etc/init.d/squid3 , and instead the service file is going to be /etc/init.d/squid
[20:00] <lamont> rharper: that's what it looked like in the 3.5 package.  I was just confirming that you're not planning to drop /usr/sbin/squid3 as well
[20:01] <lamont> (currently, the binary is /usr/sbin/squid, with a symlink of squid3 -> squid
[20:01] <rharper> right;  I know of no plans to remove the sbin symlink; just the service name;
[20:01] <lamont> ta
[20:02] <rharper> since it's not yet complete (the FFE) and slangasek is going to review it;  it's possible that it could be dropped; I'm expecting an update from slangasek about the current status
[20:02] <rharper> lamont: if you're not already subscribed, tracking https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691 is a good idea
[20:03] <infinity> I don't see much reason to keep the symlink, personally.  We'd want to drop it eventually.
[20:04] <rharper> infinity: yeah; if we're not keeping the service name squid3, then the binary ought to be called as squid as well, (and it is invoked that way); however, we may need to see if the universe packages refer to it as squid/squid3 and might need an update there if we drop the symlink
[20:04] <infinity> Or, if the intent is to give people an LTS cycle to fix their scripts, replacing the symlink with a shell wrapper that does "echo squid3 has been renamed to squid\nexec squid" would help.
[20:04] <rharper> that sounds nicer than breaking callers of squid3
[20:13] <slangasek> nacc: I don't understand the latest updates to bug #1557599, haven't we fixed phing and php-apigen several times over?
[20:17] <lamont> rharper: and subscribed thanks
[20:30] <doko> superm1, http://autopkgtest.ubuntu.com/packages/a/apt/xenial/armhf/ triggered by gnupg2
[20:32] <superm1> doko: i'm not sure that's actually caused by gnupg2
[20:33] <superm1> doko: failure was "Test for successful execution of grep dlstatus:1:0:Retrieving file 1 of 1 apt-progress-https.log … FAIL: Failed to detect download progress"
[20:33] <robert_ancell> beuno, who handles canonical-indentity-provider? I'm trying to work out how you get the username from a login so we can check reviews come from the current user
[20:33] <robert_ancell> http://canonical-identity-provider.readthedocs.org/en/latest/resources/index.html doesn't seem to have a method to query username
[20:33] <superm1> doko: any way to re-run to check if was transient?
[20:35] <doko> superm1, given back
[20:53] <doko> ginggs, https://launchpadlibrarian.net/250530365/buildlog_ubuntu-xenial-arm64.deal.ii_8.1.0-6_BUILDING.txt.gz  Too many GOT entries for -fpic, please recompile with -fPIC
[20:58] <ginggs> doko: why would that be a problem in ubuntu all of a sudden?
[20:59] <doko> ginggs, ENOCLUE, but usually using -fpic instead of -fPIC isn't worth the trouble
[21:01] <ginggs> doko ok i'll try -fPIC and see what happens, can I just do that for all archs?
[21:01] <doko> ginggs, yes
[21:12] <pitti> cyphermox, slangasek, infinity: systemd uploaded with the fix for the udev killing spree on upgrade; queue review appreciated, I tested it locally on my desktop and with its autopkgtests
[21:13] <slangasek> pitti: looking
[21:14]  * pitti waves good night
[21:14] <ginggs> good night pitti
[21:15] <ginggs> doko, deal.ii building in my PPA with -fPIC, will upload in the morning if successful
[21:17] <doko> ginggs, ta
[21:22] <nacc> slangasek: so i actually tried to use them (in order to debug something else)
[21:22] <nacc> slangasek: they both call mb_ functions in their fiels
[21:22] <nacc> slangasek: which means they need php-mbstring to be installed to work
[21:23] <slangasek> nacc: ahh, runtime dep, ok
[21:25] <karstensrage> any ubuntu backporters in here?
[21:28] <teward> karstensrage: i guess my suggestion of waiting a while longer for a response given the proximity to Xenial release, of which I stated in -motu, is being ignored?
[21:29] <nacc> slangasek: what does it mean for a package.install file to only contain, e.g., '/usr/include/php/ext/'?
[21:29] <slangasek> nacc: "install this subdirectory of the build tree into the package at the same location"
[21:30] <nacc> slangasek: ok, thanks, wasn't seeing that in the manual
[21:32] <karstensrage> no teward not ignored, asynchronous suggestions from other channels
[21:32] <karstensrage> sorry, its just that i have so many things stalled, i can compensate for 2 or 3 but when 5 things are stalled its hard to keep going
[21:33] <ginggs> doko, i've been building julia on a rpi2 with -O instead of -O2, and it has just segfaulted at the same place (docs/helpdb.jl). I guess that is better than just getting stuck there for 150 minutes
[21:33] <teward> karstensrage: ah.
[21:33] <karstensrage> i know its not your priority teward i appreciate that, but its frustrating none the less
[21:33] <infinity> karstensrage: Patience.  The backporters team is entirely volunteer-staffed, and have no stated SLA. :P
[21:33] <teward> ^ that
[21:33] <teward> :)
[21:33] <doko> ginggs, -Og could be next ...
[21:36] <ginggs> trying...
[21:43] <tsimonq2> infinity: maybe there should be? :P
[21:43] <tsimonq2> just saying
[21:44] <nacc> slangasek: Pharaoh_Atem: I think I've found a bug in php-fshl, as well, trying to figure out why it wasn't seen earlier. Rebuilding the wily version also has this problem, but the version in the wily archive doesn't -- still debugging
[21:44] <teward> tsimonq2: keep in mind proximity to Xenial - this close to a release, backports I believe have to be deprioritized in favor of bug squishing and running the final stretch ;)
[21:44] <teward> it's one of the reaosn the nginx PPAs are delayed by a few days right now, even though nginx just recently released an update ;)
[21:45] <Pharaoh_Atem> nacc: that's... bizarre
[21:46] <nacc> Pharaoh_Atem: could be a side-effect of copying; it's something to do with phpab
[21:48] <Pharaoh_Atem> hmm
[21:52] <beuno> robert_ancell, hi
[21:52] <beuno> robert_ancell, there isn't anything as a username
[21:52] <beuno> the log in is your email
[21:57] <robert_ancell> beuno, discussing with dobey in #ubuntu-desktop - rnrserver is returning the launchpad ID for username (if you have one) and the OAuth consumer key otherwise. Click reviews only return consumer_key which makes them easy to match to the credentials returned from canonical-identity-provider
[21:57] <dobey> oh hi in here too
[22:00] <dobey> beuno: i also pinged in internal irc and have been chatting with noodles about this
[22:00] <nacc> Pharaoh_Atem: can you help me make sure i'm not crazy? php-fshl has an autoload file; in wily (and debian), that file contains, e.g. 'fshl\\generator' => /Generator.php'; but in xenial (and if i rebuild the wily version), i get 'fshl\\generator' => '/FSHL-2.1.0/FSHL/Generator.php', which fails to work at runtime (as that is not an accurate path)
[22:10] <Pharaoh_Atem> nacc: what would you like me to do?
[22:10] <nacc> Pharaoh_Atem: see if you can reproduce that with debian's package (that the installed version and the version you get if you run phpab manually in the source just debian/rules does) differ
[22:10] <nacc> Pharaoh_Atem: then help me figure out why :)
[22:11] <Pharaoh_Atem> heh
[22:15] <Pharaoh_Atem> let me update my box and I'll go ahead and test that
[22:15] <Pharaoh_Atem> nacc: you want me to grab from debian sid?
[22:16] <nacc> Pharaoh_Atem: yes please
[22:16] <ginggs> doko: -Og segfaults in the same way as -O
[22:16] <doko> fun
[22:16] <Pharaoh_Atem> :'(
[22:16] <Pharaoh_Atem> apparently failed to fetch packages :(
[22:17]  * Pharaoh_Atem re-runs
[22:22] <Pharaoh_Atem> wow
[22:22] <Pharaoh_Atem> one day, Ubuntu upgrades will not be slow... :(
[22:53] <nacc> Pharaoh_Atem: is it normal for debian packages of pecl extensions to not enable the extension on installation?
[22:53] <Pharaoh_Atem> I'm not sure
[22:53] <nacc> ok
[22:53] <nacc> it seems like some do and some don't
[22:53] <Pharaoh_Atem> that's what I was about to say
[22:58] <nacc> Pharaoh_Atem: i guess i'm struggling to figure out how else a runtime dependency (php-pecl-http in its php7.0 version) can be expressed upon another pecl extension, where the dependency check is that it's enabled
[22:59] <Pharaoh_Atem> wait, it's specifically checking for it to be enabled?
[22:59] <nacc> "configure:7033: error: Please install pecl/raphf and activate extension=raphf.so in your php.ini"
[23:00] <nacc> it's in mods-available, just not mods-enabled
[23:00] <nacc> afaict
[23:00] <Pharaoh_Atem> ugh
[23:00] <Pharaoh_Atem> is there even a capability to trigger it to be enabled automatically?
[23:01] <nacc> actually, i think i see what's wrong, i might be able to use dh-php to handle it
[23:43] <slangasek> nacc: fwiw libgd2-xpm-dev is a virtual package now, provided by libgd-dev; it ought to work for php-ps, except for the fact that php-ps's build-dep is versioned
[23:44] <nacc> oh i see
[23:44] <nacc> slangasek: let me try unversioning it and see if it succeeds, at least
[23:44] <slangasek> nacc: you're welcome to, but I've already removed the package ;)
[23:44] <nacc> slangasek: fair enough, it seemed pretty crufty and had no revdeps
[23:45] <slangasek> yes
[23:45] <nacc> slangasek: i apologize for not making much progress today, i've bene trying to figure out how to wrangle 3 packages we need to take from pecl that build actual extensions, i think i've got it now
[23:45] <nacc> and mostly rebuilds from my list today (will attach to the other bug shortly)
[23:46] <slangasek> nacc: that's perfectly fine
[23:47] <slangasek> nacc: php-mysqlnd-ms is marked on bug #1547183, with no comments; anything that needs saying on this one?
[23:47] <slangasek> it hasn't been removed from Debian yet, at least
[23:47] <nacc> slangasek: per Pharaoh_Atem and remi (fedora php maintainer) it's not maintained any longer; i can't get it to build with php7 afaict
[23:47] <slangasek> ok
[23:56] <nacc> slangasek: just uploaded my debian tarballs to LP: #1564566
[23:56] <nacc> all three built for me now
[23:57] <nacc> the only ugliness i ran into was dh-php complains if there is not a <package>.php file, so i had to create empty debian/<package>-dev.php files for the -dev packages