/srv/irclogs.ubuntu.com/2016/03/18/#ubuntu-devel.txt

slangaseknacc: it's already built, htree days ago00:00
slangasekbut the autopkgtests failed00:00
naccslangasek: nm, php-symfony-security & php-symfony-security-acl are going to conflict unless we move up to a 2.8 level of symfony00:00
naccslangasek: yeah, the failure is the conflict00:01
slangasekok00:01
naccso that's another reason to move up to 2.8.200:03
naccslangasek: sigh, it's another bootstrap case, i think00:07
naccslangasek: symfony 2.8.2 needs phpy-symfony-security-acl to build, which needs php-symfony-security to build00:08
naccspecifically php-symfony-security >= 2.800:08
smoserhey.00:19
smoserso curtin depends on pyflakes (for make check)00:19
smoserit runs pyflakes both in python2 and python300:19
smoserbut theres a new 'python3-pyflakes'00:19
smoserwhere as before there was just pyflakes that worked for both00:19
smoserwhat should i write as build depends ?00:19
smoserslangasek, ^ i'm sure you can just answer this in 30 seconds.00:20
smoserie, it runs:00:20
smoser python2 -m pyflakes curtin/ tests/unittests/00:20
smoserand00:20
smoser python3 -m pyflakes curtin/ tests/unittests/ tests/vmtests/00:20
smoserwhich now results in00:21
smoser /usr/bin/python3: No module named pyflakes00:21
slangaseksmoser: well, I can guess that you want to build-depend on pyflakes + pyflakes300:21
smoserwhich previously was satisifed by a depends on pyflakes.00:21
smoserbut then i can't build on trusty00:21
smoserwhich ENOPYFLAKES300:21
slangasekok, then you want to build-depend on pyflakes + pyflakes3 | pyflakes (<< 1.1.0-2)00:21
smoserok. the << is what i was missing.00:22
slangasekthe 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 releases00:22
slangaseknacc: so how did Debian break this bootstrap loop?00:27
smoserslangasek, http://paste.ubuntu.com/15411741/00:29
smoserthat one fails on trusty00:29
smoserin sbuild: http://paste.ubuntu.com/15411746/00:29
slangaseksmoser: fails how?00:29
slangasekok00:30
smoserand when i flipped the order (pyflakes < .. | python3-pyflakes) it failed on xenia.00:30
slangasekright00:30
slangaseksmoser: are you using the same build-dep resolver setting in sbuild that launchpad uses?00:30
smoseri do not know00:30
slangasekI don't remember which one this is; and you might already have it right yet sbuild is still being unhelpful00:31
slangasekI would say that your intent is correct there, and you should throw it at lp and see if LP DTRT00:31
smoserwell, i've not changed sbuild locally to my knowledge00:33
smoserand looking at a random other laucnhpad build lo00:33
smoserlog00:33
smoserhttps://launchpadlibrarian.net/248521085/buildlog_ubuntu-xenial-amd64.cloud-init_0.7.7~bzr1182+1186+444~ubuntu16.04.1_BUILDING.txt.gz00:33
smoseri see: Install core build dependencies (apt-based resolver)00:33
smoser(and sbuild says the default resolver is 'apt').00:34
smoserso, it would seem that i should be using the same.00:34
smoserthat said, its past time when i should be looking at this.00:34
smoserthank you for your time, slangasek00:34
smosertommorrow maybe. ideally it'd work both on my system *and* launchpad :)00:34
smoserhm.. wonder if the fact that there is 'pyflakes3' helps or not. probably not.00:36
slangaseknope00:36
infinitysmoser: sbuild in LP uses --resolve-alternatives, which isn't the default.00:38
infinitysmoser: slangasek's suggestion should work if you pass that switch.00:40
naccslangasek: no idea (yet)00:40
hallynhow can i build a debian sid autopkgtest vm for adt-run to use?00:47
hallynis there a tool like adt-buildvm-ubuntu-cloud to do it?00:48
nacchallyn: do you specifically need a vm rather than lxc?00:49
hallynyes00:52
nacchallyn: hrm, i'm not finding anything, but buildvm-ubuntu-cloud can take an arbitrary url; does debian host cloud images similarly?00:53
hallynneed to run the cgmanager autopkgtests , and they requir rebooting the host to enable memory cgroup whic his disabled by default in debian00:53
naccah00:53
hallyni think they do...  not sure whether similar enough though00:53
hallyni haven't seen any google results suggesting anyone has done this...00:53
naccyeah me either :/00:53
hallynleme ping the debian lxc maintainer00:54
nacchallyn: one hit i found mentioned using vmdebootstrap to setup a debian vm00:54
hallynnacc: url?  (for full argument list).00:55
hallynsounds all right, i assume it just creates the qcow2 and runs debootstrap in there00:55
nacchallyn: 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
hallynmaybe /usr/share/autopkgtest/setup-commands/setup-testbed00:57
hallynd'oh00:59
hallynthe adt-virt-qemu manpage tells me what i need :)00:59
hallynthanks nacc00:59
nacchallyn: np, that probably should have been more obvious :)01:00
naccslangasek: 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
slangaseknacc: which version of symfony should I be looking at?01:15
naccslangasek: seems to be the case in all of them01:15
naccslangasek: 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/ afaict01:15
slangaseknacc: IIRC it will; debian/tests/control's "Tests" list typically points to scripts under debian/tests01:16
naccslangasek: hrm, ok, i got differing behavior between running that script manually and what autopkgtest said ... but will keep digging01:17
naccslangasek: fwiw, w/ 2.7.10, i'm down to one runtime failure01:19
naccslangasek: i'm wondering, though, if it's a side effect of relatime and/or overlayfs01:25
naccheh, there are bugfixes to this problem (possibly) that went into the kernel today01:35
naccsigh01:35
naccyep, the tests pass with aufs :)01:40
naccslangasek: 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 not01:41
naccslangasek: 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 FFe01:56
naccslangasek: 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_AtemI really wish that going from symfony 2.7 -> 2.8 didn't break so much crap03:52
Pharaoh_Atembut people do versioning in their packages too strictly and depend on internal behaviors just because php lets them easily do so03:53
=== darkxst_ is now known as darkxst
Mirvpitti: 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 bug05:40
cpaelzergood morning06:11
=== Son_Goku_ is now known as Son_Goku
dholbachgood morning08:24
ginggswhy is it taking so long for launchpad to pick up uploads from debian? it seems to be getting worse and worse08:40
=== sil2100_ is now known as sil2100
Odd_Blokexnox: 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/155826009:22
ubottuLaunchpad bug 1558260 in cloud-images "unable to boot arm64 cloud images due to initrd" [Undecided,New]09:22
apwOdd_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 images09:26
apwOdd_Bloke, and does not the last comment imply exactly that that it has been resolved in later images ?09:26
apwOdd_Bloke, i thought smoser or someone was on the hook for determining when in the process this file cames into existance09:27
apwOdd_Bloke, or are you saying it is you, and now :)09:28
flexiondotorgI noticed the gstreamer 0.10 plugins -bad and -ugly are no longer in the Xenial archive. Is this a permanent change?09:30
Odd_Blokeapw: 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. :p09:31
Odd_BlokeI'll assign it back to Jeff and ask him to confirm that he still sees it with the latest.09:31
apwOdd_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 look09:42
Odd_BlokeYeah, he didn't specify exactly which image he was using.09:42
apwOdd_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 link09:45
apwOdd_Bloke, and we do need to find out where that is coming from and why09:45
apwOdd_Bloke, it is definaly not right, and *puts finger in air* it feels like it is coming from a curtain-y level of the build09:45
cjwatsonginggs: Because Debian just changed a bunch of stuff and we're trying to keep up10:59
cjwatsonginggs: https://lists.debian.org/debian-devel-announce/2016/03/msg00006.html11:00
ginggscjwatson: ah, thanks11:02
dokosmb, "Revert back to bind against bind9 export libraries". did you do that for other rdeps too?11:59
smbdoko, no only isc-dhcp12:00
=== _salem is now known as salem_
dokolamont, why does libbind-export-dev ship a libbind9.so (without -export)?12:11
infinitydoko: Because he oopsed.  Already under investigation.12:11
dokoinfinity, let me do that, so you'll have time for glibc ...12:12
infinitydoko: 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
infinitydoko: Also, the udeb deps are wrong.12:13
infinitydoko: Enjoy.12:13
dokoinfinity, udeb's are already fixed12:13
infinityYay.12:14
dokook, testing a fix for the symlink issue12:21
infinitydoko: 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
dokosure12:33
infinitydoko: (Which may already be true, but I'm not holding my breath after seeing the result of the current upload)12:33
lamontdoko: because of bug.12:42
lamontdoko: ta12:43
lamontdoko: holler when you have something, and I'll add it to some other cleanup and upload it12:45
lamont(git tree is forward from P4-1 because of some patch cleanup and submmission upstream)12:46
lamontand I guess I'll be merging12:48
smoserhey. 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
smoserclearly 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
smoserslangasek suggested depending on 'python3-pyflakes | pyflakes (<< 1.1.0-2)' and on pyflakes. (full debian/control http://paste.ubuntu.com/15411741/).13:05
smoserbut that fails with http://paste.ubuntu.com/15411746/13:05
smoserany thoughts ? do i just have to make two control files now or disable checks.13:07
rbasaksmoser: you want sbuild --resolve-alternatives13:08
rbasak(I think)13:08
smoserrbasak, well, maybe. but i'd like for it to work on launchpad too13:08
rbasaksmoser: it should Just Work on the buildds I believe.13:08
rbasaksrc:php5 had the same need and the buildds were fine.13:09
smoseralright. i'll give it a shot.13:10
cjwatsonYes, Launchpad uses --resolve-alternatives.13:10
cjwatson(as Adam said yesterday)13:10
smosercjwatson, bah. well, i missed that.13:16
smoserthank you, rbasak it seems to work.13:16
mterrycjwatson: do I recall correctly that we added dbgsym packages to PPAs?13:27
mterryaha.   main/debug13:29
mterryThanks!13:29
* mterry should update some askubuntu questions13:30
dokosmb, lamont: -1ubuntu2 should fix the known issues. please re-upload isc-dhcp once this is built everywhere13:57
tjaaltondoes apt use repos that don't have the new DEP-11 metadata?13:58
smblamont, Can I leave that ^ to you as I cannot upload much (not isc-dhcp anyways)13:59
tjaaltonsilly question really..13:59
tjaaltonof course it does, like ppas.. just that apt-mirror seems somewhat broken and doesn't sync/clean stuff like before14:00
lamontdoko: ok14:00
lamontsmb: will do14:00
smbok cheers14:00
lamontdoko: and thanks, I'll get that together and create -2 for e'ryone14:00
cjwatsonmterry: 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
mterrycjwatson: oh nice ok, thanks14: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
tjaaltonok so there's an apt-mirror bug 1550852, with patches from my ex-coworker :) (having to maintain the mirror I set up..)14:15
ubottubug 1550852 in apt-mirror (Ubuntu) "apt-mirror does not reflect dep11/Components-* and dep11/icons-*" [Medium,Confirmed] https://launchpad.net/bugs/155085214:15
tjaaltonbest way to solve issues is to think out loud, publicly..14:16
jtaylordoko: interesting approach with pyzmq ... I'd rather see the broken zmq update reverted than tests disabled14:20
dokojtaylor, 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
jtayloron amd64 and i38614:22
jtaylorthey succeed there on buildds too14:22
jtaylorits the others that are the problem14:22
dokono, they failed on the buildds14:23
jtayloron debian they work14:23
doko... just on x8614:25
dokofeel free to revert14:25
jtaylorexactly14:25
jtaylorzmq is somehow broken on all other arches14:26
jtaylorzmqs own testsuite just sucks14:26
jtaylorhow did zmq even get into xenial?14:27
jtaylorit went into unstable post feature freeze14:27
dokoduring the ruby2.2 removal14:28
sinzuixnox: 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 s390x14:28
infinitysinzui: 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
xnoxsinzui, 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
infinitysinzui: I lost context long ago on this.  Is juju-mongodb/2.4 going away, or will that *also* be in xenial?14:32
xnoxsinzui, 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
sinzuixnox: I did and it didn't apply cleanly because the package has our ppc64el and arm64 patches on it14:32
xnoxright14:32
xnoxsinzui, 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
infinityxnox: juju-core has to use the old mongo.14:33
xnoxbummer14:33
infinityxnox: That's the point of the crazy transitional packages.14:33
xnoxsigh....14:34
sinzuiinfinity: juju-mongodb (2.4) will ne demoted to universe. people upgrading to xenial will still have a juju-core (1.25) to maintain existing deployments14:34
infinityBut 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 s390x14:34
xnoxinfinity, i have customers using juju-core today =) so we can't drop it, before juju2 lands =)14:34
sinzuixnox: me too. The juju release team want juju2 beta3 in xenial.14:34
infinitysinzui: 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
sinzuiinfinity: understood14:35
xnox=/14:35
xnoxack14:35
infinitysinzui: Has anyone actually talked to the release team about juju2?14:36
xnoxsinzui, so don't care about s390x on mongodb2.6. Any little people who have been using old juju on s390x, can rebootstrap.14:36
infinitysinzui: 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
xnoxit's all technically non-supported stuff.14:36
xnoxinfinity, is pitti release team at all?14:36
seb128xnox, https://launchpad.net/~ubuntu-release/+members14:37
sinzuithat membership is surprising14:37
xnoxinfinity, so pitti did talk to a few people about all the mongos and jujus14:38
* xnox ponder mongi / juji ?14:38
infinityxnox: Yes, but not specific timelines.  Just the packaging bits.14:38
infinitysinzui: Some of those members need to be culled.14:38
sinzuiinfinity: 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-core14:39
sinzuiinfinity: xnox the Juju team do want to propose the juju2 beta3 next week.14:40
xnoxsinzui, 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
sinzuixnox: I see cherylj did https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/154591314:42
ubottuLaunchpad bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,New]14:42
cjwatsonDoes 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 xenial14:42
sinzuicjwatson: 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 work14:44
rbasakxnox, 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
cjwatsonsinzui: filed https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/155916914:53
ubottuLaunchpad bug 1559169 in lxc (Ubuntu) "containers no longer start after upgrade to 2.0.0~rc11-0ubuntu1" [Undecided,New]14:53
infinityrbasak: 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
sinzuithank you cjwatson14:54
xnoxrbasak, hm, it is new package.14:55
rbasakinfinity: 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
infinityrbasak: Quite.14:56
infinityrbasak: 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
infinityrbasak: So, people should think hard about what they'll actually be landing and when and if it's something they want their name on. :P14:56
infinitys/rush if/rush is/14:57
jamespagedoko, 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
rbasakIf releasing at the same time as 16.04 is really important, then the deadline should be considered feature freeze.14:57
infinityrbasak: Don't disagree.14:57
rbasakIf 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
dokojamespage, please steal everything you like ...14:58
dokojamespage, ohh, that even was an unmerged packages by you for two years ... I had just a no-change upload15:02
jamespagedoko, nope not me15:03
jamespagebut I'll merge it anyways as it unblocks stuff...15:04
dokoahh, jtaylor ... misread15:04
jtaylorunison is a mess, it should probably just be removed15:06
jtaylorthey don't seem to have an compatiblity so whatever is in the archvie stops working on the next upstream version15:06
rbasaksinzui: 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
rbasaksinzui: http://dep.debian.net/deps/dep3/15:17
rbasaksinzui: also, please update the headers for any patch you modify (that isn't just a refresh to unfuzz)15:17
rbasakinfinity: 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
infinityrbasak: 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
rbasakOK15:20
rbasakReviewing this is fun. I don't have anything to base a diff from :-/15:20
rbasak(well, 2.6)15:20
infinityrbasak: (And if that plan involves "make the security team deal with it", they should be asked too)15:20
rbasakThat's an open question at the moment. Juju management are looking into it.15:21
dokoapw, infinity: autopkgtest for linux 4.4.0-14.30: amd64: Pass, armhf: Pass, i386: Pass, ppc64el: Regression â™» , s390x: Pass15:27
doko (triggered by gcc-5). is this a real issue, or can we ignore it?15:27
rbasaksinzui: have you checked to see if there are any updates needed to debian/copyright (for both juju-mongodbs)?15:29
sinzuirbasak: oh, have I...I removed an entry form the 3.2 because the package was removed from 3rd party15:29
sinzuirbasak: I hestitantly offer to go the full dep-515:31
rbasaksinzui: 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
rbasakThat means pitti in this case I think?15:32
infinitydoko: Gonna give it a kick to retry.  But it looks like it was busted tests (since fixed), not GCC's fault.15:32
sinzuiunderstood rbasak15:32
rbasaksinzui: dep3 headers I do want though. It's difficult to understand what I'm reviewing without them.15:33
sinzuirbasak: yeah, I have that open now15:33
rbasaksinzui: basically I want to know where each patch came from and where I can find upstreaming status.15:34
sinzuirbasak: okay, understood15:34
rbasak(because if we don't track that, packaging inevitably becomes an unmaintainable mess)15:35
rbasakThanks :)15:35
smblamont, ugh that bind9 saga isn't a happy one15:50
dokosmb, what's still wrong?15:50
smblamont, now its afaict named-checkzone which went into bind9 and bind9utils15:50
dokosmb, 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 bind915:53
lamontsmb: gar15:54
lamontdoko: likely so15:54
* lamont stares at the build-deps in -1ubuntu2, and wonders if that was really necessary15:54
lamontdeps actually15:55
dokolamont, I was checked for missing libs, because I found one export lib missing in the dh_makeshlibs call in debian/rules15:58
lamontmakes sense15:59
lamontI decided I didn't care enough to change it back15:59
apwdoko, 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 closer15:59
dokoapw, in fi ni ty already gave it back16:00
apwdoko, ahh good enough, we shall see when it completes there16:00
lamontdoko: hoping you have time to do that switch to debian/tmp?  +1 from me on the concept16:01
xnoxpitti, can i trick you into reviewing https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1551952 or are you off already?16:01
ubottuLaunchpad bug 1551952 in multipath-tools (Ubuntu) "FFE: Please merge multipath-tools 0.5.0+git1.656f8865 from Debian unstable " [Undecided,New]16:01
dokolamont, not today; I'll look at it tomorrow16:06
lamontok16:08
lamontsmb: feedback from isc is that we likely just broke signals for all of the bind tools when we fixed dhcp...16:08
lamontso I'll be reworking that diff a bit16:08
smblamont, 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_ctxstart16:10
lamontah, could be16:11
naccslangasek: filed LP: #1558848, to get symfony through, let me know what you think16:11
* lamont was just parroting the reply to the patch from isc16:11
ubottuLaunchpad bug 1558848 in symfony (Ubuntu) "symfony: failing autopkgtests" [Undecided,New] https://launchpad.net/bugs/155884816:11
smblamont, 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
smblamont, 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
lamontsmb: likely the way I'll go16:22
lamontbut it'll be post-sunday16:22
xnoxdoko, can we drop gcc-3.3 and hence libstdc++-5.0 from xenial? =)16:25
smblamont, 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 rushing16:28
* lamont plans to upload iscdhcp shortly, just waiting on the publisher16:29
lamontthe other stuff is just "bind9 bugs"16:29
lamontI mean, we already have the potential defect there in P4-116:29
smblamont, yeah but that never went out16:30
lamontit'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
lamonthrm16:31
lamontthis is sad making16:31
lamontit may be my today thing after all16:31
smblamont, none of the recent bind9 uploads I mean. The first one because of dependencies and the other becuase of the adt failures16:31
lamontsmb: ack16:32
lamontwhich is actually cool, beacuse I don't need Replaces. :D16:32
dokoxnox, can you convince Debian first to drop it?16:33
dokoit just builds one lib16:33
smblamont, Also you kinda do not have to wait to upload isc-dhcp because there is no reason to16:34
lamontsmb: it was more of "waiting for 1ubuntu2 to really really be in the archive, but taht was 2 hours ago..16:35
infinitysmb: "no reason to"?16:35
smblamont, ERm yes, that s what I try to say16:35
smblamont, It wont go there because it annoys britney (I mean ikiwiki-hosting test regression)16:36
lamontinfinity: no longer a reason to wait16:36
smbinfinity, Right that was what I meant16:36
infinitylamont: Right, I misread as "we don't need to wait" not "the wait is over".16:36
* lamont got distracted16:36
lamontand then went "why do I even have this window open"16:38
smbHeh yeah... I just happened to go back there and refresh and then decided that red is not my favourite colour in there16:41
smblamont, Or rather I think I did not mean what you thought I meant...16:45
lamontright16:46
smblamont, I meant there is no reason to do the upload...16:46
naccslangasek: 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
ubottuLaunchpad bug 1549942 in ImageMagick "php-imagick failing autopkgtests" [Unknown,New] https://launchpad.net/bugs/154994216:46
naccslangasek: apologies, I don't know what I had messed up before in my test setup16:46
smblamont, Though it probably does not matter if isc-dhcp now links dynamically it will remains stuck in proposed together with the bind916:48
lamontack16:57
naccslangasek: i believe we need a rebuild of php-zend-code so that it pulls in php-common rather than php5-common17:13
naccslangasek: but i believe why it's not migrating is symfony17:13
naccslangasek: (via php-proxy-manager)17:13
naccslangasek: 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 eventually17:26
naccslangasek: 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
naccslangasek: hrm, it's a php.ini issue, possibly17:54
Pharaoh_Atemnacc: what do I need to do to stop being moderated on ubuntu-devel?18:27
slangaseknacc: 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/1218:27
ubottuLaunchpad bug 1558848 in symfony (Ubuntu) "symfony: failing autopkgtests" [Undecided,New]18:27
slangasekPharaoh_Atem: become an Ubuntu Developer ;)18:27
naccslangasek: yep, working through them now, thanks!18:28
Pharaoh_Atemslangasek: is it anywhere near as hard as becoming a Debian one?18:28
slangaseknacc: 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 here18:29
naccslangasek: ah ok, i wasn't sure, since i hadn't run their script to mangle the name.18:29
naccslangasek: also, i just realized i still need to fix the licenses!18:30
naccslangasek: sorry, let me try to get that done now too18:30
slangasekPharaoh_Atem: it's somewhat less process-heavy but involves a fair bit of demonstrating active involvement in the project, plus waiting in queues18:30
* Pharaoh_Atem sighs18:30
slangasekPharaoh_Atem: being unmoderated on ubuntu-devel is probably not a good argument for becoming an Ubuntu Developer :-)18:30
naccPharaoh_Atem: would you be able to test something for me on php7.0 in non-ubuntu installations?18:30
Pharaoh_Atemnacc: yes18:30
slangaseknacc: ok shelving symfony until you re-ping me18:30
* Pharaoh_Atem is actually updating his testing atm18:30
Pharaoh_Atem*test stuff18:31
naccPharaoh_Atem: http://paste.ubuntu.com/15416746/18:31
naccslangasek: yep, thanks18:31
naccslangasek: php-monolog v2 debdiff posted, thanks18:32
slangaseknacc: you tested that autopkgtest works?18:37
naccslangasek: yep18:41
slangaseknacc: ok, uploading18:42
Pharaoh_Atemnacc: you'd like me to run this as a CLI app or web script?18:43
naccPharaoh_Atem: cli, please18:43
flexiondotorgI missed the details, but am I right in saying syncing with Debian is not currently possible?18:43
Pharaoh_Atemokay18:43
naccslangasek: oh, fwiw, i didn't alter upstream in this case, as i made an archive from github18:48
naccslangasek: 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_Atemafaik, it wouldn't be dfsg because you're not using the debian one, you've made your own18:49
slangasekflexiondotorg: 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 FeatureFreeze18:49
slangaseknacc: I would still say +dfsg, if you're deleting things that are part of the upstream tarball18:50
flexiondotorgslangasek, Yep, I understand that. My question was not clear enough.18:50
naccslangasek: the orig.tar.gz has no deletions; it was a `git clone`, then `git archive ... v2.7.10` from upstream symfony18:51
flexiondotorgslangasek, I do the vast majority of the Ubuntu MATE work in the Debian community as part of the pkg-mate team.18:51
slangaseknacc: ok, fine with me then18:51
flexiondotorgI have several syncrequests filed, bug fixes.18:51
flexiondotorgThose packages are not available in LP.18:52
flexiondotorgslangasek, For example - https://launchpad.net/debian/+source/mate-dock-applet18:52
flexiondotorg0.69 in LP and 0.70 in Debian. The Ubuntu dev who looked at my syncerequests was unable to process them.18:53
slangasekflexiondotorg: 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 this18:53
* Pharaoh_Atem listens to Legend of Zelda music while system updates complete18:53
slangasekpackages that were in Debian prior to Wednesday-ish are syncable, but new uploads are currently not visible18:54
flexiondotorgslangasek, Thanks. That was the deatil I was missing.18:54
flexiondotorgThanks for explaining. I heard something had changed but wasn't aware what exactly.18:54
naccslangasek: 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
naccslangasek: i believe php-psr-log requires the php-opencloud update, afaict19:08
Pharaoh_Atemnacc: http://fpaste.org/342352/83283271/19:12
naccPharaoh_Atem: sigh, those are bugs too :)19:12
Pharaoh_Atemdamn it19:12
naccPharaoh_Atem: so the thing is, if you build upstream PHP 7.0.419:12
naccPharaoh_Atem: if you wouldn't mind trying that19:13
naccPharaoh_Atem: it works fine19:13
Pharaoh_AtemI'll give it a go, one sec19:13
naccPharaoh_Atem: or just passing ./configure w/o any options19:13
Pharaoh_Atemthat's... bizarre19:13
naccagreed.19:13
Pharaoh_Atemnacc: did you get the upstream php 7.0.4 from GitHub or php.net?19:14
naccPharaoh_Atem: github19:14
naccPharaoh_Atem: is there a specific difference?19:15
Pharaoh_AtemI hope not19:15
* Pharaoh_Atem is about to check19:15
nacc:)19:15
Pharaoh_Atembut... knowing them...19:15
Pharaoh_AtemI hate people so much19:17
naccPharaoh_Atem: did you find a difference?19:18
Pharaoh_Atemnacc: http://paste.fedoraproject.org/342361/83287411/19:19
naccPharaoh_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 yet19:19
Pharaoh_AtemI'm not if these are really diffs or not19:20
naccyeah the textual diff is just lexer output, iiuc19:20
naccthe difference in some files being present in Zend/ is a bit worrisome19:20
=== salem_ is now known as _salem
naccbut those might be generated files? (i see configure is also only in 7.0.4)19:21
Pharaoh_Atemnacc: yeah, I don't know19:22
Pharaoh_Atemnacc: I'm going to compile php 7.0.4 from php.net sources19:27
naccPharaoh_Atem: thanks, that would be a good check; i'm bisecting through our disable parameters :/19:27
Pharaoh_Atemfor reference, this is what remi sets it up to be: https://github.com/remicollet/remirepo/blob/master/scl-php70/php/php.spec#L111519:29
Pharaoh_Atemand here's what %configure expands to: https://github.com/remicollet/remirepo/blob/master/scl-php70/php/php.spec#L111519:30
Pharaoh_Atemerr19:30
Pharaoh_Atemhttp://paste.fedoraproject.org/342373/45832942/19:30
Pharaoh_Atemnacc: so I'm building php now19:32
naccPharaoh_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_Atemrunning make test atm19:44
Pharaoh_Atemnacc: welp19:50
Pharaoh_Atemnacc: http://paste.fedoraproject.org/342382/14583307/ and http://paste.fedoraproject.org/342381/33065414/19:51
Pharaoh_Atemnacc: I don't know what to make of this19:53
cjwatsonslangasek,flexiondotorg: maybe I should send mail explaining this, since it'll take another few days to sort out21:02
lamontinfinity: and P4-3 uploaded to really work this time.21:06
infinitylamont: Do we need yet another dhcp upload after this bind, or was the last one correct?21:17
infinitylamont: Hrm, deps on the previous upload look plausible at least.21:18
* lamont checked amd64, and it definitely built with -1ubuntu221:19
lamontthe only issue with -1ubuntu2 was that it delivered, uh, everything not in bind9 as part of bind9.21:19
lamontor at least enough so to make it unusable21:19
infinityOops. :)21:20
lamontI didn't do that21:20
lamontbut I fixed it in -3, by switching to install into debian/tmp and sort things from there21:20
lamontcomplete with --fail-missing on dh_install21:20
lamonta 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...hrm21:21
lamontinfinity: as long as all the isc-dhcp-servers Depend on multiple -export libs, they're shiny21:22
infinitylamont: Right, that's what I confirmed on amd64.21:22
infinitylamont: I might poke the other 6 quickly out of paranoia.21:22
lamontinfinity: I would lovethat21:24
=== nobuto_ is now known as nobuto
flexiondotorgcjwatson, Do you think it likely 16.04 final beta will be delayed due to the Debian archive changes?21:33
flexiondotorgI see that 3rd party repositories are not updating on 16.04 daily due to weak digests etc too.21:33
cjwatsonflexiondotorg: No21:34
flexiondotorgOK21:34
flexiondotorgThanks.21:34
cjwatsonflexiondotorg: 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 fatal21:35
cjwatsonflexiondotorg: And there's no reason to expect any particular timeline for third-party repositories to stop sucking, other than PPAs21:35
cjwatsonflexiondotorg: 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-like21:36
flexiondotorgSo it will be required that 3rd party repositories need to adapt to thi new structure.21:36
cjwatsonflexiondotorg: They need to upgrade their signatures, yes21:37
cjwatsonflexiondotorg: I wouldn't call it a structural change21:37
cjwatsonflexiondotorg: In some cases they may have to add stronger checksums to their index files21:37
flexiondotorgSo, no one using the google-chrome repostiory will get upgrades until Google update their sigs?21:37
cjwatsonflexiondotorg: Right, but we're told that will happen soon21:38
cjwatsonflexiondotorg: Also I think it only affects upgrades *from that repository*, as long as you don't mind apt-get update exiting non-zero21:38
cjwatsonSo that seems annoying but not very fatal, and there's every incentive for third-party repository maintainers to sort stuff out21:39
juliankflexiondotorg: Chrome was fixed today21:40
juliankSo, it only warns about the weak signature now, but the files themselves contain the SHA256 values needed to still allow it.21:41
juliankI'd expect the warning to be fixed in the next weeks or months as well21:41
cjwatsonThe Google talkplugin repository has the same problem21:42
cjwatsonHopefully they have common repository generation code21:42
flexiondotorgWell, the non-zero exit code breaks aptdaemon.21:44
daxwhile Google's fixing stuff, adding arch=amd64 to their repository-adding script would be helpful21:44
dax(if that didn't happen already, I didn't look recently)21:45
flexiondotorgcjwatson, I will contact some 3rd party repo maintainers and make them aware.21:46
flexiondotorgcjwatson, So, will all repos need to adopt SHA256 and xz compression? Is that enough?21:47
flexiondotorgjuliank, Chrome has not been update. Nor Steam.21:49
flexiondotorglso affected, Spotify, Opera, Vivaldi, Insync.21:50
Unit193And apt 1.2.8 makes the warnings look less like errors, too.21:50
Pharaoh_Atemcrap21:52
Pharaoh_Atemwhat the heck happened?21:52
Pharaoh_Atemdid this sha256 and xz only stuff just take effect?21:52
juliankflexiondotorg: Seriously. It has been updated. about 10 hours ago21:52
juliankIt now only prints one warning instead of 221:52
juliankand this warning is really a warning now, not an error.21:53
juliankThey actually fixed this yesterday already, but only regenerated their archive today.21:53
juliankUnit193: APT 1.2.8 will make errors look like errors to distinguish them from warnings (both were listed as warnings previously)21:54
Unit193juliank: Ah, OK.  Noticed you fixed it anyway.  Nice job!21:55
juliankcjwatson: 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 yet21:55
juliankflexiondotorg: Steam and Opera work just fine21:55
juliankThey just print a warning, but continue21:56
juliankVivaldi, 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 works21:56
juliankWith the talkplugin, I think somebody at google would have to run an update manually, as that's practically dead.21:57
juliankVivaldi is OK21:59
juliankInsync is OK too22:00
juliankThey have until January to fix these warnings, I think that's fair.22:00
juliankThey literally just have to add two arguments to their gpg invocation22:01
juliank--digest-algo SHA512 to be precise22:02
=== _salem is now known as salem_
juliankflexiondotorg: 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
Unit193juliank: You were looking for people to report broken repos, did you have a page listing them already?22:07
juliankApart from the temporary breakage at Google, there is no real hard breakage, only the soft warnings.22:07
juliankI think I'll start a wiki page for tracking this22:08
flexiondotorgjuliank, Confirm Chrome works. Google Music Manager cause aptdaemon to fail.22:10
flexiondotorgjuliank, Google Talk plugin causes aptdaemon to fail.22:12
juliankUnit193: flexiondotorg: Listed on https://wiki.debian.org/Teams/Apt/Sha1Removal22:12
cjwatsonflexiondotorg: It's not necessary to adopt xz compression.22:12
flexiondotorgcjwatson, So just SHA256 then?22:13
cjwatsonflexiondotorg: 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
juliankI think almost everyone expect Google only has to pass --digest-algo SHA51222:13
juliankto gpg22:13
cjwatsonflexiondotorg: Something stronger than the broken SHA-1, yes.22:13
juliank(or 256)22:13
cjwatsonOr 384, which was the suggestion in one of the LP bugs/MPs22:14
juliankGoogle was incredibly beyond things22:14
juliankcjwatson: APT only support 256 and 51222:14
cjwatsonjuliank: Even for digests on signatures?  That's a curious limitation22:14
juliankAh, no, not on signatures22:15
juliankI allowed them on signatures :D22:15
juliankcjwatson: The gz removal was sort of my fault too...22:16
cjwatsonThere 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 that22:16
cjwatsonWe haven't quite decided22:16
cjwatsonjuliank: How so?22:16
juliankcjwatson: I asked Ganneff if we could try removing MD5 and SHA1, and he did that and .gz :)22:17
cjwatsonHeh22:17
cjwatsonWell, like I say, it's been a bit of a hassle but I don't actually think it's wrong22:17
juliankBut 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 work22:18
cjwatsonThe code we've run into does :)22:18
cjwatsonAt least some of it22:18
cjwatsonYeah, debmirror and gina both want all suites they're operating on to work22:19
cjwatsonIt's possible we might not have noticed the breakage otherwise, so whatever22:20
juliankcjwatson: 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
juliankoops22:22
juliankflexiondotorg: ^22:22
juliankI 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
juliankflexiondotorg: 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 do22:24
Unit193vbox's repo should likely also be on that page.22:24
juliankUnit193: I just added more details, feel free to add vbox22:27
juliankI think it's a bit rough now, but it should quickly get better.22:34
flexiondotorgjuliank, I have a list of 3rd party repos. I'll add them to the Sha1Removal in an hour or two.22:35
juliankgreat :)22:36
flexiondotorgI'm using the aptdaemon.gtk3widget22:36
flexiondotorgI'll get details of what it causing the exact issue.22:37
flexiondotorgEssentially, the install fail because the package can be found. Which suggest the repo update didn't complete.22:37
flexiondotorgjuliank, This is what I know of.22:49
flexiondotorghttp://paste.ubuntu.com/15419170/22:49
flexiondotorgSome of those are in the OBS.22:49
flexiondotorgjuliank, 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 failure23:00
naccslangasek: can you tell why php-imagick (per autopkgtest) is skipping all the tests on amd64, but not on i386 (e.g.)23:01
slangaseknacc: url?23:01
naccslangasek: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/php-imagick/20160317_113406@/log.gz23:02
naccslangasek: it seems to ahve started with that one, which was triggered by PHP 7.0.4-5ubuntu223:02
nacchttp://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/amd64/23:02
slangasek251 skipped tests> lol23:02
slangasekno, no idea23:02
naccslangasek: running it on my machine, it runs them all23:02
naccslangasek: so i'm not sure what's happening?23:03
naccand it's weird that it ran them on i38623:03
slangaseknacc: when you test are you using an adt test runner that gives you a clean env?23:03
naccslangasek: yeah, i am using adt-virt-lxc23:03
naccwith a freshly made adt-xenial from earlier today23:04
slangaseknacc: well, imagick-3.4.0RC6/tests/skipif.inc tells it to skip all tests if the imagick extension isn't loaded23:04
slangaseke.g.23:04
slangasekWARNING: Module imagick ini file doesn't exist under /etc/php/7.0/mods-available23:05
slangasekand that's listed at install time23:05
naccslangasek: but the d/t/control says to depend on php-imagick23:05
slangasekso there you go23:05
nacchrm23:05
slangasekseems to be a misbuilt package, php-imagick (3.4.0~rc6-1ubuntu2)23:05
slangasekwas there a race between the upload of this package and the upload of some of the package helper fixes23:06
slangasek?23:06
slangaseknacc: well, also, those are all tests of the old version of php-imagick in xenial; not of the version in xenial-proposed23:07
naccslangasek: yeah, could be ... except for the same package version (only using release pocket), i don't get that error?23:07
naccso i guess it could be race, but that run was from a few hours ago when imagemagick went in23:08
slangasekyes, but those tests are all still testing the released version of php-imagick, not the one in -proposed23:08
naccslangasek: right, so am I23:08
slangasekso whatever that -1ubuntu2 binary was built with, maybe it's broken23:08
flexiondotorgjuliank, SpiderOakOne fails.23:08
naccslangasek: my adt runs say both release and proposed are working right now :)23:08
nacc"working" => passing tests23:09
slangaseknacc: I can definitely reproduce that message here:23:09
slangasekSetting up php-imagick (3.4.0~rc6-1ubuntu2) ...23:09
slangasekWARNING: Module imagick ini file doesn't exist under /etc/php/7.0/mods-available23:09
slangaseknacc: 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 contents23:09
slangasek(against upstream)23:10
slangasek(one of those sponsorship nit-picky things)23:10
slangasekand I definitely get that warning with php-imagick from release, and definitely don't get it with php-imagick from -proposed23:10
slangasekso I'll solve this problem by getting the one in -proposed unblocked ;)23:10
naccslangasek: how weird, i got it in my schroot, but not in my lxc23:11
naccslangasek: ok, yeah, that sounds like a plan :)23:11
naccslangasek: yes, one moment23:11
naccslangasek: 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
naccshould do it, I believe23:12
naccslangasek: 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 version23:13
naccslangasek: yep, reproduced the skips here now23:15
slangasekright :)23:15
naccthat's something :)23:15
juliankflexiondotorg: OK.23:17
flexiondotorgjuliank, The irony of SpiderOakOne not working is not lost on me.23:17
juliankI've got no idea what that is23:18
flexiondotorgBut I have good contacts there, so I'll reach out to them.23:18
flexiondotorgZero Knowledge cloud sync.23:18
flexiondotorgSo, Dropbox but with encryption. Ahem.23:18
naccslangasek: 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 need23:20
naccsome 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
naccPharaoh_Atem: did you reproduce that php upstream does work w/ that test script, then?23:20
slangaseknacc: 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_Atemnacc: http://fpaste.org/342498/43363145/23:22
Pharaoh_Atemyep23:22
Pharaoh_Atemlooks fine23:22
slangaseknacc: oh; except it's with 11 different checksums, what's that about?23:23
naccslangasek: they are actually multiple images23:23
naccslangasek: all in one file23:23
naccslangasek: so each image has its own checksum23:23
naccit used to be two images23:23
slangasekok then23:23
naccand now it's up to 8 or whatever23:23
naccagreed it's ugly, but if you try to break their syntax, the build fails right away :)23:24
naccPharaoh_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 possible23:24
slangasekok, juju deploy fingers, juju deploy ears, juju add-relation la-la-la23:25
Pharaoh_Atemnacc: at the moment, I've got no clue, but I'm starting to poke at it23:25
naccondrej said he'd take a look this weekend too, maybe, but i'm not sure of his availability23:25
Pharaoh_AtemI'm going to try to do some looking into it as well23:26
Pharaoh_Atemit's super weird23:26
naccPharaoh_Atem: just to be sure, your local ./php invocation is using an .ini that specifies to report errors, right?23:27
slangaseknacc: 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_Atemnacc: that's... a good question23:27
naccslangasek: you're right on the first, for sure23:28
naccslangasek: and you're right, i should have merged fully, sorry, wnat me to update?23:28
slangaseknacc: yes please23:28
naccslangasek: ok, give me a few minutes23:28
Pharaoh_Atemnacc: how can I tell23:32
Pharaoh_Atemnacc: the default value for displaying errors is "On"23:36
naccPharaoh_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 reported23:37
naccwith my system-installed php23:37
Pharaoh_Atemah23:37
Pharaoh_Atemmaybe it's not reading my php.ini23:38
naccslangasek: new tarball and dsc uploaded23:38
slangaseknacc: 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
slangasekmaybe one or more of the 800+ skipped tests23:44
slangaseknacc: 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/series23:47
slangaseknacc: and I guess there are no refs to polyfill in the source, so ok23:47
naccslangasek: i did not see any such issue, but let me check again23:50
naccslangasek: polyfill is supposed to be for dealing with backporting php features to old version of php by symfony23:50
slangaseknacc: PS I hate symfony's testsuite, it leaves my /tmp full of junk23:50
naccwhich we shouldn't need regardless23:50
naccslangasek: ah sorry, i thought i had done that d/patches, yes, absolutely fine to remote them23:51
naccslangasek: 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
naccslangasek: but you're right about that, it will not be installable (php-symfony-class-loader)23:55
nacclet me investigate a bit23:55
flexiondotorgjuliank, Everything tested. Only hard fails are from Google Talk, Google Music and SpiderOakOne.23:55
flexiondotorgjuliank, I'll contact SpiderOak and you contact Google?23:56
flexiondotorgThat is of course, just back on the 3rd party repositories I make use of in Software Boutique.23:56
naccslangasek: ok, so i *think* that we can remove that for our case23:58
naccslangasek: it's purely there to support symfony on php523:58
naccslangasek: but we have the apcu fucntions from php7 itself, so there's no need to rely on the backported versions23:58
juliankflexiondotorg: Google is contacted23:59
juliankContact your SpiderOak contacts :)23:59
naccslangasek: at runtime, the ClassLoader/ApcUniversalClassLoader function dtrt and simply checks if acpu_fetch is defined and throws an error if it's not23:59
flexiondotorgjuliank, Wilco.23:59
naccit will be in our case23:59
naccslangasek: i wonder if we should tranlate that to just php-apcu, though23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!