=== Ursinha-afk is now known as Ursinha
=== doko_ is now known as doko
LaneyNBS needs to be resolved before migration now, right?09:24
xnoxLaney: yeah.10:25
Laneyxnox: do you have access to the arm64 porter machine?10:28
xnoxLaney: 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
Laneywebkit is making me sad10:33
xnoxyou are not the first one =)10:35
=== Ursinha-afk is now known as Ursinha
sil2100Hi everyone! There is a zmqpp source package in the NEW queue that would need pushing further - can anyone take care of that?11:53
seb128sil2100, looking12:08
sil2100seb128: thanks :)12:08
sil2100seb128: 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 upload12:09
xnoxare ":native" build-dependencies supported now? or is there a tracking bug about that?13:17
cjwatsonShould work13:23
cjwatsonI believe it should even work in Debian too13:23
xnoxI now only see bug 1252728 when trying to set up a fresh trusty chroot13:29
ubot2Launchpad bug 1252728 in gcc-4.8 (Ubuntu) "crossbuild-essential-armhf is not installable" [Undecided,New] https://launchpad.net/bugs/125272813:29
cjwatsonYou didn't try the usual things to get apt to give you more useful information?13:30
xnoxcjwatson: i've tried installing more sensible packages, and it gave up on trying to install gcc:armhf.13:36
xnoxlet me get more debug/verbose output out of it.13:36
cjwatsonYou 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 installed13:39
cjwatsonWhich probably just means multiarch desync in a chroot containing -proposed.13:39
xnoxah. 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 publishing13:39
cjwatsonWhich it should do on the next publisher run13:39
cjwatsonFWIW this was the command that gave me the real error:13:40
cjwatsonapt-get install libc6-dev:armhf libc6:armhf libgcc1:armhf gcc-4.8-base:armhf libc613:40
cjwatson(No doubt one can reduce that)13:40
xnoxi didn't have gcc-4.8-base:armhf, but i did try the others.13:40
cjwatsonlibgcc1:armhf libgcc1 shows it too13: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 installed13:42
* xnox ponders if mk-sbuild should default to setting up cross-builders without -proposed.13:42
cjwatsonIt at least has an option for it13:44
xnoxthen again native amd64 & _all packages from i386 can be out of sync the same way. cross just has longer window.13:45
cjwatsonOh 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
sil2100seb128: 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/zmqpp17:37
seb128sil2100, they are in NEW (note the (New) on that launchpad page), let me review those17:38
Laneythey're in binary NEW17:38
sil2100seb128: ah, but I think you moved them today from the NEW queue?17:38
seb128sil2100, source NEW, not binary NEW17:38
rtginfinity, any thoughts on this ? https://bugs.launchpad.net/ubuntu/+source/linux-goldfish/+bug/1236444/comments/517:39
ubot2Launchpad bug 1236444 in linux-goldfish (Ubuntu Saucy) "kernel panic" [Undecided,Fix released]17:39
seb128sil2100, binNEWed17:40
infinityrtg: gcc-4.6 is still in trusty, no dragging required.17:41
rtginfinity, huh, thought I looked.17:41
infinityrtg: 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, powerpc17:42
rtginfinity, doh!17:42
xnoxrtg: armhf-cross is not, and i've pinged doko about re-introducing it.17:42
xnox(for 4.6 that is)17:42
rtgxnox, yeah, the cross compiler would be nice17:42
rtgxnox, I'll respin goldfish with the old compiler17:42
infinity4.6 cross hasn't existed since quantal.17:43
sil2100seb128: thanks again!17:43
seb128sil2100, yw!17:43
rtginfinity, yeah, I've been using chroots to cross compile17:43
infinityrtg: I don't suppose anyone's put any effort into figuring out WHY 3.4 kernels blow up with newer compilers? :/17:44
infinityrtg: Maintaining a ton of toolchains just for this is really icky.17:45
xnoxinfinity: 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
rtginfinity, none of the Nexi work with newer gcc AFAIK, though I have been building recent armhf kernels with the current toolchain.17:46
infinityrtg: 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
xnoxrtg: 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
infinityrtg: But I'm just curious WHY.17:47
infinityxnox: I assume you mean it failed to boot when compiled with *4.8*, not 4.6...17:47
xnoxinfinity: yeah typo.17:47
rtgxnox, yeah, 4.8 right ?17:47
xnoxrtg: yes 1.8 from ppa compiled with 4.8 fails to boot.17:47
infinity(Have we tested 4.7?)17:48
rtginfinity, I'm curious WHY myself, but have precious little time to go figure it out.17:48
xnoxinfinity: in the past we have. see history on the goldfish kernel bug report "kernel panic"17:48
infinityrtg: Yeah, I think we're all in the ENOTIME boat.17:48
infinityxnox: The history is pretty sparse, and doesn't mention 4.7 at all, to be fair.17:49
xnoxinfinity: 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
xnoxinfinity: right, i think 4.7 was done off the kernel-ppa build / on irc.17:49
* infinity nods.17:49
infinityWell, at least the kernels are in universe, so we don't need to *support* 4.6...17:50
infinityBut we still need to sort of support it, which sucks.17:50
rtginfinity, 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
infinityrtg: Yeah, I assume all 3.4 kernels suffer the same issue.17:51
infinityTrawling git logs to find the fix(es) would probably be painful.17:51
=== debfx_ is now known as debfx
rtgxnox, linux-goldfish is pending publication in Trusty https://launchpad.net/~canonical-kernel-team/+archive/ppa18:59
xnoxrtg: \o/18:59
rtgxnox, prolly wanna make sure armhf boots before you pocket copy it (though it ought to work)19:01
xnoxrtg: right =) will -meta need an upload as well, or will it "just work" ? =)19:02
rtgxnox, no ABI bump, so all should just work19:02
rsalvetixnox: what are the changes?19:04
rsalvetioh, just a revert, ok19:05
xnoxrsalveti: actual change enable GPT disk partitions on armhf, it used to only be enabled on i386.19:07
xnoxrsalveti: and experiment compiling with 4.8, instead of 4.6 didn't work.19:07
infinityxnox: I'll do the pocket copy if you verify it's not broken.19:23
xnoxinfinity: well it boots. please copy.19:36
robruxnox, please ping me when boost is ready20:41
xnoxrobru: well it's uploaded awhile ago, it should build & migrate by itself, whenever it does.20:43
xnoxrobru: i'm not sure why i should be pinging you.20:43
robruxnox, well i need to know when it's ready so i can get on with building things that depend on it.20:44
xnoxrobru: 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
xnoxrobru: 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
xnoxrobru: with or without -mpi-source upload, you shouldn't be blocked.20:45
robruxnox, 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.gz20:46
xnoxrobru: it obsoletely must not build-depend on libboost-all-dev, that pulls in universe dependenices which will never be in main.20:47
cjwatsonhah, yes, I didn't catch that earlier20:47
robruxnox, file a bug against lp:unity-system-compositor then. i don't know anything about that stuff, it's just my job to build it20:47
xnoxrobru: please build-depend on individual boost-COMPONENT-dev packages, and you would have completely avoided this waiting.20:47
robruxnox, I didn't create the packaging for this.20:48
xnoxrobru: 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
robruxnox, hah, alright20:48
robrukenvandine, ^^ you reading this?20:49
xnoxrobru: this also not the first time this came up.20:50
robruxnox, first time it's bit me20:51
robruxnox, 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 boost20:51
robruxnox, completely unfamiliar with the components of boost, too, for that matter.20:51
xnoxrobru: look at resulting binary package it will depend on libboost-serialisation-1.54.0, then you need libboost-serialisation-dev.20:52
infinityI'd hope the people who wrote the software know what bits they need.20:52
infinityBut yes, the "build it with all-dev and check linkage" thing works.20:52
robruinfinity, sure, those people do, but i'm not one of them20:52
infinityrobru: Just sayin', you might know some of them.20:52
xnoxrobru: 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
robruinfinity, 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 it20:54
kenvandinerobru, cool if we can narrow that20:59
robrukenvandine, yep, checking now20:59
kenvandinebuild dep on the -all-dev package is the lazy way out21:01
xnoxkenvandine: i think it's just system-dev and programming-options-dev.21:02
robruxnox, seems so21:03
xnoxkenvandine: do you have commit access to that branch? cause I was going to fix it direct in the archive upload.21:03
xnoxalso I have opened the bug 125286021:03
ubot2Launchpad bug 1252860 in unity-system-compositor (Ubuntu) "Build-dependency on libboost-all-dev is not allowed" [High,Confirmed] https://launchpad.net/bugs/125286021:03
xnoxagainst ci-services & compositor.21:03
robruxnox, please don't fix it in the archive, let me fix it in the branch, it's less of a hassle to re-merge later21:03
xnoxrobru: right, once i finish the test-build, i'll give you a patch in a pastebin.21:04
robruxnox, ok21:05
kenvandinexnox, thx21:05
xnoxrobru: http://paste.ubuntu.com/6444865/21:09
robruxnox, 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
xnoxrobru: you must not have been building in a clean environment.21:10
xnoxrobru: the cmake module checks for those.21:11
robruxnox, oh, nope21:11
robruxnox, ahhh21:11
xnoxrobru: 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
robruxnox, oh yes, thanks21:12
robrukenvandine, easy one then ;-) https://code.launchpad.net/~robru/unity-system-compositor/drop-libboost-all-dev/+merge/19586021:14
xnoxrobru: you don't have to land it now.21:21
robruxnox, what do you mean? sooner the better21:21
xnoxrobru: 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
xnoxrobru: with the old "libboost-all-dev"21:22
robruxnox, ok, but it still needs to happen, might as well fix it now21:22
xnoxrobru: true =)21:22
xnoxrobru: 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
RAOFstgraber: Is Wednesday morning UTC+11 your SRU sweep time, too? :)23:30
infinityRAOF: His SRU sweep time is "whenever someone else it trying to do it".23:31
infinityIn my experience, anyway.23:31
stgraberhaha, I actually noticed RAOF was at it and stopped ;)23:31
RAOFI'll go away and do something else, then :)23:31
stgrabermy current allocated time is whenever people pester me about their SRUs23:31
RAOFWere we processing from opposite ends of the list?23:31
stgraberprobably, I was going from precise down23:32
stgraberbut I think I only did a couple of packages before noticing your SRU comments on bugs and stopping23:32

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!