Processed: Re: Bug#690210: Bug 690210 : debootstrap : debian-ports support

2018-05-13 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tag 690210 - pending
Bug #690210 [debootstrap] debootstrap: please add support for debian-ports
Removed tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
690210: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690210
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#690210: Bug 690210 : debootstrap : debian-ports support

2018-05-13 Thread Philipp Kern
tag 690210 - pending
thanks

On 4/20/18 12:16 AM, Raphael Hertzog wrote:
> On Wed, 18 Apr 2018, Hideki Yamane wrote:
>> control: tags -1 +pending
> 
> It's not "pending" because it's not yet pushed to the official git
> repository. I don't know if you just forgot to push or if willingly kept
> it out for now...

Unmarking pending for this reason.

Kind regards and thanks
Philipp Kern



Bug#896071: debootstrap fails to retrive Release file over https

2018-05-13 Thread Philipp Kern
Hideki,

On 4/24/18 3:29 PM, Raphael Hertzog wrote:
> On Mon, 23 Apr 2018, Hideki Yamane wrote:
>> On Sun, 22 Apr 2018 09:40:54 +1000
>> David Margerison  wrote:
  "$@" is extracted as '' and wget tries to fetch it and fails,
  then returns 1.
>>>
>>> Regarding the proposed fix, in general using $@ without quotes is fragile.
>>
>>  Most of the case, quotes is better. But in this case, "$@" is extracted like
 wget '' '' '' https://deb.debian.org/debian/dist/unstable/InRelease
>>  Then, it outputs
http://: Invalid host name.
http://: Invalid host name.
http://: Invalid host name.
>>  and returns 1.
> 
> I agree with David that using $@ without quotes is not a good idea.
> What you want is to not pass empty arguments to wgetprogress. So you should
> likely drop the quotes around the first 3 parameters on this line:
> if wgetprogress "$CHECKCERTIF" "$CERTIFICATE" "$PRIVATEKEY" 
> -O "$dest" "$from"; then
> 
> I'm suggesting only the first 3 since those are the variables that can be
> empty. And we want to keep the quote on "$dest" to be able to use path
> containing spaces (which you likely lost with your fix).
> 
> But even here it's not perfect since we loose the possibility to handle
> arguments containing spaces in the first 3 parameters. A complete fix would
> involve setting up the argument list manually:
> 
> set -- -O "$dest" "$from"
> if [ -n "$PRIVATEKEY" ]; then
> set -- "$PRIVATEKEY" "$@"
> fi
> if [ -n "$CERTIFICATE" ]; then
> set -- "$CERTIFICATE" "$@"
> fi
> if [ -n "$CHECKCERTIF" ]; then
> set -- "$CHECKCERTIF" "$@"
> fi
> if wgetprogress "$@"; then
> [...]
> 
> Here we should be safe even if those 3 variables do contain spaces.

any new about incorporating Raphael's suggestion? There's still a grave
bug opened against debootstrap right now (on a version that is in testing).

Kind regards and thanks
Philipp Kern



Bug#886016: debootstrap: add support for Acquire-By-Hash for downloading indices

2018-05-13 Thread Philipp Kern
tag 886016 + pending
thanks

Hi,

On 2/21/18 2:10 PM, Julien Cristau wrote:
> On 02/15/2018 11:31 AM, Philipp Kern wrote:
>> On 2018-01-01 17:01, Julien Cristau wrote:
>>> following patch looks at the Acquire-By-Hash field in (In)Release to get
>>> Packages from the by-hash directory if available and avoid races.  I
>>> thought we already had a bug about this, but can't find one now.
>>
>> So as discussed on IRC this patch sadly does not work as-is. It fetches
>> the Packages file from the by-hash location but then proceeds to fetch
>> the packages themselves from a by-hash location as well and fails when
>> those fetches all 404 (because pool doesn't have a by-hash subdirectory
>> and that would also not work well on a traditional filesystem if not
>> sharded by, say, hash prefix).
>>
>> Instead it would need to restrict itself to only attempt metadata
>> fetches by-hash by passing some sort of flag around.
>>
> I have an updated patch at home that seems to work, will try and
> remember to push/send it tonight.

I rebased and re-tested Julien's patch set and pushed the commits to master.

Kind regards and thanks
Philipp Kern



signature.asc
Description: OpenPGP digital signature


Processed: Re: Bug#886016: debootstrap: add support for Acquire-By-Hash for downloading indices

