[00:00] nacc: it's already built, htree days ago [00:00] but the autopkgtests failed [00:00] 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:01] slangasek: yeah, the failure is the conflict [00:01] ok [00:03] so that's another reason to move up to 2.8.2 [00:07] slangasek: sigh, it's another bootstrap case, i think [00:08] slangasek: symfony 2.8.2 needs phpy-symfony-security-acl to build, which needs php-symfony-security to build [00:08] specifically php-symfony-security >= 2.8 [00:19] hey. [00:19] so curtin depends on pyflakes (for make check) [00:19] it runs pyflakes both in python2 and python3 [00:19] but theres a new 'python3-pyflakes' [00:19] where as before there was just pyflakes that worked for both [00:19] what should i write as build depends ? [00:20] slangasek, ^ i'm sure you can just answer this in 30 seconds. [00:20] ie, it runs: [00:20] python2 -m pyflakes curtin/ tests/unittests/ [00:20] and [00:20] python3 -m pyflakes curtin/ tests/unittests/ tests/vmtests/ [00:21] which now results in [00:21] /usr/bin/python3: No module named pyflakes [00:21] smoser: well, I can guess that you want to build-depend on pyflakes + pyflakes3 [00:21] which previously was satisifed by a depends on pyflakes. [00:21] but then i can't build on trusty [00:21] which ENOPYFLAKES3 [00:21] ok, then you want to build-depend on pyflakes + pyflakes3 | pyflakes (<< 1.1.0-2) [00:22] ok. the << is what i was missing. [00:22] 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:27] nacc: so how did Debian break this bootstrap loop? [00:29] slangasek, http://paste.ubuntu.com/15411741/ [00:29] that one fails on trusty [00:29] in sbuild: http://paste.ubuntu.com/15411746/ [00:29] smoser: fails how? [00:30] ok [00:30] and when i flipped the order (pyflakes < .. | python3-pyflakes) it failed on xenia. [00:30] right [00:30] smoser: are you using the same build-dep resolver setting in sbuild that launchpad uses? [00:30] i do not know [00:31] I don't remember which one this is; and you might already have it right yet sbuild is still being unhelpful [00:31] I would say that your intent is correct there, and you should throw it at lp and see if LP DTRT [00:33] well, i've not changed sbuild locally to my knowledge [00:33] and looking at a random other laucnhpad build lo [00:33] log [00:33] https://launchpadlibrarian.net/248521085/buildlog_ubuntu-xenial-amd64.cloud-init_0.7.7~bzr1182+1186+444~ubuntu16.04.1_BUILDING.txt.gz [00:33] i see: Install core build dependencies (apt-based resolver) [00:34] (and sbuild says the default resolver is 'apt'). [00:34] so, it would seem that i should be using the same. [00:34] that said, its past time when i should be looking at this. [00:34] thank you for your time, slangasek [00:34] tommorrow maybe. ideally it'd work both on my system *and* launchpad :) [00:36] hm.. wonder if the fact that there is 'pyflakes3' helps or not. probably not. [00:36] nope [00:38] smoser: sbuild in LP uses --resolve-alternatives, which isn't the default. [00:40] smoser: slangasek's suggestion should work if you pass that switch. [00:40] slangasek: no idea (yet) [00:47] how can i build a debian sid autopkgtest vm for adt-run to use? [00:48] is there a tool like adt-buildvm-ubuntu-cloud to do it? [00:49] hallyn: do you specifically need a vm rather than lxc? [00:52] yes [00:53] hallyn: hrm, i'm not finding anything, but buildvm-ubuntu-cloud can take an arbitrary url; does debian host cloud images similarly? [00:53] 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] ah [00:53] i think they do... not sure whether similar enough though [00:53] i haven't seen any google results suggesting anyone has done this... [00:53] yeah me either :/ [00:54] leme ping the debian lxc maintainer [00:54] hallyn: one hit i found mentioned using vmdebootstrap to setup a debian vm [00:55] nacc: url? (for full argument list). [00:55] sounds all right, i assume it just creates the qcow2 and runs debootstrap in there [00:56] 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:57] maybe /usr/share/autopkgtest/setup-commands/setup-testbed [00:59] d'oh [00:59] the adt-virt-qemu manpage tells me what i need :) [00:59] thanks nacc [01:00] hallyn: np, that probably should have been more obvious :) [01:14] 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:15] nacc: which version of symfony should I be looking at? [01:15] slangasek: seems to be the case in all of them [01:15] 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:16] nacc: IIRC it will; debian/tests/control's "Tests" list typically points to scripts under debian/tests [01:17] slangasek: hrm, ok, i got differing behavior between running that script manually and what autopkgtest said ... but will keep digging [01:19] slangasek: fwiw, w/ 2.7.10, i'm down to one runtime failure [01:25] slangasek: i'm wondering, though, if it's a side effect of relatime and/or overlayfs [01:35] heh, there are bugfixes to this problem (possibly) that went into the kernel today [01:35] sigh [01:40] yep, the tests pass with aufs :) [01:41] 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:56] 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:57] slangasek: a bug i introduced, of course :/ === juliank is now known as Guest7038 === juliank_ is now known as juliank [03:28] ~ === salem_ is now known as _salem [03:52] I really wish that going from symfony 2.7 -> 2.8 didn't break so much crap [03:53] but people do versioning in their packages too strictly and depend on internal behaviors just because php lets them easily do so === darkxst_ is now known as darkxst [05:40] 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 [06:11] good morning === Son_Goku_ is now known as Son_Goku [08:24] good morning [08:40] why is it taking so long for launchpad to pick up uploads from debian? it seems to be getting worse and worse === sil2100_ is now known as sil2100 [09:22] 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] Launchpad bug 1558260 in cloud-images "unable to boot arm64 cloud images due to initrd" [Undecided,New] [09:26] 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] Odd_Bloke, and does not the last comment imply exactly that that it has been resolved in later images ? [09:27] Odd_Bloke, i thought smoser or someone was on the hook for determining when in the process this file cames into existance [09:28] Odd_Bloke, or are you saying it is you, and now :) [09:30] I noticed the gstreamer 0.10 plugins -bad and -ugly are no longer in the Xenial archive. Is this a permanent change? [09:31] 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] I'll assign it back to Jeff and ask him to confirm that he still sees it with the latest. [09:42] 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] Yeah, he didn't specify exactly which image he was using. [09:45] 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] Odd_Bloke, and we do need to find out where that is coming from and why [09:45] 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 [10:59] ginggs: Because Debian just changed a bunch of stuff and we're trying to keep up [11:00] ginggs: https://lists.debian.org/debian-devel-announce/2016/03/msg00006.html [11:02] cjwatson: ah, thanks [11:59] smb, "Revert back to bind against bind9 export libraries". did you do that for other rdeps too? [12:00] doko, no only isc-dhcp === _salem is now known as salem_ [12:11] lamont, why does libbind-export-dev ship a libbind9.so (without -export)? [12:11] doko: Because he oopsed. Already under investigation. [12:12] infinity, let me do that, so you'll have time for glibc ... [12:13] 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] doko: Also, the udeb deps are wrong. [12:13] doko: Enjoy. [12:13] infinity, udeb's are already fixed [12:14] Yay. [12:21] ok, testing a fix for the symlink issue [12:33] 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] sure [12:33] doko: (Which may already be true, but I'm not holding my breath after seeing the result of the current upload) [12:42] doko: because of bug. [12:43] doko: ta [12:45] doko: holler when you have something, and I'll add it to some other cleanup and upload it [12:46] (git tree is forward from P4-1 because of some patch cleanup and submmission upstream) [12:48] and I guess I'll be merging [13:03] 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:04] 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:05] slangasek suggested depending on 'python3-pyflakes | pyflakes (<< 1.1.0-2)' and on pyflakes. (full debian/control http://paste.ubuntu.com/15411741/). [13:05] but that fails with http://paste.ubuntu.com/15411746/ [13:07] any thoughts ? do i just have to make two control files now or disable checks. [13:08] smoser: you want sbuild --resolve-alternatives [13:08] (I think) [13:08] rbasak, well, maybe. but i'd like for it to work on launchpad too [13:08] smoser: it should Just Work on the buildds I believe. [13:09] src:php5 had the same need and the buildds were fine. [13:10] alright. i'll give it a shot. [13:10] Yes, Launchpad uses --resolve-alternatives. [13:10] (as Adam said yesterday) [13:16] cjwatson, bah. well, i missed that. [13:16] thank you, rbasak it seems to work. [13:27] cjwatson: do I recall correctly that we added dbgsym packages to PPAs? [13:29] aha. main/debug [13:29] Thanks! [13:30] * mterry should update some askubuntu questions [13:57] smb, lamont: -1ubuntu2 should fix the known issues. please re-upload isc-dhcp once this is built everywhere [13:58] does apt use repos that don't have the new DEP-11 metadata? [13:59] lamont, Can I leave that ^ to you as I cannot upload much (not isc-dhcp anyways) [13:59] silly question really.. [14:00] of course it does, like ppas.. just that apt-mirror seems somewhat broken and doesn't sync/clean stuff like before [14:00] doko: ok [14:00] smb: will do [14:00] ok cheers [14:00] doko: and thanks, I'll get that together and create -2 for e'ryone [14:03] 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] cjwatson: oh nice ok, thanks [14:04] (this is because debug symbols can be (a) slow to generate and (b) pretty large and would eat into quota on large archives) [14:15] 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] bug 1550852 in apt-mirror (Ubuntu) "apt-mirror does not reflect dep11/Components-* and dep11/icons-*" [Medium,Confirmed] https://launchpad.net/bugs/1550852 [14:16] best way to solve issues is to think out loud, publicly.. [14:20] doko: interesting approach with pyzmq ... I'd rather see the broken zmq update reverted than tests disabled [14:22] 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] on amd64 and i386 [14:22] they succeed there on buildds too [14:22] its the others that are the problem [14:23] no, they failed on the buildds [14:23] on debian they work [14:25] ... just on x86 [14:25] feel free to revert [14:25] exactly [14:26] zmq is somehow broken on all other arches [14:26] zmqs own testsuite just sucks [14:27] how did zmq even get into xenial? [14:27] it went into unstable post feature freeze [14:28] during the ruby2.2 removal [14:28] 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:31] 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:32] 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] sinzui: I lost context long ago on this. Is juju-mongodb/2.4 going away, or will that *also* be in xenial? [14:32] 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] xnox: I did and it didn't apply cleanly because the package has our ppc64el and arm64 patches on it [14:32] right [14:33] 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] xnox: juju-core has to use the old mongo. [14:33] bummer [14:33] xnox: That's the point of the crazy transitional packages. [14:34] sigh.... [14:34] 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] 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] infinity, i have customers using juju-core today =) so we can't drop it, before juju2 lands =) [14:34] xnox: me too. The juju release team want juju2 beta3 in xenial. [14:35] 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] infinity: understood [14:35] =/ [14:35] ack [14:36] sinzui: Has anyone actually talked to the release team about juju2? [14:36] 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] 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] it's all technically non-supported stuff. [14:36] infinity, is pitti release team at all? [14:37] xnox, https://launchpad.net/~ubuntu-release/+members [14:37] that membership is surprising [14:38] infinity, so pitti did talk to a few people about all the mongos and jujus [14:38] * xnox ponder mongi / juji ? [14:38] xnox: Yes, but not specific timelines. Just the packaging bits. [14:38] sinzui: Some of those members need to be culled. [14:39] 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:40] infinity: xnox the Juju team do want to propose the juju2 beta3 next week. [14:40] 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:42] xnox: I see cherylj did https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1545913 [14:42] Launchpad bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,New] [14:42] 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:44] 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:48] 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:49] (assuming that we take an appropriate amount of care, etc) [14:53] sinzui: filed https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1559169 [14:53] Launchpad bug 1559169 in lxc (Ubuntu) "containers no longer start after upgrade to 2.0.0~rc11-0ubuntu1" [Undecided,New] [14:53] 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:54] thank you cjwatson [14:55] rbasak, hm, it is new package. [14:55] 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:56] rbasak: Quite. [14:56] 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] 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:57] s/rush if/rush is/ [14:57] 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] If releasing at the same time as 16.04 is really important, then the deadline should be considered feature freeze. [14:57] rbasak: Don't disagree. [14:57] If feature freeze is missed, then releasing at 16.04 time is at risk. [14:58] * infinity gets back to breaking the freeze. [14:58] its spring time anyway ! stop these freeze talks ! [14:58] jamespage, please steal everything you like ... [15:02] jamespage, ohh, that even was an unmerged packages by you for two years ... I had just a no-change upload [15:03] doko, nope not me [15:04] but I'll merge it anyways as it unblocks stuff... [15:04] ahh, jtaylor ... misread [15:06] unison is a mess, it should probably just be removed [15:06] they don't seem to have an compatiblity so whatever is in the archvie stops working on the next upstream version [15:17] 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] sinzui: http://dep.debian.net/deps/dep3/ [15:17] sinzui: also, please update the headers for any patch you modify (that isn't just a refresh to unfuzz) [15:19] infinity: how do you feel about a juju-mongodb3.2 where Ubuntu's mongodb is still on 2.6? [15:19] (Debian is on 2.4 AFAICT) [15:20] 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] OK [15:20] Reviewing this is fun. I don't have anything to base a diff from :-/ [15:20] (well, 2.6) [15:20] rbasak: (And if that plan involves "make the security team deal with it", they should be asked too) [15:21] That's an open question at the moment. Juju management are looking into it. [15:27] apw, infinity: autopkgtest for linux 4.4.0-14.30: amd64: Pass, armhf: Pass, i386: Pass, ppc64el: Regression ♻ , s390x: Pass [15:27] (triggered by gcc-5). is this a real issue, or can we ignore it? [15:29] sinzui: have you checked to see if there are any updates needed to debian/copyright (for both juju-mongodbs)? [15:29] rbasak: oh, have I...I removed an entry form the 3.2 because the package was removed from 3rd party [15:31] rbasak: I hestitantly offer to go the full dep-5 [15:31] 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:32] That means pitti in this case I think? [15:32] doko: Gonna give it a kick to retry. But it looks like it was busted tests (since fixed), not GCC's fault. [15:32] understood rbasak [15:33] sinzui: dep3 headers I do want though. It's difficult to understand what I'm reviewing without them. [15:33] rbasak: yeah, I have that open now [15:34] sinzui: basically I want to know where each patch came from and where I can find upstreaming status. [15:34] rbasak: okay, understood [15:35] (because if we don't track that, packaging inevitably becomes an unmaintainable mess) [15:35] Thanks :) [15:50] lamont, ugh that bind9 saga isn't a happy one [15:50] smb, what's still wrong? [15:50] lamont, now its afaict named-checkzone which went into bind9 and bind9utils [15:53] 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:54] smb: gar [15:54] doko: likely so [15:54] * lamont stares at the build-deps in -1ubuntu2, and wonders if that was really necessary [15:55] deps actually [15:58] lamont, I was checked for missing libs, because I found one export lib missing in the dh_makeshlibs call in debian/rules [15:59] makes sense [15:59] I decided I didn't care enough to change it back [15:59] 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 [16:00] apw, in fi ni ty already gave it back [16:00] doko, ahh good enough, we shall see when it completes there [16:01] doko: hoping you have time to do that switch to debian/tmp? +1 from me on the concept [16:01] pitti, can i trick you into reviewing https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1551952 or are you off already? [16:01] Launchpad bug 1551952 in multipath-tools (Ubuntu) "FFE: Please merge multipath-tools 0.5.0+git1.656f8865 from Debian unstable " [Undecided,New] [16:06] lamont, not today; I'll look at it tomorrow [16:08] ok [16:08] smb: feedback from isc is that we likely just broke signals for all of the bind tools when we fixed dhcp... [16:08] so I'll be reworking that diff a bit [16:10] 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:11] ah, could be [16:11] 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] Launchpad bug 1558848 in symfony (Ubuntu) "symfony: failing autopkgtests" [Undecided,New] https://launchpad.net/bugs/1558848 [16:12] 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:21] 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:22] smb: likely the way I'll go [16:22] but it'll be post-sunday [16:25] doko, can we drop gcc-3.3 and hence libstdc++-5.0 from xenial? =) [16:28] 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:29] * lamont plans to upload iscdhcp shortly, just waiting on the publisher [16:29] the other stuff is just "bind9 bugs" [16:29] I mean, we already have the potential defect there in P4-1 [16:30] lamont, yeah but that never went out [16:30] 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:31] hrm [16:31] this is sad making [16:31] it may be my today thing after all [16:31] lamont, none of the recent bind9 uploads I mean. The first one because of dependencies and the other becuase of the adt failures [16:32] smb: ack [16:32] which is actually cool, beacuse I don't need Replaces. :D [16:33] xnox, can you convince Debian first to drop it? [16:33] it just builds one lib [16:34] lamont, Also you kinda do not have to wait to upload isc-dhcp because there is no reason to [16:35] smb: it was more of "waiting for 1ubuntu2 to really really be in the archive, but taht was 2 hours ago.. [16:35] smb: "no reason to"? [16:35] lamont, ERm yes, that s what I try to say [16:36] lamont, It wont go there because it annoys britney (I mean ikiwiki-hosting test regression) [16:36] infinity: no longer a reason to wait [16:36] infinity, Right that was what I meant [16:36] lamont: Right, I misread as "we don't need to wait" not "the wait is over". [16:36] * lamont got distracted [16:38] and then went "why do I even have this window open" [16:41] Heh yeah... I just happened to go back there and refresh and then decided that red is not my favourite colour in there [16:45] lamont, Or rather I think I did not mean what you thought I meant... [16:46] right [16:46] lamont, I meant there is no reason to do the upload... [16:46] 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] Launchpad bug 1549942 in ImageMagick "php-imagick failing autopkgtests" [Unknown,New] https://launchpad.net/bugs/1549942 [16:46] slangasek: apologies, I don't know what I had messed up before in my test setup [16:48] lamont, Though it probably does not matter if isc-dhcp now links dynamically it will remains stuck in proposed together with the bind9 [16:57] ack [17:13] slangasek: i believe we need a rebuild of php-zend-code so that it pulls in php-common rather than php5-common [17:13] slangasek: but i believe why it's not migrating is symfony [17:13] slangasek: (via php-proxy-manager) [17:26] 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:47] 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:54] slangasek: hrm, it's a php.ini issue, possibly [18:27] nacc: what do I need to do to stop being moderated on ubuntu-devel? [18:27] 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] Launchpad bug 1558848 in symfony (Ubuntu) "symfony: failing autopkgtests" [Undecided,New] [18:27] Pharaoh_Atem: become an Ubuntu Developer ;) [18:28] slangasek: yep, working through them now, thanks! [18:28] slangasek: is it anywhere near as hard as becoming a Debian one? [18:29] 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] slangasek: ah ok, i wasn't sure, since i hadn't run their script to mangle the name. [18:30] slangasek: also, i just realized i still need to fix the licenses! [18:30] slangasek: sorry, let me try to get that done now too [18:30] 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] Pharaoh_Atem: being unmoderated on ubuntu-devel is probably not a good argument for becoming an Ubuntu Developer :-) [18:30] Pharaoh_Atem: would you be able to test something for me on php7.0 in non-ubuntu installations? [18:30] nacc: yes [18:30] nacc: ok shelving symfony until you re-ping me [18:30] * Pharaoh_Atem is actually updating his testing atm [18:31] *test stuff [18:31] Pharaoh_Atem: http://paste.ubuntu.com/15416746/ [18:31] slangasek: yep, thanks [18:32] slangasek: php-monolog v2 debdiff posted, thanks [18:37] nacc: you tested that autopkgtest works? [18:41] slangasek: yep [18:42] nacc: ok, uploading [18:43] nacc: you'd like me to run this as a CLI app or web script? [18:43] Pharaoh_Atem: cli, please [18:43] I missed the details, but am I right in saying syncing with Debian is not currently possible? [18:43] okay [18:48] slangasek: oh, fwiw, i didn't alter upstream in this case, as i made an archive from github [18:49] 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] afaik, it wouldn't be dfsg because you're not using the debian one, you've made your own [18:49] 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:50] nacc: I would still say +dfsg, if you're deleting things that are part of the upstream tarball [18:50] slangasek, Yep, I understand that. My question was not clear enough. [18:51] slangasek: the orig.tar.gz has no deletions; it was a `git clone`, then `git archive ... v2.7.10` from upstream symfony [18:51] slangasek, I do the vast majority of the Ubuntu MATE work in the Debian community as part of the pkg-mate team. [18:51] nacc: ok, fine with me then [18:51] I have several syncrequests filed, bug fixes. [18:52] Those packages are not available in LP. [18:52] slangasek, For example - https://launchpad.net/debian/+source/mate-dock-applet [18:53] 0.69 in LP and 0.70 in Debian. The Ubuntu dev who looked at my syncerequests was unable to process them. [18:53] 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:54] packages that were in Debian prior to Wednesday-ish are syncable, but new uploads are currently not visible [18:54] slangasek, Thanks. That was the deatil I was missing. [18:54] Thanks for explaining. I heard something had changed but wasn't aware what exactly. [18:58] 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) [19:08] slangasek: i believe php-psr-log requires the php-opencloud update, afaict [19:12] nacc: http://fpaste.org/342352/83283271/ [19:12] Pharaoh_Atem: sigh, those are bugs too :) [19:12] damn it [19:12] Pharaoh_Atem: so the thing is, if you build upstream PHP 7.0.4 [19:13] Pharaoh_Atem: if you wouldn't mind trying that [19:13] Pharaoh_Atem: it works fine [19:13] I'll give it a go, one sec [19:13] Pharaoh_Atem: or just passing ./configure w/o any options [19:13] that's... bizarre [19:13] agreed. [19:14] nacc: did you get the upstream php 7.0.4 from GitHub or php.net? [19:14] Pharaoh_Atem: github [19:15] Pharaoh_Atem: is there a specific difference? [19:15] I hope not [19:15] * Pharaoh_Atem is about to check [19:15] :) [19:15] but... knowing them... [19:17] I hate people so much [19:18] Pharaoh_Atem: did you find a difference? [19:19] nacc: http://paste.fedoraproject.org/342361/83287411/ [19:19] 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:20] I'm not if these are really diffs or not [19:20]