| slangasek | nacc: it's already built, htree days ago | 00:00 |
|---|---|---|
| slangasek | but the autopkgtests failed | 00:00 |
| nacc | slangasek: nm, php-symfony-security & php-symfony-security-acl are going to conflict unless we move up to a 2.8 level of symfony | 00:00 |
| nacc | slangasek: yeah, the failure is the conflict | 00:01 |
| slangasek | ok | 00:01 |
| nacc | so that's another reason to move up to 2.8.2 | 00:03 |
| nacc | slangasek: sigh, it's another bootstrap case, i think | 00:07 |
| nacc | slangasek: symfony 2.8.2 needs phpy-symfony-security-acl to build, which needs php-symfony-security to build | 00:08 |
| nacc | specifically php-symfony-security >= 2.8 | 00:08 |
| smoser | hey. | 00:19 |
| smoser | so curtin depends on pyflakes (for make check) | 00:19 |
| smoser | it runs pyflakes both in python2 and python3 | 00:19 |
| smoser | but theres a new 'python3-pyflakes' | 00:19 |
| smoser | where as before there was just pyflakes that worked for both | 00:19 |
| smoser | what should i write as build depends ? | 00:19 |
| smoser | slangasek, ^ i'm sure you can just answer this in 30 seconds. | 00:20 |
| smoser | ie, it runs: | 00:20 |
| smoser | python2 -m pyflakes curtin/ tests/unittests/ | 00:20 |
| smoser | and | 00:20 |
| smoser | python3 -m pyflakes curtin/ tests/unittests/ tests/vmtests/ | 00:20 |
| smoser | which now results in | 00:21 |
| smoser | /usr/bin/python3: No module named pyflakes | 00:21 |
| slangasek | smoser: well, I can guess that you want to build-depend on pyflakes + pyflakes3 | 00:21 |
| smoser | which previously was satisifed by a depends on pyflakes. | 00:21 |
| smoser | but then i can't build on trusty | 00:21 |
| smoser | which ENOPYFLAKES3 | 00:21 |
| slangasek | ok, then you want to build-depend on pyflakes + pyflakes3 | pyflakes (<< 1.1.0-2) | 00:21 |
| smoser | ok. the << is what i was missing. | 00:22 |
| slangasek | the version should technically be the first version that split the package; but 1.1.0-2 is the current version in xenial which is the first release that has it, so it'll DTRT in all Ubuntu releases | 00:22 |
| slangasek | nacc: so how did Debian break this bootstrap loop? | 00:27 |
| smoser | slangasek, http://paste.ubuntu.com/15411741/ | 00:29 |
| smoser | that one fails on trusty | 00:29 |
| smoser | in sbuild: http://paste.ubuntu.com/15411746/ | 00:29 |
| slangasek | smoser: fails how? | 00:29 |
| slangasek | ok | 00:30 |
| smoser | and when i flipped the order (pyflakes < .. | python3-pyflakes) it failed on xenia. | 00:30 |
| slangasek | right | 00:30 |
| slangasek | smoser: are you using the same build-dep resolver setting in sbuild that launchpad uses? | 00:30 |
| smoser | i do not know | 00:30 |
| slangasek | I don't remember which one this is; and you might already have it right yet sbuild is still being unhelpful | 00:31 |
| slangasek | I would say that your intent is correct there, and you should throw it at lp and see if LP DTRT | 00:31 |
| smoser | well, i've not changed sbuild locally to my knowledge | 00:33 |
| smoser | and looking at a random other laucnhpad build lo | 00:33 |
| smoser | log | 00:33 |
| smoser | https://launchpadlibrarian.net/248521085/buildlog_ubuntu-xenial-amd64.cloud-init_0.7.7~bzr1182+1186+444~ubuntu16.04.1_BUILDING.txt.gz | 00:33 |
| smoser | i see: Install core build dependencies (apt-based resolver) | 00:33 |
| smoser | (and sbuild says the default resolver is 'apt'). | 00:34 |
| smoser | so, it would seem that i should be using the same. | 00:34 |
| smoser | that said, its past time when i should be looking at this. | 00:34 |
| smoser | thank you for your time, slangasek | 00:34 |
| smoser | tommorrow maybe. ideally it'd work both on my system *and* launchpad :) | 00:34 |
| smoser | hm.. wonder if the fact that there is 'pyflakes3' helps or not. probably not. | 00:36 |
| slangasek | nope | 00:36 |
| infinity | smoser: sbuild in LP uses --resolve-alternatives, which isn't the default. | 00:38 |
| infinity | smoser: slangasek's suggestion should work if you pass that switch. | 00:40 |
| nacc | slangasek: no idea (yet) | 00:40 |
| hallyn | how can i build a debian sid autopkgtest vm for adt-run to use? | 00:47 |
| hallyn | is there a tool like adt-buildvm-ubuntu-cloud to do it? | 00:48 |
| nacc | hallyn: do you specifically need a vm rather than lxc? | 00:49 |
| hallyn | yes | 00:52 |
| nacc | hallyn: hrm, i'm not finding anything, but buildvm-ubuntu-cloud can take an arbitrary url; does debian host cloud images similarly? | 00:53 |
| hallyn | need to run the cgmanager autopkgtests , and they requir rebooting the host to enable memory cgroup whic his disabled by default in debian | 00:53 |
| nacc | ah | 00:53 |
| hallyn | i think they do... not sure whether similar enough though | 00:53 |
| hallyn | i haven't seen any google results suggesting anyone has done this... | 00:53 |
| nacc | yeah me either :/ | 00:53 |
| hallyn | leme ping the debian lxc maintainer | 00:54 |
| nacc | hallyn: one hit i found mentioned using vmdebootstrap to setup a debian vm | 00:54 |
| hallyn | nacc: url? (for full argument list). | 00:55 |
| hallyn | sounds all right, i assume it just creates the qcow2 and runs debootstrap in there | 00:55 |
| nacc | hallyn: yeah looks like it; sadly they didnt' give the command they ran, just that they used it, afaict (https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1400466.html) | 00:56 |
| hallyn | maybe /usr/share/autopkgtest/setup-commands/setup-testbed | 00:57 |
| hallyn | d'oh | 00:59 |
| hallyn | the adt-virt-qemu manpage tells me what i need :) | 00:59 |
| hallyn | thanks nacc | 00:59 |
| nacc | hallyn: np, that probably should have been more obvious :) | 01:00 |
| nacc | slangasek: is it just me or does symphony's autopkgtests not dtrt? that is, there is a debian/tests/phpunit script that I *think* they meant to be running? rather than the system phpunit? | 01:14 |
| slangasek | nacc: which version of symfony should I be looking at? | 01:15 |
| nacc | slangasek: seems to be the case in all of them | 01:15 |
| nacc | slangasek: i guess i'm not sure what that script is supposed to be for, but d/test/control specifycing 'phpunit' won't run the script in d/tests/ afaict | 01:15 |
| slangasek | nacc: IIRC it will; debian/tests/control's "Tests" list typically points to scripts under debian/tests | 01:16 |
| nacc | slangasek: hrm, ok, i got differing behavior between running that script manually and what autopkgtest said ... but will keep digging | 01:17 |
| nacc | slangasek: fwiw, w/ 2.7.10, i'm down to one runtime failure | 01:19 |
| nacc | slangasek: i'm wondering, though, if it's a side effect of relatime and/or overlayfs | 01:25 |
| nacc | heh, there are bugfixes to this problem (possibly) that went into the kernel today | 01:35 |
| nacc | sigh | 01:35 |
| nacc | yep, the tests pass with aufs :) | 01:40 |
| nacc | slangasek: but then the build fails w/ the message i mentioned earlier ... will need to dig into it to see if it's a regression with dh-php or not | 01:41 |
| nacc | slangasek: figured it out! ok, so think if i get the images licenses figured out, i will have a package update for symfony for you tmrw, with FFe | 01:56 |
| nacc | slangasek: a bug i introduced, of course :/ | 01:57 |
| === juliank is now known as Guest7038 | ||
| === juliank_ is now known as juliank | ||
| sladen | ~ | 03:28 |
| === salem_ is now known as _salem | ||
| Pharaoh_Atem | I really wish that going from symfony 2.7 -> 2.8 didn't break so much crap | 03:52 |
| Pharaoh_Atem | but people do versioning in their packages too strictly and depend on internal behaviors just because php lets them easily do so | 03:53 |
| === darkxst_ is now known as darkxst | ||
| Mirv | pitti: good morning. there would be one vivid regression at https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-036/excuses.html that can't be retried due to the known bug | 05:40 |
| cpaelzer | good morning | 06:11 |
| === Son_Goku_ is now known as Son_Goku | ||
| dholbach | good morning | 08:24 |
| ginggs | why is it taking so long for launchpad to pick up uploads from debian? it seems to be getting worse and worse | 08:40 |
| === sil2100_ is now known as sil2100 | ||
| Odd_Bloke | xnox: apw: This looks like a bug we've already seen come past, but I can't remember the details; could one of you remind me (perhaps by adding a comment to the bug) where we are with all that initrd weirdness? https://bugs.launchpad.net/cloud-images/+bug/1558260 | 09:22 |
| ubottu | Launchpad bug 1558260 in cloud-images "unable to boot arm64 cloud images due to initrd" [Undecided,New] | 09:22 |
| apw | Odd_Bloke, there is a bug i the cloud image creater process (source unknown at this itme) which drops a bad file in there instead of a link, the kernel though when installed into the image is meant to cope and let us continue in the latest images | 09:26 |
| apw | Odd_Bloke, and does not the last comment imply exactly that that it has been resolved in later images ? | 09:26 |
| apw | Odd_Bloke, i thought smoser or someone was on the hook for determining when in the process this file cames into existance | 09:27 |
| apw | Odd_Bloke, or are you saying it is you, and now :) | 09:28 |
| flexiondotorg | I noticed the gstreamer 0.10 plugins -bad and -ugly are no longer in the Xenial archive. Is this a permanent change? | 09:30 |
| Odd_Bloke | apw: Yeah, that last comment does imply that, but the bug was only filed yesterday so I was checking that we expected it to be fixed or if the last commentor got lucky. :p | 09:31 |
| Odd_Bloke | I'll assign it back to Jeff and ask him to confirm that he still sees it with the latest. | 09:31 |
| apw | Odd_Bloke, i am expecting it to have been fixed some time ago, like a week maybe a little more, so it depends how old the previous test was, i didi not look | 09:42 |
| Odd_Bloke | Yeah, he didn't specify exactly which image he was using. | 09:42 |
| apw | Odd_Bloke, but even when the fixed kernel is in the image, one which has postinst which copes with the bad file and just moved it out, you can tell whether the cloud image is broken still as initrd.old would be a file not a link | 09:45 |
| apw | Odd_Bloke, and we do need to find out where that is coming from and why | 09:45 |
| apw | Odd_Bloke, it is definaly not right, and *puts finger in air* it feels like it is coming from a curtain-y level of the build | 09:45 |
| cjwatson | ginggs: Because Debian just changed a bunch of stuff and we're trying to keep up | 10:59 |
| cjwatson | ginggs: https://lists.debian.org/debian-devel-announce/2016/03/msg00006.html | 11:00 |
| ginggs | cjwatson: ah, thanks | 11:02 |
| doko | smb, "Revert back to bind against bind9 export libraries". did you do that for other rdeps too? | 11:59 |
| smb | doko, no only isc-dhcp | 12:00 |
| === _salem is now known as salem_ | ||
| doko | lamont, why does libbind-export-dev ship a libbind9.so (without -export)? | 12:11 |
| infinity | doko: Because he oopsed. Already under investigation. | 12:11 |
| doko | infinity, let me do that, so you'll have time for glibc ... | 12:12 |
| infinity | doko: Go nuts. Whatever he did (broken .so at least) led to isc-dhcp being statically linked, so that'll need a rebuild when fixed. | 12:13 |
| infinity | doko: Also, the udeb deps are wrong. | 12:13 |
| infinity | doko: Enjoy. | 12:13 |
| doko | infinity, udeb's are already fixed | 12:13 |
| infinity | Yay. | 12:14 |
| doko | ok, testing a fix for the symlink issue | 12:21 |
| infinity | doko: Make sure shlibs/etc are all sane enough that the dhcp debs (and udebs) actually get correct deps on foo-export.{deb,udeb} | 12:33 |
| doko | sure | 12:33 |
| infinity | doko: (Which may already be true, but I'm not holding my breath after seeing the result of the current upload) | 12:33 |
| lamont | doko: because of bug. | 12:42 |
| lamont | doko: ta | 12:43 |
| lamont | doko: holler when you have something, and I'll add it to some other cleanup and upload it | 12:45 |
| lamont | (git tree is forward from P4-1 because of some patch cleanup and submmission upstream) | 12:46 |
| lamont | and I guess I'll be merging | 12:48 |
| smoser | hey. i'll ask again, see if anyone has a solution. python3-pyflakes recently came into existance and that is breaking build of my cloud-init and curtin, which previously Build-Depend on pyflakes. They'd run pyflakes in both python2 and python3 mode to test validity of both. | 13:03 |
| smoser | clearly for xenial i can just add a build-depend on python3-pyflakes, but that will mean i can no longer build on anything earlier than xenial. | 13:04 |
| smoser | slangasek suggested depending on 'python3-pyflakes | pyflakes (<< 1.1.0-2)' and on pyflakes. (full debian/control http://paste.ubuntu.com/15411741/). | 13:05 |
| smoser | but that fails with http://paste.ubuntu.com/15411746/ | 13:05 |
| smoser | any thoughts ? do i just have to make two control files now or disable checks. | 13:07 |
| rbasak | smoser: you want sbuild --resolve-alternatives | 13:08 |
| rbasak | (I think) | 13:08 |
| smoser | rbasak, well, maybe. but i'd like for it to work on launchpad too | 13:08 |
| rbasak | smoser: it should Just Work on the buildds I believe. | 13:08 |
| rbasak | src:php5 had the same need and the buildds were fine. | 13:09 |
| smoser | alright. i'll give it a shot. | 13:10 |
| cjwatson | Yes, Launchpad uses --resolve-alternatives. | 13:10 |
| cjwatson | (as Adam said yesterday) | 13:10 |
| smoser | cjwatson, bah. well, i missed that. | 13:16 |
| smoser | thank you, rbasak it seems to work. | 13:16 |
| mterry | cjwatson: do I recall correctly that we added dbgsym packages to PPAs? | 13:27 |
| mterry | aha. main/debug | 13:29 |
| mterry | Thanks! | 13:29 |
| * mterry should update some askubuntu questions | 13:30 | |
| doko | smb, lamont: -1ubuntu2 should fix the known issues. please re-upload isc-dhcp once this is built everywhere | 13:57 |
| tjaalton | does apt use repos that don't have the new DEP-11 metadata? | 13:58 |
| smb | lamont, Can I leave that ^ to you as I cannot upload much (not isc-dhcp anyways) | 13:59 |
| tjaalton | silly question really.. | 13:59 |
| tjaalton | of course it does, like ppas.. just that apt-mirror seems somewhat broken and doesn't sync/clean stuff like before | 14:00 |
| lamont | doko: ok | 14:00 |
| lamont | smb: will do | 14:00 |
| smb | ok cheers | 14:00 |
| lamont | doko: and thanks, I'll get that together and create -2 for e'ryone | 14:00 |
| cjwatson | mterry: the bit you may not have found out for yourself is that it depends on PPA settings: "Build debug symbols" and "Publish debug symbols" on "Change details" | 14:03 |
| mterry | cjwatson: oh nice ok, thanks | 14:03 |
| cjwatson | (this is because debug symbols can be (a) slow to generate and (b) pretty large and would eat into quota on large archives) | 14:04 |
| tjaalton | ok so there's an apt-mirror bug 1550852, with patches from my ex-coworker :) (having to maintain the mirror I set up..) | 14:15 |
| ubottu | bug 1550852 in apt-mirror (Ubuntu) "apt-mirror does not reflect dep11/Components-* and dep11/icons-*" [Medium,Confirmed] https://launchpad.net/bugs/1550852 | 14:15 |
| tjaalton | best way to solve issues is to think out loud, publicly.. | 14:16 |
| jtaylor | doko: interesting approach with pyzmq ... I'd rather see the broken zmq update reverted than tests disabled | 14:20 |
| doko | jtaylor, the tests succeed locally (as written in the changelog=. if you can show me how to fail these locally ... and they were already disabled for mips* | 14:22 |
| jtaylor | on amd64 and i386 | 14:22 |
| jtaylor | they succeed there on buildds too | 14:22 |
| jtaylor | its the others that are the problem | 14:22 |
| doko | no, they failed on the buildds | 14:23 |
| jtaylor | on debian they work | 14:23 |
| doko | ... just on x86 | 14:25 |
| doko | feel free to revert | 14:25 |
| jtaylor | exactly | 14:25 |
| jtaylor | zmq is somehow broken on all other arches | 14:26 |
| jtaylor | zmqs own testsuite just sucks | 14:26 |
| jtaylor | how did zmq even get into xenial? | 14:27 |
| jtaylor | it went into unstable post feature freeze | 14:27 |
| doko | during the ruby2.2 removal | 14:28 |
| sinzui | xnox: rbasak : the rebase of the sl90x patch for juju-mongodb2.6 is going to take a lot of effort. I don't think this is worth the effort because this package is to support upgrades from 1.25/mongo-juju, but the Juju team is only supporting juju2 and juju-mongodb3.2 on s390x | 14:28 |
| infinity | sinzui: I concur that's probably a reasonable direction to go. I assume that would also drop powerpc support for 2.6 (which is also fine). | 14:31 |
| xnox | sinzui, right. by the way you shouldn't need to rebase s390x patch, just pick the right one from github linux-on-z repositories. | 14:32 |
| infinity | sinzui: I lost context long ago on this. Is juju-mongodb/2.4 going away, or will that *also* be in xenial? | 14:32 |
| xnox | sinzui, note that e.g. juju2 is not in ubuntu yet, and juju-core 1.2* in ubuntu xenial is currently using the old mongo. | 14:32 |
| sinzui | xnox: I did and it didn't apply cleanly because the package has our ppc64el and arm64 patches on it | 14:32 |
| xnox | right | 14:32 |
| xnox | sinzui, imho we should try to get mongodb3.2 in, sooner rather than later, at least on s390x, to make sure juju-core 1.25 doesn't use the old mongo. | 14:33 |
| infinity | xnox: juju-core has to use the old mongo. | 14:33 |
| xnox | bummer | 14:33 |
| infinity | xnox: That's the point of the crazy transitional packages. | 14:33 |
| xnox | sigh.... | 14:34 |
| sinzui | infinity: juju-mongodb (2.4) will ne demoted to universe. people upgrading to xenial will still have a juju-core (1.25) to maintain existing deployments | 14:34 |
| infinity | But if juju2 absolutely will land for xenial, we should drop s390x/powerpc from juju-core and juju-mongodb. | 14:34 |
| * xnox wants juju2 in the archive asap then =) at least on s390x | 14:34 | |
| xnox | infinity, i have customers using juju-core today =) so we can't drop it, before juju2 lands =) | 14:34 |
| sinzui | xnox: me too. The juju release team want juju2 beta3 in xenial. | 14:34 |
| infinity | sinzui: See above. Probbaly after juju2/mongo3.2 are in, but we should drop powerpc (not ppc64el) and s390x from juju-core and juju-mongo in xenial to avoid people being confused and trying to use the old bits. | 14:35 |
| sinzui | infinity: understood | 14:35 |
| xnox | =/ | 14:35 |
| xnox | ack | 14:35 |
| infinity | sinzui: Has anyone actually talked to the release team about juju2? | 14:36 |
| xnox | sinzui, so don't care about s390x on mongodb2.6. Any little people who have been using old juju on s390x, can rebootstrap. | 14:36 |
| infinity | sinzui: I've had various CDO people talk to me about things that depend *on* juju2, but I've heard nothing about juju2 timelines. | 14:36 |
| xnox | it's all technically non-supported stuff. | 14:36 |
| xnox | infinity, is pitti release team at all? | 14:36 |
| seb128 | xnox, https://launchpad.net/~ubuntu-release/+members | 14:37 |
| sinzui | that membership is surprising | 14:37 |
| xnox | infinity, so pitti did talk to a few people about all the mongos and jujus | 14:38 |
| * xnox ponder mongi / juji ? | 14:38 | |
| infinity | xnox: Yes, but not specific timelines. Just the packaging bits. | 14:38 |
| infinity | sinzui: Some of those members need to be culled. | 14:38 |
| sinzui | infinity: I beleive alexisb has talked to people. in my meetings I have been clear that there is a juju2 package that is co-installable with juju-core | 14:39 |
| sinzui | infinity: xnox the Juju team do want to propose the juju2 beta3 next week. | 14:40 |
| xnox | sinzui, usually people file FFe bug way ahead of time of landing the thing. Not like "we are ready, file bug and expect it to be reviewed instantly" =) | 14:40 |
| sinzui | xnox: I see cherylj did https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1545913 | 14:42 |
| ubottu | Launchpad bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,New] | 14:42 |
| cjwatson | Does the lxc failure in http://paste.ubuntu.com/15414988/ ring a bell for anyone? I just upgraded to lxc 2.0.0~rc11-0ubuntu1 and lxcfs 2.0.0~rc6-0ubuntu1 in xenial | 14:42 |
| sinzui | cjwatson: hey, thats my bug from this morning. I didn't get answer. I assumed my two wily hosts had incompatbile packages from the lxd ppa. I downgraded to wily-updates to get back to work | 14:44 |
| rbasak | xnox, infinity: I emailed the release team about new versions of Juju during feature freeze once. I didn't think we needed an FFe because that makes no sense given that we do major version bumps after release. | 14:48 |
| rbasak | (assuming that we take an appropriate amount of care, etc) | 14:49 |
| cjwatson | sinzui: filed https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1559169 | 14:53 |
| ubottu | Launchpad bug 1559169 in lxc (Ubuntu) "containers no longer start after upgrade to 2.0.0~rc11-0ubuntu1" [Undecided,New] | 14:53 |
| infinity | rbasak: Less about freezes and more about making sure what we ship isn't crap, migration plans (or lack thereof) are not just sane but well tested, blah blah. Landing everything 2 days before release doesn't instill confidence. | 14:53 |
| sinzui | thank you cjwatson | 14:54 |
| xnox | rbasak, hm, it is new package. | 14:55 |
| rbasak | infinity: sure. Given that Juju releases outside Ubuntu's cycle, and then updates Ubuntu's updates pockets, I sort of see it as independent of Ubuntu's cycle. But that goes both ways, so I think I agree. Because that also means that there shouldn't be any rushing or compromise of quality to make an Ubuntu release. | 14:55 |
| infinity | rbasak: Quite. | 14:56 |
| infinity | rbasak: The only reason to rush if for marketing fanfare and, honestly, releasing 2.0 a few weeks after 16.04 gets you a less noisy channel to the press. | 14:56 |
| infinity | rbasak: So, people should think hard about what they'll actually be landing and when and if it's something they want their name on. :P | 14:56 |
| infinity | s/rush if/rush is/ | 14:57 |
| jamespage | doko, hey - can I steal your last-touched unison merge? current version is causing segfaults and is blocking some HA testing we're doing? | 14:57 |
| rbasak | If releasing at the same time as 16.04 is really important, then the deadline should be considered feature freeze. | 14:57 |
| infinity | rbasak: Don't disagree. | 14:57 |
| rbasak | If feature freeze is missed, then releasing at 16.04 time is at risk. | 14:57 |
| * infinity gets back to breaking the freeze. | 14:58 | |
| ogra_ | its spring time anyway ! stop these freeze talks ! | 14:58 |
| doko | jamespage, please steal everything you like ... | 14:58 |
| doko | jamespage, ohh, that even was an unmerged packages by you for two years ... I had just a no-change upload | 15:02 |
| jamespage | doko, nope not me | 15:03 |
| jamespage | but I'll merge it anyways as it unblocks stuff... | 15:04 |
| doko | ahh, jtaylor ... misread | 15:04 |
| jtaylor | unison is a mess, it should probably just be removed | 15:06 |
| jtaylor | they don't seem to have an compatiblity so whatever is in the archvie stops working on the next upstream version | 15:06 |
| rbasak | sinzui: can you add dep3 headers to all the quilt patches you're adding for juju-mongodb 3.2 please? We normally want them anyway, but here there are so many patches we really need them to keep track. | 15:17 |
| rbasak | sinzui: http://dep.debian.net/deps/dep3/ | 15:17 |
| rbasak | sinzui: also, please update the headers for any patch you modify (that isn't just a refresh to unfuzz) | 15:17 |
| rbasak | infinity: how do you feel about a juju-mongodb3.2 where Ubuntu's mongodb is still on 2.6? | 15:19 |
| rbasak | (Debian is on 2.4 AFAICT) | 15:19 |
| infinity | rbasak: I don't care if juju's ahead or behind of the mongodb game, so long as they have a plan to support it. | 15:20 |
| rbasak | OK | 15:20 |
| rbasak | Reviewing this is fun. I don't have anything to base a diff from :-/ | 15:20 |
| rbasak | (well, 2.6) | 15:20 |
| infinity | rbasak: (And if that plan involves "make the security team deal with it", they should be asked too) | 15:20 |
| rbasak | That's an open question at the moment. Juju management are looking into it. | 15:21 |
| doko | apw, infinity: autopkgtest for linux 4.4.0-14.30: amd64: Pass, armhf: Pass, i386: Pass, ppc64el: Regression â™» , s390x: Pass | 15:27 |
| doko | (triggered by gcc-5). is this a real issue, or can we ignore it? | 15:27 |
| rbasak | sinzui: have you checked to see if there are any updates needed to debian/copyright (for both juju-mongodbs)? | 15:29 |
| sinzui | rbasak: oh, have I...I removed an entry form the 3.2 because the package was removed from 3rd party | 15:29 |
| sinzui | rbasak: I hestitantly offer to go the full dep-5 | 15:31 |
| rbasak | sinzui: I want to step out of the loop on this one. I'm confident you understand what is required and how to do it, so I think it's best to leave it between you and the archive admin. | 15:31 |
| rbasak | That means pitti in this case I think? | 15:32 |
| infinity | doko: Gonna give it a kick to retry. But it looks like it was busted tests (since fixed), not GCC's fault. | 15:32 |
| sinzui | understood rbasak | 15:32 |
| rbasak | sinzui: dep3 headers I do want though. It's difficult to understand what I'm reviewing without them. | 15:33 |
| sinzui | rbasak: yeah, I have that open now | 15:33 |
| rbasak | sinzui: basically I want to know where each patch came from and where I can find upstreaming status. | 15:34 |
| sinzui | rbasak: okay, understood | 15:34 |
| rbasak | (because if we don't track that, packaging inevitably becomes an unmaintainable mess) | 15:35 |
| rbasak | Thanks :) | 15:35 |
| smb | lamont, ugh that bind9 saga isn't a happy one | 15:50 |
| doko | smb, what's still wrong? | 15:50 |
| smb | lamont, now its afaict named-checkzone which went into bind9 and bind9utils | 15:50 |
| doko | smb, lamont: so I think the best thing would be to install into debian/tmp, not debian/bind9, and have a bind9.install file to exactly say what should be included in bind9 | 15:53 |
| lamont | smb: gar | 15:54 |
| lamont | doko: likely so | 15:54 |
| * lamont stares at the build-deps in -1ubuntu2, and wonders if that was really necessary | 15:54 | |
| lamont | deps actually | 15:55 |
| doko | lamont, I was checked for missing libs, because I found one export lib missing in the dh_makeshlibs call in debian/rules | 15:58 |
| lamont | makes sense | 15:59 |
| lamont | I decided I didn't care enough to change it back | 15:59 |
| apw | doko, that looks more like test failure to my eye you might just hit retry and see if it changes, if not i'll ask peeps to look closer | 15:59 |
| doko | apw, in fi ni ty already gave it back | 16:00 |
| apw | doko, ahh good enough, we shall see when it completes there | 16:00 |
| lamont | doko: hoping you have time to do that switch to debian/tmp? +1 from me on the concept | 16:01 |
| xnox | pitti, can i trick you into reviewing https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1551952 or are you off already? | 16:01 |
| ubottu | Launchpad bug 1551952 in multipath-tools (Ubuntu) "FFE: Please merge multipath-tools 0.5.0+git1.656f8865 from Debian unstable " [Undecided,New] | 16:01 |
| doko | lamont, not today; I'll look at it tomorrow | 16:06 |
| lamont | ok | 16:08 |
| lamont | smb: feedback from isc is that we likely just broke signals for all of the bind tools when we fixed dhcp... | 16:08 |
| lamont | so I'll be reworking that diff a bit | 16:08 |
| smb | lamont, Hm ok. To me it looked like only bind itself would enter things via isc_app_start (not sure that is the exact name) and everythning else would only have isc_app_ctxstart | 16:10 |
| lamont | ah, could be | 16:11 |
| nacc | slangasek: filed LP: #1558848, to get symfony through, let me know what you think | 16:11 |
| * lamont was just parroting the reply to the patch from isc | 16:11 | |
| ubottu | Launchpad bug 1558848 in symfony (Ubuntu) "symfony: failing autopkgtests" [Undecided,New] https://launchpad.net/bugs/1558848 | 16:11 |
| smb | lamont, Yeah, well I cannot be 100% sure. The whole thing is a bit obscure with the two sets of methods in the ctx struct. | 16:12 |
| smb | lamont, So not that this is tested or even tried as code but if we need to change it then maybe by adding some #ifdef around that only includes the return if compiled without thread support... | 16:21 |
| lamont | smb: likely the way I'll go | 16:22 |
| lamont | but it'll be post-sunday | 16:22 |
| xnox | doko, can we drop gcc-3.3 and hence libstdc++-5.0 from xenial? =) | 16:25 |
| smb | lamont, Yeah, would you think it would be better to hold back with any bind9 upload? Not completely ideal but with a working though statically linked dhclient out this might allow less rushing | 16:28 |
| * lamont plans to upload iscdhcp shortly, just waiting on the publisher | 16:29 | |
| lamont | the other stuff is just "bind9 bugs" | 16:29 |
| lamont | I mean, we already have the potential defect there in P4-1 | 16:29 |
| smb | lamont, yeah but that never went out | 16:30 |
| lamont | it's more one of "if someone files a bug about signals being broken in some random bind9 utility, we know root cause already..." | 16:30 |
| lamont | hrm | 16:31 |
| lamont | this is sad making | 16:31 |
| lamont | it may be my today thing after all | 16:31 |
| smb | lamont, none of the recent bind9 uploads I mean. The first one because of dependencies and the other becuase of the adt failures | 16:31 |
| lamont | smb: ack | 16:32 |
| lamont | which is actually cool, beacuse I don't need Replaces. :D | 16:32 |
| doko | xnox, can you convince Debian first to drop it? | 16:33 |
| doko | it just builds one lib | 16:33 |
| smb | lamont, Also you kinda do not have to wait to upload isc-dhcp because there is no reason to | 16:34 |
| lamont | smb: it was more of "waiting for 1ubuntu2 to really really be in the archive, but taht was 2 hours ago.. | 16:35 |
| infinity | smb: "no reason to"? | 16:35 |
| smb | lamont, ERm yes, that s what I try to say | 16:35 |
| smb | lamont, It wont go there because it annoys britney (I mean ikiwiki-hosting test regression) | 16:36 |
| lamont | infinity: no longer a reason to wait | 16:36 |
| smb | infinity, Right that was what I meant | 16:36 |
| infinity | lamont: Right, I misread as "we don't need to wait" not "the wait is over". | 16:36 |
| * lamont got distracted | 16:36 | |
| lamont | and then went "why do I even have this window open" | 16:38 |
| smb | Heh yeah... I just happened to go back there and refresh and then decided that red is not my favourite colour in there | 16:41 |
| smb | lamont, Or rather I think I did not mean what you thought I meant... | 16:45 |
| lamont | right | 16:46 |
| smb | lamont, I meant there is no reason to do the upload... | 16:46 |
| nacc | slangasek: and just tested in parallel w/ and w/o the imagemagick ubuntu4 i just posted to LP: #1549942; without the patch it fails the tests on amd64 and with the patch it succeeds. | 16:46 |
| ubottu | Launchpad bug 1549942 in ImageMagick "php-imagick failing autopkgtests" [Unknown,New] https://launchpad.net/bugs/1549942 | 16:46 |
| nacc | slangasek: apologies, I don't know what I had messed up before in my test setup | 16:46 |
| smb | lamont, Though it probably does not matter if isc-dhcp now links dynamically it will remains stuck in proposed together with the bind9 | 16:48 |
| lamont | ack | 16:57 |
| nacc | slangasek: i believe we need a rebuild of php-zend-code so that it pulls in php-common rather than php5-common | 17:13 |
| nacc | slangasek: but i believe why it's not migrating is symfony | 17:13 |
| nacc | slangasek: (via php-proxy-manager) | 17:13 |
| nacc | slangasek: i believe the rebuild of php-zend-code isn't strictly required right now (as it will just pull in php5 for now), but will be needed eventually | 17:26 |
| nacc | slangasek: ugh, so i buitl php7.0 again from source in s chroot, the test passed; installed php7.0 and it failed, with either the php7.0 or from-source php binaries. So ... maybe a module load issue? continuing to investigate :/ | 17:47 |
| nacc | slangasek: hrm, it's a php.ini issue, possibly | 17:54 |
| Pharaoh_Atem | nacc: what do I need to do to stop being moderated on ubuntu-devel? | 18:27 |
| slangasek | nacc: pile of replies for you on bug #1558848; the one that needs action from you is https://bugs.launchpad.net/ubuntu/+source/php-symfony-polyfill/+bug/1558848/comments/12 | 18:27 |
| ubottu | Launchpad bug 1558848 in symfony (Ubuntu) "symfony: failing autopkgtests" [Undecided,New] | 18:27 |
| slangasek | Pharaoh_Atem: become an Ubuntu Developer ;) | 18:27 |
| nacc | slangasek: yep, working through them now, thanks! | 18:28 |
| Pharaoh_Atem | slangasek: is it anywhere near as hard as becoming a Debian one? | 18:28 |
| slangasek | nacc: fwiw we'll want to adjust the symfony upstream version number to 2.7.10+dfsg (Ã la the existing 2.7.9+dfsg) to make clear this is a modified upstream tarball. I can address that here | 18:29 |
| nacc | slangasek: ah ok, i wasn't sure, since i hadn't run their script to mangle the name. | 18:29 |
| nacc | slangasek: also, i just realized i still need to fix the licenses! | 18:30 |
| nacc | slangasek: sorry, let me try to get that done now too | 18:30 |
| slangasek | Pharaoh_Atem: it's somewhat less process-heavy but involves a fair bit of demonstrating active involvement in the project, plus waiting in queues | 18:30 |
| * Pharaoh_Atem sighs | 18:30 | |
| slangasek | Pharaoh_Atem: being unmoderated on ubuntu-devel is probably not a good argument for becoming an Ubuntu Developer :-) | 18:30 |
| nacc | Pharaoh_Atem: would you be able to test something for me on php7.0 in non-ubuntu installations? | 18:30 |
| Pharaoh_Atem | nacc: yes | 18:30 |
| slangasek | nacc: ok shelving symfony until you re-ping me | 18:30 |
| * Pharaoh_Atem is actually updating his testing atm | 18:30 | |
| Pharaoh_Atem | *test stuff | 18:31 |
| nacc | Pharaoh_Atem: http://paste.ubuntu.com/15416746/ | 18:31 |
| nacc | slangasek: yep, thanks | 18:31 |
| nacc | slangasek: php-monolog v2 debdiff posted, thanks | 18:32 |
| slangasek | nacc: you tested that autopkgtest works? | 18:37 |
| nacc | slangasek: yep | 18:41 |
| slangasek | nacc: ok, uploading | 18:42 |
| Pharaoh_Atem | nacc: you'd like me to run this as a CLI app or web script? | 18:43 |
| nacc | Pharaoh_Atem: cli, please | 18:43 |
| flexiondotorg | I missed the details, but am I right in saying syncing with Debian is not currently possible? | 18:43 |
| Pharaoh_Atem | okay | 18:43 |
| nacc | slangasek: oh, fwiw, i didn't alter upstream in this case, as i made an archive from github | 18:48 |
| nacc | slangasek: for symfony, so would we still +dfsg? or would you rather I use uscan to grab the tarball (if I can convince it to get th eright version) | 18:49 |
| Pharaoh_Atem | afaik, it wouldn't be dfsg because you're not using the debian one, you've made your own | 18:49 |
| slangasek | flexiondotorg: we are past the Debian Import Freeze, so no packages are being automatically synced from Debian; an Ubuntu developer can still manually request a sync ('syncpackage' command); if the new version of the package includes new features, this should be discussed with the release team first per FeatureFreeze | 18:49 |
| slangasek | nacc: I would still say +dfsg, if you're deleting things that are part of the upstream tarball | 18:50 |
| flexiondotorg | slangasek, Yep, I understand that. My question was not clear enough. | 18:50 |
| nacc | slangasek: the orig.tar.gz has no deletions; it was a `git clone`, then `git archive ... v2.7.10` from upstream symfony | 18:51 |
| flexiondotorg | slangasek, I do the vast majority of the Ubuntu MATE work in the Debian community as part of the pkg-mate team. | 18:51 |
| slangasek | nacc: ok, fine with me then | 18:51 |
| flexiondotorg | I have several syncrequests filed, bug fixes. | 18:51 |
| flexiondotorg | Those packages are not available in LP. | 18:52 |
| flexiondotorg | slangasek, For example - https://launchpad.net/debian/+source/mate-dock-applet | 18:52 |
| flexiondotorg | 0.69 in LP and 0.70 in Debian. The Ubuntu dev who looked at my syncerequests was unable to process them. | 18:53 |
| slangasek | flexiondotorg: oh, you're asking if syncing is currently broken. Yes, lp is having import troubles due to the Debian ftp team dropping checksums on experimental; the LP team is working on fixing this | 18:53 |
| * Pharaoh_Atem listens to Legend of Zelda music while system updates complete | 18:53 | |
| slangasek | packages that were in Debian prior to Wednesday-ish are syncable, but new uploads are currently not visible | 18:54 |
| flexiondotorg | slangasek, Thanks. That was the deatil I was missing. | 18:54 |
| flexiondotorg | Thanks for explaining. I heard something had changed but wasn't aware what exactly. | 18:54 |
| nacc | slangasek: ok, updated symfony in teh same bug, passes tests and has licensing information updated (upstream moved from a base64 icon to SVG, so it changed the checksums) | 18:58 |
| nacc | slangasek: i believe php-psr-log requires the php-opencloud update, afaict | 19:08 |
| Pharaoh_Atem | nacc: http://fpaste.org/342352/83283271/ | 19:12 |
| nacc | Pharaoh_Atem: sigh, those are bugs too :) | 19:12 |
| Pharaoh_Atem | damn it | 19:12 |
| nacc | Pharaoh_Atem: so the thing is, if you build upstream PHP 7.0.4 | 19:12 |
| nacc | Pharaoh_Atem: if you wouldn't mind trying that | 19:13 |
| nacc | Pharaoh_Atem: it works fine | 19:13 |
| Pharaoh_Atem | I'll give it a go, one sec | 19:13 |
| nacc | Pharaoh_Atem: or just passing ./configure w/o any options | 19:13 |
| Pharaoh_Atem | that's... bizarre | 19:13 |
| nacc | agreed. | 19:13 |
| Pharaoh_Atem | nacc: did you get the upstream php 7.0.4 from GitHub or php.net? | 19:14 |
| nacc | Pharaoh_Atem: github | 19:14 |
| nacc | Pharaoh_Atem: is there a specific difference? | 19:15 |
| Pharaoh_Atem | I hope not | 19:15 |
| * Pharaoh_Atem is about to check | 19:15 | |
| nacc | :) | 19:15 |
| Pharaoh_Atem | but... knowing them... | 19:15 |
| Pharaoh_Atem | I hate people so much | 19:17 |
| nacc | Pharaoh_Atem: did you find a difference? | 19:18 |
| Pharaoh_Atem | nacc: http://paste.fedoraproject.org/342361/83287411/ | 19:19 |
| nacc | Pharaoh_Atem: i asked the xdebug maintainer to test the same script and he ran it with upstream 7.0.3, 7.0.4 and 7.1.0-dev and it didnt' throw an error ... so i'm pretty sure it's a bug in the distro buildds, just not surew hat yet | 19:19 |
| Pharaoh_Atem | I'm not if these are really diffs or not | 19:20 |
| nacc | yeah the textual diff is just lexer output, iiuc | 19:20 |
| nacc | the difference in some files being present in Zend/ is a bit worrisome | 19:20 |
| === salem_ is now known as _salem | ||
| nacc | but those might be generated files? (i see configure is also only in 7.0.4) | 19:21 |
| Pharaoh_Atem | nacc: yeah, I don't know | 19:22 |
| Pharaoh_Atem | nacc: I'm going to compile php 7.0.4 from php.net sources | 19:27 |
| nacc | Pharaoh_Atem: thanks, that would be a good check; i'm bisecting through our disable parameters :/ | 19:27 |
| Pharaoh_Atem | for reference, this is what remi sets it up to be: https://github.com/remicollet/remirepo/blob/master/scl-php70/php/php.spec#L1115 | 19:29 |
| Pharaoh_Atem | and here's what %configure expands to: https://github.com/remicollet/remirepo/blob/master/scl-php70/php/php.spec#L1115 | 19:30 |
| Pharaoh_Atem | err | 19:30 |
| Pharaoh_Atem | http://paste.fedoraproject.org/342373/45832942/ | 19:30 |
| Pharaoh_Atem | nacc: so I'm building php now | 19:32 |
| nacc | Pharaoh_Atem: right, a big difference is we pass --disable-all on Debian/Ubuntu ... but it seems like it might be in the intersection of the two (debug, rpath? ... neither seem likely) | 19:33 |
| Pharaoh_Atem | running make test atm | 19:44 |
| Pharaoh_Atem | nacc: welp | 19:50 |
| Pharaoh_Atem | nacc: http://paste.fedoraproject.org/342382/14583307/ and http://paste.fedoraproject.org/342381/33065414/ | 19:51 |
| Pharaoh_Atem | nacc: I don't know what to make of this | 19:53 |
| cjwatson | slangasek,flexiondotorg: maybe I should send mail explaining this, since it'll take another few days to sort out | 21:02 |
| lamont | infinity: and P4-3 uploaded to really work this time. | 21:06 |
| infinity | lamont: Do we need yet another dhcp upload after this bind, or was the last one correct? | 21:17 |
| infinity | lamont: Hrm, deps on the previous upload look plausible at least. | 21:18 |
| * lamont checked amd64, and it definitely built with -1ubuntu2 | 21:19 | |
| lamont | the only issue with -1ubuntu2 was that it delivered, uh, everything not in bind9 as part of bind9. | 21:19 |
| lamont | or at least enough so to make it unusable | 21:19 |
| infinity | Oops. :) | 21:20 |
| lamont | I didn't do that | 21:20 |
| lamont | but I fixed it in -3, by switching to install into debian/tmp and sort things from there | 21:20 |
| lamont | complete with --fail-missing on dh_install | 21:20 |
| lamont | a bit to hectic in the day for me to care enough to confirm that all the isc-dhcps built with -1ubuntu2, though that should be done to set security at ease (though the deps would likely show that easier...hrm | 21:21 |
| lamont | infinity: as long as all the isc-dhcp-servers Depend on multiple -export libs, they're shiny | 21:22 |
| infinity | lamont: Right, that's what I confirmed on amd64. | 21:22 |
| infinity | lamont: I might poke the other 6 quickly out of paranoia. | 21:22 |
| lamont | infinity: I would lovethat | 21:24 |
| === nobuto_ is now known as nobuto | ||
| flexiondotorg | cjwatson, Do you think it likely 16.04 final beta will be delayed due to the Debian archive changes? | 21:33 |
| flexiondotorg | I see that 3rd party repositories are not updating on 16.04 daily due to weak digests etc too. | 21:33 |
| cjwatson | flexiondotorg: No | 21:34 |
| flexiondotorg | OK | 21:34 |
| flexiondotorg | Thanks. | 21:34 |
| cjwatson | flexiondotorg: syncpackage being broken really just means that perhaps there might have to be a few manual uploads masquerading as syncs (or indeed fakesyncs), which is annoying but not fatal | 21:35 |
| cjwatson | flexiondotorg: And there's no reason to expect any particular timeline for third-party repositories to stop sucking, other than PPAs | 21:35 |
| cjwatson | flexiondotorg: If it's just a matter of a SHA-1 digest on the signature but the key is otherwise strong enough, then it actually is still accepted, there's just a warning which looks a bit error-like | 21:36 |
| flexiondotorg | So it will be required that 3rd party repositories need to adapt to thi new structure. | 21:36 |
| cjwatson | flexiondotorg: They need to upgrade their signatures, yes | 21:37 |
| cjwatson | flexiondotorg: I wouldn't call it a structural change | 21:37 |
| cjwatson | flexiondotorg: In some cases they may have to add stronger checksums to their index files | 21:37 |
| flexiondotorg | So, no one using the google-chrome repostiory will get upgrades until Google update their sigs? | 21:37 |
| cjwatson | flexiondotorg: Right, but we're told that will happen soon | 21:38 |
| cjwatson | flexiondotorg: Also I think it only affects upgrades *from that repository*, as long as you don't mind apt-get update exiting non-zero | 21:38 |
| cjwatson | So that seems annoying but not very fatal, and there's every incentive for third-party repository maintainers to sort stuff out | 21:39 |
| juliank | flexiondotorg: Chrome was fixed today | 21:40 |
| juliank | So, it only warns about the weak signature now, but the files themselves contain the SHA256 values needed to still allow it. | 21:41 |
| juliank | I'd expect the warning to be fixed in the next weeks or months as well | 21:41 |
| cjwatson | The Google talkplugin repository has the same problem | 21:42 |
| cjwatson | Hopefully they have common repository generation code | 21:42 |
| flexiondotorg | Well, the non-zero exit code breaks aptdaemon. | 21:44 |
| dax | while Google's fixing stuff, adding arch=amd64 to their repository-adding script would be helpful | 21:44 |
| dax | (if that didn't happen already, I didn't look recently) | 21:45 |
| flexiondotorg | cjwatson, I will contact some 3rd party repo maintainers and make them aware. | 21:46 |
| flexiondotorg | cjwatson, So, will all repos need to adopt SHA256 and xz compression? Is that enough? | 21:47 |
| flexiondotorg | juliank, Chrome has not been update. Nor Steam. | 21:49 |
| flexiondotorg | lso affected, Spotify, Opera, Vivaldi, Insync. | 21:50 |
| Unit193 | And apt 1.2.8 makes the warnings look less like errors, too. | 21:50 |
| Pharaoh_Atem | crap | 21:52 |
| Pharaoh_Atem | what the heck happened? | 21:52 |
| Pharaoh_Atem | did this sha256 and xz only stuff just take effect? | 21:52 |
| juliank | flexiondotorg: Seriously. It has been updated. about 10 hours ago | 21:52 |
| juliank | It now only prints one warning instead of 2 | 21:52 |
| juliank | and this warning is really a warning now, not an error. | 21:53 |
| juliank | They actually fixed this yesterday already, but only regenerated their archive today. | 21:53 |
| juliank | Unit193: APT 1.2.8 will make errors look like errors to distinguish them from warnings (both were listed as warnings previously) | 21:54 |
| Unit193 | juliank: Ah, OK. Noticed you fixed it anyway. Nice job! | 21:55 |
| juliank | cjwatson: I see. I suspect it's done by the same code as the Chrome repo, but given that the plugin was not updated since April, it has no SHA256 yet | 21:55 |
| juliank | flexiondotorg: Steam and Opera work just fine | 21:55 |
| juliank | They just print a warning, but continue | 21:56 |
| juliank | Vivaldi, Insync I don't know about, but I think you also only see the "The repository is insufficiently signed by key" message which means it works | 21:56 |
| juliank | With the talkplugin, I think somebody at google would have to run an update manually, as that's practically dead. | 21:57 |
| juliank | Vivaldi is OK | 21:59 |
| juliank | Insync is OK too | 22:00 |
| juliank | They have until January to fix these warnings, I think that's fair. | 22:00 |
| juliank | They literally just have to add two arguments to their gpg invocation | 22:01 |
| juliank | --digest-algo SHA512 to be precise | 22:02 |
| === _salem is now known as salem_ | ||
| juliank | flexiondotorg: If you experience any other issue, please let me know. With the google repo now half-fixed, aptdaemon should also work correctly again. | 22:06 |
| Unit193 | juliank: You were looking for people to report broken repos, did you have a page listing them already? | 22:07 |
| juliank | Apart from the temporary breakage at Google, there is no real hard breakage, only the soft warnings. | 22:07 |
| juliank | I think I'll start a wiki page for tracking this | 22:08 |
| flexiondotorg | juliank, Confirm Chrome works. Google Music Manager cause aptdaemon to fail. | 22:10 |
| flexiondotorg | juliank, Google Talk plugin causes aptdaemon to fail. | 22:12 |
| juliank | Unit193: flexiondotorg: Listed on https://wiki.debian.org/Teams/Apt/Sha1Removal | 22:12 |
| cjwatson | flexiondotorg: It's not necessary to adopt xz compression. | 22:12 |
| flexiondotorg | cjwatson, So just SHA256 then? | 22:13 |
| cjwatson | flexiondotorg: Debian experimental switched to xz only, which meant a bunch of stuff that assumed that there'd always be gz-compressed files broke, but that's unrelated to apt's requirements. | 22:13 |
| juliank | I think almost everyone expect Google only has to pass --digest-algo SHA512 | 22:13 |
| juliank | to gpg | 22:13 |
| cjwatson | flexiondotorg: Something stronger than the broken SHA-1, yes. | 22:13 |
| juliank | (or 256) | 22:13 |
| cjwatson | Or 384, which was the suggestion in one of the LP bugs/MPs | 22:14 |
| juliank | Google was incredibly beyond things | 22:14 |
| juliank | cjwatson: APT only support 256 and 512 | 22:14 |
| cjwatson | juliank: Even for digests on signatures? That's a curious limitation | 22:14 |
| juliank | Ah, no, not on signatures | 22:15 |
| juliank | I allowed them on signatures :D | 22:15 |
| juliank | cjwatson: The gz removal was sort of my fault too... | 22:16 |
| cjwatson | There was a suggestion that SHA512 might run into length extension attacks, which AIUI doesn't quite apply to signatures as stated, but 384 should still be plenty strong enough and avoids possible analogues of that | 22:16 |
| cjwatson | We haven't quite decided | 22:16 |
| cjwatson | juliank: How so? | 22:16 |
| juliank | cjwatson: I asked Ganneff if we could try removing MD5 and SHA1, and he did that and .gz :) | 22:17 |
| cjwatson | Heh | 22:17 |
| cjwatson | Well, like I say, it's been a bit of a hassle but I don't actually think it's wrong | 22:17 |
| juliank | But it's limited to experimental, so it should not be that much of a deal unless you just error out completely if exp. does not work | 22:18 |
| cjwatson | The code we've run into does :) | 22:18 |
| cjwatson | At least some of it | 22:18 |
| cjwatson | Yeah, debmirror and gina both want all suites they're operating on to work | 22:19 |
| cjwatson | It's possible we might not have noticed the breakage otherwise, so whatever | 22:20 |
| juliank | cjwatson: How exactly does aptdaemon fail? aptd is a huge issue, as it (actually python-apt) silently discards all warnings if there's no error. | 22:22 |
| juliank | oops | 22:22 |
| juliank | flexiondotorg: ^ | 22:22 |
| juliank | I don't expect that to be a problem, AFAIUI third party repositories get disabled on an update; and a new install would not have any. | 22:22 |
| juliank | flexiondotorg: I'll try to get ahold of someone who can fix the repos for Google Talk Plugin and Music Manager next week; maybe some of the chromium guys involved in fixing the Chrome repo know what to do | 22:24 |
| Unit193 | vbox's repo should likely also be on that page. | 22:24 |
| juliank | Unit193: I just added more details, feel free to add vbox | 22:27 |
| juliank | I think it's a bit rough now, but it should quickly get better. | 22:34 |
| flexiondotorg | juliank, I have a list of 3rd party repos. I'll add them to the Sha1Removal in an hour or two. | 22:35 |
| juliank | great :) | 22:36 |
| flexiondotorg | I'm using the aptdaemon.gtk3widget | 22:36 |
| flexiondotorg | I'll get details of what it causing the exact issue. | 22:37 |
| flexiondotorg | Essentially, the install fail because the package can be found. Which suggest the repo update didn't complete. | 22:37 |
| flexiondotorg | juliank, This is what I know of. | 22:49 |
| flexiondotorg | http://paste.ubuntu.com/15419170/ | 22:49 |
| flexiondotorg | Some of those are in the OBS. | 22:49 |
| flexiondotorg | juliank, I'll test all those via aptdaemon.gtk and document what works and work down. If there is a failure, I'll capture the log. | 22:56 |
| === salem_ is now known as _salem | ||
| * lamont scratches his head at the isc-dhcp apt failure | 23:00 | |
| nacc | slangasek: can you tell why php-imagick (per autopkgtest) is skipping all the tests on amd64, but not on i386 (e.g.) | 23:01 |
| slangasek | nacc: url? | 23:01 |
| nacc | slangasek: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/php-imagick/20160317_113406@/log.gz | 23:02 |
| nacc | slangasek: it seems to ahve started with that one, which was triggered by PHP 7.0.4-5ubuntu2 | 23:02 |
| nacc | http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/amd64/ | 23:02 |
| slangasek | 251 skipped tests> lol | 23:02 |
| slangasek | no, no idea | 23:02 |
| nacc | slangasek: running it on my machine, it runs them all | 23:02 |
| nacc | slangasek: so i'm not sure what's happening? | 23:03 |
| nacc | and it's weird that it ran them on i386 | 23:03 |
| slangasek | nacc: when you test are you using an adt test runner that gives you a clean env? | 23:03 |
| nacc | slangasek: yeah, i am using adt-virt-lxc | 23:03 |
| nacc | with a freshly made adt-xenial from earlier today | 23:04 |
| slangasek | nacc: well, imagick-3.4.0RC6/tests/skipif.inc tells it to skip all tests if the imagick extension isn't loaded | 23:04 |
| slangasek | e.g. | 23:04 |
| slangasek | WARNING: Module imagick ini file doesn't exist under /etc/php/7.0/mods-available | 23:05 |
| slangasek | and that's listed at install time | 23:05 |
| nacc | slangasek: but the d/t/control says to depend on php-imagick | 23:05 |
| slangasek | so there you go | 23:05 |
| nacc | hrm | 23:05 |
| slangasek | seems to be a misbuilt package, php-imagick (3.4.0~rc6-1ubuntu2) | 23:05 |
| slangasek | was there a race between the upload of this package and the upload of some of the package helper fixes | 23:06 |
| slangasek | ? | 23:06 |
| slangasek | nacc: well, also, those are all tests of the old version of php-imagick in xenial; not of the version in xenial-proposed | 23:07 |
| nacc | slangasek: yeah, could be ... except for the same package version (only using release pocket), i don't get that error? | 23:07 |
| nacc | so i guess it could be race, but that run was from a few hours ago when imagemagick went in | 23:08 |
| slangasek | yes, but those tests are all still testing the released version of php-imagick, not the one in -proposed | 23:08 |
| nacc | slangasek: right, so am I | 23:08 |
| slangasek | so whatever that -1ubuntu2 binary was built with, maybe it's broken | 23:08 |
| flexiondotorg | juliank, SpiderOakOne fails. | 23:08 |
| nacc | slangasek: my adt runs say both release and proposed are working right now :) | 23:08 |
| nacc | "working" => passing tests | 23:09 |
| slangasek | nacc: I can definitely reproduce that message here: | 23:09 |
| slangasek | Setting up php-imagick (3.4.0~rc6-1ubuntu2) ... | 23:09 |
| slangasek | WARNING: Module imagick ini file doesn't exist under /etc/php/7.0/mods-available | 23:09 |
| slangasek | nacc: btw, can you tell me how to reproduce the orig.tar.gz you created for symfony, step-by-step? want to be able to verify its contents | 23:09 |
| slangasek | (against upstream) | 23:10 |
| slangasek | (one of those sponsorship nit-picky things) | 23:10 |
| slangasek | and I definitely get that warning with php-imagick from release, and definitely don't get it with php-imagick from -proposed | 23:10 |
| slangasek | so I'll solve this problem by getting the one in -proposed unblocked ;) | 23:10 |
| nacc | slangasek: how weird, i got it in my schroot, but not in my lxc | 23:11 |
| nacc | slangasek: ok, yeah, that sounds like a plan :) | 23:11 |
| nacc | slangasek: yes, one moment | 23:11 |
| nacc | slangasek: from a fresh clone of the github tree, `git archive --format=tar.gz -o ../symfony_2.7.10.orig.tar.gz v2.7.10` | 23:12 |
| nacc | should do it, I believe | 23:12 |
| nacc | slangasek: ah! I see what it is as to why i'm getting different results :) i told adt to build a fresh .deb on accident, so it wasn't using the archive version | 23:13 |
| nacc | slangasek: yep, reproduced the skips here now | 23:15 |
| slangasek | right :) | 23:15 |
| nacc | that's something :) | 23:15 |
| juliank | flexiondotorg: OK. | 23:17 |
| flexiondotorg | juliank, The irony of SpiderOakOne not working is not lost on me. | 23:17 |
| juliank | I've got no idea what that is | 23:18 |
| flexiondotorg | But I have good contacts there, so I'll reach out to them. | 23:18 |
| flexiondotorg | Zero Knowledge cloud sync. | 23:18 |
| flexiondotorg | So, Dropbox but with encryption. Ahem. | 23:18 |
| nacc | slangasek: so as far as php-defaults going (which will unstick php-mongodb as well), we've got php-imagick working, php-monolog already migrated (so it passed its test with that version too), php-proxy-manager 2.0.0 works, but won't be migrateable until we bump symfony. php-zeta-base is hung up on php-zeta-console-tools, which is failing that test which I think is a php build bug, but am going to need | 23:20 |
| nacc | some time to debug (and is not a key functionality -- and unsure why it's triggering only here if it was something more serious). | 23:20 |
| nacc | Pharaoh_Atem: did you reproduce that php upstream does work w/ that test script, then? | 23:20 |
| slangasek | nacc: symfony debian/licensing/image-checksums.dcf shows some painful duplication of stanzas, src/Symfony/Bundle/WebProfilerBundle/Resources/views/Collector/twig.html.twig listed about a dozen times. Seems like we should just delete the trailing duplicates? | 23:22 |
| Pharaoh_Atem | nacc: http://fpaste.org/342498/43363145/ | 23:22 |
| Pharaoh_Atem | yep | 23:22 |
| Pharaoh_Atem | looks fine | 23:22 |
| slangasek | nacc: oh; except it's with 11 different checksums, what's that about? | 23:23 |
| nacc | slangasek: they are actually multiple images | 23:23 |
| nacc | slangasek: all in one file | 23:23 |
| nacc | slangasek: so each image has its own checksum | 23:23 |
| nacc | it used to be two images | 23:23 |
| slangasek | ok then | 23:23 |
| nacc | and now it's up to 8 or whatever | 23:23 |
| nacc | agreed it's ugly, but if you try to break their syntax, the build fails right away :) | 23:24 |
| nacc | Pharaoh_Atem: any ideas? :) would you be able to help figure out what's going with this? i'm really trying to focus on the packaging stuff and getting as much migrated as possible | 23:24 |
| slangasek | ok, juju deploy fingers, juju deploy ears, juju add-relation la-la-la | 23:25 |
| Pharaoh_Atem | nacc: at the moment, I've got no clue, but I'm starting to poke at it | 23:25 |
| nacc | ondrej said he'd take a look this weekend too, maybe, but i'm not sure of his availability | 23:25 |
| Pharaoh_Atem | I'm going to try to do some looking into it as well | 23:26 |
| Pharaoh_Atem | it's super weird | 23:26 |
| nacc | Pharaoh_Atem: just to be sure, your local ./php invocation is using an .ini that specifies to report errors, right? | 23:27 |
| slangasek | nacc: you've dropped the use of dh-php in debian/rules, but the build-dep is still listed in debian/control; should be purged, I think? also, your debian/rules drops the delta for implementing stage1/nocheck? | 23:27 |
| Pharaoh_Atem | nacc: that's... a good question | 23:27 |
| nacc | slangasek: you're right on the first, for sure | 23:28 |
| nacc | slangasek: and you're right, i should have merged fully, sorry, wnat me to update? | 23:28 |
| slangasek | nacc: yes please | 23:28 |
| nacc | slangasek: ok, give me a few minutes | 23:28 |
| Pharaoh_Atem | nacc: how can I tell | 23:32 |
| Pharaoh_Atem | nacc: the default value for displaying errors is "On" | 23:36 |
| nacc | Pharaoh_Atem: ok, i noticed an odd behavior that if i didn't have anything in /etc/php/7.0/cli/php.ini (e.g. renamed to php.ini.bak), no error was reported | 23:37 |
| nacc | with my system-installed php | 23:37 |
| Pharaoh_Atem | ah | 23:37 |
| Pharaoh_Atem | maybe it's not reading my php.ini | 23:38 |
| nacc | slangasek: new tarball and dsc uploaded | 23:38 |
| slangasek | nacc: got it, thanks. I also see that composer.json lists a require for symfony/polyfill-apcu, which was the bootstrapping question from earlier. The 'requires' here isn't going to break the image build, or leave us with a package that builds but doesn't dtrt at runtime? | 23:43 |
| slangasek | maybe one or more of the 800+ skipped tests | 23:44 |
| slangasek | nacc: ah, and I'm dropping debian/patches/Embed-paragonie-random_compat-into-the-security-comp.patch and debian/patches/cherrypick_5d433cab.patch from the source, in addition to dropping from debian/patches/series | 23:47 |
| slangasek | nacc: and I guess there are no refs to polyfill in the source, so ok | 23:47 |
| nacc | slangasek: i did not see any such issue, but let me check again | 23:50 |
| nacc | slangasek: polyfill is supposed to be for dealing with backporting php features to old version of php by symfony | 23:50 |
| slangasek | nacc: PS I hate symfony's testsuite, it leaves my /tmp full of junk | 23:50 |
| nacc | which we shouldn't need regardless | 23:50 |
| nacc | slangasek: ah sorry, i thought i had done that d/patches, yes, absolutely fine to remote them | 23:51 |
| nacc | slangasek: so the only reference in the source that i could find to polyfill-apcu was src/Symfony/Component/ClassLoader/composer.json, and those tests passed (although it did skip 30 of them, i'll look) | 23:54 |
| nacc | slangasek: but you're right about that, it will not be installable (php-symfony-class-loader) | 23:55 |
| nacc | let me investigate a bit | 23:55 |
| flexiondotorg | juliank, Everything tested. Only hard fails are from Google Talk, Google Music and SpiderOakOne. | 23:55 |
| flexiondotorg | juliank, I'll contact SpiderOak and you contact Google? | 23:56 |
| flexiondotorg | That is of course, just back on the 3rd party repositories I make use of in Software Boutique. | 23:56 |
| nacc | slangasek: ok, so i *think* that we can remove that for our case | 23:58 |
| nacc | slangasek: it's purely there to support symfony on php5 | 23:58 |
| nacc | slangasek: but we have the apcu fucntions from php7 itself, so there's no need to rely on the backported versions | 23:58 |
| juliank | flexiondotorg: Google is contacted | 23:59 |
| juliank | Contact your SpiderOak contacts :) | 23:59 |
| nacc | slangasek: at runtime, the ClassLoader/ApcUniversalClassLoader function dtrt and simply checks if acpu_fetch is defined and throws an error if it's not | 23:59 |
| flexiondotorg | juliank, Wilco. | 23:59 |
| nacc | it will be in our case | 23:59 |
| nacc | slangasek: i wonder if we should tranlate that to just php-apcu, though | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!