2018-05-13 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tag 886016 + pending
Bug #886016 [debootstrap] debootstrap: add support for Acquire-By-Hash for 
downloading indices
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
886016: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886016
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Re: installation-guide is marked for autoremoval from testing

2018-05-13 Thread Holger Wansing

Am Sonntag, 13. Mai 2018 schrieb Cyril Brulebois:
> Heya,
> 
> Holger Wansing  (2018-05-13):
> > However, there is much more work to do here, "svn" and "alioth" is
> > often mentioned in the manual.
> 
> That's fair. But maybe we should track this as a different RC bug (just
> to make extra sure this doesn't go unnoticed/unfixed until the release),
> which could be closed later on?

ACK.
 
> > And:
> > maybe the workflow of xml-based translations is affected by git migration?
> > Tracking the up-to-date-status of those files is handled with svn revision
> > numbers, which are no longer available now IMHO.
> > How to deal with this?
> > Is it worse to overwork the relevant scripts, to make them work with git
> > hashes, or should we just drop xml-based translations altogether now?
> > Most translations have switched to po already, from the up-to-date
> > languages only Czech is left on xml.
> 
> I don't have stats handy, but if there's only Czech around, I think time
> would be better spent moving it from xml to po?

Yes, that's my impression too.

> I suppose this is a
> transition that had been underway for a while and was never completed?

Yes, maybe.

> I'm not sure whether we should work on porting any other xml-based
> translations if there's nobody active on them?

Generally correct.
eu and pt_br could stay as they are now, for possible future use.
 
