[00:00] roaksoax: do you want to upload that? [00:00] roaksoax: I was about to go to bed. [00:13] nacc_: and the php7.0-cli dependency on libqdbm14 (universe) needs to be resolved before pkg-php-tools is buildable [00:17] slangasek: ok, the build of php7.0 takes a while, so i'm waiting for it to finish before submitting the debdiff [00:18] 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:48] nacc_: ok. please do point me at the debdiff once you've uploaded it [00:52] slangasek: will do -- also, i'm finally looking at LP: #cobbler 1543820 [00:52] gah [00:52] LP: #1543820 [00:52] Launchpad bug 1543820 in jmespath.php (Ubuntu) "jmespath.php: add nocheck and stage1 build profiles" [Wishlist,New] https://launchpad.net/bugs/1543820 [00:52] excellent [00:52] i understand the test: target issue [00:52] but i don't know how to fixup the coverage: one? [00:53] and test: is a dependency for all: [00:53] actually [00:54] 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 build [01:01] slangasek: urgh, sorry, was confusing that and LP #1543817 [01:01] Launchpad bug 1543817 in php-guzzlehttp-psr7 (Ubuntu) "php-guzzlehttp-psr7: add nocheck and stage1 build profiles" [Wishlist,Incomplete] https://launchpad.net/bugs/1543817 [01:01] it feels like they will have the same answer, though [01:01] 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:11] slangasek: fyi, build just finished, works w/ debdiff from LP: #1547245 [01:11] Launchpad bug 1547245 in php7.0 (Ubuntu) "php7.0: remove dependencies that come from universe" [Undecided,New] https://launchpad.net/bugs/1547245 [01:17] nacc_: php5-xmlrpc is in main and doesn't depend on xmlrpc-epi; is this maybe an optional dependency? [01:19] nacc_: 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] 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] ok [01:20] nacc_: 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 us [01:20] slangasek: well, here's the really confusing part with php5 [01:22] well, maybe a side discussion [01:23] php5 and php5.6 are different src pckages [01:23] :) [01:23] it leads to some weirdness and i don't know why it's that way, tbh [01:23] but i can do the MIR for packages that now won't exist [01:24] slangasek: so far that's php-xmlrpc, php-interbase and php-imap (with their corresponding 7.0 names) [01:25] hmm yes [01:25] I don't know why that is [01:26] which of those packages will exist when xenial is released? php5? php5.6? php7? [01:27] only php7 [01:27] is the plan [01:27] sarnold: --^ [01:28] nacc_: no php 5.x in xenial, even in universe? [01:28] sarnold: correct [01:28] sarnold: if you want php5 stay on 14.04 LTS [01:28] wow, feels ambitious :) woo. thanks. [01:33] nacc_: so we're doing the php7 move? [01:33] awesome [01:34] meanwhile, 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 fashion [01:34] jsalisbury, that dir you sent me for the kernel to test is empty [01:36] nacc_: 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 me [01:48] slangasek: I'm actually trying to fix them [01:48] the 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 VM [01:48] however, autopkgtest is failing for whatever reason [01:49] slangasek: Pharaoh_Atem: i'll try and take a look [01:49] nacc_: my theory is that all the a2* commands need to be guarded to redirect their output to /dev/null and set to OR with true [01:49] but I've been having a hell of a time trying to prove that [01:50] Pharaoh_Atem: hrm [01:50] pbuilder and sbuild make me want to hurt people [01:50] I've never encountered a more obnoxious chroot builder tool [01:51] err, package builder tool using chroots [01:51] i'm suriously surprised no one's replaced them with lbuild for lxc or kbuild for kvm.. [01:52] Pharaoh_Atem: trying it locally, will let you know [01:52] nacc_: awesome [01:52] thanks [01:52] sarnold: this is the first time I've attempted to build debian packages using pbuilder and the like in quite a while [01:53] most of the time, I just use open build service [01:53] 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] nacc_: if you need my patch diff, I can send it to you [01:55] 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.dsc [01:55] err [01:56] php7.0-cli Breaks: php5-cli (<< 5.6.16+dfsg-4~) [01:58] slangasek: i *think* those exist because in debian they are coinstallable [01:58] nacc_: I'm also going through and ensuring that every test turns off stuff that could potentially conflict that was turned on by other tests [02:00] nacc_: 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 same [02:01] slangasek: ah ok, so sort of the same process, but for each of these [02:01] got it [02:01] sarnold: is there anything that's as simple as RH/Fedora's mock for Debian packages? [02:02] nacc_: regarding the breaks, if the package is policy-compliant then that's because php7.0-cli took over some file previously provided by php5-cli [02:02] if they're coinstallable and no bootstrap is needed, then that's peachy :) [02:02] slangasek: well, they are possibly now :/ frustrating given how much time i spent on it, but yeah, much easier [02:03] i think that means we can just start building stuff once we have the updated pkg-php-tools and php-pear [02:03] neat [02:03] very possible [02:03] although i'm not sure if they'll automatically pull in the php7 deps [02:03] Pharaoh_Atem: sorry, I've never heard of mock; what does it do? [02:03] i'll need to test that with the current archive [02:03] that depends how their build-depends are listed [02:03] anything that was on your list for "rebuild only" should pull in the php7 versions of packages, yes [02:04] sarnold: http://linuxmanpages.net/manpages/fedora21/man1/mock.1.html [02:04] it takes Source RPMs and can rebuild them for any arbitrary target [02:04] into binary packages [02:04] it can also create generic chroots that you can use for arbitrary purposes [02:04] 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 sure [02:05] ah [02:05] sarnold: it's actually available in Ubuntu, too :P ( http://manpages.ubuntu.com/manpages/wily/en/man1/mock.1.html ) [02:05] hah [02:05] the version in Ubuntu is a tad bit old, but it works [02:05] 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:06] Pharaoh_Atem: schroot manges the chroot bits.. sbuild uses them to build packages.. [02:06] Pharaoh_Atem: debootstrap can populate a directory with a debian / ubuntu install [02:07] nacc_: 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 appropriate [02:07] 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] ok, i'll spend some time tmrw morning, if that's ok with you, thinking about that [02:07] sarnold: 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] nacc_: 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 rebuilds [02:07] sorry, I mean if they aren't doing the right thing [02:07] slangasek: right [02:08] Pharaoh_Atem: have you seen this yet? https://wiki.ubuntu.com/SimpleSbuild [02:08] yeah [02:08] slangasek: i'm starting to think that possibly we'll be able to just build straight through in the right order [02:08] I've been trying to set that up [02:08] slangasek: but that's what i'd like to confirm tmrw before we kick it off [02:08] nacc_: ok [02:09] sarnold: it just finished building the chroot tarball, so I think it might actually work, just maybe possibly... [02:09] slangasek: and pkg-php-tools should be able to go once php7.0 is updated? [02:09] nacc_: yes [02:10] nacc_: so I'll retry that build as soon as php7.0 is done, which I'm expecting to be in less than a half hour [02:10] slangasek: yeah it takes a while, i noticed, but that was on my laptop :) === beisner- is now known as beisner [02:10] slangasek: thanks for all your help! [02:11] i really appreiate it [02:11] no prob [02:15] slangasek: sigh, just confirmed, e.g., that php-guzzlehttp-psr7 can just be rebuilt against xenial w/o bootstrap/modification [02:15] slangasek: there's two weeks+ of work that can be tossed :) [02:15] oh well, learned a lot [02:16] nacc_: at least you enjoyed it, right? [02:16] or did you hate everything :P [02:16] Pharaoh_Atem: no it was good, just stressful :) [02:16] nacc_: interesting, is this because something changed out from underneath you with php5-cli? [02:17] slangasek: yeah, debian has updated both php5 and php7 past the point where there was a conflict in the build-deps [02:17] err, in the binary packages [02:17] * slangasek nods [02:17] so, a race condition [02:17] e.g., when i started, php7.0-cli and php5-cli conflicted [02:17] now they don't :) [02:17] yeh [02:17] so that means a mass import for the php stack will fix everything? [02:17] Pharaoh_Atem: that's what i need to check [02:18] Pharaoh_Atem: I *think* the debian packages right now still refer to php5 in their deps [02:18] guh [02:18] Pharaoh_Atem: because debian hasn't uploaded the new php-pear and pkg-php-tools [02:18] that's the step that will diverge for now in ubuntu [02:18] that won't be for very long, practically speaking [02:18] with the understanding that what we have is what debian has in their git tree(s) [02:18] yeah [02:18] so it's a very known delta to carry for hopefully a short amount of time [02:19] that's why I've been submitting fixes to php7.0 to their git tree [02:19] yep and those have all been sync'd to ubuntu already, afaict [02:19] I've had some testing of it done against our applications [02:19] the fpm stuff has not [02:19] Pharaoh_Atem: ok [02:19] ondrej didn't see my patches and only applied the newest set from last week yesterday [02:20] Pharaoh_Atem: you saw this, right? [02:20] /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 nonexistent [02:20] no, I didn't [02:20] that's weird [02:20] it's in the middle of the bulid log [02:20] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/php7.0/20160217_205539@/log.gz [02:21] 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] is /var/www/html not your default path? [02:21] nacc_: archive version [02:21] Pharaoh_Atem: that's the archive's build [02:21] I'm extremely confused now [02:22] http://autopkgtest.ubuntu.com/packages/p/php7.0/xenial/amd64/ [02:22] start there [02:22] then test log [02:22] ah [02:22] now I get it [02:22] that's what i assume you were trying to resolve (as those tests need to pass) [02:23] yes [02:23] weirdly enough [02:23] that's not a test I modified [02:26] hold on [02:26] hold the phone [02:26] I think I *might* know why [02:26] I hope I'm wrong [02:26] because otherwise this will be really dumb [02:27] nope, libapache2-mod-php7.0 depends on apache2 [02:28] oh, wait [02:28] nacc_: I know what happened [02:28] libapache2-mod-php7.0 doesn't depend on apache2, only apache2-bin [02:28] the directory is created when apache2 is installed [02:28] NOT when apache2-bin is installed [02:28] * Pharaoh_Atem groans [02:30] nacc_: so basically, I need to add apache2 as a dep to the mod-php test [02:31] nacc_: it worked for me before because apache2 was installed [02:31] but this builder environment didn't have it === juliank is now known as Guest490 === juliank_ is now known as juliank [02:36] Pharaoh_Atem: glad to help :) [02:36] Pharaoh_Atem: will that fix fpm too? [02:36] fpm already had apache2 as a dep, but I think the other fix I made should make things better [02:36] if you'd be so kind to test a pair of patches I'll send your way? [02:37] Pharaoh_Atem: sure just e-mail them to me [02:39] nacc_: they should be in your canonical inbox [02:41] Pharaoh_Atem: ok ,might not get to it til the am, fyi [02:41] Pharaoh_Atem: working on dinner at the moment :) [02:43] that's okay [02:44] hopefully it fixes those tests [02:46] if these are good, I'll send them up to Ondrej for inclusion in the master-7.0 dgit [05:48] good morning [06:35] Good morning [06:35] stgraber: yes, it was broken due to a proxy issue, I fixed it last night [06:39] 5 [07:08] we have a test failing in dep8/autopkg runs due to sse3 not being available [07:08] which makes sense as the default vm has only up to sse2 [07:09] I wonder if there is a way to define a d/t/control in a way so that tests would have sse3 available or something similar [07:09] cpaelzer: your test could detect that and just skip itself (i. e. early exit 0) [07:09] locally I confirmed that providing adt-run with "--qemu-options='-cpu qemu64,+ssse3' " it works [07:09] but this bears the question, how is that going to work on an real system? [07:10] it is supposed to only work on real systems with >=sse3 [07:10] disabling that would mean disabling all tests, so I wondered if there would be any way [07:11] of corse in the worst case one might detect and early exit, but keep the tests for those who run it local with the qemu options [07:11] cpaelzer: if only some of the tests need ss3, then only check it there? [07:11] pitti: all of them need it [07:12] but I'd really like to check if there is really no way to get such options passed properly before disabling it [07:12] cpaelzer: so where is "disabling that would mean disabling all tests" a problem then? [07:12] if your debian/tests/whatever just checks /proc/cpuinfo and prints a sensible message and exits 0? [07:12] pitti: the problem would be no dep8 tests in normal CI on package upload [07:12] if none of the tests below can run, then you aren't losing anything [07:13] right, but that's nothing the test itself can influence [07:13] a test doesn't have magic powers over the testbed you are running it on [07:14] pitti: ok, I'd hoped there would be a way to force the test env to have such properties - like the isolation or class flags [07:14] pitti: but thanks I really just wanted to make sure there is no easy way to get sse3 in the test env overlooked [07:14] cpaelzer, ok - lets just put a check in the test to skip the tests if sse if not found then [07:14] jamespage: ok [07:15] I'm not really around this morning - if you can't find a sponsor, I'll pickup pm today [07:15] cpaelzer: no, this kind of feature test is way too specific [07:15] cpaelzer: I don't have control over the -cpu flags in production, we are using scalingstack instances, not direct QEMU invocations [07:15] jamespage: ok, I'll pull the current package make the check happen test it and look around - if no one is here I'll mail you [07:16] pitti: the only thing we could control there could be via a flavor maybe [07:17] ah I see autopkgtest is a flavour already [07:17] it is probably too much, for just this test to put extra effort there [07:21] on-site aptop repair incoming - til later [07:35] @pilot in === 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 [07:49] good morning [08:10] did anything change on archive.ubuntu.com recently? [08:11] my squid-deb-proxy is reporting 503 errors for URLs like http://security.ubuntu.com/ubuntu/dists/precise-security/main/binary-amd64/Packages [08:11] (and also archive.ubuntu.com) [08:11] and then actual security updates fail with apt hash mismatch errors [08:12] ("WARNING: The following packages cannot be authenticated") [08:19] cjwatson, could you have a look, if ghc can be built with llvm-3.8 (or -3.6) instead of 3.5? [08:48] doko: should pkcon be willing to install a file called com.ubuntu.terminal_0.7.170_multi.click on amd64? [08:48] (it says "Fatal error: Wrong architecture 'multi'") [08:48] I'm jus asking you since yourname is in the changelog, [08:49] though it looks like you just fixed the bulid, nm [08:49] hallyn, I have no idea about click ... [08:49] doko: yeah, sorry to bother you [08:49] the whole chnagelog is a lot of "rebuild" :) [08:53] pitti, nacc_: how many packages depend on swig's php support? [09:04] dholbach, Morning [09:04] hi flexiondotorg_ [09:09] seb128, Laney, willcooke: fyi, https://bugs.launchpad.net/ubuntu/+source/lua-bitop/+bug/1547395 [09:09] Launchpad bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New] [09:22] doko: was about 7, and none of the removed binaries had rdepends [09:41] nacc_, jamespage: fop needs a xmlgraphics-commons merge [09:42] nacc_: can you please look at https://launchpad.net/ubuntu/+source/phpunit/5.1.3-1+ubuntu1/+build/9036792 ? segfault in dh_phpcomposer [09:42] doko: x-c merge is already in -proposed [09:42] l [09:46] ta [09:46] nacc_: you have an irritating habit to add trailing space to your debian/changelog entries :) [09:47] did somebody give back pcl on amd64? [09:47] ^ not me [09:56] kees, 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:57] xnox: 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) [10:01] pitti, the context was from "kees" saying many hours back -> " 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:03] pitti, 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:05] nacc_: please also look at bug 1543850, you attached the wrong debdiff [10:05] bug 1543850 in phpunit-global-state (Ubuntu) "phpunit-global-state: add nocheck and stage1 build profiles" [Wishlist,Incomplete] https://launchpad.net/bugs/1543850 [10:05] Saviq: no; apparently appstream landed on the images/in ubuntu-desktop and now has a broken hook? [10:05] Saviq: it probably needs another test for "am I root" [10:06] pitti, yeah, my apt-cacher-ng broke, too, need to allow the new file types [10:06] Saviq: oh, I'm using acng too, I didn't yet see that [10:06] pitti, 403 on the .yml files [10:06] ah, I don't have /usr/bin/appstreamcli [10:07] oh well, that's *a* solution [10:08] * Saviq files bug with apport and acng [10:09] although, wonder, should the first one be with appstream instead [10:11] Saviq: it's only a bug in appstream [10:11] Saviq: it apparently installs that apt hook, and that needs fixing [10:12] [ `id -u` = 0 ] or something [10:12] pitti, bug #1547428 [10:12] bug 1547428 in appstream (Ubuntu) "Fails to update packages in apport-retrace" [Undecided,New] https://launchpad.net/bugs/1547428 [10:12] https://github.com/ximion/appstream/pull/28 [10:14] * pitti hugs Laney, thanks! [10:16] pitti, bug #1547431 for acng [10:16] bug 1547431 in apt-cacher-ng (Ubuntu) "Does not allow appstream files" [Undecided,New] https://launchpad.net/bugs/1547431 [10:22] nacc_: btw, for next time: simpler to just add multiple tasks to one bug about the same issue ("add stage1 blabla") [10:26] * pitti declares victory in today's sponsoring battle against nacc :) [10:27] l [10:31] m [10:32] pitti, we have lxd for s390x. [10:32] pitti, is that because nacc fell asleep or some such?! =) [10:40] nacc_: segfault in https://launchpad.net/ubuntu/+source/twig/1.23.1-1ubuntu2/+build/9036982 too [10:49] doko: 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:52] ok, at least it's now demoted [11:01] this morning we discussed here about skipping tests in openvswitch-dpdk if the environment can't provide sse3 [11:02] since fixing this autppkgtest blocks another packets migration through proposed I wanted to ask if somebody would have a minute to sponsor bug #1547460 [11:02] bug 1547460 in openvswitch-dpdk (Ubuntu) "openvswitch-switch-dpdk failing in autopkgtests" [High,Triaged] https://launchpad.net/bugs/1547460 [11:02] jamespage: you are not back already are you ? ^^ [11:04] cpaelzer: 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] rbasak, 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] apw, Setting up linux-image-4.4.0-6-generic (4.4.0-6.21) ... [11:04] Running depmod. [11:04] update-initramfs: deferring update (hook will be called later) [11:04] cp: cannot stat ‘/boot/initrd.img-4.4.0-6-generic’: No such file or directory [11:04] Failed 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] dpkg: error processing package linux-image-4.4.0-6-generic (--configure): [11:04] apw, on amd64.... [11:04] infinity: yeah talked this morning with piiti and jamespage and skipping them was what was decided [11:05] infinity: 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 needed [11:05] infinity: but we didn't consider changing the flavour an immediate task like "for today" [11:05] $ ls -latr /initrd.img [11:05] -rw-r--r-- 1 root root 0 Jan 31 13:21 /initrd.img [11:05] cpaelzer: *nod* [11:06] which is well aweful. [11:06] apw, ^ [11:06] infinity: 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 it [11:06] xnox: Where did that root filesystem come from? [11:06] ahh, that's LP: #1539903 [11:06] Launchpad bug 1539903 in tomcat8 (Ubuntu) "tomcat-8 in main for upcoming 16.04 LTS" [Low,Fix committed] https://launchpad.net/bugs/1539903 [11:07] infinity, that's just my xenial laptop.... fairely normal install with full disk encryption. but otherwise mostly harmless. [11:07] xnox, what sort of image is that [11:07] xnox: We've seen this on curtin installs, IIRC, where initrd is a file instead of a symlink. [11:07] xnox: Oh, that was just installed with ubiquity or d-i, then? [11:07] and when installed [11:07] infinity, i did d-i, cause wanted to keep my windows 10. [11:08] * xnox checks [11:08] xnox: link_in_boot = yes? [11:08] infinity, i am starting to think i have to just remove these if they are the wrong type, there are just too many of them [11:08] infinity, link_in_boot = no [11:08] Oh, that's not link_in_boot, you said / [11:08] $ cat media-info [11:08] Ubuntu-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] infinity, 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 clash [11:09] infinity, me too [11:09] well 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] xnox: Servers default to noisy, I believe. [11:09] ok. [11:10] infinity, i assume a d-i install is simply a install linux-generic and let the normal mechanics make a mess [11:10] apw: Quite. [11:10] apw, i wonder if we should make kernel scripts more resiliant "this is a file, not symlink => purge" before doing anything. [11:10] d-i would definitely never be putting a regular file there. [11:10] infinity, so this has somehow to be either an initramfs-tools or postinst issue [11:10] cause this ended up failing to upgrade kernle, and generate apport popup [11:10] but that's a bandaid. [11:11] apw: Yeahp, it's going to either be initramfs-tools or linux-image.postinst [11:11] cause we still don't know who or what is making a mess. [11:11] xnox, making the postinst resilient would be trivial i am sure, but we have at least two different mess makers out there [11:11] xnox, and i am loath to let them get away with it [11:11] xnox, i will finish what i am at, and try and do a server install in a vm and see if it goes wrong too [11:12] though of course the last milestone should have failed dismally if that was the case [11:13] apw, infinity https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1547471 [11:13] Launchpad 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:15] cpaelzer: Uploaded. [11:16] infinity: thanks++, I'll check excuses and such after lunch [11:18] tseliot: Can you verify https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1518958 so we can push those both to updates? [11:18] Launchpad bug 1518958 in fglrx-installer-updates (Ubuntu Trusty) "SRU Request: fglrx-installer: dkms build failures with linux-lts-wily" [High,Fix committed] [11:19] infinity: sure, can you approve my nvidia-361 (and -updates) in Xenial NEW, please? [11:20] tseliot: Not tonight, it's past 3am, but we'll get there soon. [11:20] ok [11:25] cpaelzer: Of course, openvswitch-dpdk is now FTBFS: http://paste.ubuntu.com/15130205/ [11:25] cpaelzer: Have fun. :P [11:26] cpaelzer: Definitely looks like libdpdk.so is underlinkes. [11:27] s/underlinkes/underlinked/ [11:27] cpaelzer: http://paste.ubuntu.com/15130215/ < -- You should aim to clear all that up. [11:28] At least missing -ldl and -lm... And one or two others I can't immediately identify. === _salem is now known as salem_ [11:47] infinity: it is statically linked atm which is a bug #1546550 on its own [11:47] bug 1546550 in openvswitch-dpdk (Ubuntu) "openvswitch-switch-dpdk links against libdpdk statically" [Medium,Triaged] https://launchpad.net/bugs/1546550 [11:47] infinity: there goes my dream that this would have been simple, I'll look into it [11:48] willcooke, 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 MIRs [11:49] infinity: I wonder why that didn't show up in my sbuild [11:49] cpaelzer: Which bit? The underlinked stuff? It probably did show up and you didn't notice. It's not fatal. [11:49] cpaelzer: Unless you mean a test build of openvswitch-dpdk, which I can only assume you did against the old dpdk by accident. [11:50] infinity: I wonder why that didn't show up in my sbuild openvswitch-dpdk, which is why I built against it [11:50] infinity: I guess they meet in proposed [11:51] infinity: and fail there [11:51] infinity: jamespage has already the 2.5 ready (so do I), so I'll patch&test his last 2.5 now [11:52] cpaelzer: The bug isn't in openvswitch, though, it's in dpdk. [11:52] tjaalton, any thoughts on doko's query? ^ [11:52] cpaelzer: dpdk.so should be linked to all the libs it uses. [11:54] doko,willcooke: no idea, one got promoted before? [11:56] tjaalton, what do you mean? [11:57] doko: willcooke forwarded the question to me.. [11:58] tjaalton, well libvdpau is in main since 2010 ... https://bugs.launchpad.net/ubuntu/+source/libvdpau/+bug/506788 [11:58] Launchpad bug 506788 in libvdpau (Ubuntu) "[MIR] libvdpau" [High,Fix released] [11:58] what was the question about? the other one is a separate source [11:59] tjaalton, component mismatch, see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg not sure we want ffmpeg in main [12:00] hasn't ffmpeg replaced libav on ubuntu too? [12:00] please be so [12:00] feel free to file these 30 MIRs for ffmpeg [12:01] heh [12:01] i thought it happened in wily [12:01] guess not [12:01] seb128: ^ [12:06] tjaalton: Package: ffmpeg Version: 7:2.8.4-1ubuntu3 Priority: optional Section: universe/video [12:13] lamont, https://launchpadlibrarian.net/240544779/buildlog_ubuntu-xenial-amd64.isc-dhcp_4.3.3-5ubuntu6_BUILDING.txt.gz [12:14] wanting to link: LDFLAGS="-lirs-export", was in libbind-export-dev [12:19] doko: what's the libva MIR? [12:21] tjaalton, there's none yet (if you click on the svg file, then it wants to open one) [12:22] doko: ahh, but libvdpau wants to pull in -va-gl? [12:23] tjaalton, yes [12:24] ok then [12:28] lamont, how to proceed? libirs isn't shipped by bind, and isc-dhcp has the bind subdir removed [12:32] lamont: looks like we need a correspondeing isc-dhcp 4.3.4? to be released on March 29? [12:32] Laney: 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 again [12:33] ok [12:35] doko: that's only because libvdpau-va-gl Provides: vdpau-driver? [12:37] and should be fixed if libvdpau1 didn't Recommend vdpau-driver [12:39]