Bug #16864

lint_po regression: does not skip files in ./tmp/ anymore

Added by intrigeri 2019-07-09 08:18:00 . Updated 2019-09-18 16:51:08 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
tails:bugfix/16864-improve-lint_po, jenkins-tools:bugfix/16864-improve-lint_po
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Translation Platform
Deliverable for:
309

Description

The shell version of check_po rightfully skipped files under ./tmp/ (find -wholename ./tmp -prune). This is useful because some developers, in particular release managers, have PO files in there that we don’t want to check. The new Python version has lost this property.

No big emergency but it would be sweet if that was fixed before next time we go through our release process (which typically triggers this problem).


Subtasks


History

#1 Updated by intrigeri 2019-08-30 16:17:06

  • Target version changed from Tails_3.16 to Tails_3.17
  • Affected tool set to Translation Platform

#2 Updated by intrigeri 2019-09-12 09:16:06

  • Assignee set to intrigeri

This looks straightforward enough to fix and the impact of the problem is really annoying, so I’ll give it a try.

#3 Updated by intrigeri 2019-09-12 10:11:12

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|18aca66e8ac5bc61b309e0043b1892a499539e75.

#4 Updated by intrigeri 2019-09-12 10:12:07

  • Status changed from In Progress to Needs Validation
  • Assignee changed from intrigeri to hefee
  • Feature Branch set to tails:bugfix/16864-improve-lint_po, jenkins-tools:bugfix/16864-improve-lint_po

Hi @hefee, can you please review these branches? Thanks in advance!

#5 Updated by intrigeri 2019-09-12 14:25:35

  • Target version changed from Tails_3.17 to Tails_4.0

#6 Updated by hefee 2019-09-16 16:26:26

  • Status changed from Needs Validation to In Progress
  • Assignee changed from hefee to intrigeri

I’m fine with tails.git:79a7fc00ca88e4f3a9e40b5c9aef3d789d736844

But I have nearly no experience about how to have submodules properly, so either merge yourself or you need to guide me:D

That’s what I think I need to do:

cd submodules/jenkins-tools
git checkout master # ??? correct branch
git merge bugfix/16864-improve-lint_po
git push origin master # ??? correct branch
cd ../..
git checkout stable
git merge bugfix/16864-improve-lint_po
git push origin stable

I think you mentioned that every branch needs to be updated, when a submodule is updated…

#7 Updated by intrigeri 2019-09-17 10:28:46

  • Status changed from In Progress to Needs Validation
  • Assignee changed from intrigeri to hefee

> I’m fine with tails.git:79a7fc00ca88e4f3a9e40b5c9aef3d789d736844

OK!

> But I have nearly no experience about how to have submodules properly, so either merge yourself or you need to guide me:D

I’m happy to help :)

> That’s what I think I need to do:

First, check out master in tails.git and run git submodule update --init. Then:

> cd submodules/jenkins-tools
> git checkout master # ??? correct branch

Yes + git merge origin/master: your local master branch might be outdated.
Then, to solve your doubts, you can first check that the current HEAD of submodules/jenkins-tools is the same commit as origin/master.

> git merge bugfix/16864-improve-lint_po
> git push origin master # ??? correct branch

Yes.

> cd ../..
> git checkout stable

Here, you’ll want to checkout master instead.

> git merge bugfix/16864-improve-lint_po

Yes.

> git push origin stable

s/stable/master/

> I think you mentioned that every branch needs to be updated, when a submodule is updated…

Indeed, once you’ve followed the above steps, master will have code updates that stable & devel haven’t, which is not ideal.
So once you’ve done that, merge master into stable, then stable into devel, and push both stable and devel.

Regarding “every branch needs to be updated, when a submodule is updated”: It Depends™ on what change we’re talking about. In this case, I don’t think there’s any need to update every branch. Updating our main branches (master, stable, and devel) is sufficient.

#8 Updated by hefee 2019-09-17 12:34:37

  • Status changed from Needs Validation to In Progress
  • Assignee changed from hefee to intrigeri

intrigeri wrote:
> First, check out master in tails.git and run git submodule update --init.

Okay done.

Then:
>
> > cd submodules/jenkins-tools
> > git checkout master # ??? correct branch
>
> Yes + git merge origin/master: your local master branch might be outdated.
> Then, to solve your doubts, you can first check that the current HEAD of submodules/jenkins-tools is the same commit as origin/master.

done.

>
> > git merge bugfix/16864-improve-lint_po
> > git push origin master # ??? correct branch

Should I use git merge --no-ff for the submodule too? I can’t push to jenkins-tools, maybe I have no permission, as I should not have access to Jenkins?

% torsocks git push gitolite@d53ykjpeekuikgoq.onion:jenkins-tools.git master
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "de_DE.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
FATAL: W any jenkins-tools hefee DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

> Indeed, once you’ve followed the above steps, master will have code updates that stable & devel haven’t, which is not ideal.
> So once you’ve done that, merge master into stable, then stable into devel, and push both stable and devel.

any rules, how to solve merge conflicts of po files in devel? It is only about the header part of po files not the translation itself.

> Regarding “every branch needs to be updated, when a submodule is updated”: It Depends™ on what change we’re talking about. In this case, I don’t think there’s any need to update every branch. Updating our main branches (master, stable, and devel) is sufficient.

okay.

#9 Updated by intrigeri 2019-09-18 07:48:25

  • Status changed from In Progress to Needs Validation
  • Assignee changed from intrigeri to hefee

Hi @hefee!

> Should I use git merge --no-ff for the submodule too?

