Re: Salsa

[Christian PERRIER]

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

> > I think I will have to leave the Salsa -boot project to you and the
> > rest of the team going forwards.
> 
> Thanks for having shown interest and having set up a project so much in
> advance, and sorry again for not having jumped on that train at the
> time…


On my side, well, I'm watching the Salsa train from the platform and I
have to admit that I'm not active at all in the Salsa move.

While I very well understand reasons behind Alioth's shutdown, it
breaks so many established workflows of mine that, since the beginning,
I decided that I would be a follower on that topic. I never wanted to
enter arguments on -devel about this, but I think this move is way too
disruptive, with regards of the *real* situation of manpower in Debian.

If I can adapt my workflows to changes needed by the move to Salsa,
then I'm fine with it, that's mostly how I  follow things.

As of now, I know that l10n workflows *will* be affected, that's obvious.



signature.asc
Description: PGP signature

[Travel question] 1000000+ unique high-ranking visitors from the US, AU, CA, UK per month to your site

[info]

Thank you for contacting us.
We will be in touch ASAP!

Re: Salsa

[Cyril Brulebois]

Hi,

Chris Boot  (2018-04-24):
> I didn't receive much feedback from the -boot team since I created the
> Salsa project and did the initial member import, but I also didn't
> remind people about it after those first few emails.

Yes, sorry for not having been more proactive on this topic. :(

> FWIW I have been using GitLab both personally and at work very
> successfully for quite a while now with my generally Git-centric
> workflow. I have no recent experience with conversions from other VCS,
> and I do understand some people's concerns about whether GitLab is the
> best fit for Debian, but I strongly believe that whilst it may require
> a bit of a mindset readjustment it's the best thing out there for us.

That's very fine. :) I was more wondering about tips and tricks for the
actual migration; but apparently Steve is happy to help with setting
things up with packages, so I would only have to deal with adapting the
l10n commit robot for new URLs.

While I'm on that topic, short brain dump: I've created it already
(di-l10n-guest), pointing to a mail address of mine for the time being;
and I've requested access to the group.

> I also must admit that I haven't had a huge amount of time lately to
> work on Debian things, much to my regret. From now on for a while I
> will have even *less* time, but with no regret now as my first child
> was born yesterday! (Mother and child doing very well, thanks, and
> email to -private will come shortly!)

Congratz. :)

> I think I will have to leave the Salsa -boot project to you and the
> rest of the team going forwards.

Thanks for having shown interest and having set up a project so much in
advance, and sorry again for not having jumped on that train at the
time…


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


signature.asc
Description: PGP signature

Re: Salsa

[Chris Boot]

On 24/04/18 02:29, Cyril Brulebois wrote:
> Hi Chris,
> 
> Chris Boot  (2018-01-22):
>> I think it would be helpful to start using Salsa for some of our repos.
>>
>> I would like to move my personal busybox work-in-progress repo to Salsa;
>> I know nothing prevents me from doing that but it feels like everything
>> would be more joined-up if the main busybox repo was also in Salsa and
>> in a debian-boot team/group.
>>
>> Does anyone have any objection if I create a d-i/boot team on Salsa?
>> What should it be called? Should its membership just be copied from the
>> Alioth team? Alternatively, would it be preferable to use the "Debian"
>> group given we have such a large membership anyway?
>>
>> axhn: any objection to moving busybox into Salsa?
> 
> Do you have any feedback regarding your salsa attempts?
> 
> Clock's ticking and it would be nice to migrate soon, so any gathered
> experience is welcome.

Hi Cyril,

I didn't receive much feedback from the -boot team since I created the
Salsa project and did the initial member import, but I also didn't
remind people about it after those first few emails.

FWIW I have been using GitLab both personally and at work very
successfully for quite a while now with my generally Git-centric
workflow. I have no recent experience with conversions from other VCS,
and I do understand some people's concerns about whether GitLab is the
best fit for Debian, but I strongly believe that whilst it may require a
bit of a mindset readjustment it's the best thing out there for us.

I also must admit that I haven't had a huge amount of time lately to
work on Debian things, much to my regret. From now on for a while I will
have even *less* time, but with no regret now as my first child was born
yesterday! (Mother and child doing very well, thanks, and email to
-private will come shortly!)

