Re: d-i repo at dillon

2018-06-15 Thread Holger Wansing
Hi,

Holger Wansing  wrote:
> 
> This morning, I performed a l10n-sync run with my latest modifications, and
> it went through so far. But when committing, I had to give username and 
> password to commit. What's the way to make it non-interactive?
> (I am somewhat confused: I gave "holgerw" as username and my password, but
> in the git log, it now reports username "D-I role". ???)

Ah, wait: will it just work, when the script is fired up by cron?
(Today, I started it manually via "sudo -u d-i".)


Holger

-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/




Re: d-i repo at dillon

2018-06-15 Thread Holger Wansing
Hi,

Cyril Brulebois  wrote:
> Hey,
> 
> Holger Wansing  (2018-06-15):
> > Some cron jobs still fail. Until the reasons have been investigated, I
> > have disabled those (3) jobs for now.
> > 
> > Then I started to test the l10n-sync script.
> > And it turns out, that there is some changed behaviour, when comparing
> > the old "svn st" lines against the new "git status -s -uno" lines.
> > The relevant diff is this:
> > 
> > 
> >   # Do not accept working on an unclean copy
> > - if $(svn st $DI_COPY/packages/po | grep -q "^C") ; then
> > -   error "$DI_COPY seems to contain some SVN conflict files"
> > + if $($git status -s -uno $DI_COPY/packages/po) ; then
> > +   error "$DI_COPY seems to contain some GIT conflict files"
> > +   error "in packages/po."
> > error "Please fix this before launching the script again"
> > exit 1
> > 
> > 
> > As it seems, the svn st line returns 0, if there _are_ changes in the
> > ../po dir while the new git status line returns 0, if there _are_no_
> > changes.
> > 
> > So I tried to change "if" into "if !" and that seems to work so far,
> > however I would like to receive a short confirmation from coding
> > people for this (/me having no coding skills so far).  It seems to
> > work at least.
> 
> That's exactly what's needed to reverse the check! :)
> 
> The original/final lines are a bit strange, though, instead of having:
> 
>   if $($git foo bar); then … fi
> 
> I suppose it should only be:
> 
>   if $git foo bar; then … fi

However, with this simplified variant it fails. So I left it as is for now.


This morning, I performed a l10n-sync run with my latest modifications, and
it went through so far. But when committing, I had to give username and 
password to commit. What's the way to make it non-interactive?
(I am somewhat confused: I gave "holgerw" as username and my password, but
in the git log, it now reports username "D-I role". ???)

Holger




-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/




Re: d-i repo at dillon

2018-06-15 Thread Christian PERRIER
(/me still reading this thread in case I can help at some point)

Quoting Cyril Brulebois (k...@debian.org):

> Also wondering if it makes sense to keep $git a variable instead of just
> using git everywhere. Maybe we used to require a specific $svn, but I
> won't be doing any archeology tonight.

Yes, that was the point. We had to use a different version of SVN,
than the one on the machine, in the old days, as l10n-sync was not
always running on a Debian stable machine (it ran on my own machine
for quite some time).

I agree thaat this is probably not so useful nowadays.





signature.asc
Description: PGP signature


Bug#899155: systemd-setup-machine-id leaving mount behind?

2018-06-15 Thread Hideki Yamane
Hi,

On Wed, 13 Jun 2018 15:16:00 +0200 Michael Biebl  wrote:
> Control: reassign -1 debootstrap
> Control: found -1 1.0.98
> 
> I'm going to reassign this bug report to debootstrap given it was
> introduced by the changes in 1.0.98, specifically [1]

 Now I've fixed it as
 https://salsa.debian.org/installer-team/debootstrap/merge_requests/11

 Could someone review (& merge) it, please?


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp



Re: debootstrap/1.0.102 appears to break debuerreotype autopkgtest

2018-06-15 Thread Hideki Yamane
Hi,

On Fri, 15 Jun 2018 07:57:21 +0900
Hideki Yamane  wrote:
> > > Instead of stretch simply defaulting to non-merged-usr, it's now
> > > _blacklisted_ from merged-usr, even if I explicitly specify
> > > "--merged-usr", right?  Is that the intended implementation here?
> 
>  Yes, since releases until stretch was already shipped without merged-usr,
>  so it should be. But loose restriction for test purpose is okay, IMO.

 Anyway, I've created a patch for it. Please review it
 https://salsa.debian.org/installer-team/debootstrap/merge_requests/12


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp



Re: d-i repo at dillon

2018-06-15 Thread Cyril Brulebois
Hey,

