morphis | is that known that launchpad git repositories loose all tags? | 08:15 |
---|---|---|
morphis | wgrant: any idea? | 08:17 |
=== caraka_ is now known as caraka | ||
wgrant | morphis: Can you provide an example? | 08:40 |
wgrant | Tags work fine in general. | 08:40 |
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:53 |
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 | 08:59 |
wgrant | morphis: There's nothing magical about LP git pushes. Are you sure you pushed them in the first place? | 09:13 |
wgrant | Can you try pushing them again? | 09:14 |
wgrant | seb128: Any idea when? | 09:14 |
morphis | wgrant: sure | 09:14 |
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:16 |
wgrant | morphis: Wrong URL | 09:17 |
wgrant | ~libhybris-maintainers/+git/libhybris vs ~libhybris-maintainers/libhybris/+git/libhybris | 09:17 |
morphis | ah damn it | 09:17 |
morphis | ahh | 09:18 |
morphis | wgrant: sorry for the noise :) | 09:18 |
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:19 |
seb128 | wgrant, do you have any log of those changes? | 09:33 |
wgrant | seb128: Hadn't changed between 2015-10-28 and today AFAICS | 10:03 |
wgrant | But all I have is web server request logs. | 10:04 |
seb128 | hum, k | 10:06 |
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:31 |
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 :-) | 11:33 |
katyafervent_ | Hi all! | 16:10 |
katyafervent_ | If blueprint has 'Related bug' section filled, will all that bugs change status after blueprint will be implemented? | 16:11 |
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:23 |
=== su_v_ is now known as su_v | ||
mapreri | #1517510 \o/ | 16:50 |
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:52 |
cjwatson | That one is kind of me off my own bat ;-) | 16:55 |
cjwatson | Though prompted by looking into what's needed for by-hash support | 16:56 |
mapreri | cjwatson: by-hash you mean that new thing in experimental's apt? | 17:02 |
cjwatson | mapreri: Yeah | 17:03 |
mapreri | cool | 17:03 |
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:38 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
cjwatson | suspect wires got crossed between setup.py and setuptools [metadata] too | 17:47 |
lifeless | cjwatson: certainly somewhere :) | 17:58 |
cjwatson | yay bazaar.launchpad.net has SHA-2 now | 17:59 |
cjwatson | one down, three to go ... | 17:59 |
sarnold | woo :) | 18:22 |
clivejo | Can anyone give me a brief overview of what Upstream project means in LP? | 18:44 |
dobey | clivejo: in what context? | 18:56 |
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:57 |
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 | 18:58 |
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:14 |
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:18 |
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:19 |
dobey | smoser: i don't think there are any UDD branches for xenial | 19:25 |
dobey | cjwatson: ^^ is that right? | 19:25 |
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:26 |
mgz | the last few releases either I did it or more recently dimitri | 19:27 |
mgz | there's a thread on ubuntu-devel about this | 19:28 |
dobey | ubuntu isn't a team | 19:29 |
dobey | the "team" that owns the branches is ~ubuntu-branches i think | 19:29 |
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:32 |
dobey | right | 19:37 |
cjwatson | dobey: indeed, not right now | 21:05 |
cjwatson | smoser: you can push to lp:~some-team-you-are-a-member-of/ubuntu/xenial/cloud-init/xenial | 21:06 |
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:08 |
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:14 |
cjwatson | su_v: sorry, it'll have to wait, need to give children some attention | 21:15 |
su_v | cjwatson: np | 21:16 |
wgrant | su_v: Done. | 21:22 |
su_v | wgrant: thanks a lot | 21:23 |
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:44 |
ki7mt | FWIW, i386 and ppc64el built OK, and its now building on armhf | 21:46 |
wgrant | ki7mt: Have you retried the build? That looks like a temporary network issue. | 21:51 |
ki7mt | wgrant, No sir, I have not. But I can do now. | 21:54 |
ki7mt | wgrant, OK trying the rebuild now. | 21:55 |
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. | 22:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!