[08:15] is that known that launchpad git repositories loose all tags? [08:17] wgrant: any idea? === caraka_ is now known as caraka [08:40] morphis: Can you provide an example? [08:40] Tags work fine in general. [08:53] wgrant: I pushed a bunch of tags to https://code.launchpad.net/~libhybris-maintainers/libhybris/+git/libhybris [08:53] but when I clone that repo again they are all lost [08:53] also cgit doesn't show any [08:53] https://git.launchpad.net/~libhybris-maintainers/libhybris/+git/libhybris/refs/ [08:59] hey there [08:59] does launchpad has records of who changed translation domains? [08:59] https://translations.launchpad.net/ubuntu-rtm/15.04/+source/unity8/+pots/unity8/+admin got changed to unity89280 [09:13] morphis: There's nothing magical about LP git pushes. Are you sure you pushed them in the first place? [09:14] Can you try pushing them again? [09:14] seb128: Any idea when? [09:14] wgrant: sure [09:16] wgrant, between 11-04 and 11-11 [09:16] wgrant: http://paste.ubuntu.com/13326374/ [09:16] wgrant: I pushed all tags now, before I pushed a single one [09:16] but that didn't help [09:17] morphis: Wrong URL [09:17] ~libhybris-maintainers/+git/libhybris vs ~libhybris-maintainers/libhybris/+git/libhybris [09:17] ah damn it [09:18] ahh [09:18] wgrant: sorry for the noise :) [09:19] 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] Makes the URL a bit simpler! [09:19] yeah [09:33] wgrant, do you have any log of those changes? [10:03] seb128: Hadn't changed between 2015-10-28 and today AFAICS [10:04] But all I have is web server request logs. [10:06] hum, k [11:31] 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] 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] Hi all! [16:11] If blueprint has 'Related bug' section filled, will all that bugs change status after blueprint will be implemented? [16:23] katyafervent_: No, they're linked for information but that doesn't imply particular workflows such as closing bugs [16:23] cjwatson: ok, thanks === su_v_ is now known as su_v [16:50] #1517510 \o/ [16:52] 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] That one is kind of me off my own bat ;-) [16:56] Though prompted by looking into what's needed for by-hash support [17:02] cjwatson: by-hash you mean that new thing in experimental's apt? [17:03] mapreri: Yeah [17:03] cool [17:38] cjwatson: he's putting find links into setup.py [17:38] cjwatson: which pip won't honour unless you also turn it on [17:42] lifeless: not in the code of his that I'm looking at he isn't :) [17:42] 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] 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] lifeless: find_links works fine in .pydistutils.cfg IME [17:43] 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] what we're doing right now in lp:turnip is: [17:44] cjwatson: ah, so I got looped in when he said he *was* using it in setup.py [17:44] so, confused wires [17:44] pip install --no-index --find-links=file://blah/ [17:44] and in env/.pydistutils.cfg: [17:44] [easy_install] [17:44] allow_hosts = '' [17:44] find_links = file://blah/ [17:45] ok sure [17:45] 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] -f on the pip cli is fine [17:46] its the find links metadata thats deprecated [17:46] right, cool - yeah, that makes sense [17:46] terrible having the same name [17:47] suspect wires got crossed between setup.py and setuptools [metadata] too [17:58] cjwatson: certainly somewhere :) [17:59] yay bazaar.launchpad.net has SHA-2 now [17:59] one down, three to go ... [18:22] woo :) [18:44] Can anyone give me a brief overview of what Upstream project means in LP? [18:56] clivejo: in what context? [18:57] the "upstream link" in ubuntu packages in the archive? [18:57] well https://launchpad.net/ubuntu/+source/kdeconnect-plasma is a KDE project and part of Kubuntu [18:57] yes [18:58] its project page is https://community.kde.org/KDEConnect [18:58] the "upstream link" is to link to a series in launchpad on a project in launchpad, if one exists [19:14] help [19:14] $ bzr push --overwrite lp:ubuntu/xenial/cloud-init [19:14] bzr: ERROR: Server sent an unexpected error: ('error', 'xmlrpclib.Fault', ', )">') [19:14] is this known issue ? [19:18] bzr branch lp:ubuntu/xenial/cloud-init [19:18] bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/xenial/cloud-init/". [19:19] not sure if that matters [19:19] dobey, well, i had added the --overwrite when it failed without it [19:19] which is probably what confused you. [19:19] but basically i want to create that thing [19:25] smoser: i don't think there are any UDD branches for xenial [19:25] cjwatson: ^^ is that right? [19:26] what am i supposed to do then ? use a team other than 'ubuntu' ? [19:26] yeah, I suspect the thing just didn't get run [19:27] the last few releases either I did it or more recently dimitri [19:28] there's a thread on ubuntu-devel about this [19:29] ubuntu isn't a team [19:29] the "team" that owns the branches is ~ubuntu-branches i think [19:32] ah, there's a new informative mail from colin [19:32] https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html [19:37] right [21:05] dobey: indeed, not right now [21:06] smoser: you can push to lp:~some-team-you-are-a-member-of/ubuntu/xenial/cloud-init/xenial [21:08] cjwatson, your're right, i can do that. and i suppose i can probably push to lp:~ubuntu-core-dev/.... [21:08] which gets me the same team that could push as before [21:14] 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] su_v: sorry, it'll have to wait, need to give children some attention [21:16] cjwatson: np [21:22] su_v: Done. [21:23] wgrant: thanks a lot [21:44] 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] FWIW, i386 and ppc64el built OK, and its now building on armhf [21:51] ki7mt: Have you retried the build? That looks like a temporary network issue. [21:54] wgrant, No sir, I have not. But I can do now. [21:55] wgrant, OK trying the rebuild now. [22:05] 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] It finished OK: https://launchpadlibrarian.net/226935530/buildlog_ubuntu-trusty-amd64.wsjtx_1.7.0-r6126-1~ki7mt~trusty_BUILDING.txt.gz [22:05] Thanks for the help.