[00:02] s390x, not the 31bit variant [00:05] hrm, weird bug here -- trying to figure out why php-zeta-base tests are failing. Set up parallel sid and xenial chroots (as sid successfully passes the tests). Took a look at what exactly is failing and it's a size miscompare for a file from php-zeta-unit-test (specifically, /usr/share/php/data/UnitTest/design/class_diagram.png). In Debian that file is 163K, in Ubuntu it is 74.5K. Is this the result of [00:05] the "PNG optimization" stuff I see run? [00:05] and is the solution, where the tests are actually looking to compare the sizes returned by some API, to update the tests in Ubuntu to use the correct size? [00:05] seems annoying to carry that delta just because of that [00:07] "pkgstripfiles: Running PNG optimization (using 4 cpus) for package php-zeta-unit-test ..." [00:07] hrm [00:17] nacc, you can disabled that by: export NO_PNG_PKG_MANGLE=1 [00:17] for Debian, that wouldn't have any effect [00:17] doko: how do i disable that in the ubuntu build? [00:17] oh, in the rules? [00:17] yes [00:17] ah ok, i'll submit a patch :) [00:40] pitti, barry: new lava-dispatcher autopkg test failure triggered in python-setuptools :-/ [01:22] slangasek: pitti: well, twig failures now are not segfaults :) (with 7.0.3-7) ... still failures, but something at least === juliank is now known as Guest89791 === juliank_ is now known as juliank === salem_ is now known as _salem === jgrimm is now known as jgrimm-afk [05:26] good morning === FlannelKing is now known as Flannel [06:53] stgraber: I uploaded lxd for bug 1549133 as that wreaks havoc; can you please commit the fix to your git too? [06:53] bug 1549133 in lxd (Ubuntu) "upgrade failure" [Critical,Fix committed] https://launchpad.net/bugs/1549133 [06:54] I had to downgrade lxc on all autopkgtest hosts, the new one fails completely :( [07:03] mfisch: Would you mind if I stole your debmirror merge? [07:03] mfisch: (you touched it last, but in 2013) [07:07] doko: tests are ok now [07:09] doko, apw: ah, virtualbox tests fail because our kernel now ships the vboxguest module pre-compiled; I guess we should remove the DKMS module from vbox then? [07:16] apw: linux-{goldfish,manta} and a few others still have a dependency to module-init-tools [07:16] apw: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/l/linux-goldfish/20160224_065132@/log.gz doesn't seem to like that [07:17] apw: but either way this is obsolete, so changing it to "kmod" in git would be appreciated === ochosi_ is now known as ochosi [07:23] pitti: The original intent in shipping the vbox dkms modules still was in case they updated out of sync, but I think the syncing mechanism that pulls from the vbox source package the linux source package might make that pointless. Andy and I will discuss when I'm legit awake. [07:23] pitti: And yeah, they're well aware that all the Android kernels are a mess. ;) [07:35] good morning [08:19] pitti: Seems the flavours are still getting no love with your upower fix in #-release [08:19] infinity: hm, so the ubiquity crash is separate after all? [08:20] i. e. bug 1548362 [08:20] bug 1547793 in Upower "duplicate for #1548362 upowerd crashed with SIGSEGV in g_variant_is_trusted()" [Critical,In progress] https://launchpad.net/bugs/1547793 [08:20] pitti: Perhaps. If you could get them to feed you backtracey things (or try it yourself), that might be nice. [08:20] pitti: ubiquity apparently crashes on launch, so not tough to repro. [08:20] unduped for now [08:22] pitti: If you do find the issue, can you pre-upload to Ubuntu, rather than Debian and sync, since the flavours are trying to pull off a Beta? [08:23] infinity: sure, that's what I did yesterday [08:23] Ta. [08:23] infinity: I started the current live system, and ubiquity comes up fine [08:23] * infinity raises brow. [08:23] so the reproduction instructions need to be a tad more precise, I'm afraid [08:23] Try xubuntu or Ubuntu GNOME? They were the two complaining, AFAIR. [08:23] Adri2000, what about updating filezilla in debian too? I can sponsor a dsc [08:23] * pitti restarts it with giving it an actual hard disk image, so that I get beyond the initial greeter [08:24] ok, moving to #u-r [08:24] can anybody please retry https://launchpad.net/ubuntu/+source/rhythmbox/3.3-1ubuntu5 on s390x? [08:25] LocutusOfBorg: done [08:25] thanks [08:25] and thanks for syncing spooles [08:25] it was on my todo [08:37] doko: python2.7 landed, python-setuptools is a valid candidate, but causes uninstallability (I guess that's not a surprise due to the -wxl removal?) [10:09] LocutusOfBorg: hi, I thought I sent you links for review in /query and now realize I did that on the wrong IRC server :s let me try again [10:39] pitti, argh, yes. until now it only showed the breaking pip whl [11:13] what appened to node-tap autopkgtest for amd64? [11:13] http://autopkgtest.ubuntu.com/running.shtml#pkg-node-tap [11:13] not only node-tap, but it is what I was waiting to migrate [11:14] OverLimit: Quota exceeded for ram: Requested 1536, but already used 50688 of 51200 ram (HTTP 413) (Request-ID: req-a67b23c2-bd77-4c59-9675-0b3823421f22) [11:14] ERROR: Quota exceeded for ram: Requested 1536, but already used 50688 of 51200 ram (HTTP 413) (Request-ID: req-a67b23c2-bd77-4c59-9675-0b3823421f22) [11:16] * LocutusOfBorg wonders if it is really a problem, or something that will be automatically fixed [11:26] 52 === vrruiz_ is now known as rvr [11:39] lamont: I was configuring a postfix on xenial this morning which just got the merge to 3.x [11:39] lamont: I was seeing this http://paste.ubuntu.com/15186744/ and wanted to ask you if the old default config was kept intentionally or if it is worth to file a LP bug for it [12:07] coreycb, 1548512 is missing a bug subscriber === _salem is now known as salem_ [12:45] pitti: around? My pending squid merge is racing systemd on pidfile creation (after the parent process exits 0, using an /etc/init.d/squid script). What can I advise upstream? [12:45] A sleep before the init script exits after start works around it. [12:46] Is there some mechanism by which we can tell systemd to wait for the pidfile to be created? Or perhaps I should do that in the init script? [13:06] doko, sorry, working on adding a bug subscriber [13:14] xnox: ping [13:15] bzoltan, hello [13:15] xnox: hi there... I would like to ask your help if you have few minutes [13:15] bzoltan, depends what it is about =) [13:16] xnox: I have a strange s390x build failure .. only on xenial and only that arch - https://launchpadlibrarian.net/242402456/buildlog_ubuntu-xenial-s390x.ubuntu-ui-toolkit_1.3.1862+16.04.20160224-0ubuntu1_BUILDING.txt.gz [13:16] xnox: that is the part http://pastebin.ubuntu.com/15187078/ [13:16] xnox: this branch does it -> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/OTA10-landing-2016-01-20/+merge/283385 [13:17] bzoltan, there is nothing strange about it, and the compiler tells you exactly what is missing. [13:17] bzoltan, it appears to be underlinked again, as the compiler says... [13:18] xnox: it is missing the libUbuntuToolkit.so.5 yes [13:18] "warning: libUbuntuToolkit.so.5, needed by /<>/ubuntu-ui-toolkit-1.3.1862+16.04.20160224/tests/unit/../../qml/Ubuntu/Components/libUbuntuComponents.so, not found (try using -rpath or -rpath-link)" [13:18] it appears that the library in question is moved / not present in the -L specified repositories. [13:19] last time, i send a patch to add it in, later it was shuffled around/removed. [13:20] bzoltan, i suspect that things are not done right everywhere, it's just s390x is bloody fast and does more things in parallel =) exposing bugs in the configury-buildsystem you have done. [13:20] xnox: I see [13:20] are you sure that (a) libUbuntuTOolkit.so.5 is built (b) linked (c) the dependencies are set right that e.g. said test depends on Toolkit to be built (d) -L linking is included. [13:21] bzoltan, i don't know which buildsystem you are using, but you should be able to carefully check that imperically. [13:21] xnox: for the src space we used this patch from cjwatson http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/revision/1000.84.1#src/src.pro [13:21] What would happen to ZFS updates once 16.04 gets out? Will we for example still get 0.7 in 16.04? [13:22] bzoltan, e.g. it looks like "-L/<>/ubuntu-ui-toolkit-1.3.1862+16.04.20160224/tests/unit/../../qml/Ubuntu/Components -lUbuntuComponents" is done right. But I don't see similar for e.g. "toolkit". [13:23] bzoltan, and/or possibly components, should have a correct dep on Toolkit, such that whenever linking to Components is requested appropriate "-L/<>/ubuntu-ui-toolkit-1.3.1862+16.04.20160224/tests/unit/../../qml/Ubuntu/Toolkit -lUbuntuToolkit" or some such is included there too. [13:24] bzoltan, that change looks good, however it should also have src_test.depends = sub-toolkit or some such. Or the sub-components should have a dep on sub-toolkit, or some such. [13:24] bzoltan, cjwatson: i don't speak QMake (?!) at all =) [13:25] bzoltan, but yeah it is high-parallelisation race discovered. [13:27] xnox: cool, thanks. I understand the issue. [13:28] bzoltan, sorry, i can't like patch qmake .pro files to do that =/ [13:28] i only have a yellow qt-foo belt. [13:32] xnox, superm1: fyi i uploaded a fixed firmware-extract to go with firmware-tools that xnox fixed, it is currently in NEW [13:34] xnox: :) [13:38] xnox: I hope you're not under the impression that I immediately knew how to fix that one :) [13:39] I seem to remember spending quite a while experimenting [13:42] cjwatson, but you have +1 lines of code of QMake experience over me =))))) [13:42] pitti, systemd does not boot [13:43] xnox: that is indeed about the sum of it [13:44] xnox: that's a little vague :) [13:45] pitti, so the bug is https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1546714 [13:45] Launchpad bug 1546714 in systemd (Ubuntu) "System not booting when /home is on separate LUKS-encrypted partition" [Undecided,New] [13:45] pitti, to reproduce, use installer, switch to "medium" priority and choose guided partitining to do "full disk, separate /home" [13:46] rbasak: what do you mean? the pid file specified in PIDFile= isn't created late/early enough, i. e. systemd considers the daemon as running too early/late? [13:46] pitti, i see fstab unit generated for home.mount with a wantedby local-fs.target or some such, but it fails to boot. [13:46] i'm not sure of a better term, it did boot, cause we are past kernel and initramfs. I guess we "fail to reach default.target" =) [13:46] xnox: what do you see? does it ask you for the password, etc? [13:47] journal would be very helpful (debug shell) [13:47] cpaelzer: it's a known thing, but yeah, a bug report would not be amiss [13:48] pitti: it's an init.d script only, no systemd service unit definition shipped by the package. [13:48] pitti: the init.d script exits with the daemon started but with no pidfile created. [13:48] pitti: "# pidfile: /var/run/squid.pid" is in the init.d script header which I think systemd picks up? [13:49] pitti, this is without encryption at all. just /home on a separate partition from / [13:50] pitti, ok, let me try to recover something from this vm. [13:50] rbasak: right, it parses a pidfile: in the LSB headers, but if the init script doesn't create it it's fairly useless indeed [13:50] pitti, also it looks like "recovery" boot option, and "system recovery shell" conflict with each other, and i booted to a messed up thing. [13:50] xnox: ah, the bug speaks about a LUKS encrypted partition :) [13:51] lamont: ok I'll add that later on - thanks for the feedback [13:51] pitti, the devil is in the last sentence =) "This does also happen, when you put LUKS on top of an LVM setup or if you even place the /home partition on a separate DASD. The problem is the same." [13:51] pitti, so on amd64 this is totally reproducible with just normal install, using "guided paritioning, but /home on a separate partition". [13:52] pitti: it does create it, just late. [13:52] well, I've always had /home on a separate partition [13:52] (after exit) [13:52] rbasak: so the point of the PIDFile= option is that the service is "starting" while it doesn't exist, and the service is considered "started" (i. e. dependencies can start) once it does exist [13:52] pitti, removing "quiet splash" makes it boot. SIGH [13:52] * xnox adds back splash [13:53] xnox: add systemd.debug-shell, let it fail, switch to shell, capture journal, attach it to the bug please? [13:53] * lamont sometimes wishes that the default server install did "noquiet nosplash" [13:53] pitti, i'm now blaming "splash" [13:54] pitti: "Job for squid.service failed because a configured resource limit was exceeded." when I run "systemctl squid start". [13:54] lamont: I do believe servers don't use splash [13:54] pitti: unless I add a sleep before the init.d script exits [13:54] lamont, default server installs do not specify "quiet splash", it's just empty -> thus should be chatty! [13:54] even beter [13:54] pitti: I assumed that was a pidfile creation race, but I suppose it could be something else? [13:54] pitti: so my question is: what's a better way of fixing this, then a "sleep" workaround? [13:54] rbasak: not sure, "sudo systemctl status -l squid" should have some details? [13:55] pitti: http://paste.ubuntu.com/15187272/ [13:57] doko, pitti tox & python-virtualenv are all passing now [13:57] rbasak: hmm, I guess to actually create the pid file before exiting? is it actually written? [13:57] pitti: no, it isn't written - I'm sure of that race. [13:58] rbasak: ah, well, then that explains that failure [13:58] pitti: unfortunately I don't think I can easily persuade the daemon to do that. [13:58] pitti: right. So what's a good workaround? [13:58] rbasak: drop the pidfile: from the init.d script then, if it isn't reliable? [13:58] pitti: upstream will fix in time, but I need something for the archive for now. Should I for example not tell systemd about the pidfile? [13:58] pitti: OK, makes sense. Thanks. [14:04] barry, yes, had to upload a new python3.5, venv not depending on python-setuptools-whl. Maybe it would have been better if python-pip-whl would provide that, but I didn't want to touch this stack again when all tests pass ... now waiting for the python3.5 autopkg tests [14:04] pitti, oh blimey [14:04] i think i end up being on a wrong tty. [14:04] cause tty7 has "/dev/vda1: clean," message [14:04] whilst tty1 is the one that has login. [14:05] but on e.g. s390x there is no multiple ttys. [14:05] doko: agreed, and thanks! you're probably right, but let's get all this stuff promoted and then try to improve. [14:05] * xnox ponders what's going on. [14:06] pitti, i do have splash quiet vt.handoff=7 -> no idea why i saw the fsck message though, and got stuck on tty7. [14:08] oh cool, after rebooting, the clock at the top of the screen is working again. [14:08] xnox: oh, so no debug shell for you either then [14:09] pitti, so systemctl is-system-running -> says running. [14:10] yet i don't have getty on tty7, plymouth has been terminated, and all i have there is a leftover fsck message. [14:10] getty isn't supposed to be on tty7, only 1 to 6 [14:10] pitti, true..... [14:10] however i don't have a display manager in this case =) [14:10] xnox: so what is this, an s390x server install? [14:11] or an amd64 VM? [14:11] * pitti is confused [14:11] xnox: is lightdm running? some /var/log/Xorg.0.log error perhaps? [14:11] this is a netboot-install, amd64, VM, thus "server" which has separate /home, and ended up with "splash quiet" + plymouth + no dispalay manager + no-X, yet vt_handoff=7. [14:12] meh, vt_handoff with a server install? [14:12] yeap. [14:12] xnox: so I take it /home is mounted after all [14:12] yes. [14:13] i don't think our mini.iso knows at all what's it's doing. But e.g. all s390x installs, are essentially "netboot" code path. [14:13] I don't have a vt_handoff on cloud images, but they are fairly different from netboot indeed [14:13] ubuntu server.iso takes the pre-bootstrapped code path. [14:13] (whatever it's called when the squashfs filesystem is used, instead of "installing the base system bootstrap") [14:14] * xnox live-installer ?! [14:14] * xnox ponders if our base-installer method is borked. [14:14] I can test verify this! [14:24] xnox, just looking at your -no-pie patch in qemu - do you think it would be possible to make that dynamic? i.e. only set -no-pie if the toolchain default is pie? [14:27] jamespage, because you are backporting? we can do it per-release / if toolchain supports the flag. [14:27] xnox, basically yes [14:27] jamespage, so xenial and up toolchains (and debian stretch) suppor the -pie / -no-pie flags, and we will have many architectures with -pie by default in the future. [14:28] jamespage, s390x is a pilot one... [14:28] xnox, so really we need a check to see if -no-pie is supported, and then use if so [14:28] jamespage, i can do that, i guess. [14:28] yeap. [14:31] doko, is there a good/imperical check ^ [14:32] jamespage, to be honest qemu does have support for "pie" builds, but i guess they don't support fully the "-no-pie" or e.g. toolchains with pie by default. [14:33] doko, echo "" | gcc -fsyntax-only -no-pie -xc - ? is that ok. [14:33] cpaelzer: for the DPDK MIR, we just need to do whatever will pull DPDK into main, by a dependency or by seeding directly. [14:34] xnox, jamespage: -no-pie works in xenial on all archs [14:34] In this case we want it in main because of ovs, so presumably the right parts of ovs will get seeded and as soon as they depend on the bits of dpdk needed, they will generate a component mismatch. [14:34] jamespage will manage that I guess. [14:34] doko, yeah, but jamespage is backporting qemu to cloud-archive, and gcc there does not support -no-pie =) [14:35] jamespage, urgh, i patched upstream makefile. [14:35] Then because the MIR is already approved, an AA will issue the component override to actually make the change and put the dpdk source and right binaries into main. [14:35] Essentially main inclusion isn't a thing in its own right; it's a consequence of being seeded or being an indirect dependency of something that is seeded. [14:36] rbasak: ah ok, that I might do with jamespage then when he combines openvswitch-dpdk into openvswitch [14:36] In server we also have a special seed for stuff that we want to have in main but not ship or be seeded elsewhere, but use of that is fairly rare. [14:36] cpaelzer: right. You shouldn't have to do anything further - getting the MIR approved is enough. [14:37] rbasak: I only thought of the explicit seeding before - makes sense, thank you [14:37] np! === jgrimm-afk is now known as jgrimm [14:40] jamespage, how do i test it? sbuild -A -d trusty qemu*.dsc -> should just work? [14:40] xnox, almost [14:41] you'll need to build against ppa:ubuntu-cloud-archive/mitaka-staging [14:41] jamespage, how about i test build xenial, and you test build that. before i upload =) [14:41] xnox, that works for me [14:43] xnox, thankyou :-) [14:45] jamespage, note this is not the only package with -no-pie... =) [14:45] xnox, only one I'm tripping over in the b-o-m right now [14:45] (backport-o-matic for reference) [14:46] jamespage, but e.g. xenial is the "last" release to be backported onto things pre-xenial, right? [14:46] e.g. we are not backporting Yummy packages to trusty-wily in the cloud archive? [14:48] xnox, yes thankgod [14:49] jamespage, good, cause then we can drop these -no-pie extra stuff in Yummy Yak [14:49] love the name [14:49] not sure whether sabdfl takes suggestions or not :-) [14:50] cpaelzer, rbasak: my multi-ovs-vswitchd upload will pull it in - just working that now [14:54] there is not so much positive left other than yummy http://adjectivesstarting.com/with-y/ :-) [14:54] cpaelzer, dpdk is still i386 and amd64 only right? [14:54] jamespage: yes [14:55] jamespage: the ppc things where moved to (at least) 16.10 by the taco team [14:55] well at least I'll only extend two package builds x2 [14:55] jamespage: and the IBM buy in was there, but not super huge [14:58] cyphermox, cjwatson, pitti - i wonder if ".iso" based installs use preseeds to tweak default behaviour. With bare netboot defaults skewed for desktop, rather than server. [14:58] which works ok mostly everywhere, apart from the crazy s390x. [14:59] xnox: they do, but nothing comes to mind, from what I remember of it, that would break s390x [14:59] what is it exactly that you see is wrong? [14:59] cyphermox, like vt_hadoff splash quiet [14:59] that's done in grub-installer/debian-installer-utils iirc [14:59] on amd64 is specified, when using ubuntu mini.iso [14:59] right, so that can't ever affect s390x. [15:00] in fact vt.handoff is done in grub2 [15:00] splash quiet are done in grub-installer I believe [15:01] yeah [15:01] horum. [15:02] jamespage, sorry it's taking so long, i by accident did non-parallel build, and now it's too late to kill and restart =/ [15:03] cjwatson: if there is a need to change anything in grub2 I have another change too [15:05] xnox: is it just vt_handoff that breaks things? [15:05] cyphermox, cjwatson, pitti: i think amd64 mini.iso is borked, installing using that media and just doing a bog standard install of nothing (i.e. just minimal utils et.al.) ends up with "quiet splash vt_handoff=7" instead of ending up like the server.iso with "ro" [15:05] cyphermox, net effect one ends up booting on tty7, with nothing, and no idea what's going on.... unless one like switches to tty1. [15:05] ok [15:05] not a biggie, but is annoying and confusing to the remote-hands people. [15:06] aka local users. [15:06] however, that doesn't explain my s390x troubles =) [15:06] sure, but I see removing splash would get you no vt handoff [15:07] yeah. it feels to me that somewhere rather "quiet splash" is default, and we toggle that off in server.iso. Where imho, it should be "" by default, and toggled on in the desktop.iso. And/or installer somehow checking "aha" you chose to install a "desktopy" metapackage you probably want "quiet splash". [15:08] cyphermox, no spalsh, no vt-handoff, i would then endup on tty1, where getty is spawned at the end of boot and live is wonderful. [15:08] so that's a separate bug, and not the bug i was looking for though however! [15:08] * xnox ponders if on s390x we end up on wrong serial console, or not enough gettys on all serial consoles etc. [15:10] jamespage, could you try http://paste.ubuntu.com/15187794/ ? [15:10] that still works for me on xenial, and should work in b-o-m [15:11] xnox: well, the only issue you mentioned was the handoff ;) [15:15] cyphermox, touche =) [15:16] this is going to sound like a crazy question, but did something change in the way the gcc in xenial is computing include paths? i have a project that on older xenial gcc's was compiling, but now it isn't. [15:21] pitti: yep, I will. Sorry about that, I forgot to update that part when moving from postinst to preinst and my test was in a clean VM so not an upgrade... [15:33] doko, insighttoolkit4 is ICE on amd64, do you have any clue/workaround? [15:33] I don't have access to ubuntu porterboxes [15:40] LocutusOfBorg, read the build log please, x86_64-linux-gnu-g++: internal compiler error: Killed (program cc1plus) [15:41] sorry isn't Internal Compiler Error called "ICE"? [15:42] no, not "Killed" [15:42] ah ok, and what does it mean? I retried the build and it failed again [15:42] lower the parallel build number? [15:42] yes, just build with two [15:44] sad thanks [15:49] well, wait until the other builds finish, and then enable that only on those archs that need it [15:53] nacc, I'm going to steal your gdcm merge :) [16:17] LocutusOfBorg: heh, thanks! [16:17] LocutusOfBorg: can you add it to the bug, too? LP: #1546823 [16:17] Launchpad bug 1546823 in swig (Ubuntu) "swig: disable PHP bindings until PHP7 support exists" [Wishlist,Fix released] https://launchpad.net/bugs/1546823 === cpaelzer_ is now known as cpaelzer [16:20] oops too late, I dropped the bug reference in the merge [16:21] do you want me to have a new upload? [16:27] LocutusOfBorg: no, it's ok, I think -- i'll put it in manually [16:27] it's mostly for my own tracking so when i do get swig fixed, i know what all to go back and fix up :) [16:32] nacc, isn't this a debian issue too? [16:32] I'm wondering why you are not doing this work there and sync it [16:32] LocutusOfBorg: it will be when they move to only php7.0 [16:32] LocutusOfBorg: because we're dropping php5 in xenial [16:32] *only* php7? wow [16:32] huge move [16:32] LocutusOfBorg: so had to get stuff in before FF [16:33] LocutusOfBorg: yeah [16:33] yes sure :D [16:33] I'll try to remember it on the next merge [16:33] jamespage, uploaded fixed up qemu, hopefully when that builds, freeze is lifted (if tangled up) and it migrates and b-o-m picks it up.... it will just work (tm) =) [16:33] LocutusOfBorg: the plan is to send it all to Debian once I've got all the builds kicked off and hopefully php5 out :) [16:33] xnox, looked ok to me as well [16:33] xnox, b-o-m picks from proposed so that's good [16:34] jamespage, cool! =) [16:36] btw nacc there is a new php7.0 upload in debian (two actually) :) [16:36] s/is/are [16:38] * Laney remembers his PHP days [16:38] happy times [16:38] LocutusOfBorg: yes, sync for 7.0.3-7 is requested already, but i was told 7.0.3-9 is preferred, possibly (by debian maintainer) [16:38] doko: --^ [16:38] doko: will send a new debdiff [16:39] I see -7 in proposed, this is why I wondered about the last -8 and -9 [16:42] doko, i giggle at your changelogs =) i always new there are multiple doko's working in ubuntu and debian. The only way to explain an NMU from doko to doko's package. I hope doko doesn't disagree with doko on that one =) https://launchpad.net/ubuntu/+source/twisted/+changelog === davidcalle is now known as davidcalle_afk [16:44] I would put both doko@d.o and doko@u.c in the uploaders field :) [16:48] xnox, it's a twisted package [16:48] * xnox har har har [17:15] seb128: Could you have a look at bug 1545517? [17:15] bug 1545517 in popularity-contest (Ubuntu) "xenial popularity-client regards successful popcon.ubuntu.com submissions as failures" [Undecided,New] https://launchpad.net/bugs/1545517 === mnepton is now known as mneptok [17:30] who's maintaining indicator-datetime nowadays? [17:30] it looks like it's the reason why I still have systemd-shim installed on my machine here despite it running systemd [17:30] any chance it could be changed to depend on "systemd | systemd-shim" instead? [17:36] Laney: any idea who's maintaining this? I could just upload to the archive but I seem to remember folks not being very happy about me doing that last time I did :) [17:36] stgraber: umm charles and/or ted probably [17:36] I'd do a merge proposal and then zap them a link to it [17:38] they don't seem to have a 16.04 branch... [17:39] looks like lp:indicator-datetime is it [17:39] despite the series [17:39] yeah [17:39] context is I'm trying to get rid of cgmanager on default installs [17:39] doko: any chance you could upload new versions of gcc-4.8-*-cross in trusty to rebuild against the SRUed gcc-4.8-sources? [17:41] cjwatson: is there a way to tell germinate to ignore recommends for just one package in a seed? [17:43] tedg: https://code.launchpad.net/~stgraber/indicator-datetime/fix-deps/+merge/287068 [17:43] Laney: ^ [17:44] stgraber: Cool, that's actually charles' now, but he's out today. [17:45] stgraber: systemd-services is a thing Provided by systemd [17:45] I guess you can delete that one too [17:45] cyphermox: No. Fix the package to stop recommending the thing you don't want? [17:45] infinity: yeah, that's what I'm looking at [17:47] mjeanson, please could you file a bug report, and validate the SRU once it is built? [17:49] cyphermox: The reason germinate won't support this is that it would become impossible for its behaviour to be consistent with that of apt if it did [17:49] Laney: so I'm not entirely sure what to do with systemd-services. It appears to only be provided by systemd in the archive right now but I thought that phone people were still using upstart so I'm not sure how that works at all. [17:49] cjwatson: oh, indeed [17:50] Laney: I guess I'll turn that into "systemd | systemd-services" in case they have something in the crazy phone archive thing that provides it somehow for a non-systemd system [17:51] stgraber: I thought that's what -shim was TBH [17:51] Laney: me too but it's not providing it :) [17:51] I mean that "systemd | systemd-shim" is probably alright :P [17:52] yeah, just that one should do, lets drop the systemd-services thing entirely then [17:52] at least I hope that they seed -shim [17:53] infinity, is there any type of policy on automatically using a binary that requires more than Ubuntu's baseline feature set? [17:53] I'd like to auto-enable the dpdk binary for ovs now that dpdk is in main which would require the ssse2 cpu flag - fairly easy todo when configuring the alternatives [18:08] jamespage: Define auto-enable. You mean you want all x86 installations to use it, regardless of their baseline ISA? [18:08] infinity, no [18:09] jamespage: Could you perhaps ship both versions, and use a wrapper to call one or the other based on cpuinfo? [18:09] the package contains two binaries for ovs-vswitchd - one vanilla which works with the baseline ISA [18:09] and one which requires ssse3 [18:09] I'd like to use the ssse3 enabled binary on installs that can support that [18:10] (obligatory whine about why have people not heard of perfectly good hwcap/ifunc mechanisms) [18:10] infinity, https://git.launchpad.net/~james-page/ubuntu/+source/openvswitch/tree/debian/openvswitch-switch.postinst [18:10] jamespage: Don't do it in postinst. [18:10] cjwatson, pointer? I'd like to read more [18:10] jamespage: That means that preimaged installs (for instance) wouldn't DTRT. [18:10] infinity, hmm - yeah [18:11] ok that does make sense [18:11] * jamespage thinks [18:11] jamespage: Make /usr/bin/foo a wrapper that checks for the flag and then execs /usr/lib/foo{-variant} as appropriate. [18:11] jamespage: `man getauxval`, iirc [18:11] jamespage: that's for C, and hwcap, at least [18:11] barry, the pip mess migrated \o/ [18:12] (And, yes, if this is something you can do in a single build with hwcap, that would be cleaner, and upstreamable) [18:12] doko: \o/ [18:12] is the wiki down for anyone else...? (Can't get to the Freeze Exception page to find out what i'm missing in an FFE request bug) [18:12] (sorry to interrupt) [18:12] doko: MIR filled [18:12] jamespage: hwcap works by putting most of it in a library, installing to special library directories, and letting the linker auto-resolve whichever path is best [18:12] cjwatson, can that apply to binaries as well? [18:12] jamespage: No. [18:13] hwcap is for libraries only. [18:13] okies [18:13] I understand the current challenge to be with dpdk headers - but I'll recheck that [18:13] jamespage: ifunc is I think reasonably googleable; that would be usable in binaries without needing to split out libraries, probably as long as it isn't too ridiculous a number of functions that need variants [18:14] ifunc is decidedly more complex, and lets you create stub functions that are pointers to variants of the real function, based on arbitrary conditions (like hwcaps), but that's a lot of work to rewrite something to do that. [18:14] It's work I wish upstream would have done, but not work I'd expect a downstream to do for them. [18:15] https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Function-Attributes.html documents ifunc [18:15] I agree that neither is great as a downstream, that's why it was a whine rather than "you have to do this" [18:15] jamespage: Anyhow, for now, I think a 5-line (ish) shell script that execs the right binary would be fine. [18:15] huh, wiki down? [18:15] infinity, ack - I'll work that through tomorrow [18:15] doko: sure, here you go #1549421 [18:15] hallyn: i just asked if it's down for anyone else - is it showing down for you? [18:15] (shows me a 500 error) [18:16] thanks for the feedback - cjwatson- thanks for the pointers - I'd like to look at the for dpdk and erasurecoding stuff next cycle... [18:16] mjeanson, thanks, will look at this this week [18:16] doko: thanks, I'll test the packages when they hit proposed [18:16] teward: nope down for me :( [18:17] hallyn: sounds like Canonical IS should be notified [18:17] https://wiki.ubuntu.com/FreezeExceptionProcess e.g. loads for me [18:17] jamespage: Speaking of dpdk, are we going to be pulling ARM patches and turning it on there too? [18:17] jamespage: Or has no one looked at that yet? [18:17] cjwatson: hm, me too. yet https://wiki.ubuntu.com/SergeHallyn does not [18:18] cjwatson: mmm... still a 500 for me. [18:18] getting "Connectoin Refused" actually now [18:18] "connection to 91.189.89.111 failed" [18:19] I know that bits of prodstack were just being rebooted, so maybe just wait a little bit [18:19] ok [18:24] horay, cloud image today has no python2 at all. not even libpython. http://cloud-images.ubuntu.com/daily/server/xenial/20160223.1/xenial-server-cloudimg-amd64.manifest [18:25] well done [18:27] Pharaoh_Atem: ping [18:37] smoser: \o/ [19:11] nacc: pong [19:21] nacc: what's up? [19:25] I'm trying to figure out how/what in the apache2* packages is causing the population of /etc/rc*d - I can't find any reference to update-rc.d or similar that is populating the files/scripts. Am I missing something obvious? [19:26] Pharaoh_Atem: i think i figured out the twig issue, or why it's happening -- utf8 invalid character encoding coming back [19:26] ah [19:26] nneul: insserv perhaps? [19:26] nacc: well, funnily enough, I'm not getting that error locally [19:26] I'm getting a different one [19:26] but I think it's because I'm running an older build of the package [19:26] (base)adconrad@nosferatu:/var/lib/dpkg/info$ grep update apache* [19:26] apache2.postinst: update-rc.d apache2 defaults 91 09 >/dev/null [19:26] apache2.postrm: update-rc.d apache2 remove >/dev/null [19:27] nneul: Looks there to me. [19:27]