| === Ursinha-afk is now known as Ursinha | ||
| === doko_ is now known as doko | ||
| Laney | NBS needs to be resolved before migration now, right? | 09:24 |
|---|---|---|
| xnox | Laney: yeah. | 10:25 |
| Laney | xnox: do you have access to the arm64 porter machine? | 10:28 |
| Laney | (unrelated) | 10:28 |
| xnox | Laney: i don't believe i have any arm64 access. And I thought there are no porters available. So far I have been cross-compiling or using qemu-static from a ppa. | 10:31 |
| Laney | ok | 10:33 |
| Laney | webkit is making me sad | 10:33 |
| xnox | you are not the first one =) | 10:35 |
| === Ursinha-afk is now known as Ursinha | ||
| sil2100 | Hi everyone! There is a zmqpp source package in the NEW queue that would need pushing further - can anyone take care of that? | 11:53 |
| seb128 | sil2100, looking | 12:08 |
| sil2100 | seb128: thanks :) | 12:08 |
| sil2100 | seb128: the packaging is not super perfect, there is a dep that would be good if it would be added, but I intend to fix it in the next upload | 12:09 |
| xnox | are ":native" build-dependencies supported now? or is there a tracking bug about that? | 13:17 |
| cjwatson | Should work | 13:23 |
| cjwatson | I believe it should even work in Debian too | 13:23 |
| xnox | excellent! | 13:28 |
| xnox | I now only see bug 1252728 when trying to set up a fresh trusty chroot | 13:29 |
| ubot2 | Launchpad bug 1252728 in gcc-4.8 (Ubuntu) "crossbuild-essential-armhf is not installable" [Undecided,New] https://launchpad.net/bugs/1252728 | 13:29 |
| cjwatson | You didn't try the usual things to get apt to give you more useful information? | 13:30 |
| xnox | cjwatson: i've tried installing more sensible packages, and it gave up on trying to install gcc:armhf. | 13:36 |
| xnox | let me get more debug/verbose output out of it. | 13:36 |
| cjwatson | You don't need special verbosity options; just repeatedly add the packages it complains about to the apt-get install line until it gives you a more useful error. | 13:37 |
| cjwatson | gcc-4.8-base : Breaks: gcc-4.8-base:armhf (!= 4.8.2-5ubuntu3) but 4.8.2-5ubuntu2 is to be installed | 13:39 |
| cjwatson | Which probably just means multiarch desync in a chroot containing -proposed. | 13:39 |
| xnox | ah. right. i guess i didn't go far enough then. | 13:39 |
| cjwatson | -> not really a bug, just wait for gcc-4.8:armhf to finish publishing | 13:39 |
| cjwatson | Which it should do on the next publisher run | 13:39 |
| cjwatson | FWIW this was the command that gave me the real error: | 13:40 |
| cjwatson | apt-get install libc6-dev:armhf libc6:armhf libgcc1:armhf gcc-4.8-base:armhf libc6 | 13:40 |
| cjwatson | (No doubt one can reduce that) | 13:40 |
| xnox | i didn't have gcc-4.8-base:armhf, but i did try the others. | 13:40 |
| cjwatson | libgcc1:armhf libgcc1 shows it too | 13:41 |
| xnox | that's what i got to, but failed to parse it as "wait for gcc-4.8:armhf to publish" libgcc1:armhf : Depends: gcc-4.8-base:armhf (= 4.8.2-5ubuntu2) but it is not going to be installed | 13:42 |
| * xnox ponders if mk-sbuild should default to setting up cross-builders without -proposed. | 13:42 | |
| cjwatson | It at least has an option for it | 13:44 |
| xnox | then again native amd64 & _all packages from i386 can be out of sync the same way. cross just has longer window. | 13:45 |
| cjwatson | Indeed | 13:45 |
| cjwatson | Oh good, my cdimage fix yesterday for old series in current/ worked. | 13:52 |
| === LordOfTime is now known as TheLordOfTime | ||
| === bdrung_ is now known as bdrung | ||
| === adam_g is now known as adam_g_afk | ||
| === jamespag` is now known as jamespage | ||
| === cyphermox_ is now known as cyphermox | ||
| === pgraner` is now known as pgraner | ||
| === kees_ is now known as kees | ||
| === SpamapS_ is now known as SpamapS | ||
| sil2100 | seb128: do you know by any chance why all the builds of zmqpp are still pending publication after such a long while? https://launchpad.net/ubuntu/+source/zmqpp | 17:37 |
| seb128 | sil2100, they are in NEW (note the (New) on that launchpad page), let me review those | 17:38 |
| Laney | they're in binary NEW | 17:38 |
| sil2100 | seb128: ah, but I think you moved them today from the NEW queue? | 17:38 |
| seb128 | sil2100, source NEW, not binary NEW | 17:38 |
| rtg | infinity, any thoughts on this ? https://bugs.launchpad.net/ubuntu/+source/linux-goldfish/+bug/1236444/comments/5 | 17:39 |
| ubot2 | Launchpad bug 1236444 in linux-goldfish (Ubuntu Saucy) "kernel panic" [Undecided,Fix released] | 17:39 |
| seb128 | sil2100, binNEWed | 17:40 |
| infinity | rtg: gcc-4.6 is still in trusty, no dragging required. | 17:41 |
| rtg | infinity, huh, thought I looked. | 17:41 |
| infinity | rtg: doko really would like to drop it (as would I), but it hasn't been dropped yet. | 17:41 |
| infinity | gcc-4.6 | 4.6.4-3ubuntu1 | trusty/universe | source, amd64, armhf, i386, powerpc | 17:42 |
| rtg | infinity, doh! | 17:42 |
| xnox | rtg: armhf-cross is not, and i've pinged doko about re-introducing it. | 17:42 |
| xnox | (for 4.6 that is) | 17:42 |
| rtg | xnox, yeah, the cross compiler would be nice | 17:42 |
| rtg | xnox, I'll respin goldfish with the old compiler | 17:42 |
| infinity | 4.6 cross hasn't existed since quantal. | 17:43 |
| sil2100 | \o/ | 17:43 |
| sil2100 | seb128: thanks again! | 17:43 |
| seb128 | sil2100, yw! | 17:43 |
| rtg | infinity, yeah, I've been using chroots to cross compile | 17:43 |
| infinity | rtg: I don't suppose anyone's put any effort into figuring out WHY 3.4 kernels blow up with newer compilers? :/ | 17:44 |
| infinity | rtg: Maintaining a ton of toolchains just for this is really icky. | 17:45 |
| xnox | infinity: it was removed in raring. with a comment "i've asked linaro guy who doesn't work anymore for us, we don't need it" apart from like compiling all but one ubuntu-touch kernels. | 17:46 |
| rtg | infinity, none of the Nexi work with newer gcc AFAIK, though I have been building recent armhf kernels with the current toolchain. | 17:46 |
| infinity | rtg: Sure, all the new master/mainline kernels should work fine with 4.8, I assume it's 3.4 (and older) kernels that break, not ARM-specific at all. | 17:47 |
| xnox | rtg: thank's for respining goldfish, it did fail to boot when compiled with 4.6. I am guesing you get the email comment I posted on the bug report? =) | 17:47 |
| infinity | rtg: But I'm just curious WHY. | 17:47 |
| infinity | xnox: I assume you mean it failed to boot when compiled with *4.8*, not 4.6... | 17:47 |
| xnox | infinity: yeah typo. | 17:47 |
| rtg | xnox, yeah, 4.8 right ? | 17:47 |
| xnox | rtg: yes 1.8 from ppa compiled with 4.8 fails to boot. | 17:47 |
| infinity | (Have we tested 4.7?) | 17:48 |
| rtg | infinity, I'm curious WHY myself, but have precious little time to go figure it out. | 17:48 |
| xnox | infinity: in the past we have. see history on the goldfish kernel bug report "kernel panic" | 17:48 |
| infinity | rtg: Yeah, I think we're all in the ENOTIME boat. | 17:48 |
| infinity | xnox: The history is pretty sparse, and doesn't mention 4.7 at all, to be fair. | 17:49 |
| xnox | infinity: it generates kernel panics when compiled with newer toolchains. and android-open-source-project is using 4.6 still. I'm guessing sucky drivers / closed-sourced drivers. | 17:49 |
| xnox | infinity: right, i think 4.7 was done off the kernel-ppa build / on irc. | 17:49 |
| * infinity nods. | 17:49 | |
| infinity | Well, at least the kernels are in universe, so we don't need to *support* 4.6... | 17:50 |
| infinity | But we still need to sort of support it, which sucks. | 17:50 |
| rtg | infinity, I probably chose 4.6 because goldfish is the same kernel version as some of the other Nexi kernels (and they workwith -4.6). | 17:50 |
| infinity | rtg: Yeah, I assume all 3.4 kernels suffer the same issue. | 17:51 |
| rtg | likely | 17:51 |
| infinity | Trawling git logs to find the fix(es) would probably be painful. | 17:51 |
| === debfx_ is now known as debfx | ||
| rtg | xnox, linux-goldfish is pending publication in Trusty https://launchpad.net/~canonical-kernel-team/+archive/ppa | 18:59 |
| xnox | rtg: \o/ | 18:59 |
| rtg | xnox, prolly wanna make sure armhf boots before you pocket copy it (though it ought to work) | 19:01 |
| xnox | rtg: right =) will -meta need an upload as well, or will it "just work" ? =) | 19:02 |
| rtg | xnox, no ABI bump, so all should just work | 19:02 |
| rsalveti | xnox: what are the changes? | 19:04 |
| rsalveti | oh, just a revert, ok | 19:05 |
| xnox | rsalveti: actual change enable GPT disk partitions on armhf, it used to only be enabled on i386. | 19:07 |
| xnox | rsalveti: and experiment compiling with 4.8, instead of 4.6 didn't work. | 19:07 |
| rsalveti | right | 19:09 |
| infinity | xnox: I'll do the pocket copy if you verify it's not broken. | 19:23 |
| xnox | infinity: well it boots. please copy. | 19:36 |
| infinity | Done. | 19:37 |
| xnox | cool. | 19:37 |
| robru | xnox, please ping me when boost is ready | 20:41 |
| xnox | robru: well it's uploaded awhile ago, it should build & migrate by itself, whenever it does. | 20:43 |
| xnox | robru: i'm not sure why i should be pinging you. | 20:43 |
| robru | xnox, well i need to know when it's ready so i can get on with building things that depend on it. | 20:44 |
| xnox | robru: i'm not sure that's the case, boost1.54 all binary packages are available everywhere (from saucy, to trusty, to trusty-proposed). | 20:44 |
| xnox | robru: there is no api/abi migrations. and it's only -mpi-source package that has that tight dependency on boost1.54 package version. | 20:45 |
| xnox | robru: with or without -mpi-source upload, you shouldn't be blocked. | 20:45 |
| robru | xnox, this buildlog suggests otherwise: https://launchpadlibrarian.net/156938010/buildlog_ubuntu-trusty-amd64.unity-system-compositor_0.0.1%2B14.04.20131119.1-0ubuntu1_FAILEDTOBUILD.txt.gz | 20:46 |
| xnox | robru: it obsoletely must not build-depend on libboost-all-dev, that pulls in universe dependenices which will never be in main. | 20:47 |
| cjwatson | hah, yes, I didn't catch that earlier | 20:47 |
| robru | xnox, file a bug against lp:unity-system-compositor then. i don't know anything about that stuff, it's just my job to build it | 20:47 |
| xnox | robru: please build-depend on individual boost-COMPONENT-dev packages, and you would have completely avoided this waiting. | 20:47 |
| robru | xnox, I didn't create the packaging for this. | 20:48 |
| xnox | robru: right, i'll talk to C-I people to add validation to reject any packages that build-depend on libboost-all-dev, that's completely a no-go. | 20:48 |
| robru | xnox, hah, alright | 20:48 |
| robru | kenvandine, ^^ you reading this? | 20:49 |
| xnox | robru: this also not the first time this came up. | 20:50 |
| robru | xnox, first time it's bit me | 20:51 |
| robru | xnox, is there an easy way for me to determine what parts of boost i need to depend on? i'm completely unfamiliar with the package or how they're using boost | 20:51 |
| robru | xnox, completely unfamiliar with the components of boost, too, for that matter. | 20:51 |
| xnox | robru: look at resulting binary package it will depend on libboost-serialisation-1.54.0, then you need libboost-serialisation-dev. | 20:52 |
| infinity | I'd hope the people who wrote the software know what bits they need. | 20:52 |
| infinity | But yes, the "build it with all-dev and check linkage" thing works. | 20:52 |
| robru | infinity, sure, those people do, but i'm not one of them | 20:52 |
| infinity | robru: Just sayin', you might know some of them. | 20:52 |
| xnox | robru: boost is a catching sync of everything that's missing. E.g. in python one gets a lot of modules that are always available (batteries included), in C++ world one usually depends on one of the ~30 libraries that boost provides. | 20:52 |
| xnox | s/catching/kitchen/ | 20:53 |
| robru | infinity, i might know them, but if it's an easy fix, it's easier for me to just do it than to try and track down whoever. like, first I'd need to look up who even is responsible, then i'd have to find them, then they might be EOD, etc etc etc. I'll just fix it | 20:54 |
| kenvandine | robru, cool if we can narrow that | 20:59 |
| robru | kenvandine, yep, checking now | 20:59 |
| kenvandine | build dep on the -all-dev package is the lazy way out | 21:01 |
| xnox | kenvandine: i think it's just system-dev and programming-options-dev. | 21:02 |
| robru | xnox, seems so | 21:03 |
| xnox | kenvandine: do you have commit access to that branch? cause I was going to fix it direct in the archive upload. | 21:03 |
| xnox | also I have opened the bug 1252860 | 21:03 |
| ubot2 | Launchpad bug 1252860 in unity-system-compositor (Ubuntu) "Build-dependency on libboost-all-dev is not allowed" [High,Confirmed] https://launchpad.net/bugs/1252860 | 21:03 |
| xnox | against ci-services & compositor. | 21:03 |
| robru | xnox, please don't fix it in the archive, let me fix it in the branch, it's less of a hassle to re-merge later | 21:03 |
| xnox | robru: right, once i finish the test-build, i'll give you a patch in a pastebin. | 21:04 |
| robru | xnox, ok | 21:05 |
| kenvandine | xnox, thx | 21:05 |
| xnox | robru: http://paste.ubuntu.com/6444865/ | 21:09 |
| robru | xnox, oh, how did you determine those other bits were required? I built it just with system and program-options, seemed fine to me... | 21:10 |
| xnox | robru: you must not have been building in a clean environment. | 21:10 |
| xnox | robru: the cmake module checks for those. | 21:11 |
| robru | xnox, oh, nope | 21:11 |
| robru | xnox, ahhh | 21:11 |
| xnox | robru: anyway, i'm past EOD and i've been dragged into fixing boost & unity-system-compositor =) so I'll be gone now, and I hope you have enough patches to proceed. | 21:12 |
| robru | xnox, oh yes, thanks | 21:12 |
| robru | kenvandine, easy one then ;-) https://code.launchpad.net/~robru/unity-system-compositor/drop-libboost-all-dev/+merge/195860 | 21:14 |
| xnox | robru: you don't have to land it now. | 21:21 |
| robru | xnox, what do you mean? sooner the better | 21:21 |
| xnox | robru: boost-mpi-source is fully build and will be published everywhere in less than 30 minutes, thus you will be able to retry failed build. | 21:21 |
| xnox | robru: with the old "libboost-all-dev" | 21:22 |
| robru | xnox, ok, but it still needs to happen, might as well fix it now | 21:22 |
| xnox | robru: true =) | 21:22 |
| xnox | robru: yes, the fix needs to happen to avoid this problem ever again for that package (also main inclusion & cross-building require to have explicit boost dependencies) | 21:23 |
| === alex-abreu is now known as alex-abreu|afk | ||
| RAOF | stgraber: Is Wednesday morning UTC+11 your SRU sweep time, too? :) | 23:30 |
| infinity | RAOF: His SRU sweep time is "whenever someone else it trying to do it". | 23:31 |
| infinity | In my experience, anyway. | 23:31 |
| infinity | s/it/is/ | 23:31 |
| stgraber | haha, I actually noticed RAOF was at it and stopped ;) | 23:31 |
| RAOF | I'll go away and do something else, then :) | 23:31 |
| stgraber | my current allocated time is whenever people pester me about their SRUs | 23:31 |
| RAOF | Were we processing from opposite ends of the list? | 23:31 |
| stgraber | probably, I was going from precise down | 23:32 |
| stgraber | but I think I only did a couple of packages before noticing your SRU comments on bugs and stopping | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!