=== salem_ is now known as _salem === timchen1` is now known as timchen119 [03:29] https://answers.launchpad.net/ubuntu/+source/gvfs/+question/274076 [03:31] please help me. === nudtrobert1 is now known as nudtrobert === sunweave1 is now known as sunweaver === marcusto_ is now known as marcustomlinson === cpaelzer_ is now known as cpaelzer [07:28] good morning [07:38] slangasek: yeah, I know; It's ridiculously hard to inspect AMQP queues, much harder than e. g. doing the live logtailing :/ [07:39] slangasek: however, we could publish britney's pending.txt somewhere, which would already be a start [07:42] Laney: wow, now that we get mailed about the cloud errors/worker failures it's quite dazzling how many there are.. [09:14] doko, hey, "libllvm3.7: Add Conflicts/Replaces to libllvm3.7v4 (anticipated backport)." ... what do you mean "anticipated backport"? could that go to Debian as well? [09:33] doko, bug #1501300 ... seems like llvm-toolchain-3.4 was built with gcc-4.9 in wily due to an issue with the debian/rules gcc version regexp, do you think fixing that/building with gcc5 is the sort of change that is fine for a SRU? [09:33] bug 1501300 in llvm-toolchain-3.4 (Ubuntu) "Wily (15.10) this package got not compiled with __cxx11 support" [Medium,Fix released] https://launchpad.net/bugs/1501300 [09:35] same for bug #1511128 [09:35] bug 1511128 in llvm-toolchain-3.7 (Ubuntu) "Package compiled on wrong compiler for wily" [Medium,Confirmed] https://launchpad.net/bugs/1511128 [09:44] pitti: yeah... what's up with the ssh timeout ones? just the instances failing to come up properly? === nudtrobert1 is now known as nudtrobert [09:59] Laney: seems they all come from vivid systemd's fsck test [10:00] Laney: it timed out, it got handed to another worker, and then killed that as well [10:00] Laney: I guess the possibility of chain-killing workers is now a consequence of not giving up on tmpfails [10:00] but I'd rather have it this way, this happens much less (systemd/vivid/ppc64el is the only known case to me) [10:01] Laney: the others were quota ceiling again [10:02] Laney: wrt. http://autopkgtest.ubuntu.com/status/alerts/ -- I retried mpfit (RT to delete the two undeletable nova instances got processed and done) [10:03] Laney: systemd/network-manager are these chain-killers, to be investigated [10:03] Laney: apw and I found the reason for the linux/ppc64el test dep uninstallability, but there's still a bug somewhere in my code because it re-tries twice and then fails on the already removed apt pin file [10:03] so TL;DR: I'm on them, please don't retry those [10:04] okay, thanks for being on top of them! [10:05] Laney: I'm now looking into converting these pesky "Temporary failure resolving 'ftpmaster.internal' [10:05] Laney: ... to tmpfail, so that they will auto-retry [10:05] instead of having to be retried manually [10:06] is that fatal or can adt itself be retried? [10:06] i.e. do you have to kill the instance when that happens? [10:06] Laney: you mean apt? [10:06] well I presume it makes adt-run fail [10:06] we already retry apt-get update [10:06] can you try it again? [10:06] we might try to re-run apt-get install too [10:07] Laney: if adt-run exits with a failure, the container is gone, so we have to start over, yes [10:07] (but I don't see that as a big problem) [10:07] retrying apt-get install itself is a bit more elegant, though [10:08] in both cases I simultaneously need to capture apt's output to check for the error message but also have it go to stdout/err for the log [10:08] so I might just as well do it locally in the apt-get call [10:09] apt-get --quiet update || (sleep 15; apt-get update)) 2>&1 [10:09] we already do that trick for update, which commonly fail with hash sum mismatches [10:13] hm, but if the outages last longer than a few seconds, then the test can't do much about it by itself [10:15] mvo: apt-get always exits with 100 on errors? is there a way to tell apart errors on downloading/fetching stuff from uninstallability or postinst errors? [10:16] mvo: apart from checking the output, I mean [10:16] mvo: or maybe some extra "side channel" where it outputs such errors in addition, so that I can leave normal stdout/stderr in place? [10:16] mvo: like dpkg's --status-fd [10:19] * pitti discovers README.progress-reporting in the source and APT::Status-Fd [10:22] err, the status-fd messages are translated [10:23] heh just what you need [10:24] -o APT::Status-Fd=2 works [10:24] but this doesn't, /tmp/out is empty; sudo apt-get install -o APT::Status-Fd=2 pmount 3>/tmp/out [10:25] err, APT::Status-Fd=3 of course [10:25] apparently my redirection fu isn't strong enough [10:25] pitti, some LANG=C foo tooo to make sure its parable [10:25] *parsable [10:25] oh, sudo, hang on [10:26] yep, works without sudo and in a root shell, sorry for the noise; so indeed weak redir fu :) [10:28] mvo: so, found it, unping [10:30] so I think if the file contains ^dlstatus: but does not contain ^pmstatus:, I can assume downlaod failed and it's worth trying again [10:31] with sleeping 10 s in between, and give up with tmpfail after the third failure [10:41] hello all, [10:41] I have a general question about contributing to Ubuntu through bzr branches [10:42] pitti: hi, what exactly is the problem you need to solve? I guess I can look into giving you different exit codes for certain failures [10:42] Currently, there is no xenial branch for partman efi: https://code.launchpad.net/ubuntu/+source/partman-efi [10:42] can we expect that branch to exist at some point? how/when that happens? [10:42] mvo: we have a lot of failures like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/x/xen-tools/20151111_234936@/log.gz [10:43] mvo: so if a package fails to install due to postinst bugs, bad dependencies etc., I want the test to fail [10:43] mvo: but if it fails to download, or these DNS errors, I want to retry or make it a temporary testbed failure insted of a test failure [10:43] mvo: but APT::Status-Fd=3 actually works well enough [10:44] * pitti checks if that's available in precise [10:44] pitti: ok, so a different exit code for download failures? that sounds not too terrible, let me check [10:44] mvo: well, I need something that works on all releases; so it might be nice for the future as these retry loops become much simpler [10:44] pitti: aha, ok. if status-fd is good enough, sure. it should be in precise, its availalbe since a long time (~2007ish I would say) [10:45] yep, works in precise [10:45] so, that's good, thanks! [10:45] yw [10:49] mvo: so I guess I'll use "apt-get install -o APT::Status-Fd=3 ... 3>&2 2>&1" and capture stderr [10:52] hmm, looks like my upgrade to Xenial was not a success : lost sound, external display, USB keyboard & I don't get a prompt upon boot for my encryption password [10:53] hey dholbach, can I ask you a question related to contributing to Ubuntu through bzr branches? [10:53] caribou: wow -- was it interrupted in the middle or so? [10:53] caribou: the worst that I can say is that gedit now looks strange, so it's not generally broken for everyone [10:54] ara, sure [10:54] pitti: no nothing to report [10:55] dholbach, Currently, there is no xenial branch for partman efi: https://code.launchpad.net/ubuntu/+source/partman-efi [10:55] can we expect that branch to exist at some point? how/when that happens? [10:55] pitti: I'm going to reboot with a clean syslog & I'll be back [10:57] ara, no idea - let me ask somebody [10:57] pitti, cjwatson (or anyone else): do you know why there's no xenial branch for https://code.launchpad.net/ubuntu/+source/partman-efi yet? (ara just asked.) [10:58] I don't know, sorry; I don't know whether anybody still maintains the UDD branches in LP, but it seemed pretty dead to me [10:58] to be blunt, they've been a mis-design right from the start, and a lot of imports tend to be behind; I thought there was a new plan to have something like dgit [10:59] pitti, so you'd recommend to just send a patch? [10:59] dholbach: personally, yes (I know other sponsors actually like the UDD branches, so don't consider that a "project opinion") [10:59] personally, a debdiff to a sponsoring bug is ten times faster and simpler than wrestling with the UDD patch maze [11:00] ok [11:00] and no sponsor I know of dares to actually push these branches [11:00] ara, ^ does that help? [11:00] yes, it does [11:00] dholbach, the packaging guide still says that UDD is the way to go :) [11:01] dholbach, pitti: thanks! [11:01] ara: the other option is to work on the Debian git, but we have a delta, so this mostly just makes sense for more convenient development if you want to use git diff, stashing, etc. [11:01] and then attach the git format-patch to the bug [11:03] ara, I guess it needs a bit of a broader discussion - but yeah, I agree [11:07] dholbach: have the candidates for CC written any kind of platform? [11:07] I don't know how to choose between most of them tbh [11:09] dholbach: right, more or less as pitti says. We haven't brought them up yet, and conceivably, we might be close enough to being able to have dgit working that it might not be worth the effort. And the auto-import branches have been so badly broken in so many ways for so long ... [11:09] some might have something up on their website, but as we were a bit late already, I didn't want to go through another round of "please write something and send a link back" before we announce [11:09] cjwatson, cool - thanks! [11:09] ara: I have been complaining about that in the packaging guide for years :P [11:10] cjwatson, :) [11:10] nothing ever happens because rah rah revision control (even if it's horribly broken) [11:11] ok... let's have a discussion about it and change it [11:11] I'm not sure if I'm seen as blocking this... because I'm happy for it to be changed [11:13] pitti: systemd complains about some apparmor issue : http://paste.ubuntu.com/13237626/ === _salem is now known as salem_ [11:33] caribou: ah, I get that too [11:33] sudo systemctl status apparmor -l [11:33] Nov 12 08:34:00 donald apparmor[476]: AppArmor-Analysefehler f?r /etc/apparmor.d/usr.bin.webbrowser-app in /etc/apparmor.d/usr.bin.webbrowser-app in Zeile 26: >>/usr/share/apparmor/hardware/graphics.d<< konnte nicht ge?ffnet werden [11:33] so apparently an error in webbrowser-app's apparmor profile [11:33] but that should be moderately harmless [11:33] why do I have webbrowser-app installed in the first place.. [11:40] pitti, we install it by default (should be cleaned out but we noticed that just before xenial and it was too late for such changes) [11:41] seb128: s/xenial/wily/ I suppose [11:41] yes [11:42] it's used by webapps but we don't install any by default so we don't need it on the iso [11:44] pitti: I found my problem [11:44] pitti: linux-image-extra for .18 is missing in the Xenial archive [11:44] pitti: apw is looking into it [11:45] caribou: oh indeed; I still have -16 installed [11:45] pitti: I also had .17 so going back to that one fixes my usb/sound/external display problem [11:45] caribou: .17 is in -proposed still [11:46] never ever (and I mean EVER) enable devel-proposed on a real machine [11:46] devel-proposed by definition are all packages which are broken [11:46] pitti: I don't have it enabled. [11:46] pitti: apparently it is a miss from a CVE upload [11:46] caribou: oh, wily now has a newer kernel than xenial? nice.. [11:47] pitti: no, xenial has linux-image-4.2.0.18-generic but it is missing linux-image-EXTRA-4.2.0.18-generic [11:47] caribou: ok, so missing -extra does explain missing sound, graphics, and stuff [11:47] pitti: yes [11:48] pitti: thanks for diwic for nailing it down [11:48] ok, rebooting to see if I get my password prompt [11:48] yw [11:48] hm, so wily-updates has 4.2.0-18.22, xenial has 4.2.0-16.19 , xenial-proposed has 4.2.0-17.21 [11:49] caribou: that explains why I didn't see that, as I dist-upgraded to xenial right away, before I got wily-updates bits [11:49] diwic, caribou: thanks for tracking it down! [11:49] pitti: well, that's the reason for running/upgrading to Xenial isn't it ? [11:50] caribou: well, usually I'd expect the breakage to be in the devel series, not in the stable series [11:50] in devel it would be "meh", but devel is fine [11:50] it seems we completely screwed wily with that [11:51] and that's in the "disaster" category [11:51] caribou: or did I misunderstand this somehow? did you have -18 extras in wily, but it somehow got lost on the xenial update? [11:52] linux-image-extra-4.2.0-18-generic | 4.2.0-18.22 | wily-security | amd64, i386, ppc64el [11:52] ah no, *phew* [11:53] caribou: so your -18 kernel got partially removed during the upgrade then? [11:53] pitti, the tl;dr was that the install of -18 was manual and not done completly, so all is understod and we're fine [11:53] apw: ok, good [11:53] pitti, he wanted -18, but was on xenail where it did not exist [11:53] pitti: no, dist-upgrade was complaining it couldn't find it in the archive so I went back to wily and manually installed _only_ the linux-image [11:54] pitti, and i've requested that be copied up to close this hole [11:54] pitti: then dist-ugprade [12:07] Laney, mvo: this works nicely: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=609c99 [12:07] Laney: and the .bomb() instead of .badpkg() will make it a tmpfail instead of a test fail, so hopefully these shoudl be gone [12:08] * pitti runs a mass-retry to mop up the current failures [12:08] I'm sure that we now find some tests which are genuinely broken but trigger this :) [12:09] pitti: heh :) [12:37] Laney, did you get a reply from dholbach earlier about the community council eventual programs? (didn't see you but there were cross discussions) [12:38] seb128: "eventual programs"? nothing further no [12:38] but I don't know what one of those is. :P [12:38] sorry, I guess franglish [12:38] platform is the thing I asked for [12:39] you asked if candidates eventually had a platform [12:39] don't think there is any central list of them [12:39] k [12:39] we use "programme" for "platform" in french [12:39] ah [12:39] I though "program" would work in this context in english [12:39] sorry ;-) [12:40] no worries [12:40] like "having an agenda" [12:41] It kind of works but wouldn't be the usual term [12:42] I see [12:42] seb128, Laney: sorry - maybe I should have been clearer earlier.... we were a bit late with the election and I wanted to get it announced as opposed to mailing everyone again, asking for a platform to be written, pages updated, etc [12:43] dholbach, no worry, but does it mean it's likely that some people will write something? [12:43] or said differently is waiting likely to provide more details to make an informed choice? [12:44] seb128, I haven't pinged people yet, but I could do that - and send a mail with links to their wiki page in an update? [12:44] dholbach, that would be nice === nudtrobert1 is now known as nudtrobert [12:45] ok....... [12:47] dholbach, don't feel like you have to do it, I was just asking in case because I don't know some of the candidates, but I opened their launchpad page which already gives some kind of idea [12:57] seb128, I would... but the wiki doesn't let me :-P [12:57] heh [13:47] doko: you here? can you take a look at phonon-backend-vlc maybe? [13:48] (build failure, -fPIC stuff, I can't get it to build) [13:50] pitti: the webbroswer-app bug is known. oSoMoN is working on it [13:51] bug #1511439 [13:52] bug 1511439 in webbrowser-app (Ubuntu) "webbrowser-app apparmor policy fails to load on desktop" [High,In progress] https://launchpad.net/bugs/1511439 [13:56] jdstrand: thanks [13:57] pitti: do you need more for migration or is that enough? [13:57] s/more/more info/ [13:57] jdstrand: oh, I was looking at that in the context of caribou's upgrade b0rkage, not proposed-migration [14:00] pitti: ah. well, in either case, you can install apparmor-easyprof-ubuntu on the system or disable the profile with aa-disable [14:01] and that should fix things. oSoMoN's fix will (obviously) also fix it, but it hasn't landed yet [14:01] jdstrand: TBH I just purged webbrowser-app; seb128 said it's going away from the default install anyway, and I have no need for it [14:01] pitti: heh, that is another option :) [14:03] pitti: ok, looking at proposed migration, the regression has nothing to do with apparmor: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/s/systemd/20151112_015036@/log.gz [14:03] FAIL: test_hotplug_dhcp_ip6 (__main__.TestNetworkd) [14:03] jdstrand: no, that's a race condition in the networkd test, I'm aware of it [14:03] AssertionError: nameserver 192.168.5.1 not found in /etc/resolv.conf [14:03] ok [14:03] (either in the test, or in the resolvconf integration, not sure yet) [14:04] pitti: does that mean you'll handle the proposed migration for apparmor then? [14:04] jdstrand: yes, will do [14:04] pitti: thanks! :) [14:06] jdstrand, pitti: my fix for webbrowser-app is awaiting QA verification, will hopefully land soon [14:12] doko: asking you because TIL: puppetmaster-passenger started to become uninstallable because it depends on the removed libapache2-mod-passenger; do you have any idea about that, or is that server team matter? [14:13] ah, this was fixed in Debian [14:13] so, merge o'clock [14:14] doko: I can do the merge if you don't care, but would like to ask you first [14:25] Laney: do you plan to merge lintian anytime soon? [14:25] with debhelper updated all libraries in the kubuntu ci throw lintian errors about missing ldconfig calls. So if you don't plan to merge it soon I would give it a try. [14:35] Anyone else had apport just sit there chewing a cpu for _ages_ on xenial? [14:35] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [14:35] 5386 root 20 0 164460 82176 8768 R 100.0 0.5 124:53.76 apport [14:36] ahh, it's dealing with a caja crash, will poke flexiondotorg :) [14:36] popey: is it actually writing a .crash file in /var/crash and is the crashed process still existing (in 'D' state)? or is it trapped in a post-crash loop? [14:36] nothing in /var/crash [14:36] was just sat there in a loop [14:37] alan 27679 0.0 0.3 1211948 62316 ? Sl Nov10 0:07 caja [14:37] thats the process it was dealing with [14:38] popey: can you show me the tail of /var/log/apport.log? This caja process didn't even crash [14:39] -rw-r----- 1 root adm 0 Nov 11 07:39 /var/log/apport.log [14:39] :( [14:39] its a days old process, maybe an older apport log... [14:39] definitely a short tail [14:40] popey: what's the full command line of that apport process? [14:40] root 5386 99.8 0.5 164740 85876 ? R 12:29 125:47 /usr/bin/python3 /usr/share/apport/apport 27679 11 0 27679 [14:40] http://paste.ubuntu.com/13238745/ is the previous apport log [14:40] "another apport instance is already running, aborting", ah [14:41] this makes no sense at all [14:41] so caja crashed with SEGV (signal 11), the kernel called apport, but the process is still alive; it should go into 'D' and then die after core dumping [14:42] popey: can you attach strace to apport for a bit and see what it's looping on? [14:42] I'd already killed it, sorry :( [14:42] * pitti wonders if it's continuously reading some junk from the kernel as core dump data [14:42] ok [14:42] It may happen again, I have seen this before [14:42] and if it does, I'll trace it [15:06] yofel: I'll get to all my merges soon, been a bit busy shepherding some transitions [15:12] Laney: ok, then I'll leave it to you as I would need a sponsor for it. [15:12] thanks === adrian is now known as alvesadrian [15:42] tdaitx: how is the squid3 merge going? [15:42] tdaitx: no hurry, just checking it's not stuck. [15:43] rbasak, hi there! well, it is stuck, but just because we didn't have time to work on it during the sprint =) [15:43] tdaitx: OK, no problem. [16:00] pitti, puppet is now demoted [16:12] doko: i. e. does that translate to "I don't care, go ahead and merge", or something else? :-) [16:14] doko: I wasn't aware of any plan around puppet. Is that intended to be permanent? [16:18] pitti, the former ;p [16:19] doko: ok :) I'll do that then to fix that again [16:24] doko: I wasn't aware of any plan around puppet. Is that intended to be permanent? [16:25] doko, can you give some background on that ? i think that i've seen something around it, but dont remember the details. [16:25] Whatever was pulling it into main must have stopped... [16:25] http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.xenial/revision/2008 [16:26] Ahh. [16:26] doko: Yeah, why was that done? :P [16:27] doko: supported != shipped, so that has no effect on images. [16:29] hey. i need to fix http://pad.lv/1515661 [16:29] Launchpad bug 1515661 in cloud-initramfs-tools (Ubuntu Precise) "SRU:add cloud-initramfs-copymods to 12.04" [Medium,Confirmed] [16:30] the easiest thing to do would be to take the trusty-updates version and get it to precise. [16:30] trusty-updates is 0.25ubuntu1.14.04.1 [16:30] rbasak, infinity: puppet was only needed by IS, and isn't anymore. I didn't get any reply from the server team that it is still needed. [16:30] doko: I wasn't aware that you asked. Where did you ask? [16:30] doko: I'd prefer us to make a considered decision on whether we want it in main rather than have it ripped out from under us. [16:33] rbasak, nothing is permanent until the release is done [16:33] doko: I wasn't aware that you asked. Where did you ask? [16:33] rbasak, by email [16:33] To whom? [16:36] doko, hey, did you see my llvm/SRU question this morning? [16:38] seb128, yes, but I didn't look at it yet. the issue is that backported llvm 3.7 packages need a different library package name when built with GCC 4.9 or earlier [16:39] doko, speaking of gcc, apparently the wily packages are built with 4.9 instead of 5 due to an issue with the debian/rules regexp issue, unsure if changing the gcc version is material for a SRU? [16:39] slangasek, when configuring my system to work on a high dpi display I noticed that console-setup, console-setup-linux, and keyboard-configuration have upstart scripts, but only keyboard-configuration has a systemd service, thus the font I selected on console-setup is never applied on boot time (there are open bugs for that) [16:39] is that the expected behavior or somtehing that needs fixing? [16:40] seb128, afaics, it's not yet used, so maybe nobody cares (and somebody should address the ftbfs on i386 and powerpc) [16:41] doko, there is a bug reported so I guess some people care [16:41] and ack on the build issues [16:47] slangasek, apart from that, I find it a bit weird that keyboard-configuration init/systemd service is named console-setup and its initram hook also handles font and depends on stuff setup by setupcon (setupcon is from console-setup, which actually depends on keyboard-configuration, not the other way around) [16:49] Mirv: do you have any clues about this x86-only build failure in phonon-backend-vlc? it looks like something internal to cmake+qt5 rather than a bug in phonon-backend-vlc's code: [16:49] In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/QtGlobal:1:0, [16:49] from /«PKGBUILDDIR»/obj-qt5/CMakeTmp/check_qt_visibility.cpp:1: [16:49] /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1052:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)." [16:49] # error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\ [16:49] tdaitx: console-setup/keyboard-configuration have a very long history, and it's possible the current state includes some historical reasons. And if the configured console-setup font is not applied at boot, yes, that's a bug and quite possibly related to this [16:50] tdaitx: cyphermox would have some recent context about console-setup; pitti might know a thing or two about how systemd expects to set console fonts [16:50] slangasek, this popped up a lot during the last cycle. iirc, the "solution" was to remove -fPIE and add -fPIC. [16:51] sbeattie, ^^^ [16:51] doko: well, but this package isn't passing -fPIE [16:52] but -fPIC? [16:52] doko: no - I mean that -fPIE is being passed but not by this package [16:52] maybe it comes from /usr/share/phonon4qt5/buildsystem/FindPhononInternal.cmake [16:54] Is there an email from gaughen_ sitting in the ubuntu-devel@ moderation queue? [16:54] there's a KDE4_ENABLE_FPIE [16:54] (And if so, who can unblock it?) [16:55] Odd_Bloke: I think cjwatson has moderation privs there; not sure who else might [16:55] me, nothing there [16:57] Odd_Bloke: ^ [16:58] Laney, sweet, thanks! [16:59] FWIW, I finally solved the problem that I came by here to figure out: [16:59] https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770/comments/1 [16:59] Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,Confirmed] [16:59] all better [16:59] 'course, IMO there's a couple of broken packages there, but whatev ☺ [16:59] works for me! 😝 [17:02] $ simple-scan [17:02] simple-scan: error while loading shared libraries: libpackagekit-glib2.so.16: cannot open shared object file: No such file or directory [17:03] seb128, ^^^ can you reproduce this? or was this something part of wily-proposed which didn't go into the release? [17:04] doko, [17:04] $ dpkg -S libpackagekit-glib2.so.16 [17:04] libpackagekit-glib2-16:i386: /usr/lib/i386-linux-gnu/libpackagekit-glib2.so.16 [17:04] do you have that package? [17:05] $ dpkg -S libpackagekit-glib2.so.18 [17:05] libpackagekit-glib2-16:amd64: /usr/lib/x86_64-linux-gnu/libpackagekit-glib2.so.18 [17:05] libpackagekit-glib2-16:amd64: /usr/lib/x86_64-linux-gnu/libpackagekit-glib2.so.18.0.0 [17:05] so, maybe left over from using -proposed during the GCC 5 transition [17:07] doko, yes, that version of packagekit was in proposed only and breaking aptdaemon and never migrated/was removed [17:07] ahh, I remember ... [17:07] but the binary should depends on the lib it uses [17:07] how does anyone debug cmake, ever? [17:07] so looks like there is a bug [17:08] slangasek: I just pinged mitya57 about this and he said he'd look, FYi [17:08] I [17:08] as a more qualified cmaker than me [17:08] Laney: alright; my question stands [17:08] this is untraceable spaghetti [17:09] check_cxx_compiler_flag(-fPIE HAVE_FPIE_SUPPORT) [17:09] so OBVIOUSLY that causes all tests to immediately start using that flag [17:10] I don't understand why this bug doesn't happen in Debian [17:10] In simple case one just needs to add something like set(CMAKE_CXX_FLAGS "-fPIC") and that will work. But looks like it's a bit more complicate here. [17:11] * mitya57 is not a CMake expert unfortunately [17:11] I can't find anything in the cmake code that explains why -fPIE is being used [17:11] maybe you'll have better luck than me [17:14] mitya57: Debian version of libphonon4qt5-dev doesn't include the check for -fPIE [17:15] ah, I thought that warning was coming from Qt itself [17:15] Actually I believe adding actually set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS}") to CMakeLists.txt will just work [17:17] maybe it's worth checking if this is fixed by a phonon merge from unstable [17:17] tdaitx: what about console-setup/keyboard-configuration? [17:17] since there are (surprising) differences in the installed cmake rules, and Debian doesn't have this problem [17:20] cyphermox, well, I set up a new font and keyboard layout for the new computer, but only the keyboard layout is being applied on boot... I'm investigating what I might be missing in my initramfs config, but anyway I noticed that console-setup, console-setup-linux, and keyboard-configuration have upstart scripts, while only keyboard-configuration has a systemd service, so the console font is not being set [17:22] * Laney stares at gstreamer-vaapi [17:23] ah right, probably just skew === sarnold_ is now known as sarnold [17:30] tdaitx: interesting. text-mode console font? [17:31] cyphermox, yes [17:31] as you expect this would be applied in initramfs, before systemd, no? [17:31] which font, for fun? if I want to install it here? [17:32] it should be [17:33] CODESET="Lat15" [17:33] FONTFACE="TerminusBold" [17:33] FONTSIZE="16x32" [17:33] cyphermox, ^ [17:33] yep, will apply this here on my temporary laptop, while the tech finishes changing the mobo [17:35] cyphermox, you might want to use a smaller one =) [17:35] in case you dont have a high dpi display [17:42] tjaalton, is anyone looking at bug #1510970 [17:42] bug 1510970 in xserver-xorg-video-intel (Ubuntu) "Intel driver crashes on Ubuntu 15.10" [Medium,Confirmed] https://launchpad.net/bugs/1510970 [17:42] seems lamont is able to reproduce easily [17:43] well, easily is more one of "I do things, and it gets mad sometime with in about 10 minutes of normal work on my laptop" [17:43] but yeah, it reproduces on an alarmingly easy basis [17:43] tdaitx: I see so well that this is a great font size for me ;) [17:44] yay, I gotz new variables now. [17:44] cyphermox, sorry, my battery ran out [17:44] cyphermox, heh, nice [17:44] tdaitx: so, I agree, needs some systemd magic [17:44] but it should also get applied before then in initramfs and it doesn't seem to be [17:44] dbg package installed, laptop rebooting for a known-fresh start, let see how hard it falls over now [17:45] cyphermox, indeed, I'm trying to figure out why [17:45] it should be run setfont in init-top though [17:47] hallyn: The T upload for bug 1511830 seems to be missing. [17:47] bug 1511830 in libvirt (Ubuntu Trusty) "apparmor denies VM startup when image is network mounted" [High,New] https://launchpad.net/bugs/1511830 [17:53] bdmurray: correct [17:53] when i uploaded those on 11/04 i was still waiting for libvirt to clear t-proposed [17:53] in fact i still am [17:53] hallyn: Re: ubuntu-vm-builder. Looked into vmdebootstrap? [17:56] Unit193: in what sense? I encourage anyone rdep'ing on vmbuilder to switch over :) [17:57] i don't think it was around last time i tried to drop vmbuilder [17:57] (from the archive) [17:57] currently rdeps are sandbox-upgrader and auto-upgrade-tester [17:59] Aha, so yes. Nice. [17:59] any chance you'd have time to work on proposed debdiffs to move those over? :-) [17:59] Laney, mitya57: well hey, it seems that this same failure causes phonon itself to FTBFS; so the problem lies deeper yet [18:00] I'm sad that I don't get to do the last upload. :) [18:00] * Laney has to go [18:00] hallyn: That's not actually directed at me is it? [18:03] [18:05] (That is, never touched those, not a core dev.) [18:06] seb128: so much for "trivial reproduction" [18:06] once I get it to die, I'll update 1510970 [18:06] lamont, :-( [18:06] thanks [18:07] seb128: it did seem to always be around a popup window being created, fwiw [18:07] write that on the bug when you get the bt [18:08] then we can do some nagging upstream ;-) [18:10] tbf, if -dbg makes it go away, ... :D [18:10] I doubt it, -dbg doesn't change runtine [18:10] runtime [18:10] those are just files on the side that gdb uses [18:13] yeah [18:13] * lamont otp meeting [18:20] Unit193: s'ok, you can still post debdiffs :) [18:22] seb128: tbf, when I installed -dbg, it upgraded the driver too [18:23] I'm tempted do downrev and grab the matching -dbg [18:24] lamont, it's likely that the update fixed it, dholbach had a similar issue and tjaalton said the new git snapshot in xenial included fixes for some similar issues [18:24] we should still find the fix for that issue and SRU it [18:24] so having a debug bt of the old version would be useful [18:25] could help to find the corresponding upstream bug/commit [18:29]