Bug#984846: netcfg: Default hostname hardcoded in netcfg-common

[Arnaud Rebillout]

Package: netcfg
Severity: normal
Tags: d-i
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

the default hostname "debian" is hardcoded in two places in the file
netcfg-common.c:

https://salsa.debian.org/installer-team/netcfg/-/blob/master/netcfg-common.c#L1043
https://salsa.debian.org/installer-team/netcfg/-/blob/master/netcfg-common.c#L1069

This was reported in the Kali Linux bugtracker [1].

For Kali, we set the default hostname to 'kali' in the file
'debian/netcfg-common.templates', key 'netcfg/get_hostname', so that the
installer proposes it as the default hostname. It works well, however
one of our user noticed that if they enter an invalid hostname, the
default hostname is set back to 'debian' (since it's hardcoded in
netcfg-common.c).

It would be nice if instead it would default to the value that is set in
'netcfg/get_hostname'. However I'm nost sure how to achieve that, as
I'm not familiar with the netcfg code at all, and it's not clear if we
can still get this value at this moment in the code, or if it has been
overwritten by the user's input.

Cheers,

  Arnaud

[1] https://bugs.kali.org/view.php?id=7070

Re: Merge request created [Re: Use isenkram to get around the firmware problem?]

[Cyril Brulebois]

Hallo Holger,

Holger Wansing  (2021-03-08):
> Holger Wansing  wrote (Sun, 7 Mar 2021 17:02:06 +0100):
> > And for the (graphics) firmware problem, isenkram is of no help as it 
> > seems, 
> > at least for Bullseye.
> 
> I have reached the end of my path on this issue.
> 
> isenkram is apparently no solution for Bullseye.

Nevertheless, I'd like to address you many thanks for having looked into
it! It's going to be a major time saver once I get back to d-i topics.

I might try and add some kludge specifically for amdgpu for bullseye,
and we might need to revisit the whole thing during the next release
cycle… Anyway, next window of opportunity for me is somewhen later this
month or maybe April.


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


signature.asc
Description: PGP signature

Re: Bug#983918: buster-pu: package libbsd/0.9.1-2

[Adam D. Barratt]

I somehow missed that libbsd produces a udeb when I was processing
stable-new, so CCing KiBi and -boot now.

Regards,

Adam

