[08:15] <seb128> wgrant, hey, did you see the translations discussion from yesterday?
[08:40] <wgrant> seb128: I did, was waiting for you to appear.
[08:40] <seb128> I'm here :-)
[08:40] <wgrant> seb128: Sharing with upstream only inhibits PO imports, not POT ones.
[08:41] <wgrant> Does that look plausible here?
[08:41] <seb128> yes
[08:41] <seb128> though why are the .pot not listed in the queue then?
[08:41] <wgrant> So the template looks updated?
[08:41] <seb128> yes, the template is fine
[08:41] <wgrant> They probably get purged after not very long.
[08:42] <seb128> my issue was that some strings translated in the fr.po in the tarball had been translated again in launchpad because the upstream translations didn't get imported
[08:42] <seb128> that's leading to incomplete translations and to translator wasting work
[08:42] <wgrant> Right.
[08:42] <wgrant> So, unsetting the packaging link would allow imports to happen again.
[08:42] <wgrant> PO imports, that is.
[08:42] <seb128> but...?
[08:43] <wgrant> But as Colin says, nothing stops someone from readding the packaging link, and the translations split involved in removing a packaging link is very buggy.
[08:43] <seb128> what would be a better solution?
[08:44] <seb128> fixing launchpad imports I guess? ;-)
[08:44] <seb128> ideally upstream git could be mirrored in git and the translation sharing could import the po from there
[08:44] <wgrant> Right, the ideal solution is to not make weird decisions when designing Launchpad Translations.
[08:44] <wgrant> But that's a bit difficult.
[08:44] <seb128> well the "share with trunk" worked as long as the imports were updated
[08:45] <seb128> but the git to bzr import has limitations
[08:45] <wgrant> seb128: What's the issue with the import?
[08:45] <seb128> nautilus, gedit, etc use git submodules
[08:45] <wgrant> The bzr import, that is.
[08:45] <wgrant> Oh, I was looking at the wrong project.
[08:45] <wgrant> Right.
[08:45] <wgrant> Also, submodules, really? Ew.
[08:46] <seb128> https://git.gnome.org/browse/nautilus/tree/.gitmodules
[08:46] <seb128> but yeah
[08:46] <wgrant> O_o
[08:46] <wgrant> why
[08:46] <seb128> because maintaing a lib and a stable interface is too much work for them I guess :p
[08:47] <seb128> but anyway that's where we stand
[08:47] <wgrant> Heh
[08:47] <seb128> and the bzr importer doesn't like those
[08:47] <wgrant> No.
[08:47] <seb128> so I guess the only thing we can do now is to unset the sharing
[08:48] <seb128> until somebody works on launchpad translations to make it do things differently
[08:48] <seb128> or use git to git rather than git to bzr imports
[08:48] <wgrant> Hmmm.
[08:48] <wgrant> Another option is to make the upstream project look like it doesn't have any current templates.
[08:48] <wgrant> Heh, we'll see if anybody's working on Launchpad soon.
[08:49] <seb128> how do you make a project looks like it hasn't a current template?
[08:49] <seb128> also would that lead to import the .po from the source uploads?
[08:49] <wgrant> seb128: Easiest way is to make it actually not have a current template.
[08:50]  * wgrant tries to find the template.
[08:50] <seb128> it shouldn't have one
[08:50] <seb128> upstream GNOME doesn't have the pot in git iirc
[08:50] <seb128> http://bazaar.launchpad.net/~vcs-imports/nautilus/master-git/files/head:/po/
[08:50] <seb128> not pot
[08:50] <wgrant> Right, but it still exists in LP.
[08:50] <wgrant> https://translations.launchpad.net/ubuntu/xenial/+source/nautilus/+sharing-details
[08:51]  * wgrant tries to find a list of sticks to poke it with.
[08:51] <seb128> the "view upstream" leads to a "lost something"
[08:51] <seb128> https://translations.launchpad.net/nautilus/main/+pots/nautilus
[08:51] <wgrant> hm, wfm.
[08:52] <wgrant> And it's active, so I'm surprised you can't see it.
[08:52] <seb128>  ID OOPS-5d65cff6f90d6f1e9450847214db4acc
[08:52] <seb128> is what I got
[08:52] <seb128> error ID OOPS-93cca20415ad262e5ce4c90907bade35 on retry
[08:53] <seb128> no, I just get errors
[08:54] <wgrant> Oh, because it's set to external.
[08:54] <wgrant> So that template is invisible to mortals anyway.
[08:54] <wgrant> So we can totally deactivate it, and the only visible change will be that Ubuntu will think it's not sharing any more.
[08:54] <wgrant> Do you have a list of affected projects?
[08:56] <seb128> no
[08:56] <seb128> I know of nautilus and gedit
[08:56] <seb128> do we have a list of outdated imports somewhere?
[08:56] <wgrant> I could generate one, but it's very large.
[08:57] <seb128> if we restrict to main?
[08:57] <wgrant> Let me see what I can find.
[09:00] <seb128> but it's likely a good part of GNOME
[09:00] <seb128> evince gedit gnome-control-center nautilus
[09:02] <wgrant> Do you know that gedit's translations are broken?
[09:02] <wgrant> I don't see an upstream template on LP.
[09:04] <wgrant> Hmm, the nautilus upstream template was apparently updated from an LP export in February.
[09:04] <wgrant> I was querying for all sharing templates where the upstream hadn't been updated this year, and it didn't show up.
[09:05] <wgrant> seb128: http://paste.ubuntu.com/13853627/ is all the packages with upstream templates that haven't been updated since September. 12 of those were updated earlier in the year.
[09:06] <seb128> wgrant, gedit translation, I assume so because https://translations.launchpad.net/ubuntu/xenial/+source/gedit/+imports doesn't list imported .pos
[09:06] <wgrant> grumble
[09:07]  * wgrant digs deeper
[09:07] <wgrant> seb128: Hum, that lists four for me?
[09:07] <seb128> right, only fails
[09:07] <wgrant> The rest where probably just pruned a month after they were successfully imported.
[09:07] <seb128> not success
[09:07] <wgrant> The fact that there were any at all means it's not affected by this problem.
[09:07] <seb128> but gedit was uploaded on 11-24
[09:07] <seb128> so it's less than a month
[09:08] <wgrant>     RosettaImportStatus.IMPORTED: timedelta(days=3),
[09:08] <wgrant> seriously...
[09:08]  * wgrant multiplies them all by 20
[09:08] <seb128> thanks
[09:08] <seb128> ok, so I guess it's only nautilus
[09:09] <seb128> from your pastebin list
[09:09] <wgrant> I've deactivated its template, so the next upload should get POs.
[09:10] <wgrant> https://translations.launchpad.net/ubuntu/xenial/+source/nautilus/+sharing-details oh no :(
[09:10] <wgrant> no sharing :'(
[09:13] <seb128> didn't work out then?
[09:13] <wgrant> Nope, should all be good.
[09:13] <wgrant> Sharing is disabled.
[09:15] <seb128> k, great
[09:15] <seb128> wgrant, thanks!
[09:17] <wgrant> seb128: Let me know if you run into anything vaguely related.
[09:17] <wgrant> Preferably before my memories of this fade again :P
[09:17] <seb128> ok :-)
[12:14] <Laney> cjwatson: Does OOPS-9e4ded7ce5520af0a9a53412c8e33cae interest you? Getting this while trying to change the default repository for a project.
[12:24] <Laney> (Filed #1524316)
[12:27] <cjwatson> GitDefaultConflict: The default repository for 'geonames' is already set to ~larsu/geonames/+git/geonames-1.
[12:28] <cjwatson> Laney: Could you update the bug to describe how exactly you were trying to change it?
[12:29] <cjwatson> (Looks like via /geonames/+configure-code, but best to have that in the bug and not just the OOPS)
[12:29] <Laney> oh, right, ok
[12:29] <Laney> there
[13:55] <DJJeff> keep getting alot of these 404's
[13:56] <DJJeff> The requested URL /user/repo/ubuntu/dists/mydist/InRelease was not found on this server.
[13:56] <DJJeff> I know its safe to ignore these 404's
[13:56] <DJJeff> but why do they happen
[13:57] <DJJeff> it only happens on a select few like for example /webupd8team/somepackage/ubuntu/dists/utopic
[14:08] <DJJeff> I guess the proper way would be to return 304 Not Modified
[14:11] <dobey> why would a 304 be proper for something that doesn't exist?
[14:12] <dobey> it happens because you've added a PPA which doesn't have packages for your ubuntu release. utopic is also EOL
[14:15] <cjwatson> DJJeff: Because those bits of those repositories haven't been published since we added InRelease support.
[14:16] <cjwatson> 404 is fine; apt handles that and falls back to Release/Release.gpg.
[14:20] <DJJeff> http://i.imgur.com/fKDU94M.png
[14:20] <DJJeff> not all of them 404
[14:20] <DJJeff> just some
[14:21] <DJJeff> I used wireshark to watch when I ran sudo apt-update
[14:21] <DJJeff> some actually do return 304
[14:23] <DJJeff> I try to avoid using PPA's I only use them when the packages are not in the distro repo
[14:23] <DJJeff> or the ones in the distro repo are old or broken
[14:24] <DJJeff> one big problem many run into including myself is when distros get added
[14:24] <DJJeff> for example I run 16.04 Xenial and in the repo its still at utopic or vivid
[14:25] <DJJeff> and if xenial gets added there is no good way to check all the PPAs to update to the latest supported distro
[14:25] <cjwatson> DJJeff: 304 is for those that have been published since the addition of InRelease support and which your apt already has identical copies of
[14:25] <cjwatson> DJJeff: this is a non-issue in practice though, you're only noticing it because you're paying too much attention :)
[14:26] <DJJeff> ppa's are super slow as it is
[14:26] <DJJeff> cause there are no mirrors etc
[14:27] <cjwatson> you can use "devel" for PPAs if you really want, which is linked to the latest published series in that archive with any packages in it - but the gotcha there is that that really is *any* packages, even if that PPA has a collection of lots of different things and the thing you're interested in hasn't been updated, so it's not necessarily always appropriate
[14:28] <DJJeff> doing apt-get update for me takes almost 45 seconds :-(
[14:33] <seb128> can we do MPs from git branches pushed to personnal user space?
[14:35] <cjwatson> yes
[14:35] <seb128> I do see a button on e.g https://code.launchpad.net/~seb128/geonames/+git/tweaks
[14:35] <seb128> *don't*
[14:35] <cjwatson> seb128: see e.g. https://code.launchpad.net/~cjwatson/turnip/+git/turnip/+merge/279906
[14:35] <cjwatson> seb128: go to the branch you want to merge, not the repository
[14:35] <seb128> oh, right
[14:36] <seb128> thanks cjwatson
[14:38] <DJJeff> ok switching my distro mirrors using https://launchpad.net/ubuntu/+archivemirrors
[14:38] <DJJeff> now its down to 18 seconds
[14:39] <DJJeff> sed -i 's/ca.archive.ubuntu.com/mirror.it.ubc.ca/g' /etc/apt/sources.list
[14:39] <DJJeff> hehe
[15:08] <dobey> DJJeff: if you don't care about source packages too, you can disable any deb-src lines, and it will speed things up a bit. though, i have several PPAs, and update only takes about 4.5 seconds for me.
[15:11] <DJJeff> latency right now is around 60ms to ppa.launchpad.net (184.168.221.104)
[15:11] <DJJeff> http://paste.ubuntu.com/13860678/
[15:13] <dobey> unless apt is broken and not using a single connection, latency shouldn't matter unless it's up near a second or more
[15:15] <DJJeff> 15% packet loss from 212.118.240.116
[15:15] <DJJeff> lol
[15:15] <DJJeff> United Kingdom Square Pnap-lon Backbone Net
[15:18] <DJJeff> ya I am in canada so thats like 18 hops for me to launchpad
[15:20] <dobey> i'm in the us, so it's not like i'm sitting in the data center either :)
[15:21] <cjwatson> DJJeff: traceroutes are more meaningful if you haven't typoed the target hostname
[15:21] <cjwatson> launchpad != launchpage
[15:21] <DJJeff> oh shit lol
[15:21] <dobey> lol, also that
[15:22] <DJJeff> hold up
[15:23] <DJJeff> issues are more on my end X_X
[15:23] <DJJeff> http://i.imgur.com/gN9f0lf.png
[18:42] <karni> Hi guys. Got a git on Lp related question. I created a project, and can successfully push to lp:~user/project, but not lp:project - I'm the project owner, but git push lp master (where lp is remote on launchpad) just sits there and does nothing.
[18:43] <karni> Question being - any pointers how to get that going? -v just prints "Pushing to git+ssh:// ..." and nothing more
[18:45] <karni> I'll be around bit later, in case there's an answer on what may be wrong with my setup.
[21:57] <cjwatson> karni: Real examples would help.