Re: Salsa

[Christian PERRIER]

> I've updated .mrconfig to point to the new location; I'll probably remove the
> “deleted = true” entries as they are for packages in the attic; and those are
> doubly deprecated as they're going to be archived now anyway.
> 
> URLs on dillon (d-i.debian.org host) have been updated to point to salsa.

I guess I should mimic this in order to update my local copy (the one
where I build packages), right?

And figure out how I can now push my changes back to salsa (but,
again, I guess that looking at what you did on dillon under the d-i
role account is probably the thing to do)

/me in n00b mode:-)



signature.asc
Description: PGP signature

Re: Salsa

[Cyril Brulebois]

Hey,

Steve McIntyre  (2018-04-26):
> I've now migrated all 103(!) of the non-attic d-i repos across from
> alioth to salsa, following the pattern
> 
>  https://anonscm.debian.org/cgit/d-i/$REPO.git
> 
>to
> 
>  https://salsa.debian.org/installer-team/$REPO

Thanks!

> In each case, the old alioth repo will now reject pushes. The new
> repos are each set up to use KGB to announce changes in #debian-boot
> as previously. I've not (yet) spent any time on updating all the
> debian/control files to point at salsa, or updated mr configs or
> anything else.
> 
> The repos involved are:
> 
> […]
> bak.debootstrap

That one should probably go away?


I've updated .mrconfig to point to the new location; I'll probably remove the
“deleted = true” entries as they are for packages in the attic; and those are
doubly deprecated as they're going to be archived now anyway.

URLs on dillon (d-i.debian.org host) have been updated to point to salsa.

A key has been generated there specifically for salsa, ~/.gitconfig has been
updated to rewrite https into ssh to push using ssh, and I've set up a
di-l10n-guest account as previously on alioth. I'm told we could be using
deploy keys, but from a quick glance they seem to work on a project level
(rather than on the group leve), and I'm not toying with salsa's API right
away. Also, https://wiki.debian.org/Salsa/Doc#Deployment_keys is in FIXME
mode. ;) If the di-l10n-guest account remains needed, we should adjust the
mail address from one of mine to something shared across several people (not
sure about using debian-boot@ for that…).

A manual l10n-sync script seems to be working just fine, given the log
and the commits popping up on IRC. The only issue seems to be this, which is
likely an issue with the package itself:
| Everything up-to-date
| - preseed
|   - Run debconf-updatepo... failed.


Migrating away from SVN is still an open task though.


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


signature.asc
Description: PGP signature

Re: Salsa

[Steve McIntyre]

On Tue, Apr 24, 2018 at 11:16:04PM +0200, Cyril Brulebois wrote:
>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.

I've now migrated all 103(!) of the non-attic d-i repos across from
alioth to salsa, following the pattern

 https://anonscm.debian.org/cgit/d-i/$REPO.git

   to

 https://salsa.debian.org/installer-team/$REPO

In each case, the old alioth repo will now reject pushes. The new
repos are each set up to use KGB to announce changes in #debian-boot
as previously. I've not (yet) spent any time on updating all the
debian/control files to point at salsa, or updated mr configs or
anything else.

The repos involved are:

anna
apt-setup
arcboot-installer
babelbox
bak.debootstrap
base-installer
bterm-unifont
busybox
cdebconf-entropy
cdebconf-terminal
cdebconf
cdrom-checker
cdrom-detect
cdrom-retriever
choose-mirror
clock-setup
console-setup
d-i
daily-build-logs
debian-installer-launcher
debian-installer-netboot-images
debian-installer-utils
debian-installer
debootstrap
desktop-chooser
devicetype-detect
dh-di
efi-reader
elilo-installer
finish-install
flash-kernel
grub-installer
hw-detect
installation-locale
installation-report
iso-scan
kadit-playbooks
kadit
kbd-chooser
kernel-wedge
kickseed
libdebian-installer
lilo-installer
live-installer
localechooser
lowmem
lvmcfg
main-menu
mdcfg
media-retriever
mklibs
mountmedia
net-retriever
netboot-assistant
netcfg
network-console
nobootloader
oldsys-preseed
os-prober
partconf
partman-auto-crypto
partman-auto-lvm
partman-auto-raid
partman-auto
partman-base
partman-basicfilesystems
partman-basicmethods
partman-btrfs
partman-crypto
partman-efi
partman-ext3
partman-iscsi
partman-jfs
partman-lvm
partman-md
partman-multipath
partman-nbd
partman-newworld
partman-partitioning
partman-prep
partman-swapfile
partman-target
partman-ufs
partman-xfs
partman-zfs
pkgsel
prep-installer
preseed
quik-installer
rescue
rootskel-gtk
rootskel
s390-dasd
s390-netdevice
s390-sysconfig-writer
s390-zfcp
tzsetup
udpkg
usb-discover
user-setup
win32-loader
yaboot-installer
zipl-installer

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Bug#896908: busybox cpio: fails to extract absolute symlinks

