[PATCH] Add support for the NanoPiNeo

[Paul Tagliamonte]

Hey, -boot

vagrantc added support for the NanoPi in u-boot in version 2016.03~rc3+dfsg1-1,
and i've been playing with it since. Finally, with Linux 4.13, the
NanoPi emac driver has been mainlined, and it (finally!) is starting to
look sensible.

I've got my NanoPi booted and the eth looking happy, but I've not
completed an install yet. Attached is a patch to generate the firmware
image. I was able to test the generated image, and it booted.

Attached is a patch against debian-installer/installer, adding the
NanoPiNeo to the u-boot-image-config.

Thanks for maintaining d-i,
  Paul


-- 
>From 985a6677878ba148db2d175a7cdb9140681bc995 Mon Sep 17 00:00:00 2001
From: Paul Tagliamonte 
Date: Tue, 22 Aug 2017 23:05:59 -0400
Subject: [PATCH] Add support for the NanoPiNeo

---
 build/boot/arm/u-boot-image-config | 1 +
 1 file changed, 1 insertion(+)

diff --git a/build/boot/arm/u-boot-image-config b/build/boot/arm/u-boot-image-config
index efc735457..68856a057 100644
--- a/build/boot/arm/u-boot-image-config
+++ b/build/boot/arm/u-boot-image-config
@@ -28,6 +28,7 @@ Lamobo_R1 /usr/lib/u-boot/Lamobo_R1/u-boot-sunxi-with-spl.bin 16
 orangepi_plus /usr/lib/u-boot/orangepi_plus/u-boot-sunxi-with-spl.bin 16
 pcDuino /usr/lib/u-boot/Linksprite_pcDuino/u-boot-sunxi-with-spl.bin 16
 pcDuino3 /usr/lib/u-boot/Linksprite_pcDuino3/u-boot-sunxi-with-spl.bin 16
+NanoPiNeo /usr/lib/u-boot/nanopi_neo/u-boot-sunxi-with-spl.bin 16
 #
 # Images from u-boot-rockchip
 Firefly-RK3288 /usr/lib/u-boot/firefly-rk3288/u-boot.rksd 64
-- 
2.14.1

Re: Busybox in Debian

[Ben Hutchings]

On Tue, 2017-08-22 at 10:38 +0200, Denys Vlasenko wrote:
> On Mon, Aug 21, 2017 at 8:38 PM, Ben Hutchings 
> wrote:
> > On Mon, 2017-08-21 at 19:40 +0200, Denys Vlasenko wrote:
> > > > On Mon, Aug 14, 2017 at 5:12 PM, Ben Hutchings  > > > g.uk> wrote:
> > > > On Mon, 2017-08-14 at 16:42 +0200, Denys Vlasenko wrote:
> > > > > > > run-init
> > > > > 
> > > > > This tool is doing this:
> > > > 
> > > > [...]
> > > > > There is the "switch_root" tool in util-linux which does the
> > > > > crucial part of this functionality - deleting / remounting /
> > > > > chrooting.
> > > > > It is in bbox too.
> > > > 
> > > > initramfs-tools used to use switch_root if possible, but it
> > > > didn't
> > > > support the -d (drop capabilities) option.  Later on we needed
> > > > validation of the init filename to support symlinks (e.g.
> > > > /sbin/init ->
> > > > /lib/systemd/systemd), so I added and used the -n (dry run)
> > > > option to
> > > > run-init.  busybox would need to support both of these.
> > > 
> > > I added run-init to busybox just now, but I don't see -n option
> > > in
> > > klibc-2.0.4 source. Can you point me to the source code with -n?
> > 
> > It's not upstream yet, but in a Debian patch:
> > https://sources.debian.net/src/klibc/2.0.4-9/debian/patches/run-ini
> > t-add-dry-run-mode.patch/
> 
> Done:
> 
> $ ./busybox run-init
> BusyBox v1.28.0.git (2017-08-21 18:55:09 CEST) multi-call binary.
> 
> Usage: run-init [-d CAP,CAP...] [-n] [-c CONSOLE_DEV] NEW_ROOT
> NEW_INIT [ARGS]
> 
> Free initramfs and switch to another root fs:
> chroot to NEW_ROOT, delete all in /, move NEW_ROOT to /,
> execute NEW_INIT. PID must be 1. NEW_ROOT must be a mountpoint.
> 
> -c DEVReopen stdio to DEV after switch
> -d CAPS   Drop capabilities
> -nDry run

