[08:15] <morphis> is that known that launchpad git repositories loose all tags?
[08:17] <morphis> wgrant: any idea?
[08:40] <wgrant> morphis: Can you provide an example?
[08:40] <wgrant> Tags work fine in general.
[08:53] <morphis> wgrant: I pushed a bunch of tags to https://code.launchpad.net/~libhybris-maintainers/libhybris/+git/libhybris
[08:53] <morphis> but when I clone that repo again they are all lost
[08:53] <morphis> also cgit doesn't show any
[08:53] <morphis> https://git.launchpad.net/~libhybris-maintainers/libhybris/+git/libhybris/refs/
[08:59] <seb128> hey there
[08:59] <seb128> does launchpad has records of who changed translation domains?
[08:59] <seb128> https://translations.launchpad.net/ubuntu-rtm/15.04/+source/unity8/+pots/unity8/+admin got changed to unity89280
[09:13] <wgrant> morphis: There's nothing magical about LP git pushes. Are you sure you pushed them in the first place?
[09:14] <wgrant> Can you try pushing them again?
[09:14] <wgrant> seb128: Any idea when?
[09:14] <morphis> wgrant: sure
[09:16] <seb128> wgrant, between 11-04 and 11-11
[09:16] <morphis> wgrant: http://paste.ubuntu.com/13326374/
[09:16] <morphis> wgrant: I pushed all tags now, before I pushed a single one
[09:16] <morphis> but that didn't help
[09:17] <wgrant> morphis: Wrong URL
[09:17] <wgrant> ~libhybris-maintainers/+git/libhybris vs ~libhybris-maintainers/libhybris/+git/libhybris
[09:17] <morphis> ah damn it
[09:18] <morphis> ahh
[09:18] <morphis> wgrant: sorry for the noise :)
[09:19] <wgrant> morphis: Should that repo be https://git.launchpad.net/libhybris? If so, set it in the git section on https://code.launchpad.net/libhybris/+configure-code
[09:19] <wgrant> Makes the URL a bit simpler!
[09:19] <morphis> yeah
[09:33] <seb128> wgrant, do you have any log of those changes?
[10:03] <wgrant> seb128: Hadn't changed between 2015-10-28 and today AFAICS
[10:04] <wgrant> But all I have is web server request logs.
[10:06] <seb128> hum, k
[11:31] <cjwatson> lifeless: so step 1 there seems like a non-trivial amount of work to set up (bearing in mind that this is being compared against "no work").  can you explain why "local index plus --index-url=foo" is better than "--no-index --find-links=foo", at least for a smallish directory where it doesn't take long for pip to work things out on the fly?
[11:33] <cjwatson> lifeless: blr does have some problem with --find-links that we haven't sorted out yet, but it is working fine for other deployments; https://github.com/wolever/pip2pi seems to be a plausible thing for building a local index but it does seem like more work than not doing it :-)
[16:10] <katyafervent_> Hi all!
[16:11] <katyafervent_> If blueprint has 'Related bug' section filled, will all that bugs change status after blueprint will be implemented?
[16:23] <cjwatson> katyafervent_: No, they're linked for information but that doesn't imply particular workflows such as closing bugs
[16:23] <katyafervent_> cjwatson: ok, thanks
[16:50] <mapreri> #1517510 \o/
[16:52] <mapreri> seems like that as soon as canonical chose to invest in lp once again, suddenly a whole lot of new feature has come to ubuntu (or neighborhood) :)
[16:55] <cjwatson> That one is kind of me off my own bat ;-)
[16:56] <cjwatson> Though prompted by looking into what's needed for by-hash support
[17:02] <mapreri> cjwatson: by-hash you mean that new thing in experimental's apt?
[17:03] <cjwatson> mapreri: Yeah
[17:03] <mapreri> cool
[17:38] <lifeless> cjwatson: he's putting find links into setup.py
[17:38] <lifeless> cjwatson: which pip won't honour unless you also turn it on
[17:42] <cjwatson> lifeless: not in the code of his that I'm looking at he isn't :)
[17:42] <lifeless> cjwatson: secondly IIRC setuptools doesn't have a cli find-links equiv, so when dealing with setup_requires you need to take the replacement index approach
[17:42] <cjwatson> lifeless: he's using it on the pip install command line, and also in .pydistutils.cfg just in case setuptools accidentally gets invoked
[17:43] <cjwatson> lifeless: find_links works fine in .pydistutils.cfg IME
[17:43] <cjwatson> lifeless: we're using it successfully in another project.  haven't yet worked out why blr's superficially similar case is failing (because I haven't yet reproduced it myself, because something else is failing first ...)
[17:44] <cjwatson> what we're doing right now in lp:turnip is:
[17:44] <lifeless> cjwatson: ah, so I got looped in when he said he *was* using it in setup.py
[17:44] <lifeless> so, confused wires
[17:44] <cjwatson> pip install --no-index --find-links=file://blah/
[17:44] <cjwatson> and in env/.pydistutils.cfg:
[17:44] <cjwatson> [easy_install]
[17:44] <cjwatson> allow_hosts = ''
[17:44] <cjwatson> find_links = file://blah/
[17:45] <lifeless> ok sure
[17:45] <cjwatson> so I'm happy to switch to index-url if there's a concrete reason it's better, but the "build local index" step seems a bit more complicated than just letting pip.index work it out
[17:45] <lifeless> -f on the pip cli is fine
[17:46] <lifeless> its the find links metadata thats deprecated
[17:46] <cjwatson> right, cool - yeah, that makes sense
[17:46] <lifeless> terrible having the same name
[17:47] <cjwatson> suspect wires got crossed between setup.py and setuptools [metadata] too
[17:58] <lifeless> cjwatson: certainly somewhere :)
[17:59] <cjwatson> yay bazaar.launchpad.net has SHA-2 now
[17:59] <cjwatson> one down, three to go ...
[18:22] <sarnold> woo :)
[18:44] <clivejo> Can anyone give me a brief overview of what Upstream project means in LP?
[18:56] <dobey> clivejo: in what context?
[18:57] <dobey> the "upstream link" in ubuntu packages in the archive?
[18:57] <clivejo> well https://launchpad.net/ubuntu/+source/kdeconnect-plasma is a KDE project and part of Kubuntu
[18:57] <dobey> yes
[18:58] <clivejo> its project page is https://community.kde.org/KDEConnect
[18:58] <dobey> the "upstream link" is to link to a series in launchpad on a project in launchpad, if one exists
[19:14] <smoser> help
[19:14] <smoser> $ bzr push --overwrite lp:ubuntu/xenial/cloud-init
[19:14] <smoser> bzr: ERROR: Server sent an unexpected error: ('error', 'xmlrpclib.Fault', '<Fault -1: "Unexpected Zope exception: TypeError: (\'Could not adapt\', <SuiteSourcePackage ubuntu/xenial/cloud-init>, <InterfaceClass lp.code.interfaces.branchtarget.IBranchTarget>)">')
[19:14] <smoser> is this  known issue ?
[19:18] <dobey> bzr branch lp:ubuntu/xenial/cloud-init
[19:18] <dobey> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/xenial/cloud-init/".
[19:19] <dobey> not sure if that matters
[19:19] <smoser> dobey, well, i had added the --overwrite when it failed without it
[19:19] <smoser> which is probably what confused you.
[19:19] <smoser> but basically i want to create that thing
[19:25] <dobey> smoser: i don't think there are any UDD branches for xenial
[19:25] <dobey> cjwatson: ^^ is that right?
[19:26] <smoser> what am i supposed to do then ? use a team other than 'ubuntu' ?
[19:26] <mgz> yeah, I suspect the thing just didn't get run
[19:27] <mgz> the last few releases either I did it or more recently dimitri
[19:28] <mgz> there's a thread on ubuntu-devel about this
[19:29] <dobey> ubuntu isn't a team
[19:29] <dobey> the "team" that owns the branches is ~ubuntu-branches i think
[19:32] <mgz> ah, there's a new informative mail from colin
[19:32] <mgz> https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html
[19:37] <dobey> right
[21:05] <cjwatson> dobey: indeed, not right now
[21:06] <cjwatson> smoser: you can push to lp:~some-team-you-are-a-member-of/ubuntu/xenial/cloud-init/xenial
[21:08] <smoser> cjwatson, your're right, i can do that. and i suppose i can probably push to lp:~ubuntu-core-dev/....
[21:08] <smoser> which gets me the same team that could push as before
[21:14] <su_v> cjwatson: would you mind running your despam script again on https://answers.launchpad.net/inkscape ? (currently 10 messages from 9 suspended and 1 active spam account) - thx
[21:15] <cjwatson> su_v: sorry, it'll have to wait, need to give children some attention
[21:16] <su_v> cjwatson: np
[21:22] <wgrant> su_v: Done.
[21:23] <su_v> wgrant: thanks a lot
[21:44] <ki7mt> Hello, can someone have a look at this build error log and  help me determine what's gone wrong? It was building before, now it's failing amd64: https://launchpadlibrarian.net/226933083/buildlog_ubuntu-trusty-amd64.wsjtx_1.7.0-r6126-1~ki7mt~trusty_BUILDING.txt.gz
[21:46] <ki7mt> FWIW, i386 and ppc64el built OK, and its now building on armhf
[21:51] <wgrant> ki7mt: Have you retried the build? That looks like a temporary network issue.
[21:54] <ki7mt> wgrant, No sir, I have not. But I can do now.
[21:55] <ki7mt> wgrant, OK trying the rebuild now.
[22:05] <ki7mt> wgrant, It appears that was the problem, as the build is in the Cmake phase, which I don't think it would have made it that far without the required builds deps.
[22:05] <ki7mt> It finished OK: https://launchpadlibrarian.net/226935530/buildlog_ubuntu-trusty-amd64.wsjtx_1.7.0-r6126-1~ki7mt~trusty_BUILDING.txt.gz
[22:05] <ki7mt> Thanks for the help.