[00:42] xnox, doko, since you guys have touched it recently, I thought I would ask you... libboost seems to have a file, /usr/bin/quickbook... it moved from liboost-tools-dev to libboost-dev between liboost 1.53 and 1.54, which makes libboost1.54-dev have an undeclared conflicts with libboost1.53-tools-dev... why did this file move between binary packages? [00:45] quick question, is tahr fairly usable? [01:02] psusi: due to multiarch. [01:02] psusi: in trusty, we have boost 54 (default) and 55 (available in universe) and they should be all fine. [01:02] psusi: ditto conflicts / replaces. Where are you spotting 1.53 / 1.54 conflict? [01:02] psusi: also boost-dev packages are not co-installable per se.... [01:04] if boost-dev packages aren't co-installable, why offer both 54 and 55? [01:04] xnox, yea... I see they are set to conflict with each other but due to the change of package, 1.54 needs a Conflicts: libboost1.53-tools-dev... I saw someone asking about it on askubuntu, and there are a few upgrade failure bugs in launchpad [01:04] sarnold, in case you need the old one to build something.. it's there... you just have to remove the new one [01:07] i've no idea why you would need an older version though. AFAIK boost is great at backward source compat [01:24] It is better than it used to be. [01:50] so my gnome-terminal's transparency is not working, what should I check? [01:56] nvrpunk: use kde [01:56] * semiosis ducks [01:56] Use #ubuntu ? [01:57] nvrpunk: but seriously, as much as i love kde, this is probably teh wrong channel for that kind of question. [01:57] as Unit193 points out :) [01:57] it might be alright if it is busted in trusty... [01:57] truth [01:59] *Generally*, trusty would be in #ubuntu+1 though. [01:59] heh never seen that one before.. [02:00] im using Ubuntu Gnome Trusty Tahr [02:01] so how is this the wrong channel? [02:01] sarnold: why offer both -> because that's easier then black-listing from debian. [02:01] sarnold: and actualy libboost runtime library packages are co-installable. [02:02] xnox: that's a good answer :) hehe [02:02] I haven't looked enough at boost but I'm surprised there's much 'runtime library' [02:04] sarnold: a good chunk of boost are templates, but a whole-load of it are shared libraries that one links against. === TheMuso` is now known as TheMuso [02:13] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso [02:25] Unit193: Where can I find a tarball for https://code.launchpad.net/~unit193/xfce4-panel/snapshot/+merge/206173? [02:27] TheMuso: Right, sorry about that. https://launchpad.net/~unit193/+archive/staging/+sourcepub/3912036/+listing-archive-extra [02:27] Unit193: Thanks, please put a pointer to the tarball if its a snapshot in the merge proposal in future. [02:28] Sure, not used to bzr merges so wasn't really sure what to do there. [02:28] Understandable. [02:28] (FWIW, xfce4-indicator-plugin is there too.) [02:29] Unit193: Yeah, I saw it, I'm doing them together. [02:30] TheMuso: Just to be clear, that's preferred over dsc files? [02:31] Unit193: Yeah, thanks. === _salem is now known as salem_ === salem_ is now known as _salem [02:57] can I ping a maintainer or is it considered disrespect? === freeflying_away is now known as freeflying [02:58] I would like to discuss an idea on IRC before going any further, so I thought discussing here would be better than e-mails etc as it is all informal for now [03:17] Devastator: Pinging is generally fine. [03:19] RAOF do you know which approach Stéphane Graber likes? [03:20] If he's here I'm sure he'd be fine with a ping. stgraber? [03:21] his idle says almost 4:30 hours, so probably not :) [03:23] Devastator: Already been a couple pings, may as well ask now (in a highlight, and he may well see it. [03:24] Unit193 alright, thanks, I'm assuming pasting links which may be from debian is ok also?! [03:24] yes [03:24] thanks! [03:31] stgraber hi, I've seen that you are ubuntu's ifupdown maintainer and I want to add something that can be perhaps useful. Currently ifupdown exports IF_ environment variables to be used in if-pre-up.d, if-up.d, if-down.d and if-post-down.d, but it doesn't distinguish each parameter per interface, example: everytime one interface goes up it exports IF_ADDRESS, IF_NETMASK and others, what [03:31] I'm proposing is adding interface logical name to it, like IF_eth0_ADDRESS, IF_eth1_ADDRESS, IF_eth0_NETMASK, IF_eth1_NETMASK and so on as this could be useful for using in shellscripts for advanced configurations. I must say I'm not currently using ubuntu but I'm willing to try it if you think this can be added [03:32] Devastator: you were cut off at "others, what" in your first message [03:33] thanks [03:33] stgraber what I'm proposing is adding interface logical name to it, like IF_eth0_ADDRESS, IF_eth1_ADDRESS, IF_eth0_NETMASK, IF_eth1_NETMASK and so on as this could be useful for using in shellscripts for advanced configurations. I must say I'm not currently using ubuntu but I'm willing to try it if you think this can be added === maclin__ is now known as maclin [03:35] stgraber I give you a pastebin of what ifupdown exports currently: http://codepad.org/pksia5AW and here is the wishlist bug I posted in debian's BTS which contains the piece of code I tried to edit and failed miserably: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737749 [03:35] Debian bug 737749 in ifupdown "Add interface name to IF_ environment variable" [Wishlist,Open] [03:36] Devastator, that would make it _less_ usable... if you want to know what iface you are being run for that is what the IFACE variable is for [03:38] psusi yes, but how to check if IF_ADDRESS=1.2.3.4 is from IFACE=eth0 for example? [03:38] TheMuso: Thanks muchly! [03:41] Unit193: You're welcome, please keep in mind the pointers I made both on IRC, and in the comments for the indicator plugin. [03:41] Indeed. [03:42] also, if you guys don't mind me asking, are there plans to replace ifupdown altogether? === rww_ is now known as rww [03:48] psusi also, could you please explain why you think it would make less usable? === mwhudson is now known as zz_mwhudson [03:59] Devastator, with an if statement of course [03:59] Devastator, it would make it less usable because you couldn't write a script without knowing the name of the iface [04:00] psusi I'm not trying to replace IFACE with IF__ADDRESS etc, I want to keep IFACE [04:01] psusi did you take a look at the pastebin also? [04:01] psusi also, I'm not saying you are wrong, just trying to understand [04:03] if you possible, give me an example of the if [04:07] Devastator, if [ $IFACE = eth0] [04:09] psusi does it matter if $IFACE is exported after $IF_ADDRESS? [04:09] no [04:10] will do some tests [04:15] Devastator, generally speaking, the script shouldn't *care* what interface it is being used with [04:17] psusi I'm trying to come up with a multiwan failover solution without having to hardcode things, the if works, now I have to make some kind of array to store $IFACE from each interface, then get each $IF_ADDRESS, but I think it will work [04:20] Devastator, I think you're going about it all the wrong way.. I'm pretty sure those scripts aren't called when an interface fails... only when you manually ifdown [04:24] psusi I don't think I follow you, are you saying it's not a good idea to use if-up.d scripts? [04:40] psusi I really have to get some rest, can we continue this talk at perhaps.. 11:00 UTC?! my TZ is UTC-2 by the way [04:46] Devastator, yes, that is not a use case for if-up.d scripts === timrc is now known as timrc-afk [06:04] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === bfiller is now known as bfiller_afk [06:43] Good morning [06:45] mlankhorst: they auto-ran; yay, they all succeed now! https://jenkins.qa.ubuntu.com/view/Upgrade/? [06:45] mlankhorst: that is, ubuntu-precise-trusty-*-lts-* [07:14] good morning [07:16] pitti: Not to poo-poo you for fixing wine1.4, but I'd rather you just delete it === Guest25707 is now known as Lutin [07:16] YokoZar: ah, I wanted to ask you yesterday, but you weren't online [07:16] https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/1218645 [07:16] Launchpad bug 1218645 in wine1.4 (Ubuntu) "Migrate to wine1.6 and remove old wine things from archive" [Wishlist,Triaged] [07:17] YokoZar: I actually already uploaded it yesterday, but the upload somehow wasn't accepted [07:17] YokoZar: right, Debian has 1.6, I wondered whether we want to upgrade [07:17] We have 1.6 too [07:17] now [07:17] I wanted to upgrade 2 releases ago [07:17] YokoZar: I just got the FTBFS when I did the libgphoto transition, and then felt obliged to spend the two hours to fixing the build and finishing the transition [07:18] It never got into saucy due to being uploaded like 2 minutes after feature freeze [07:18] hm, I cant' see wine 1.6 in trusty [07:18] wait, what [07:19] not in https://launchpad.net/ubuntu/trusty/+queue?queue_state=0 either [07:19] wine1.6 | 1:1.6.1-0ubuntu4 | trusty-proposed/universe | source, amd64, i386 [07:19] ooh [07:19] they just didn't propagate yet [07:19] wine1.6/amd64 unsatisfiable Depends: wine1.6-i386 (= 1:1.6.1-0ubuntu4) [07:20] yeah, that looks wrong [07:20] oh right [07:21] I thought in the times of multi-arch we wouldn't need those -i386/-amd64 packages at all any more [07:21] didn't we have to do something manual for wine1.4 [07:21] you can just apt-get install wine and would get wine:i386 [07:21] The issue is that wine on amd64 needs BOTH the i386 and amd64 guys [07:21] and there's no way to do arch-specific depends [07:22] so instead you have to make a package that's only satisfiable as a foreign depends [07:22] ah, so wine: is arch: all, depends: wine-bin [07:22] and wine-bin is M-A: foreign? [07:22] Yeah [07:25] To be more specific, wine is a metapackage depending on wine1.6, which in turn depends on wine1.6-i386 or (both wine1.6-i386 and wine1.6-amd64) [07:26] and wine1.6 isn't arch-all but is defined for specific arches (cause the dependencies change based on the arch) [07:28] I seem to remember there being some sort of "ignore wine's unsatisfiable cross-arch depends" thing in the proposed migration for wine1.4. Or maybe it was just manually approved each time. [07:28] YokoZar: ah, indeed skype is similar; skype is amd64, depending on skype-bin which is i386 only and M-A: foreign [07:29] IIRC slangasek set that up, so I take that as "official reference to do it right" :) [07:29] Yup. I'm somewhat proud of it being so coherent (and Wine using just about every edge case of apt there is) [07:31] YokoZar: oh, and now the wine1.4 builds got rejected because they are older than the transitional ones in -proposed [07:32] so I guess that was in vain [07:32] hah, so I suppose you would have discovered wine1.6 that way :p [07:33] so, TBH I don't know why britney complains about it [07:33] infinity: do you have an idea about "wine1.6/amd64 unsatisfiable Depends: wine1.6-i386 (= 1:1.6.1-0ubuntu4)" in britney? [07:34] wine1.6-i386 is already M-A: foreign [07:34] pitti: Yeah, we need a fauxpkg setup for it. britney doesn't do cross-arch deps. [07:34] pitti: I'll sort it in the morning when I'm more awake. Or ask cjwatson, he knows what's up. [07:34] * pitti tries to make an halfway intelligent face about "fauxpkg" [07:35] pitti: See fauxpkg/FauxPackages in britney1 source. [07:36] YokoZar: Bug me about it in the morning if no one's fixed it before. I'm sleeping in about 3 minutes. [07:37] infinity: I just got a bug report against langpack-locales; do we actually build locales from eglibc now? eglibc has it in it's Binary: list, but our locales still comes from langpack-locales [07:37] infinity: (feel free to answer after you wake up again, not urgent at all) [07:40] pitti: infinity: thank you both [08:07] tkamppeter_: yay, thanks. === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === tkamppeter_ is now known as tkamppeter [09:35] pitti: not yet, xrandr needs a tes ttoo [09:35] test that ls /usr/bin/xrandr* == /usr/bin/xrandr [09:37] I forgot about that diversion [09:39] mlankhorst: would you mind describing that in https://bugs.launchpad.net/auto-upgrade-testing/+filebug ? [09:39] (hunting down two other failures ATM, brain stack is full) === doko_ is now known as doko [10:09] pitti: upload https://mblankhorst.nl/etc/xorg-lts-transitional_5.tar.gz and then https://bugs.launchpad.net/ubuntu/+source/x11-xserver-utils/+bug/1280155 should be fixed for the packages in ubuntu [10:09] Launchpad bug 1280155 in xorg-lts-transitional (Ubuntu) "test for /usr/bin/xrandr when upgrading from lts" [Undecided,New] [10:11] mlankhorst: uploaded, thanks! [10:19] hey, daily update left my system with this: [10:19] apt-get: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory [10:20] I didn't reboot but I cannot launch most things [10:20] doko: ^^ [10:20] help please :-) [10:21] ara: what a day ;) [10:21] zyga, what happened? [10:22] urhg, indeed [10:22] zyga, I see [10:22] ara: libgcc_s.so.1: cannot open shared object file [10:22] this just caused a gazillion autopkgtset failures, too [10:22] ara: don't upgrade for a moment [10:22] arghh, and it did migrate already ... [10:22] jibel: hm, given that this broke pretty much every autopkgtest, any idea why this wasn't held back? [10:22] ara: (earlier I had lots of kernel fc*ups, wired networking didn't work and other funny things) [10:22] an we delete the binaries before they get downloaded? [10:23] can* [10:23] oh, I guess they only started failing after the promotion of whatever caused that [10:23] zyga, quick fix: install the old libgcc1 [10:23] if you have it in the cache [10:24] doko, can you get #is to block the download of the buggy binaries? [10:24] I only have libgcc1_1%3a4.9-20140213-0ubuntu1_amd64.deb [10:24] hmm, gcc-4.8 was uploaded two days ago already [10:24] trying ... [10:24] * zyga checks if apt-cacher-ng has it [10:25] zyga: you can get older ones from https://launchpad.net/ubuntu/+source/gcc-4.8/ [10:25] why did that only just happen? [10:25] is that really libgcc1? [10:26] it must have been something which just propagated an hour or so ago [10:26] pitti: I may have it in apt-cacher-ng [10:26] yeah [10:26] pitti: now built from gccgo-4.9 [10:26] ah [10:26] but empty package. messed up the testing [10:26] and gccgo-4.9 doesn't trigger any autopkgtests, so it wasn't caught by those until after it promoted [10:27] ok, that at least explains the mysteries [10:27] doko: i. e. is it meant to build from gccgo-4.9, or was that an oversight? In the latter case, we'd need a version downgrade, i. e. update gcc-4.8 to 4.9+really4.8.. or so? [10:28] pitti, it is meant to [10:28] doko: ok, that at least simplifies the versioning problem [10:28] but the quick fix is to download the previous version and just dpkg -i it [10:29] wget http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-4.8/libgcc1_4.8.2-15ubuntu3_amd64.deb [10:29] sudo dpkg -i libgcc1_4.8.2-15ubuntu3_amd64.deb [10:29] zyga: ^ [10:29] ok, thank god I had apt-cacher-ng with the older copy :) [10:29] already fixed, I also installed the i386 version for parity [10:30] hmmmmmmm [10:30] the teutonic mirror is behind by half a day or so, seems that rescued me [10:30] I ended up with /var/lib/spamassassin being root:root rather than debian-spamd:debian-spamd [10:30] And of course this means all trusty builds are failing too [10:30] which broke my upgrade due to the new sa-compile thingy [10:31] does anybody else have it with these permissions? [10:31] /usr/bin/apt-cache exit status 32512 [10:32] i. e. including the upcoming gccgo4.9 fix, yay [10:32] We can probably work around that with the bootstrap archive somehow [10:32] cjwatson: could we temporarily disable the dist-upgrade of the build chroots for that? [10:33] I take it the chroots are usually a few days or even weeks old [10:33] can we get the binaries blocked from download on the server? [10:33] save users and the chroots :p [10:33] oh, cjwatson just pinged #is a bit more, thanks [10:34] pitti: it's easier to prod it in the bootstrap archive; fiddling with the build chroots will require infinity to wake up [10:34] ack [10:35] doko, around? [10:35] tvoss: not now, please : ) [10:35] tvoss: trusty is on fire, nobody disturb doko for a while [10:35] pitti, ack [10:35] was I the first person affected that came here/ [10:36] I don't understand why autopkgtest didn't save us from this [10:36] I: [Fri Feb 14 09:42:55 2014] - Requested autopkgtest for apt_0.9.15.2ubuntu1 (NEW gccgo-4.9 1:4.9-20140213-0ubuntu1) [10:36] [lots of more things along the same lines] [10:36] final: gccgo-4.9,ubuntu-keyboard [10:36] cjwatson: yeah, we got a bazillion failures [10:36] cjwatson: this is like backup, the first time we know the backup failed, the second time we check if backups can also restore [10:36] zyga: please can I not have the smart commentary just now? :) [10:36] cjwatson: sorry [10:36] * zyga goes away [10:37] cjwatson: gccgo4.9 doesn't have direct rdepends that have autopkgtests apparently, but it should have caught the libgcc1 binary for sure [10:37] jibel: could you have a look at why adt-britney apparently said everything was just fine when we'd just triggered a load of autopkgtests for gccgo-4.9 and they hadn't come back yet? [10:37] pitti: the above log entry shows that it definitely felt it necessary to trigger them [10:37] cjwatson: ok [10:38] yeah, I noticed that several times, britney waving through uploads before tests finished [10:38] cjwatson, looking [10:41] I'm going to disable the publisher while I figure this out; don't tell anyone but I think I might be able to manage to wind this back as an emergency measure [10:46] 10:45 doko: so, I'm going to remove gccgo-4.9 from trusty, copy gcc-4.8 back over it (which should be permitted, and should restore libgcc1), rerun the publisher, then hopefully we can build the new gccgo-4.9 [10:46] oops, echan, but never mind [10:51] Downloads should be disabled where possible === _salem is now known as salem_ === MacSlow is now known as MacSlow|lunch [12:22] pitti: I think you can retry those autopkgtest failures now [12:30] cjwatson: thanks; our internal mirror (tachash) still gives the bad deb, I asked in #ci a while ago about purging it [12:30] it should be sufficient to just sync it now [12:30] current indices have libgcc 4.8.mumble instead [12:30] I'll just try [12:33] yay, works now [12:33] * pitti gives our machines something to chew on then [12:34] doko, cjwatson: many thanks for your swift handling of this! [12:34] I'm going to do an automated search for affected failed builds [12:34] (once I write it) [12:38] pitti, autopkgtest in the lab use ftpmaster and should have the right deb [12:40] OK, walking through all recent builder history now searching for "/usr/bin/apt-cache exit status", will take a while [12:41] of course chances of getting answers quickly out of wildcherry right now ... [12:41] wgrant: I guess the POST rule applies with the API too? so my first retry() -> everything after on wildcherry [12:41] cjwatson: All API requests go straight to the master [12:42] ah ok [12:42] But the API is mostly performing OK at the moment. [12:43] cjwatson: i was reading in the ML and the link you gave me. But where can i find details on where i put the different binaries for the different archs? like the armhf binaries, the x86 binaries and so on [12:47] zbenjamin: that's not up to click [12:48] zbenjamin: it's for the SDK and tools such as upstart-app-launch to define how packages are laid out internally [12:48] zbenjamin: tedg might be able to advise on current standards [12:48] cjwatson: thx i'll ask him [12:50] cjwatson, what I found so far, gccgo triggered an autopkgtest for 54 packages, status has been set to running for these packages and collected by britney but gccgo has not been removed from upgrade_me, it passed the upgrade test and has been copied. What is unclear yet is why gccgo has not been removed while tests of dependant packages were running. [12:58] jibel: hopefully that much will clear out soonish, a fixed gccgo-4.9 is building [12:58] oh, but you mean for why it didn't block initially [12:59] cjwatson, yes, for why it didn't block initially, I'm in britney.py [13:03] jibel: beer o'clock! [13:03] http://d-jenkins.ubuntu-ci:8080/view/Upgrade/ [13:03] ugh, at least the wrestling this week was useful :) [13:05] pitti, 38 profiles, all green \o/ time to add more tests [13:05] pitti, hum, are you sure you want to hand beer to jibel while he's working on britney.py? ;-) [13:06] seb128: I'll buy him one next week [13:06] I pestered him all week with questions about how stuff works [13:06] oh, you guys have a team gathering coming [13:06] enjoy it! [13:06] yeah, Oakland, will fly out tomorrow [13:06] seb128: merci ! [13:07] jibel: more tests> for sure, but nice to have a stable base line now [13:09] more Oakland, lucky pitti ;-) === timrc-afk is now known as timrc [13:16] jibel: hopefully you're about to get it again; accepted the fixed gccgo-4.9 [13:17] though armhf is still building so maybe it'll block anyway === zyga__ is now known as zyga-sick [13:37] All libgcc-affected failed builds retried, I believe === MacSlow|lunch is now known as MacSlow === PeterSchwaller_ is now known as PeterSchwaller === Sweetsha1k is now known as Sweetshark [14:25] doko: hello, to build checkbox-gui for ubuntu we're a bit blocked by two dependencies waiting to be promoted to the main archive: bug 1277408 and bug 1278822, could you please help us? [14:25] bug 1277408 in checkbox-ng (Ubuntu) "[MIR] checkbox-ng" [Undecided,Fix committed] https://launchpad.net/bugs/1277408 [14:25] bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [Undecided,Fix committed] https://launchpad.net/bugs/1278822 [14:26] spineau, not yet seen in http://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:27] doko: I think it's because we're still in -proposed [14:27] roadmr: ^ [14:27] http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:30] spineau, doko: I see, I fixed the stuff that was keeping checkbox in proposed (dep-wait) so it should make it out, will it appear in component-mismatches once this happens? [14:30] roadmr, yes, it should [14:31] spineau, doko: OK then, upload coming up in a second [14:31] roadmr: doko: perfect, thanks === bfiller_afk is now known as bfiller === ara is now known as Guest55777 === WebbyIT is now known as rpadovani === freeflying is now known as freeflying_away [15:03] ev: ping === tyhicks` is now known as tyhicks [15:34] pitti: can Kubuntu also utilize https://jenkins.qa.ubuntu.com/view/Upgrade/ ? [15:39] shadeslayer: yes, I don't see why not [15:41] yay :) [15:41] pitti: I'll have a look at how to write a test case and send MR's [15:42] shadeslayer: it's primarily about defining a new scenario [15:43] shadeslayer: i. e. something like s/ubuntu-desktop/kubuntu-desktop/ and enabling universe [15:43] I see [15:43] stgraber: Have you seen this? https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1280050 [15:43] Launchpad bug 1280050 in samba (Ubuntu) "libsmbd_base.so.0 missing symlink?" [Undecided,New] [15:43] shadeslayer: the scenarios in lp:auto-upgrade-testing are outdated, we are actually using a branch from jibel, hang on [15:43] pitti: I think there are 2 upgrade paths we want to check : regular 13.10 to 14.04 and 13.10 + LTS Stack + Kubuntu backports to 14.04 [15:45] jpds: nope, I haven't. Though to be faire, I'm not maintaining samba, I only patched the few bits I needed to get my use case covered (AD domain controller) :) [15:45] Ah, right. [15:45] jpds: I believe the server team are the ones actually maintaining our delta, anything else should probably go straight to Debian [15:46] infinity: do you think it appropriate/could you sync cyrus-sasl2, please? Looks like a host of bugs have been fixed recently there. It's not in testing yet though. [15:46] (and it's a new upstream release, too, which looks minor, but the changelog suggests that it isn't) [15:47] shadeslayer, I think I've already a profile for Kubuntu 13.10->14.04. [15:47] shadeslayer, What is 13.10 + LTS stack? [15:47] shadeslayer: this one: https://code.launchpad.net/~jibel/+junk/auto-upgrade-testing_profiles [15:48] shadeslayer: I think the 12.04+LTS stack scenarios are already well-handled; is there anything Kubuntu specific in them? [15:48] jibel: whoops, I meant 12.04 + HWE [15:48] oh yes, http://bazaar.launchpad.net/~jibel/+junk/auto-upgrade-testing_profiles/files/head:/kubuntu/ [15:48] stgraber good afternoon (or probably evening), did you happen to see the message I leave here? [15:48] pitti: well, we backport KDE releases to our PPA, and alot of users add that ppa [15:48] so I think it's useful to have that tested [15:51] ah, yes [15:52] shadeslayer, ah okay as pitti said LTS+HWE is already covered, we could do 12.04 + Kubuntu backport [15:52] sure, fine with me [15:53] tedg: ping [15:54] zbenjamin, Howdy [15:54] hey [15:54] tedg: i got pointed to you by jdstrand i think, because i was asking about how a fat click package should look like internally and how it will work with the desktop files EXEC property [15:55] i'm working on the qtcreator ubuntu plugin and we would like to integrate fat packaging :) [15:55] zbenjamin, Yup, so what we're doing is adding an arch dependent directory to the path. So that way you can put an executable name in the Exec line and it'll find the arch dependent one. [15:56] tedg: ok but do i need a own desktop file per architecture in the package then? [15:57] zbenjamin, Nope, so the desktop file can have "Exec=foo-bar" and the package would have a $(dir)/lib/$(arch)/bin/foo-bar for each arch. [15:57] Devastatr: I did. I'm not necessarily against extending the script environment though I'm not going to diverge from Debian either, so if Andrew (the Debian maintainer) does those changes, I'll include them in Ubuntu but I don't want Ubuntu to suddenly become incompatible with Debian for those scripts. [15:57] tedg: ok and the path will be set correctly so it will be found [15:58] zbenjamin, Yup, for some examples there are the exec-test* file in the tests directory here: http://bazaar.launchpad.net/~indicator-applet-developers/upstart-app-launch/trunk.14.04/files/head:/tests/ [15:59] tedg: and for things like : Exec=qmlscene $@ -I ./lib/arm-linux-gnueabihf/qt5/qml share/qml/cmake1/cmake1.qml [16:00] stgraber I understand that and I agree, when you have some time, can you ping me? I want to discuss if I wanted to design something to replace ifupdown, together with you and Andrew, where to start [16:00] zbenjamin, We're also setting the QML2_IMPORT_PATH to be $(dir)/lib/$(arch) [16:02] tedg: do you have any docs on which directories have to be where? [16:02] zbenjamin, Uhm, not really. Not really sure where that belongs. [16:03] tedg: ok so lets recap, i put a arch into the manifest , lets say armhf, then click wants to have executables in APP_DIR/bin/armhf and libs in APP_DIR/lib/armhf [16:04] or is it arm-linux-gnueabihf [16:04] zbenjamin, It's the triplet, and not /bin, but /lib/$arch/bin [16:05] tedg: or maybe you could point me to the code that sets up the env [16:08] zbenjamin, Sure, I'm not sure that's as helpful as the tests are though. http://bazaar.launchpad.net/~indicator-applet-developers/upstart-app-launch/trunk.14.04/view/head:/exec-line-exec.c#L62 [16:10] tedg: thanks , if i have more questions i'll come back to you :) [16:14] zbenjamin, No problem, good to see this getting into the plugin! [16:16] tedg: yeah, we have a _lot_ of things to get in there ;) [16:18] zbenjamin, BTW, are you guys also adding support for custom URLs (or is that on the TODO list)? [16:18] custom urls? that i don't know about, bzoltan is my mentor so he should know more [16:22] bdmurray: hi, so regarding bug 1228977. I was waiting for sdague to post a test case so I could do the SRU justification [16:22] bug 1228977 in libvirt (Ubuntu Saucy) "n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive" [High,Triaged] https://launchpad.net/bugs/1228977 [16:23] bdmurray: however, the candidate package I pushed is broader, taking the whole upstream "-stable" series for that libvirt version. I wasn't sure if that should be handled specially [16:24] (it took some time to reconsile the upstream patchset with the individually-applied CVE patches in our tree) [16:24] normally, I would say that if the bug submitter can't be bothered to give a test reproduction s cript, let's just drop the patch and close the bug, but [16:25] since this is a whole -stable patchset I'd prefer to test for new regressions and call it good [16:32] hallyn: I hadn't actually looked at the diff yesterday, just the bug. [16:38] bdmurray: if my reasoning about the -stable patchset is legitimate i can put that in teh bug comment. otherwise, i'll ping the bug submitter oen more time for a test case, and we can drop teh set and close the bug next week if we dont' get it [16:39] using the -stable patchset seems more like a micro release to me than a standard SRU [16:46] bdmurray: if saucy was going to be around longer i'd pursue that. unfortunately there is an upstream libvirt -stable tree for saucy, but not (other than the one i maintain :) for precise === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [17:03] shadeslayer: pong [17:04] ev: Kubuntu has started reporting crashes to errors.ubuntu.com but our backtraces usually end in KCrash ( the KDE Crash handling framework ) , would daisy interpret the crashes as crashes in KCrash or will it be able to parse the stack correctly? ( see ref : https://trello.com/c/u9KpFFxF ) [17:08] shadeslayer: what do you mean by "our backtraces usually end in KCrash"? [17:09] oh [17:09] ev: KDE Software :) [17:09] shadeslayer: that's pretty easy to test. Just kill -SEGV a KDE process and see what's in the executablepath and package fields [17:09] in the resulting crash report [17:10] ev: but my question is whether daisy will interpret all crashes as crashes in KCrash? [17:10] shadeslayer: right, and I'm saying the way to find out is by looking at the resulting crash report after killing a process with sigsegv [17:12] ev: and what am I looking for? [17:12] shadeslayer: the Package field and the ExecutablePath field [17:14] ev: grep doesn't say anything [17:14] Bunch of jumbled text [17:14] shadeslayer: can you pastebin the resulting .crash file? [17:14] sure [17:15] ev: http://paste.ubuntu.com/6932266/ [17:16] ev: really really large file :P [17:17] shadeslayer: looks right to me: ExecutablePath: /usr/bin/kate [17:17] shadeslayer: you do have Package and ExecutablePath in there [17:17] you wont get Package until you actually run apport-kde over it [17:17] err so you do :) [17:17] ev: Laney yeah it's weird, grep didn't return anything [17:19] * Laney suspects PEBCAK :P [17:19] http://paste.ubuntu.com/6932302/ [17:20] ev: anyway, so it'll be fine even though backtrace has KCrash in it? [17:22] shadeslayer: ja [17:22] cool :) === zyga-sic1 is now known as zyga-sick [19:58] Hy, I've tryed to install trusty using the latest daily-live image dd-d over an usb key but it refuses to boot :( [20:10] is anyone here? [20:11] a few hundred :) normally IRC works best if you've got something concrete.. an error message or something similar [20:12] sorry I have only the fact that my bios immediatelly returns to the device selection mennu when I select the pendriver and hit enter :/ [20:12] I've tried to dd the iso on the dirst (active) partition and also on the entire device without success [20:13] also I can't found the unity alpha2 iso image, there are the images for every other flavor but not for ubuntu-desktop [20:14] main ubuntu doesn't do actual alpha releases any more [20:14] the daily image should be what you use [20:15] so I should try it with an older daily image? [20:15] maybe, i don't know [20:15] "refuses to boot" doesn't really say anything about what's wrong [20:15] you do have to dd to the main device, not a partition [20:16] "dd if=foo.iso of=/dev/sdg bs=4096" for example [20:16] tried that way also, but got only a blank screen [20:16] my bios has uefi support and it can't be disabled [20:17] i can't really help beyond that info though. sorry [20:17] okay, thanks anyway [20:18] fwiw though, #ubuntu is the help channel, so you might have better luck asking in there [20:18] I'll try with the 11th image maybe it will work [20:19] kenvandine, mardy: are there docs about what mechanisms/options can be used with the generic_oauth plug-in, when creating a provider file? [20:19] well I thought this is the right channel for asking about an alpha release :) then I'l try asking there also if it won't boot with the other image [20:24] dobey, not that i've seen [20:24] Hi, where can I find a kernel that will work with this: cdimage.ubuntu.com/ubuntu-core/daily/current/trusty-core-arm64.tar.gz? [20:24] kenvandine: do you know if PLAINTEXT is a valid mechanism? [20:25] I looked around in ports.ubuntu.com, but could'nt find anything for arm64 [20:29] ah, i guess it is [20:32] dobey, sorry, don't know [20:34] ok [20:37] Is there anything i can do to speed up bug 1272123 [20:37] bug 1272123 in Precise Backports "Please backport gtk2-engines-xfce 3.0.0-1 (universe) from quantal" [Undecided,New] https://launchpad.net/bugs/1272123 [20:42] well, definitely something's wrong with the uefi boot ot the daily images.. it boots into a black screen when selecting the pendrive from the boot menu, but it boots properly when selecting the pendrive as the first boot device from the bios setup [20:43] anyway it's installing now [20:48]