/srv/irclogs.ubuntu.com/2016/02/19/#ubuntu-devel.txt

rbasakroaksoax: do you want to upload that?00:00
rbasakroaksoax: I was about to go to bed.00:00
slangaseknacc_: and the php7.0-cli dependency on libqdbm14 (universe) needs to be resolved before pkg-php-tools is buildable00:13
nacc_slangasek: ok, the build of php7.0 takes a while, so i'm waiting for it to finish before submitting the debdiff00:17
nacc_slangasek: i'm fairly confident it is right now that it's going properly (they changed the way extenions were compiled in, so had to adjust the php5 delta)00:18
slangaseknacc_: ok.  please do point me at the debdiff once you've uploaded it00:48
nacc_slangasek: will do -- also, i'm finally looking at LP: #cobbler 154382000:52
nacc_gah00:52
nacc_LP: #154382000:52
ubottuLaunchpad bug 1543820 in jmespath.php (Ubuntu) "jmespath.php: add nocheck and stage1 build profiles" [Wishlist,New] https://launchpad.net/bugs/154382000:52
slangasekexcellent00:52
nacc_i understand the test: target issue00:52
nacc_but i don't know how to fixup the coverage: one?00:52
nacc_and test: is a dependency for all:00:53
nacc_actually00:53
nacc_so would i remove that dependency in the makefile and then just add a dh_override_auto_test? coverage i think won't get invoked during the build00:54
nacc_slangasek: urgh, sorry, was confusing that and LP #154381701:01
ubottuLaunchpad bug 1543817 in php-guzzlehttp-psr7 (Ubuntu) "php-guzzlehttp-psr7: add nocheck and stage1 build profiles" [Wishlist,Incomplete] https://launchpad.net/bugs/154381701:01
nacc_it feels like they will have the same answer, though01:01
nacc_is it ok for me to change the all: target to not run tests by default? so i can override it in debian/rules? or should that work?01:01
nacc_slangasek: fyi, build just finished, works w/ debdiff from LP: #154724501:11
ubottuLaunchpad bug 1547245 in php7.0 (Ubuntu) "php7.0: remove dependencies that come from universe" [Undecided,New] https://launchpad.net/bugs/154724501:11
slangaseknacc_: php5-xmlrpc is in main and doesn't depend on xmlrpc-epi; is this maybe an optional dependency?01:17
slangaseknacc_: interbase and imap packages were built for php5, but came from separate source packages in that version.  So this is probably ok for here and now (until we finish the main build-depends discussion)01:19
nacc_slangasek: i think the xmlrpc-epi dependency is altogether new in 7.0 and the xmlrpc module (it's makefile) uses xmlrpc-epi explicitly (http://anonscm.debian.org/cgit/pkg-php/php.git/commit/?h=master-7.0&id=1ae43adc9057c3911d1ada8e3a1231d456f6f20f)01:19
slangasekok01:19
slangaseknacc_: so, that's probably something that should get an MIR rather than just being dropped; but I'm ok with applying this patch now and uploading, to unblock us01:20
nacc_slangasek: well, here's the really confusing part with php501:20
nacc_well, maybe a side discussion01:22
nacc_php5 and php5.6 are different src pckages01:23
nacc_:)01:23
nacc_it leads to some weirdness and i don't know why it's that way, tbh01:23
nacc_but i can do the MIR for packages that now won't exist01:23
nacc_slangasek: so far that's php-xmlrpc, php-interbase and php-imap (with their corresponding 7.0 names)01:24
slangasekhmm yes01:25
slangasekI don't know why that is01:25
sarnoldwhich of those packages will exist when xenial is released? php5? php5.6? php7?01:26
nacc_only php701:27
nacc_is the plan01:27
nacc_sarnold: --^01:27
sarnoldnacc_: no php 5.x in xenial, even in universe?01:28
nacc_sarnold: correct01:28
nacc_sarnold: if you want php5 stay on 14.04 LTS01:28
sarnoldwow, feels ambitious :) woo. thanks.01:28
Pharaoh_Atemnacc_: so we're doing the php7 move?01:33
Pharaoh_Atemawesome01:33
Pharaoh_Atemmeanwhile, I'm about to break down and cry in the amount of effort I've expended to try to build this package in a sane fashion01:34
robert_ancelljsalisbury, that dir you sent me for the kernel to test is empty01:34
slangaseknacc_: btw do you know anything about the autopkgtest failures on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php7.0 ? it doesn't look like a false positive to me01:36
Pharaoh_Atemslangasek: I'm actually trying to fix them01:48
Pharaoh_Atemthe weird thing is, I can run them manually (i.e., run the commands in the scripts in order) and everything is fine in my Xenial VM01:48
Pharaoh_Atemhowever, autopkgtest is failing for whatever reason01:48
nacc_slangasek: Pharaoh_Atem: i'll try and take a look01:49
Pharaoh_Atemnacc_: my theory is that all the a2* commands need to be guarded to redirect their output to /dev/null and set to OR with true01:49
Pharaoh_Atembut I've been having a hell of a time trying to prove that01:49
nacc_Pharaoh_Atem: hrm01:50
Pharaoh_Atempbuilder and sbuild make me want to hurt people01:50
Pharaoh_AtemI've never encountered a more obnoxious chroot builder tool01:50
Pharaoh_Atemerr, package builder tool using chroots01:51
sarnoldi'm suriously surprised no one's replaced them with lbuild for lxc or kbuild for kvm..01:51
nacc_Pharaoh_Atem: trying it locally, will let you know01:52
Pharaoh_Atemnacc_: awesome01:52
Pharaoh_Atemthanks01:52
Pharaoh_Atemsarnold: this is the first time I've attempted to build debian packages using pbuilder and the like in quite a while01:52
Pharaoh_Atemmost of the time, I just use open build service01:53
nacc_slangasek: for those packages that need MIR, is the general strategy to start with basically php7.0 as the source and just strip them down to the point where they just have the bits needed for say php7.0-xmlrpc? and then that source and binary would be in universe?01:53
Pharaoh_Atemnacc_: if you need my patch diff, I can send it to you01:53
nacc_slangasek: do we, to enforce the break from php5 to php7 have the php7 packages break their php5 counterparts? i'm noticing that the bootstrap may not be necessary anymore (!) because the deps are versioned, e.g. php7.0-cli php7.0_7.0.3-5ubuntu1.dsc01:55
nacc_err01:55
nacc_php7.0-cli Breaks: php5-cli (<< 5.6.16+dfsg-4~)01:56
nacc_slangasek: i *think* those exist because in debian they are coinstallable01:58
Pharaoh_Atemnacc_: I'm also going through and ensuring that every test turns off stuff that could potentially conflict that was turned on by other tests01:58
slangaseknacc_: MIR> the process is, you identify the build-dependency that's needed for php7.0-xmlrpc (xmlrpc-epi), you go through the checklist for that package to see what it needs in order to be in main; then you look at any dependencies /that/ package has which aren't in main and do the same02:00
nacc_slangasek: ah ok, so sort of the same process, but for each of these02:01
nacc_got it02:01
Pharaoh_Atemsarnold: is there anything that's as simple as RH/Fedora's mock for Debian packages?02:01
slangaseknacc_: regarding the breaks, if the package is policy-compliant then that's because php7.0-cli took over some file previously provided by php5-cli02:02
slangasekif they're coinstallable and no bootstrap is needed, then that's peachy :)02:02
nacc_slangasek: well, they are possibly now :/ frustrating given how much time i spent on it, but yeah, much easier02:02
nacc_i think that means we can just start building stuff once we have the updated pkg-php-tools and php-pear02:03
Pharaoh_Atemneat02:03
slangasekvery possible02:03
nacc_although i'm not sure if they'll automatically pull in the php7 deps02:03
sarnoldPharaoh_Atem: sorry, I've never heard of mock; what does it do?02:03
nacc_i'll need to test that with the current archive02:03
slangasekthat depends how their build-depends are listed02:03
slangasekanything that was on your list for "rebuild only" should pull in the php7 versions of packages, yes02:03
Pharaoh_Atemsarnold: http://linuxmanpages.net/manpages/fedora21/man1/mock.1.html02:04
Pharaoh_Atemit takes Source RPMs and can rebuild them for any arbitrary target02:04
Pharaoh_Ateminto binary packages02:04
Pharaoh_Atemit can also create generic chroots that you can use for arbitrary purposes02:04
nacc_slangasek: right, but i'm worried that with the coinstallable version, what's happening is that sbuild right now is installing php5-cli for phpunit and php7.0-cli for the package and possibly running under php5 ... i'm not sure02:04
slangasekah02:05
Pharaoh_Atemsarnold: it's actually available in Ubuntu, too :P ( http://manpages.ubuntu.com/manpages/wily/en/man1/mock.1.html )02:05
sarnoldhah02:05
Pharaoh_Atemthe version in Ubuntu is a tad bit old, but it works02:05
nacc_slangasek: does that make sense? i'm just worried that the world we're building in now is different than the one i did the builds with (and i know produced the right result)02:05
sarnoldPharaoh_Atem: schroot manges the chroot bits.. sbuild uses them to build packages..02:06
sarnoldPharaoh_Atem: debootstrap can populate a directory with a debian / ubuntu install02:06
slangaseknacc_: well, to date the only things we're building are php-pear (done) and pkg-php-tools (dep-wait) which were the bits at the bottom of your tree. I don't have to upload no-change rebuilds for the other stuff until you confirm that's appropriate02:07
nacc_slangasek: that is, i'm noticing if i tell sbuild that there is a build conflict with php5-cli, e.g., the build fails unless i'm in a staged build (which is roughly the result we want with updated php-pear and pkg-php-tools)02:07
nacc_ok, i'll spend some time tmrw morning, if that's ok with you, thinking about that02:07
Pharaoh_Atemsarnold: yeah, the functionality of debootstrap is sorta not necessary in RH/Fedora because it's built into Yum (RHEL; Fedora <22) and DNF (Fedora >=22)02:07
slangaseknacc_: but also, if the builds *are* doing the right thing, we can do the whole bootstrap in the main archive by just double-uploading no-change rebuilds02:07
slangaseksorry, I mean if they aren't doing the right thing02:07
nacc_slangasek: right02:07
sarnoldPharaoh_Atem: have you seen this yet? https://wiki.ubuntu.com/SimpleSbuild02:08
Pharaoh_Atemyeah02:08
nacc_slangasek: i'm starting to think that possibly we'll be able to just build straight through in the right order02:08
Pharaoh_AtemI've been trying to set that up02:08
nacc_slangasek: but that's what i'd like to confirm tmrw before we kick it off02:08
slangaseknacc_: ok02:08
Pharaoh_Atemsarnold: it just finished building the chroot tarball, so I think it might actually work, just maybe possibly...02:09
nacc_slangasek: and pkg-php-tools should be able to go once php7.0 is updated?02:09
slangaseknacc_: yes02:09
slangaseknacc_: so I'll retry that build as soon as php7.0 is done, which I'm expecting to be in less than a half hour02:10
nacc_slangasek: yeah it takes a while, i noticed, but that was on my laptop :)02:10
=== beisner- is now known as beisner
nacc_slangasek: thanks for all your help!02:10
nacc_i really appreiate it02:11
slangasekno prob02:11
nacc_slangasek: sigh, just confirmed, e.g., that php-guzzlehttp-psr7 can just be rebuilt against xenial w/o bootstrap/modification02:15
nacc_slangasek: there's two weeks+ of work that can be tossed :)02:15
nacc_oh well, learned a lot02:15
Pharaoh_Atemnacc_: at least you enjoyed it, right?02:16
Pharaoh_Atemor did you hate everything :P02:16
nacc_Pharaoh_Atem: no it was good, just stressful :)02:16
slangaseknacc_: interesting, is this because something changed out from underneath you with php5-cli?02:16
nacc_slangasek: yeah, debian has updated both php5 and php7 past the point where there was a conflict in the build-deps02:17
nacc_err, in the binary packages02:17
* slangasek nods02:17
slangasekso, a race condition02:17
nacc_e.g., when i started, php7.0-cli and php5-cli conflicted02:17
nacc_now they don't :)02:17
nacc_yeh02:17
Pharaoh_Atemso that means a mass import for the php stack  will fix everything?02:17
nacc_Pharaoh_Atem: that's what i need to check02:17
nacc_Pharaoh_Atem: I *think* the debian packages right now still refer to php5 in their deps02:18
Pharaoh_Atemguh02:18
nacc_Pharaoh_Atem: because debian hasn't uploaded the new php-pear and pkg-php-tools02:18
nacc_that's the step that will diverge for now in ubuntu02:18
Pharaoh_Atemthat won't be for very long, practically speaking02:18
nacc_with the understanding that what we have is what debian has in their git tree(s)02:18
nacc_yeah02:18
nacc_so it's a very known delta to carry for hopefully a short amount of time02:18
Pharaoh_Atemthat's why I've been submitting fixes to php7.0 to their git tree02:19
nacc_yep and those have all been sync'd to ubuntu already, afaict02:19
Pharaoh_AtemI've had some testing of it done against our applications02:19
Pharaoh_Atemthe fpm stuff has not02:19
nacc_Pharaoh_Atem: ok02:19
Pharaoh_Atemondrej didn't see my patches and only applied the newest set from last week yesterday02:19
nacc_Pharaoh_Atem: you saw this, right?02:20
nacc_/tmp/adt-run.qW8OfQ/build.vJ1/php7.0-7.0.3/debian/tests/mod-php: 6: /tmp/adt-run.qW8OfQ/build.vJ1/php7.0-7.0.3/debian/tests/mod-php: cannot create /var/www/html/hello.php: Directory nonexistent02:20
Pharaoh_Atemno, I didn't02:20
Pharaoh_Atemthat's weird02:20
nacc_it's in the middle of the bulid log02:20
nacc_https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/php7.0/20160217_205539@/log.gz02:20
nacc_i'm not sure why fpm is exiting yet, but when you've been running the tests, were you testing the archive version of php-fpm or your pathed version?02:21
Pharaoh_Atemis /var/www/html not your default path?02:21
Pharaoh_Atemnacc_: archive version02:21
nacc_Pharaoh_Atem: that's the archive's build02:21
Pharaoh_AtemI'm extremely confused now02:21
nacc_http://autopkgtest.ubuntu.com/packages/p/php7.0/xenial/amd64/02:22
nacc_start there02:22
nacc_then test log02:22
Pharaoh_Atemah02:22
Pharaoh_Atemnow I get it02:22
nacc_that's what i assume you were trying to resolve (as those tests need to pass)02:22
Pharaoh_Atemyes02:23
Pharaoh_Atemweirdly enough02:23
Pharaoh_Atemthat's not a test I modified02:23
Pharaoh_Atemhold on02:26
Pharaoh_Atemhold the phone02:26
Pharaoh_AtemI think I *might* know why02:26
Pharaoh_AtemI hope I'm wrong02:26
Pharaoh_Atembecause otherwise this will be really dumb02:26
Pharaoh_Atemnope, libapache2-mod-php7.0 depends on apache202:27
Pharaoh_Atemoh, wait02:28
Pharaoh_Atemnacc_: I know what happened02:28
Pharaoh_Atemlibapache2-mod-php7.0 doesn't depend on apache2, only apache2-bin02:28
Pharaoh_Atemthe directory is created when apache2 is installed02:28
Pharaoh_AtemNOT when apache2-bin is installed02:28
* Pharaoh_Atem groans02:28
Pharaoh_Atemnacc_: so basically, I need to add apache2 as a dep to the mod-php test02:30
Pharaoh_Atemnacc_: it worked for me before because apache2 was installed02:31
Pharaoh_Atembut this builder environment didn't have it02:31
=== juliank is now known as Guest490
=== juliank_ is now known as juliank
nacc_Pharaoh_Atem: glad to help :)02:36
nacc_Pharaoh_Atem: will that fix fpm too?02:36
Pharaoh_Atemfpm already had apache2 as a dep, but I think the other fix I made should make things better02:36
Pharaoh_Atemif you'd be so kind to test a pair of patches I'll send your way?02:36
nacc_Pharaoh_Atem: sure just e-mail them to me02:37
Pharaoh_Atemnacc_: they should be in your canonical inbox02:39
nacc_Pharaoh_Atem: ok ,might not get to it til the am, fyi02:41
nacc_Pharaoh_Atem: working on dinner at the moment :)02:41
Pharaoh_Atemthat's okay02:43
Pharaoh_Atemhopefully it fixes those tests02:44
Pharaoh_Atemif these are good, I'll send them up to Ondrej for inclusion in the master-7.0 dgit02:46
cpaelzergood morning05:48
pittiGood morning06:35
pittistgraber: yes, it was broken due to a proxy issue, I fixed it last night06:35
highvoltage506:39
cpaelzerwe have a test failing in dep8/autopkg runs due to sse3 not being available07:08
cpaelzerwhich makes sense as the default vm has only up to sse207:08
cpaelzerI wonder if there is a way to define a d/t/control in a way so that tests would have sse3 available or something similar07:09
pitticpaelzer: your test could detect that and just skip itself (i. e. early exit 0)07:09
cpaelzerlocally I confirmed that providing adt-run with "--qemu-options='-cpu qemu64,+ssse3' " it works07:09
pittibut this bears the question, how is that going to work on an real system?07:09
cpaelzerit is supposed to only work on real systems with >=sse307:10
cpaelzerdisabling that would mean disabling all tests, so I wondered if there would be any way07:10
cpaelzerof corse in the worst case one might detect and early exit, but keep the tests for those who run it local with the qemu options07:11
pitticpaelzer: if only some of the tests need ss3, then only check it there?07:11
cpaelzerpitti: all of them need it07:11
cpaelzerbut I'd really like to check if there is really no way to get such options passed properly before disabling it07:12
pitticpaelzer: so where is "disabling that would mean disabling all tests" a problem then?07:12
pittiif your debian/tests/whatever just checks /proc/cpuinfo and prints a sensible message and exits 0?07:12
cpaelzerpitti: the problem would be no dep8 tests in normal CI on package upload07:12
pittiif none of the tests below can run, then you aren't losing anything07:12
pittiright, but that's nothing the test itself can influence07:13
pittia test doesn't have magic powers over the testbed you are running it on07:13
cpaelzerpitti: ok, I'd hoped there would be a way to force the test env to have such properties - like the isolation or class flags07:14
cpaelzerpitti: but thanks I really just wanted to make sure there is no easy way to get sse3 in the test env overlooked07:14
jamespagecpaelzer, ok - lets just put a check in the test to skip the tests if sse if not found then07:14
cpaelzerjamespage: ok07:14
jamespageI'm not really around this morning - if you can't find a sponsor, I'll pickup pm today07:15
pitticpaelzer: no, this kind of feature test is way too specific07:15
pitticpaelzer: I don't have control over the -cpu flags in production, we are using scalingstack instances, not direct QEMU invocations07:15
cpaelzerjamespage: ok, I'll pull the current package make the check happen test it and look around - if no one is here I'll mail you07:15
cpaelzerpitti: the only thing we could control there could be via a flavor maybe07:16
cpaelzerah I see autopkgtest is a flavour already07:17
cpaelzerit is probably too much, for just this test to put extra effort there07:17
cpaelzeron-site aptop repair incoming - til later07:21
pitti@pilot in07:35
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
dholbachgood morning07:49
mgedmindid anything change on archive.ubuntu.com recently?08:10
mgedminmy squid-deb-proxy is reporting 503 errors for URLs like http://security.ubuntu.com/ubuntu/dists/precise-security/main/binary-amd64/Packages08:11
mgedmin(and also archive.ubuntu.com)08:11
mgedminand then actual security updates fail with apt hash mismatch errors08:11
mgedmin("WARNING: The following packages cannot be authenticated")08:12
dokocjwatson, could you have a look, if ghc can be built with llvm-3.8 (or -3.6) instead of 3.5?08:19
hallyndoko: should pkcon be willing to install a file called com.ubuntu.terminal_0.7.170_multi.click on amd64?08:48
hallyn(it says "Fatal error: Wrong architecture 'multi'")08:48
hallynI'm jus asking you since yourname is in the changelog,08:48
hallynthough it looks like you just fixed the bulid, nm08:49
dokohallyn, I have no idea about click ...08:49
hallyndoko: yeah, sorry to bother you08:49
hallynthe whole chnagelog is a lot of "rebuild" :)08:49
dokopitti, nacc_: how many packages depend on swig's php support?08:53
flexiondotorg_dholbach, Morning09:04
dholbachhi flexiondotorg_09:04
dokoseb128, Laney, willcooke: fyi, https://bugs.launchpad.net/ubuntu/+source/lua-bitop/+bug/154739509:09
ubottuLaunchpad bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New]09:09
pittidoko: was about 7, and none of the removed binaries had rdepends09:22
dokonacc_, jamespage: fop needs a xmlgraphics-commons merge09:41
pittinacc_: can you please look at https://launchpad.net/ubuntu/+source/phpunit/5.1.3-1+ubuntu1/+build/9036792 ? segfault in dh_phpcomposer09:42
pittidoko: x-c merge is already in -proposed09:42
pittil09:42
dokota09:46
pittinacc_: you have an irritating habit to add trailing space to your debian/changelog entries :)09:46
dokodid somebody give back pcl on amd64?09:47
pitti^ not me09:47
xnoxkees, depends. I have seen obscure events resulting in reversal of "boot" direction. E.g. restart or stop dbus. Whilst doesn't quite means shutdown, the only practical way to recover is reboot. dm-0... depends what's on it, what upstart-udev events are emitted, and what other things trigger on that. On Ubuntu it shouldn't cause too much havoc by default....09:56
pittixnox: not sure about the context, but "systemctl stop dbus" is a no-op under Ubuntu FYI (and thus restart doesn't work either -- I recently made that a bit more robust)09:57
xnoxpitti, the context was from "kees" saying many hours back -> "<kees> xnox: got a weird question for you -- why would the surprise appearance of dm-0 during upstart boot cause upstart to shut down they system?"10:01
Saviqpitti, morning, do you know anything about why apport-retrace would fail with "ERROR: E:Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -e /usr/bin/appstreamcli; then appstreamcli refresh > /dev/null; fi', E:Sub-process returned an error code"" since ~yesterday?10:03
pittinacc_: please also look at bug 1543850, you attached the wrong debdiff10:05
ubottubug 1543850 in phpunit-global-state (Ubuntu) "phpunit-global-state: add nocheck and stage1 build profiles" [Wishlist,Incomplete] https://launchpad.net/bugs/154385010:05
pittiSaviq: no; apparently appstream landed on the images/in ubuntu-desktop and now has a broken hook?10:05
pittiSaviq: it probably needs another test for "am I root"10:05
Saviqpitti, yeah, my apt-cacher-ng broke, too, need to allow the new file types10:06
pittiSaviq: oh, I'm using acng too, I didn't yet see that10:06
Saviqpitti, 403 on the .yml files10:06
pittiah, I don't have /usr/bin/appstreamcli10:06
Saviqoh well, that's *a* solution10:07
* Saviq files bug with apport and acng10:08
Saviqalthough, wonder, should the first one be with appstream instead10:09
pittiSaviq: it's only a bug in appstream10:11
pittiSaviq: it apparently installs that apt hook, and that needs fixing10:11
pitti[ `id -u` = 0 ] or something10:12
Saviqpitti, bug #154742810:12
ubottubug 1547428 in appstream (Ubuntu) "Fails to update packages in apport-retrace" [Undecided,New] https://launchpad.net/bugs/154742810:12
Laneyhttps://github.com/ximion/appstream/pull/2810:12
* pitti hugs Laney, thanks!10:14
Saviqpitti, bug #1547431 for acng10:16
ubottubug 1547431 in apt-cacher-ng (Ubuntu) "Does not allow appstream files" [Undecided,New] https://launchpad.net/bugs/154743110:16
pittinacc_: btw, for next  time: simpler to just add multiple tasks to one bug about the same issue ("add stage1 blabla")10:22
* pitti declares victory in today's sponsoring battle against nacc :)10:26
pittil10:27
ogra_m10:31
xnoxpitti, we have lxd for s390x.10:32
xnoxpitti, is that because nacc fell asleep or some such?! =)10:32
pittinacc_: segfault in https://launchpad.net/ubuntu/+source/twig/1.23.1-1ubuntu2/+build/9036982 too10:40
cjwatsondoko: My general sense from debian-haskell@ is "haha no", and I'm certainly not going to go down a rabbit-hole on it when the experts think it's implausible to touch that.  My understanding is that GHC is going to end up vendoring LLVM. :-/10:49
dokook, at least it's now demoted10:52
cpaelzerthis morning we discussed here about skipping tests in openvswitch-dpdk if the environment can't provide sse311:01
cpaelzersince fixing this autppkgtest blocks another packets migration through proposed I wanted to ask if somebody would have a minute to sponsor bug #154746011:02
ubottubug 1547460 in openvswitch-dpdk (Ubuntu) "openvswitch-switch-dpdk failing in autopkgtests" [High,Triaged] https://launchpad.net/bugs/154746011:02
cpaelzerjamespage: you are not back already are you ? ^^11:02
infinitycpaelzer: So, while skipping tests when they literally can't run is reasonable, we also shouldn't find ourselves in a situation where we can't test at all in our production builds.  Have you talked to people about perhaps bumping the baseline scalingstack machine configs?  I don't think any of the underlying hardware lacks sse3, we're probably just running in -cpu=core2duo or something and masking it out.11:04
dokorbasak, jamespage: now Debian is depending a lot on tomcat8 (libservlet3.1-java) instead of tomcat7 (libservlet3.0-java). I saw that seb128 changed libhsqldb1.8.0-java to libservlet3.0-java. time to move to tomcat8?11:04
xnoxapw, Setting up linux-image-4.4.0-6-generic (4.4.0-6.21) ...11:04
xnoxRunning depmod.11:04
xnoxupdate-initramfs: deferring update (hook will be called later)11:04
xnoxcp: cannot stat ‘/boot/initrd.img-4.4.0-6-generic’: No such file or directory11:04
xnoxFailed to copy /boot/initrd.img-4.4.0-6-generic to /initrd.img at /var/lib/dpkg/info/linux-image-4.4.0-6-generic.postinst line 745.11:04
xnoxdpkg: error processing package linux-image-4.4.0-6-generic (--configure):11:04
xnoxapw, on amd64....11:04
cpaelzerinfinity: yeah  talked this morning with piiti and jamespage and skipping them was what was decided11:04
cpaelzerinfinity: we talked about the flavour used for autopackagetest very briefly, and as soon as that might be changed the test would run as-is again without further upload needed11:05
cpaelzerinfinity: but we didn't consider changing the flavour an immediate task like "for today"11:05
xnox$ ls -latr /initrd.img11:05
xnox-rw-r--r-- 1 root root 0 Jan 31 13:21 /initrd.img11:05
infinitycpaelzer: *nod*11:05
xnoxwhich is well aweful.11:06
xnoxapw, ^11:06
cpaelzerinfinity: but you are right, I guess no one would have driven that - I'll write down a note to send a mail to the mailing list about it11:06
infinityxnox: Where did that root filesystem come from?11:06
dokoahh, that's LP: #153990311:06
ubottuLaunchpad bug 1539903 in tomcat8 (Ubuntu) "tomcat-8 in main for upcoming 16.04 LTS" [Low,Fix committed] https://launchpad.net/bugs/153990311:06
xnoxinfinity, that's just my xenial laptop.... fairely normal install with full disk encryption. but otherwise mostly harmless.11:07
apwxnox, what sort of image is that11:07
infinityxnox: We've seen this on curtin installs, IIRC, where initrd is a file instead of a symlink.11:07
infinityxnox: Oh, that was just installed with ubiquity or d-i, then?11:07
apwand when installed11:07
xnoxinfinity, i did d-i, cause wanted to keep my windows 10.11:07
* xnox checks11:08
infinityxnox: link_in_boot = yes?11:08
apwinfinity, i am starting to think i have to just remove these if they are the wrong type, there are just too many of them11:08
xnoxinfinity, link_in_boot = no11:08
infinityOh, that's not link_in_boot, you said /11:08
xnox$ cat media-info11:08
xnoxUbuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160125)11:08
* infinity wonders why he's not actually seen this failure mode yet.11:08
apwinfinity, i don't see how link_in_boot matters, i htink we only notice that there because curtain is making a mess in /boot and you don't notice it if you arn't link_in_boot because there is no name clash11:08
apwinfinity, me too11:09
xnoxwell has ubuntu desktop now, also i noticed that it was lacking "quiet splash" -> which i had to fix manually. Do servers not default to quiet & spalsh, btw?11:09
infinityxnox: Servers default to noisy, I believe.11:09
xnoxok.11:09
apwinfinity, i assume a d-i install is simply a install linux-generic and let the normal mechanics make a mess11:10
infinityapw: Quite.11:10
xnoxapw, i wonder if we should make kernel scripts more resiliant "this is a file, not symlink => purge" before doing anything.11:10
infinityd-i would definitely never be putting a regular file there.11:10
apwinfinity, so this has somehow to be either an initramfs-tools or postinst issue11:10
xnoxcause this ended up failing to upgrade kernle, and generate apport popup11:10
xnoxbut that's a bandaid.11:10
infinityapw: Yeahp, it's going to either be initramfs-tools or linux-image.postinst11:11
xnoxcause we still don't know who or what is making a mess.11:11
apwxnox, making the postinst resilient would be trivial i am sure, but we have at least two different mess makers out there11:11
apwxnox, and i am loath to let them get away with it11:11
apwxnox, i will finish what i am at, and try and do a server install in a vm and see if it goes wrong too11:11
apwthough of course the last milestone should have failed dismally if that was the case11:12
xnoxapw, infinity https://bugs.launchpad.net/ubuntu/+source/linux/+bug/154747111:13
ubottuLaunchpad bug 1547471 in linux (Ubuntu) "package linux-image-4.4.0-6-generic 4.4.0-6.21 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,New]11:13
infinitycpaelzer: Uploaded.11:15
cpaelzerinfinity: thanks++, I'll check excuses and such after lunch11:16
infinitytseliot: Can you verify https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1518958 so we can push those both to updates?11:18
ubottuLaunchpad bug 1518958 in fglrx-installer-updates (Ubuntu Trusty) "SRU Request: fglrx-installer: dkms build failures with linux-lts-wily" [High,Fix committed]11:18
tseliotinfinity: sure, can you approve my nvidia-361 (and -updates) in Xenial NEW, please?11:19
infinitytseliot: Not tonight, it's past 3am, but we'll get there soon.11:20
tseliotok11:20
infinitycpaelzer: Of course, openvswitch-dpdk is now FTBFS: http://paste.ubuntu.com/15130205/11:25
infinitycpaelzer: Have fun. :P11:25
infinitycpaelzer: Definitely looks like libdpdk.so is underlinkes.11:26
infinitys/underlinkes/underlinked/11:27
infinitycpaelzer: http://paste.ubuntu.com/15130215/ < -- You should aim to clear all that up.11:27
infinityAt least missing -ldl and -lm... And one or two others I can't immediately identify.11:28
=== _salem is now known as salem_
cpaelzerinfinity: it is statically linked atm which is a bug #1546550 on its own11:47
ubottubug 1546550 in openvswitch-dpdk (Ubuntu) "openvswitch-switch-dpdk links against libdpdk statically" [Medium,Triaged] https://launchpad.net/bugs/154655011:47
cpaelzerinfinity: there goes my dream that this would have been simple, I'll look into it11:47
dokowillcooke, seb128: what's the goal with the libvdpau / libvdpau-va-gl component mismatch? asking because I'm assing to the vdpau-video and intel-vaapi-driver MIRs11:48
cpaelzerinfinity: I wonder why that didn't show up in my sbuild11:49
infinitycpaelzer: Which bit?  The underlinked stuff?  It probably did show up and you didn't notice.  It's not fatal.11:49
infinitycpaelzer: Unless you mean a test build of openvswitch-dpdk, which I can only assume you did against the old dpdk by accident.11:49
cpaelzerinfinity: I wonder why that didn't show up in my sbuild openvswitch-dpdk, which is why I built against it11:50
cpaelzerinfinity: I guess they meet in proposed11:50
cpaelzerinfinity: and fail there11:51
cpaelzerinfinity: jamespage has already the 2.5 ready (so do I), so I'll patch&test his last 2.5 now11:51
infinitycpaelzer: The bug isn't in openvswitch, though, it's in dpdk.11:52
willcooketjaalton, any thoughts on doko's query? ^11:52
infinitycpaelzer: dpdk.so should be linked to all the libs it uses.11:52
tjaaltondoko,willcooke: no idea, one got promoted before?11:54
dokotjaalton, what do you mean?11:56
tjaaltondoko: willcooke forwarded the question to me..11:57
dokotjaalton, well libvdpau is in main since 2010 ... https://bugs.launchpad.net/ubuntu/+source/libvdpau/+bug/50678811:58
ubottuLaunchpad bug 506788 in libvdpau (Ubuntu) "[MIR] libvdpau" [High,Fix released]11:58
tjaaltonwhat was the question about? the other one is a separate source11:58
dokotjaalton, component mismatch, see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  not sure we want ffmpeg in main11:59
tjaaltonhasn't ffmpeg replaced libav on ubuntu too?12:00
tjaaltonplease be so12:00
dokofeel free to file these 30 MIRs for ffmpeg12:00
tjaaltonheh12:01
tjaaltoni thought it happened in wily12:01
tjaaltonguess not12:01
tjaaltonseb128: ^12:01
davmor2tjaalton: Package: ffmpeg     Version: 7:2.8.4-1ubuntu3    Priority: optional     Section: universe/video12:06
dokolamont, https://launchpadlibrarian.net/240544779/buildlog_ubuntu-xenial-amd64.isc-dhcp_4.3.3-5ubuntu6_BUILDING.txt.gz12:13
dokowanting to link: LDFLAGS="-lirs-export", was in libbind-export-dev12:14
tjaaltondoko: what's the libva MIR?12:19
dokotjaalton, there's none yet (if you click on the svg file, then it wants to open one)12:21
tjaaltondoko: ahh, but libvdpau wants to pull in -va-gl?12:22
dokotjaalton, yes12:23
tjaaltonok then12:24
dokolamont, how to proceed? libirs isn't shipped by bind, and isc-dhcp has the bind subdir removed12:28
dokolamont: looks like we need a correspondeing isc-dhcp 4.3.4? to be released on March 29?12:32
bluesabreLaney: can you run the packageset generation script? We have make some changes to shimmer-themes (with Kubuntu's permisssion) and the package should now appear in the xubuntu packageset again12:32
Laneyok12:33
tjaaltondoko: that's only because libvdpau-va-gl Provides: vdpau-driver?12:35
tjaaltonand should be fixed if libvdpau1 didn't Recommend vdpau-driver12:37
dokotjaalton, but vdpau-driver-all still depends on libvdpau-va-gl112:39
tjaaltonah12:40
tjaaltonsuggests then12:40
seb128doko, tjaalton, I've no idea about ffmpeg vs libav, we should probably follow debian12:40
tjaaltondoes that Recommend matter btw? guess not since vdpau-driver is virtual12:41
tjaaltonseb128: yeah, probably too late though12:41
seb128:-/12:41
tjaaltonamazing noone noticed before :)12:41
dokoseb128, we don't have libav anymore12:41
tjaaltongood12:42
tjaaltonI guess we never had libav provided stuff in main, so it's fine12:46
seb128tjaalton, we had in precise according to https://launchpad.net/distros/ubuntu/+source/libav12:47
tjaaltonseb128: ah, so it seems12:50
rbasaknacc_, jamespage: looks like a new tomcat7 microrelease went into Debian yesterday but didn't make our freeze. Worth a manual sync?12:54
rbasakThere are new build deps, but given freeze was yesterday the release team may be OK with it.12:54
seb128lamont, https://errors.ubuntu.com/problem/ff29324d627eef6e11b0e8b37e37b3f645e6ea9c seems a new issue (but lacks symbols/not very useful so)12:59
seb128bdmurray, ^ do you have any idea why that retracing fails?12:59
=== lucas_ is now known as lucas
tseliotinfinity: all tested13:07
tjaaltondoko: libvdpau fixed, hopefully13:08
slangaseknacc_: fyi, started looking at <2> on https://launchpadlibrarian.net/238303205/php7-archive-admins.howtov4 ; php-zeta-base is listed as only needing a rebuild, but it fails to build with an error in phpunit, possibly because it gained a phpunit build-dep in the 1.9-2 upload?13:13
=== ackkk is now known as ackk
cpaelzerinfinity: FYI I sorted out with jamespage to get the fix to openvswitch-dpdk (that we already had in ppas) combined with my fix13:37
cpaelzerinfinity: the issue you pointed out is still an issue on its own and worked on in #154751713:37
cpaelzerinfinity: thanks13:38
cpaelzershould have written bug #1547517 to get the bot posting the right link13:38
ubottubug 1547517 in dpdk (Ubuntu) "libdpdk should link against the library it uses" [Low,Triaged] https://launchpad.net/bugs/154751713:38
jamespagecpaelzer, just testing both ovs and ovs-dpdk with a snapshot from the 2.5 branch (which is in release stabilization right now)13:44
jamespageand then I'll upload13:44
* dholbach hugs pitti 13:54
jamespagecpaelzer, ok - both uploaded  - tested fine13:55
lamontseb128: Sorry, you are not a member of a group that is allowed to see the data from error reports. Please fill out this form to request access.13:55
lamontseb128: and I have no idea what I'm requesting access to in order to request it... care to smack things over the head as needed?13:58
seb128lamont, bdmurray can probably help there13:58
seb128lamont, it's a segfault which started with the recent xenial update but the retracing fail for some reason so there is no debug symbol so not useful anyway until we get that resolved13:59
cpaelzerjamespage: thanks, I'm happy that both changes go along well14:01
* cpaelzer touches all kind of wood to leave update_excuses now14:01
lamontseb128: segfault in what?14:04
lamontdoko: we may just need to deliver libirs?  not sure?14:05
seb128lamont, http://paste.ubuntu.com/15131566/14:05
lamontbut yes, I suspect that we want to at least consider getting 4.3.4 dhcp for xenial14:05
lamontseb128: hrmpf... which version of bind?  /me suspects 3ubuntu114:06
seb128lamont, in fact we have a bug with a retracing it seems14:06
seb128lamont, reports are from 1:9.10.3.dfsg.P2-3~build3 and 1:9.10.3.dfsg.P2-3~ubuntu114:07
lamontthose are the best, yes? :(14:07
seb128lamont,14:07
seb128 talloc_abort_unknown_value () at ../talloc.c:41714:07
seb128 talloc_chunk_from_ptr (ptr=0x7f1504003140) at ../talloc.c:43614:07
seb128 _talloc_free (ptr=0x7f1504003140, location=0x7f152192e888 "../common/ldb.c:289") at ../talloc.c:162514:07
seb128 ldb_asprintf_errstring (ldb=ldb@entry=0x7f151c226010, format=format@entry=0x7f150adfe4b7 "No such Base DN: %s") at ../common/ldb.c:28914:07
lamontdo we hvae the named.conf files from that trace?14:07
* lamont needs to step away for a few, but will look when he's back online in 20 or so14:08
seb128lamont, I don't think so, apport doesn't seem to have a hook to include that info14:08
lamontseb128: if you can ask the submitter for it, that may help isolate things.14:09
lamontafk14:09
seb128k14:09
dokolamont, yeah, fixing ... cyphermox told me the same14:10
dokopitti, looks like the gnutls transition is blocked on systemd14:11
dokoginggs, cuda doesn't migrate, missing dependency. see excuses_html14:14
ginggsdoko: i saw that, needs nvidia driver for ppc64el, -3 not much different to -2ubuntu114:16
ginggsdoko: i was talking to tseliot about creating an nvidia-tesla-drivers package for ubuntu - neither of us have ppc64el hardware with a gpu for testing14:17
ginggsdoko: and we are working on cuda 7.5 packaging in debian, so hope to have that ready soon14:18
=== juliank_ is now known as juliank
dobeywho is our xrandr expert these days?14:27
seb128I don't think we have one14:28
seb128you can try tjaalton or robert_ancell14:28
seb128or maybe the mir team has people knowing about xrandr as well14:28
dobeytjaalton: around? :)14:34
tjaaltondobey: one foot only14:35
tjaaltonso be quick :)14:35
dobeytjaalton: oh ok. i don't know if this would be quick. i'm wondering if there's some way to "fake" xinerama-like setup with xrandr on intel, using the VIRTUAL1 output to wrap the actual DP1-X outputs14:35
tjaaltondoesn't sound too quick, no :)14:37
tjaaltonwhat are you trying to do?14:37
tjaaltoni mean, why fake-xinerama14:37
dobeytjaalton: i have a 4k display, and only way to get 60Hz is MST, and intel treats it as two completely separate monitors :-/14:38
tjaaltonah14:39
tjaaltonyeah no experience with that, but I bet you're not the only one14:40
tjaaltonwhich cpu?14:40
dobeyi7 4790S14:40
tjaaltonhaswell, might work14:40
tjaaltonskylake doesn't14:40
tjaaltonso if google doesn't help, I can dig something next week14:41
dobeyi guess good thing i didn't upgrade yet then14:41
tjaaltonsame here (to 4k :)14:41
dobeyyeah, searching hasn't been productive so far14:41
dobeyi've been stuck at 30Hz for far too long14:41
tseliotthey implemented RRMonitors exactly for that, IIRC14:44
tseliotthe window manager needs to support that though, I think14:45
dobeytseliot: so we need to fix compiz?14:47
tseliotdobey: that, and the new X https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt?id=randrproto-1.5.014:47
dobeytseliot: so i can't make this work until 16.04?14:48
tseliotdobey: exactly14:48
dobeytseliot: is compiz fixed in 16.04?14:49
tseliotdobey: not yet14:49
dobeytseliot: will it be?14:49
tseliotdobey: maybe ask the maintainers?14:50
tseliotright now the new X breaks hybrid graphics because of the new RandR, so that should be fixed14:51
dobeytseliot: is there no way to use the VIRTUAL1 output in older xorg to redirect the monitors to a single display?14:53
tseliotdobey: not that I know. You can still ask in #intel-gfx or in #xorg-devel14:55
dobeyok14:56
tseliotdobey: on a second thought, simply rebuilding gtk with RandR 1.5 support might work: https://git.gnome.org/browse/gtk+/commit/?id=e670720d196bac1cef6f88313f6514cdd8c4a0c515:06
dobeytseliot: would still need 16.04 for the new X, but hopefully that gtk+ patch will be included. i wonder if anything special will need to be done from chromium/etc though.15:08
tseliotdobey: it turns out the code is already there. Support in X was missing. Maybe you can try the PPA for Xenial?15:11
tseliotbut again, that comes with bugs: https://bugs.launchpad.net/gtk/+bug/154751015:12
ubottuLaunchpad bug 1547510 in GTK+ "display scaling doesn't work with xserver 1.18" [Medium,Confirmed]15:12
dobeytseliot: well, i don't use display scaling, so i guess i'll be fine there :)15:15
tseliotdobey: ok, here's the ppa https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging15:16
dobeytseliot: but i don't think i want to upgrade to xenial yet :)15:17
tseliotfair enough15:17
dobeytseliot: but i'll keep all this in mind when i do. thanks! :)15:23
=== bladernr_ is now known as bladernr
naccpitti: sigh, so last night we might have realized that bootstrapping is altogether unnecessary15:59
naccpitti: meaning we can drop all these deltas15:59
naccpitti: i'll fix up my side to make sure there isn't trailing space, sorry!16:01
naccpitti: i learned about the lp tasks thing only after starting, now i'm doing that :)16:02
Son_Gokunacc: did my patches help with the tests?16:02
naccrbasak: jamespage: i'll try and look at tomcat716:03
naccslangasek: will look at php-zeta-base now16:03
naccSon_Goku: about to kick them off again now16:03
Son_Gokuawesome16:03
dokoapw, tjaalton: please see https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1075780   is this something which should get promoted?16:18
ubottuLaunchpad bug 1075780 in intel-vaapi-driver (Ubuntu) "[MIR] intel-vaapi-driver" [Wishlist,Confirmed]16:18
Laneyxnox: could you send a second cfn for the dmb please?16:19
naccSon_Goku: is it just me or should your patches be numbered 48 and 49?16:33
naccSon_Goku: that is, the php7.0 src seems to have all the old php5 patches in it still?16:33
Son_Gokunacc: it should cleanly apply on top of php7.0 src on master-7.0 branch16:33
Son_Gokuthese are patches that apply to the debian git itself16:34
Son_Gokuthey don’t go into debian/patches16:34
Son_Gokunacc: they apply on top of this: http://anonscm.debian.org/cgit/pkg-php/php.git/log/?h=master-7.016:35
lamontta16:36
lamontbah16:36
naccSon_Goku: oh ... that's not as helpful for me to test (and is also not what adt is testing); can you spin patches that apply on top of the src package16:37
Son_Gokudebian/patches stuff don’t work for fixing tests16:38
naccSon_Goku: good point16:38
Son_Gokunacc: an easy way to apply them is to expand your source tree, initialize with git, and then do “git am </path/to/patches/in/order.patch>” to apply them16:39
Son_Gokuthen repack and rebuild16:39
Son_Gokunacc: I could just go ahead and send them to Ondrej anyway16:40
naccpitti: re: https://launchpad.net/ubuntu/+source/phpunit/5.1.3-1+ubuntu1/+build/9036792 -- i don't see a segfault?16:40
naccpitti: but the issue is probably the one i mentioned in the xdebug bug16:40
=== thegodfather is now known as fabbione
naccSon_Goku: ok, got it, rebuilding php7.0 now to test locally16:48
Son_Gokuawesome16:48
lamontseb128: happily? that trace is against 9.9.5, so it's not related to my most recent mess^Wupload16:58
dokoseb128, Laney: if not seen ... gnome-software doesn't build because of a component mismatch16:59
pittinacc: oh, seems someone retried the test and it's working now, so apparently it happens only sometimes17:02
pittinacc: twig still has a segfault; I can retry too if you think that's useful17:03
naccpitti: testing it now here17:04
naccpitti: will let you know17:04
naccpitti: it's possible the new xdebug went in in between?17:04
naccpitti: hrm, reproduced the twig segfault, debugging it now17:04
dokonacc, remove firebird from b-d's if not yet done17:04
pittiphp7.0 lost its firebird dep today17:05
naccdoko: that's done for php7.017:05
dokota17:05
Laneydoko: it has an approved MIR and was previously in main17:05
seb128doko, it built before and control didn't change, appstream needs to be promoted back17:05
dokoI didn't demote it ...17:05
naccpitti: can you tell me why component-mismatches says php7.0 has a dep on xmlrpc-epi? we dropped it via LP #1547245 ?17:05
ubottuLaunchpad bug 1547245 in php7.0 (Ubuntu) "php7.0: remove dependencies that come from universe" [Undecided,Fix committed] https://launchpad.net/bugs/154724517:05
seb128doko, I guess it was not promoted, sorry, but it has a MIR approved so it can be17:06
Laneyhttps://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1538293/comments/817:06
ubottuLaunchpad bug 1538293 in appstream (Ubuntu) "[MIR] appstream" [Undecided,Fix released]17:06
pittinacc: supposedly the new version is still in -proposed, so it sees the one in ubuntu-release?17:06
pittiseb128: an approved MIR isn't sufficient -- you need something in main to depend on it17:06
naccpitti: ah ha!17:06
naccpitti: thanks :) sorry, some obvious stuff isn't so obvious to me still :)17:06
pittiseb128: otherwise it's on component-mismatches and archive admins demote it back17:06
seb128pitti, right, which is what doko is pointing, gnome-software is deptwaiting on it17:06
seb128but it was probably on component-mismatch for a week or so17:07
dokoseb128, well, I even pasted the commit message17:07
seb128before gnome-software got promoted17:07
dokoinfinity, did you demote packages this week?17:07
seb128doko, right, I guess it was demoted in between17:07
dokoanyway, promoting17:07
infinitydoko: Nope.17:07
LaneyI don't see that it got promoted on +publishinghistory17:07
Laneyhttps://launchpad.net/ubuntu/+source/appstream/+publishinghistory17:07
Laneyso, not sure what happened before17:08
naccpitti: also, i *think* the php-defaults -> dh-php5 dep is a false positive. Because php-json used to be its own src package, but now is a binary package produced by php-defaults17:08
naccand we're going to drop the old src package17:08
seb128doko, thanks17:09
seb128doko, could you have a look to bug #1513922? gdb/python is buggy on i386, the attached patch fixes it17:09
ubottubug 1513922 in gdb (Ubuntu) "[xenial] backtrace gives python error" [High,New] https://launchpad.net/bugs/151392217:10
dokoI think I should promote tomcat8 now17:10
naccpitti: finally, thank you for all your help. I really appreciate it!17:10
infinitylamont: Your bind9 udebs are uninstallable (depend on debs, due to new deps that aren't udebby)17:10
xnoxpitti, ppc64el are all dead?17:11
lamontinfinity: awesome.17:11
* lamont adds that to the list for -417:11
xnoxpitti, could you hint through juju-core? passed everywhere apart from blocked up ppc64el, and we need it for the demo today...17:12
lamontDepends: ${shlibs:Depends}, ${misc:Depends}17:12
lamontPackage-Type: udeb17:12
lamontdammit, I liked using the variables17:12
infinitylamont: Yeah, it's not a bug in your package.17:12
infinitylamont: Except for the part where you're linking libs that aren't udebs.17:12
infinitylamont: It's not debian/control that needs fixing, it's either the other packages that need udebs, or your udeb build of your libs need to have fewer features.17:13
infinity libdns162-udeb : Depends: libgeoip1 but it is not installable17:13
infinity                  Depends: libgssapi-krb5-2 but it is not installable17:13
infinity                  Depends: libkrb5-3 but it is not installable17:13
lamontoh17:13
dokopitti, is systemd: autopkgtest for linux 4.4.0-6.21 really a regression?17:14
infinitylibxml2-udeb seems broken too, for some reason.  Oh, how I love feature freeze.17:14
smoseris anyone else seeing apt 503 from security.ubuntu.com ?17:15
seb128lamont, unsure, maybe the launchpad report is not the same, the e.u.c are no useful info, I guess we need bdmurray or somebody to tell us why the retracing is not working and get that fixed, then we get more info about the issue17:15
lamontseb128: ack17:15
lamontinfinity: looks like I may need to reintroduce the export build/17:15
dokolamont, ugh, why? how many packages need fixing?17:16
dokoseb128, on my list17:16
pittixnox: they will auto-cleanup/restart in an hour, but I restarted them now17:16
lamontdoko: I can't see needing libgeoip in d-i17:16
lamontOTOH, well.17:16
bdmurrayseb128: I'm trying to look at it but the Error Tracker is having some issues at the moment17:17
naccpitti: i think the symfony build goes now (if you add -proposed, where the nwe version of php-proxy-manager is), but that breaks the unit tests ... i'll see if i can fix those up now17:17
lamontthe nice part is that libdns is the boottom of the pile, so it's just those 317:17
seb128bdmurray, hey! ok, thanks17:17
seb128doko, thanks!17:17
bdmurrayseb128: what package was the crash about?17:17
seb128bdmurray, bind917:18
xnoxpitti, well, something is/was odd with them. As e.g. slowest armhf passed juju-core 4 hours ago, and it was available for testing 5 hours ago.17:18
bdmurrayseb128: IIRC that's missing ddebs17:18
pittixnox: hinted juju17:19
seb128bdmurray, I though that missing ddebs was deprecated now that those are in launchpad?17:19
bdmurrayseb128: but there aren't any in LP either17:19
seb128https://launchpad.net/ubuntu/+source/bind9/1:9.10.3.dfsg.P2-3~ubuntu1 lists some though17:20
xnoxseb128, depends. if things were copied from PPAs with bad config, there might not be any ddebs.17:20
pittidoko: no, systemd for anything else than the systemd update itself is not a regression; we need to land the new systemd to fix the ppc64el test, but that's blocked on gnutls17:20
seb128https://launchpad.net/ubuntu/xenial/amd64/bind9-host-dbgsym/1:9.10.3.dfsg.P2-3~ubuntu117:20
pittidoko: systmed/ppc64el has a hint, though17:20
seb128xnox, bind9 is an archive upload and the launchpad build record have them17:20
xnoxseb128, but that package version is superseeded in -proposed.17:20
xnox.... so garbage collected.17:20
dokopitti, but the linux test in systemd is blocking gnutls28  ...17:21
pittidoko: oh, *this* way around17:21
bdmurrayseb128: that's only the -proposed package version17:22
seb128xnox, right, the retracings are from previous days when that was not the case17:22
seb128bdmurray, well the issues are only with proposed versions17:22
pittino, that just looks flaky, it's a failure in apparmor17:22
cjwatsonxnox: binary GC is much much less aggressive than that.17:23
pittidoko: hinted17:23
pittiok, gotta run, cu on Monday17:23
bdmurrayseb128: okay, I'll have a look when errors comes back17:23
seb128bdmurray, thanks17:23
seb128pitti, have a good w.e!17:23
xnoxcjwatson, ok.17:28
jtaylordoko: thanks for the vim-py2 :D17:29
dokojtaylor, otoh this one upstream proposed a py3 compatible package17:30
jtaylordoko: you mean youcompleteme?17:31
dokoyes17:31
dokoor IcompleteYou17:31
jtaylordoko: thats one of many, also I'm not using the package17:31
Pharaoh_Atemnacc: so how are the tests going?17:36
pittixnox: FTR, ppc64el machines are getting serial-killed by some test in trusty:17:39
pittiE: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/e/eglibc/libc-dev-bin_2.19-0ubuntu6.6_ppc64el.deb  404  Not17:39
pitti+Found17:39
pittithis counts as temporary failure and thus they retry17:39
pittiI didn't look into that yet17:39
LaneySomething is going wrong with the apt update17:40
cjwatsonYeah, latest version is 2.19-0ubuntu6.617:40
cjwatsonEr, 6.717:40
cjwatsonpitti: Do you have output from the apt update?17:40
naccPharaoh_Atem: still building php7.0 :) it's a bit big to get to all the .debs17:41
Pharaoh_Atemyeah, I know :/17:41
naccPharaoh_Atem: will ping you as soon as they are going17:41
Pharaoh_Atemnacc: awesome17:45
infinitylamont: PS: This is blocking d-i, which is blocking the kernel, so ick.17:46
naccPharaoh_Atem: kicking off the tests now17:46
Pharaoh_Atem:D17:47
lamontinfinity: ack17:49
jtaylorinfinity: I hope feature freeze does not mean no glibc update anymore?18:07
jtayloris there something I can do to help?18:09
naccPharaoh_Atem: ok, mod-php tests fixed, but fpm still fails18:18
naccPharaoh_Atem: is it possibly due to not restarting apache2? i really don't know much about what's ahppening, but see this line:18:19
nacc"To activate the new configuration, you need to run: service apache2 restart18:19
Pharaoh_Atemhmm18:20
Pharaoh_Atemthe fpm test does have an apache2 restart call18:21
naccPharaoh_Atem: ok18:22
Pharaoh_Atemnacc: do you have the output from the fpm test?18:23
naccPharaoh_Atem: no ... running again to get it18:32
=== dx- is now known as dx
Pharaoh_Atemnacc: thank you18:34
infinityjtaylor: I fully intend to break my own freeze, I got stuck at a sprint this week, so I'm delayed a tad.18:38
rbasakIf a conffile is renamed, is the old name supposed to still show as obsolete in "dpkg -s"? If not, then what's the mechanism dpkg uses to make it not appear there?18:45
* rbasak goes afk, but will see replies in the next hour or two but will be offline for the weekend after that18:52
tewardwho was working on php7 again...?  I forget, and I probably should know by now :P18:54
sarnoldteward: nacc18:55
tewardthank you :)18:55
tewardnacc: ping, if you're not busy, regarding php7 and fpm19:02
tewardnacc: With regards to php7 and fpm, php5 had the defaults, in Debian, to listen on a UNIX socket by default; has this been evaluated as a comparison to listening on a UNIX socket, and which way is implemented in php7.0-fpm for Xenial?19:04
tewarddepending on the answer there, I may or may not have to modify the default nginx configuration files to adapt19:04
* teward should have checked this before but forgot19:04
Pharaoh_Atemteward: it's set to use a Unix socket now19:05
tewardPharaoh_Atem: i'm looking at the package in proposed and don't see that, if you can point me at where that change was done?19:06
Pharaoh_Atemwith php7.0, it uses a Unix socket by default because httpd 2.4.10 and newer supports using a Unix socket through mod_proxy_fcgi19:06
tewardahhh, okay19:06
Pharaoh_AtemDebian 8 includes httpd 2.4.12, and Ubuntu 16.04 LTS includes a newer version19:07
tewardPharaoh_Atem: do you know what path it's using for the Unix socket?  So I can update the nginx default configuration, after I check to make sure it doesn't need an FFe :P19:07
Pharaoh_Atemteward: yes19:07
* Pharaoh_Atem wrote the new httpd php-fpm config, so he figured all this out19:07
Pharaoh_Atemthe path is /run/php/php@PHP_VERSION@-fpm.sock19:07
Pharaoh_Atemwith @PHP_VERSION@ being replaced dynamically with the correct version number (7.0 in this case)19:08
tewardah, wonderful, now I know what I need to change :)  thank you and nacc for your work on it :)19:08
Pharaoh_Atemno problem19:08
naccPharaoh_Atem: thanks for helping out19:11
Pharaoh_Atemno problem19:11
naccPharaoh_Atem: still trying to figure out why fpm is failing, no logs produces that say exactly why19:11
Pharaoh_Atemthat's frustrating19:11
naccPharaoh_Atem: just a non-zero exit status19:11
Pharaoh_AtemO.o19:12
naccI *think* the tests are actually passing19:12
Pharaoh_AtemI think they are too19:12
Pharaoh_Atembecause when I manually run them as normal scripts, it works correctly19:12
naccPharaoh_Atem: hrm, if the test returns false at the end19:14
naccwont' it be RC=1?19:14
naccPharaoh_Atem: ok, i'm trying to reproduce it manually in a schroot19:18
naccPharaoh_Atem: couple of questions19:18
nacca2enconf php7.0-fpm19:18
naccERROR: Conf php7.0-fpm does not exist!19:18
naccis that expected?19:18
naccalso, dont' you need Depends: wget in the fpm test? (it wasn't installed by default in my schroot for instance)19:19
Pharaoh_Atemhmm19:21
Pharaoh_Atemit doesn't exist?19:21
Pharaoh_Atemthat's... weird19:21
nacchrm, i also get19:22
nacca2disconf php7.0-cgi19:22
naccERROR: Conf php7.0-cgi does not exist!19:23
Pharaoh_Atemif it's not been enabled, it should say that, I think19:23
naccok19:24
Pharaoh_Atemso... it looks like my config file is not being installed19:24
Pharaoh_Atemthat might be why it's not working19:25
naccphp7.0-fpm: /usr/lib/tmpfiles.d/php7.0-fpm.conf19:25
Pharaoh_Atemthat's not the one I care about19:25
naccthere's no other php7.0-fpm.conf in the archive?19:26
Pharaoh_Atemthere should be /etc/apache2/conf-available/php7.0-fpm.conf19:26
Pharaoh_Atemthe sources have a php-fpm.apache2 file19:26
naccphp7.0-cgi: /etc/apache2/conf-available/php7.0-cgi.conf19:26
naccphp7.0-fpm: /usr/lib/tmpfiles.d/php7.0-fpm.conf19:26
naccphp7.0-fpm is busted?19:26
Pharaoh_AtemI think it's not installing the apache2 conf file19:26
naccPharaoh_Atem: it's not in the package19:27
Pharaoh_Atembut it is installing the tmpfiles conf file19:27
naccPharaoh_Atem: you should fix the fpm test to do the same checks as cgi19:27
naccwould tell us if that's the case pretty easily19:28
Pharaoh_Atemah, yes19:28
Pharaoh_Atemls19:28
naccPharaoh_Atem: and probably mod-php should be updated too :)19:29
Pharaoh_Atemhmm, good point19:29
naccPharaoh_Atem: ok, so if i manually put the src package's conf file in the right place a2enconf does work19:34
Pharaoh_Atemwhat am I missing to make it install correctly?19:36
naccPharaoh_Atem: not sure, but if i do that and then manually `service start php7.0-fpm`, the test works19:36
naccPharaoh_Atem: so those two bits are what is missing right now, afaict19:36
Pharaoh_Atemyeah19:37
Pharaoh_Atemwell, I'm also adding the file checks to the tests19:37
asperhey folks. if i install xenial now. will i have to modify my apt-sources to get of the development branch, when it gets released?19:37
Pharaoh_Atemno19:37
Pharaoh_Atemit'll transition to release state automatically19:37
Pharaoh_Atemafaik, there's no actual devel branch maintained publicly?19:37
asperok thanks. at least one good message today. :)19:38
kyrofaCan anyone explain why sid has sbcl for essentially every arch (https://packages.debian.org/sid/sbcl) and xenial only has it for amd64 and i386 (http://packages.ubuntu.com/xenial/sbcl)?19:38
tewardkyrofa: fail to builds, it looks like19:39
tewardoh, um, i read the wrong line ;)19:40
teward(disregard me)19:40
kyrofateward, haha19:40
kyrofaI mean... the autosync should just pull them over, right?19:41
tewardkyrofa: i will point out that packages.ubuntu.com is not the best source of information for what is and is not available in the repositories...19:41
Pharaoh_Atemteward: please don't tell me that19:41
sarnolde.g. here's a powerpc package.. https://launchpad.net/ubuntu/+source/sbcl/2:1.3.0-1ubuntu1/+build/832218719:41
kyrofateward, understood, but it reflects what I'm seeing from arm64 at least19:41
nacckyrofa: https://launchpad.net/ubuntu/+source/sbcl/19:41
tewardkyrofa: well, arm64 is stuck on depwait19:42
nacckyrofa: you can see underneath the current xenial version19:42
tewardon both the current and proposed19:42
naccthe builds and as teward just said19:42
tewardhttps://launchpad.net/ubuntu/+source/sbcl/2:1.3.0-1ubuntu119:42
teward^ that's what's in Xenial now (not proposed, which has FTBFS on all archs and depwait for arm64)19:42
naccteward: is it just me or is that depwait never going to resolve? given the older versions of sbcl wasn't built for arm64?19:43
naccMissing build dependencies: sbcl (> 1:0.9.5.50-9)19:43
tewardnacc: no clue, sorry, i just happened to be poking launchpad.net looking at other things on my radar, when the question came in and i started poking at that one in LP19:44
tewardnacc: probably won't ever resolve, though, no.19:44
tewardthough, given the thing's in Universe, i'm not 100% concerned19:44
naccteward: sure, just wondering if that's normal19:44
naccteward: looks to be a bootstrap-y situtation19:44
nacc*situation19:44
tewardnacc: I've never seen it, but what I focus on specifically, myself, is very narrow19:44
tewardso, that may be why i've never seen it :)19:45
naccheh19:45
tewardfinally the thing accepts the bugfix only upload to fix the nginx default config issues that needed addressed due to php7.0 replacing php5 xD19:46
kyrofanacc, teward is there a way to fix that? It's blocking me at the moment19:46
nacckyrofa: is it expected for sbcl to need sbcl to build? is there a restricted build that can be done (staged build or so)?19:47
robert_ancellupload.ubuntu.com down?19:47
robert_ancellback again19:48
kyrofanacc, heh, I have no clue. All I know is that it's a dependency of the code I'm trying to build19:48
tewardrobert_ancell: it looks like a delay is all19:48
tewardfinally came though for my upload heh19:48
robert_ancellteward, I was getting connection refused :(19:48
tewardah19:49
tewardthen i'm lucky ;)19:49
naccPharaoh_Atem: hrm, i noticed this19:49
naccoverride_dh_apache2: for sapi in apache2 cgi; do \19:49
naccshould fpm be there too?19:49
naccPharaoh_Atem: in d/rules19:49
kyrofanacc, but indeed, that dependency seems a bit bogus19:50
pepeefor kernel bugs, is it better to report to ubuntu, or upstream?19:50
kyrofaThen again... it's lisp :P19:50
sarnoldpepee: ubuntu -- a bot will mmediately mark the bug for expiration and ask you to do some testing with upstream packaged kernels (it'll include links, etc..)19:54
nacckyrofa: ifeq (,$(BOOTSTRAPLISP)) BOOTSTRAPLISP=/usr/bin/sbcl --disable-debugger --no-sysinit --no-userinit19:55
naccendif19:55
nacci think it's a real dep :/19:55
kyrofanacc, yikes19:55
kyrofanacc, I've not seen that before19:55
kyrofanacc, so it must require some sort of staged build, then19:56
naccand the later on19:56
nacc./make.sh --xc-host="$(BOOTSTRAPLISP)" --prefix=$(CURDIR)/stage1 $(FEATURES)19:56
naccyeah, it basically seems to require a lisp to already be there :)19:56
nacckyrofa: i know nothing about lisp, but that's just my reading of the package19:57
kyrofanacc, unfortunately, neither do I. I'll continue to investigate19:58
doko fixed bind9 accepted19:58
dokolamont, infinity: ^^^19:58
pepeesarnold, what if I submit kernel bugs manually? also, by "better" I mean, which is quicker...20:01
pepee*which one... this is the bug, btw: https://bugs.launchpad.net/ubuntu/+source/linux-lts-wily/+bug/1545401  I also asked in #ubuntu-bugs, no one has replied so far20:02
ubottuLaunchpad bug 1545401 in linux-lts-wily (Ubuntu) ""kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/mm/memory.c:3146!"" [Undecided,New]20:02
sarnoldpepee: 'manually'? also, quicker for whom and for what? :) just filing an issue? or getting a fix to a few million people?20:02
pepeequicker as in, the less time from "submitted" to "solved"20:03
sarnoldprobably submitting to launchpad; it'll still take work on your end but I think it'll get to someone who can fix it faster that way20:04
pepeesarnold, ah, thanks20:06
Unit193infinity: ...I don't suppose any way to get a package uploaded, jump from 2.2.28 → 2.2.33 (Debian unreleased vcs) without a ffe, even if they are very minor bug fix releases? :320:10
naccPharaoh_Atem: any experience with phpunit?20:12
Pharaoh_Atemnacc: not much20:19
Pharaoh_AtemI've only really run unit tests20:19
Pharaoh_Atemwhy?20:19
Pharaoh_Atemnacc: also, in re d/rules, you're right20:20
Pharaoh_Atemit should be there too20:20
infinityUnit193: If it's all bugfixes, the version number is irrelevant.20:23
Unit193Hoho!  I may be in luck.20:24
naccPharaoh_Atem: cool, maybe that's the issue?20:34
naccPharaoh_Atem: and np on phpunit, i'll learn20:34
Unit193Men, it's potentially uploadable. :320:34
Pharaoh_Atemnacc: sent you new patch series to try20:35
Pharaoh_Atemplease try asap20:35
gsedeji have issue with dependency on 16.04 daily, where should I ask (libtinfo5:i386 breaks libtinfo5 on 64b)20:40
naccPharaoh_Atem: will do20:41
naccPharaoh_Atem: will take time to build, etc20:41
naccpitti: for now i have had to skip those twig tests20:44
naccpitti: i've filed upstream issues for each20:44
Pharaoh_Atemnacc: that's fine21:06
cjwatsonkyrofa,nacc: language implementations often have self-build-depends.  we can certainly bootstrap that on arm64, but it would help if somebody (Logan?) could work out why the current version is failing to build everywhere21:34
cjwatsonkyrofa: if you want to help unblock this, that would be a good thing to investigate.  https://launchpad.net/ubuntu/+source/sbcl/2:1.3.1-1ubuntu121:35
Loganhi21:35
nacccjwatson: yep, it makes sense21:35
Loganah yes, I was looking into the sbcl failures21:36
naccLogan: kyrofa was asking about sbcl earlier -- seems like arm64 is stuck becuase it needs sbcl to already exist?21:36
Loganright, as cjwatson said, we can bootstrap21:36
Loganbut we first need to figure out why this minor point release I uploaded yesterday suddenly fails to build on all architectures21:37
Loganwell no, it was 1.2.14 to 1.3.0, so I guess that's not a minor point release21:37
Loganno21:37
cjwatson1.3.0 worked, it was 1.3.1 that failed21:37
Loganit was 1.3.0 to 1.3.121:37
Loganyes21:37
cjwatsonLogan: let me know when I'm good to run a bootstrap cycle21:38
cjwatsonI probably won't remember unprompted21:38
Loganit was some sort of etex failure21:38
Loganurgh21:38
Logancjwatson: sure thing21:38
LoganI love debugging TeX issues (not)21:38
Loganlemme run a test build in my Debian chroot and see if it's failing there21:38
LoganI can rope in the sbcl maintainer21:39
naccslangasek: ah! i see php-zeta-base changed versions since i bootstrapped21:41
naccslangasek: testing now to figure out what's needed21:41
=== salem_ is now known as _salem
naccPharaoh_Atem: cp debian/php7.0-fpm.conf debian/php7.0-fpm/etc/apache2/conf-available/21:50
nacccp: cannot stat 'debian/php7.0-fpm.conf': No such file or directory21:50
Pharaoh_Atemgrr21:50
naccbecuase it's debain/php-fpm.conf ?21:52
Pharaoh_Atemso there's something that's missing to go from debian/php-fpm.conf to debian/php7.0-fpm.conf21:52
Pharaoh_Atemnacc: php-cgi's conf does the correct transformation21:52
Pharaoh_Atemnacc: I think I figured it out!21:57
Pharaoh_Atemnacc: sent you a new patch to add on top of the current series21:59
Pharaoh_Atemplease test21:59
naccPharaoh_Atem: ok, will do22:00
Pharaoh_Atemmy god22:01
Pharaoh_Atemthis package is so convoluted22:01
Pharaoh_Atemnacc: I'm hoping that I'll finally have it, and once it works, I can send all of these patches to Ondrej22:25
naccPharaoh_Atem: still building, will let you know22:26
naccPharaoh_Atem: right, and we'll need to file a bug to update ubuntu, i think, as sync is off now22:26
Pharaoh_Atemright22:32
Pharaoh_Atembut I'll be happy just to get these tests beaten into shape22:32
Pharaoh_Atemthen it'll be a matter of taking a look at the php5 bugs filed for fpm and seeing if they even still apply22:34
naccPharaoh_Atem: right22:35
naccslangasek: ha, in between my bootstrap and your update, they added phpunit as a build-dep and run the tests at build tim e:)22:35
Pharaoh_Atemnacc: I'm glad the php-pear circular dependency has been broken22:38
Pharaoh_Atemthat was annoying when upgrading php in the past22:38
Pharaoh_Atembut afaik, phpunit is a new circular dependency?22:40
naccPharaoh_Atem: well, it's confusing, but i think because php 7 and php5 are coinstallable in debian and we are syncd (as of yesterday), phpunit isn't a problem anymore22:41
Pharaoh_Atemah22:42
naccslangasek: file a MIR to promote xmlrpc-epi (and then we can reenable php7.0-xmlrpc)22:42
sarnoldwow, xmlrpc-epi's mail list looks a bit idle, https://sourceforge.net/p/xmlrpc-epi/mailman/xmlrpc-epi-devel/22:44
sarnoldone message since 2008-11-0522:45
naccsarnold: yeah, not great22:45
sarnoldmaybe that's because it's perfect22:45
sarnoldbut it has both 'xml' and 'rpc' in the name so I'm suspicious22:46
rharperlol22:46
naccsarnold: yep, i realize it's a possible issue22:46
naccsarnold: i *think* we could also go down the path of having a distinct src package in xenial/universe for just php-xmlrpc, but then we have to keep it in sync (or should try) with php7 (it's actual source) in main22:47
naccsarnold: but that's just my current opinion22:47
sarnoldnacc: not ideal either, heh22:47
naccPharaoh_Atem: tests are starting up again now23:02
slangaseknacc: separate source package> or we could focus on getting the build-dep MIR problem solved ;)23:32
slangaseknacc: fwiw I believe all of your bootstrap patches are still appropriate (e.g. for the case of a from-scratch bootstrap), even if not required right now for the transition.  I suggest that you forward the remainder up to Debian23:32
slangaseknacc: and yeah, php-zeta-base now uses phpunit, but phpunit has rebuilt for php 7 and php-zeta-base is still failing23:33
naccslangasek: yeah, it looks to be a real issue with php-zeta-base and php723:34
slangasekso, someone needs to make sense of that23:34
slangasekok23:34
naccslangasek: i'm working on fixing it23:34
slangasekok great23:35
sarnoldslangasek: probably php7-xmlrpc will runtime-depend upon xmlrpc-epi if it build-depends upon it.. heh23:38
slangaseksarnold: yes, but php7 build-depending on xmlrpc-epi and spitting the php7-xmlrpc binary out to universe would be A-OK23:38
sarnoldslangasek: oh!23:38
naccslangasek: right, that's something i meant to ask about -- i think i've seen src in main producing binaries inmain & universe23:39
naccbut the build-dep would still need to be in main, right?23:39
slangaseknacc: only under the current model, which we are trying to change23:39
naccslangasek: ah right23:40
naccsarnold: fyi, you're right, php7.0-xmlrpc depends on libxmlrpc-epi023:40
naccslangasek: would that be an approach we could take for the other bin packages we have removed as well?23:41
slangaseknacc: yes23:41
naccslangasek: cool! would simplify things greatly for me23:41
naccslangasek: and would make our delta smaller23:41
naccslangasek: so ... i *think* 7 of the 10 failures we see in sbuild are because we're root?23:45
naccslangasek: i'm not sure why debian doesn't see the same problem, though23:45
naccslangasek: i created a dummy user in an schroot and the tests passed23:45
naccslangasek: because root doesn't respect file permissions23:46
slangaseknacc: we don't run anything in the build as root23:46
naccslangasek: ok, that's good -- so probably just my env23:47
naccslangasek: so i'm back to the original 3 issues :)23:47
slangaseknacc: and I reproduced the problem here (we're talking about php-zeta-base, right?) - you are pulling your build-deps from -proposed, not just from xenial?23:47
naccslangasek: yeah, i reproduced it here too23:48
slangasekok23:49
naccslangasek: not directly related, but similar, for tomcat8 -> main (and tomcat7 in universe), now that the seed change has been merged, I don't need to do a MIR? once tomcat8 is in main, there won't be any comonent-mismatches, afaict23:56
slangaseknacc: should not need to do an MIR, correct.  Do similarly need to make sure that we make it a clean swap23:57
naccslangasek: right23:57
naccslangasek: at least in that case, since we're keeping tomcat7, it's a little easier23:57
slangaseknacc: and php-guzzlehttp FTBFS23:58

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