[10:08] <crass> anyone noticed a change in debhelper starting in quantal, where the build target seems not to be called, but build-arch target is called directly?
[10:09] <wgrant> crass: dpkg-buildpackage will nowdays call build-arch and build-indep directly if they exist.
[10:09] <crass> wgrant: why?
[10:09] <wgrant> (as well as binary-arch/binary-indep)
[10:10] <wgrant> crass: So that only the relevant bits of the package are built.
[10:11] <crass> that makes sense, but then you can't rely on the build target to do stuff of define dependencies common to both of them
[10:11] <wgrant> That's correct, you cannot rely on that.
[10:13] <wgrant> If build-arch or build-indep exist, they need to operate without build
[10:14] <crass> what's interesting is that for amd64 builds build-arch is called directly, but for x86 build is called
[10:15] <wgrant> crass: That's because i386 builds build both the i386 arch-dep and the arch-indep packages.
[10:15] <crass> there is no defined build-arch or build-indep in the rules
[10:15] <crass> why is there that difference?
[10:15] <wgrant> Because the architecture-independent packages need only be built on a single architecture
[10:16] <crass> ahh, of course
[10:16] <wgrant> However, dpkg-buildpackage is meant to detect whether build-arch and build-indep exist
[10:16] <wgrant> Are you sure they don't?
[10:17] <crass> well, they aren't in the rules file, perhaps debhelper does something?
[10:18] <crass> build does exist
[10:18] <wgrant> If you're using the modern debhelper style then it will define them for you.
[10:18] <wgrant> But if you're using modern debhelper you wouldn't usually override the build target directly...
[10:18] <crass> modern is %:\n\tdh $@ ?
[10:19] <wgrant> Yes
[10:19] <crass> well, I copied a rules from a package in the ubuntu repo (universe) and it needs to patch the source with quilt
[10:20] <wgrant> You'd normally override something like override_dh_auto_build
[10:20] <wgrant> Ah, if you want quilt then just call 'dh --with quilt $@' instead of 'dh $@'
[10:21] <crass> hmm, let me try that, this package was probably created before that existed
[10:22] <wgrant> Which package?
[10:22] <crass> proxychains
[10:22] <wgrant> Which version?
[10:23] <wgrant> In saucy it's using the 3.0 (quilt) format, which does quilt patches itself.
[10:23] <crass> ahh, I copied from the precise repo, which is what I'm still using
[10:23] <crass> version 3.1
[10:23] <wgrant> Hm, so you're trying to build the precise package in quantal?
[10:24] <crass> well no, I just copied the debian dir
[10:24] <crass> should work across all distros (ideally)
[10:24] <crass> I'm also building for raring, and saucy
[10:24] <crass> its a recipe build of trunk
[10:25] <wgrant> You'd probably want to grab the latest packaging and tweak it until it also works on older series, rather than vice-versa.
[10:25] <crass> yeah, good point
[10:26] <crass> I don't normally do that just because it more of a PITA to get that than apt-get source <pkg>
[10:28] <cjwatson> If you need a common target, you should have both build-arch and build-indep depend on a build-common target or similar, not rely on build to be that common target.
[10:28] <cjwatson> But usually with modern dh this sort of thing isn't necessary, as wgrant says.
[10:29] <crass> yeah, and I wouldn't think it would be necessary.  I just didn't know how it was supposed to be done
[10:29] <cjwatson> pull-lp-source can fetch from any series without apt configuration, and is no more of a PITA than apt-get source.  Very handy.
[10:31] <crass> thanks for the tip cjwatson!
[12:28] <crass> why is the automated svn import for wireshark failing? http://launchpadlibrarian.net/133073002/vcs-imports-wireshark-trunk.log
[20:34] <qengho> Hi hi. There's a private PPA in a team that I'm a member of. I want to use the PPA. Should I be able to?
[20:34] <qengho> On the PPA page, there are APT lines that do not have credentials attached.
[20:35] <qengho> When I try to use them, I get HTTP 401.
[20:36] <cjwatson> I believe you need a subscription
[20:36] <cjwatson> Archive:+subscriptions
[20:37] <cjwatson> That requires archive owner access
[20:38] <cjwatson> So if the PPA is owned by the team and you're a member, you should be able to use that
[20:39] <qengho> cjwatson: you lost me at "Archive:+subscription" .
[20:39] <cjwatson> https://launchpad.net/~OWNER/+archive/PPANAME/+subscriptions
[20:40] <cjwatson> LP people tend to talk about ObjectName:+page as a generalised encoding of https://launchpad.net/path/to/object/+page
[20:41] <qengho> cjwatson: Right.  I'm already authorized there.  (ObjectName didn't end in a slash, either.)(
[20:42] <qengho> Anyway, so, I should be able to access it, which I think means the PPA description page should have a custom apt source line for me.  It doesn't.
[20:42] <cjwatson> Authorised personally or by team?  Just so I can set up something equivalent on dogfood ...
[20:43] <qengho> cjwatson: personally.
[20:43] <cjwatson> It looks like you should get the token by mail rather than on the web page
[20:46] <qengho> cjwatson: I don't remember one, and can't find it in mail archive. I don't see a way to ask for a reminder.
[20:50] <cjwatson> qengho: https://launchpad.net/~/+archivesubscriptions
[20:50] <cjwatson> The "View" links there give you apt lines with tokens
[20:51] <cjwatson> That's linked from "View your private PPA subscriptions" on https://launchpad.net/~
[20:52] <qengho> cjwatson: ah hah!
[20:52] <qengho> cjwatson: thank you.
[20:52] <cjwatson> I knew it was around somewhere but had to grep the source to find it :)
[20:53] <czajkowski> aloha
[20:53] <qengho> cjwatson: that used to be on the PPA page, a year ago.
[20:53] <cjwatson> I'll take your word for it
[20:54] <cjwatson> It does seem a bit unhelpful the way it is
[21:03] <dobey> qengho: i don't recall it ever being on the archive page instead of the general apt source lines. i do know it's been complained about/requested before though, and there is probably an open bug for it :)
[21:05] <qengho> dobey: It was for a project you and I worked on, I'm pretty sure.  It's been a while since I needed it, though.
[21:06] <dobey> qengho: don't think so. i've always had to tell people to not use those lines, and we have a wiki page for setting up dev environments that points to the /~/+archivesubscriptions page
[21:07] <dobey> qengho: it's probably just been long enough that you've misremembered it :)
[21:08] <qengho> dobey: my memory is terrible. I believe you.
[21:09] <cjwatson> qengho,dobey: https://bugs.launchpad.net/launchpad/+bug/376608
[21:10] <cjwatson> Hm, actually no
[21:10] <cjwatson> That's about the series
[21:11] <cjwatson> Perhaps https://bugs.launchpad.net/launchpad/+bug/458360 ?
[21:12] <dobey> those sound like the same issue
[21:12] <cjwatson> Not quite, if you read the former bug in detail
[21:13] <cjwatson> 458360 sounds plausible-ish though
[21:15] <dobey> ah, so not exactly the same but related. the former is probably best fixed by fixing the latter, and then just changing the code to redirect to the archive page, where it defaults to "RELEASE" in the deb lines, and you can select a series to copie, and it has a bit more textual info about how "RELEASE" won't work, when accepting a private ppa subscription