[03:53] any truth to roumers about a Ubuntu mate remix? [03:54] roumors [03:58] 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] I think there is some work happening on it though. [04:07] thanks very much cjwatson [04:08] we were thinking of a meta package for Vinux users who love the old Gnome2 feel but personally I like Unity === timrc is now known as timrc-afk [05:21] Good morning [05:22] Noskcaj: are iodbc and unixodbc now installable in parallel, or did Debian's psqlodbc now drop support for iodbc? [05:42] 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] doko_: that's the one that holds back the gcc-4.0 upload, FYI === smb` is now known as smb === alexlist` is now known as alexlist === doko_ is now known as doko [08:54] Hi [08:54] I was testing a wifi guide to enable the EOL repositories [08:55] apt-get update is working, but apt-get install no [08:56] doko: are you aware of gcc-doc bustage? [08:56] I get many 404 not found [08:56] *s [08:57] Investigating, I discovered that EOL repositories are not updated [08:58] I was suggested to open a bug report for these problems [09:00] Can you confirm this problem and explain how to open the report in my case? [09:00] 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] am I missing something to make it work? [09:02] for example, here I'm pretty sure I installed the correct version of rsyslogd-dbgsym, yet gdb doesn't find the source: [09:02] #3 0x00000000004319a6 in qqueueEnqObj (pThis=0x23d6d80, flowCtlType=eFLOWCTL_NO_DELAY, pUsr=) at queue.c:2400 [09:02] 2400 queue.c: No such file or directory. === liska is now known as human_resource [09:38] do we have a script that does "fetch all the debs from a ppa build"? [10:31] seb128, as in all debs for a single package? no idea if there is a script I just do it with apt pinning [10:32] 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] that's for local reviewing, not for installing [10:33] seb128, source or binary? [10:34] bdmurray: none of the issues listed on http://people.canonical.com/~ubuntu-archive/phased-updates.html against kde-workspace can be found [10:34] 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:35] oh [10:35] darkxst, binaries, I get dget the .dsc for source, but e.g the url I just copied a > 10 debs [10:35] darkxst, it's a bit annoying to click on them all and click download for each === Ursinha is now known as Ursinha-afk [10:36] seb128, pretty sure you could the urls in less than 10 lines of python, but I dont have a script === Ursinha-afk is now known as Ursinha [10:36] darkxst, right, I was just asking in case we had a standard script is some devtools collection [10:36] I'm going to write one myself otheriwse [10:36] just trying to avoid reinventing things [10:37] thanks for replying though ;-) [10:37] 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] mlankhorst: okay, in a short while [10:37] is this going upstream? [10:37] 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] eventually [10:38] need to review it some more first === rbasak_ is now known as rbasak [10:40] can anyone tell me what getprop "ro.product.cpu.abi" would return on a amd64 machine? [10:40] would it be also x86 [10:41] zbenjamin, only if you have an android running on your amd64 :) [10:41] (i doubt there are amd64 android builds) [10:42] ogra_: i see, it will still be a 32bit build hmmm [10:42] what are you trying to do ? [10:42] 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:43] for the using the emulator ? [10:45] (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] *inside [10:50] ogra_: for the target system [10:51] for that using getprop should be okayish [10:51] i could use uname i guess [10:51] yeah, that works for sure [10:51] ogra_: thx [10:51] and will even work once we have actual x86 tablets etc [10:51] * zbenjamin --> lunch [10:51] (that dont use an android container) [10:52] ogra_: yeah thats what i had in mind [10:52] bbl [10:52] note that it wont return debian arches that way though [10:53] phablet@ubuntu-phablet:~$ uname -m [10:53] armv7l === _salem is now known as salem_ === MacSlow is now known as MacSlow|lunch === salem_ is now known as _salem [11:44] zbenjamin: uname returns the kernel, not the userspace abi. Uname can be amd64, yet userspace i386. [11:44] zbenjamin: i think you want $ dpkg --print-architecture [11:45] zbenjamin: but thanks to qemu-user-static for example I can execute armhf, i386 and amd64 binaries on my amd64 machine. [11:46] ev: errors.ubuntu.com is not showing a graph =( [11:50] xnox: we just cut over to a new database. That will return ~tomorrow. [11:50] ev: =( ok. === 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 [13:32] xnox: what i need is the architecture/abi i have to use to compile apps for the device [13:33] zbenjamin: at the moment we have two: armhf (all devices + emulator) and i386 (emulator) [13:33] zbenjamin: adb shell dpkg --architecture, will tell you the architecture device is running. [13:34] --print-architecture that is [13:35] seb128: script> citrain in phablet-tools-citrain is sort of close [13:37] did that land already ? [13:37] Well, I have it from ppa:phablet-team/tools [13:37] oh, it is a separate package [13:38] yeah, i thought it was supposed to be merged into phablet-tools [13:38] it's in utopic though [13:38] (it did ... but only on source level ... produces its own binary) === olli_ is now known as olli [14:05] 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] and then a rule (with dependencies) gets executed, passing name.of.test.to.run as a command line argument [14:07] does declaring the non-file-based-target in .PHONY help? [14:15] cjwatson: nope - so perhaps I'm doing something entirely wrong here: http://paste.ubuntu.com/7628766/ === _salem is now known as salem_ [14:15] $@ ends up being the first file in the directory, Makefile [14:15] ev: have a variable with ?= [14:16] e.g. TESTS ?= $(wildcard *runfiles) [14:16] make TESTS=on-ythis-file-please [14:16] like regular make check [14:16] automake check [14:17] 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:18] but I'm already abusing make for this [14:19] its not an env variable its a make variable [14:19] indeed [14:20] Laney: ping? :P [14:20] not yet sorry === mbarnett` is now known as mbarnett [14:28] cjwatson: is there something like "click uninstall", or is that simply "sudo rm -r /opt/click.ubuntu.com/com.ubuntu.calculator/" ? [14:29] I found "unregister --all-users", but that's not the same === pete-woods-lunch is now known as pete-woods [14:30] pitti, adb shell click unregister --user=phablet $PACKAGE [14:31] pitti: unregister [14:31] 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] Don't just do rm -r, you'll leave bits behind [14:33] cjwatson, thanks [14:34] cjwatson: I tried that (with and without --all-users), it still leaves /opt/click.ubuntu.com/com.ubuntu.calculator/* behind [14:34] that just hides it [14:35] pitti: in general that depends whether the app is running [14:36] it should get GCed eventually; normally, don't worry about it [14:36] cjwatson: ah, ok; thanks! [14:36] --all-users likely isn't what you want unless it was registered with --all-users to start with [14:36] cjwatson: I don't know how it was registered; it's installed by default [14:38] 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] you don't [14:38] any user-installed version will override things installed by default [14:38] 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] so we don't try, we just hide it [14:39] but anyway the structure of the database makes that sort of care unnecessary [14:39] https://click.readthedocs.org/en/latest/databases.html FWIW [14:39] 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:40] cjwatson: thanks [14:40] look through /opt/click.ubuntu.com/.click/, there might be a @gcinuse thing somewhere [14:40] ah, 276 was in the image, 279 came as an app update [14:41] 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] stray versions are allowed to hang around a bit [15:00] doko: yes. will have a fix in a few minutes [15:15] xnox: thx [16:00] infinity: ping, re: juju-core powerpc ftbfs [16:16] 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] Sorry, I must have missed your reply. [16:17] I wanted Fix Released status in Utopic for an SRU to Trusty. But I guess having it in utopic-proposed is enough? [16:18] rbasak: Having it in proposed is enough. [16:18] 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:19] OK, thanks. I'll work on the SRU. [16:46] did we switch the compiler default to 4.9 already ? [16:46] 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] xnox: normally ahs3 uploads for me but he's swamped with real life [16:46] hallyn: sure. [16:46] xnox: thanks! [16:47] ogra_: lemme know if I missed the reply [16:48] hallyn: i need to sprint somewhere with you, to get keys cross-signed. [16:48] 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] xnox: hey, are we using 4.9 by default in u now? [16:48] or doko [16:50] ogra_: ricmm: i believe we use 4.9 by default from now on. Let me find out when that happened. [16:50] must have been very recent [16:51] ogra_: it's about a month late. [16:51] ricmm: older compilers are still available and you can choose to use an older one. [16:52] xnox: are you going to be at linuxcon chicago or plumbers dusseldorf? [16:52] ogra_: as off 2 hours ago. [16:52] hah ! [16:52] anyway come up with a pretext i love to sprint :) [16:52] ricmm, so that might be your prob :) [16:53] it is indeed [16:53] I just checked, the first failing build is using 4.9 [16:53] instead of 4.8 [16:53] boom headshot [16:53] I'm never landing my stuff [16:53] oh my [16:53] slangasek: ^ can i go to linuxcon chicago or plubmers dusseldorf? Or have a cloud vs core stand-off sprint =) [16:53] as he said you can Build-Depends: gcc-4.8 and set CC=gcc-4.8, or similar [16:54] right [16:54] 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] though clearly this is technical debt [16:54] xnox: ... to get keys cross-signed with hallyn? [16:54] ricmm: what's the build log? [16:54] cjwatson, just that this needs a change of the MP and means re-testing everything again [16:54] slangasek: yes. [16:54] ogra_: sure [16:54] xnox: this is a tough header-based thing with dbus-cpp [16:54] its not a build failure, its a runtime hashtable explosion [16:54] ricmm: that's fine, what's the build failure? =) [16:54] so maybe an ABI break somewhere [16:54] cjwatson, ricmm is only trying to land that since 4 weeks :P [16:54] xnox: try to be more circumspect about your motives [16:54] it was done today :) [16:54] ogra_: this isn't really a helpful line of argument ... [16:55] there is no argument, forget about it all [16:55] not a line of argument at all ... [16:55] ricmm: i believe dbus-cpp is compiled with 4.7, maybe we need to recompile dbus-cpp with 4.9 [16:55] just a comment [16:55] I'll have this thing work 4.8 and bye bye [16:55] dbus-cpp is 4.8 [16:55] probably will need a recompile yea [16:55] I'll figure it out dont worry [16:55] just wanted to know when the change had happened [16:55] to confirm [16:55] thanks [16:57] lol. xnox: slangasek ain't gonna go for that one :) [16:58] xnox: i bet we can come up with very good reasons. systemd.vs.cgmanager.vs.lxc comes to mind [16:58] which is very much inplay at both linuxcon and plumbers, in fact [16:59] 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] or something like that [17:01] mdeslaur: stgraber: (zul:) if no objections i'll push http://paste.ubuntu.com/7629496/ [17:02] hallyn: fine with me [17:02] 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] i'll try to look into it assuming you do not have time. [17:03] or, that's right, you were mentioning something new that may be easier to have ppl switch to? [17:03] hallyn: LGTM [17:03] thx, pushing [17:03] hallyn: I've done it, it's just that there are a zillion MIR bugs to file [17:03] mdeslaur: right, that's waht i meant [17:03] hallyn: give me a couple of days, and I'll take a look [17:03] although, [17:03] virt-manager isn't in main is it? [17:03] yeah, it is [17:04] egads [17:04] right [17:04] might be easier to demote it :P [17:04] ok - thanks, happy to wait :) [17:04] yes, [17:04] is it part of anything strategic that we ship? [17:04] i'm not sure anyone uses it on server anyway... [17:04] not that i know of [17:04] ok, I'll look into that possibility too [17:05] jamespage: smoser: ^ do you know if virt-manager needs to be in main for any particular reason? [17:05] the only thing rdepending on it is ubuntu-virt-mgmt :) which sounds like a bogus metapackage [17:06] 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:07] hallyn, i dont have a good reason off the top of my head [17:08] sarnold: simple tool like xterm -e "while :; do virsh list; sleep 5m; done" [17:08] :) [17:08] * sarnold hugs hallyn [17:08] lol [17:20] hallyn: you know about watch, right? "watch -n300 virsh list" [17:29] i do [17:30] but what can i say i like manually looping [17:33] You like doing what? :) [17:34] the man likes to control his own loops [17:34] he'd have used goto except shell makes that hard :) [17:35] ricmm, what exactly is the issue? didn't see a reply when xnox or ogra_ were asking [17:35] doko, dbus-cpp is compiled against 4.7 or 4.8 [17:35] that caused a bunch of build issues now [17:35] ogra_, and why is this an issue? [17:36] dunno ... they are working on porting it now ... [17:36] doko: no reply either. [17:36] (no worries, it was just the info that the default switched that was important ) [17:36] ricmm: can you please give us projects which need fixing? [17:37] ricmm: doko and I, are both from foundations team and we are ultimately responsible to get all packages fixed for 4.9. [17:38] xnox, silo 007 [17:39] rebuilding the location-service FTBFS due to dbus-test-runner timing out [17:40] xnox, doko, seems a simple rebuild of dbus-cpp fixes everything ... it was just that nobody was aware the default had changed [17:46] ogra_, xnox: it's suspicious that a simple rebuild fixes things ... [17:46] well, dbus-cpp is special :) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [18:50] dobey, thanks for the fix [18:50] no problem :) === roadmr is now known as roadmr_afk [19:15] 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] jcastro: and no running wget; any idea how I can check what's going on? [19:15] pitti, can you ping frankban on #juju-gui? Marco and I are in the middle of another session [19:15] jcastro: strace is just in an endless futex wait [19:15] jcastro: sure, thanks [19:38] tedg: !!!! [19:38] ? [19:38] tedg: oh, surprisingly it wasn't you this time =) [19:39] tedg: indicator-datetime adding a semi-bogus recommends =) [19:39] ? [19:39] bug 1309063 [19:39] 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:40] pulls in ubuntu-touch-sounds [19:40] into all instalations of indicator-datetime => everywhere [19:41] xnox, not sure that's a bad thing? how else would we ensure we had an alarm sound? [19:56] tedg: indicator-datetime does alarms on xubuntu & unity7 ?! [19:56] tedg: and it should fallback to the desktop sound theme -> thus get alarm sound from the theme [19:56] not a file on disk [19:57] xnox, I believe the issue there is that the mechanisms on the phone aren't theme aware. [19:57] xnox, And we will do alarms if someone uses that Ubuntu SDK to set them. [19:59] k, cool. [19:59] weird, i thought sounds came from the same themeing capability as icons. [20:00] and i thought we do have that in the sdk -> well, pure qt [20:01] xnox, It's similar, but just a matter of programming :-) === 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 [22:36] ricmm, doko: bug #1329089 filed [22:36] 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:37] ricmm, doko: I think I'm going to revert the gcc-defaults change, until we have a handle on the cause of this incompatibility [23:08] 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] slangasek: Is it possibly that dbus-cpp itself is just doing something Very Bad? [23:08] 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] so it's possible that this was a 4.8-specific ABI breakage [23:09] slangasek: Or possible that these components are somehow crazy. :P [23:10] 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] slangasek: You do when the library does things against spec that intentionally break its ABI, but yes, point taken. [23:17] slangasek, so is there anybody available from the phone team who can tell what the failing test is supposed to test? [23:18] 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:39] 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] infinity: in an appropriate timezone, probably [23:40] in the meantime, I've reverted the default compiler to 4.8, so we're not under time pressure [23:41] You bumped the epoch instead of just mangling versions? Fun. [23:42] I guess that's easier than making gcc_4.8 depend on gcc-4.9 [23:42] Err, other way around. [23:43] well, bumping the epoch should be a no-go [23:43] doko: It's already been done. [23:43] doko: how does that follow? [23:44] or rather: what would you expect to do in a revert if not an epoch? [23:44] because any synced versioned deps will be meaningless in ubuntu from now on [23:44] the +really convention is less intrusive [23:45] less permanently intrusive I mean [23:45] slangasek, just change the dependencies [23:45] do we have time to undo the epoch with archive hackery? that's kind of scary [23:45] 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] It's still in proposed, we could thwack it. [23:46] doko: as the Debian maintainer, why would you not just bump the epoch in Debian too? [23:46] it already has an epoch there [23:46] it's not like revving the epoch would cost you anything [23:46] I've stopped p-m so that we have time to finish this discussion [23:46] cjwatson: thanks [23:46] will block gcc-defaults now, this was just quicker [23:47] 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:48] 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] 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] And for a couple of days, ugly version tricks seem to make more sense. But meh. [23:48] ok, gcc-defaults blocked, p-m unstopped [23:48] infinity: again, error-prone [23:49] I'll look at fixing the dependencies now [23:49] surely only "error-prone" in gcc-defaults' own build process, and that doesn't take long to check [23:49] doko: ok, if you want to own this, I defer to you [23:50] doko: though if you wanted to just agree to revving the epoch in Debian, you could go to sleep instead ;) [23:50] I do not want to ... but it looks I'll have to if I do not want to bump the epoch [23:50] why do you object to bumping the epoch?