| Fudge | any truth to roumers about a Ubuntu mate remix? | 03:53 |
|---|---|---|
| Fudge | roumors | 03:54 |
| cjwatson | Fudge: I've heard some noises about it, but it hasn't reached the point of people coming to the release team asking for official builds yet. | 03:58 |
| cjwatson | I think there is some work happening on it though. | 03:58 |
| Fudge | thanks very much cjwatson | 04:07 |
| Fudge | we were thinking of a meta package for Vinux users who love the old Gnome2 feel but personally I like Unity | 04:08 |
| === timrc is now known as timrc-afk | ||
| pitti | Good morning | 05:21 |
| pitti | Noskcaj: are iodbc and unixodbc now installable in parallel, or did Debian's psqlodbc now drop support for iodbc? | 05:22 |
| pitti | doko_: I forwarded the unity-scope-click autopkgtest failure to dobey; seems the new gcc now emits a new warning which makes it FTBFS | 05:42 |
| pitti | doko_: that's the one that holds back the gcc-4.0 upload, FYI | 05:42 |
| === smb` is now known as smb | ||
| === alexlist` is now known as alexlist | ||
| === doko_ is now known as doko | ||
| cristian_c | Hi | 08:54 |
| cristian_c | I was testing a wifi guide to enable the EOL repositories | 08:54 |
| cristian_c | apt-get update is working, but apt-get install no | 08:55 |
| Laney | doko: are you aware of gcc-doc bustage? | 08:56 |
| cristian_c | I get many 404 not found | 08:56 |
| cristian_c | *s | 08:56 |
| cristian_c | Investigating, I discovered that EOL repositories are not updated | 08:57 |
| cristian_c | I was suggested to open a bug report for these problems | 08:58 |
| cristian_c | Can you confirm this problem and explain how to open the report in my case? | 09:00 |
| pcarrier | hi! I've been frustrating by the gdb/ddeb experience on precise. coming from the el world, after a debuginfo-install I get source listings out of the box when inspecting core dumps | 09:00 |
| pcarrier | am I missing something to make it work? | 09:00 |
| pcarrier | for example, here I'm pretty sure I installed the correct version of rsyslogd-dbgsym, yet gdb doesn't find the source: | 09:02 |
| pcarrier | #3 0x00000000004319a6 in qqueueEnqObj (pThis=0x23d6d80, flowCtlType=eFLOWCTL_NO_DELAY, pUsr=<optimized out>) at queue.c:2400 | 09:02 |
| pcarrier | 2400 queue.c: No such file or directory. | 09:02 |
| === liska is now known as human_resource | ||
| seb128 | do we have a script that does "fetch all the debs from a ppa build"? | 09:38 |
| darkxst | seb128, as in all debs for a single package? no idea if there is a script I just do it with apt pinning | 10:31 |
| seb128 | darkxst, I don't want to use apt, typically I just want to wget/download the debs from a build page, like https://launchpad.net/~ci-train-ppa-service/+archive/landing-019/+build/6072535 | 10:32 |
| seb128 | that's for local reviewing, not for installing | 10:32 |
| darkxst | seb128, source or binary? | 10:33 |
| shadeslayer | bdmurray: none of the issues listed on http://people.canonical.com/~ubuntu-archive/phased-updates.html against kde-workspace can be found | 10:34 |
| seb128 | hey SRU team, could anyone review unity-settings-daemon in the trusty SRU queue? it fixes an important issue with touch screen configs that the oem team would be happy to see resolved | 10:34 |
| shadeslayer | oh | 10:35 |
| seb128 | darkxst, binaries, I get dget the .dsc for source, but e.g the url I just copied a > 10 debs | 10:35 |
| seb128 | darkxst, it's a bit annoying to click on them all and click download for each | 10:35 |
| === Ursinha is now known as Ursinha-afk | ||
| darkxst | seb128, pretty sure you could the urls in less than 10 lines of python, but I dont have a script | 10:36 |
| === Ursinha-afk is now known as Ursinha | ||
| seb128 | darkxst, right, I was just asking in case we had a standard script is some devtools collection | 10:36 |
| seb128 | I'm going to write one myself otheriwse | 10:36 |
| seb128 | just trying to avoid reinventing things | 10:36 |
| seb128 | thanks for replying though ;-) | 10:37 |
| mlankhorst | Laney: I've reviewed my code and found some more missing unlock paths, can you try mesa - 10.1.3-0ubuntu1+ppa1 from the canonical-x/x-staging ppa? | 10:37 |
| Laney | mlankhorst: okay, in a short while | 10:37 |
| Laney | is this going upstream? | 10:37 |
| seb128 | bdmurray, infinity, stgraber, arges, slangasek, ..., ^ see the unity-settings-daemon ping some lines earlier, if one of you could have a look this week that would be nice ;-) | 10:37 |
| mlankhorst | eventually | 10:37 |
| mlankhorst | need to review it some more first | 10:38 |
| === rbasak_ is now known as rbasak | ||
| zbenjamin | can anyone tell me what getprop "ro.product.cpu.abi" would return on a amd64 machine? | 10:40 |
| zbenjamin | would it be also x86 | 10:40 |
| ogra_ | zbenjamin, only if you have an android running on your amd64 :) | 10:41 |
| ogra_ | (i doubt there are amd64 android builds) | 10:41 |
| zbenjamin | ogra_: i see, it will still be a 32bit build hmmm | 10:42 |
| ogra_ | what are you trying to do ? | 10:42 |
| zbenjamin | ogra_: i need to map the devices abi to the abi inside QtCreator and right now i look for a way to find out whats the correct way | 10:42 |
| ogra_ | for the using the emulator ? | 10:43 |
| ogra_ | (i mean, do you look for the arch of the host or of the target system ? getprop will not be available on desktops, only indsie ubuntu touch VMs or real HW) | 10:45 |
| ogra_ | *inside | 10:45 |
| zbenjamin | ogra_: for the target system | 10:50 |
| ogra_ | for that using getprop should be okayish | 10:51 |
| zbenjamin | i could use uname i guess | 10:51 |
| ogra_ | yeah, that works for sure | 10:51 |
| zbenjamin | ogra_: thx | 10:51 |
| ogra_ | and will even work once we have actual x86 tablets etc | 10:51 |
| * zbenjamin --> lunch | 10:51 | |
| ogra_ | (that dont use an android container) | 10:51 |
| zbenjamin | ogra_: yeah thats what i had in mind | 10:52 |
| zbenjamin | bbl | 10:52 |
| ogra_ | note that it wont return debian arches that way though | 10:52 |
| ogra_ | phablet@ubuntu-phablet:~$ uname -m | 10:53 |
| ogra_ | armv7l | 10:53 |
| === _salem is now known as salem_ | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === salem_ is now known as _salem | ||
| xnox | zbenjamin: uname returns the kernel, not the userspace abi. Uname can be amd64, yet userspace i386. | 11:44 |
| xnox | zbenjamin: i think you want $ dpkg --print-architecture | 11:44 |
| xnox | zbenjamin: but thanks to qemu-user-static for example I can execute armhf, i386 and amd64 binaries on my amd64 machine. | 11:45 |
| xnox | ev: errors.ubuntu.com is not showing a graph =( | 11:46 |
| ev | xnox: we just cut over to a new database. That will return ~tomorrow. | 11:50 |
| xnox | ev: =( ok. | 11:50 |
| === human_resource is now known as animal_resource | ||
| === lderan_ is now known as lderan | ||
| === pitti_ is now known as pitti | ||
| === rickspencer3_ is now known as rickspencer3 | ||
| === pete-woods is now known as pete-woods-lunch | ||
| zbenjamin | xnox: what i need is the architecture/abi i have to use to compile apps for the device | 13:32 |
| xnox | zbenjamin: at the moment we have two: armhf (all devices + emulator) and i386 (emulator) | 13:33 |
| xnox | zbenjamin: adb shell dpkg --architecture, will tell you the architecture device is running. | 13:33 |
| xnox | --print-architecture that is | 13:34 |
| cjwatson | seb128: script> citrain in phablet-tools-citrain is sort of close | 13:35 |
| ogra_ | did that land already ? | 13:37 |
| cjwatson | Well, I have it from ppa:phablet-team/tools | 13:37 |
| ogra_ | oh, it is a separate package | 13:37 |
| ogra_ | yeah, i thought it was supposed to be merged into phablet-tools | 13:38 |
| cjwatson | it's in utopic though | 13:38 |
| ogra_ | (it did ... but only on source level ... produces its own binary) | 13:38 |
| === olli_ is now known as olli | ||
| ev | make experts: is there any way of having a match-anything rule that doesn't try to evaluate files? I'm trying to have a fallback rule that effectively passes an argument to another rule, so that I can do `make name.of.test.to.run` | 14:05 |
| ev | and then a rule (with dependencies) gets executed, passing name.of.test.to.run as a command line argument | 14:05 |
| cjwatson | does declaring the non-file-based-target in .PHONY help? | 14:07 |
| ev | cjwatson: nope - so perhaps I'm doing something entirely wrong here: http://paste.ubuntu.com/7628766/ | 14:15 |
| === _salem is now known as salem_ | ||
| ev | $@ ends up being the first file in the directory, Makefile | 14:15 |
| jtaylor | ev: have a variable with ?= | 14:15 |
| jtaylor | e.g. TESTS ?= $(wildcard *runfiles) | 14:16 |
| jtaylor | make TESTS=on-ythis-file-please | 14:16 |
| jtaylor | like regular make check | 14:16 |
| jtaylor | automake check | 14:16 |
| ev | yeah, I guess I could fall back to that. It just looks ugly and creates inconsistency between running ./run-tests with arguments and feeding something an env var. | 14:17 |
| ev | but I'm already abusing make for this | 14:18 |
| jtaylor | its not an env variable its a make variable | 14:19 |
| ev | indeed | 14:19 |
| mlankhorst | Laney: ping? :P | 14:20 |
| Laney | not yet sorry | 14:20 |
| === mbarnett` is now known as mbarnett | ||
| pitti | cjwatson: is there something like "click uninstall", or is that simply "sudo rm -r /opt/click.ubuntu.com/com.ubuntu.calculator/" ? | 14:28 |
| pitti | I found "unregister --all-users", but that's not the same | 14:29 |
| === pete-woods-lunch is now known as pete-woods | ||
| ogra_ | pitti, adb shell click unregister --user=phablet $PACKAGE | 14:30 |
| cjwatson | pitti: unregister | 14:31 |
| doko | dobey, could you have a look at https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scope-click/lastBuild/? not sure if pitti already told you | 14:31 |
| cjwatson | Don't just do rm -r, you'll leave bits behind | 14:31 |
| seb128 | cjwatson, thanks | 14:33 |
| pitti | cjwatson: I tried that (with and without --all-users), it still leaves /opt/click.ubuntu.com/com.ubuntu.calculator/* behind | 14:34 |
| pitti | that just hides it | 14:34 |
| cjwatson | pitti: in general that depends whether the app is running | 14:35 |
| cjwatson | it should get GCed eventually; normally, don't worry about it | 14:36 |
| pitti | cjwatson: ah, ok; thanks! | 14:36 |
| cjwatson | --all-users likely isn't what you want unless it was registered with --all-users to start with | 14:36 |
| pitti | cjwatson: I don't know how it was registered; it's installed by default | 14:36 |
| pitti | cjwatson: use case: for testing a local .click I wanted to ensure that no other version is installed, and then click install that one; but perhaps I don't need to do that cleanup | 14:38 |
| cjwatson | you don't | 14:38 |
| cjwatson | any user-installed version will override things installed by default | 14:38 |
| cjwatson | the installed-by-default stuff will be in /usr/share/click/preinstalled/, not /opt/click.ubuntu.com/, and it is generally not possible to remove those (unless the image is writable) | 14:38 |
| cjwatson | so we don't try, we just hide it | 14:38 |
| cjwatson | but anyway the structure of the database makes that sort of care unnecessary | 14:39 |
| cjwatson | https://click.readthedocs.org/en/latest/databases.html FWIW | 14:39 |
| pitti | hmm; apparently I managed to actually remove /opt/click.ubuntu.com/com.ubuntu.calculator/1.3.279/ (as on current image), but still have 1.3.277/ (my local install), and now can't unregister/remove the latter | 14:39 |
| pitti | cjwatson: thanks | 14:40 |
| cjwatson | look through /opt/click.ubuntu.com/.click/, there might be a @gcinuse thing somewhere | 14:40 |
| pitti | ah, 276 was in the image, 279 came as an app update | 14:40 |
| cjwatson | in any case, it isn't supposed to matter - the version that's actually used is looked up dynamically in the .click directories | 14:41 |
| cjwatson | stray versions are allowed to hang around a bit | 14:41 |
| dobey | doko: yes. will have a fix in a few minutes | 15:00 |
| zbenjamin | xnox: thx | 15:15 |
| rbasak | infinity: ping, re: juju-core powerpc ftbfs | 16:00 |
| infinity | rbasak: Yo. I'm still trying to get to the bottom of it. But, as I said yesterday, why should a utopic FTBFS be holding up trusty in any way? We already know it builds on trusty. | 16:16 |
| rbasak | Sorry, I must have missed your reply. | 16:16 |
| rbasak | I wanted Fix Released status in Utopic for an SRU to Trusty. But I guess having it in utopic-proposed is enough? | 16:17 |
| infinity | rbasak: Having it in proposed is enough. | 16:18 |
| infinity | rbasak: The point of that rule isn't that development users are more important and must get the fix first, the point is for the fix to not get lost/forgotten in the devel release. Uploaded, or even commited to a branch that you guarantee will get uploaded, is good enough. | 16:18 |
| rbasak | OK, thanks. I'll work on the SRU. | 16:19 |
| ogra_ | did we switch the compiler default to 4.9 already ? | 16:46 |
| hallyn | xnox: hey, you're DD right? Would you mind taking a look at http://people.canonical.com/~serge/netcf-src-0.2.4/netcf_0.2.4-1.dsc and potentially sponsoring it? | 16:46 |
| hallyn | xnox: normally ahs3 uploads for me but he's swamped with real life | 16:46 |
| xnox | hallyn: sure. | 16:46 |
| hallyn | xnox: thanks! | 16:46 |
| ricmm | ogra_: lemme know if I missed the reply | 16:47 |
| xnox | hallyn: i need to sprint somewhere with you, to get keys cross-signed. | 16:48 |
| ogra_ | doko, did we swithc the compiler default to 4.9 already ? | 16:48 |
| * xnox hasn't seen verification failed in a long time. | 16:48 | |
| ricmm | xnox: hey, are we using 4.9 by default in u now? | 16:48 |
| ricmm | or doko | 16:48 |
| xnox | ogra_: ricmm: i believe we use 4.9 by default from now on. Let me find out when that happened. | 16:50 |
| ogra_ | must have been very recent | 16:50 |
| xnox | ogra_: it's about a month late. | 16:51 |
| xnox | ricmm: older compilers are still available and you can choose to use an older one. | 16:51 |
| hallyn | xnox: are you going to be at linuxcon chicago or plumbers dusseldorf? | 16:52 |
| xnox | ogra_: as off 2 hours ago. | 16:52 |
| ogra_ | hah ! | 16:52 |
| hallyn | anyway come up with a pretext i love to sprint :) | 16:52 |
| ogra_ | ricmm, so that might be your prob :) | 16:52 |
| ricmm | it is indeed | 16:53 |
| ricmm | I just checked, the first failing build is using 4.9 | 16:53 |
| ricmm | instead of 4.8 | 16:53 |
| ricmm | boom headshot | 16:53 |
| ricmm | I'm never landing my stuff | 16:53 |
| ogra_ | oh my | 16:53 |
| xnox | slangasek: ^ can i go to linuxcon chicago or plubmers dusseldorf? Or have a cloud vs core stand-off sprint =) | 16:53 |
| cjwatson | as he said you can Build-Depends: gcc-4.8 and set CC=gcc-4.8, or similar | 16:53 |
| ogra_ | right | 16:54 |
| xnox | ricmm: build-depend on gcc-4.8 set 4.8 compiler. Or give me the build failure and maybe i can fix it for you? | 16:54 |
| cjwatson | though clearly this is technical debt | 16:54 |
| slangasek | xnox: ... to get keys cross-signed with hallyn? | 16:54 |
| xnox | ricmm: what's the build log? | 16:54 |
| ogra_ | cjwatson, just that this needs a change of the MP and means re-testing everything again | 16:54 |
| xnox | slangasek: yes. | 16:54 |
| cjwatson | ogra_: sure | 16:54 |
| ricmm | xnox: this is a tough header-based thing with dbus-cpp | 16:54 |
| ricmm | its not a build failure, its a runtime hashtable explosion | 16:54 |
| xnox | ricmm: that's fine, what's the build failure? =) | 16:54 |
| ricmm | so maybe an ABI break somewhere | 16:54 |
| ogra_ | cjwatson, ricmm is only trying to land that since 4 weeks :P | 16:54 |
| slangasek | xnox: try to be more circumspect about your motives | 16:54 |
| ogra_ | it was done today :) | 16:54 |
| cjwatson | ogra_: this isn't really a helpful line of argument ... | 16:54 |
| ricmm | there is no argument, forget about it all | 16:55 |
| ogra_ | not a line of argument at all ... | 16:55 |
| xnox | ricmm: i believe dbus-cpp is compiled with 4.7, maybe we need to recompile dbus-cpp with 4.9 | 16:55 |
| ogra_ | just a comment | 16:55 |
| ricmm | I'll have this thing work 4.8 and bye bye | 16:55 |
| ricmm | dbus-cpp is 4.8 | 16:55 |
| ricmm | probably will need a recompile yea | 16:55 |
| ricmm | I'll figure it out dont worry | 16:55 |
| ricmm | just wanted to know when the change had happened | 16:55 |
| ricmm | to confirm | 16:55 |
| ricmm | thanks | 16:55 |
| hallyn | lol. xnox: slangasek ain't gonna go for that one :) | 16:57 |
| hallyn | xnox: i bet we can come up with very good reasons. systemd.vs.cgmanager.vs.lxc comes to mind | 16:58 |
| hallyn | which is very much inplay at both linuxcon and plumbers, in fact | 16:58 |
| cjwatson | ricmm: perhaps this is simply that dbus-cpp is hardcoding 4.8 and something built on it is failing to hardcode 4.8 and was assuming that default gcc == 4.8 | 16:59 |
| cjwatson | or something like that | 16:59 |
| hallyn | mdeslaur: stgraber: (zul:) if no objections i'll push http://paste.ubuntu.com/7629496/ | 17:01 |
| mdeslaur | hallyn: fine with me | 17:02 |
| hallyn | mdeslaur: on the topic, are you actively working on the $)(*&)%(* required for virt-manager merge, or are we all just hoping someone else does it? :) | 17:02 |
| hallyn | i'll try to look into it assuming you do not have time. | 17:02 |
| hallyn | or, that's right, you were mentioning something new that may be easier to have ppl switch to? | 17:03 |
| stgraber | hallyn: LGTM | 17:03 |
| hallyn | thx, pushing | 17:03 |
| mdeslaur | hallyn: I've done it, it's just that there are a zillion MIR bugs to file | 17:03 |
| hallyn | mdeslaur: right, that's waht i meant | 17:03 |
| mdeslaur | hallyn: give me a couple of days, and I'll take a look | 17:03 |
| hallyn | although, | 17:03 |
| hallyn | virt-manager isn't in main is it? | 17:03 |
| mdeslaur | yeah, it is | 17:03 |
| hallyn | egads | 17:04 |
| mdeslaur | right | 17:04 |
| mdeslaur | might be easier to demote it :P | 17:04 |
| hallyn | ok - thanks, happy to wait :) | 17:04 |
| hallyn | yes, | 17:04 |
| mdeslaur | is it part of anything strategic that we ship? | 17:04 |
| hallyn | i'm not sure anyone uses it on server anyway... | 17:04 |
| hallyn | not that i know of | 17:04 |
| mdeslaur | ok, I'll look into that possibility too | 17:04 |
| hallyn | jamespage: smoser: ^ do you know if virt-manager needs to be in main for any particular reason? | 17:05 |
| hallyn | the only thing rdepending on it is ubuntu-virt-mgmt :) which sounds like a bogus metapackage | 17:05 |
| hallyn | oh and is in universe anyway | 17:06 |
| * sarnold weighs how many MIRs might be needed vs having a simple bloody tool that can show which VMs are actually running... | 17:06 | |
| smoser | hallyn, i dont have a good reason off the top of my head | 17:07 |
| hallyn | sarnold: simple tool like xterm -e "while :; do virsh list; sleep 5m; done" | 17:08 |
| hallyn | :) | 17:08 |
| * sarnold hugs hallyn | 17:08 | |
| hallyn | lol | 17:08 |
| rbasak | hallyn: you know about watch, right? "watch -n300 virsh list" | 17:20 |
| hallyn | i do | 17:29 |
| hallyn | but what can i say i like manually looping | 17:30 |
| rbasak | You like doing what? :) | 17:33 |
| sarnold | the man likes to control his own loops | 17:34 |
| sarnold | he'd have used goto except shell makes that hard :) | 17:34 |
| doko | ricmm, what exactly is the issue? didn't see a reply when xnox or ogra_ were asking | 17:35 |
| ogra_ | doko, dbus-cpp is compiled against 4.7 or 4.8 | 17:35 |
| ogra_ | that caused a bunch of build issues now | 17:35 |
| doko | ogra_, and why is this an issue? | 17:35 |
| ogra_ | dunno ... they are working on porting it now ... | 17:36 |
| xnox | doko: no reply either. | 17:36 |
| ogra_ | (no worries, it was just the info that the default switched that was important ) | 17:36 |
| xnox | ricmm: can you please give us projects which need fixing? | 17:36 |
| xnox | ricmm: doko and I, are both from foundations team and we are ultimately responsible to get all packages fixed for 4.9. | 17:37 |
| ogra_ | xnox, silo 007 | 17:38 |
| ogra_ | rebuilding the location-service FTBFS due to dbus-test-runner timing out | 17:39 |
| ogra_ | xnox, doko, seems a simple rebuild of dbus-cpp fixes everything ... it was just that nobody was aware the default had changed | 17:40 |
| doko | ogra_, xnox: it's suspicious that a simple rebuild fixes things ... | 17:46 |
| ogra_ | well, dbus-cpp is special :) | 17:46 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| doko | dobey, thanks for the fix | 18:50 |
| dobey | no problem :) | 18:50 |
| === roadmr is now known as roadmr_afk | ||
| pitti | jcastro: hey! so I'm trying "juju quickstart" as in your tutorial, as that looked really nice; I get http://paste.ubuntu.com/7630057/ and now it's just hanging | 19:15 |
| pitti | jcastro: and no running wget; any idea how I can check what's going on? | 19:15 |
| jcastro | pitti, can you ping frankban on #juju-gui? Marco and I are in the middle of another session | 19:15 |
| pitti | jcastro: strace is just in an endless futex wait | 19:15 |
| pitti | jcastro: sure, thanks | 19:15 |
| xnox | tedg: !!!! | 19:38 |
| tedg | ? | 19:38 |
| xnox | tedg: oh, surprisingly it wasn't you this time =) | 19:38 |
| xnox | tedg: indicator-datetime adding a semi-bogus recommends =) | 19:39 |
| tedg | ? | 19:39 |
| xnox | bug 1309063 | 19:39 |
| ubottu | bug 1309063 in Indicator Date and Time "It's confusing to use the Incoming Call sound for Alarms" [Medium,In progress] https://launchpad.net/bugs/1309063 | 19:39 |
| xnox | pulls in ubuntu-touch-sounds | 19:40 |
| xnox | into all instalations of indicator-datetime => everywhere | 19:40 |
| tedg | xnox, not sure that's a bad thing? how else would we ensure we had an alarm sound? | 19:41 |
| xnox | tedg: indicator-datetime does alarms on xubuntu & unity7 ?! | 19:56 |
| xnox | tedg: and it should fallback to the desktop sound theme -> thus get alarm sound from the theme | 19:56 |
| xnox | not a file on disk | 19:56 |
| tedg | xnox, I believe the issue there is that the mechanisms on the phone aren't theme aware. | 19:57 |
| tedg | xnox, And we will do alarms if someone uses that Ubuntu SDK to set them. | 19:57 |
| xnox | k, cool. | 19:59 |
| xnox | weird, i thought sounds came from the same themeing capability as icons. | 19:59 |
| xnox | and i thought we do have that in the sdk -> well, pure qt | 20:00 |
| tedg | xnox, It's similar, but just a matter of programming :-) | 20:01 |
| === roadmr_afk is now known as roadmr | ||
| === ming is now known as Guest58318 | ||
| === roaksoax_ is now known as roaksoax | ||
| === salem_ is now known as _salem | ||
| slangasek | ricmm, doko: bug #1329089 filed | 22:36 |
| ubottu | bug 1329089 in gcc-4.9 (Ubuntu) "g++-4.9 binary incompatibilties with libraries built with g++-4.8" [Critical,New] https://launchpad.net/bugs/1329089 | 22:36 |
| slangasek | ricmm, doko: I think I'm going to revert the gcc-defaults change, until we have a handle on the cause of this incompatibility | 22:37 |
| infinity | slangasek: You'd think that if this was a fundamental ABI breakage issue, we'd have seen it in a lot of testsuite during the 4.9 rebuild tests, since most of them would have been running against 4.8-built libraries. | 23:08 |
| infinity | slangasek: Is it possibly that dbus-cpp itself is just doing something Very Bad? | 23:08 |
| slangasek | infinity: interestingly we've turned up that at the time of the archive rebuild, several of these components were hard-coded to use a different compiler /earlier/ than 4.8 | 23:08 |
| slangasek | so it's possible that this was a 4.8-specific ABI breakage | 23:08 |
| infinity | slangasek: Or possible that these components are somehow crazy. :P | 23:09 |
| slangasek | you don't blame the python script when the interpreter segfaults, and you don't blame the library when the ABI output by the compiler changes | 23:10 |
| infinity | slangasek: You do when the library does things against spec that intentionally break its ABI, but yes, point taken. | 23:10 |
| doko | slangasek, so is there anybody available from the phone team who can tell what the failing test is supposed to test? | 23:17 |
| slangasek | doko: ricmm might be able to; but I know this was holding up a stalled landing, so he's been busy working around it on his side and may not be in a position to discuss it right now | 23:18 |
| infinity | slangasek: dbus-cpp is tvoss's baby, isn't it? Maybe he could shed some light on if it's doing something naughty with C++ that it shouldn't. | 23:39 |
| slangasek | infinity: in an appropriate timezone, probably | 23:39 |
| slangasek | in the meantime, I've reverted the default compiler to 4.8, so we're not under time pressure | 23:40 |
| infinity | You bumped the epoch instead of just mangling versions? Fun. | 23:41 |
| infinity | I guess that's easier than making gcc_4.8 depend on gcc-4.9 | 23:42 |
| infinity | Err, other way around. | 23:42 |
| doko | well, bumping the epoch should be a no-go | 23:43 |
| infinity | doko: It's already been done. | 23:43 |
| slangasek | doko: how does that follow? | 23:43 |
| slangasek | or rather: what would you expect to do in a revert if not an epoch? | 23:44 |
| doko | because any synced versioned deps will be meaningless in ubuntu from now on | 23:44 |
| cjwatson | the +really convention is less intrusive | 23:44 |
| cjwatson | less permanently intrusive I mean | 23:45 |
| doko | slangasek, just change the dependencies | 23:45 |
| cjwatson | do we have time to undo the epoch with archive hackery? that's kind of scary | 23:45 |
| slangasek | cjwatson: sure, but much more error-prone for a metapackage that munges the binary version numbers of each individual binary at build time | 23:45 |
| infinity | It's still in proposed, we could thwack it. | 23:45 |
| slangasek | doko: as the Debian maintainer, why would you not just bump the epoch in Debian too? | 23:46 |
| slangasek | it already has an epoch there | 23:46 |
| slangasek | it's not like revving the epoch would cost you anything | 23:46 |
| cjwatson | I've stopped p-m so that we have time to finish this discussion | 23:46 |
| slangasek | cjwatson: thanks | 23:46 |
| cjwatson | will block gcc-defaults now, this was just quicker | 23:46 |
| slangasek | fwiw I don't like the idea of either +really, or having a mismatch between the binary package version and the compiler version it depends on; I think the epoch is least-bad here | 23:47 |
| cjwatson | I don't object to the epoch if doko accepts it in Debian but I think that Ubuntu-specific epoch changes should be avoided at nearly all costs | 23:48 |
| infinity | slangasek: The epoch is least bad, long-term, but I assume this is only a day-or-two-long solution while we hunt the issue. | 23:48 |
| infinity | And for a couple of days, ugly version tricks seem to make more sense. But meh. | 23:48 |
| cjwatson | ok, gcc-defaults blocked, p-m unstopped | 23:48 |
| slangasek | infinity: again, error-prone | 23:48 |
| doko | I'll look at fixing the dependencies now | 23:49 |
| cjwatson | surely only "error-prone" in gcc-defaults' own build process, and that doesn't take long to check | 23:49 |
| slangasek | doko: ok, if you want to own this, I defer to you | 23:49 |
| slangasek | doko: though if you wanted to just agree to revving the epoch in Debian, you could go to sleep instead ;) | 23:50 |
| doko | I do not want to ... but it looks I'll have to if I do not want to bump the epoch | 23:50 |
| slangasek | why do you object to bumping the epoch? | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!