[08:48] <ari-tczew> is there any ppa for arm64 / ppc64el? I found probably a patch to fix FTBFS on such archs, but I wouldn't  do mess up in -proposed...
[08:56] <ari-tczew> or another way, can someone take a look on following buildlog and give a feedback, whether enabling dh-autoreconf should fix that FTBFS? https://launchpadlibrarian.net/200243699/buildlog_ubuntu-vivid-ppc64el.blktap_2.0.90-3ubuntu1_BUILDING.txt.gz
[08:58] <mitya57> ari-tczew: enabling autoreconf won't fix it
[08:58] <ari-tczew> mitya57: ok thanks, also upstream problem
[09:01] <ari-tczew> mitya57: what do you think, is now better way to disable compiling blktap on arm64 and ppc64el? our delta is: Architecture: i386 amd64 -> Architecture: linux-any
[09:02] <mitya57> Actually that error (uninitialized variable) does not look architecture-specific at all
[09:03]  * ogra_ hugs infinity ... (initramfs-tools-ubuntu-touch builds again )
[09:07] <mitya57> hm, maybe it's a false positive
[09:09] <mitya57> ari-tczew: looks like it is a false positive: vhd_footer_offset_at_eof(ctx, &end) will either initialize end or return an exit code, which will be handled
[09:12] <mitya57> a simple "end = 0;" before "err  = vhd_footer_offset_at_eof(ctx, &end);" will make it compile without that warning
[09:24] <ari-tczew> mitya57: wow, nice. however, in such cases ppa for arm64 / ppc64el would be useful... anyway I have to test your fix through -proposed
[09:29] <mitya57> there are landing ppas with all 6 architectures, but a very limited set of people can upload to it
[09:35] <ari-tczew> mitya57: ok, so if it's very limited for VIPs, then I'll push a patch to vivid-proposed without any doubts
[09:36] <mitya57> yes
[11:03] <ari-tczew> mitya57: Well, I was trying to build your fix, but now it fails with the same error on i386, as well :)
[11:05]  * mitya57 looks
[11:06] <mitya57> oh, not i386, but arm64
[11:07] <mitya57> ari-tczew: or do you mean that it fails locally?
[11:07] <ari-tczew> mitya57: locally
[11:08] <ari-tczew> @pbuilder
[11:08] <udevbot> Error: "pbuilder" is not a valid command.
[11:09] <mitya57> do you have the build log?
[11:09] <mitya57> and paste the patch that you applied, please
[11:10] <ari-tczew> mitya57: build log: http://paste.ubuntu.com/10650875/
[11:10] <mitya57> well, you didn't include the ';'
[11:12] <mitya57> actually even if you (or I) fix it, it won't migrate because of a different error
[11:12] <mitya57> "blktap-utils/powerpc unsatisfiable Depends: blktap-dkms"
[11:13] <mitya57> let me fix it
[11:13] <ari-tczew> mitya57: odd, lame bug
[11:14]  * ari-tczew is hiding himself underground
[11:16] <ari-tczew> mitya57: how are you going to fix unsatisfiable depends if there is no arch provided by blktap-dkms?
[11:19] <mitya57> I'm going to check if blktap-dkms builds on powerpc
[11:21] <ari-tczew> mitya57: have you got a powerpc or do you have an access to VIP's ppa? :)
[11:23] <mitya57> Both :)
[11:23] <mitya57> well, not my powerpc, but I can test on Debian's porter boxes
[11:24] <ari-tczew> mitya57: is it possible to build fine that package on Debian, but on Ubuntu's builder will FTBFS?
[11:25] <mitya57> I don't think there will be any difference between Debian and Ubuntu here
[11:27] <ari-tczew> ok
[11:45] <infinity> ogra_: Yeah, that fakechroot behaviour is irritating.
[11:45] <infinity> ogra_: But I guess I don't update glibc to new upstream versions more than once every six months, so not world-ending.
[11:45] <ogra_> infinity, well, the prob is that you cant tell debootstrap to use proposed :)
[11:47] <infinity> ogra_: Yeah, I've been considering fixing that.  Well, not proposed specifically, but extra sources, so that preseed netinst installs can debootstrap from updates instead of doing release-pocket-then-upgrade.
[11:48] <ogra_> oh, that would be cool ... i can imagine that restriction bites in other places too
[11:48] <infinity> ogra_: But debootstrap used to be pretty sensitive to Packages ordering (there's a bit of dumb luck involved), so just concatenating Packages files, which would be the naive way to fix it, might break things.
[11:49] <infinity> ogra_: I think the "right" way to do it would be to pull all the source you asked for and then interlace them, or maybe even supersede old entries with new, but that's a lot more work, given debootstrap's generally simple architecture.
[11:49] <ogra_> yeah
[11:55] <jhenke> hi are there any known problems with the dns resolution after boot? Here it just works after cycling all connections once
[11:55] <jhenke> bug #1434986
[19:16] <infinity> Riddell: Your new upstream version of libgit2 is incompatible with one of its only 2 rdeps (libgit2-glib).
[19:19] <Riddell> infinity: libgit2-glib needs to fix its abi https://lists.ubuntu.com/archives/ubuntu-devel/2015-February/038683.html
[19:20] <infinity> Riddell: Whee.  Has anyone told upstream that they broke ABI?
[19:21] <Riddell> infinity: not that I know of
[19:21] <infinity> Riddell: Oh, wait, that's a .0 SOVER, I imagine ABI breaking is something they feel within their rights to do.
[19:21] <infinity> Riddell: So, the right thing to do would just be to declare a versioned Breaks on gitg (<< 3.15) and carry on, I imagine.
[19:23] <Riddell> infinity: gotcha, I'll add it to my todo
[19:24] <infinity> Riddell: Ta.  It's the only thing in NBS right now, so it was sticking out like a sore thumb, hence my poking at it.
[19:28] <Noskcaj> infinity, Riddell: Should libgit2-glib 0.22.0 be packaged?
[19:30] <Noskcaj> and the required gitg patches
[19:31] <Riddell> Noskcaj: yes please :)
[20:25] <Noskcaj> Riddell, both are in ppa:noskcaj/staging
[20:26] <Noskcaj> Do i need to file a new FFe, or is there an existing one i should add this to?