On Wed, 2021-03-03 at 12:05 +0100, Gianfranco Costamagna wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: buster
> Severity: normal
> 
> CVE-2019-20367 (no DSA) has been fixed for stretch in 0.8.3-1+deb9u1
> and
> for bullseye, sid with version 0.10.0-1
> Buster has been left out from the patches, and since the patch is
> trivial, I propose to apply it for buster too
> 
> 
> diff -Nru libbsd-0.9.1/debian/changelog libbsd-0.9.1/debian/changelog
> --- libbsd-0.9.1/debian/changelog 2019-02-25 01:33:03.0
> +0100
> +++ libbsd-0.9.1/debian/changelog 2021-03-03 12:03:12.0
> +0100
> @@ -1,3 +1,12 @@
> +libbsd (0.9.1-2+deb10u1) buster; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * CVE-2019-20367
> +A non-NUL terminated symbol name in the string table might
> +result in a out-of-bounds read.
> +
> + -- Gianfranco Costamagna   Wed, 03 Mar
> 2021 12:03:12 +0100
> +
>  libbsd (0.9.1-2) unstable; urgency=medium
>  
>* Perform a proper and correct /usr-merge transition by moving the
> package
> diff -Nru libbsd-0.9.1/debian/patches/CVE-2019-20367.patch libbsd-
> 0.9.1/debian/patches/CVE-2019-20367.patch
> --- libbsd-0.9.1/debian/patches/CVE-2019-20367.patch  1970-01-01
> 01:00:00.0 +0100
> +++ libbsd-0.9.1/debian/patches/CVE-2019-20367.patch  2021-03-03
> 12:00:40.0 +0100
> @@ -0,0 +1,42 @@
> +From 9d917aad37778a9f4a96ba358415f077f3f36f3b Mon Sep 17 00:00:00
> 2001
> +From: Guillem Jover 
> +Date: Wed, 7 Aug 2019 22:58:30 +0200
> +Subject: [PATCH] nlist: Fix out-of-bounds read on strtab
> +
> +When doing a string comparison for a symbol name from the string
> table,
> +we should make sure we do a bounded comparison, otherwise a non-NUL
> +terminated string might make the code read out-of-bounds.
> +
> +Warned-by: coverity
> +---
> + src/nlist.c | 6 --
> + 1 file changed, 4 insertions(+), 2 deletions(-)
> +
> +diff --git a/src/nlist.c b/src/nlist.c
> +index 8aa46a2..228c220 100644
> +--- a/src/nlist.c
>  b/src/nlist.c
> +@@ -227,16 +227,18 @@ __fdnlist(int fd, struct nlist *list)
> + symsize -= cc;
> + for (s = sbuf; cc > 0 && nent > 0; ++s, cc -=
> sizeof(*s)) {
> + char *name;
> ++Elf_Word size;
> + struct nlist *p;
> + 
> + name = strtab + s->st_name;
> + if (name[0] == '\0')
> + continue;
> ++size = symstrsize - s->st_name;
> + 
> + for (p = list; !ISLAST(p); p++) {
> + if ((p->n_un.n_name[0] == '_' &&
> +-strcmp(name, p->n_un.n_name+1) ==
> 0)
> +-|| strcmp(name, p->n_un.n_name) ==
> 0) {
> ++ strncmp(name, p->n_un.n_name+1,
> size) == 0) ||
> ++strncmp(name, p->n_un.n_name, size)
> == 0) {
> + elf_sym_to_nlist(p, s, shdr,
> + ehdr.e_shnum);
> + if (--nent <= 0)
> +-- 
> +GitLab
> +
> diff -Nru libbsd-0.9.1/debian/patches/series libbsd-
> 0.9.1/debian/patches/series
> --- libbsd-0.9.1/debian/patches/series1970-01-01
> 01:00:00.0 +0100
> +++ libbsd-0.9.1/debian/patches/series2021-03-03
> 12:01:48.0 +0100
> @@ -0,0 +1 @@
> +CVE-2019-20367.patch

Re: Merge request created [Re: Use isenkram to get around the firmware problem?]

[Holger Wansing]

Hi,

Holger Wansing  wrote (Mon, 8 Mar 2021 22:41:53 +0100):
> At the bare minimum, I have created a merge request for my "introduce a dialog
> to enter packages for firmware installation" approach, so it is at least 
> officially documented somewhere...

Should have added a link. 
That's 
https://salsa.debian.org/installer-team/hw-detect/-/merge_requests/3


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Merge request created [Re: Use isenkram to get around the firmware problem?]

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sun, 7 Mar 2021 17:02:06 +0100):
> And for the (graphics) firmware problem, isenkram is of no help as it seems, 
> at least for Bullseye.

I have reached the end of my path on this issue.

isenkram is apparently no solution for Bullseye.

At the bare minimum, I have created a merge request for my "introduce a dialog
to enter packages for firmware installation" approach, so it is at least 
officially documented somewhere...


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Use isenkram to get around the firmware problem?

[Brian Potkin]

On Sun 07 Mar 2021 at 17:12:33 +0100, John Paul Adrian Glaubitz wrote:

> On 3/7/21 5:02 PM, Holger Wansing wrote:
> > I fear, all the above is out of my skills.
> > 
> > And for the (graphics) firmware problem, isenkram is of no help as it 
> > seems, 
> > at least for Bullseye.

[...]

> As a compromise, I think it would already be a step forward if the non-free 
> images
> were more visible on the Debian homepage so that users don't have to search 
> for them
> on the interwebs.

At least half a dozen pages were altered to include pointers to the
non-free images. The one page that was not altered was the one that
many people want to be changed was the home page. Interesting.

-- 
Brian.

Re: Issues regarding input methods for Bullseye

[Shengjing Zhu]

On Mon, Mar 8, 2021 at 6:45 AM Holger Wansing  wrote:
>
> Hi all,
>
> currently we have 4 bugreports open regarding input methods:
>
> #983704 Switch to fcitx5 for Simplified and Traditional Chinese desktop
> #941624 Recommending ibus breaks fcitx
> #983653 task-japanese-gnome-desktop: no Japanese input method available out 
> of the box
> #982175 task-japanese-desktop: should explicitly prefer mozc over anthy
>
> This correlates with Gnome's changing to Recommends: ibus.
>
> So, what's the way to solve these issues for Bullseye?
> What are the options?
>
> 1. Since Gnome only supports ibus, all relevant languages would need to get
>an ibus-* package installed, to run Gnome.
>Would that work? Is ibus working fine for all relevant languages?
>
> 2. There are of course people, who don't want to use ibus, but fcitx or uim.
>In that case, would it be ok, to install both (ibus + fctix|uim) ?
>It has been stated, that it's no problem, when more than one input method
>is installed, im-config is there to take care of that.
>
> 3. Getting Gnome reverting the Recommends:ibus dependency is probably no
>longer possible in this development status of Bullseye ... (?)
>
> 4. What about other desktop environments?
>Apart from the fcitx -> fcitx5 switch, are there any other changings
>needed?
>
> 5. 

Just FTR, as there's another thread in #983695.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983695#85

It may be better to recommend gnome-initial-setup for gnome tasks like
task-korean-gnome-desktop, to workaround that ibus doesn't have a
default config for all languages.

Bug#984816: busybox resume fails to resume with swap file after hibernation

[Sven Mueller]

Package: busybox-static
Version: 1:1.30.1-6

Hi.

I wasn't able to figure out all the details yet and likely won't get to
that in the next few weeks. However, I tried getting hibernation to work on
a machine with only a swap file.
This failed miserably (machine appeared to hibernate properly, but on
reboot, the script in the initrd (local-premount/resume, from
initramfs-tools) did call /usr/bin/resume properly (I added some echo/sleep
commands to see what happens), but that just terminated apparently, without
any error message or similar.

Reproduction (on ext4, btrfs needs more involved procedure for offset):

1) create a sufficiently large file /swap
2) mkswap /swap
3) Add swap to /etc/fstab
4) Figure out parameters for resume/resume_offset, /sys/power/resume_offset
and /sys/power/resume