I think I will have to leave the Salsa -boot project to you and the rest
of the team going forwards.

Cheers,
Chris

-- 
Chris Boot
bo...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#896826: partman-auto: Wrong minimal disk size calculation when using expert_recipe and lvm partitions

[Garinot Pierre]

Package: partman-auto
Version: partman-auto
Severity: important
Tags: d-i

Dear Maintainer,

   * What led up to the situation?
Trying to pressed the debian installer for automatic partitionning.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Used these preseed rules:


d-i partman-auto/disk string /dev/sda
d-i partman-auto/method string lvm
d-i partman-auto/expert_recipe string \
arcadia ::\
30 50 100 ext4\
$primary{ } $bootable{ }  \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 }  \
mountpoint{ /boot }   \
. \
64 1024 300% linux-swap   \
method{ swap } format{ }  \
. \
1980 3000 -1 ext4 \
$defaultignore{ } \
$primary{ }   \
method{ lvm } \
device{ /dev/sda }\
vg_name{ system } \
. \
60 100 150 ext4   \
$lvmok{ } in_vg{ system } lv_name{ root } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 }  \
mountpoint{ / }   \
. \
750 1000 15000 ext4   \
$lvmok{ } in_vg{ system } lv_name{ usr }  \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 }  \
mountpoint{ /usr }\
. \
10 20 30 ext4 \
$lvmok{ } in_vg{ system } lv_name{ home } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 }  \
mountpoint{ /home }   \
. \
10 20 30 ext4 \
$lvmok{ } in_vg{ system } lv_name{ roothome } \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 }  \
mountpoint{ /root }   \
. \
20 30 50 ext4 \
$lvmok{ } in_vg{ system } lv_name{ tmp }  \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 }  \
mountpoint{ /tmp }\
. \
800 1000 1 ext4   \
$lvmok{ } in_vg{ system } lv_name{ var }  \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 }  \
mountpoint{ /var }\
. \
250 500 1000 ext4 \
$lvmok{ } in_vg{ system } lv_name{ log }  \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 }  \
mountpoint{ /var/log }\
. \
10 20 1 ext4  \
$lvmok{ } in_vg{ system } lv_name{ local }\
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 }  \
mountpoint{ /usr/local }  \
. \
10 20 30 ext4 \
$lvmok{ } in_vg{ system } lv_name{ srv }  \
method{ format } format{ }\
use_filesystem{ } filesystem{ ext4 }  \
mountpoint{ /srv }\
.


   * What was the outcome of this action?
Partitionning fails with the following message in syslog:
"partman-auto: Available disk space (2147) too small for expert recipe(3994);
skipping"

   * What outcome did you expect instead?
Partitionning successfull, with LVM setup correctly.
The computed size should be /boot + swap + VG(system) 

Bug#840372: debootstrap: second-stage fails within systemd-nspawn: proc already mounted

[Raphael Hertzog]

On Tue, 24 Apr 2018, Hideki Yamane wrote:
> On Mon, 23 Apr 2018 15:59:31 +0200
> Raphael Hertzog  wrote:
> > I'm saying this because the following lines are left untouched and are
> > called in all cases:
> > umount_on_exit /proc
> > umount_on_exit /proc/bus/usb
> > 
> > (They are in the context of your unified diff)
> > 
> > They should only be called if debootstrap is mounting /proc by itself.
> 
>  Okay, I want to treat it as separate issue (this code is not touched
>  until now), deal with it after next upload.

I don't think that it makes sense to fix one problem to introduce another
one at the same place. debootstrap was broken because the wrapper did
already mount /proc. Now the wrapper will be broken because debootstrap
has already umounted /proc and the wrapper will fail to be able to umount
it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

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

[Raphael Hertzog]

On Mon, 23 Apr 2018, Hideki Yamane wrote:
> Hi,
> 
> 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.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#840372: debootstrap: second-stage fails within systemd-nspawn: proc already mounted

[Hideki Yamane]

