[00:24] <wgrant> helmut: Thanks for poking us about that. Do you have a timeline for those packages starting to land in sid?
[03:55] <DalekSec> (Instrusted to try asking here.) So why is it when I use bzr lp-propose (with or without target branch), it seemingly randomly targets whatever it wants, not what I specify?  Most recently, I targetted nothing and it errord out, I targetted branch/utopic and it tried to submit to branch/trusty.
[04:01] <wgrant> DalekSec: How are you invoking it?
[04:08] <DalekSec> bzr lp-propose  or  bzr lp-propose lp:~xubuntu-dev/ubuntu-seeds/xubuntu.utopic   or   bzr lp-propose bzr+ssh://bazaar.launchpad.net/xubuntu-dev/ubuntu-seeds/xubuntu.utopic/
[04:12] <DalekSec> Also tried putting in some "saved" location in .bzr/branch/branch.conf
[04:15] <wgrant> DalekSec: It's working fine for me. Which version of bzr are you using?
[04:16] <wgrant> ubuntu-seeds has no development focus, so there will be no default.
[04:16] <DalekSec> Installed: 2.6.0+bzr6593-1ubuntu1.1
[04:17] <DalekSec> It'd be a great tool, but it works about 30% of the time.:/
[04:21] <DalekSec> But yeah, happens on many different repos, that's just the latest. :/
[04:26] <wgrant> DalekSec: It's a bug in bzr. It tries to turn the given submit branch URL into a Launchpad API URL using lp_api.LaunchpadBranch.from_bzr, which calls candidate_urls, which looks up the branch's parent branch.
[04:27] <wgrant> I'm not sure why it doesn't use bzr_branch.base
[04:27] <wgrant> But I'd be filing a bug against bzr.
[04:29] <DalekSec> I would if I knew what was going on more than bzr being bzr..  I'll use that info and see if I can find any reported bug.
[04:34] <DalekSec> Hrm, perhaps 1078211.
[04:35] <wgrant> Yup, that looks like it.
[04:36] <DalekSec> wgrant: As always, thanks for your help.  Do you ever stop looking here? :P
[04:36] <wgrant> Sometimes for almost eight hours a day!
[04:36] <DalekSec> \o/
[04:37] <DalekSec> Welp, have a good night.
[04:37] <wgrant> Night.
[04:47] <helmut> wgrant: we are in the process of updating the tools and updating the infrastructure. the next steps (hopefully) are uploading to wheezy-backports, updating ftp-master's installation and then uploading to experimental. I think sid should be safe for a month at least.
[04:48] <wgrant> helmut: Thanks. experimental's interesting for us too. I can easily formulate some example packages to test, but are there some existing samples?
[04:49] <helmut> wgrant: there are quite a few patches in the debian bts. most of them are in bug reports blocked by #744246
[04:49] <helmut> (that's a debian number)
[04:50] <wgrant> helmut: Thanks.
[04:50] <helmut> wgrant: one thing I'd like to see become common is Build-Depends: myownbinarypackage <profile.cross>
[04:51] <helmut> wgrant: that's a good test-case, because it uses a profile in a positive way, so you need to ignore this build-dependency unless the cross profile is activated.
[04:54] <helmut> wgrant: cjwatson pointed out to me that lp:launchpad-buildd and sbuild likely need changes. I didn't check the former, but patches for the latter can be found at http://bugs.debian.org/731798
[04:55] <helmut> since debian traditionally uses a different sbuild package from the one in sid, this bug may stay open even after using build profiles.
[04:55] <wgrant> helmut: Our sbuild is currently a fork of DSA sbuild from ~2004, so sadly the patches won't be terribly useful. Until we upgrade to something more modern, I intend to do the minimum and just drop any dep that is restricted and doesn't have at least one negative term.
[04:56] <wgrant> That is the minimum, isn't it?
[04:56] <helmut> yes, that is perfectly ok and is what we are proposing the the wheezy-backports, see https://lists.debian.org/deity/2014/04/msg00142.html
[04:57] <helmut> there you can see example patches for dpkg and apt that support just the syntax without actually supporting profiles
[04:58] <helmut> and there is not much more to do anyway unless you actually want to use build profiles.
[04:58] <helmut> so just supporting the syntax may get you a long way.
[04:59] <helmut> the main use case currently is for cross-compilation and bootstrapping, where knowing what dependencies can be dropped in staged builds is cruicial.
[05:00] <wgrant> Yeah, exactly. We don't do early bootstrapping directly in Launchpad. We use a modern distro sbuild for that.
[05:01] <wgrant> Thanks.
[05:02] <helmut> if you have any other questions at a later time or need patch review, just ask. you'll reach those driving build profiles in oftc #debian-bootstrap
[05:02] <helmut> should I stumble accross more infrastructure pieces in Debian that likely have a match in launchpad, I shall notify you.
[05:04] <wgrant> helmut: Great. IRC or wgrant@ubuntu.com works, but I can't think of much else. I'll test it all out next week.
[05:05] <helmut> I see that launchpad will be faster in supporting build profiles than Debian will be.
[05:07] <wgrant> I'm hoping to avoid the unpleasantness back in 2010 of having to quickly implement 3.0 (quilt) just after it started landing it sid.
[05:08] <helmut> I guess that is why vorlon asked me to poke you.
[05:09] <helmut> wgrant: my plan is to use doxygen as a test package in experimental first and only if nothing breaks upload to sid.
[05:10] <wgrant> Sounds good.
[05:10] <wgrant> I hate the mess of loops around doxygen :)
[05:10] <helmut> in what ways did it cause grief to you?
[05:11] <wgrant> Oh, just the doxygen -> graphviz -> THE ENTIRE WORLD dep chain makes arch bootstraps annoying.
[05:11] <helmut> the profile stuff will not get around that issue
[05:12] <helmut> it only removes the qt dependency
[05:12] <wgrant> Ahh
[05:14] <helmut> on the bright side, bootstrapping is already in way better shape than it was recently (at least in sid) due to the amount of patches applied.
[05:15] <helmut> my personal interest resides mostly in https://wiki.debian.org/HelmutGrohne/rebootstrap </advertisement>