[01:05] Is anyone able to sponsor a few things for xubuntu? [01:07] bug 1282734 and bug 1282937 [01:07] bug 1282734 in xubuntu-artwork (Ubuntu) "Please update xubuntu-artwork" [Wishlist,In progress] https://launchpad.net/bugs/1282734 [01:07] bug 1282937 in xfburn (Ubuntu) "Please package xfburn 0.5.0" [Undecided,In progress] https://launchpad.net/bugs/1282937 [01:17] xnox???? [01:19] LinuxPC: It's 1:20am Monday morning for xnox, there's a fair chance he's not around. [01:21] oh, ok, I didn't know what time it is where he is. [01:21] LinuxPC: London. [01:21] infinity: can you build glibc without optimizations? [01:21] I tried just replacing O2 with O0 and it complained cannot build without optimizations [01:22] jtaylor: Dunno, never tried. It could be a mismatch of -O and -DFORTIFY that's tripping you up. [01:23] it was an actual error message telling me I need to optimize [01:23] but I wonder how do you debug it properly then [01:24] jtaylor: Right, but what was the error message? -DFORTIFY_SOURCE will yell at you at -O0, I believe. [01:24] hm ok, I'll try without fortify thx [01:25] Most people, I believe, debug it by getting good at reading optimized gdb backtraces, since an -O0 build would be sufficiently different from -O2 to not always be helpful. [01:26] I'm reasonably familiar with it too by now but for some code its just much faster to ahve O0 code [01:26] * infinity nods. [01:26] if its not serial code usually you get the same results [01:26] s/not// [01:27] though I should give the new Og flag a try once [01:28] infinity: Thanks for the info, I'll check back at a better time. What I wanted to tell him, is, I really appreciated his help. I was getting errors trying to install Ubuntu onto a new drive and then loading dual-boot so that I could still have access to my windows drive. He was an awesome help to me and I wanted him to know it. [01:54] doko_: Should gcc-4.8 depend on libgcc-4.8-dev? [01:55] doko_: Without it, doesn't exist, and pretty much nothing useful can be compiled. [01:55] doko_: (g++ pulls it in transitively through g++ -> libstdc++-dev -> libgcc-dev, hence why build-essential and the buildds are fine and don't show the problem) [01:58] doko_: And, indeed, saucy's gcc-4.8 has the dependency, so I assume maybe it got lost during the libgcc 4.8/4.9 shuffle? [02:01] infinity: no idea what's going on with libnih, but pitti mentioned libnih autopkgtest timing out on ppc64el too, so maybe that's related and it's an across-the-board regression [02:01] doko_: https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1283850 [02:01] Launchpad bug 1283850 in gcc-4.8 (Ubuntu) "Spamassassin update broke Ubuntu GNOME daily builds" [High,Incomplete] [02:01] slangasek: The libnih thing is another incarnation of https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1266492 [02:01] Launchpad bug 1266492 in binutils (Ubuntu Trusty) "ld:i386 crashes with -static -fPIE -pie" [High,Confirmed] [02:01] slangasek: Seems like a bit of a random fluke on default build flags or something that it triggers in a sid userspace and not a trusty one. [02:01] infinity: and adsb seems to think it's a toolchain bug - right [02:01] In related gcc news, why do we now have a gcc-4.9-base package that does nothing but provide a gcc [02:01] (toolchain/libc) [02:02] In related gcc news, why do we now have a gcc-4.9-base package that does nothing but provide a gcc-4.9 binary that says “you don't have gcc-4.9 installed”? [02:02] RAOF: because any compiler we build comes with a corresponding -base, but gcc-4.9 is only supported for go, not for C [02:02] RAOF: RAOF Erm, gcc-*-base don't provide any binaries... [02:03] right, there is no gcc-4.9 binary in that package [02:03] how did you come to find this out, exactly? :) [02:03] RAOF: gcc-*-base is a tiny (very tiny) package that just provides common docs for all packages built from that GCC source. [02:03] slangasek: Ah, that makes sense. It's just a bit surprising that we've got /usr/bin/gcc-4.9 that, if you call it, says “you don't have gcc-4.9 installed” [02:03] Looks like it's hardening-wrapper providing a diversion. [02:03] RAOF: So, it exists to provide the changelog and copyright for libgcc1_4.9, basically. [02:04] RAOF: Yeah, hardening-wrapper always did that to you. :P [02:04] slangasek: I found out because I noticed an upgrade install gcc-4.9-$SOMETHING and thought “ooh, I like trying newer compilers to see if they bring up any new and interesting warnings” [02:09] slangasek: So, the bug with the configure test is a binutils bug. But the part where it subsequently hangs is a glibc bug. I'm uploading a workaround to just skip past the whole mess right now, since the glibc bug is Really Hard to fix, and the binutils bug seems to have seen no traction. [02:10] slangasek: http://deb.li/3DdiR (thanks to sbeattie) [02:14] er\ [02:14] anyone willing to admit to knowing anything about setcontext? [02:17] * mwhudson now knows why his go process is crashing but isn't really sure about who is to blame [02:17] (on arm64) [02:19] mwhudson: Marcus Shawcroft would be your best bet. [02:19] yeah i think so too probably [02:19] mwhudson: Have you tested with the glibc 2.19 in -proposed? [02:20] no, but i looked at pretty recent glibc sources [02:20] mwhudson: Err, assuming this uses glibc at all. If you're talking directly to the kernel, then... Not sure who to talk to. [02:20] yeah, this is gccgo so glibc is involved [02:21] basically: setcontext copies the uc_stack of the context to the task's sigaltstack settings [02:22] which seems a bit strange [02:22] and certainly not what the gccgo runtime is expecting... [02:22] Guessing this isn't how it works on armv7? [02:22] had started to look at that but no idea at this stage [02:24] mwhudson: 402a76b62dded0ee93cfec0471aaeccb989196d2 is the ARM setcontext implementation, modulo later cleanups and bugfixes. [02:24] yeah i think that probably doesn't have the odd behaviour that's causing problems [02:25] unexpected croissant break, brb [02:25] Unexpected? Did you just get thwacked in the head by a wild croissant? [02:26] someone walked in with a tray of them [02:33] so yes, i'm feeling like this is a glibc bug [02:33] cool! i haven't found one of them recently [02:35] mwhudson: There are no glibc bugs, only features that you're using incorrectly. [02:35] infinity: i thought mr drepper was doing other things now [02:35] mwhudson: (On a more serious note, the aarch64 port is still pretty immature, and really only has the one guy working on it, so please do file bugs and annoy Marcus if you sort out solid testcases and the like) [02:35] it could also be a kernel bug, it depends how you squint [02:36] infinity: oh, i am definitely going to annoy people [02:36] mwhudson: Marcus comes back from VAC in ~6h, and will no doubt be flooded by people annoying him (including me)... Get in line. :) [02:36] haha [02:37] infinity: i presume there is a glibc bugzilla somewhere? [02:37] * infinity looks forward to arm64 kit being more widely available and the general hacker community banging on it and finding all the problems with the port. [02:37] mwhudson: https://sourceware.org/bugzilla/ [02:38] would be nice if that happened before T... [02:38] looking unlikely i guess now [02:38] Yeah, even if people start getting their hands on AMD dev boards, it's a bit too late for that to influence trusty in any meaningful way. [02:38] But some bugfixes will likely be backportable. [02:39] mwhudson: Want to CC me (adconrad@0c3.net) on your bug report, so I can keep tabs on what's going on? [02:39] infinity: sure [02:41] mwhudson: Do be sure to test with my 2.19 packages before you report bugs, though. [02:42] We're so dangerously close to mainline right now that you can almost pretend that's testing against mainline. :P [02:42] Almost. [02:42] oh heh look at that [02:42] i am already :) [02:42] (t-mwhudson)mwhudson@am1:~/gccgo-4.9-4.9-20140222$ dpkg-query -W libc6 [02:42] libc6:arm64 2.19-0ubuntu1 [02:42] Shiny. [02:43] I need to find the round tuits to set up a PPA for actual mainline builds. [02:43] So I can be warned in advanace of new testsuite failures, etc. [02:43] Instead of the post-release "hey, all this stuff is broken and I need to fix it" panic. :/ [02:44] Probably also much easier to rebase patches one day at a time instead of 6 months at a time. [02:53] er [02:53] paste.ubuntu.com is down? [02:54] infinity: test case: http://hastebin.com/qunasobobo.c [02:54] infinity: output http://hastebin.com/kacilipepi.sm [02:55] paste.ubuntu.com appears to be up [02:56] Takyoji: not accepting new pastes though [02:56] ahh, understood [02:56] anyway, have got a sysadmins attention now [03:01] what's the common practice for handling changelog entries for debian revisions in x.y.z+reallyA.B.C releases? [03:03] do i just put the intermediate A.B.D-1 changelog entry in between the x.y.z+reallyA.B.C-0ubuntu1 and x.y.z+reallyA.B.D-1ubuntu1 entries? [03:03] or do i just leave it out? [03:03] hyperair: Up to you. But if it implies bug closures and such, it might be less confusing to leave it out. [03:04] hmm, why would it be less confusing in that case? [03:04] Because people parsing a changelog for the bug might think it's closed. [03:04] *shrug* [03:04] but it is closed, is it not? [03:04] I mean if the interim new upstream release closed bugs. [03:04] i mean the bugs closed in the A.B.D-1 changelog entry [03:05] If that closed bugs, you should reopen them. [03:05] why? [03:05] ... [03:05] Because they're no longer fixed by code you're not shipping? [03:05] why wouldn't they? [03:05] the bugfixes are from A.B.C..A.B.D [03:06] i'm merging these changes into x.y.z+reallyA.B.C so that it's x.y.z+reallyA.B.D. [03:06] Oh, I may not be seeing your usecase here. I'm thinking that you're reverting from x.y.z to A.B.D, not just upgrading from A.B.C to A.B.D [03:06] i've already reverted from x.y.z to A.B.C [03:07] now i'd like to upgrade from A.B.C to A.B.D [03:07] So, if this is about us having messed up and reverted in the past and now merging with Debian's A.B.C->A.B.D, then yeah, I'd keep the Debian changelog entries in between. [03:07] rigth, and should i renumber the entries? [03:07] so that debian's A.B.C-1 entry is now x.y.z+reallyA.B.C? [03:07] Nah. [03:07] okay [03:07] What's the actual package in question here? [03:08] Is x.y.z close enough to A.B.D that the mistake will sort itself soon? [03:08] Or are we talking an order of magnitude where it might be worth begging the Debian maintainer to add an epoch to get you out of your mess? :P [03:09] banshee [03:09] i'm the debian maintainer [03:09] no epoch necessary [03:09] Ahh, yeah, that'll sort itself soon enough. [03:09] yeah [03:09] So, yeah, I'd just stuff the interim versions in there unchanged in your merge. [03:10] okay cool [03:10] infinity: https://sourceware.org/bugzilla/show_bug.cgi?id=16629 [03:10] sourceware.org bug 16629 in libc "[aarch64] setcontext clobbers alternate signal stack" [Normal,New] [03:10] "Merge changes from 2.6.1-5" [03:11] hyperair: For sanity's sake, I probably would have called that 2.9.0+really2.6.1-5ubuntu1 instead of 2.9.0+really2.6.1-0ubuntu1, as a better indication of the relationship with the Debian packaging. [03:11] infinity: yeah i realized that a little too late, and didn't think it warranted another upload [03:11] * infinity nods. === SpamapS_ is now known as SpamapS === mwhudson is now known as zz_mwhudson === tlyu_ is now known as tlyu === stub` is now known as stub === seelaman` is now known as seelaman [05:46] How can i check locally if a package supports building on ppc64el? [05:47] check build logs on launchpad? [05:47] For a merge i'm doing [05:47] https://code.launchpad.net/~noskcaj/ubuntu/trusty/garcon/merge/+merge/207861 [05:47] and two more in progress [05:54] Noskcaj: I believe the current status is ‘upload it and see’; it doesn't seem that qemu has grown support yet. [05:54] ok [05:54] And chance you could do some sponsoring then? [05:54] That said, we're in feature freeze now; does it have an exception? [05:54] bugfix releases [05:54] (Or is purely bugfix?) [05:55] Trusty has a git snapshot, it's now actually released with a bugfix or two. (Garcon) [05:55] one is bugfix + translation, the other we have a git snapshot of so it's just re-enabling docs and more translations [05:56] Noskcaj: If it has a configure script, you can make an educated guess on support. [05:57] how? [05:58] Noskcaj: Also, it might not matter unless it builds a library... [05:58] Ahh, it does. [05:58] libxfce4ui does, i'm not sure about garcon [05:58] Noskcaj: So, search for "powerpc64" in libtool.m4 and configure, and other places that have that construct. Compare the /usr/share/aclocal/libtool.m4 ... Note that your is wrong. [05:59] "your is" ? [05:59] Noskcaj: If you run dh-autoreconf, it might just solve itself, assuming autoreconf on that package relibtoolizes. [05:59] Noskcaj: The merge you linked to has old libtool macros. [05:59] garcon is also a library [05:59] s/your/yours/ [06:00] ok [06:00] https://code.launchpad.net/~noskcaj/ubuntu/trusty/libxfce4ui/4.11.1 is the other merge [06:00] In other news, why do people still do Debian merges as MPs? It's completely unreadable and unparseable. [06:01] infinity, How should i be doing it? [06:01] (debian merges) [06:01] Noskcaj: Well, that merge explicitly claims it's using dh-autoreconf for ppc64el, so I assume that works. :P [06:01] Noskcaj: I dunno. I prefer the sort of patches that MoM spits out. Delta against Debian is much more helpful (usually tiny) than delta against previous Ubuntu (can be several megs of unauditable goop). [06:02] Plus, you can interdiff deltas between Debian nicely. [06:02] Old delta was foo, new delta was bar, quick interdiff shows the 5 lines you had to change to make the merge work. [06:03] makes sense, issue being MoM makes a lot of files and clutter, which get's confusing to new people trying to merge [06:03] Surely nowhere near as confusing as a massive MP no one's going to read before committing. :P [06:03] although i should be on the reviewing end soon-ish [06:03] (And if no one's going to review it, you'd just subverted the whole point of getting a sponsor to upload) [06:03] s/you'd/you've/ [06:06] yep [06:07] my current issue being, i have both sorts of merge up, and no sponsoring anywhere [06:07] e.g. bug 1282937 [06:08] bug 1282937 in xfburn (Ubuntu) "Please package xfburn 0.5.0" [Undecided,In progress] https://launchpad.net/bugs/1282937 [06:08] (bugfix only, all major changes are already in ubuntu as patches) [06:21] Noskcaj: Well, now that feature freeze has come and gone, you might be able to find sponsors who aren't crazy busy. :) [06:22] * Noskcaj looks at sponsoring queue, 51 packages. [07:01] Good morning [07:01] good morning [07:05] hey dholbach, wie gehts? [07:06] pitti, sehr gut - und dir? :) [07:06] dholbach: still feeling a bit zombie-like with the jetlag, but ok; at least no ubuflu :) [07:09] infinity, slangasek: yes, libnih keeps getting eternally stuck on ppc64 and armhf; it even seems to reset autopkgtest's timeout timer, so not even that kicks in [07:09] infinity, slangasek: so I had to kill all of them at some point [07:15] Could someone please sponsor https://code.launchpad.net/~noskcaj/ubuntu/trusty/clutter-1.0/1.16.4/+merge/207778 ? [07:16] It's bugfixes, so it shouldn't need an FFe [07:17] infinity: ah, gunnarhj reminded me that we should refresh the -base langpacks, as we just got a new ubuntu-docs; I'm doing that now, does that still work out for beta-1? [07:17] (will also make the images smaller) === mardy_ is now known as mardy [07:44] pitti: Yeahp, should be fine, b1 freeze is later todayish. [07:45] Noskcaj: Can you find out where clutter upstream got their libtool from? [07:45] Noskcaj: It's buggy. :/ [07:45] Noskcaj: If Fedora's shipping that, they need to stop. [07:46] looking now [07:46] Noskcaj: See this bit from your diff: http://paste.ubuntu.com/6985749/ [07:46] Noskcaj: That top set should say powerpc64le and powerpc64 (as the libtool.m4 on your Ubuntu system does). [07:47] ok [07:47] Noskcaj: So, they obviously relibtoolized with a broken libtool, we should hunt down where that's coming from before it infects more upstream projects. [07:48] the git log doesn't seem to have a libtool change since 2011, but i've seen that issue before in something [07:48] doko_: I've seen 'Exception ignored in: > [07:48] pitti: Everyone's seen it. Happens on every python postinst. :P [07:48] doko_: from /usr/lib/python3.4/subprocess.py in a lot of places; postinst scripts, tests, etc.; do you know where that's coming from? that's something since the py3.4 default [07:49] Noskcaj: libtool and configure bits might not be in git at all, autogen might be part of the tarball release process. [07:49] looks like your right, i can't see libtool in the source [07:50] Noskcaj: Right, hence hunting down the guy who did the release tarball to find out what distro he made it on to see if their libtool can be fixed would be awesome. [07:50] (My guess is Fedora, since it's a fairly GNOMEish thing, but who knows) [07:50] just let my computer unfreeze from my current compiling and i'll look [07:53] pitti: apparently the kernel API broke again and fglrx doesn't build any more in Trusty. I wasn't notified. Is there a way to get the system to send me an email about it? [07:59] tseliot: we don't currenlty have anything which triggers the ubuntu-drivers-common autopkgtest on kernel uploads [07:59] tseliot: jibel is doing separate DKMS tests, they might be able to give you an email notification [08:00] tseliot: http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/Trusty%20Release%20-generic/job/dkms-trusty-release-generic-fglrx/ ran on Saturday and succeeded [08:00] pitti: err... I think it would be useful to do that when the kernel is uploaded, so that if the API breaks we know about it [08:00] http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/Trusty%20Release%20-generic/job/dkms-trusty-release-generic-fglrx_updates/ ran on Sat as well and failed [08:03] yes, it would; we could perhaps add a linux-libc-dev build dependency to u-d-common, so that the reverse dependency check mechanism kicks in? [08:04] tseliot: https://jenkins.qa.ubuntu.com/job/trusty-adt-ubuntu-drivers-common/58/ ran yesterday, did we get a new kernel since yesterday? [08:04] (and succeeded) [08:04] infinity, The developer's name is Emmanuele Bassi, i have to go and have dinner, than i'll email him === FlannelKing is now known as Flannel [08:05] pitti: How would ubuntu-drivers-common help identify if fglrx or nvidia have stopped building? [08:05] pitti: I updated my system on Saturday and the build failed. I'm not sure if they fixed it over the weekend. [08:05] apw: ^^ [08:05] pitti: Or is its autopkgtest an attempt to build everything it knows about? [08:05] infinity: its autopkgtests check our most popular dkms packages (nvidia, fglrx, bcmwl) [08:05] tseliot: There have been no new kernels over the weekend, though there is one in proposed since Friday. [08:06] infinity: https://jenkins.qa.ubuntu.com/view/DKMS/? is a more comprehensive approach to testing DKMS packages, but it doesn't hold back new kernels on failures [08:06] let me check what kernel version caused the problem [08:06] 3.13.0-11-generic [08:07] pitti: I don't know if it should hold back new kernels necessarily, but it certainly needs a notification system that isn't "refresh the page once in a while". === zyga_ is now known as zyga [08:08] infinity: I'm not sure whether it has notifications; jibel and the kernel team discussed how notifications should look like back then, but I forgot what the result was [08:08] adding email notifications to jenkins is trivial, but I don't know any more whether the kernel team actually wanted them [08:08] the failure: http://paste.ubuntu.com/6985814/ [08:08] good morning [08:12] pitti: is this a good log? http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/Trusty%20Release%20-generic/job/dkms-trusty-release-generic-fglrx/24/ARCH=amd64,label=wazn-adt/artifact/results/fglrx/13.350/3.13.0-12-generic/x86_64/log/make.log [08:12] pitti: "build succeeded with return value 0 duplication skipped - generator was not called from regular lib tree done." [08:17] pitti: the log from "successful" builds looks exactly like the one from the failed build (19 February) [08:23] at least it seems the compilation worked? [08:27] pitti: it still doesn't here [08:27] let's try the kernel in -proposed [08:34] I'm having problems installing Skype on my 64 bit Trusty machine. Is this the right place to as for help? Output of "apt-get install skype" and "apt-get install skype-bin" and some other commands at: http://upload.egarden.fi/apt-get_install_skype_failed.txt [08:38] Wnt: You want #ubnutu, this isn't a support channel. [08:39] yes, #ubuntu [08:39] Hello guys! I need help with a FTBFS issue on trusty. [08:39] anyone has a few minutes to spare? [08:40] phanimahesh: Depends on the issue and the minutes. Just ask. [08:40] unity-tweak-tool is a package in the repos, and I am a member of its dev team. [08:40] python3.4 transition issues [08:40] And due to a python transition issue, tha package fails to build on trusty. [08:41] and i'm not able to figure out how to fix it. [08:41] Wasn't that fixed in the archive 4 days ago? [08:41] + python3.3 setup.py build --executable=/usr/bin/python3 [08:41] /bin/sh: 2: python3.3: not found [08:42] that is the relevant error message in the failed build log [08:42] phanimahesh: That should just be python3, not python3.3 [08:42] https://github.com/freyja-dev/unity-tweak-tool/blob/master/debian/rules [08:42] That is our debian/rules [08:42] http://launchpadlibrarian.net/167142991/unity-tweak-tool_0.0.6_0.0.6ubuntu1.diff.gz [08:43] phanimahesh: Like I said, this was already fixed in the archive, afaict. [08:43] Andrew should probably have forwarded you the patches, but there you go. The last build in trusty was against python3.4 as default, and worked fine. [08:43] Oh. [08:43] Thanks. :) [08:43] I did see that he backported a crash fix, [08:44] but did not notice the change to debian/rules. [08:44] And debian/control. [08:44] I'll pull in the changes. [08:44] Thanks. [08:44] Equally important. [08:44] yup. just looked at the changelog. [08:44] thanks! === mthaddon` is now known as mthaddon [08:58] Hey guys! I have to geplace gksudo by pkexec. But how can i display a special message to the user like gksudo --message "Hey you"? [08:58] replace [09:00] imapados: it uses the polkit .policy's message, see e. g. /usr/share/polkit-1/actions/com.ubuntu.update-notifier.policy [09:00] thx, pitti! [09:00] imapados: the pkexec caller can't set an arbitrary message [09:00] that's quite by design [09:01] Hmmppff.. [09:01] Noskcaj: infinity: thanks for your help. [09:01] no problem [09:01] But you won't use gksudo in future? [09:01] I should have noticed it earlier, though. [09:01] imapados: we have dropped gksudo for almost everything many cycles ago already, so yes [09:02] so, i will follow you! ;) [09:09] infinity: ok, built and tested; upload ahoi [09:10] pitti: Should all build before stgraber wakes up, so yay. :) [09:10] Especially with that massive army of x86 builders you now have... [09:15] infinity: indeed; I wonder whether they can keep up with debuild/dputting them :) [09:16] hm, probably should have updated the chroots before, but *shrug* too late [09:16] You mean the LP buildd chroot? [09:16] yes === iulian is now known as Guest58541 [09:17] pitti: The largest portion of that upgrade (libc6 and gcc) is in -proposed, which isn't in the chroots, so wouldn't win you much. [09:17] ah, ok [09:17] 54 upgraded packages [09:18] Not like 2m builds are a big deal. :P [09:23] langpack pwned! https://launchpad.net/builders [09:24] doko_: hey, I'd like to understand https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732703 better [09:24] Debian bug 732703 in python3.4 "python3.4: cannot create a virtualenv" [Normal,Open] [09:24] doko_: that effectively breaks virtualenv on python3.4 [09:24] doko_: is that the status quo for the next 5 years or is this still something we can fix for trusty? === doko_ is now known as doko [09:31] zyga, mind adding something constructive to the bug report? [09:33] doko: I try to understand what's the current status first, is ensurepip deliberaltely disabled? [09:35] I just found that it is, what is the reason for that? [09:37] zyga, see debian-devel about shipping pip. debian wants to use the pip shipped by debian. and I don't want to have the ensurepip interfer with the system python [09:38] doko: I see, that makes sense, so pyvenv-3.4 should link to the local copy of pip, right? [09:38] doko: (currently you just get a relatively useless virtualenv as you know, with just bare python) [09:39] zyga, yes, but it is currently my highest priority [09:40] doko: so you are working on this? [09:40] no [09:40] doko: can I help you somehow? [09:40] doko: it is your highest priority or isnt? [09:41] ahh, typo. no, not my highes prio [09:41] ah [09:42] doko: do you have a preferred solution to this problem? is it just as simpe as symlinking pip pip-3 pip-3.4 in the right place? [09:42] *simple [09:43] zyga, if you have patch, please send it [09:43] doko: I'm willing to work on it if I know that's the right solution you will accept [09:44] you'll need to find this solution. I just outlined the requirements [09:44] doko: ok, thankyou === ev_ is now known as ev [09:57] doko: can you tell me if the older version of python3-pip is a part of the story? upstream released 1.5.4, debian (and trusty) is at 1.4.1 [09:58] doko: is that deliberate due to wheels or is that just lack of manpower? [09:58] infinity: cjwatson: Can I have a slither of moderation in the direction of u-d-a please? [09:58] can do, too [09:58] oh really? [09:58] done [09:58] you should be on here then https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce [09:58] thanks! [09:59] Laney: well, I don't admin the ML, I just have a moderation pw [09:59] mmm, "run by" [09:59] It's a hard (hah!) password to forget. [09:59] anyway, happy voting [09:59] *shrug* ~/.listadmin.ini FTW :) [10:00] Laney: Is it bad if I put everyone below None of the Above? [10:00] *chuckle* [10:00] Or, I guess, none of the below... [10:00] it's NOTB [10:00] infinity: haha =) [10:00] if that expresses your thoughts :-) [10:01] Nah. Not this time around. :) [10:02] Snow-Man: hey [10:02] Snow-Man: you asked me about http://www.postgresql.org/message-id/52D6D914.8090207%40agliodbs.com the other day [10:03] Snow-Man: FWIW, I think that features like conf.d are rather useless if you can disable them [10:03] Snow-Man: especially if you can do so at runtime [10:04] Snow-Man: for Debian I'd enable it in the packages, and we can then change p-common to use those instead of always modifying the default one in-place [10:07] ev, bdmurray_: the e.u.c trusty retracing have quite some issues, is there anything we can do help figuring out what is wrong? like the ranking shows we have new compiz/unity segfaults but the reports are of no use since retracing doesn't work [10:07] Snow-Man: while configurability doesn't hurt distros so much, it entirely breaks configuration tools/GUIs that are supposed to work everywhere [10:07] doko, I suppose you have already seen this, but Bug 1283850 is blocking all things beta1-ish like QA for ubuntu GNOME, would be great if you can take a look today ;) [10:07] bug 1283850 in gcc-4.8 (Ubuntu) "Spamassassin update broke Ubuntu GNOME daily builds" [High,Triaged] https://launchpad.net/bugs/1283850 [10:07] Snow-Man: so if you want to make it configurable, you can just as well drop the feature entirely; halves the testing space and avoids trouble [10:07] ev, bdmurray_: e.g https://errors.ubuntu.com/problem/44226fe8b2fa8e16ed82ac4469f9b26e726420a0 [10:08] darkxst, please ask ScottK, I didn't update spamassassin [10:14] doko: well commentry on the bug report, suggests gcc missing a build-dep on libgcc-x.y-dev. [10:14] doko: unless that was intentional... [10:15] hmm, no [10:18] hmm, more gccgo fallout [10:21] pitti, we don't have detailed logs of retracings anymore? [10:22] seb128: on the porter box? nothing changed wrt. logging for a long time [10:22] I didn't look at those for ages [10:24] seb128: I still saw proper logs a few days ago; which logs do you mean? [10:24] pitti, I'm trying a retracing by hand, trying to figure out why https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1283885 is missing unity symbols [10:24] Launchpad bug 1283885 in unity (Ubuntu) "compiz crashed with SIGSEGV in __dynamic_cast()" [Undecided,New] [10:25] "dynamically loaded /usr/lib/compiz/libunityshell.so needs package unity, queueing [10:25] " [10:25] that part looks ok [10:25] pitti, I only see "retracing <...>" in the log, not the logs of the actual retrace (that would hint on why symbols are missing) [10:27] shrug [10:27] #4 0x00007f5b7c526b3a in ?? () from /tmp/s/usr/lib/compiz/libunityshell.so [10:27] No symbol table info available. [10:27] but no indication why that's missing [10:27] the package looks current at least [10:27] doko, it was the gcc update that killed it, read the bug ;) [10:28] pitti, is there any way to tell apport-retrace to display infos about the ddebs it fetches? [10:28] the log has [10:28] "dynamically loaded /usr/lib/compiz/libunityshell.so needs package unity, queueing" [10:28] then the gdb bt [10:28] no debug in between [10:29] WARNING: /home/townsend/.compiz-1/plugins/libunityshell.so is needed, but cannot be mapped to a package [10:29] seb128: ^ [10:29] seb128: ah sorry, different bug [10:30] seb128: that's your local log? because I don't see that on the porter bos [10:30] pitti, on osageorange [10:30] $ ls cache-amd64/Ubuntu\ 14.04/apt/var/cache/apt/archives/*unity_*ddeb* [10:30] box [10:30] pitti, I ran the command manually on porter to have the log [10:30] $ apport/bin/apport-retrace -sv --auth launchpad-credentials -S config --sandbox-dir=/tmp/s 1283885 [10:31] doko: that broke fglrx too here (trusty amd64). The module won't build although the relevant headers are included: http://paste.ubuntu.com/6985814/ [10:31] bah [10:32] pitti, ddebs are missing from http://ddebs.ubuntu.com/pool/main/u/unity/ [10:32] go ddeb-retriever! [10:32] pitti, that version is 4 days old, can we rescue them? [10:32] seb128: yes, hang on [10:32] thanks [10:33] err, buildds don't have ddebs any more from Feb 20? [10:33]