resume=$(findmnt -no SOURCE -T /swap)
findmnt -no MAJ:MIN -T /swap > /sys/power/resume
resume_offset=$(debugfs -R 'bmap /swap 0' $resume 2>/dev/null)

cat > /etc/initramfs-tools/conf.d/resume < /sys/power/resume_offset

(Note the different capitalization for conf.d/resume - it is needed this
way)

Run 'update-initramfs -k all -u'

Now you should be ready to hibernate (NOTE: Unless the bug is fixed or you
configured initramfs-tools to _not_ use busybox, this will potentially lead
to data loss, close all programs)

echo shutdown > /sys/power/disk
echo disk > /sys/power/state

your system should now suspend to disk and power off.

On power-on, the expected state would be that the machine resumes.
The actual state is that the machine does a fresh boot (after running
/usr/bin/resume $resume $resume_offset though).

Cross-check:
Modify /usr/share/initramfstools/hooks/klibc-utils by adding:

rm "$DESTDIR/bin/resume"
cp -pL /usr/lib/klibc/bin/resume "$DESTDIR/bin/resume"

Re-run the steps from "resume=" above.
The system properly resumes from hibernation.

I know that the "resume" tool in busybox originates from the code in
klibc-utils, but right now, the one in busybox doesn't work in this
scenario while the one from klibc-utils does.

Cheers,
Sven

Re: Issues regarding input methods for Bullseye

[Shengjing Zhu]

