[09:05] <free> wgrant, cjwatson: hey there, some of you around?
[11:45] <cjwatson> free: what's up?
[11:48] <free> cjwatson: hey there
[11:49] <free> cjwatson: I pushed this MP for the txfixtures package (used by LP two, I guess): https://code.launchpad.net/~free.ekanayaka/txfixtures/sphinx-docs/+merge/311472
[11:49] <free> cjwatson: there is a few narrative in the MP description, but in short we (Landscape) would like to push a few new features there, that won't affect the existing ones at all. I'm wondering if we could make Landscape (or me) part of the project, to have commit rights
[11:51] <cjwatson> I think it should be ~lazr-developers
[11:52] <cjwatson> would that suit you?
[11:52] <free> cjwatson: sure, thanks
[11:53] <free> cjwatson: there's also the issue that there's no one in Canonical left with PyPI access to publish txfixtures releases (the owners are Robert Collins, Francis Lacoste and Martin Pool), but I'll get in touch with them for this
[11:53] <cjwatson> free: done, feel free to land your thing
[11:54] <cjwatson> free: hm, wgrant went through a big effort to reclaim PyPI access for a bunch of packages but maybe missed that one
[11:54] <cjwatson> free: Robert has generally been helpful there IIRC
[11:55] <free> cjwatson: cheers! cool, I'll get in touch with him. We're already in contact for other testing-related things
[11:57] <cjwatson> free: one minor thing, once you've landed that sphinx MP I'd suggest setting up a webhook to poke RTD to update (assuming RTD is configured to point to the right branch)
[11:58] <free> cjwatson: yeah we'll need that
[11:58] <cjwatson> free: it's very easy, go to https://code.launchpad.net/+branch/txfixtures, Manage webhooks, Add webhook, tell it to deliver to https://readthedocs.org/build/txfixtures on Bazaar push
[11:59] <free> cjwatson: unrelated, but JFY if you recall that old "issue" with txlongpoll, where I introduced a dependency on some yet-to-be-merged txamqp branch, that's going to be solved too, since I finally got a hang on txamqp (maintainership was transferred to me, since the original author can't work on it anymore)
[11:59] <cjwatson> ah, good
[11:59] <cjwatson> I still haven't had a chance to sort out the txlongpoll deployment issues we have :-/
[12:00] <free> cjwatson: yeah, iirc pbr was a problem for LP?
[12:00] <cjwatson> pbr is a headache
[12:00] <cjwatson> due to buildout
[12:00] <free> cjwatson: the two don't play nice together or what?
[12:00] <cjwatson> buildout doesn't like setup_requires
[12:00] <free> ah
[12:01] <cjwatson> the plan is to ditch buildout, but converting 12 years of build system complexity /o\
[12:01] <free> cjwatson: can't we teach buildout about setup_requires instead? or is that involved?
[12:02] <cjwatson> appears pretty involved, and converting to modern buildout is nearly as big a change as converting to pip anyway
[12:02] <free> cjwatson: I see, makes sense
[12:02] <cjwatson> so might as well convert to pip instead and be on the same tooling as the rest of the modern webdev space
[12:02] <cjwatson> but I keep inconsiderately having urgent new feature development dropped on me instead ;-)
[12:03] <free> cjwatson: :/
[12:04] <free> cjwatson: fwiw I believe a considerable part of Launchpad dependencies is in Debian and relatively well-maintained (and I just submitted an ITP for txfixtures plus uploaded it to NEW)
[12:04] <cjwatson> we mostly don't use packages
[12:04] <free> yeah
[12:04] <cjwatson> but I agree that those parts that are in Debian for whatever reason generally seem to be fairly well-maintained
[13:37] <sigmavirus> cjwatson: heh, I know that feeling of inconsiderately having new features dropped on you
[13:38]  * sigmavirus wishes he had free time to help improve launchpad's packaging
[17:49] <jgdx> hey, I'm getting NOPUBKEY when building https://code.launchpad.net/~jonas-drange/+snap/silo-2194 — anything I can do?\
[19:15] <phako> hi - looking for help with a PPA that is in dependency wait which I don't understand
[19:33] <olly> hi, a recent ppa upload for precise i made resulted in an email with "Rejected:" / "Cannot build any of the architectures requested: any all" - the previous upload i made a few months ago doesn't seem to have anything notably different in the _source.changes or .dsc (in particular, the same "any all" arch list) and worked
[19:33] <olly> and https://launchpad.net/ubuntu/+ppas lists precise as supported still
[19:34] <sarnold> olly: just out of curiosity, what does "any all" mean? I thought one meant "build on amd64 and use for all" and the other meant "build on all architectures"
[19:34] <olly> the subject line of the reject email seems to provide all the useful details: [~xapian-backports/ubuntu/ppa/precise] xapian-core 1.4.1-1.99precise (Rejected)
[19:35] <olly> a source package which builds both arch dependent and arch independent binary packages
[19:35] <sarnold> (back in precise days, the one that meant 'build once and use for all' may still have used i386?)
[19:35] <sarnold> aha
[19:36] <olly> not sure "build on X and use everywhere" is the best way to think of "all"
[19:37] <phako> https://launchpad.net/~yg-jensge/+archive/ubuntu/shotwell-unstable - it waits for libgexiv2-dev 0.10.4 which is also in that PPA - which I don't understand
[19:40] <sarnold> olly: heh, the debian policy doc is kind of all over the place on it :) no wonder I never understood it: " If all or any appears, that value must be the entire contents of the field" but six paragraphs later "Specifying any all indicates that the source package isn't dependent on any particular architecture."
[19:41] <sarnold> olly: thanks :)
[19:42] <olly> i suspect that this change at some point and the first reflects the old state of affairs
[19:42] <olly> changed
[19:42] <olly> *changed
[19:43] <sarnold> yeah
[19:43] <sarnold> that sounds about right
[19:43] <olly> indeed, in "Version 3.9.3.0" "Released February, 2012"
[19:43] <olly> https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt
[19:44] <olly> and precise is 12.04...
[19:44] <olly> but this worked in the previous upload
[19:45] <olly> well, i'll wait and see for now, but might try adjust that and reuploading later
[19:47] <sarnold> oh cool, I haven't seent his upgrading-checklist.txt before.
[19:48] <sarnold> pity it doesn't spell out whatever it was that it replaced :)
[20:00] <olly> fairly sure it used to be "any" for that case (so you couldn't tell as easily if such a source package would built arch all binary packages)
[20:01] <olly> i've filed a bug against policy
[21:10] <cjwatson> jgdx: that's https://bugs.launchpad.net/launchpad/+bug/1626739, we need to sort that out at our end I'm afraid
[21:10] <ubot5`> Ubuntu bug 1626739 in Launchpad itself "Snapcraft build failing in Yakkety for unauthenticated stage-packages" [Undecided,New]
[21:11] <cjwatson> olly: "any all" in a .dsc should be fine - give me a minute
[21:11] <jgdx> cjwatson, fine, thanks. Subscribed.
[21:11] <cjwatson> (you wouldn't see that in debian/control, but it's perfectly normal in .dsc files where the source builds a mixture of arch-dep and arch-indep packages)
[21:13] <cjwatson> olly: could you upload the .dsc somewhere for me?  this should definitely work
[21:15] <cjwatson> olly: never mind
[21:15] <cjwatson> olly: this is a super-confusing error message but it's actually because that same version is already in that PPA
[21:16] <cjwatson> olly: you must have uploaded the bitwise-exact same source package again I guess, which for some reason caused LP to go "I know, I'll just try to create any missing builds for that source package"
[21:16] <cjwatson> olly: it's weird that there wasn't an earlier and clearer rejection, but the "any all" thing is a red herring
[21:17] <cjwatson> phako: $ dpkg --compare-versions 0.10.4-0~jensge1~xenial4 ge 0.10.4 && echo yes || echo no
[21:17] <cjwatson> no
[21:18] <cjwatson> phako: ^- i.e. the version of libgexiv2-dev you have is not in fact >= 0.10.4 by Debian version comparison rules
[21:18] <cjwatson> phako: consider using 0.10.4-0jensge1~xenial4 instead (i.e. dropping the first ~)
[21:19] <cjwatson> iliv: out of curiosity, any reason you keep creating https://code.launchpad.net/~commandpromptinc/postgresql-93/+git/postgresql-snap afresh over and over?
[21:25] <phako> cjwatson: meh
[21:25] <phako> thanks
[21:25] <phako> now that you write that I remember falling in that trap some time ago
[21:34] <cjwatson> olly,sarnold: FYI the current policy text is correct and does not need to be amended regarding Architecture in debian/control, although the reason for the different specification is maybe a bit subtle.  I followed up to https://bugs.debian.org/845369 explaining why (should appear there shortly)
[21:34] <ubot5`> Debian bug 845369 in debian-policy "debian-policy: [5.6.8] Not fully updated for "any all"" [Minor,Open]
[21:35] <cjwatson> sarnold: and yes, the architecture-independent builder for Ubuntu changed from i386 to amd64 in vivid, though that's an implementation detail rather than anything that should be specified in policy
[22:26] <sarnold> cjwatson: thanks