It’s mostly a matter of taste. I personally prefer having explicit merge commits so we record the information of who merged what and when exactly the new commits made it into the master branch. Others might disagree :)

> I can’t push to jenkins-tools, maybe I have no permission, as I should not have access to Jenkins?

> % torsocks git push gitolite@d53ykjpeekuikgoq.onion:jenkins-tools.git master

You’re trying to push to a repository that does not exist.

In tails.git, .gitmodules points to https://git-tails.immerda.ch/jenkins-tools which should be translated, in your environment, to tails@git.tails.boum.org:jenkins-tools (see insteadOf in https://tails.boum.org/contribute/git/), to which you have write access AFAICT.

So please try to push to the default origin remote, without trying to be fancy :))

> any rules, how to solve merge conflicts of po files in devel? It is only about the header part of po files not the translation itself.

Since it’s the header only: whatever works.

#10 Updated by hefee 2019-09-18 09:21:11

  • Status changed from Needs Validation to Fix committed
  • Assignee changed from hefee to intrigeri

intrigeri wrote:
> > Should I use git merge --no-ff for the submodule too?
>
> It’s mostly a matter of taste. I personally prefer having explicit merge commits so we record the information of who merged what and when exactly the new commits made it into the master branch. Others might disagree :)

Okay.

> > I can’t push to jenkins-tools, maybe I have no permission, as I should not have access to Jenkins?
>
> > % torsocks git push gitolite@d53ykjpeekuikgoq.onion:jenkins-tools.git master
>
> You’re trying to push to a repository that does not exist.
>
> In tails.git, .gitmodules points to https://git-tails.immerda.ch/jenkins-tools which should be translated, in your environment, to tails@git.tails.boum.org:jenkins-tools (see insteadOf in https://tails.boum.org/contribute/git/), to which you have write access AFAICT.
>
> So please try to push to the default origin remote, without trying to be fancy :))

I thought the onion address is a replacement for the git.tails.boum.org. I now use

[url "tails@git.tails.boum.org:"]
   pushInsteadOf = https://git-tails.immerda.ch/

and I could now push ;D

> > any rules, how to solve merge conflicts of po files in devel? It is only about the header part of po files not the translation itself.
>
> Since it’s the header only: whatever works.

;D

Should we close this as resolved.

#11 Updated by intrigeri 2019-09-18 09:37:16

  • Status changed from Fix committed to Needs Validation
  • Assignee changed from intrigeri to hefee

Hi,

> I thought the onion address is a replacement for the git.tails.boum.org.

No, it’s a replacement for git.puppet.tails.boum.org. I understand it can be confusing :/

> and I could now push ;D

:)

> Should we close this as resolved.

Yes, once you’ve followed the next steps (for example, it seems you have pushed none of our main branches yet).

But wait, maybe you did push, but to the incorrect remote for tails.git?

See https://tails.boum.org/contribute/git/#main-repo.

#12 Updated by Anonymous 2019-09-18 13:36:10

  • Status changed from Needs Validation to Fix committed
  • % Done changed from 0 to 100

Applied in changeset commit:tails|20936d69d15bc7691078b8c19a66c7db9db977da.

#13 Updated by hefee 2019-09-18 15:15:49

  • Status changed from Fix committed to Resolved
  • Assignee deleted (hefee)

intrigeri wrote:

@intrigeri: hopefully now everything is in order.

> > I thought the onion address is a replacement for the git.tails.boum.org.
>
> No, it’s a replacement for git.puppet.tails.boum.org. I understand it can be confusing :/

äh wht? I pushed to tails@git.tails.boum.org:puppet-tails and the commits were accepted. Than I used
tails@git.tails.boum.org:tails - but this is not the correct way to push tails.git? there for I need the onion address?

This seems like a big mystery for me atm;)

Okay I used the onion address to push tails.git and now I see the normal messages about jenkins etc. and also redmine is catching the new commits.

> Yes, once you’ve followed the next steps (for example, it seems you have pushed none of our main branches yet).
>
> But wait, maybe you did push, but to the incorrect remote for tails.git?

I seems like this.

> See https://tails.boum.org/contribute/git/#main-repo.

https://git-tails.immerda.ch/tails and gitolite@d53ykjpeekuikgoq.onion:tails should connect to the same server wired.

#14 Updated by intrigeri 2019-09-18 16:51:08

> intrigeri: hopefully now everything is in order.

@hefee, yes, it looks perfect!

> äh wht? I pushed to tails@git.tails.boum.org:puppet-tails and the commits were accepted.

That’s a read-only mirror: https://tails.boum.org/contribute/git/#index4h3

> Than I used tails@git.tails.boum.org:tails - but this is not the correct way to push tails.git?

That’s a read-only mirror too. Anything you push there will be overwritten on next push.

> there for I need the onion address?

Yes.

> This seems like a big mystery for me atm;)

As much as I’d love to explain it all, I suspect it would be a waste of my time since all this complexity will go away with the switch to GitLab.
If you disagree, just let me know and I’ll explain :)

> Okay I used the onion address to push tails.git and now I see the normal messages about jenkins etc. and also redmine is catching the new commits.

Yes!!!

> https://git-tails.immerda.ch/tails and gitolite@d53ykjpeekuikgoq.onion:tails should connect to the same server wired.

They are on different servers, hosted by different people. The first one is a read-only mirror that folks who don’t have access to the canonical repo can use to track the official repo. The second one is the canonical repo, to which you have RW+ access. The second one pushes —mirror to the first one when updated.