Your message dated Sun, 21 Oct 2018 21:07:16 +0200
with message-id <20181021190716.nnh2t3wnovuj3nuk@function>
and subject line Re: tasksel: fails to preseed desktop on kfreebsd, hurd
has caused the Debian Bug report #769616,
regarding tasksel: fails to preseed desktop on kfreebsd, hurd
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.)
--
769616: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769616
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:tasksel
Version: 3.29
Severity: important
Hi,
(this bug may also affect linux release architectures other than
i386|amd64|powerpc*, and their CD media, so severity may be higher)
It was seen on kfreebsd and hurd that preseeding with:
tasksel tasksel/first multiselect standard, desktop
tasksel tasksel/desktop multiselect xfce
no longer works, a regressions since wheezy; no desktop gets installed:
https://lists.debian.org/debian-hurd/2014/11/msg00074.html
The logic gets ridiculously complex, but I gather that:
* tasksel/first item "desktop", used to be the only thing listed;
selecting or preseeding it would previously install task-desktop
as well as task-xfce-desktop (whatever was default, or preseeded as
tasksel/desktop)
* now, preseeding tasksel/desktop seems to work *only* if
/usr/lib/tasksel/tests/desktop decides it should install a desktop;
irrespective of whether tasksel/first includes "desktop"
* as such, on kfreebsd, hurd and some other arches, selecting or
preseeding tasksel/first with "desktop" only leads to task-desktop
being installed (the parent item), but not the individual task for
desktop, despite setting tasksel/desktop
So I think possible ways to fix this are:
1. simply adding kfreebsd-* and hurd-* to the list of "common
desktop architectures" may inadvertently fix this - that determines
whether tasksel preselects the 'desktop' option by default;
currently the list has only (linux-) i386|amd64|powerpc* and may
explain why the bug wasn't noticed there
2. make tests/default-desktop not conditional on check_desktop_wanted,
if tasksel/first has "desktop", or tasksel/desktop is preseeded
3. make tests/desktop (whether to install a desktop) answer "yes"
(exit 2) if tasksel/first has "desktop", or tasksel/desktop is
preseeded, overriding any guess it would make based on architecture,
diskspace, RAM etc. that it does currently
I'll send a patch for consideration that probably does all three in
some way.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Hello,
Holger Wansing, le dim. 30 sept. 2018 21:06:16 +0200, a ecrit:
> > Steven Chamberlain, le Sun 10 May 2015 22:41:57 +0100, a écrit :
> > > Samuel Thibault wrote:
> > > > I believe it's completely fixed by now: using
> > > >
> > > > tasksel tasksel/first multiselect standard, xfce-desktop
> > > >
> > > > works to preseed the desktop on !linux, and the tasksel/desktop
> > > > preseeding works as expected.
> > >
> > > The same is also true on linux jessie and sid.
> >
> > I just meant that it used to be disfunctional for !linux before, and the
> > arch difference was fixed in time for jessie.
> >
> > > This preseeds to install XFCE:
> > >
> > > tasksel tasksel/first multiselect standard, xfce-desktop
> > >
> > > whereas this (traditional way) no longer does anything, and you would
> > > still get GNOME or whatever is default:
> > >
> > > tasksel tasksel/desktop multiselect xfce
> >
> > Right, the latter doesn't seem to be propagated to the former when only
> > the latter is preseeded.
>
> What's the status here? Can we close this bug?
I'd say so, thus closing it.
Samuel
--- End Message ---