Great.  Once these changes are in the Debian package, I can update
initramfs-tools to make klibc-utils optional.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an
expert.



signature.asc
Description: This is a digitally signed message part

Fw: Why I wasted Debian's bandwidth

[Mickael Profeta]

Hi Debian installer!

I thought this installation issue can be usefull, so I forward this
message. 

My friend uses debian since at least 10 years, not exactly a newbie but
not a debian developper.

Hope this can help.

Best regards

Mike


 - Message Transféré -

Date : Sun, 20 Aug 2017 23:07:54 +0200 (CEST)
De : Seb 
À : Mike 
Sujet : Why I wasted Debian's bandwidth


Hi Mike,


Sorry to write to you in English.

I reinstalled Debian on my home computer this week and ran into a few 
problems that should interest someone in Debian's team. Problem is, I 
don't know who to forward this to. But you might :-)

A little background: I reinstalled Debian after messing with a swap 
partition left the machine broken (my bad, careless). The computer is
not a laptop. I can't run cables in the house so I rely on wifi.

I first downloaded a netinstall CD, small ISO, and copied it to a USB 
stick. As you know I like to cherry pick my packages and I use fvwm, so
my basic install is quite small. The install worked quite well. In 
particular, the two wifi cards (of which one is embedded in the 
motherboard) were correctly detected and the wifi ran smoothly to
download packages from the mirrors. When presented with a dselect-type
choice toward the end of the installation, I elected not to install a
graphical system. After all, most of the related packages are useless
for fvwm.

Problem 1: this left me with a machine with no internet connexion. This
is all the more frustrating since this part worked well during install.
I know it's been pointed out many times to the d-i team, but for my
part I still don't understand the rationale behind this choice. Why
should the connexion part be installed on the system only if a
graphical UI is installed? So I had no way to install network-manager.
In the past, the authors of this excellent software relied on a GUI
being installed, but now there is the smallish nmtui that does the job
from the console.

OK, so I reinstalled. Ah, but there was a snag. On this machine there
are two RAID1 arrays (on two SATA disks), one small for /, one big
for /home. For reasons unknown, both arrays could be assembled but the
second one was deemed unusable by the partitioner even though there was
no problem during the previous install. I fsck'd it just in case, but
to no avail. I reinstalled once again: same problem. OK, I thought I
could take care of this once the machine was installed. I made the same
choices except that I checked the box for a graphical interface. The
package number shot up from 350 to 1400, approximately.

Problem 2: once the install was finished, I could not login as root
from the GUI. I entered the correct password several times. It seems
that logging in as root in a GUI context is impossible (one more reason
for me to prefer loging into the console). Therefore I could manually
mount the RAID1 partition destined to become my /home, but I could not
put it to use since a user was already using the files from the
existing /home partition. (It's not exactly true, I now think I could
have fiddled with fstab and rebooted. But I was unnerved by the
unexpected root situation and did not think of it on the spot.)

OK, so I downloaded this time a full DVD image (the first disk) and
copied the ISO to a USB stick. The install went fine, including using
both RAID1 partitions.

Problem 3: sources.list included a "cdrom:" entry so apt-get did not
know how to use my USB stick to find the .debs.

OK, so I fiddled with mount's options until I had the DVD's contents in 
/media/cdrom.

Problem 4: nmtui is not on that DVD1. I know choices have to be made,
and perhaps popcon is not in favor of nmtui. But perhaps one could make
the case that packages that are relied upon to create an internet
connexion should be on the first DVD.

Problem 5: before downloading the DVD image I did try to check whether 
nmtui would be on it, but I could not find the information. Perhaps it 
would be nice to have a sorted "list-of-packages.txt" next to the
download link. (I'm sure the information exists somewhere, I'm just
pointing out that it's not located where we most want it to be.)

OK, so in the end I hardcoded every fscking details of the wifi
connexion in /etc/network/interfaces and finally got the wifi to work.

Overall, I have wasted several GB of bandwidth and I feel sorry for
that. I also wasted several hours and I feel cheated for that. It would
sure be nice if a connexion that works during install was kept
functional after rebooting :-)

I imagine there are good reasons for the current situation, so I
suggest a compromise: in the dselect-like menu toward the end of the
installation, below "SSH server" (which I checked), add an "Internet
connexion" pre-checked entry, so that users can make a choice here and
be warned of the consequences if they don't select it. (Or, maybe, a
machine that is to become an "SSH server" should have the internet
connexion, no question asked.)