On Mon, Mar 8, 2021 at 11:52 PM Holger Wansing  wrote:
>
> Am 8. März 2021 16:34:54 MEZ schrieb Shengjing Zhu :
> >I just looked at tasksel, but it seems it's not straightforward to
> >implement,
> >1. install ibus for GNOME
> >2. install other input method for DE except GNOME.
> >Since it's seems hard to express all DE without GNOME, except
> >enumerating them?
>
> I guess it would go like this:
>
> 1. install the IM method prefered by language team
> for all DE
>
> 2. install (additionally) ibus-* , if DE is Gnome.
>
> That way we would have two IM systems installed
> for Gnome, but im-config would take care of  that just
> fine, since ibus is the preferred choice.
>
> And for all other DEs we had that IM installed, what's
> preferred by the language team.
>
> Would that be reasonable?

Agree, it seems it's the feasible option currently.

But we need to add some new packages, task--gnome-desktop, for
languages which prefer non-ibus.

Which are:
1. task-amharic-gnome-desktop, *maybe NEW*, I didn't find amharic for ibus?
2. task-chinese-s-gnome-desktop, *NEW*, probably ibus-libpinyin
3. task-chinese-t-gnome-desktop, *NEW*, probably ibus-chewing
4. task-kannada-gnome-desktop, *NEW*, probably ibus-m17n
5. task-malayalam-gnome-desktop, *maybe NEW*, I didn't find malayalam for ibus?
6. task-telugu-gnome-desktop, already has, probably ibus-m17n
7. task-japanese-gnome-desktop, already has, patch in #983653

@Release Team, could you look at this? It's OK for these new packages.

-- 
Shengjing Zhu

Bug#700633: Debootstrap is very slow. Please use eatmydata to fix this.

[ValdikSS]

Debootstrap is used in Debian ISO installer (debian-installer, d-i) for 
initial target rootfs bootstrapping. With sync enabled, this takes 
hundreds of minutes to unpack and configure base system on a HDD.


With eatmydata it takes about a minute.

What could be done to introduce eatmydata into debootstrap? Are propsed 
patches above (in message 50 and before) are not correct or not conform 
to Debian style or policy? If so, what should be improved?






OpenPGP_signature
Description: OpenPGP digital signature

Re: Issues regarding input methods for Bullseye

[Holger Wansing]

Am 8. März 2021 16:34:54 MEZ schrieb Shengjing Zhu :
>I just looked at tasksel, but it seems it's not straightforward to
>implement,
>1. install ibus for GNOME
>2. install other input method for DE except GNOME.
>Since it's seems hard to express all DE without GNOME, except
>enumerating them?

I guess it would go like this:

1. install the IM method prefered by language team
for all DE

2. install (additionally) ibus-* , if DE is Gnome.

That way we would have two IM systems installed
for Gnome, but im-config would take care of  that just
fine, since ibus is the preferred choice.

And for all other DEs we had that IM installed, what's
preferred by the language team.

Would that be reasonable?


Holger


Hi,
-- 
Sent from /e/ Mail on Fairphone3

Re: Issues regarding input methods for Bullseye

[Shengjing Zhu]

Hi,

On Mon, Mar 8, 2021 at 6:39 PM Shengjing Zhu  wrote:
>
> On Mon, Mar 8, 2021 at 5:05 PM Holger Wansing  wrote:
> >
> > Hi,
> >
> > Shengjing Zhu  wrote (Mon, 8 Mar 2021 13:14:26 +0800):
> > > IMO, we have 3 choice here:
> > >
> > > 1. All languages in tasksel should have a separate task for GNOME, and
> > > a separate task for other DE.
> > >
> > >The GNOME task installs ibus related language modules. And the
> > > other DE task installs the local team prefered input method and the
> > > corresponding language module.
> > >
> > >This is my preference, since the choice of GNOME upstream and
> > > maintainer shouldn't have influence on other DE. But we also respect
> > > the GNOME upstream and maintainer's choice.
> > >
> > >However currently only Japanese has the standalone GNOME task.
> >
> > This option requires to add new binary packages to tasksel, if I understand
> > correctly, but that is no longer possible for Bullseye, due to the freeze,
> > right?

