[00:22] slangasek: actually, we'll need some updates, nm [00:51] nacc: dns resolution failures of ftpmaster.internal are transient failures and should be retried. was that a package build or autopkgtest? [00:57] tsimonq2: I'm around, mostly. just took an hour to get food and get my mind off upgrades for a big [00:57] cyphermox: hey, I have an idea on bhow to solve 4 FTBFSes, a build-dep error [00:58] *how [00:58] 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] 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] cyphermox: mind confirming or denying my hunch? [01:01] denying right away [01:02] libhybris isn't built on arm64, that's a long time issue [01:02] iirc when I looked at the code it had issues that'd keep it from working correctly on 64 bit platforms [01:02] slangasek: it was a packge build [01:03] sarnold: seems to be build on amd64 in any case [01:03] tsimonq2: It's very easy to check this using "rmadison libhybris-dev" and noting the absence of arm64. [01:03] sarnold: not that it's very useful there ;) [01:03] cjwatson: oh thanks :) [01:03] tsimonq2: Also, dep-waits like that are automatically given back if the dependency becomes available. [01:03] tsimonq2: It's only necessary to do anything with them by hand if something has gone wrong with Launchpad. [01:04] cjwatson: makes sense, sorry, thanks :) [01:04] cyphermox: hah :) surprising.. [01:04] haha, not really [01:04] it's weird android magic, IIRC [01:04] yeah [01:05] while I have some people here, what's holding up bug 1547395 ? [01:05] bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New] https://launchpad.net/bugs/1547395 [01:05] I'd expect it to build on arm32 and only arm32.. [01:05] it builds on amd64, but won't do anything and might in fact blow up if you try to use it [01:05] yeah [01:05] so then why do we have it in Ubuntu? [01:05] JUST for those people? [01:05] tsimonq2: it is necessary on armhf for some ubuntu touch stuff [01:06] ohh I see :) [01:06] cyphermox: so then should we expect those guys to take a look? [01:06] Do we have any Network Manager code-huggers or is it all upstream? [01:07] tsimonq2: not until it becomes important to port Ubuntu Touch to arm64 [01:07] * cyphermox whistles innocently [01:07] tsimonq2: we don't *have* to clear all arch-specific dep-waits [01:07] Pharaoh_Atem: can you also sync with remi & ondrej on php-mysqlnd-ms (https://bugs.php.net/bug.php?id=70371) [01:07] sometimes things are just hard to port [01:07] cjwatson: I see :) [01:08] it's only any kind of blocker if it results in a package's architecture support regressing [01:08] 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] bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New] https://launchpad.net/bugs/1547395 [01:08] 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] cyphermox: that bug would unblock the only red in main, FYI, so yes, I took your recommendation ;) [01:09] (only all-arch) [01:10] (and the only one I even have a sight hope of fixing) [01:11] *slight [01:25] 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] 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] down to 125 packages in my list! :) [01:27] nacc: we can remove php5 from the archive, and then the false positives will disappear [01:27] at the cost of other packages becoming immediately uninstallable [01:28] slangasek: it's ok, i just am making notes to myself [01:28] slangasek: i think we're looking good to be very close by friday at this rate [01:29] slangasek: i might just try to write a wrapper for the tooling that handles the few cases i know about [01:30] right, you can also reverse-depends | grep -v php-pear :) [01:30] slangasek: that's true, but i've been using reverse-depends src:php5 [01:30] nad the problem is php-pear is in that list, i'm guessing :) [01:31] 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] nacc: yeah, I'll check into it [01:32] 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] nacc: ah yes - grep -v and then postprocess, to reproduce the -l style list :) [01:32] yep :) [01:32] I only learned about -l recently, and already forgot it again ;) [01:34] slangasek: fair enough :) [01:35] 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] 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] slangasek: thank! i'm done for the day again [01:37] ho boy i can no longer remember how to use bzr [01:38] mwhudson: heh, same happened to hallyn earlier today. he went to play in the sun instead... :) [01:38] funnily enough it's basicaly time to take my daughter swimming [01:38] have fun :) [01:39] mwhudson: schroot -c trusty -c 'apt-install bzr-git; ...' [01:39] except obviously not that ;) [01:39] yeah how about no [01:49] Pharaoh_Atem: thanks! === juliank is now known as Guest88020 === juliank_ is now known as juliank === marlinc_ is now known as marlinc === xnox_ is now known as xnox === dx- is now known as dx === dkessel_ is now known as dkessel === stokachu_ is now known as stokachu === stgraber_ is now known as stgraber === czchen_ is now known as czchen [04:17] 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] and he's got no idea about whether php-horde-mongo is even being maintained/updated [04:25] a little poking around indicates nothing particularly good: https://github.com/horde/horde/commits/master/framework/Mongo [04:54] superm1: dude, 1536871, beautiful work. [04:54] sarnold: thanks [04:54] superm1: you have no idea how nuts this was driving me. [04:55] 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] superm1: oh hell. [04:55] I bet you're right. [04:56] at least for 16.04 the answer is to update to gnupg2 2.1 (which I just uploaded to -proposed) [04:57] 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] superm1: well, good news, looks like only ruby-gpgmg and fwupd in the debian codesearch archives use that function. [05:14] 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] superm1: or the version of seahorse where you ran into it isn't indexed in DCS :/ [05:15] it's a great tool but only approximate to what we ship.. :( [05:15] yeah [05:16] I'm missing the source browser. :/ [05:20] superm1: If you update gnupg2 to 2.1, you'll need to sync pygpgme from Debian too. [05:21] ScottK: OK thanks for the heads up [05:22] yw [06:10] good morning [06:46] Good morning [06:47] Saviq: I'll mark them as bad tests for this version for now [06:49] good morning === tvoss|dinner is now known as tvoss [08:40] 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] Saviq: what is "ssh into britney"? [08:41] oh, ssh into a failing test? yes, that works [08:41] testbed, I mean [08:41] pitti, yeah, that [08:41] Saviq: I thought you asked me two weeks ago, but then wanted to try something else first [08:42] pitti, yeah we found the issue then [08:42] 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] Saviq: I started the test manually with -s [08:45] pitti, ack, thanks [10:29] 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] err, germanium, but same thing [10:31] pitti: LP uses a backport of trusty's apt (slightly patched to add source caching) [10:31] it's in precise-cat-lp or some such [10:32] and we do use apt-ftparchive, yes === hikiko is now known as hikiko|ln [11:13] superm1, sarnold: yeah, we were waiting for debian bug 796931 to be resolved before switching to gnupg 2.1 [11:13] Debian bug 796931 in gnupg-agent "gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file" [Normal,Open] http://bugs.debian.org/796931 [11:18] mdeslaur, ugh, it looked to me that seth was fine with approving qnupg 2.1 ... so should we remove it from -proposed? [11:21] cjwatson: http://ddebs.ubuntu.com/dists/xenial/main/binary-amd64/ [11:22] mdeslaur, superm1: ^^^it's dep-wait for now anyway [11:22] 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] pitti: ah, excellent; will it also now cope with bz2 being absent from the Ubuntu archive? [11:23] superm1, sarnold, doko: I'm not sure what the right answer is [11:23] mdeslaur, I was looking at https://bugs.launchpad.net/ubuntu/+source/npth/+bug/1536871 [11:23] Launchpad bug 1536871 in fwupd (Ubuntu) "[MIR] fwupd" [Undecided,In progress] [11:24] 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] pitti: the best approach is to try .xz .bz2 .gz uncompressed in succession [11:25] pitti: Debian is flirting with getting rid of .gz and we might eventually do the same [11:25] ok; that's an extra urlopen/error check, but I'll do that after lunch then [11:25] 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] for now at least [11:26] not too hard, just a bit more work than a single-letter change === hikiko|ln is now known as hikiko [12:01] xnox: got a minute ? [12:02] caribou, sure [12:02] well, I can ask in the room, maybe somebody else will have an opinion : [12:03] in the room is best =) [12:03] 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] they reverted listen_ivp6 from YES to NO to match the manpage default and now the systemd job will not start [12:04] (between wily & xenial) [12:05] my guess is that he/we should at least add a prompt to ask to enable it otherwise disable the systemd job [12:06] i believe we too, do not start vsftpd by default. [12:06] as one must configure it to start [12:07] e.g. #ubuntu-hardened default is no open ports by default. And hence e.g. we never install openssh-server by default. [12:07] xnox: let me recheck but it was set to YES in wily [12:07] i'd rather look at e.g. trusty [12:07] there is loads of flux in init/startup between there and now. [12:07] xnox: well we didn't do anything, it was set to YES in the uptream package [12:09] xnox: it starts by default on W [12:09] lemme check trusty [12:09] caribou, right and on trusty [12:09] it does start and does listen [12:09] tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 23463/vsftpd [12:10] caribou, imho it should listen on ::* by default [12:10] sorry [::]:21 that is [12:10] (any ipv4/6 on port 21) [12:11] 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] xnox: I think it is how it was done on Debian as well, until Bug: #803999 [12:11] bug 803999 in evolution (Ubuntu) "evolution crashed with SIGSEGV in gdk_cairo_set_source_pixbuf()" [Medium,Expired] https://launchpad.net/bugs/803999 [12:11] nah debian bug [12:12] 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] imho it's the manpage that is broken. [12:13] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819546 [12:13] Debian bug 819546 in vsftpd "vsftpd no longer starts with systemd because of listen_ipv6=NO from Bug: #803999" [Normal,Open] [12:13] but default should listen on _both_ ipv4 and ipv6 from a single daemon [12:13] listen_ipv6 will do both [12:13] that's a debian ipv6 goal [12:14] but that's (a) regression (b) deviation from debian policy [12:14] e.g. installing apache2 on debian does bring it up and start serving pages [12:14] ditto ftp. [12:15] caribou, patch it in ubuntu, and then comment more on the bug report. [12:16] xnox: fine by me. [12:16] xnox: on another topic, I've been testing zfcpdump [12:17] xnox: as inaddy said, we do need a small footprint kernel in order to get it to work [12:19] caribou, talk to kernel people about it =) [12:19] kernel team maintains all kernels on s390x. [12:19] xnox: yes, been doing so, just wanted to keep you posted [12:19] (well the one kernel) [12:19] cool. === fabo_ is now known as fabo [12:35] cjwatson: ok, done; it now does the xz → gz → uncompressed fallback [12:50] 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] pitti: in lp-shell production devel [12:52] cjwatson: done [12:56] pitti: thanks, let's see how that works out [12:57] ginggs, do you know about the background for the different wine packaging in Debian/Ubuntu ? [12:58] doko: yeah, i did some digging a few weeks ago [12:58] so I know a little [12:59] ? [13:00] what is it you want to know? I put some of the info I found here LP: #1558480 [13:00] Launchpad bug 1558480 in wine1.6 (Ubuntu) "remove wine1.6 package" [Undecided,Confirmed] https://launchpad.net/bugs/1558480 === _salem is now known as salem_ [13:01] Scott Ritchie (YokoZar) did a large amount of work on wine in ubuntu but that didn't make it back to debian. [13:01] he always did it directly upstream instead [13:01] ginggs, I'm more curious why 1.8 was not uploaded [13:01] skipping debian in the chain [13:02] the packages in the ppa were last touched in December [13:03] ginggs, highvoltage, ogra_: the easy way would be to upload the debian package, bumping the epoch for the wine binary package [13:03] afaik upstream was always unhappy about some splits debian did ... YokoZar is originally more of an upstream guy than a debian dev [13:03] yeah, but if nothing is happening ... [13:04] the prob will likely be upgrades here [13:04] doko: lack of time? interest? i don't know... I tried contacting both members of wine team [13:05] 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] 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] right [13:05] ginggs, not afaics [13:05] ginggs: aah [13:06] 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] doko: i think removing wine1.6 is the first step === _bjf is now known as bjf [13:07] ginggs, reverse-depends tells you otherwise [13:07] Reverse-Recommends [13:07] ================== [13:07] * q4wine [amd64 arm64 armhf i386 powerpc] (for wine) [13:07] * q4wine [amd64 i386] (for wine1.6) [13:07] * winetricks (for wine) [13:07] Reverse-Depends [13:07] =============== [13:07] * dssi-vst [i386] (for wine1.6-i386) [13:07] * playonlinux (for wine) [13:07] * pq (for wine) [13:07] Reverse-Build-Depends [13:07] ===================== [13:07] 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] * dssi-vst (for wine1.4-dev) [13:08] ginggs, did you try to use the wine1.8 packages in the ppa? [13:10] doko: no, i have been using the debian packages for some time now [13:11] anyone know how to prevent the Network Manager build from failing due to testsuites not workable, on a local 'fakeroot' build ? [13:12] doko: since november last year, there is another "wine team" PPA https://launchpad.net/~wine/+archive/ubuntu/wine-builds [13:12] specifically: "ERROR: test-nm-client - too few tests run (expected 9, got 0)" [13:12] TJ-: typically you want to run that in autopkgtests [13:12] or in a vm, or in a chroot [13:13] the tests are dependent on the interfaces on your system, so that may explain why they fail [13:13] ginggs, ogra_: sent email [13:13] 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] ginggs, only devel builds [13:14] TJ-: override_dh_auto_test to not contain anything [13:15] cyphermox: so "override_dh_auto_test: > dbus-test-runner -m 300 -t dh_auto_test" becomes just "override_dh_auto_test:" ? [13:16] TJ-: precisely [13:16] cyphermox: thank you :) [13:16] cyphermox: for reference I'm working up a patch for bug 1533631 [13:16] bug 1533631 in network-manager (Ubuntu) "Failed to renew DHCPv6 lease after suspend" [High,Triaged] https://launchpad.net/bugs/1533631 [13:18] ah, that needs renaming to be accurate, it's now "dhclient killed when DHCPv6 lease is out-of date" [13:19] doko: i think it was mlankhorst who did the last wine ppa upload [13:19] TJ-: have you tried git master? it likely already has a patch [13:20] cyphermox: I'm working from master; there's no handling of deprefer upstream at all [13:20] ok [13:20] cyphermox: I gen the patch on master, then import into the Ubuntu package for testing [13:46] morning, did openjdk-7-jdk get removed from ubuntu xenial? [13:47] it was installable up until last night [13:49] pabelanger: yes, see bug 1563986 [13:49] bug 1563986 in radare2-bindings (Ubuntu) "openjdk-7 removal for 16.04 LTS" [Undecided,Fix released] https://launchpad.net/bugs/1563986 [13:49] pitti: thanks for confirming [13:52] 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] pitti: I will tomorrow, if arges doesn't beat me to it before that [13:54] working on something now, may have time later today [13:54] thanks [14:35] pitti, hey, we managed to find a way to repro locally, you can release, thanks! [14:46] 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:46] Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Critical,Fix committed] [14:56] Saviq: cool, thanks [14:57] arges: thanks [15:04] Pharaoh_Atem: i filed https://bugs.horde.org/ticket/14309 for php-horde-mongo [15:04] Pharaoh_Atem: so do you think we're safe to remove them? i'll check revdeps [15:05] Pharaoh_Atem: ok, no revdeps, will schedule for removals [15:09] apw, infinity: are these expected failures? autopkgtest for linux 4.4.0-16.32 [15:11] 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] infinity xnox https://bugs.launchpad.net/ubuntu/+source/quassel/+bug/1506550 [15:12] Launchpad bug 1506550 in quassel (Ubuntu) "quassel can't play audio notifications in wily" [Low,In progress] [15:25] woo, down to 131 packages blocking removal of src:php5, src:php-json, src:dh-php5! [15:44] pitti: hi - are you talking about a kernel failure? [15:45] nacc: I think we’re good on removals for them [15:45] I’ve not encountered anything that uses either of them [15:45] tyhicks: yes, on http://autopkgtest.ubuntu.com/packages/l/linux/xenial/amd64/ [15:45] I think I know the issue [15:45] give me a sec to confirm [15:45] nacc: bbs as Pharaoh_Atem [15:45] Son_Goku: thanks [15:47] 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] 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] 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] https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1561762 [15:48] Launchpad bug 1561762 in apparmor (Ubuntu) "[FFe] AppArmor 2.11 Beta 1 for policy namespace stacking and bug fixes" [Critical,New] [15:49] tyhicks: ah, that should fix the test again? thanks for the heads-up [15:49] pitti: yes, I'm 100% sure that'll fix the test [15:50] rharper: fwiw on squid, stgraber's dpkg-maintscript-helper changes were incomplete and wrong. I'll follow up today [15:59] superm1, online? [15:59] doko: Yep [15:59] 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] I found this bug filed: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1373598 but it appears not to be assigned yet [16:00] Launchpad bug 1373598 in apt (Ubuntu) "apt-get update fails, hash sum mismatches with de.archive.ubuntu.com" [High,Confirmed] [16:00] I was mostly curious what the process is for bugs that are marked high,confirmed to be assigned if there is one [16:00] superm1, any idea what would go wrong when updating to the new gnupg2 version? [16:01] doko: the only that came to mind was what mdeslaur raised regarding the difference in behavior with the agent [16:01] there was quite a bit of discussion on the debian bug about it [16:03] superm1, do you know about packages which would depend on this? [16:04] 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:04] Debian bug 744758 in apt "apt: hash sum mismatch" [Normal,Fixed] [16:05] doko: depend on the new command line arguments that came in version 2.1? [16:07] or you mean the difference in behavior with the agent? [16:07] superm1, the debian bug talks about the changed filename, not command line options [16:08] 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] 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] bug 1373598 in apt (Ubuntu) "apt-get update fails, hash sum mismatches with de.archive.ubuntu.com" [High,Confirmed] https://launchpad.net/bugs/1373598 [16:10] 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] (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] so it might affect what gets passed through on say an SSH login [16:13] so maybe people need adjust, but no packages need adjustments [16:14] right [16:14] if anything at some point it might be worthwhile to SRU the outcome of that debian bug [16:15] slangasek: just filed LP: #1564492, which is a FTBFS due to a debhelper issue (patch for debhelper attached) [16:15] Launchpad bug 1564492 in php-mf2 (Ubuntu) "FTBFS: php-mf2 due to unicode in substvars file" [Undecided,New] https://launchpad.net/bugs/1564492 [16:18] nacc: er, is non-ascii allowed in description fields under Debian policy? [16:19] slangasek: the fix is from Debian, so I assumed so, let me see if i can find it i the policy [16:21] slangasek: hrm, good point... [16:21] 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] Launchpad bug 1536871 in npth (Ubuntu) "[MIR] fwupd" [Undecided,Incomplete] [16:21] "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] slangasek: so names can't have non-ASCII, but it's unclear if the value can [16:22] 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] I'm fairly sure Description can be UTF-8 and non-ASCII [16:23] 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] It seems like one of the most obvious fields that would want to be non-ASCII [16:23] ok [16:23] 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] The policy language seems a bit woolly on it though [16:24] "All control files must be encoded in UTF-8" and it only explicitly mentions "field name" as being in ASCII [16:24] afaict [16:25] 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] There are examples that already do, e.g. cvs, deja-dup [16:25] cvs is a bit gratuitous but deja-dup is IMO reasonable [16:26] or firefox-locale-nb which is definitely reasonable [16:26] 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] superm1, both promoted [16:26] doko: okay thanks [16:26] superm1: uh my test failure just said something like Aborted, as if there was a segfault... let me run it again [16:27] does launchpad drop permissions for the build? i can only seem to reproduce it on launchpad, not in pbuilder locally [16:28] 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] 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] superm1: Launchpad uses sbuild which runs the build as a non-root user [16:29] ah OK. I'll dig further into this then [16:34] could someone take care of https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1557955 [16:34] Launchpad bug 1557955 in pcre2 (Ubuntu) "Please sync pcre2 10.21 from Debian" [Undecided,New] [16:35] ricotz: wouldn't it need a FFe? [16:35] it would at this point [16:35] past FeatureFreeze [16:36] ricotz: https://wiki.ubuntu.com/FreezeExceptionProcess [16:36] nacc, it does, I was about to file a bug, and found about that one [16:39] filed a proper one https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1564510 [16:39] Launchpad bug 1564510 in pcre2 (Ubuntu) "FFe: Sync pcre2 10.21-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] [16:40] 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] (I am fixing the script(s) to handle failing over to different compression types) [16:45] Odd_Bloke: your scripting is indeed just buggy, since that file isn't advertised in .../xenial-security/Release [16:45] Odd_Bloke: Packages.xz will appear next time xenial-security is actually published :) [16:46] cjwatson: OK, cool. [16:47] cjwatson: may i ask what the proposed server-side solution is for 16.04? Is it documented somewhere? [16:47] cjwatson: its not a proxy bug -- no proxy is being used and the repo is being transmit over HTTPS [16:48] 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] 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] ice799: You very much need to not conflate a ton of different possible causes for hash sum mismatches. [16:52] ah finally [16:52] indexes with hash sums in the URL [16:52] ice799: -o Debug::Acquire::https=true -o Debug::Hashes=true is probably a good place to start/ [16:52] s,/,., [16:58] doko: fwupd tests weren't sorted out yet man [16:58] mterry, ohh, sorry [16:58] superm1, ^^^ [16:58] doko: it's ok, superm1 is working on them [16:59] superm1: please continue to work on them, even though fwupd is in main now :) [16:59] yeah i'll get something in next upload [16:59] 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] cjwatson: Debug::Hashes doesn't seem to tell me anything but I do see some HTTP 416s come back [17:08] looks a bit like this one: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/798023 [17:08] Launchpad bug 798023 in apt (Ubuntu) "apt-get update fails with error 416 Requested Range Not Satisfiable" [High,Confirmed] [17:15] ice799: I think I'd get further seeing the raw apt-get update output with those debug options than guessing at bugs [17:16] (though am about to go for dinner) [17:16] cjwatson: ah i see [17:16] i had a typo [17:16] yea so [17:17] i see a "201 URI Done" with a list of hashes that all match [17:17] followed by a "[6 Packages store 0 B]" [17:17] with hashes that mismatch [17:17] 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] a paste of the relevant Release file would probably be useful too [17:18] the release file is right [17:19] that doesn't mean it isn't useful for debugging [17:19] agreed [17:19] the actual APT error appears to be: W: Failed to fetch store:/var/lib/apt/lists/partial [17:19] with a long path [17:19] i need to read the apt source to see what failed to fetch store really means [17:19] 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] also there are some subtleties that are not obvious, like handling of uncompressed files [17:20] that's why I'm asking for the Release file [17:20] im gathering all of this information now [17:21] 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] Saviq, what's the error? [17:24] doko, "QObject::connect: signal not found in DirectionalDragArea" [17:24] when running the test [17:24] Saviq, how do you know that's a link error? [17:25] doko, I don't, I just know the error goes away and test passes when I downgrade cmake... [17:26] doko, or, it's a red herring... [17:26] dinner bell, EOD [17:27] Saviq, a little more investigation would be nice, or maybe ask LocutosOfBorg (currently not online) [17:28] 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]