On Mon, 23 Apr 2018 15:59:31 +0200
Raphael Hertzog  wrote:
> I'm saying this because the following lines are left untouched and are
> called in all cases:
> umount_on_exit /proc
> umount_on_exit /proc/bus/usb
> 
> (They are in the context of your unified diff)
> 
> They should only be called if debootstrap is mounting /proc by itself.

 Okay, I want to treat it as separate issue (this code is not touched
 until now), deal with it after next upload.


-- 
Regards,

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

Bug#896809: installation-reports: "Select a language" -> DE, but install EN

[Ralf]

Package: installation-reports
Severity: important

Dear Maintainer,

I have selected German as the installation language. 
However, the installation process will continue in English.
The finished Debian installation is also in English.

-- Package-specific info:

Boot method: network
Image version: 
https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/firmware.Lamobo_R1.img.gz
Date: 

Machine: Lamobo R1
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20180423-00:04"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux BananaPi 4.15.0-2-armmp #1 SMP Debian 4.15.11-1 (2018-03-20) 
armv7l GNU/Linux
lsmod: Module  Size  Used by
lsmod: dm_mod118784  0
lsmod: dax20480  1 dm_mod
lsmod: md_mod139264  0
lsmod: jfs   184320  0
lsmod: btrfs1212416  0
lsmod: xor16384  1 btrfs
lsmod: zstd_decompress69632  1 btrfs
lsmod: zstd_compress 167936  1 btrfs
lsmod: xxhash 20480  2 zstd_compress,zstd_decompress
lsmod: zlib_deflate   28672  1 btrfs
lsmod: raid6_pq   98304  1 btrfs
lsmod: vfat   20480  0
lsmod: fat69632  1 vfat
lsmod: ext4  593920  2
lsmod: crc16  16384  1 ext4
lsmod: mbcache16384  1 ext4
lsmod: jbd2  102400  1 ext4
lsmod: crc32c_generic 16384  3
lsmod: fscrypto   24576  1 ext4
lsmod: ecb16384  0
lsmod: usb_storage53248  0
lsmod: sd_mod 45056  0
lsmod: ahci_sunxi 16384  0
lsmod: libahci_platform   16384  1 ahci_sunxi
lsmod: libahci32768  2 ahci_sunxi,libahci_platform
lsmod: libata204800  3 ahci_sunxi,libahci_platform,libahci
lsmod: scsi_mod  196608  3 sd_mod,usb_storage,libata
lsmod: b53_mdio   16384  0
lsmod: b53_common 32768  1 b53_mdio
lsmod: dsa_core   49152  7 b53_mdio,b53_common
lsmod: bridge143360  1 dsa_core
lsmod: stp16384  1 bridge
lsmod: llc16384  2 bridge,stp
lsmod: devlink40960  1 dsa_core
lsmod: axp20x_usb_power   16384  0
lsmod: industrialio   57344  1 axp20x_usb_power
lsmod: axp20x_regulator   36864  0
lsmod: dwmac_sunxi16384  0
lsmod: stmmac_platform20480  1 dwmac_sunxi
lsmod: ohci_platform  16384  0
lsmod: stmmac102400  2 stmmac_platform,dwmac_sunxi
lsmod: sunxi  20480  0
lsmod: i2c_mv64xxx20480  0
lsmod: ohci_hcd   45056  1 ohci_platform
lsmod: sunxi_wdt  16384  0
lsmod: ehci_platform  16384  0
lsmod: phy_generic16384  1 sunxi
lsmod: musb_hdrc 122880  1 sunxi
lsmod: ehci_hcd   77824  1 ehci_platform
lsmod: udc_core   36864  1 musb_hdrc
lsmod: usbcore   204800  6 
usb_storage,ehci_hcd,musb_hdrc,ohci_hcd,ehci_platform,ohci_platform
lsmod: phy_sun4i_usb  20480  1 sunxi
lsmod: sunxi_mmc  20480  0
lsmod: usb_common 16384  5 
udc_core,sunxi,musb_hdrc,phy_sun4i_usb,usbcore
lsmod: leds_gpio  16384  0
df: Filesystem   1K-blocks  Used Available Use% Mounted on
df: none10246084102376   0% /run
df: devtmpfs492360 0492360   0% /dev
df: /dev/mmcblk0p2 6323528675088   5307500  11% /target
df: /dev/mmcblk0p1  240972 26527202004  12% /target/boot
df: /dev/mmcblk0p2 6323528675088   5307500  11% /dev/.static/dev
df: devtmpfs492360 0492360   0% /target/dev
free:  total   used   free sharedbuffers cached
free: Mem:   1024600 776248 248352 

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