I just looked at tasksel, but it seems it's not straightforward to implement,
1. install ibus for GNOME
2. install other input method for DE except GNOME.
Since it's seems hard to express all DE without GNOME, except enumerating them?

-- 
Shengjing Zhu

Bug#982175: task-japanese-desktop: should explicitly prefer mozc over anthy

[YOSHINO Yoshihito]

Followup-For: Bug #982175
Package: task-japanese-desktop

Hi Holger,

Note that this bug is not related to the GNOME desktop nor ibus.
Instead, it is only related to uim and dpkg (and perhaps apt.)
So this fix should be safely released regardless of the ongoing
discussion around the GNOME desktop.

Thanks in advance,
-- 
YOSHINO Yoshihito 

Bug#983688: tasksel-data: gnome-flashback-desktop task in Japanese environment should pull task-japanese-gnome-desktop

[Holger Wansing]

Control: tags -1 + pending

YOSHINO Yoshihito  wrote (Sun, 28 Feb 2021 22:24:49 
+0900):
> For Japanese users, when the GNOME Flashback desktop is installed,
> it is expected to also install the task-japanese-gnome-desktop package.
> 
> The attached patch adds "japanese-gnome-flashback-desktop" Task
> which behaves just like "japanese-gnome-desktop" Task for
> "gnome-flashback-desktop" Task,
> which installs the task-japanese-gnome-desktop package.
> Note that this patch does NOT add a new binary package, but just adds
> a new Task.

Committed to git.

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Issues regarding input methods for Bullseye

[Shengjing Zhu]

On Mon, Mar 8, 2021 at 5:05 PM Holger Wansing  wrote:
>
> Hi,
>
> Shengjing Zhu  wrote (Mon, 8 Mar 2021 13:14:26 +0800):
> > IMO, we have 3 choice here:
> >
> > 1. All languages in tasksel should have a separate task for GNOME, and
> > a separate task for other DE.
> >
> >The GNOME task installs ibus related language modules. And the
> > other DE task installs the local team prefered input method and the
> > corresponding language module.
> >
> >This is my preference, since the choice of GNOME upstream and
> > maintainer shouldn't have influence on other DE. But we also respect
> > the GNOME upstream and maintainer's choice.
> >
> >However currently only Japanese has the standalone GNOME task.
>
> This option requires to add new binary packages to tasksel, if I understand
> correctly, but that is no longer possible for Bullseye, due to the freeze,
> right?

Let's loop debian-release@ as well.

Dear RT, the thread is started from
https://lists.debian.org/msgid-search/20210307232906.14715b8e982b03f94068d...@mailbox.org

I think there's always another option,

4. Document the incorrect default behavior of GNOME DE in the
release-notes. Tell the user to change the input method manually after
installing. And if something strange happens, uninstall ibus by hand.

-- 
Shengjing Zhu

Processed: Re: Bug#983688: tasksel-data: gnome-flashback-desktop task in Japanese environment should pull task-japanese-gnome-desktop

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #983688 [tasksel-data] tasksel-data: gnome-flashback-desktop task in 
Japanese environment should pull task-japanese-gnome-desktop
Added tag(s) pending.

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

Re: Issues regarding input methods for Bullseye

[Holger Wansing]

Hi,

Shengjing Zhu  wrote (Mon, 8 Mar 2021 13:14:26 +0800):
> IMO, we have 3 choice here:
> 
> 1. All languages in tasksel should have a separate task for GNOME, and
> a separate task for other DE.
> 
>The GNOME task installs ibus related language modules. And the
> other DE task installs the local team prefered input method and the
> corresponding language module.
> 
>This is my preference, since the choice of GNOME upstream and
> maintainer shouldn't have influence on other DE. But we also respect
> the GNOME upstream and maintainer's choice.
> 
>However currently only Japanese has the standalone GNOME task.

This option requires to add new binary packages to tasksel, if I understand
correctly, but that is no longer possible for Bullseye, due to the freeze,
right?

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076