/srv/irclogs.ubuntu.com/2016/11/22/#launchpad.txt

=== JanC is now known as Guest78373
=== JanC_ is now known as JanC
=== chihchun_afk is now known as chihchun
=== cpaelzer_ is now known as cpaelzer
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
freewgrant, cjwatson: hey there, some of you around?09:05
cjwatsonfree: what's up?11:45
=== chihchun is now known as chihchun_afk
freecjwatson: hey there11:48
freecjwatson: I pushed this MP for the txfixtures package (used by LP two, I guess): https://code.launchpad.net/~free.ekanayaka/txfixtures/sphinx-docs/+merge/31147211:49
freecjwatson: 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 rights11:49
cjwatsonI think it should be ~lazr-developers11:51
cjwatsonwould that suit you?11:52
freecjwatson: sure, thanks11:52
freecjwatson: 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 this11:53
cjwatsonfree: done, feel free to land your thing11:53
cjwatsonfree: hm, wgrant went through a big effort to reclaim PyPI access for a bunch of packages but maybe missed that one11:54
cjwatsonfree: Robert has generally been helpful there IIRC11:54
freecjwatson: cheers! cool, I'll get in touch with him. We're already in contact for other testing-related things11:55
=== chihchun_afk is now known as chihchun
cjwatsonfree: 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:57
freecjwatson: yeah we'll need that11:58
cjwatsonfree: 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 push11:58
freecjwatson: 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
cjwatsonah, good11:59
cjwatsonI still haven't had a chance to sort out the txlongpoll deployment issues we have :-/11:59
freecjwatson: yeah, iirc pbr was a problem for LP?12:00
cjwatsonpbr is a headache12:00
cjwatsondue to buildout12:00
freecjwatson: the two don't play nice together or what?12:00
cjwatsonbuildout doesn't like setup_requires12:00
freeah12:00
cjwatsonthe plan is to ditch buildout, but converting 12 years of build system complexity /o\12:01
freecjwatson: can't we teach buildout about setup_requires instead? or is that involved?12:01
cjwatsonappears pretty involved, and converting to modern buildout is nearly as big a change as converting to pip anyway12:02
freecjwatson: I see, makes sense12:02
cjwatsonso might as well convert to pip instead and be on the same tooling as the rest of the modern webdev space12:02
cjwatsonbut I keep inconsiderately having urgent new feature development dropped on me instead ;-)12:02
freecjwatson: :/12:03
freecjwatson: 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
cjwatsonwe mostly don't use packages12:04
freeyeah12:04
cjwatsonbut I agree that those parts that are in Debian for whatever reason generally seem to be fairly well-maintained12:04
sigmaviruscjwatson: heh, I know that feeling of inconsiderately having new features dropped on you13:37
* sigmavirus wishes he had free time to help improve launchpad's packaging13:38
=== chihchun is now known as chihchun_afk
jgdxhey, I'm getting NOPUBKEY when building https://code.launchpad.net/~jonas-drange/+snap/silo-2194 — anything I can do?\17:49
=== JanC_ is now known as JanC
phakohi - looking for help with a PPA that is in dependency wait which I don't understand19:15
ollyhi, 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 worked19:33
ollyand https://launchpad.net/ubuntu/+ppas lists precise as supported still19:33
sarnoldolly: 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
ollythe 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:34
ollya source package which builds both arch dependent and arch independent binary packages19:35
sarnold(back in precise days, the one that meant 'build once and use for all' may still have used i386?)19:35
sarnoldaha19:35
ollynot sure "build on X and use everywhere" is the best way to think of "all"19:36
phakohttps://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 understand19:37
sarnoldolly: 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:40
sarnoldolly: thanks :)19:41
ollyi suspect that this change at some point and the first reflects the old state of affairs19:42
ollychanged19:42
olly*changed19:42
sarnoldyeah19:43
sarnoldthat sounds about right19:43
ollyindeed, in "Version 3.9.3.0" "Released February, 2012"19:43
ollyhttps://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt19:43
ollyand precise is 12.04...19:44
ollybut this worked in the previous upload19:44
ollywell, i'll wait and see for now, but might try adjust that and reuploading later19:45
sarnoldoh cool, I haven't seent his upgrading-checklist.txt before.19:47
sarnoldpity it doesn't spell out whatever it was that it replaced :)19:48
ollyfairly 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:00
ollyi've filed a bug against policy20:01
cjwatsonjgdx: that's https://bugs.launchpad.net/launchpad/+bug/1626739, we need to sort that out at our end I'm afraid21:10
ubot5`Ubuntu bug 1626739 in Launchpad itself "Snapcraft build failing in Yakkety for unauthenticated stage-packages" [Undecided,New]21:10
cjwatsonolly: "any all" in a .dsc should be fine - give me a minute21:11
jgdxcjwatson, 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:11
cjwatsonolly: could you upload the .dsc somewhere for me?  this should definitely work21:13
cjwatsonolly: never mind21:15
cjwatsonolly: this is a super-confusing error message but it's actually because that same version is already in that PPA21:15
cjwatsonolly: 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
cjwatsonolly: it's weird that there wasn't an earlier and clearer rejection, but the "any all" thing is a red herring21:16
cjwatsonphako: $ dpkg --compare-versions 0.10.4-0~jensge1~xenial4 ge 0.10.4 && echo yes || echo no21:17
cjwatsonno21:17
cjwatsonphako: ^- i.e. the version of libgexiv2-dev you have is not in fact >= 0.10.4 by Debian version comparison rules21:18
cjwatsonphako: consider using 0.10.4-0jensge1~xenial4 instead (i.e. dropping the first ~)21:18
cjwatsoniliv: out of curiosity, any reason you keep creating https://code.launchpad.net/~commandpromptinc/postgresql-93/+git/postgresql-snap afresh over and over?21:19
phakocjwatson: meh21:25
phakothanks21:25
phakonow that you write that I remember falling in that trap some time ago21:25
cjwatsonolly,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:34
cjwatsonsarnold: 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 policy21:35
sarnoldcjwatson: thanks22:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!