[Hideki Yamane]

On Tue, 24 Apr 2018 14:07:30 +0200
Raphael Hertzog  wrote:
> Honestly, I'd prefer not to diverge from Debian and use plain http as well
> so that we limit the risk of regression related to https support.
> 
> In particular since our main http.kali.org host redirects to many other
> mirrors whose certificates are not under our control. We are not monitoring
> that all the certificates are valid.

 I understand it, then remain unchanged.

-- 
Regards,

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

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

[Raphael Hertzog]

Hi,

On Tue, 24 Apr 2018, Hideki Yamane wrote:
>  I'll revert below your commit since this regression fix also solve it.
> 
> > commit c1c20ed48e83fe9d4f3512c524f7734d4e1469ac
> > Author: Raphaël Hertzog 
> > Date:   Thu Apr 12 12:18:29 2018 +0200
> > 
> > Do not use HTTPS for Kali bootstrap script
> 
>  Please let me know if you don't want it.

Honestly, I'd prefer not to diverge from Debian and use plain http as well
so that we limit the risk of regression related to https support.

In particular since our main http.kali.org host redirects to many other
mirrors whose certificates are not under our control. We are not monitoring
that all the certificates are valid.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

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

[Hideki Yamane]

Hi,

 I'll revert below your commit since this regression fix also solve it.

> commit c1c20ed48e83fe9d4f3512c524f7734d4e1469ac
> Author: Raphaël Hertzog 
> Date:   Thu Apr 12 12:18:29 2018 +0200
> 
> Do not use HTTPS for Kali bootstrap script


 Please let me know if you don't want it.


On Sat, 21 Apr 2018 20:32:59 +0900
Hideki Yamane  wrote:
> > there was a change in behaviour with the latest upload:
> 
>  Thanks for the report, and here's a proposal fix.
>  "$@" is extracted as '' and wget tries to fetch it and fails, 
>  then returns 1.
> 
> 
> diff --git a/functions b/functions
> index 1e41862..bad37dc 100644
> --- a/functions
> +++ b/functions
> @@ -80,10 +80,10 @@ wgetprogress () {
> [ ! "$VERBOSE" ] && NVSWITCH="-nv"
> local ret=0
> if [ "$USE_DEBIANINSTALLER_INTERACTION" ] && [ "$PROGRESS_NEXT" ]; 
> then
> -   wget "$@" 2>&1 >/dev/null | "$PKGDETAILS" "WGET%" 
> "$PROGRESS_NOW" "$PROGRESS_NEXT" "$PROGRESS_END" >&3
> +   wget $@ 2>&1 >/dev/null | "$PKGDETAILS" "WGET%" 
> "$PROGRESS_NOW" "$PROGRESS_NEXT" "$PROGRESS_END" >&3
> ret=$?
> else
> -   wget $NVSWITCH "$@"
> +   wget $NVSWITCH $@
> ret=$?
> fi
> return $ret


-- 
Regards,

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

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

[Hideki Yamane]

On Tue, 24 Apr 2018 00:52:10 +1000
David Margerison  wrote:
> needs to be changed to something like this
>wgetprogress $a $b $c "$url"

 Unfortunately, changed to it like above but caused same error.

diff --git a/functions b/functions
index 1e41862..d54b07f 100644
--- a/functions
+++ b/functions
@@ -398,7 +398,7 @@ just_get () {
fi
elif [ "${from#https://}; != "$from" ] ; then
# http/ftp mirror
-   if wgetprogress "$CHECKCERTIF" "$CERTIFICATE" "$PRIVATEKEY" -O 
"$dest" "$from"; then
+   if wgetprogress $CHECKCERTIF $CERTIFICATE $PRIVATEKEY -O 
"$dest" "$from"; then
return 0
else
rm -f "$dest"


-- 
Regards,

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