Kind regards,
Sébastien.


-- 

Bug#872867: another option: GENC

[Ben Hildred]

On Tue, Aug 22, 2017 at 2:09 PM, Daniel Pocock  wrote:

>
> Mozilla decided[1] to use GENC[2], a list produced by the US Government
> and including additional countries that are not correctly covered by
> ISO3166.
>
> The US Govertment's approach (making their own list based on ISO3166) is
> similar in some ways to the approach I have suggested for Debian.
>
>
> 1. https://bugzilla.mozilla.org/show_bug.cgi?id=733417#c20
> 2. https://nsgreg.nga.mil/doc/view?i=2500
>
>
Note that GENC 3.0 has been superseded with GENC 3.0.1

 https://nsgreg.nga.mil/doc/view?i=2564



-- 
--
Ben Hildred
Automation Support Services

Bug#872948: debootstrap: Debootstrap does not explain what is calls a Debian base system

[Emmanuel Kasper]

Package: debootstrap
Version: 1.0.89
Severity: minor
Tags: patch

The debootstrap man page says:
The default, with no --variant=X argument, is to create a base Debian 
installation in TARGET.

but does not explain what comes in the base Debian installation.
The patch included tries to improve that.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C.UTF-8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debootstrap depends on:
ii  wget  1.18-5

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2017.5
ii  gnupg   2.1.18-6

debootstrap suggests no packages.

-- no debconf information
commit 5e18585594bf93a1bec5e9f4f2496e016084805c
Author: Emmanuel Kasper 
Date:   Tue Aug 22 22:12:21 2017 +0200

Document which packages are installed by a default variant

The default base system installed by debootstrap includes all packages with 
Pritority essential and
important, but this was not yet documented.

diff --git a/debootstrap.8 b/debootstrap.8
index e802003..a3afc90 100644
--- a/debootstrap.8
+++ b/debootstrap.8
@@ -74,13 +74,13 @@ With this option set, this behaviour is disabled.
 .IP "\fB\-\-variant=minbase|buildd|fakechroot\fP"
 Name of the bootstrap script variant to use.
 Currently, the variants supported are minbase, which only includes
-essential packages and apt; buildd, which installs the build-essential
+\fIessential\fR packages and apt; buildd, which installs the build-essential
 packages into
 .IR TARGET ;
 and fakechroot, which installs the packages without root privileges.
-The default, with no \fB\-\-variant=X\fP argument, is to create a base
-Debian installation in
-.IR TARGET .
+The default, with no \fB\-\-variant=X\fP argument, is to create a
+base Debian installation with all packages of priority \fIessential\fR and
+\fIimportant\fR, including apt.
 .IP
 .IP "\fB\-\-merged-usr\fP"
 Create /{bin,sbin,lib}/ symlinks pointing to their counterparts in /usr/.

Bug#872867: another option: GENC

[Daniel Pocock]

Mozilla decided[1] to use GENC[2], a list produced by the US Government
and including additional countries that are not correctly covered by
ISO3166.

The US Govertment's approach (making their own list based on ISO3166) is
similar in some ways to the approach I have suggested for Debian.


1. https://bugzilla.mozilla.org/show_bug.cgi?id=733417#c20
2. https://nsgreg.nga.mil/doc/view?i=2500

Re: Bug#872867: is ISO-3166 really the optimal list for our users?

[Andrew M.A. Cater]

On Tue, Aug 22, 2017 at 12:28:18AM +0200, Daniel Pocock wrote:
> Package: localechooser
> Version: 2.69
> Severity: wishlist
> 
> While visiting Kosovo, I have met several people interested in becoming
> Debian users.
> 
> The first time I helped one of them run the Debian installation, I was
> baffled to find that their country was not in the list offered by the
> installer.
> 
> It is potentially not a good situation for a developer to be in a
> country, surround by 1.8 million people who consider themselves to be
> citizens of a country that our installer doesn't know about. 
> Fortunately Kosovans are really nice people and weren't upset about this
> but I can image they must feel quite sad each time something like this
> happens.
> 
> According to this section in the Debian Installer i18n guide[1], the
> list of countries is based on ISO3166.
> 
> According to wikipedia, ISO3166 comes from a group of 10
> representatives[2] from mostly rich countries.
> 

The fact that these were rich countries doesn't matter, particularly.
Internet TLDs are IETF, I think. There's also a UN list for things like
car registrations and country codes. It's not quite as simple as it
looks.


> The Debian Social Contract[3], point 4, requires us to put our users
> first.  Can Debian do more to listen to the 1.8 million potential users
> in Kosovo and other countries like it?  Are we actually obliged to
> respect how our users see themselves over and above the way some
> bureaucrats in Geneva see them?
> 
> I would propose that we regard ISO3166 as a subset of the list of
> countries perceived by our users and that for the next installer
> release, the locale chooser offers a list of countries with a disclaimer
> that some of them are not in ISO3166 but they are included at the
> request of our users.

Please go back and review the lists for mails round Taiwan / Hong Kong
/ China / Taiwan (R.O.C) status - this sort of thing is incredibly
tricky. Also, some countries / states / regions have two or three valid
keyboard layouts, some groups span nation boundaries - Kurds spring to
mind - and the installer is already complicated and arcane. Debian is
apolitical and largely border-agnostic but we lost developers because of
this sort of thing - ?? Herbert ?? Xu springs to mind.
> 
> Maybe the list can show two columns, country and country code.  For
> countries where ISO3166 is not competent, the country code column could
> be blank.
> 
> Implementing this might be tricky but not impossible.  For example, a
> crude implementation may simply display the extra countries in the main
> list, but if somebody selects one of them, the installer shows a message
> apologizing for the fact they are not fully supported and offering to
> help them choose from a subset of related country codes.  Maybe their
> preferred choice (verbose country name) could be saved somewhere for
> later use when their country is fully supported and a future version of
> localechooser will help them adapt to their eventual country code during
> a future dist-upgrade.
> 
> For Kosovo in particular, Wikipedia notes[4] that "The code XK is being
> used by the European Commission
> ,^[21]
>  the IMF
> , and SWIFT
> ,^[22]
>  CLDR and
> other organizations as a temporary country code for Kosovo
> .".  Other 2-letter codes are
> mentioned elsewhere so the ideal solution may avoid using a 2 letter
> code for such countries or maybe it can borrow one of the codes used by
> other international organizations who didn't wait for ISO3166.

Then when you find that there's two or three conflicting codes? See also
the Russian / Ukrainian character set messes of long ago. [Windows
character sets, koi8r and similar]

All best, however, 

Andy C
> 
> It may be interesting to support micronations like the Principality of
> Hutt River[5] too.
> 
> Regards,
> 
> Daniel
> 
> 
> 1. https://d-i.alioth.debian.org/doc/i18n/ch01s05.html#idm45330184240096
> 2. https://en.wikipedia.org/wiki/ISO_3166#Members
> 3. https://www.debian.org/social_contract
> 4. https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
> 5. https://en.wikipedia.org/wiki/Principality_of_Hutt_River
> 

Bug#872577: debootstrap: Handle existing /dev

[Dan Nicholson]

On Sun, Aug 20, 2017 at 4:57 PM, Philip Hands  wrote:
> Ben Hildred <426...@gmail.com> writes:
>
>> On Sun, Aug 20, 2017 at 3:25 AM, Ansgar Burchardt  wrote:
>>
>>> Dan Nicholson writes:
>>> > On Fri, Aug 18, 2017 at 2:48 PM, Henrique de Moraes Holschuh
>>> >  wrote:
>>> >> Wouldn't it be more straigthforward to "test -e || mknod" ?
>>> >
>>> > I definitely considered that, but it seemed more noisy to the code to
>>> > add a conditional for every call. But I'd be fine reworking to that
>>> > approach if that's more acceptable, though.
>>>
>>> You can always introduce a `mknod_if_not_exists` function or so.  Though
>>> I'm not sure this is worth here (the name is so long the `test -e` is
>>> almost shorter).
>>>
>>> Ansgar
>>>
>>>
>> function mknod-e () {
>> [ -e "$1" ] || mknod "$@"
>> }
>
> $1 for mknod in this case is liable to be '-m'
>
> The attached patch might satisfy the quest for neatness.
>
> One could instead call the function something like
> ensure-exists-in-target and leave the /dev/'s on all the filenames, if
> that were considered clearer.

That certainly helps, but it doesn't cover everything since the
mkdir's and ln's could fail. Those are easier to handle by adding -p
and -f, respectively, but that's a subtle change in behavior for ln
relative to the mknod change. In the mknod case, an existing device is
left as is. In the ln case, it would be forcefully overwritten.

It's not a big deal in my case (both OBS and debootstrap setup /dev
properly), but I don't know if that's important to others.

Bug#872867: is ISO-3166 really the optimal list for our users?

[Daniel Pocock]

On 22/08/17 10:52, Bastian Blank wrote:
> On Tue, Aug 22, 2017 at 12:28:18AM +0200, Daniel Pocock wrote:
>> According to this section in the Debian Installer i18n guide[1], the
>> list of countries is based on ISO3166.
> Kosovo is listed in ISO3166 as RS-KM, see
> https://www.iso.org/obp/ui/#iso:code:3166:RS 
>
> However we don't list subdivisions.

I'm not sure adding support for subdivisions would satisfy Debian users
in some of these situations but it could be one part of the solution.

>> According to wikipedia, ISO3166 comes from a group of 10
>> representatives[2] from mostly rich countries.
> Most of them from countries actually reognizing Kosovo as independent,
> so what?

While it is good that we use material from official sources, Debian is
independent of any state and may not need to feel constrained by such
lists/standards in the same way that a commercial software vendor might be.


>> It may be interesting to support micronations like the Principality of
>> Hutt River[5] too.
> This one is not recognized by anyone.
>
> Please let the peolpe of Kosovo speak for themselves.

Well, when somebody in Kosovo set up a new mirror, they listed[1] it
under AL (Albania) rather than RS (Serbia).

Regards,

Daniel

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867255

Bug#872867: is ISO-3166 really the optimal list for our users?

[Bastian Blank]

On Tue, Aug 22, 2017 at 12:28:18AM +0200, Daniel Pocock wrote:
> According to this section in the Debian Installer i18n guide[1], the
> list of countries is based on ISO3166.

Kosovo is listed in ISO3166 as RS-KM, see
https://www.iso.org/obp/ui/#iso:code:3166:RS 

However we don't list subdivisions.

> According to wikipedia, ISO3166 comes from a group of 10
> representatives[2] from mostly rich countries.

Most of them from countries actually reognizing Kosovo as independent,
so what?

> It may be interesting to support micronations like the Principality of
> Hutt River[5] too.

This one is not recognized by anyone.

Please let the peolpe of Kosovo speak for themselves.

Bastian

-- 
Actual war is a very messy business.  Very, very messy business.
-- Kirk, "A Taste of Armageddon", stardate 3193.0

Re: Busybox in Debian

[Denys Vlasenko]

On Mon, Aug 21, 2017 at 8:38 PM, Ben Hutchings  wrote:
> On Mon, 2017-08-21 at 19:40 +0200, Denys Vlasenko wrote:
>> > On Mon, Aug 14, 2017 at 5:12 PM, Ben Hutchings  
>> > wrote:
>> > On Mon, 2017-08-14 at 16:42 +0200, Denys Vlasenko wrote:
>> > > > > run-init
>> > >
>> > > This tool is doing this:
>> >
>> > [...]
>> > > There is the "switch_root" tool in util-linux which does the
>> > > crucial part of this functionality - deleting / remounting / chrooting.
>> > > It is in bbox too.
>> >
>> > initramfs-tools used to use switch_root if possible, but it didn't
>> > support the -d (drop capabilities) option.  Later on we needed
>> > validation of the init filename to support symlinks (e.g. /sbin/init ->
>> > /lib/systemd/systemd), so I added and used the -n (dry run) option to
>> > run-init.  busybox would need to support both of these.
>>
>> I added run-init to busybox just now, but I don't see -n option in
>> klibc-2.0.4 source. Can you point me to the source code with -n?
>
> It's not upstream yet, but in a Debian patch:
> https://sources.debian.net/src/klibc/2.0.4-9/debian/patches/run-init-add-dry-run-mode.patch/

Done:

$ ./busybox run-init
BusyBox v1.28.0.git (2017-08-21 18:55:09 CEST) multi-call binary.

Usage: run-init [-d CAP,CAP...] [-n] [-c CONSOLE_DEV] NEW_ROOT NEW_INIT [ARGS]

Free initramfs and switch to another root fs:
chroot to NEW_ROOT, delete all in /, move NEW_ROOT to /,
execute NEW_INIT. PID must be 1. NEW_ROOT must be a mountpoint.

-c DEVReopen stdio to DEV after switch
-d CAPS   Drop capabilities
-nDry run