[03:11] <micahg> infinity: is there a reason why you didn't just make a new backport for precise-backports for debootstrap (apologies if I'm beating a dead horse)
[03:13] <infinity> micahg: Yeah, because re-backporting it every time is silly.
[03:13] <infinity> micahg: Not when people also insist on SRUing it anyway.
[03:13] <micahg> infinity: did you remove the version from backports then?
[03:14] <infinity> Was planning on it.
[03:14] <micahg> it's useful if someone wants features, I assume the backport was for features
[03:14] <infinity> No, the backport was just for the symlink.
[03:14] <micahg> yeah, that should've been an SRU then, <shrug>
[03:15] <infinity> There, removed from backports.
[03:15] <micahg> thanks
[03:15] <micahg> I usually end up with the problem that updating the seeds usually wants a newer debootstrap each time
[03:15] <mfisch> looking at a merge and finding out that it can be a sync is the best part of my day...
[03:16] <micahg> I'm still on precise on my main machine
[03:16] <infinity> I tend to just grab the .deb from the devel release and install it on older releases.
[03:16] <infinity> It's arch_all after all, and Just Works.
[03:16] <micahg> I usually end up with a local backport, but that's probably just as good of a solution
[03:18]  * micahg fires up a trusty chroot
[03:52] <mfisch> micahg: do you get email notifications of new packages in the repos?
[03:52] <micahg> yes
[03:53] <mfisch> micahg: where do you sign up for that?
[03:53] <micahg> https://lists.ubuntu.com/mailman/listinfo/trusty-changes
[03:55]  * mfisch checks the archive
[03:55] <mfisch> so I've managed 3, only 487 more to go to catch up with Colin ;)
[03:56] <ScottK> mfisch: Worry more about making them good than how many there are.
[03:56] <mfisch> ScottK: heh, I'm not worried either way, I just enjoy doing it
[14:12] <dereck> where do I submit bugs for the arm64 compiler on launchpad?
[14:13] <mitya57> dereck: What do you mean by "arm64 compiler"? We have the same compiler everywhere i.e. gcc.
[14:14] <dereck> that is to day that a build on launchpad failed with an 'internal compiler error: Segmentation fault'
[14:14] <dereck> and it asked to submit a bug report, but doesn't mention where :)
[14:14] <cjwatson> dereck: Don't submit bugs for those, they're hardware problems
[14:15] <cjwatson> dereck: Just give us the .../+build/... URL and we'll sort it out - or alternatively you can ignore it and we'll sort it out in bulk once arm64 has caught up
[14:15] <dereck> 10-4, thanks
[14:16] <dereck> it's not particularaly important to me, but I thougth i'd report it in case someone cared: +build/5150148
[14:17] <cjwatson> dereck: I'd need the full URL
[14:20] <dereck> cjwatson: http://goo.gl/T450jj
[14:21] <cjwatson> dereck: retried, thanks
[14:21] <cjwatson> (in fact I had mail about that, I just hadn't processed it yet)
[14:22] <dereck> Just for curiosity's sake, you say it's a hardware issue?
[14:22] <cjwatson> Yes
[14:23] <dereck> do you have a link to more info on what casues that, or do you know what it is by chance?
[14:23] <cjwatson> I'm not able to talk about the hardware in question right now
[14:24] <cjwatson> Suffice to say it's pre-release and occasionally a bit shaky
[14:24] <dereck> :D fair enough.
[14:24] <dereck> I'm surprised launchpad doesn't just use cross-comppilers rather than native builds. why is that, if I may?
[14:24] <cjwatson> A retry is usually sufficient; failing that, birch is a slightly newer model and does better
[14:25] <cjwatson> dereck: About a third of packages in Ubuntu main can be cross-compiled cleanly
[14:25] <cjwatson> dereck: This is a massive step up from where we were five years ago, but it's still very far from where we'd need to be to use it across the board
[14:25] <cjwatson> dereck: And even at that, some packages can't be cross-built without leaving some things out - anything that builds executables and then attempts to run them as part of its build, which is a lot more common than you'd think
[14:26] <cjwatson> dereck: For example, gtk-doc generation currently requires running the built binaries in a special mode
[14:26] <cjwatson> (AIUI; I haven't looked closely at that particular case but it comes up a fair bit)
[14:26] <dereck> That's quite interesting, thanks. :)
[14:26] <cjwatson> dereck: Oh, and of course you often can't run test suites during the build if you're cross-compiling, which would be a serious problem for QA
[14:27] <cjwatson> dereck: So I don't expect we'll ever use cross-compiling in the general case, although we'll probably make more use of it in some special cases as time goes on
[14:27] <dereck> once KVM supports arm64, could you run the build process in there with a performance hit?
[14:27] <cjwatson> In short, not practical for a full distribution
[14:28] <cjwatson> dereck: User-mode qemu is very shaky in our experience; for example anything that uses threading tends to fall over, so the stack above Qt loses badly
[14:28] <cjwatson> dereck: We might use that for PPAs, but not for the primary distribution
[14:29] <dereck> good to know :)
[14:29] <cjwatson> In any case, the hardware we're building on now is pretty nice when it isn't segfaulting; it should be great once the bugs have been shaken out
[14:29] <cjwatson> I'm not keen to go back from that to qemu
[14:31] <dereck> I agree hardware is the best option, I was only curious. :) And surprised that you have access to it honestly. :)
[18:19] <dereck> Is there anything I can do to help advance bug 1243310
[19:09] <dereck> Is there anything I can do to help advance my pet bug 1243310?
[19:10] <Laney> dereck: There's no source package called libaria2 - do you mean libaria?
[19:11] <Laney> What you need to provide us with is confirmation that the package you want to backport builds (without chanages), installs cleanly and runs on the target releases.
[19:16] <dereck> Laney: I fixed up the request, does that look better?
[19:17] <dereck> I also built the package locally and it's working fine. But cjwatson applied a patch to the ubuntu source that he says is required.
[19:17] <Laney> dereck: We backport from Ubuntu releases.
[19:17] <dereck> I don't really know much about that patch honestly.
[19:17] <Laney> So we can't take a Debian package (and it probably wouldn't work due to this patch).
[19:18] <Laney> You need to check the package from trusty builds/installs/runs as I just outlined
[19:19] <dereck> Ah, that makes sense then. I need to grab the Trusty source and build it locally then?
[19:19] <Laney> yeah
[19:19] <Laney> on all the releases you want to backport to (chroots can help you here)
[19:19] <Laney> possibly together with a PPA
[19:19] <Laney> the backportpackage script can help you prepare the package
[19:19] <Laney> s
[19:20] <dereck> ok, now that I have a better idea of what needs doing I'll hammer at it ^.^ Thanks@
[19:20] <Laney> No problem
[19:41] <lfaraone> Laney: wow, the backports team is fast :)
[19:41] <Laney> you got us on a good day :P
[19:41] <lfaraone> yesterday too!
[19:41] <lfaraone> much appreciated.
[19:41] <Laney> when requests are well-formed straight off it's so much easier
[19:41] <Laney> I have much less energy to chase up bad ones
[19:47] <dereck> Laney: this backportpackage script rocks! :3 Thanks for the tip~
[20:24] <dereck> Laney: I have finished building on each target distor without any problems, I think it's solid.
[20:24] <Laney> dereck: okay, please check it works a little bit too (light testing) and then post your results to the bug report
[20:25] <dereck> what's the best way to do that? It's a robot interface library, so I would have to install each distro on a robot to test really?
[20:26] <dereck> I have been using this code on raring for a couple days without any problem, is that good 'nuff?
[20:28] <Laney> dereck: Just post up what you've got and we'll see :-)
[20:42] <dereck> Laney: Updated with my results *fingers crossed*
[22:53] <jalcine> Question about packaging:/b 105