[00:37] <nacc> slangasek: pitti: i think i've gotten most everyting resolved in excuses except for symfony & doctrine. I will spend some time tomorrow looking at those, as i think we'll need some more bootstrapping possibly
[00:44] <Trevinho> robru: the problem is not the debian changelog. That is fine. Ad I wrote in the email, the bugged one is the bzr commit message. Which should be multi-line
[00:45] <Trevinho> Ad = as
=== adam_g` is now known as adam_g
[00:46] <robru> Trevinho: if you write your own changelog, it uses that also for the bzr commit
[00:47] <robru> Trevinho: anyway I can review this tomorrow
[00:48] <Trevinho> robru: Mh ok, but that is not fine. The commit message should be used for bzr commit. Whole the debian changelog should only apply to distro changes
[00:48] <Trevinho> While*
[00:50] <Trevinho> Robru: Ok thanks. Please have a look to this. Since we're loosing useful informations when it's up to blame or review changes
[00:50] <robru> Trevinho: ok, will do
[00:51] <Trevinho> Thanks
=== _salem is now known as salem_
[04:02] <Logan> nacc: regarding bug 1592972, shouldn't that substitution variable add php-pear? that's kinda weird
[04:02] <ubottu> bug 1592972 in php-text-captcha (Ubuntu) "php-text-captcha depends on php-pear" [Low,New] https://launchpad.net/bugs/1592972
[04:08] <slangasek> nacc: php-zend-search removed
=== salem_ is now known as _salem
=== rharper` is now known as rharper
=== lpotter__ is now known as lpotter
[05:58] <pitti> Good morning
[06:01] <sil2100> Morning
[06:02] <pitti> nacc: php-imagick kickified
=== _salem is now known as salem_
[06:10] <didrocks> good morning pitti, sil2100
[06:11] <pitti> bonjour didrocks !
[06:11] <sil2100> Morning didrocks! :)
=== geser_ is now known as geser
=== sarnold_ is now known as sarnold
=== andrewsh_ is now known as andrewsh
=== nhaines_ is now known as nhaines
[07:10] <infinity> Trevinho: That fixed it, thanks.
[07:16] <xnox> infinity, sorry that i forgot to push xenial-proposed bzr branch of d-i for last sru =(
[07:16] <xnox> infinity, thanks for committing all that.
[07:17] <xnox> no i did, derp, got my :parent and :push mixed up
[07:18] <xnox> $ bzr pull --overwrite --remember :push
[07:36] <pitti> cking: trusty kernel on xenial gives me http://paste.ubuntu.com/17392362/, and lxd hangs; does that smell like some incompatibility with the trusty kernel, possibly seccomp related?
[07:39] <cking> pitti, syscall 384 on aarch64 is getrandom() and that does not exist on trusty :-(
[07:39] <pitti> cking: ah, meh
[07:39] <pitti> cking: so I guess that won't get me very far; I guess vivid next?
[07:43] <cking> pitti, I believe 3.19 is the first ubuntu kernel that supported that syscall
[07:44] <pitti> cking: cool, that shold be vivid then; I'm currently installing that
[08:01] <mwhudson> slangasek, pitti, etc: call now?
[08:01] <pitti> mwhudson: one minute
[08:02] <slangasek> mwhudson: working on it, yes :)
=== athairus is now known as afkthairus
[08:03] <mwhudson> :)
[08:05] <slangasek> mwhudson: live!
[08:05] <pitti> mwhudson: we are talking
[08:20] <pitti> cking: hm, still happening with 3.19; OTOH, I don't think the fallout is actually too bad, perhaps userspace has an appropriate fallback
[08:20] <pitti> cking: anyway, I'll keep vivid running and see whether it happens there; that limits the bisect space
[08:21] <cking> pitti, yep, thanks, let's see what falls out
=== thegodfather is now known as fabbione
=== buxy_bak is now known as buxy
=== fidencio_ is now known as fidencio
[09:09] <mwhudson> pitti: hey i'm going to upload a new docker.io soon with actual sane autopkgtests
[09:09] <mwhudson> pitti: can you remove the blocks that are stopping them running?
[09:10] <pitti> mwhudson: oh, sure
[09:12] <pitti> mwhudson: committed and rolled out
[09:12] <pitti> mwhudson: thanks for that!
[09:12] <mwhudson> pitti: thanks, uploading (turns out i had it all prepared already)
[09:12] <pitti> mwhudson: (and the next worker mass-killing will be on you :-P)
[09:13] <pitti> more seriously, I'll let you know if it still wreaks havoc
[09:13] <mwhudson> heh
[09:14] <mwhudson> this one really shouldn't
[09:15] <mwhudson> next fun task: get this junk in the xenial sru queue
[09:15] <pitti> you apparently have high opinions about your work :)
[09:16] <mwhudson> heh
[09:29] <mwhudson> now i want the publisher and britney and so on to get 100 times quicker magically
[09:30] <FourDollars> Is there any problem that http://ddebs.ubuntu.com is not synced to the latest version? http://paste.ubuntu.com/17393232/
[09:32] <sarnold> pitti: ^^^ are you still the go-to contact for ddebs?
[09:34] <pitti> sarnold: I'm afraid so; I did get a couple of cron mails from it recently, I just didn't have time to investigate yet
[09:34] <sarnold> pitti: hehe
[09:34] <sarnold> pitti: thanks
[09:38] <cyphermox> caribou: maybe http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commitdiff;h=1ba2e171eb75f1abc72e939d9cbd9681c56954d0;hp=e9ad6f77a9036e60acc047cc2150a4dce1545578 ?
=== hikiko is now known as hikiko|ln
=== salem_ is now known as _salem
[10:31] <cyphermox> infinity: http://paste.ubuntu.com/17393792/
[10:57] <mwhudson> pitti: argl, some of the docker.io autopkgtests have been triggered by the runc/containerd uploads and are running the old, bad, tests
[10:57] <mwhudson> pitti: if they die and start again, will they pick up the new version of docker.io?
=== hikiko|ln is now known as hikiko
=== _salem is now known as salem_
[11:13] <Laney> juliank: I just got "W: Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/_srv_mirrors_ubuntu_dists_yakkety_InRelease" - and the release file wasn't used - for the Ubuntu archive which has "Date: Thu, 16 Jun 2016  9:35:47 UTC
[11:13] <Laney> "
[11:13] <Laney> do you know who has the bug here?
[11:14] <Laney> looks like it's https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=9febc2b so maybe I should ask DonKult
[11:14] <juliank> Laney: Looks fancy, I saw something similar yesterday on travis
=== dpm_ is now known as dpm
[11:15] <cjwatson> Not something to do with space-padding of the hour field?
[11:15] <cjwatson> That would maybe account for it not being all the time
[11:16] <cjwatson> Do ask DonKult though ...
[11:16] <juliank> Oh yeah, it expects 09
[11:16] <juliank> not <space>9
[11:16] <juliank> AFAICT
[11:16] <Laney> Could be the same with the day of month then
[11:17] <cjwatson> No, we use %d for that
[11:17] <Laney> The repository affected is non-LP
[11:17] <cjwatson> Ah
[11:17] <cjwatson> Not too sure why LP uses %k for the hour, which we could change, but we have quite a few Release files in the wild using %k for the hour so apt needs to handle that IMO
[11:17] <juliank> Let me check
[11:19] <juliank> On travis it even rejects Sun Nov  6 08:49:37 1994
[11:19] <juliank> no idea why though
[11:19] <juliank> (it works here, maybe trusty parsed differently)
[11:20] <juliank> Hmm, not sure how to parse that
[11:21] <Laney> https://github.com/smira/aptly/blob/master/deb/publish.go#L670
[11:21] <juliank> I tried "%a, %d %b %Y %k:%M:%S"
[11:22] <juliank> std::get_time() seems to be weird
[11:24] <juliank> I now tried %H with two spaces in front as the doc says "leading zeros not required", but that does not seem to work
[11:25] <juliank> Well, I guess I'll figure that out in the next hour
[11:28] <juliank> gtg now, back in ~ 20-30 min
[11:29] <Laney> I hope it's just a matter of permitting some more patterns
[11:29] <Laney> thanks for looking
=== salem_ is now known as _salem
[11:59] <juliank> cjwatson: Laney: It looks like a libstdc++6 bug, I cannot get it to parse an hour with space instead of 0 padding
[12:00] <juliank> According torkel http://en.cppreference.com/w/cpp/io/manip/get_time, %H does not require leading zeroes, so " %H" should parse " 9". But it doesnt
[12:01] <juliank> "torkel" should have been "to", sorry
[12:03] <jaksi07c8> hi
[12:04] <jaksi07c8> I'm looking for a way to create a customized Ubuntu ISO
[12:04] <jaksi07c8> there is a help page, but it doesn't mention USB bootable ISOs or UEFI
[12:04] <jaksi07c8> is the way official ubuntu ISOs are generated public?
[12:04] <juliank> cjwatson: Laney: Yep, confirmed: Reproducer: https://paste.debian.net/739661/
[12:28] <juliank> doko: ^ perhaps something for you to look at? - summary: std::get_time() in libstdc++6 requires leading 0s for %H and friends, but must also accept ones without leading 0s; causing APT to fail for some repos that use " 9" (%k) instead of "09" (%H) for hour formatting
[12:29] <juliank> this whole C++ thing is so buggy :/
[12:29] <juliank> We previously used strptime() which worked fine, but requires calling setlocale() around it
[12:30] <juliank> which is ugly and not thread safe
[12:39] <pitti> mwhudson: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#docker.io \o/
[12:42] <juliank> cjwatson, Laney, doko - Reported the libstdc++6 date parsing bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556
[12:42] <ubottu> gcc.gnu.org bug 71556 in libstdc++ "set::get_time() requires leading 0s for %H and friends" [Normal,Unconfirmed]
=== lamont` is now known as lamont
[12:45] <cjwatson> juliank: I think you should probably report this as a Launchpad bug as well.  We can't do much about old Release files, but if %H will work everywhere (which seems likely) then there's really no reason for us not to use that instead of %k and make life a little easier.
[12:45] <cjwatson> juliank: (obviously that doesn't help other archives)
[12:45] <juliank> cjwatson: I hope we get this fixed soon-ish, and it only affects 1.3*
[12:45] <cjwatson> All right, well, whatever you think best
[12:46] <juliank> But yes, you could just change %k to %H
[12:46] <juliank> :D
[12:46] <cjwatson> We should probably prefer what apt-ftparchive uses, which is %H
[12:48] <pitti> xnox: bug 1422249
[12:48] <ubottu> bug 1422249 in python-launchpadlib (Ubuntu) "TypeError crash if credentials are expired and needs to re-login [py3]" [Undecided,New] https://launchpad.net/bugs/1422249
[12:48] <pitti> xnox: bug 1425575
[12:48] <ubottu> bug 1425575 in python-launchpadlib (Ubuntu) "[py3] corrupts binary bug attachments" [Undecided,New] https://launchpad.net/bugs/1425575
[12:48] <pitti> xnox: bug 1425627
[12:48] <ubottu> bug 1425627 in lazr.restfulclient (Ubuntu) "[py3] bug.subscribe() crashes with simplejson.scanner.JSONDecodeError" [Undecided,New] https://launchpad.net/bugs/1425627
[12:49] <xnox> and bug 1471927
[12:49] <ubottu> bug 1471927 in launchpadlib "AccessToken.from_string() crashes on python3" [Undecided,New] https://launchpad.net/bugs/1471927
[12:49] <xnox> barry, ^
[12:49] <xnox> shall we? =)
[12:49] <xnox> there is double decode bug.....
=== dannf` is now known as dannf
[14:27] <tkamppeter> slangasek, hi
[14:28] <tkamppeter> slangasek, thanks for fixing bug 1592841.
[14:28] <ubottu> bug 1592841 in krb5 (Ubuntu) "FTBFS on ppc64el, blocks updates of all packages depending on krb5, for example CUPS" [Critical,Confirmed] https://launchpad.net/bugs/1592841
[14:29] <tkamppeter> slangasek, but now krb5 does not seem to make it from -proposed into release again, without reason visible on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#krb5
[14:29] <tkamppeter> slangasek, perhaps it needs some manual kick?
[14:30] <sarnold> doesn't it take seven days to migrate?
[14:31] <tkamppeter> sarnold, no, if I upload something into the development branch (no yakkety) it goes into -proposed first and after around an hour it advances to release.
[14:32] <sarnold> tkamppeter: ah :)
[14:32] <tkamppeter> sarnold, the seven days are for SRUs. They go into -proposed and the original poster of the bug is called for testing and if there is positive confirmation but no regression report in the seven days, the SRU is advanced to -updates.
[14:36] <ginggs> tkamppeter: does krb5-sync perhaps need to be rebuilt?
[14:37] <Laney> transition
[14:37] <Laney> libkadm5srv-mit10
=== olli__ is now known as olli
[14:41] <slangasek> tkamppeter: it hasn't migrated because what Laney and ginggs say. I'm triggering a rebuild now of the revdeps
[14:43] <Laney> slangasek: I've got a couple of them already
[14:44] <nacc> Logan: there are other php-* packages that also add the explicit depends (I based my patch off the same) -- also debian just took the same patch, so we can sync now :)
[14:44] <nacc> slangasek: thanks!
[14:44] <nacc> pitti: great, thanks!
[14:48] <nacc> rbasak: if you wouldn't mind taking a look at and sponsoring bug 1592890
[14:48] <ubottu> bug 1592890 in php-pimple (Ubuntu) "Fix autopkgtest failure for php-pimple" [Undecided,New] https://launchpad.net/bugs/1592890
[14:48] <nacc> rbasak: that will clear out two more php excuses (i've already sent the same patch to debian as well)
[14:54] <nacc> pitti: i believe both armhf failures from the update php-defaults run are testbed issues
[14:55] <nacc> pitti: php-defaults -> php-horde-imp; php-defaults -> php-horde-ldap
[14:56] <nacc> pitti: the cacti one may also fail again (it was failing before), but slangasek determined (and I agreed) it's not due to the deps, but something with cacti + armhf itself
[15:08] <dosaboy> bdmurray: hi, sru 1521396 is *-done so ready when you are :)
[15:13] <bdmurray> dosaboy: it helps more knowing the package and release rather than a bug number.
[15:14] <dosaboy> bdmurray: 10-4 lemme get that for you
[15:14] <dosaboy> bdmurray: python-os-brick and Ubuntu Wily
[15:15] <dosaboy> bdmurray: hopefully this is the last os-brick sru for a bit ;)
[15:15] <bdmurray> dosaboy: it's been in -proposed for < 7 days.  Is there a rush to get it in -updates?
[15:20] <dosaboy> bdmurray: how long would you typically let it bake?
[15:21] <dosaboy> typically/ideally
[15:22] <bdmurray> dosaboy: "The SRU team will evaluate the testing feedback and they will move the package into -updates after it has passed a minimum aging period of 7 days."
[15:22] <dosaboy> bdmurray: ok no problem that makes sense
[15:24] <bdmurray> dosaboy: looking at the patch again it's basically just one line right?
[15:25] <dosaboy> bdmurray: yep
[15:25] <bdmurray> dosaboy: okay, then if its important I'm fine with releasing it early
[15:26] <dosaboy> bdmurray: sounds good, fwiw this change is in all subsequent versions of Openstack already and was essentiually a type in that release so should be pretty safe
[15:26] <dosaboy> s/type/typo
[15:27] <nacc> slangasek: phpseclib -> php-horde-mapi test failure. I am having a heck of a time figuring out what's going on. If I have my adt-run drop to a shell and run the same command as the d/t/control file, it passes. The reason it's failing (I think) is the deprecation warning (maybe the test runner assumes any stderr output is a failure?). phpunit does raise all warnings to exceptions, but even manually
[15:27] <bdmurray> dosaboy: right, then I'll release it now.
[15:27] <nacc> hacking it to not do that for deprecations doesn't seem to help. Note that this is also an issue in Debian.
[15:27] <dosaboy> bdmurray: thanks
[15:45] <nacc> rbasak: also, if you could add sponsoring from bug 1570472 to your list, that'd be great
[15:45] <ubottu> bug 1570472 in puppet (Ubuntu) "Set systemd as default service provider" [Undecided,In progress] https://launchpad.net/bugs/1570472
[16:01] <nacc> rbasak: have a q for you after the meeting, if you have about 5 minutes
[16:01] <rbasak> Sure
[16:04] <nacc> rbasak: re: cobbler; it's not a merge as the Ubuntu version is out-of-band with Debian (packaged in Ubuntu before Debian afaict). Is it appropriate to requestsync with a simple -- 'want to get to the Debian version'? What is the best strategy for explaining years of Ubuntu delta accumulation? Do I need to go through each released version and ensure it does/doesn't apply to the Debian version?
[16:09] <rbasak> nacc: good question. I think it's fine to summarise. There's no hope of maintaining backwards compatibility, this branch is EOL, so we're deliberately breaking to the Debian branch.
[16:10] <nacc> rbasak: ack, just wanted to confirm, as `requestsync` gave me a whole bunch of delta to explain :)
[16:10] <rbasak> And that we don't really expect people to upgrade cobbler from release to release anyway without taking a great deal of care and reading the release notes.
[16:10] <rbasak> It might be worth release noting this.
[16:10] <nacc> rbasak: yep
[16:11] <nacc> rbasak: thanks!
=== dpm is now known as dpm-afk
=== alvesadrian is now known as adrian
[16:32] <bdmurray> LocutusOfBorg: there are no Launchpad-Bugs-Fixed in the .changes file for your upload of biber to xenial-proposed.
[16:36] <LocutusOfBorg> sorry bdmurray
[16:36] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/biber/+bug/1589644
[16:36] <ubottu> Launchpad bug 1589644 in biber (Ubuntu Xenial) "[SRU] biber 2.4 to xenial" [Low,Fix committed]
[16:37] <bdmurray> LocutusOfBorg: I saw the bug in the changelog, but its not in the .changes file possibly because you built it on a debian system?
[16:37] <LocutusOfBorg> no, I didn't
[16:38] <LocutusOfBorg> dpkg-buildpackage -S -sa -d on ubuntu 16.04lts
[16:38] <bdmurray> well without a Launchpad-Bugs-Fixed line, the SRU tools won't know about the bug which will slow down the process.
[16:39] <LocutusOfBorg> but why it didn't add it?
[16:41] <cjwatson> bdmurray: hm, really?  http://launchpadlibrarian.net/265003294/biber_2.4-1ubuntu1.16.04.1_source.changes shows a Launchpad-Bugs-Fixed line
[16:41] <cjwatson> bdmurray: linked from https://launchpad.net/ubuntu/xenial/+queue?queue_state=1
[16:42] <bdmurray> cjwatson: hmm, thanks I didn't realize the package name linked to the .changes file.  I'll try sru-review again
[16:43] <bdmurray> LocutusOfBorg: okay, that was my mistake
[16:43] <LocutusOfBorg> wonderful to hear :) thanks for reviewing it
[16:43]  * LocutusOfBorg leaves to home
=== dpm-afk is now known as dpm
[18:04] <nacc> cyphermox: around? have some quick questions on the current ubuntu delta for sg3-utils
=== afkthairus is now known as athairus
=== Snow-Man_ is now known as Snow-Man
[20:13] <bdmurray> mwhudson: Is comment #10 a good test case for bug 1574904?
[20:13] <ubottu> bug 1574904 in docker.io (Ubuntu Xenial) "Docker compiled with wrong version of Go" [High,New] https://launchpad.net/bugs/1574904
=== tinoco is now known as tinocoff
[20:51] <slangasek> nacc: yes, by default anything on stderr is a failure; there's a Restriction that you need to explicitly set if you want stderr to /not/ be treated as a failure
[20:52] <nacc> slangasek: ah interesting, i think that's what we want for this case -- i'll look for documentation
[20:53] <nacc> Restriction: allow-stderr
[20:53] <dobey> i still think that is an insane default
[21:13] <nacc> slangasek: i think the php-defaults -> php-horde-{imp,ldap} failures in excuses are testbed issues, can you mark them as ignored? (or retry?)
[21:17] <nacc> slangasek: fyi, i think all php related packages in excuses now have fixes filed for them that are just awaiting sponsorship
=== jynik_ is now known as jynik
=== Fersure_ is now known as Fersure