Holger Wansing  (2018-06-15):
> Some cron jobs still fail. Until the reasons have been investigated, I
> have disabled those (3) jobs for now.
> 
> Then I started to test the l10n-sync script.
> And it turns out, that there is some changed behaviour, when comparing
> the old "svn st" lines against the new "git status -s -uno" lines.
> The relevant diff is this:
> 
> 
>   # Do not accept working on an unclean copy
> - if $(svn st $DI_COPY/packages/po | grep -q "^C") ; then
> - error "$DI_COPY seems to contain some SVN conflict files"
> + if $($git status -s -uno $DI_COPY/packages/po) ; then
> + error "$DI_COPY seems to contain some GIT conflict files"
> + error "in packages/po."
> error "Please fix this before launching the script again"
> exit 1
> 
> 
> As it seems, the svn st line returns 0, if there _are_ changes in the
> ../po dir while the new git status line returns 0, if there _are_no_
> changes.
> 
> So I tried to change "if" into "if !" and that seems to work so far,
> however I would like to receive a short confirmation from coding
> people for this (/me having no coding skills so far).  It seems to
> work at least.

That's exactly what's needed to reverse the check! :)

The original/final lines are a bit strange, though, instead of having:

  if $($git foo bar); then … fi

I suppose it should only be:

  if $git foo bar; then … fi

Since $() is used to introduce a command substitution…

(e.g. echo "I'm working on $(hostname)")


Also wondering if it makes sense to keep $git a variable instead of just
using git everywhere. Maybe we used to require a specific $svn, but I
won't be doing any archeology tonight.

> > Don't bother regarding the daily-build-logs.git repository (or
> > whatever it's called), it has gotten corrupted at some point, which
> > I've never found time to investigate, fix, or nuke. It might make
> > sense to re-init it to an empty repository at some point, so that
> > further logs can be injected in it. Just mentioning that so that you
> > don't wonder too much, not trying to put it in your plate.
> 
> I cannot find such repo on salsa.
> Does this need to be created?

I'll handle this (repo+relevant jobs) when I have some spare time, don't
worry about those.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: d-i repo at dillon

2018-06-15 Thread Holger Wansing
Hi,

Cyril Brulebois  wrote:
> Hi,
> 
> Holger Wansing  (2018-06-14):
> > > I also changed some lines from svn to git (./daily-build-aggregator
> > > and ./daily-build-manager and ./daily-build-overview)
> > 
> > They fail, because on dillon, there is still a checkout of the svn
> > repo.  So dillon needs an git checkout there.
> > 
> > Ok for me to do that?
> 
> Sure thing, and thanks!

Done.
Some cron jobs still fail. Until the reasons have been investigated, I have
disabled those (3) jobs for now.

Then I started to test the l10n-sync script.
And it turns out, that there is some changed behaviour, when comparing
the old "svn st" lines against the new "git status -s -uno" lines.
The relevant diff is this:


  # Do not accept working on an unclean copy
- if $(svn st $DI_COPY/packages/po | grep -q "^C") ; then
-   error "$DI_COPY seems to contain some SVN conflict files"
+ if $($git status -s -uno $DI_COPY/packages/po) ; then
+   error "$DI_COPY seems to contain some GIT conflict files"
+   error "in packages/po."
error "Please fix this before launching the script again"
exit 1


As it seems, the svn st line returns 0, if there _are_ changes in the ../po dir
while the new git status line returns 0, if there _are_no_ changes.

So I tried to change "if" into "if !" and that seems to work so far, however
I would like to receive a short confirmation from coding people for this
(/me having no coding skills so far). 
It seems to work at least.

> Don't bother regarding the daily-build-logs.git repository (or whatever
> it's called), it has gotten corrupted at some point, which I've never
> found time to investigate, fix, or nuke. It might make sense to re-init
> it to an empty repository at some point, so that further logs can be
> injected in it. Just mentioning that so that you don't wonder too much,
> not trying to put it in your plate.

I cannot find such repo on salsa.
Does this need to be created?


Holger

-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/




Bug#731859: Happens to me on stretch

2018-06-15 Thread Hideki Yamane
Hi,

On Sun, 27 May 2018 21:19:20 +1000 Russell Stuart  
wrote:
> The attached script ("bug-731859-demo.sh") does a nested debootstrap
> run.  The outer run sets up a chroot for the  Debian suite passed on
> the command line (eg, "stretch"), then runs a nested debootstrap --
> variant=fakechroot in that environment.  For me both these fail:
> 
> ./bug-731859-demo.sh stretch
> ./bug-731859-demo.sh buster

 Thank you for providing script :)

 I've tested it and got failure. However, I could fix it a bit by adding
 "sudo mount -t proc none "${suite}.chroot/proc"" after debootstraping.
 Because debootstrap failure is caused by "systemd-machine-id-setup" in
 systemd.postinst, and can improve it with /proc mount.

 Russell, could you test it, please?


> They fail in different ways, but the root cause appears to be the same:
>  the ldconfig isn't working.  Note that both leave ldd.REAL and
> ldconfig.REAL lying around in the nested run.

 I'm not sure how to run nested chroot with success, it means
 "chroot "/tmp/${suite}" /bin/sh" line would still fail, though.


-- 
Hideki Yamane