[Tzafrir Cohen]

Package: busybox-static
Version: 1:1.27.2-2
Severity: normal

I tried building debirf on a current Sid system (chroot, rather). The
generated initramfs failed to properly boot. I noticed that the
second-stage rootfs in it, is OK but when extracted misses /sbin/init
and a number of other symlinks from /sbin and thus the system fails to
boot due to a missing init.

cpio on Stretch and on Sid as well as busybox cpio on Stretch
(1:1.22.0-19+b3) extract the absolute symlinks OK, but busybox cpio on
Sid does not extract absolute symlinks.

A test for the problem:

#!/bin/sh
#cpio="cpio"
cpio="/bin/busybox cpio"

mkdir -p test_dir
cd test_dir

rm -rf src_dir
mkdir src_dir
cd src_dir
ln -s /bin/true absolute_link
touch a_file
ln -s a_file relative_link
# Create with the regular cpio:
ls absolute_link a_file relative_link | cpio -H newc -o >../test.cpio
cd ..

rm -rf dst_dir
mkdir dst_dir
cd dst_dir
# Extract with the tested cpio:
$cpio -H newc -i <../test.cpio
count=`ls | wc -l`
if [ "$count" = 2 ]; then
echo "absolute links were not extracted"
fi



-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8), 
LANGUAGE=he_IL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Re: Remote Debian installation assistance for newbies using WireGuard VPN

[Philip Hands]

ST  writes:

> On Wed, 2018-04-25 at 14:50 +0200, Philip Hands wrote:
>> ST  writes:
>> 
>> > Hello Debian Install System Team,
>> >
>> > there used to be Linux install parties - a very cool event in itself and
>> > a way to bring new users into community. However it is not so easy to
>> > organize and it is somewhat limiting in time and space.
>> >
>> > Several weeks ago I learned about the kernel-space VPN - WireGuard [1]
>> > and was so positively shocked by the ease of it's configuration/use [2]
>> > so that I don't stop to think how it can be effectively utilized.
>> >
>> > Today I was thinking whether it would be possible to use this technology
>> > to enable an experienced Linux user to help a fellow newbie to install
>> > Debian on his Windows box?...
>> >
>> > The idea is to add an "Remote assistance mode" into win32-loader. Once
>> > toggled - it will preseed and run Debian Installer (after reboot)
>> > without any interaction until it:
>> > 1. creates a WG interface,
>> > 2. obtains an IP from a (not yet extent) Debian WireGuard VPN server [3]
>> > (the assisting Linux profi also should be part of this VPN so he can SSH
>> > to the newbie through NAT).
>> > 3. runs SSH server listening on that IP.
>> > 4. generates a short random password for the root user and displays it
>> > together with its IP from step #2 on the monitor of the newbie. This
>> > information (IP and root's password) are communicated by newbie to his
>> > Linux profi friend by phone/sms/etc..
>> >
>> >>From this point on the Linux profi can SSH to the box and continue the
>> > installation process in text mode.
>> >
>> > Is something like this possible?
>> 
>> I've not yet used WireGuard, but from what I can see one needs a unique
>> key per client to be known to the server (perhaps there's a way of
>> telling it not to care).  Also, the examples around the place also seem
>> to suggest that one needs a UDP port per connection.
>> 
>> Also, the wireguard.com front page does currently say:
>> 
>>   WireGuard is not yet complete. _You should not rely on this code._
>> 
>> Anyway, I don't see that one actually needs WireGuard to implement it.
>> 
>> A similar result could be achieved by configuring the new system to ssh
>> to a server somewhere, and either have that connection used for the
>> remote control, or have ssh also do port-forwarding back to the new
>> installation.
>
> Indeed?!... I'm positively shocked once again... Never knew it could be
> possible. Let's say we have a newbie (with a private IP - N which is
> behind NAT) and the same for a profie with IP P. And a publicly visible
> server with the IP S. Let's say both can SSH to S:22 and know each
> others' passwords/keys.
>
>  Could you, please, describe in details how one can implement both
> approaches, namely:
>
> 1. "to ssh to a server somewhere, and either have that connection used",
> i.e. `ssh newbie@S:22`... so what now? How profi can get through to N?