> > > > However, that would be an upload for Buster (there's "Bump release
> > > > name to buster" in the changelog).
> > > 
> > > I'm not sure why that would be an issue? The manual documents the buster
> > > installation process (which shouldn't have changed too much?), but the
> > > upload targets unstable as usual?
> > 
> > I remembered some trouble with the debian-refcard, where the
> > publication on the debian.org website was affected, because the
> > website directly uses the latest uploaded package version.
> 
> I think we've had fixes on the website generation framework to handle
> that problem exactly. If we spot issues (again), we should work on
> fixing them, rather than being limited in our upload capacity on the
> installation guide side, I think?

Yes, right.
 
> > But the installation-guide is handled differently here apparently, so
> > that's most probably not a problem here...
> 
> We'll see. :)

Ok  :-)
So let's go for an upload.
Samuel, maybe?


Holger

Holger

-- 
Sent from my Jolla phone
http://www.jolla.com/

Re: installation-guide is marked for autoremoval from testing

2018-05-13 Thread Cyril Brulebois
Heya,

Holger Wansing  (2018-05-13):
> However, there is much more work to do here, "svn" and "alioth" is
> often mentioned in the manual.

That's fair. But maybe we should track this as a different RC bug (just
to make extra sure this doesn't go unnoticed/unfixed until the release),
which could be closed later on?

Steve, do we have to have installation-guide in testing to build Alpha
or RC images?

> And:
> maybe the workflow of xml-based translations is affected by git migration?
> Tracking the up-to-date-status of those files is handled with svn revision
> numbers, which are no longer available now IMHO.
> How to deal with this?
> Is it worse to overwork the relevant scripts, to make them work with git
> hashes, or should we just drop xml-based translations altogether now?
> Most translations have switched to po already, from the up-to-date
> languages only Czech is left on xml.

I don't have stats handy, but if there's only Czech around, I think time
would be better spent moving it from xml to po? I suppose this is a
transition that had been underway for a while and was never completed?
I'm not sure whether we should work on porting any other xml-based
translations if there's nobody active on them?

> Christian, any opinion on this?

… but I'm definitely happy to hear more about this from Christian or
others.

Again, I'm so sorry this is getting kind of forced onto us, but I don't
think it would have been reasonable to take responsibility for
maintaining an svn server forever anyway. :(

> > > However, that would be an upload for Buster (there's "Bump release
> > > name to buster" in the changelog).
> > 
> > I'm not sure why that would be an issue? The manual documents the buster
> > installation process (which shouldn't have changed too much?), but the
> > upload targets unstable as usual?
> 
> I remembered some trouble with the debian-refcard, where the
> publication on the debian.org website was affected, because the
> website directly uses the latest uploaded package version.

I think we've had fixes on the website generation framework to handle
that problem exactly. If we spot issues (again), we should work on
fixing them, rather than being limited in our upload capacity on the
installation guide side, I think?

> But the installation-guide is handled differently here apparently, so
> that's most probably not a problem here...

We'll see. :)


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


signature.asc
Description: PGP signature


Re: installation-guide is marked for autoremoval from testing

2018-05-13 Thread Holger Wansing
Hi,

Cyril Brulebois  wrote:
> Hi,
> 
> Holger Wansing  (2018-05-10):
> > Debian testing autoremoval watch  wrote:
> > > installation-guide 20170614 is marked for autoremoval from testing on 
> > > 2018-05-31
> > > 
> > > It is affected by these RC bugs:
> > > 897529: installation-guide: FTBFS
> > 
> > This is because of the "ID xxx-yyy already defined" validation errors",
> > which has already been reported in 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880210
> > and which was already fixed in svn repo (oh, this is now git).
> > 
> > Maybe we should do an upload to get this fixed in the archive?
> 
> That would be a good idea (along with an extra commit to update Vcs-* to
> salsa, see my latest reply in the salsa thread).

Done.

However, there is much more work to do here, "svn" and "alioth" is often 
mentioned in the manual.
That would need some more time (at least for me).

And:
maybe the workflow of xml-based translations is affected by git migration?
Tracking the up-to-date-status of those files is handled with svn revision
numbers, which are no longer available now IMHO.
How to deal with this?
Is it worse to overwork the relevant scripts, to make them work with git
hashes, or should we just drop xml-based translations altogether now?
Most translations have switched to po already, from the up-to-date
languages only Czech is left on xml.

Christian, any opinion on this?

> > However, that would be an upload for Buster (there's "Bump release
> > name to buster" in the changelog).
> 
> I'm not sure why that would be an issue? The manual documents the buster
> installation process (which shouldn't have changed too much?), but the
> upload targets unstable as usual?

I remembered some trouble with the debian-refcard, where the publication
on the debian.org website was affected, because the website directly uses
the latest uploaded package version.
But the installation-guide is handled differently here apparently, so
that's most probably not a problem here...


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: [Reportbug-maint] Bug#873852: No shortcut for debian-installer

2018-05-13 Thread Holger Wansing

Hi,

Am Sonntag, 13. Mai 2018 schrieb Sandro Tosi:
> On Sun, May 13, 2018 at 11:51 AM Cyril Brulebois  wrote:
> 
> > Hi,
> 
> > Sandro Tosi  (2018-05-13):
> > > Hey debian-boot@ ! do you have any thoughts on this suggestions? do you
> > > feel the current rate of bug reports is impacted by the issue Eduard
> > > reported? what would you like to see here? thanks!
> 
> > Why isn't “Joe user” checking what the installation guide recommends?
> 
> >https://www.debian.org/releases/stable/amd64/ch05s04.html#submit-bug
> 
> fully agree with you here. Unless Eduard wants to add something, i'm
> probably going to close this report as wontfix.

Maybe it would be worse to add some short hint on this onto 
one of the help pages in the installer? 
F9 already has some info related to installation problems,
and has some space left...

BTW: F10 (copyright and warranties) does not work here on
qemu, no reaction. Is that already known?
 

Holger

-- 
Sent from my Jolla phone
http://www.jolla.com/

Re: Salsa

2018-05-13 Thread Steve McIntyre
On Sun, May 13, 2018 at 05:14:49PM +0100, Steve McIntyre wrote:
>On Sun, May 13, 2018 at 06:05:53PM +0200, Cyril Brulebois wrote:
>
>>Can't we just go for that instead, which would have the benefit of
>>matching the source package name?
>>  https://salsa.debian.org/installer-team/installation-guide
>
>Good call, yes. That makes much more sense. I'll happily move it if
>you like, unless you'd rather...?

I've done it, as agreed in irc.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html



Re: [Reportbug-maint] Bug#873852: No shortcut for debian-installer

2018-05-13 Thread Sandro Tosi
On Sun, May 13, 2018 at 11:51 AM Cyril Brulebois  wrote:

> Hi,

> Sandro Tosi  (2018-05-13):
> > Hey debian-boot@ ! do you have any thoughts on this suggestions? do you
> > feel the current rate of bug reports is impacted by the issue Eduard
> > reported? what would you like to see here? thanks!

> Why isn't “Joe user” checking what the installation guide recommends?

>https://www.debian.org/releases/stable/amd64/ch05s04.html#submit-bug

fully agree with you here. Unless Eduard wants to add something, i'm
probably going to close this report as wontfix.

Thanks!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi



Re: Salsa

2018-05-13 Thread Steve McIntyre
On Sun, May 13, 2018 at 06:05:53PM +0200, Cyril Brulebois wrote:
>Hey,
>
>Looking at names…
>
>Steve McIntyre  (2018-05-09):
>> Yup. In fact, at this point I declare the conversion to be as done as
>> it's going to be. I've just imported these test repos into the
>> installer-team area:
>> 
>>  https://salsa.debian.org/installer-team/d-i
>
>I guess this is fair, even if people might confuse that with the
>(real) debian-installer package/repository.

ACK.

>>  https://salsa.debian.org/installer-team/di-i-manual
>
>This seems to be named this way, now?
>  https://salsa.debian.org/installer-team/d-i-manual

Gah, yes - the name I wrote there was a typo!

>Can't we just go for that instead, which would have the benefit of
>matching the source package name?
>  https://salsa.debian.org/installer-team/installation-guide

Good call, yes. That makes much more sense. I'll happily move it if
you like, unless you'd rather...?

>>  https://salsa.debian.org/installer-team/di-i-archive
>
>Apparently named https://salsa.debian.org/installer-team/d-i-archive
>now, which looks fine if we keep the d-i name for the old svn top-level
>(see first point).

Again, same typo. Late night cut and paste... :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer



Re: installation-guide is marked for autoremoval from testing

2018-05-13 Thread Cyril Brulebois
Hi,

Holger Wansing  (2018-05-10):
> Debian testing autoremoval watch  wrote:
> > installation-guide 20170614 is marked for autoremoval from testing on 
> > 2018-05-31
> > 
> > It is affected by these RC bugs:
> > 897529: installation-guide: FTBFS
> 
> This is because of the "ID xxx-yyy already defined" validation errors",
> which has already been reported in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880210
> and which was already fixed in svn repo (oh, this is now git).
> 
> Maybe we should do an upload to get this fixed in the archive?

That would be a good idea (along with an extra commit to update Vcs-* to
salsa, see my latest reply in the salsa thread).

> However, that would be an upload for Buster (there's "Bump release
> name to buster" in the changelog).

I'm not sure why that would be an issue? The manual documents the buster
installation process (which shouldn't have changed too much?), but the
upload targets unstable as usual?


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


signature.asc
Description: PGP signature


Re: Salsa

2018-05-13 Thread Cyril Brulebois
Hey,

Looking at names…

Steve McIntyre  (2018-05-09):
> Yup. In fact, at this point I declare the conversion to be as done as
> it's going to be. I've just imported these test repos into the
> installer-team area:
> 
>  https://salsa.debian.org/installer-team/d-i

I guess this is fair, even if people might confuse that with the
(real) debian-installer package/repository.

>  https://salsa.debian.org/installer-team/di-i-manual

This seems to be named this way, now?
  https://salsa.debian.org/installer-team/d-i-manual

Can't we just go for that instead, which would have the benefit of
matching the source package name?
  https://salsa.debian.org/installer-team/installation-guide

>  https://salsa.debian.org/installer-team/di-i-archive

Apparently named https://salsa.debian.org/installer-team/d-i-archive
now, which looks fine if we keep the d-i name for the old svn top-level
(see first point).


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


signature.asc
Description: PGP signature


Re: [Reportbug-maint] Bug#873852: No shortcut for debian-installer

2018-05-13 Thread Cyril Brulebois
Hi,

Sandro Tosi  (2018-05-13):
> Hey debian-boot@ ! do you have any thoughts on this suggestions? do you
> feel the current rate of bug reports is impacted by the issue Eduard
> reported? what would you like to see here? thanks!

Why isn't “Joe user” checking what the installation guide recommends?

  https://www.debian.org/releases/stable/amd64/ch05s04.html#submit-bug


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


signature.asc
Description: PGP signature


Re: [Reportbug-maint] Bug#873852: No shortcut for debian-installer

2018-05-13 Thread Sandro Tosi
> I tried to report a bug in the debian installer with reportbug. Doing
> this with "Joe user attitude", not looking for the actual virtual
> package name and other resources. I tried:

> reportbug install
> reportbug installer
> reportbug (and then selecting other and looking for debian-installer in
the list)

> None of those pretty obvious methods leads me to do what I want, file a
> bug against debian-installer.

> I think this is a UX problem and should be improved in future.

Hey debian-boot@ ! do you have any thoughts on this suggestions? do you
feel the current rate of bug reports is impacted by the issue Eduard
reported? what would you like to see here? thanks!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi