Bug#861343: debootstrap: hardcodes mawk as awk provider

[Raphael Hertzog]

Hi Hideki,

On Mon, 19 Mar 2018, Hideki Yamane wrote:
>  However, in scripts/*, there's unnecessary mawk hardcode line and
>  we can remove it safely as attached patch.
[...]
> - ln -sf mawk "$TARGET/usr/bin/awk"
> + ln -sf awk "$TARGET/usr/bin/awk"

Huh? This doesn't make any sense. You are creating a symlink named "awk" that
points to itself. And you will have broken everything.

The problem is the lack of /usr/bin/awk because that file is handled by
update-alternatives which can't be run in the early steps. So it's
manually created and it needs to point to the awk alternative that
has been unpacked earlier.

At best you can try to match /usr/bin/*awk to try to guess how the
awk executable is named and use that to look up the package name
(for the x_core_install call that also hardcodes the mawk name)
and create the appropriate symlink (which will get replaced by
the update-alternatives managed one).

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#893476: marked as done (DNS setting is not reflected in netplan yaml file when domain name is empty string)

[Debian Bug Tracking System]

Your message dated Mon, 19 Mar 2018 20:03:41 +0100
with message-id <2e527a0a-1e29-576b-9afd-6bc159079...@debian.org>
and subject line Re: Bug#893476: DNS setting is not reflected in netplan yaml 
file when domain name is empty string
has caused the Debian Bug report #893476,
regarding DNS setting is not reflected in netplan yaml file when domain name is 
empty string
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
893476: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893476
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: netcfg
Version: 1.142
Severity: normal

Dear Maintainer,

When we install ubuntu server and set DNS addresses (ex. 8.8.8.8), the event 
that the DNS setting is not reflected in netplan yaml file 
(/etc/netplan/*.yaml) may occur.

We finded that the reason is related to the source code of the network package 
'netcfg'.

In the function 'nc_wi_netplan_write_nameservers' of write_interface.c of 
netcfg-1.142ubuntu5(netcfg package source code directory), the nameservers are 
not written in the netplan yaml file if domain name is empty string.

We hope that the nameservers are written even if domain name is empty string.

Please check the bug.

Regards,

Yeongsoo Yoon.
--- End Message ---
--- Begin Message ---
On 3/19/18 9:38 AM, 윤영수 wrote:
> In the function 'nc_wi_netplan_write_nameservers' of write_interface.c
> of netcfg-1.142ubuntu5(netcfg package source code directory), the
> nameservers are not written in the netplan yaml file if domain name is
> empty string.

Then you should report the bug to Ubuntu, not Debian. (Which by my
knowledge doesn't carry any netplan code at all.)

Kind regards
Philipp Kern--- End Message ---

Re: Curious case of /lib/libkmod.so.2

[Mike Purvis]

Small update here. I broke out of the make run and manually invoked
mklibs-copy in verbose mode. It turns out that libkmod.so.2 does it fact
get copied out of the /lib directory on the system being used to construct
the initrd (I guess I must have had that package installed after all). See
the highlighted line in the mklibs-copy output here:

https://gist.github.com/mikepurvis/a7182157f63ea01649cfca01a57f1068#file-mklibs-copy-L275

The same thing happens with libslang.so.2, a few lines further down.

This behaviour seems very odd and undesirable to me— wouldn't it break the
ability to generate an installer for a different architecture? These
libraries should be coming from libkmod2-udeb and libslang2-udeb,
respectively, right? Should there be a bug filed for this?

Mike

On 15 March 2018 at 16:17, Mike Purvis  wrote:

> Hi d-i developers,
>
> I'm working on an bootloader/installer system for some industrial
> equipment. Until now, my main interaction with d-i has been grabbing the
> pre-cooked kernel/initrds from Debian or Ubuntu, and tacking on a few extra
> files to the tail of the initrd, like preseed, scripts, and an extra udeb
> or two.
>
> However, I've come to a place where I'd like to have more control over
> some things (incl exact kernel version) and so I want to generate my own
> initrd with just the particular udebs I require. I'm basing most of my work
> on the Makefile here, which details downloading a dependency tree of
> packages, and creating a bare bones dpkg setup into which they are
> installed:
>
> https://anonscm.debian.org/git/d-i/debian-installer.git/
> tree/build/Makefile#n308
>
> My system actually mostly works, but one key file I'm missing is
> /lib/libkmod.so.2. This file isn't contained within any of the udebs
> (libkmod2-udeb is just a multi-call binary with no libs), and in fact a
> little tracing reveals that it springs into existence as a result of the
> mklibs-copy call which happens here:
>
> https://anonscm.debian.org/git/d-i/debian-installer.git/
> tree/build/Makefile#n526
>
> Without this lib, systemd-udevd fails to link at runtime (called by the
> init script), and the kernel panics shortly after boot.
>
> So my main question is, what is going on with the mklibs-copy call? Where
> are the contents of libkmod.so.2 coming from? They're byte-for-byte
> identical with the copy in the libkmod2 package, but in a different
> location, and I don't even have that package installed.
>
> I'm sure there's some silly explanation here that I'm just not seeing, but
> a I think I need a poke in the right direction to get there. Thanks,
>
> Mike
>

Processed: Re: debootstrap: 'Release signed by unknown key' should report keyring used

[Debian Bug Tracking System]

Processing control commands:

> tags -1 +patch
Bug #698677 [debootstrap] debootstrap: 'Release signed by unknown key' should 
report keyring used
Added tag(s) patch.

-- 
698677: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698677
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: APT Date verification

[Julian Andres Klode]

On Thu, Feb 08, 2018 at 03:07:54PM +0100, Julian Andres Klode wrote:
> Hey guys,
> 
> APT will shortly start validating that the Date field in a release
> file is not (too far) in the future. This might have implications
> for installing on devices with an inaccurate clock, as they might
> now fail.
> 
> There are two primary workarounds:
> 
> * Set Acquire::Check-Date to false
> * Set check-date sources.list option to false
> 
> It's a bit unclear if this only affects validation of the Date field,
> or also turns off Validation of the Valid-Until field (as a generic "turn
> off all date-related checks" option). Opinions on that?

I think I forgot to follow up, but we enabled this feature  in beta1
on Feb 26, which entered testing on Mar 03.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Processed: Re: debootstrap: hardcodes mawk as awk provider

[Debian Bug Tracking System]

Processing control commands:

> tags -1 +patch
Bug #861343 [debootstrap] debootstrap: hardcodes mawk as awk provider
Added tag(s) patch.

-- 
861343: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861343
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#861343: debootstrap: hardcodes mawk as awk provider

[Hideki Yamane]

control: tags -1 +patch

On Thu, 27 Apr 2017 20:35:01 +0200 Sven Joachim  wrote:
> It might be useful for Debian or derivatives to change the default awk
> provider, which currently is mawk - a package that has de facto been
> unmaintained in Debian for several years.  The original-awk package is
> in my experience considerably less buggy and similarly small.
> 
> However, all the scripts/* files in debootstrap currently hardcode mawk,
> making it impossible to swap the priorities of mawk and original-awk
> without instantly breaking debootstrap. :-(

 mawk package is "required" but other awk packages are "optional".
 Perhaps it is the reason for mawk to be choosed. 

 However, in scripts/*, there's unnecessary mawk hardcode line and
 we can remove it safely as attached patch.

diff --git a/scripts/aequorea b/scripts/aequorea
index 1ae17d8..fb70941 100644
--- a/scripts/aequorea
+++ b/scripts/aequorea
@@ -107,7 +107,7 @@ second_stage_install () {
 	info INSTCORE "Installing core packages..."
 
 	p; progress $baseprog $bases INSTCORE "Installing core packages" #2
-	ln -sf mawk "$TARGET/usr/bin/awk"
+	ln -sf awk "$TARGET/usr/bin/awk"
 	x_core_install base-passwd
 	x_core_install base-files
 	p; progress $baseprog $bases INSTCORE "Installing core packages" #3
diff --git a/scripts/breezy b/scripts/breezy
index f15967a..132d7ea 100644
--- a/scripts/breezy
+++ b/scripts/breezy
@@ -90,7 +90,7 @@ second_stage_install () {
 info INSTCORE "Installing core packages..."
 
 p; progress $baseprog $bases INSTCORE "Installing core packages" #2
-ln -sf mawk "$TARGET/usr/bin/awk"
+ln -sf awk "$TARGET/usr/bin/awk"
 x_core_install base-files base-passwd
 p; progress $baseprog $bases INSTCORE "Installing core packages" #3
 x_core_install dpkg
diff --git a/scripts/dapper b/scripts/dapper
index b1e44d0..4ea3cfa 100644
--- a/scripts/dapper
+++ b/scripts/dapper
@@ -95,7 +95,7 @@ second_stage_install () {
 info INSTCORE "Installing core packages..."
 
 p; progress $baseprog $bases INSTCORE "Installing core packages" #2
-ln -sf mawk "$TARGET/usr/bin/awk"
+ln -sf awk "$TARGET/usr/bin/awk"
 x_core_install base-files base-passwd
 p; progress $baseprog $bases INSTCORE "Installing core packages" #3
 x_core_install dpkg
diff --git a/scripts/debian-common b/scripts/debian-common
index 36989a2..a8591bd 100644
--- a/scripts/debian-common
+++ b/scripts/debian-common
@@ -105,7 +105,7 @@ Status: install ok installed" >> "$TARGET/var/lib/dpkg/status"
 	info INSTCORE "Installing core packages..."
 
 	p; progress $baseprog $bases INSTCORE "Installing core packages" #2
-	ln -sf mawk "$TARGET/usr/bin/awk"
+	ln -sf awk "$TARGET/usr/bin/awk"
 	x_core_install base-passwd
 	x_core_install base-files
 	p; progress $baseprog $bases INSTCORE "Installing core packages" #3
diff --git a/scripts/edgy b/scripts/edgy
index 719a258..eb4ec56 100644
--- a/scripts/edgy
+++ b/scripts/edgy
@@ -105,7 +105,7 @@ second_stage_install () {
 info INSTCORE "Installing core packages..."
 
 p; progress $baseprog $bases INSTCORE "Installing core packages" #2
-ln -sf mawk "$TARGET/usr/bin/awk"
+ln -sf awk "$TARGET/usr/bin/awk"
 x_core_install base-files base-passwd
 p; progress $baseprog $bases INSTCORE "Installing core packages" #3
 x_core_install dpkg
diff --git a/scripts/feisty b/scripts/feisty
index e38f799..671ff86 100644
--- a/scripts/feisty
+++ b/scripts/feisty
@@ -104,7 +104,7 @@ second_stage_install () {
 info INSTCORE "Installing core packages..."
 
 p; progress $baseprog $bases INSTCORE "Installing core packages" #2
-ln -sf mawk "$TARGET/usr/bin/awk"
+ln -sf awk "$TARGET/usr/bin/awk"
 x_core_install base-files base-passwd
 p; progress $baseprog $bases INSTCORE "Installing core packages" #3
 x_core_install dpkg
diff --git a/scripts/gutsy b/scripts/gutsy
index 65a748f..b4066c1 100644
--- a/scripts/gutsy
+++ b/scripts/gutsy
@@ -136,7 +136,7 @@ Status: install ok installed" >> "$TARGET/var/lib/dpkg/status"
 	info INSTCORE "Installing core packages..."
 
 	p; progress $baseprog $bases INSTCORE "Installing core packages" #2
-	ln -sf mawk "$TARGET/usr/bin/awk"
+	ln -sf awk "$TARGET/usr/bin/awk"
 	x_core_install base-passwd
 	x_core_install base-files
 	p; progress $baseprog $bases INSTCORE "Installing core packages" #3
diff --git a/scripts/hoary b/scripts/hoary
index e5fe9fc..7821e2b 100644
--- a/scripts/hoary
+++ b/scripts/hoary
@@ -109,7 +109,7 @@ second_stage_install () {
 info INSTCORE "Installing core packages..."
 
 p; progress $baseprog $bases INSTCORE "Installing core packages" #2
-ln -sf mawk "$TARGET/usr/bin/awk"
+ln -sf awk "$TARGET/usr/bin/awk"
 x_core_install base-files base-passwd
 p; progress $baseprog $bases INSTCORE "Installing core packages" #3
 x_core_install dpkg
diff --git a/scripts/hoary.buildd b/scripts/hoary.buildd
index 8d10d80..e625d79 100644
--- a/scripts/hoary.buildd
+++ 

Bug#731859: debootstrap: variant=fakechroot fails

[Hideki Yamane]

control: tags -1 +unreproducible

On Tue, 10 Dec 2013 15:48:33 +0100 Johannes Schauer  wrote:
> Package: debootstrap
> Version: 1.0.55
> Severity: normal
> 
> Running debootstrap under Debian Sid yields:
> 
> $ fakeroot fakechroot debootstrap --verbose --variant=fakechroot sid 
> debian-sid
> [...]
> I: Installing core packages...
> W: Failure trying to run: chroot /home/josch/debian-sid dpkg --force-depends 
> --install /var/cache/apt/archives/base-files_7.2_amd64.deb 
> /var/cache/apt/archives/base-passwd_3.5.28_amd64.deb
> W: See /home/josch/debian-sid/debootstrap/debootstrap.log for details 
> (possibly the package archive is at fault)

 It was succeeded on my box.

$ dpkg --status debootstrap
Package: debootstrap
Status: install ok installed
Priority: extra
Section: admin
Installed-Size: 227
Maintainer: Debian Install System Team 
Architecture: all
Version: 1.0.55
Depends: wget
Recommends: gnupg, debian-archive-keyring
Description: Bootstrap a basic Debian system
 debootstrap is used to create a Debian base system from scratch,
 without requiring the availability of dpkg or apt. It does this by
 downloading .deb files from a mirror site, and carefully unpacking them
 into a directory which can eventually be chrooted into.

$ fakeroot fakechroot debootstrap --verbose --variant=fakechroot sid debian-sid
(snip)
I: Configuring systemd...
I: Base system installed successfully.
$ echo $?
0

Processed: Re: debootstrap: variant=fakechroot fails

[Debian Bug Tracking System]

Processing control commands:

> tags -1 +unreproducible
Bug #731859 [debootstrap] debootstrap: variant=fakechroot fails
Added tag(s) unreproducible.

-- 
731859: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731859
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#893476: DNS setting is not reflected in netplan yaml file when domain name is empty string

[윤영수]

Package: netcfg
Version: 1.142
Severity: normal

Dear Maintainer,

When we install ubuntu server and set DNS addresses (ex. 8.8.8.8), the event 
that the DNS setting is not reflected in netplan yaml file 
(/etc/netplan/*.yaml) may occur.

We finded that the reason is related to the source code of the network package 
'netcfg'.

In the function 'nc_wi_netplan_write_nameservers' of write_interface.c of 
netcfg-1.142ubuntu5(netcfg package source code directory), the nameservers are 
not written in the netplan yaml file if domain name is empty string.

We hope that the nameservers are written even if domain name is empty string.

Please check the bug.

Regards,

Yeongsoo Yoon.