Many years ago I used to plumb things like this together with expect,
but there's bound to be a better way to do it these days -- tmate.io
(mentioned elsewhere in the thread) seems like it might be part of such
a solution.  I doesn't trike me as the optimal approach though.

> 2. "or have ssh also do port-forwarding back to the new installation"
> could you, please show the sequence of commands to achieve this?

One would use something like this on the target system:

  ssh -R 0:localhost:22 newbie@S

which leaves you with the challenge of telling the "profi" the port
that's been allocated, which is probably scriptable on the server
somehow, at which point they can do what boils down to:

  ssh -J profie@S:22 -p $DYN_PORT root@localhost

which should jump via the server, up the reverse port forward, and then
onto the target.

Making that so that nobody gets to do anything nasty on the server or to
connect to the wrong newbie is left as an excercise to the reader ;-)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#896902: busybox: Segmentation fault in microcom applet

[Uwe Kleine-König]

Package: busybox
Version: 1:1.27.2-2
Severity: normal

Hello

user@host:~$ busybox microcom
Segmentation fault (core dumped)

reproduces on two different amd64 machines. Could also reproduce on an
armel porter machine (abel, in the sid schroot).

1:1.22.0-19+b3 isn't affected.

Best regards
Uwe

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), 
(500, 'stable'), (499, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages busybox depends on:
ii  libc6  2.27-3

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information

Bug#896826: Fixed by ignoring partitions using 'in_vg{ ... }'

[Garinot Pierre]

Actually i took a closer look at this and wrote a patch that fixes it
for me.
It is attached with this mail.

It filters partitions using 'in_vg{' when computing min_size in
choose_recipe() and using method 'lvm'.

I saw that min_size() is used in some other places in partman, that's
the reason i put the filter in choose_recipe():
The recipe is still the same, we only modify the $scheme used by
min_size() for this particular check.

For all i know and understand about d-i, this shouldn't affect anything
other than this bug.

I'm not used to making patches for debian packages, much less for the
installer, so that may not be the _right_ way to do it, just tell me
and i'll find the time to modify my patch. Anyway, it works for me.diff -Nru partman-auto-137/debian/changelog partman-auto-137+nmu1/debian/changelog
--- partman-auto-137/debian/changelog	2016-10-13 07:02:40.0 +0200
+++ partman-auto-137+nmu1/debian/changelog	2018-04-25 09:57:42.0 +0200
@@ -1,3 +1,10 @@
+partman-auto (137+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Test
+
+ -- Garinot Pierre   Wed, 25 Apr 2018 09:57:42 +0200
+
 partman-auto (137) unstable; urgency=medium
 
   [ Helge Deller ]
diff -Nru partman-auto-137/lib/recipes.sh partman-auto-137+nmu1/lib/recipes.sh
--- partman-auto-137/lib/recipes.sh	2013-10-01 07:21:24.0 +0200
+++ partman-auto-137+nmu1/lib/recipes.sh	2018-04-25 09:57:42.0 +0200
@@ -200,6 +200,21 @@
 	done
 }
 
+filter_lvm () {
+	scheme_lvm=$(
+	foreach_partition '
+		if echo "$*" | grep -q '\''in_vg{'\''; then
+			echo "$*"
+		fi'
+	)
+	scheme=$(
+	foreach_partition '
+		if ! echo "$*" | grep -q '\''in_vg{'\''; then
+			echo "$*"
+		fi'
+	)
+}
+
 min_size () {
 	local size
 	size=0
@@ -374,6 +389,9 @@
 		recipe="$RET"
 		decode_recipe $recipe $type
 		filter_reused
+		if [ "$type" = "lvm" ]; then
+			filter_lvm
+		fi
 		min_size=$(min_size)
 		if [ $min_size -le $free_size ]; then
 			return 0

Re: Remote Debian installation assistance for newbies using WireGuard VPN

[ST]

On Wed, 2018-04-25 at 14:50 +0200, Philip Hands wrote:
> ST  writes:
> 
> > Hello Debian Install System Team,
> >
> > there used to be Linux install parties - a very cool event in itself and
> > a way to bring new users into community. However it is not so easy to
> > organize and it is somewhat limiting in time and space.
> >
> > Several weeks ago I learned about the kernel-space VPN - WireGuard [1]
> > and was so positively shocked by the ease of it's configuration/use [2]
> > so that I don't stop to think how it can be effectively utilized.
> >
> > Today I was thinking whether it would be possible to use this technology
> > to enable an experienced Linux user to help a fellow newbie to install
> > Debian on his Windows box?...
> >
> > The idea is to add an "Remote assistance mode" into win32-loader. Once
> > toggled - it will preseed and run Debian Installer (after reboot)
> > without any interaction until it:
> > 1. creates a WG interface,
> > 2. obtains an IP from a (not yet extent) Debian WireGuard VPN server [3]
> > (the assisting Linux profi also should be part of this VPN so he can SSH
> > to the newbie through NAT).
> > 3. runs SSH server listening on that IP.
> > 4. generates a short random password for the root user and displays it
> > together with its IP from step #2 on the monitor of the newbie. This
> > information (IP and root's password) are communicated by newbie to his
> > Linux profi friend by phone/sms/etc..
> >
> >>From this point on the Linux profi can SSH to the box and continue the
> > installation process in text mode.
> >
> > Is something like this possible?
> 
> I've not yet used WireGuard, but from what I can see one needs a unique
> key per client to be known to the server (perhaps there's a way of
> telling it not to care).  Also, the examples around the place also seem
> to suggest that one needs a UDP port per connection.
> 
> Also, the wireguard.com front page does currently say:
> 
>   WireGuard is not yet complete. _You should not rely on this code._
> 
> Anyway, I don't see that one actually needs WireGuard to implement it.
> 
> A similar result could be achieved by configuring the new system to ssh
> to a server somewhere, and either have that connection used for the
> remote control, or have ssh also do port-forwarding back to the new
> installation.

Indeed?!... I'm positively shocked once again... Never knew it could be
possible. Let's say we have a newbie (with a private IP - N which is
behind NAT) and the same for a profie with IP P. And a publicly visible
server with the IP S. Let's say both can SSH to S:22 and know each
others' passwords/keys.

 Could you, please, describe in details how one can implement both
approaches, namely:

1. "to ssh to a server somewhere, and either have that connection used",
i.e. `ssh newbie@S:22`... so what now? How profi can get through to N?

2. "or have ssh also do port-forwarding back to the new installation"
could you, please show the sequence of commands to achieve this?

> 
> Of course we then have to work out under what circumstances the user
> should trust that person to be connected to their network,

I think a usual case is when they are just friends and trust each other
and have another shared communication channel, like phone/etc.. It's
kind of what TeamViewer is doing. The innovative part here though is to
enable terminal sharing for _bootstrapping_ an _not yet existent_ OS!

Thank you!

Re: Remote Debian installation assistance for newbies using WireGuard VPN

[Jason A. Donenfeld]

tmate.io seems well suited for this.

Re: Remote Debian installation assistance for newbies using WireGuard VPN

[Ian Campbell]

On Wed, 2018-04-25 at 14:50 +0200, Philip Hands wrote:
> Of course we then have to work out under what circumstances the user
> should trust that person to be connected to their network, the
> implications of which one cannot really expect a newbie to fully
> grasp.

I'm reminded of https://debug-me.branchable.com/

Ian.

Re: Remote Debian installation assistance for newbies using WireGuard VPN

[Philip Hands]

ST  writes:

> Hello Debian Install System Team,
>
> there used to be Linux install parties - a very cool event in itself and
> a way to bring new users into community. However it is not so easy to
> organize and it is somewhat limiting in time and space.
>
> Several weeks ago I learned about the kernel-space VPN - WireGuard [1]
> and was so positively shocked by the ease of it's configuration/use [2]
> so that I don't stop to think how it can be effectively utilized.
>
> Today I was thinking whether it would be possible to use this technology
> to enable an experienced Linux user to help a fellow newbie to install
> Debian on his Windows box?...
>
> The idea is to add an "Remote assistance mode" into win32-loader. Once
> toggled - it will preseed and run Debian Installer (after reboot)
> without any interaction until it:
> 1. creates a WG interface,
> 2. obtains an IP from a (not yet extent) Debian WireGuard VPN server [3]
> (the assisting Linux profi also should be part of this VPN so he can SSH
> to the newbie through NAT).
> 3. runs SSH server listening on that IP.
> 4. generates a short random password for the root user and displays it
> together with its IP from step #2 on the monitor of the newbie. This
> information (IP and root's password) are communicated by newbie to his
> Linux profi friend by phone/sms/etc..
>
>>From this point on the Linux profi can SSH to the box and continue the
> installation process in text mode.
>
> Is something like this possible?

I've not yet used WireGuard, but from what I can see one needs a unique
key per client to be known to the server (perhaps there's a way of
telling it not to care).  Also, the examples around the place also seem
to suggest that one needs a UDP port per connection.

Also, the wireguard.com front page does currently say:

  WireGuard is not yet complete. _You should not rely on this code._

Anyway, I don't see that one actually needs WireGuard to implement it.

A similar result could be achieved by configuring the new system to ssh
to a server somewhere, and either have that connection used for the
remote control, or have ssh also do port-forwarding back to the new
installation.

Of course we then have to work out under what circumstances the user
should trust that person to be connected to their network, the
implications of which one cannot really expect a newbie to fully grasp.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Remote Debian installation assistance for newbies using WireGuard VPN

[ST]

Hello Debian Install System Team,

there used to be Linux install parties - a very cool event in itself and
a way to bring new users into community. However it is not so easy to
organize and it is somewhat limiting in time and space.

Several weeks ago I learned about the kernel-space VPN - WireGuard [1]
and was so positively shocked by the ease of it's configuration/use [2]
so that I don't stop to think how it can be effectively utilized.

Today I was thinking whether it would be possible to use this technology
to enable an experienced Linux user to help a fellow newbie to install
Debian on his Windows box?...

The idea is to add an "Remote assistance mode" into win32-loader. Once
toggled - it will preseed and run Debian Installer (after reboot)
without any interaction until it:
1. creates a WG interface,
2. obtains an IP from a (not yet extent) Debian WireGuard VPN server [3]
(the assisting Linux profi also should be part of this VPN so he can SSH
to the newbie through NAT).
3. runs SSH server listening on that IP.
4. generates a short random password for the root user and displays it
together with its IP from step #2 on the monitor of the newbie. This
information (IP and root's password) are communicated by newbie to his
Linux profi friend by phone/sms/etc..

>From this point on the Linux profi can SSH to the box and continue the
installation process in text mode.

Is something like this possible?

Thank you!

[1]: https://www.wireguard.com/
[2]:
https://linode.com/docs/networking/vpn/set-up-wireguard-vpn-on-ubuntu/
[3]: here is a short demo of how it could be done:
https://git.zx2c4.com/WireGuard/tree/contrib/examples/ncat-client-server

Bug#877467: Odroid-XU4: success despite several challenges

[Jochen Sprickerhof]

Hi Vagrant,

* Vagrant Cascadian  [2018-04-11 19:52]:

Modules needed to detect the ethernet adapter were still not present in
the netboot image.


The modules are now in there (cf. #895976).


There was a confusing message about partitioning
location. The boot firmware was overwritten as part of the install, but
I suspect that is an old vendor conflict with dos partition tables that
should be fixed in more recent versions of the firmware.


Talking of the firmware, I opened an issue upstream about the license of 
it:


https://github.com/hardkernel/u-boot/issues/49

So maybe we can add it in non-free, or did you invest time in that 
direction already?


Cheers Jochen


signature.asc
Description: PGP signature