root-fs too small [was: Re: Debian Installer Jessie Beta 2 release]

Hi,

Important changes in this release of the installer
==================================================

[...]

* A list of desktop environments is displayed in tasksel, making it
easy to install another desktop environment (or several of them).
Unfortunately that is currently a bit underdocumented (#764026).

Testing debian-jessie-DI-b2-kfreebsd-amd64-netinst.iso under qemu, if I
only choose
« Graphical desktop environment », d-i don't install any DE, just
something like desktop-base. It seems that I have to choose explicitly
(Xfce in my specific case).

I've seen default_desktop_for_arch() in
http://sources.debian.net/src/tasksel/3.28/default_desktop/
but I don't know if it's used. (If not, you successfully get rid of
« default desktop » difficulty !)
Do I need to mention this in #764026, or it's not a desired feature ?

Note that I didn't try linux kernel to compare, and it could be
kfreebsd-specific.

Baptiste

--
To UNSUBSCRIBE, email to debian-boot-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@mailoo.org

Cyril Brulebois

2014-10-06 14:30:02 UTC

Hi,

Post by Baptiste Jammet
Testing debian-jessie-DI-b2-kfreebsd-amd64-netinst.iso under qemu,
if I only choose
« Graphical desktop environment », d-i don't install any DE, just
something like desktop-base. It seems that I have to choose
explicitly (Xfce in my specific case).
I've seen default_desktop_for_arch() in
http://sources.debian.net/src/tasksel/3.28/default_desktop/
but I don't know if it's used. (If not, you successfully get rid of
« default desktop » difficulty !)
Do I need to mention this in #764026, or it's not a desired feature ?

please file a full installation report, including syslog:
https://www.debian.org/releases/stable/amd64/ch05s04.html.en#problem-report

We'll see.

Mraw,
KiBi.

Steven Chamberlain

2014-10-06 23:50:02 UTC

Hi!

Post by Baptiste Jammet
Testing debian-jessie-DI-b2-kfreebsd-amd64-netinst.iso under qemu,
if I only choose
« Graphical desktop environment », d-i don't install any DE, [...]

There should have been several DEs listed in that menu to choose from;
seems okay to me, or is that choice only shown for Expert-mode installs?

Regards,

--
Steven Chamberlain
***@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-boot-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@squeeze.pyro.eu.org

Cyril Brulebois

2014-10-07 00:00:01 UTC

Post by Steven Chamberlain
There should have been several DEs listed in that menu to choose from;
seems okay to me, or is that choice only shown for Expert-mode installs?

Please send follow-ups to #764277?

Mraw,
KiBi.

Baptiste Jammet

2014-10-07 07:40:01 UTC

Hi Steven,

Post by Steven Chamberlain
There should have been several DEs listed in that menu to choose from;
seems okay to me, or is that choice only shown for Expert-mode
installs?

The tasksel screen look like this (from memory) :

[*]Graphical Desktop Environment
[ ]...GNOME
[ ]...Xfce
[ ]...KDE
[ ]...Cinnamon
[ ]...MATE
[ ]...LXDE
[ ]SSH server
[ ]and so on...

I only choose the task « Graphical DE » without explicitly ask for a
particular DE, in order to test the default behaviour.
What I expected is :
a) Only GDE is selected by default and it install the default DE choosen
or b) GDE task don't install any DE, but one of the 5 is pre-selected.

Baptiste

--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org

Andreas Tille

2014-10-08 09:50:03 UTC

Hi Cyril,

The Debian Installer team[1] is pleased to announce the second beta
release of the installer for Debian 8 "Jessie".
...

thanks for your report and your continuous work on the installer.

I wonder what might be the opinion of the installer team about bug
#758116 which contains the suggestion to add Blends to the tasks
selection menu and whether we could do something to help with the
implementation. The bug report received a lot of agreement from people
working in different Blends but only one question[1] of Joey Hess
probably wearing his tasksel maintainer hat. For me it is not clear
whether this is an issue of deciding what Blend to include (Joey's
question was targeting into this direction) or whether you hesitate to
implement this at all. Since it is not clear whether you think this
kind of menu is sensible or not we did not yet mindet providing patches
or so to support your work. Some kind of statement could be motivating
to provide more work on the technical side.

Kind regards and thanks again for your work on the installer

Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#140

--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-boot-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@an3as.eu

Cyril Brulebois

2014-10-14 04:10:01 UTC

Hi Andreas,

The Debian Installer team[1] is pleased to announce the second beta
release of the installer for Debian 8 "Jessie".
...

thanks for your report and your continuous work on the installer.
I wonder what might be the opinion of the installer team about bug
#758116 which contains the suggestion to add Blends to the tasks
selection menu and whether we could do something to help with the
implementation. The bug report received a lot of agreement from people
working in different Blends but only one question[1] of Joey Hess
probably wearing his tasksel maintainer hat. For me it is not clear
whether this is an issue of deciding what Blend to include (Joey's
question was targeting into this direction) or whether you hesitate to
implement this at all. Since it is not clear whether you think this
kind of menu is sensible or not we did not yet mindet providing patches
or so to support your work. Some kind of statement could be motivating
to provide more work on the technical side.
Kind regards and thanks again for your work on the installer
Andreas.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#140

well to be honest the whole blend story came as a surprise.

I think we identified quite early in the release cycle that we would
need to finally do something about the desktop situation (which first
landed in D-I Jessie Beta 2).

Blends were first mentioned during a DC'14 talk in late August. At the
moment my personal feeling about this is that it looks a bit late, and
I'm almost certainly not going to drive such changes myself. I don't
have any strong incentive to prevent other people from working on this
though. (Of course, any work should happen sooner than later.)

Of course, if blends support ends up not being merged for Jessie, I'm
very sorry for people having participated in the discussion and their
false hope. :(

Mraw,
KiBi.

Andreas Tille

2014-10-14 08:10:01 UTC

Hi Cyril,

Post by Cyril Brulebois
Hi Andreas,

The Debian Installer team[1] is pleased to announce the second beta
release of the installer for Debian 8 "Jessie".
...

thanks for your report and your continuous work on the installer.
I wonder what might be the opinion of the installer team about bug
#758116 which contains the suggestion to add Blends to the tasks
selection menu and whether we could do something to help with the
implementation. The bug report received a lot of agreement from people
working in different Blends but only one question[1] of Joey Hess
probably wearing his tasksel maintainer hat. For me it is not clear
whether this is an issue of deciding what Blend to include (Joey's
question was targeting into this direction) or whether you hesitate to
implement this at all. Since it is not clear whether you think this
kind of menu is sensible or not we did not yet mindet providing patches
or so to support your work. Some kind of statement could be motivating
to provide more work on the technical side.
Kind regards and thanks again for your work on the installer
Andreas.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#140

well to be honest the whole blend story came as a surprise.

Ahhh, this in turn is surprising for me since the first "version" of
this bug is dated 24 Mar 2003 (#186085) :-). But I agree that Blends
are not widely known even if I was proactively running around since
more than ten years telling people
"Is there a topic in Debian you care about? Create a Blend today!"
as Asheesh advised me in last years DebConf talk[1 - just see the
linked subtitles text to save time - it is *very* speaking for the
whole topic!]

In other words: I perfectly know the fact that Blends are widely
ignored even amongst Debian developers and that's not about you / the
debian-boot team - perhaps my "running around and tell people" is just
not the right way to convince people. At least I can tell that those
people who were listening started to like the idea [see 1].

Post by Cyril Brulebois
I think we identified quite early in the release cycle that we would
need to finally do something about the desktop situation (which first
landed in D-I Jessie Beta 2).

Well, Blends and "the desktop situation" could be considered orthogonal.
The main goal of a Blend is not primarily to tweak the desktop (even if
this could be done). It is rather about the applications. In Debian
Med we even have a cluster task which contains exclusively those
packages which can be run without a graphical desktop (bio-cloud [2]).

Post by Cyril Brulebois
Blends were first mentioned during a DC'14 talk in late August.

To be precise: Blends (formerly Custom Debian Distributions - yes, I'm
*not* responsible for this broken name :-() was mentioned on *any*
DebConf I joined with exception of DebConf 0 where this idea was not yet
born. If you scroll down my talks page[3] you stumble upon DebConf 1 in
Bordeaux 2001 as first time presenting the idea on a DebConf. Any of my
talks raised the question, whether there is a menu in the installer to
a) get an easy installation method and b) propagate the Blends concept
(which is obviously needed). It might have been the fault of people who
care about Blends that they did not approached the Debian Boot team
earlier, yes. The reason why at least I stayed away from this since
2003 (#186085) was that I have seen little chances to change the
refusal. However, since recently some Blends of some more general
interest like Debian Games and Debian GIS started or gained some
traktion resp. the idea came up to rise this question on IRC in the
DebConf talk.

Post by Cyril Brulebois
At the
moment my personal feeling about this is that it looks a bit late, and
I'm almost certainly not going to drive such changes myself.

I perfectly agree that you as the one person army keeping Debian Boot
alive (hey, do you like the Blends born idea to prove this point[4]??)
should not spend extra time cycles into the implementation.

Post by Cyril Brulebois
I don't
have any strong incentive to prevent other people from working on this
though. (Of course, any work should happen sooner than later.)

That's in fact a quite motivating incentive and I perfectly agree that
we really should start rather yesterday than today. The thing is that
it is not really clear to me, what we should do rather than adding the
packages

edu-tasks
games-tasks
gis-tasks
junior-tasks
med-tasks
science-tasks
debichem-tasks
ezgo-tasks

(multimedia-tasks is not ready according to their maintainer[5]) to the
boot disks.

Joey Hess as tasksel maintainer mentioned "limited amount of space in
tasksel for blends" but this does not give a sensible hint of what exact
action we should do now. I think currently eight additional lines is
not that much. I also totally contradict to Joey's statement "The
'Debian Pure Blends' effort has been around for several releases and
been publicised." and I take [1] as sufficient argument that it is not
the case. Blends were never ever regarded in practice as some Debian
internal thing and *every* time when I talk about Blends on conferences
and in private discussions I will be asked: "Why don't you do this cool
stuff right into Debian instead of a derivative?" It would *really*
help in this kind of discussion to point to the Debian installer ...

So if we would get some helping hand what exactly technically needs to
be done, we could try to come up with some solution.

Post by Cyril Brulebois
Of course, if blends support ends up not being merged for Jessie, I'm
very sorry for people having participated in the discussion and their
false hope. :(

Well, after more than ten years work on this the time of "false hope" is
over. ;-) I'm really happy about the "no incentive to prevent other
people from working on this". Perhaps some slight hint - perhaps even
from Joey - would help to get this done.

Kind regards

Andreas.

[1] http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/987_How_to_attract_new_developers_for_your_team.ogv
... or instead of spending time into the full video you rather might
like to simply browse the subtitles starting at line 2379
http://anonscm.debian.org/cgit/debconfsubs/debconfsubs.git/tree/2013/DebConf13/english/987_How_to_attract_new_developers_for_your_team.en.srt
[2] http://blends.debian.org/med/tasks/cloud
[3] https://people.debian.org/~tille/talks/
[4] Loading Image...

[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#135

Cyril Brulebois

2014-10-14 08:20:01 UTC

Hi again Andreas,

Post by Cyril Brulebois
well to be honest the whole blend story came as a surprise.

Ahhh, this in turn is surprising for me since the first "version" of
this bug is dated 24 Mar 2003 (#186085) :-). But I agree that Blends
are not widely known even if I was proactively running around since
more than ten years telling people
"Is there a topic in Debian you care about? Create a Blend today!"
as Asheesh advised me in last years DebConf talk[1 - just see the
linked subtitles text to save time - it is *very* speaking for the
whole topic!]
In other words: I perfectly know the fact that Blends are widely
ignored even amongst Debian developers and that's not about you / the
debian-boot team - perhaps my "running around and tell people" is just
not the right way to convince people. At least I can tell that those
people who were listening started to like the idea [see 1].

to clarify a bit: my surprise was about blends support in tasksel/d-i.
I've known about blends for a while but I don't think that topic popped
up in my debian-boot radar during the whole Jessie release cycle.

Post by Cyril Brulebois
I think we identified quite early in the release cycle that we would
need to finally do something about the desktop situation (which first
landed in D-I Jessie Beta 2).

I meant the needed changes in tasksel to support both desktop selection
and blends.

Post by Cyril Brulebois
Blends were first mentioned during a DC'14 talk in late August.

BlendsâŠ support in d-i (during this release cycle) was what I meant,
sorry for being unclear. Hopefully that was covered by the above
clarification. ;)

Post by Cyril Brulebois
At the moment my personal feeling about this is that it looks a bit
late, and I'm almost certainly not going to drive such changes
myself.

That really isn't true, there are many other developers, reporters, and
patch providers. I'm only adding glue or oil where neededâŠ Of course we
could do with more hands (look at the BTS), but I'm far for being the
only one working on d-i.

Post by Cyril Brulebois
I don't have any strong incentive to prevent other people from
working on this though. (Of course, any work should happen sooner
than later.)

That's in fact a quite motivating incentive and I perfectly agree that
we really should start rather yesterday than today. The thing is that
it is not really clear to me, what we should do rather than adding the
packages
edu-tasks
games-tasks
gis-tasks
junior-tasks
med-tasks
science-tasks
debichem-tasks
ezgo-tasks
(multimedia-tasks is not ready according to their maintainer[5]) to the
boot disks.
Joey Hess as tasksel maintainer mentioned "limited amount of space in
tasksel for blends" but this does not give a sensible hint of what exact
action we should do now. I think currently eight additional lines is
not that much. I also totally contradict to Joey's statement "The
'Debian Pure Blends' effort has been around for several releases and
been publicised." and I take [1] as sufficient argument that it is not
the case. Blends were never ever regarded in practice as some Debian
internal thing and *every* time when I talk about Blends on conferences
and in private discussions I will be asked: "Why don't you do this cool
stuff right into Debian instead of a derivative?" It would *really*
help in this kind of discussion to point to the Debian installer ...
So if we would get some helping hand what exactly technically needs to
be done, we could try to come up with some solution.

I'm not sure we have 8 slots at the moment. I'm pretty sure a scrollbar
(if at all feasible) in a multi-choice menu would be a bad idea. Maybe
we'd need a separate prompt for blends. Joey will likely be able to tell
you more about this.

Mraw,
KiBi.

Andreas Tille

2014-10-14 09:30:02 UTC

Hi Cyril,

Post by Andreas Tille
In other words: I perfectly know the fact that Blends are widely
ignored even amongst Debian developers and that's not about you / the
debian-boot team - perhaps my "running around and tell people" is just
not the right way to convince people. At least I can tell that those
people who were listening started to like the idea [see 1].

I admit I expected *you* to know about Blends for a while - but
considering the video recorded quote I think I was not wrong using this
chance to point this out for other readers of this mail as it is really
a fact that I always meet DDs who mix up this concept with derivatives.

Post by Andreas Tille
Well, Blends and "the desktop situation" could be considered orthogonal.
The main goal of a Blend is not primarily to tweak the desktop (even if
this could be done). It is rather about the applications. In Debian
Med we even have a cluster task which contains exclusively those
packages which can be run without a graphical desktop (bio-cloud [2]).

I meant the needed changes in tasksel to support both desktop selection
and blends.

OK.

Post by Andreas Tille
...
earlier, yes. The reason why at least I stayed away from this since
2003 (#186085) was that I have seen little chances to change the
refusal. However, since recently some Blends of some more general
interest like Debian Games and Debian GIS started or gained some
traktion resp. the idea came up to rise this question on IRC in the
DebConf talk.

Blends… support in d-i (during this release cycle) was what I meant,
sorry for being unclear. Hopefully that was covered by the above
clarification. ;)

Yes it was. :-) However, I also had taken the chance to refer to an
earlier bug (perhaps also to review its old arguments).

Post by Andreas Tille
I perfectly agree that you as the one person army keeping Debian Boot
alive (hey, do you like the Blends born idea to prove this point[4]??)
should not spend extra time cycles into the implementation.

That really isn't true, there are many other developers, reporters, and
patch providers. I'm only adding glue or oil where needed… Of course we
could do with more hands (look at the BTS), but I'm far for being the
only one working on d-i.

I agree that my term was a bit in terms of a compliment in the sense of
a "friendly lie". I was not trying to underestimate the work of those
people who are providing smaller contributions. However, you really
find lots of graphs similar like[4] which show the feature of one
dominant person at a certain time. Perhaps you take this as: Thanks
for the effort you spent obviously for debian-boot.

Post by Andreas Tille
That's in fact a quite motivating incentive and I perfectly agree that
we really should start rather yesterday than today. The thing is that
it is not really clear to me, what we should do rather than adding the
packages
edu-tasks
games-tasks
gis-tasks
junior-tasks
med-tasks
science-tasks
debichem-tasks
ezgo-tasks
(multimedia-tasks is not ready according to their maintainer[5]) to the
boot disks.
Joey Hess as tasksel maintainer mentioned "limited amount of space in
tasksel for blends" but this does not give a sensible hint of what exact
action we should do now. I think currently eight additional lines is
not that much. I also totally contradict to Joey's statement "The
'Debian Pure Blends' effort has been around for several releases and
been publicised." and I take [1] as sufficient argument that it is not
the case. Blends were never ever regarded in practice as some Debian
internal thing and *every* time when I talk about Blends on conferences
and in private discussions I will be asked: "Why don't you do this cool
stuff right into Debian instead of a derivative?" It would *really*
help in this kind of discussion to point to the Debian installer ...
So if we would get some helping hand what exactly technically needs to
be done, we could try to come up with some solution.

I'm not sure we have 8 slots at the moment. I'm pretty sure a scrollbar
(if at all feasible) in a multi-choice menu would be a bad idea.

I agree here. However, I think it would be a shame to drop a good idea
(and as far as I understood the responses to the bug it is considered
good by several people) since we failed to find a sensible menu design.

Post by Cyril Brulebois
Maybe we'd need a separate prompt for blends.

I perfectly agree that some additional menu level would be the most
natural way in my eyes. I think I mentioned this before. Hmmm, just
wondering why I can't find this term in the previous bugreport(s) since
I always imagined this. May be there is no instance of this since there
never was a real discussion whether we should do it at all and thus
implementation details were not discussed at all.

Post by Cyril Brulebois
Joey will likely be able to tell
you more about this.

I'm keen in hearing this. :-)

Kind regards

Andreas.

[4] http://blends.debian.net/liststats/authorstat_debian-boot.png

Bas Wijnen

2014-10-14 17:30:02 UTC

Post by Andreas Tille
I admit I expected *you* to know about Blends for a while - but
considering the video recorded quote I think I was not wrong using this
chance to point this out for other readers of this mail as it is really
a fact that I always meet DDs who mix up this concept with derivatives.

I have heard about them for quite a while, indeed, but I must say that I
never entirely understood what they are. I'm guessing I'm not alone in
this. So let me write what I think they are, and then you can correct
me. I've read the explanation on the wiki, but I'm still not sure if I
understand it right.

I think a blend is a system you can install, which after installing is a
regular Debian system, set up for a particular task. Because it's a
regualr Debian system, after installation packages can be installed and
removed just like on any other Debian system, and any other system can
be turned into a blend by installing the right packages.

From the wiki, it seems that is just the "Pure Blend", because other
Blends may have extra apt sources.

Is this a good summary?

If so, I think it would be a very good idea to make this part of the
installer. And turn the default system into "just another blend".

Regardless of whether my summary is good, I think the documentation can
use some improvement. Examples of the target audience would be useful.
What is made possible or easier with blends? What is often confused
with it, but isn't actually related? I admit I didn't spend a lot of
time trying to find answers to these questions, but I think it shouldn't
require a large time investment.

Post by Andreas Tille
Well, Blends and "the desktop situation" could be considered orthogonal.

Do all blends work well with all desktop environments? I can see how
some blends would focus to make things work perfectly with one of them
only. In such a case, it makes sense to omit the desktop selection
after such a blend is selected, or at least let the blend define the
default.

Thanks,
Bas

Jonas Smedegaard

2014-10-14 18:40:04 UTC

Quoting Bas Wijnen (2014-10-14 19:19:36)

I have heard about [Blends] for quite a while, indeed, but I must say
that I never entirely understood what they are. I'm guessing I'm not
alone in this. So let me write what I think they are, and then you
can correct me. I've read the explanation on the wiki, but I'm still
not sure if I understand it right.

[snip]

This is the canonical definition:
https://wiki.debian.org/DebianPureBlends#Terminology

If that's the text you found confusing, please do help by elaborating
what was confusing about it.

Post by Andreas Tille
Well, Blends and "the desktop situation" could be considered orthogonal.

Do all blends work well with all desktop environments?

No.

I can see how some blends would focus to make things work perfectly
with one of them only. In such a case, it makes sense to omit the
desktop selection after such a blend is selected, or at least let the
blend define the default.

Good point!

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private

Andreas Tille

2014-10-15 07:40:02 UTC

Hi,

Post by Andreas Tille
Well, Blends and "the desktop situation" could be considered orthogonal.

Do all blends work well with all desktop environments?

No.

While this "no" means: There exist 1 or 2 Blends focussing on a
specific desktop environment (as far as I know Debian Edu and Ezgo) but
others work perfectly well under all desktop environments. So the
answer is mathematical correct but a bit short to understand the full
picture.

Kind regards

Andreas.

PS: I'll answer Bas' question tomorrow in more detail but I'm to
tired today.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-blends-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@an3as.eu

--
To UNSUBSCRIBE, email to debian-boot-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@an3as.eu

Andreas Tille

2014-10-15 09:20:03 UTC

Hi Holger,

Hi,

Post by Andreas Tille
While this "no" means: There exist 1 or 2 Blends focussing on a
specific desktop environment (as far as I know Debian Edu and Ezgo) but

Debian Edu offers you the documented choices between KDE Plasma (default),
Gnome, Mate, Xfce4, LXDE and Sugar. (And for jessie+1 hopefully Cinnamon too.)
And as the documentation also says you can apt-get install anything else you
wish from Debian too.
So no, Debian Edu doesnt focus on a specific desktop anymore. A few years ago
KDE was *the* choice, but iirc that was until ~2009 or 10.

Thanks for the clarification. In this case I'd answer the question from
Bas

Do all blends work well with all desktop environments?

rather with "yes".

I'll send this to the other lists where the question came up to. At
some point we should stop cross-posting to several lists, but since the
topic about the installer is relevant for debian-boot as well I'm not
sure whether it is good to leave this out.

Kind regards

Andreas.

--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@an3as.eu

Andreas Tille

2014-10-15 07:40:02 UTC

Hi Bas,

I have heard about them for quite a while, indeed, but I must say that I
never entirely understood what they are. I'm guessing I'm not alone in
this.

You belong to a majority if I might conclude from my experience. I have
no idea whether I should feel responsible for this but I'm fighting on
several fronts like the extensive documentation[1] and countless
talks[2] as well as trying to push newcomers into the topic by
sponsering their packages[3].

Post by Bas Wijnen
So let me write what I think they are, and then you can correct
me. I've read the explanation on the wiki, but I'm still not sure if I
understand it right.
I think a blend is a system you can install, which after installing is a
regular Debian system, set up for a particular task. Because it's a
regualr Debian system, after installation packages can be installed and
removed just like on any other Debian system, and any other system can
be turned into a blend by installing the right packages.

For the moment the way to install Blends is to use the plain Debian
installer and afterwards install a bunch of metapackages. There is one
exception Debian Edu / Skolelinux which uses dedicated installation
medias with pre-feeded debconf data. There is a long standing
discussion whether Debian Edu deserves the term "pure" but I will not
dive into this can of worms since I do not want to spoil the general
picture here with details caused by a single bug (Debian Edu people will
know it by heart). The lack of a missing installer for all other Blends
is a frequently criticised problem and I personally think this should be
fixed by the integration into the official boot cds since this fits to
the nature of Blends which are a subset of Debian.

I'd like to add some informal ideas about Blends to perhaps give a
better picture of the idea:

- Several people entertain deriving from Debian and actually the never
ending misconception about Blends is that they are derivatives. But
Blends are derivatives "done the right way" - by not deriving Debian
and rather do the adaptations inside Debian. The goal is to save
time and prevent reinventing the wheel on the (non)derivers side and
to bundle forces right into Debian.
- Blends are a way to advertise Debian in specific fields of interest
I personally started from a point where I wanted to reach a status,
that if somebody wonders what distribution to use for biology and
medical care the natural answer should be "Use Debian" We could
easily reach this goal for other fields of interest if all our
dedicated experts we had in Debian would work on this direction in
their own field.
- Blends is also about forming teams inside Debian to care for a
certain topic to serve as glue between upstream and the end user and
if you have watched[4] (as advised in my last mail) you not only get
an idea about how we form teams but about the Blends concept in
general.

Post by Bas Wijnen
From the wiki, it seems that is just the "Pure Blend", because other
Blends may have extra apt sources.

There might be additional apt sources but it is not only about apt
sources. For instance (as far as I'm informed) all packages in Debian
Edu are inside Debian and there was just a need to change some
configuration change of some *other* packages which conflicts with
Debian policy (I'm pretty sure Jonas will respond in detail to this mail
- so I save my time here B-)). The whole pure / non-pure discussion is
from my personal point of view a consequence of nitpicking about policy
compliance which was born out of the problem that some package
maintainers are not willing to accept some more flexible debconf
configuration options. I agree that policy is something to be really
picky about and will not argue against this but on the other hand it
spoils a bit the simplicy to understand the whole concept. So a "Debian
Pure Blend" (I use the shortcut "Blend" as a synonym) is fully
integrated into Debian while "non-pure" Blends are trying to approach
the full Debian integration but some minor pieces like a hand full of
packages or some policy conflicting stuff remain on their todo list.

Post by Bas Wijnen
Is this a good summary?

I hope I added some more points to this summary.

Post by Bas Wijnen
If so, I think it would be a very good idea to make this part of the
installer. And turn the default system into "just another blend".

Sounds like a nice view on the Blends concept. :-)

Post by Bas Wijnen
Regardless of whether my summary is good, I think the documentation can
use some improvement.

+1
That's always needed.

Post by Bas Wijnen
Examples of the target audience would be useful.

Hmmmm. I had thought / hoped that this is documented in[5].
Enhancements / patches(source is in package source of blends source
package) are always welcome.

Post by Bas Wijnen
What is made possible or easier with blends?

Installation of a set of packages needed for a specific field of
interest. Providing an overview for newcomers about all packages of a
specific field of interests. Here are examples for gamers (task list of
Debian Games [6]) and for scientists (task list of Debian Science [7])
I'm working surrounded by biologists and epidemiologists and I'm just
pointing my (non-Linux using!) colleagues frequently to the according
tasks pages ([8] resp. [9]) of Debian Med to show them what they are
missing by not using Debian.

It would be great to add to these tasks pages the hint that you simply
can click on the according task on the plain Debian installer to get all
these packages installed (even if everybody could install the tasks
manually later also easily).

Post by Bas Wijnen
What is often confused
with it, but isn't actually related?

Derivatives are confused all the times (which is one problem of the
previous name which was "Custom Debian Distributions" ... if I only had
vetoed against this term from the first moment :-()

Post by Bas Wijnen
I admit I didn't spend a lot of
time trying to find answers to these questions, but I think it shouldn't
require a large time investment.

Do you think I should add these answers to the Wiki page with the
relevant links?

Post by Andreas Tille
Well, Blends and "the desktop situation" could be considered orthogonal.

As far as I know Debian Edu installs KDE and Ezgo also installs
task-kde-desktop. I'm not aware that any other Blend would prefer any
desktop environment. I personally do not see the definition of a
specific desktop as primary goal of a Blend. These both Blends decided
that for their primary goal education KDE would fit better than others
which I have no opinion on since I'm neither in education nor do I use
KDE.

Hope this additional explanation helps

Andreas.

[1] http://blends.debian.org/blends/
[2] http://people.debian.org/~tille/talks/
[3] http://wiki.debian.org/DebianPureBlends/SoB
[4] http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/987_How_to_attract_new_developers_for_your_team.ogv
... or instead of spending time into the full video you rather might
like to simply browse the subtitles starting at line 2379
http://anonscm.debian.org/cgit/debconfsubs/debconfsubs.git/tree/2013/DebConf13/english/987_How_to_attract_new_developers_for_your_team.en.srt
[5] http://blends.debian.org/blends/ch04.html
[6] http://blends.debian.org/games/tasks/
[7] http://blends.debian.org/science/tasks/
[8] http://blends.debian.org/med/tasks/bio
[9] http://blends.debian.org/med/tasks/epi

Bas Wijnen

2014-10-15 18:00:02 UTC

Hi,

Post by Andreas Tille
You belong to a majority if I might conclude from my experience. I have
no idea whether I should feel responsible for this but I'm fighting on
several fronts like the extensive documentation[1] and countless
talks[2] as well as trying to push newcomers into the topic by
sponsering their packages[3].

Yes, I noticed. Thanks for all that work!

Post by Andreas Tille
For the moment the way to install Blends is to use the plain Debian
installer and afterwards install a bunch of metapackages.

Ah, and that's what you want to change now. That sounds like a very
good idea.

Post by Andreas Tille
The lack of a missing installer for all other Blends is a frequently
criticised problem and I personally think this should be fixed by the
integration into the official boot cds since this fits to the nature
of Blends which are a subset of Debian.

Yes, I agree. For the documentation, I think the main thing that is
missing is "how to start and stop"; important for every documentation.
"Stopping" isn't really relevant in this case (but it doesn't hurt to
mention that the metapackage can be uninstalled). But "To use a Blend,
you need to install its metapackage" would have clarified it for me.
Once it is possible, it would be very nice if "there is an option to do
this during system install" could be added to that.

Post by Andreas Tille
- Blends are a way to advertise Debian in specific fields of interest
I personally started from a point where I wanted to reach a status,
that if somebody wonders what distribution to use for biology and
medical care the natural answer should be "Use Debian" We could
easily reach this goal for other fields of interest if all our
dedicated experts we had in Debian would work on this direction in
their own field.

On occasion, I've needed a single-use system; something that boots up
into an application and that shuts down when that application exits.
(Having the full power of Debian in the background is a nice feature,
but mostly unused.) For example, for dancing rehearsal I want the
instructors to be able to switch their computer on and have the sound
program start up without any interaction. It isn't hard to set this up,
but if I want to tell other dancing instructors how to do this, it
requires more steps than I would like. I've tried making custom live
CDs, with a special package that does these things.

Would this use case also be a reason for creating a personal blend? Or
even an official one? What would be the easiest way for people to
install a non-official blend? Should I create my own installer? Should
the installer be changed to allow entering a URL (for an external apt
source) before it presents the list of available blends? (I think this
might be a good idea, but it shouldn't be in there by default; only when
the user selects "back" on the blend selection menu. Or perhaps there
can be a button in that menu for opening the dialog, but if it's for
adding any apt repository, the blends dialog is not the right place for
it.)

Post by Andreas Tille
There might be additional apt sources but it is not only about apt
sources. For instance (as far as I'm informed) all packages in Debian
Edu are inside Debian and there was just a need to change some
configuration change of some *other* packages which conflicts with
Debian policy (I'm pretty sure Jonas will respond in detail to this mail
- so I save my time here B-)).

So it installs a package which changes configuration of other packages
when it is installed? That sounds very ugly... Isn't there a better
way to preconfigure a system?

Post by Andreas Tille
I hope I added some more points to this summary.

Yes, thank you.

Post by Bas Wijnen
Examples of the target audience would be useful.

Hmmmm. I had thought / hoped that this is documented in[5].

It is, but I think it's too much text and too far away. It's good that
it's there, but I think it would be good to have on the first page
people are pointed to (which one is that anyway? The one in the wiki?)
a one-line explanation that is understandable. The definition of "Pure
Blend" on https://wiki.debian.org/DebianPureBlends is "a subset of
Debian that is configured to support a particular target group
out-of-the-box." That does not give me enough information to know if I
should be interested enough to read any further.

Oh, and I have another question; this seems very similar to "tasks"; how
is it different?

Post by Andreas Tille
Enhancements / patches(source is in package source of blends source
package) are always welcome.

I might write a patch, but knowing myself I probably don't get around to
actually do that.

Post by Bas Wijnen
I admit I didn't spend a lot of
time trying to find answers to these questions, but I think it shouldn't
require a large time investment.

Do you think I should add these answers to the Wiki page with the
relevant links?

Yes, that would be good. But it should be as short as possible; less
text is better. However, currently it is not enough text, I think,
which is of course worse.

Post by Andreas Tille
Hope this additional explanation helps

Yes, thanks!
Bas

Jonas Smedegaard

2014-10-15 19:40:01 UTC

Quoting Bas Wijnen (2014-10-15 19:49:32)

Post by Bas Wijnen
On occasion, I've needed a single-use system; something that boots up
into an application and that shuts down when that application exits.
(Having the full power of Debian in the background is a nice feature,
but mostly unused.) For example, for dancing rehearsal I want the
instructors to be able to switch their computer on and have the sound
program start up without any interaction. It isn't hard to set this
up, but if I want to tell other dancing instructors how to do this, it
requires more steps than I would like. I've tried making custom live
CDs, with a special package that does these things.
Would this use case also be a reason for creating a personal blend?
Or even an official one? What would be the easiest way for people to
install a non-official blend? Should I create my own installer?
Should the installer be changed to allow entering a URL (for an
external apt source) before it presents the list of available blends?
(I think this might be a good idea, but it shouldn't be in there by
default; only when the user selects "back" on the blend selection
menu. Or perhaps there can be a button in that menu for opening the
dialog, but if it's for adding any apt repository, the blends dialog
is not the right place for it.)

That sounds like an excellent idea for a Blend!

You raise a bunch of questions on how that idea should be implemented
and work out in details - but that has is open for you as driver of a
Blend to figure out.

If you do decide to start create above as a Blend, and would be
interested in collaborating (with me), please do count me in! I have
fumbled with a few ideas in the past that seems to fit perfectly to
above (e.g. a dead-simple videophone "PhoneHome" dialing a hardcoded
number, or a party jukebox with a touch keyboard (no avoid spilling
liquids into a real keyboard, or a gaming box to pacify visiting kids,
or...).

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private

Andreas Tille

2014-10-16 06:50:01 UTC

Hi Bas,

Post by Andreas Tille
For the moment the way to install Blends is to use the plain Debian
installer and afterwards install a bunch of metapackages.

Ah, and that's what you want to change now. That sounds like a very
good idea.

:-)

I'll put this on my todo list for 2014-11-05+x.

Jonas has answered this question. I'd like to add that I'm no fan of
"personal" things since you spoil the idea of forming a team around the
idea. I could perfectly imagine such a Blend and every specific
application is a separate "task" (in the Blends slang). So you can
assemble those people with the goal to run one dedicated application.

Post by Bas Wijnen
What would be the easiest way for people to
install a non-official blend? Should I create my own installer? Should
the installer be changed to allow entering a URL (for an external apt
source) before it presents the list of available blends? (I think this
might be a good idea, but it shouldn't be in there by default; only when
the user selects "back" on the blend selection menu. Or perhaps there
can be a button in that menu for opening the dialog, but if it's for
adding any apt repository, the blends dialog is not the right place for
it.)

Well, these are good questions. They are abit hard to answer in a
situation when we are discussing about how to properly install the
currently existing Blends.

So it installs a package which changes configuration of other packages
when it is installed? That sounds very ugly... Isn't there a better
way to preconfigure a system?

Yes. The better way is to convince the single package maintainers. The
longish discussion is in bug #311188.

Post by Andreas Tille
Hmmmm. I had thought / hoped that this is documented in[5].

Also todo list for 2014-11-05+x.

Post by Bas Wijnen
Oh, and I have another question; this seems very similar to "tasks"; how
is it different?

Each Blend creates metapackages and a <blenname>-tasks package to feed
tasksel. Yes, we are using this term actively. The difference is more
in the content that the tasks are specific for fields of interest but
the used technique is the same (which is intentional to enable
integration into the installer easily).

Post by Andreas Tille
Enhancements / patches(source is in package source of blends source
package) are always welcome.

I might write a patch, but knowing myself I probably don't get around to
actually do that.

... as always with documentation. :-) The same applies to me to some
extend (and I'm not proud about this).

Post by Andreas Tille
Do you think I should add these answers to the Wiki page with the
relevant links?

Yes, that would be good. But it should be as short as possible; less
text is better. However, currently it is not enough text, I think,
which is of course worse.

Thanks for the helpful hints.

Kind regards

Andreas.

Jonas Smedegaard

2014-10-16 09:50:03 UTC

Quoting Andreas Tille (2014-10-16 08:47:19)

Jonas has answered this question. I'd like to add that I'm no fan of
"personal" things since you spoil the idea of forming a team around
the idea. I could perfectly imagine such a Blend and every specific
application is a separate "task" (in the Blends slang). So you can
assemble those people with the goal to run one dedicated application.

And I fully agree with Andreas: I assumed you were talking about "Debian
Blends" as defined at
https://wiki.debian.org/DebianPureBlends#Terminology and that you
therefore really a generally reusable Blend (sparked by personal _needs_
which I see as a perfectly fine drive for creating a Debian Blend).

I am sorry if I twisted your meaning.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private

Bas Wijnen

2014-10-16 18:30:02 UTC

Hello,

Post by Bas Wijnen
Would this use case also be a reason for creating a personal blend? Or
even an official one?

Jonas has answered this question. I'd like to add that I'm no fan of
"personal" things since you spoil the idea of forming a team around the
idea.

Yes, I agree. However, sometimes the needs are so specific that it
doesn't make sense to do them on a larger scale. I'd make the packages
public, but I wouldn't suggest that a blend for very limited use
deserves a prominent position in the installer.

But as Jonas pointed out, if the blend only does the setup for running a
single application and any application can be chosen at install time,
that increases the audience to a point where it may deserve that
position.

I'll consider if I want to drive that effort. I'd really like to see
this happen, but I'm also trying to limit new projects I start, so that
I have enough time to handle the things I do properly. If more people
(besides Jonas) are interested, please let me know privately. If you
want to be the driver, definitely let me know, too. :-)

I'll send a status update by the end of the month.

Post by Andreas Tille
Well, these are good questions. They are abit hard to answer in a
situation when we are discussing about how to properly install the
currently existing Blends.

Indeed. Someone should remember to bring them back up once that question
has been answered (and the answer has been implemented).

Post by Bas Wijnen
So it installs a package which changes configuration of other packages
when it is installed? That sounds very ugly... Isn't there a better
way to preconfigure a system?

Yes. The better way is to convince the single package maintainers. The
longish discussion is in bug #311188.

Reading that raises questions regarding the configuration editing tool I
wrote about some time ago. I'll follow up to that thread (on -devel
only).

Post by Bas Wijnen
Oh, and I have another question; this seems very similar to "tasks"; how
is it different?

Ok. Is it supposed to be possible to install more than one blend
simultaneously? Is that technically prevented with Conflicts?

Post by Andreas Tille
Enhancements / patches(source is in package source of blends source
package) are always welcome.

I might write a patch, but knowing myself I probably don't get around to
actually do that.

... as always with documentation. :-) The same applies to me to some
extend (and I'm not proud about this).

No, I'm not proud of it either. But as Feynman said: "you [yourself]
are the easiest person to fool." So I take some pride in admitting it;
telling myself otherwise would have been easier. ;-)

Thanks,
Bas

Andreas Tille

2014-10-16 20:40:01 UTC

Hi Bas,

Post by Bas Wijnen
Ok. Is it supposed to be possible to install more than one blend
simultaneously? Is that technically prevented with Conflicts?

Not at all. I have not tested but I would bet that you can install all
existing metapackages of all Blends at the same time. Conflicts do not
make any sense to the contrary it makes sense to install say med-bio and
science-typesetting at the same time (just to say a random example).

Post by Andreas Tille
... as always with documentation. :-) The same applies to me to some
extend (and I'm not proud about this).

No, I'm not proud of it either. But as Feynman said: "you [yourself]
are the easiest person to fool." So I take some pride in admitting it;
telling myself otherwise would have been easier. ;-)

:-)

Kind regards

Andreas.

Andreas Tille

2018-08-16 08:40:02 UTC

Hi,

to give some status information about how we can make Blends more
visible at installer stage: Holger Levsen, Phil Hands, Steve McIntyre
and I had some discussion in DebCamp. The conclusion was that adding
Blends to the installer tasksel menu would be perfectly possible if
tasksel itself would provide some menu hierarchy. We all agreed that
the current selection of tasks needs some overhaul in general. It
could provide some menu item:

"Select Blend" (or rather some better text here!)

and than you get a selection of Blends to pick (one or more) from.

For the Stretch release Phil even wrote some code in this direction that
needs some refresh. (Phil, can you give some pointer if there is
something to test?)

Any comments / code contributions are welcome.

Kind regards

Andreas.

PS: Please correct me if my short summary is incomplete.

--
http://fam-tille.de

Filippo Rusconi

2018-08-16 09:00:01 UTC

Greetings, Andreas, and everybody,

Post by Andreas Tille
Hi,
to give some status information about how we can make Blends more
visible at installer stage: Holger Levsen, Phil Hands, Steve McIntyre
and I had some discussion in DebCamp. The conclusion was that adding
Blends to the installer tasksel menu would be perfectly possible if
tasksel itself would provide some menu hierarchy. We all agreed that
the current selection of tasks needs some overhaul in general. It
"Select Blend" (or rather some better text here!)
and than you get a selection of Blends to pick (one or more) from.
For the Stretch release Phil even wrote some code in this direction that
needs some refresh. (Phil, can you give some pointer if there is
something to test?)
Any comments / code contributions are welcome.

Please, add some small strophe to explain what a blend is, as I can tell that
this is not something widely known even to seasoned Debian users/admins (have
examples from research labs).

Also, when I installed debian-science and debichem last time, the process
downloaded such an amount of software that it almost filled my disk (which I was
not suspecting). Maybe, a rough indication of the used disk space in front of
each blend might be useful, in this respect.

Just my 2 cents, along with my very best wishes,

Filippo

--
⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁ Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄⠀⠀⠀⠀ http://msxpertsuite.org
http://www.debian.org

Andreas Tille

2018-08-16 11:50:02 UTC

Hi Ole,

Post by Filippo Rusconi
Also, when I installed debian-science and debichem last time, the process
downloaded such an amount of software that it almost filled my disk (which I was
not suspecting). Maybe, a rough indication of the used disk space in front of
each blend might be useful, in this respect.

I would not include debian-science to the blends listed in the
installer: it is more an umbrella to organize the packages then a useful
selection of software. The software selection is also inconsitent: it
only contains software that is not maintained by a more specialized
blend (like debichem).
So, there is probably no real use case to install Debian Science in its
current form (unless someone takes the work to kurate a "Generic Debian
Science Workstation" or so).

True. There might be some general use in may be the following tasks:

https://blends.debian.org/science/tasks/dataacquisition
https://blends.debian.org/science/tasks/distributedcomputing
https://blends.debian.org/science/tasks/statistics
https://blends.debian.org/science/tasks/typesetting
https://blends.debian.org/science/tasks/viewing

(or even a subset of these). I'm not very keen on having these but may
be this could be a topic to discuss.

On our last attempt, we had an opt-in for the blends to be in the
installer; I would propose the same now as well.

Definitely

Andreas.

--
http://fam-tille.de

Andreas Tille

2018-12-03 21:40:02 UTC

Hi,

somehow I've thought I would have pinged about this one and I even
somehow remember that Holger liked that I did so but I do not find and
trace of this in my outbox nor the mailing list archive. So may be I
have dreamed this. It would be a real dream if we could finally realise
this 15 year old idea to have Blends right in the installer. Is there
any work in progress that could be tested?

Kind regards

Andreas.

--
http://fam-tille.de

Andreas Tille

2019-12-18 07:30:02 UTC

Hi Steve,

the first alpha of the installer of Debian 11 is out. As we talked at
DebConf about better Blends support: Is there anything we can test
regarding tasksel?

Kind regards

Andreas.

Post by Andreas Tille
Hi,
somehow I've thought I would have pinged about this one and I even
somehow remember that Holger liked that I did so but I do not find and
trace of this in my outbox nor the mailing list archive. So may be I
have dreamed this. It would be a real dream if we could finally realise
this 15 year old idea to have Blends right in the installer. Is there
any work in progress that could be tested?
Kind regards
Andreas.

--
http://fam-tille.de

Steve McIntyre

2020-01-06 16:30:02 UTC

Hey Andreas!

Post by Andreas Tille
the first alpha of the installer of Debian 11 is out. As we talked at
DebConf about better Blends support: Is there anything we can test
regarding tasksel?

Not yet, I'm afraid. A little too swamped so far, but you're near the
top of my TODO list. I'm hoping to get some time for development on
this in the next couple of months.

--
Steve McIntyre, Cambridge, UK. ***@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Steve McIntyre

2020-03-23 19:20:01 UTC

Post by Steve McIntyre
Hey Andreas!

Post by Andreas Tille
the first alpha of the installer of Debian 11 is out. As we talked at
DebConf about better Blends support: Is there anything we can test
regarding tasksel?

Not yet, I'm afraid. A little too swamped so far, but you're near the
top of my TODO list. I'm hoping to get some time for development on
this in the next couple of months.

(Overdue!) update: I've been hacking on this for a while, and I hope
to have a prototype for testing up shortly. It works fine on my local
system, but in a test d-i build it fails totally so I've clearly
missed something! Debugging that now...

--
Steve McIntyre, Cambridge, UK. ***@einval.com
Getting a SCSI chain working is perfectly simple if you remember that there
must be exactly three terminations: one on one end of the cable, one on the
far end, and the goat, terminated over the SCSI chain with a silver-handled
knife whilst burning *black* candles. --- Anthony DeBoer

Andreas Tille

2020-03-24 06:50:02 UTC

Hi Steve,

Post by Steve McIntyre

Post by Steve McIntyre
Not yet, I'm afraid. A little too swamped so far, but you're near the
top of my TODO list. I'm hoping to get some time for development on
this in the next couple of months.

Thanks a lot. Its really appreciated. I hope that other Blends step in
with testing since I guess the next monthes I'm busy with COVID-19
issues.

Thank you for the update

Andreas.

--
http://fam-tille.de

Andreas Tille

2020-10-06 16:10:01 UTC

Hi Steve,

Post by Steve McIntyre

Post by Steve McIntyre
Not yet, I'm afraid. A little too swamped so far, but you're near the
top of my TODO list. I'm hoping to get some time for development on
this in the next couple of months.

I wonder whether I might have missed some information whether there
is something I could test meanwhile.

Kind regards and thanks for all your work for the installer

Andreas.

--
http://fam-tille.de

Steve McIntyre

2020-10-08 09:30:01 UTC

Hey Andreas! I hope you're keeping well!

Post by Steve McIntyre

Post by Steve McIntyre
Not yet, I'm afraid. A little too swamped so far, but you're near the
top of my TODO list. I'm hoping to get some time for development on
this in the next couple of months.

I wonder whether I might have missed some information whether there
is something I could test meanwhile.

I'm afraid that various higher-priority interrupts came up (new job,
UEFI security work) and I got side-tracked for a while. You must be
psychic - I just started picking things up again last weekend.

--
Steve McIntyre, Cambridge, UK. ***@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters are forecast."
Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Andreas Tille

2020-10-08 13:30:01 UTC

Hi Steve,

Post by Steve McIntyre
Hey Andreas! I hope you're keeping well!

Thanks, I'm perfectly fine. I hope you as well.

Post by Steve McIntyre
You must be
psychic - I just started picking things up again last weekend.

Argh, now you have made my deepest secret public! ;-)
Thanks for picking it up and let us know if there is something
to test

Andreas.

--
http://fam-tille.de

Andreas Tille

2021-03-02 13:50:01 UTC

Hi Steve,

Post by Steve McIntyre
Hey Andreas! I hope you're keeping well!

Post by Steve McIntyre
(Overdue!) update: I've been hacking on this for a while, and I hope
to have a prototype for testing up shortly. It works fine on my local
system, but in a test d-i build it fails totally so I've clearly
missed something! Debugging that now...

I wonder whether I might have missed some information whether there
is something I could test meanwhile.

I'm afraid that various higher-priority interrupts came up (new job,
UEFI security work) and I got side-tracked for a while. You must be
psychic - I just started picking things up again last weekend.

I admit I did not payed much attention on the development of tasksel and
thus the chances to select Blends right from the installer. The topic
remains to be urgent for all Blends - but I'm afraid it will be to late
for Debian 10. Or did I missed something and the status is promising
for this release?

Kind regards and thanks for all your attempts anyway

Andreas.

--
http://fam-tille.de

Steve McIntyre

2021-03-06 17:00:01 UTC

Hey Andreas!

Post by Steve McIntyre
Hey Andreas! I hope you're keeping well!

I wonder whether I might have missed some information whether there
is something I could test meanwhile.

I'm afraid that various higher-priority interrupts came up (new job,
UEFI security work) and I got side-tracked for a while. You must be
psychic - I just started picking things up again last weekend.

Andreas Tille

2021-11-14 07:50:02 UTC

Hi Steve,

Post by Steve McIntyre
I've made a *small* amount of progress at hacking on debconf (route
#2). But again I've had other things come up, not least another round
of Secure Boot fixes. We're not going to have changes in for
Bullseye. Sorry. :-(

Do you see any chance to get this for Bookworm?

Kind regards

Andreas.

--
http://fam-tille.de

Andreas Tille

2022-01-10 16:40:02 UTC

Hi Steve,

a new release cycle has started. Do you think it is possible to
implement this long wanted feature for the next release?

Kind regards and happy new year

Andreas.

Post by Steve McIntyre
Hey Andreas!

Post by Steve McIntyre
Hey Andreas! I hope you're keeping well!

I wonder whether I might have missed some information whether there
is something I could test meanwhile.

I'm afraid that various higher-priority interrupts came up (new job,
UEFI security work) and I got side-tracked for a while. You must be
psychic - I just started picking things up again last weekend.

Apologies, I think I've let you down :-( .
I've made a *small* amount of progress at hacking on debconf (route
#2). But again I've had other things come up, not least another round
of Secure Boot fixes. We're not going to have changes in for
Bullseye. Sorry. :-(
--
Getting a SCSI chain working is perfectly simple if you remember that there
must be exactly three terminations: one on one end of the cable, one on the
far end, and the goat, terminated over the SCSI chain with a silver-handled
knife whilst burning *black* candles. --- Anthony DeBoer

--
http://fam-tille.de

Philip Hands

2022-01-10 19:30:02 UTC

Post by Andreas Tille
Hi Steve,
a new release cycle has started. Do you think it is possible to
implement this long wanted feature for the next release?

BTW I've got almost all of the bits in place to allow one to test this
just by pushing repos on salsa.

The only missing bit AFAIK is getting the step where tasksel gets
installed into the target system, and then run, to be able to grab the
version of tasksel to use from an alternative apt repository (which is
already being created as part of the salsa-CI pipeline I've got setup),
which I think ought to be a case of running apt update an extra time at
the right moment.

Fixing that last bit is next on my TODO list. Once done, that should
allow us to try things out rather more easily, and thus have a chance to
demonstrate that they are ready for a wider audience.

I'll follow up here once I've got all the bits in place. I also expect
to have time to work on getting Blends into d-i after that.

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

Andreas Tille

2022-01-10 19:50:01 UTC

Hi Phil,

Post by Philip Hands
Fixing that last bit is next on my TODO list. Once done, that should
allow us to try things out rather more easily, and thus have a chance to
demonstrate that they are ready for a wider audience.
I'll follow up here once I've got all the bits in place. I also expect
to have time to work on getting Blends into d-i after that.

That's really great news. Thanks a lot

Andreas.

--
http://fam-tille.de

Sunil Mohan Adapa

2022-01-10 20:10:01 UTC

Post by Andreas Tille
Hi Phil,

That's really great news. Thanks a lot

Great news indeed. I am available to help out with testing or any
further work needed. Give out a shout when changes are ready to be tested.

--
Sunil

Seth Arnold

2022-01-11 01:10:02 UTC

Post by Philip Hands
The only missing bit AFAIK is getting the step where tasksel gets
installed into the target system, and then run, to be able to grab the
version of tasksel to use from an alternative apt repository (which is
already being created as part of the salsa-CI pipeline I've got setup),

Is installing tasksel actually necessary? apt understands tasks, eg:
apt install lamp-server^

https://shantanugoel.com/2010/10/23/apt-get-caret/
https://askubuntu.com/questions/211912/

I believe this works even if tasksel isn't installed on the target system.

Thanks

Wouter Verhelst

2022-01-11 08:30:01 UTC

Post by Seth Arnold

apt install lamp-server^
https://shantanugoel.com/2010/10/23/apt-get-caret/
https://askubuntu.com/questions/211912/
I believe this works even if tasksel isn't installed on the target system.

Yes, but that doesn't give a user a friendly way to select a task.

If you know the task then yes, that's plenty, but there's more at play here.

--
***@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Steve McIntyre

2022-01-17 23:40:02 UTC

Hi Andreas!

Apologies for keeping you waiting here. For a range of reasons, I've
been struggling to find *any* time to look at this.

Much as I hate to let you down, I think the best policy now is to be
honest (with myself and you!) and say that I'm not going to find time
to do this any time soon. Sorry. :-(

I'm just orphaning some of my packages now, as I've been failing to
keep on top of those already. Other stuff has had to take priority for
too long.

I still think the best route forward is to add new functionality into
debconf and then update tasksel use that. But please don't wait on me
any more. If you can find other volunteers to pick this up, *please*
do.

--
Steve McIntyre, Cambridge, UK. ***@einval.com
Google-bait: https://www.debian.org/CD/free-linux-cd
Debian does NOT ship free CDs. Please do NOT contact the mailing
lists asking us to send them to you.

Andreas Tille

2022-01-18 06:50:02 UTC

Hi Steve,

Post by Steve McIntyre
Much as I hate to let you down, I think the best policy now is to be
honest (with myself and you!) and say that I'm not going to find time
to do this any time soon. Sorry. :-(

No need to be sorry about this. I highly evaluate all your work and use
the chance to thank you for this.

Post by Steve McIntyre
I'm just orphaning some of my packages now, as I've been failing to
keep on top of those already. Other stuff has had to take priority for
too long.

I can perfectly understand this since I'm in a similar situation that
I've done so much in the past and need to realise that I have to step
back a bit.

Post by Steve McIntyre
I still think the best route forward is to add new functionality into
debconf and then update tasksel use that. But please don't wait on me
any more. If you can find other volunteers to pick this up, *please*
do.

As far as I understood Phil's last posting he is working on an enhanced
tasksel. Hopefully those two mails (yours and Phil's) will motivate
other contributors to step in. I will not do this (see above).

Thanks again for all your work

Andreas.

--
http://fam-tille.de

Philip Hands

2022-01-18 09:00:02 UTC

Andreas Tille <***@debian.org> writes:

...

Post by Andreas Tille
As far as I understood Phil's last posting he is working on an enhanced
tasksel.

Actually, what I've been working on is infrastructure to allow others to
contribute to such an effort.

I've recently enabled a CI pipeline in the tasksel master branch, so
anyone forking that will now get the benefit of this work for free (as
long as they set the CI file to be 'debian/salsa-ci.yml').

I intend to blog about the details shortly, but a quick run down is that
this pipeline was triggered by a commit to my fork:

https://salsa.debian.org/philh/tasksel/-/pipelines/337031

which (via a multi-project pipeline) generates a mini-iso:

https://salsa.debian.org/installer-team/debian-installer/-/jobs/2364015/artifacts/file/public/gtk-mini.iso

that is configured to use an additional apt repo, which in this case
includes a version of tasksel built from the above branch:

https://salsa.debian.org/installer-team/branch2repo/-/jobs/2364013/artifacts/browse/public/pool/main/t/tasksel/

which one can then download the min-iso for testing, and/or cause to be
automatically tested with openQA, as seen here:

https://openqa.debian.net/tests/overview?groupid=13&build=-salsa-337031:philh:tasksel:salsa-CI_tasksel

where if one drills down to the logs, and search for 'salsaci', one can
see that the tasksel packages came from the extra repo:

https://openqa.debian.net/tests/37964/logfile?filename=_collect_data-debs.txt

The same is true for udebs that are included at build time, and that
would be expected to be downloaded at d-i runtime, so simply by creating
named branches with the same name across all the (u)debs that one wants
to test together you can get hold of a mini-iso that will use those
versions in preference to the released versions, without needing to know
anything about building d-i or debian CDs.

Hopefully that lowers the bar enough so that people can concentrate on
the bits they want to improve without immediately getting stuck on how
they could possibly test their efforts.

However, I've not really put much thought into what actually needs to be
changed in order to address the Blends Selection problem.

In the past when this has come up I've come up with some temporary hacks
that worked around the lack of a decent user interface, but if we want
to fix this properly then I think Steve has a point that one way to do
that is to extend debconf, and then use new features in tasksel.

I don't have anything like a design for how that should look in my head
though -- I guess interested parties should get together and come up
with a design _before_ we start trying to implement it :-)

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

Wouter Verhelst

2022-01-21 07:20:01 UTC

Post by Philip Hands
I don't have anything like a design for how that should look in my head
though -- I guess interested parties should get together and come up
with a design _before_ we start trying to implement it :-)

This sounds like you need someone with UX design experience to look at
this first, before you can actually implement things properly.

Perhaps this is something that could be posted as a "job" on the open
source design website? I've used them in the past to great effect for
the review interface of SReview, my video review system (we did a talk
about that process at FOSDEM 2019; you can see the video at
https://archive.fosdem.org/2019/schedule/event/open_source_design_in_trenches/)

You'd need someone who's willing and able to implement the required
changes to give feedback to the designer, and you'd need to commit to a
bit of time in order to do this properly (in my experience there were a
few iterations of back-and-forth improvements that did take some time to
get fleshed out), but I think the end result is worth it...

--
***@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Holger Wansing

2024-02-13 22:50:01 UTC

Hi,

I would like to push a proposal here on this longstanding topic:

By other means, my attention was drawn to the blends-tasks package.
While this package is not new, an idea came to my mind when reading the
package description:

As a possible way to solve (or work-around ?) this issue:
could we just "copy tasksel with its UI and infrastructure" into a new package
(I name it 'blends-di-tasks' here), which has all the blends listed, and add
one entry to tasksel with a name like "Debian Pure Blends" or similar?

If one then selects "Debian Pure Blends" in the good all known tasksel, the
blends-di-tasks package would be installed on /target, and later a new dialog
would appear, listing all the blends, where the user could select which one to
install.
(If the "Debian Pure Blends" entry stays unchecked, as would be the default
value, everything stays as is: the new dialog would not appear, no difference
to previous releases.)

Would that be a possible solution for all involved parties?

I know, the current (?) plan is something like an "enhanced tasksel" with some
sort of hierarchy included, but I'm not sure, if this will ever happen....

Thus, I wonder if this could be an alternative, which would be do-able?

Holger

--
Holger Wansing <***@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

Andreas Tille

2024-02-14 08:40:02 UTC

Hi Holger,
Thanks a lot for supporting this long standing topic which actually
bothers me than 20 years. But Debian is not only about technique it is
also about patience. ;-)

Post by Holger Wansing
By other means, my attention was drawn to the blends-tasks package.
While this package is not new, an idea came to my mind when reading the
could we just "copy tasksel with its UI and infrastructure" into a new package
(I name it 'blends-di-tasks' here), which has all the blends listed, and add
one entry to tasksel with a name like "Debian Pure Blends" or similar?
If one then selects "Debian Pure Blends" in the good all known tasksel, the
blends-di-tasks package would be installed on /target, and later a new dialog
would appear, listing all the blends, where the user could select which one to
install.
(If the "Debian Pure Blends" entry stays unchecked, as would be the default
value, everything stays as is: the new dialog would not appear, no difference
to previous releases.)
Would that be a possible solution for all involved parties?

I consider this an acceptable work-around and it would be definitely a
great enhancement over having nothing.

Post by Holger Wansing
I know, the current (?) plan is something like an "enhanced tasksel" with some
sort of hierarchy included, but I'm not sure, if this will ever happen....

I think tasksel deserves a new design, but well if we do not have
someone who might tackle this task we need to go with the means we have.

Post by Holger Wansing
Thus, I wonder if this could be an alternative, which would be do-able?

Thanks a lot for this inspiring idea.

Kind regards
Andreas.

--
http://fam-tille.de

Cyril Brulebois

2024-05-09 21:20:01 UTC

Hallo Holger,

Post by Holger Wansing
could we just "copy tasksel with its UI and infrastructure" into a
new package (I name it 'blends-di-tasks' here), which has all the
blends listed, and add one entry to tasksel with a name like "Debian
Pure Blends" or similar?
If one then selects "Debian Pure Blends" in the good all known
tasksel, the blends-di-tasks package would be installed on /target,
and later a new dialog would appear, listing all the blends, where
the user could select which one to install. (If the "Debian Pure
Blends" entry stays unchecked, as would be the default value,
everything stays as is: the new dialog would not appear, no
difference to previous releases.)
Would that be a possible solution for all involved parties?

That approach looks very fine to me, thanks.

So, how to proceed now?
To make progress, the new blendsel needs to get into the archive I guess,
otherwise testing and providing test images will not work IMO.
Would the installer-team be ok with taking blendsel under its umbrella,
as tasksel is, to get it uploaded?

Looks good to me.

I totally understand how testing can be difficult until packages reach
the archive, feel free to âupload early, upload oftenâ.

It looks like the 64-bit time_t transition is getting better (at least
from afar) but I don't have any immediate plans for a release at the
moment, so it's perfectly fine to have glitches/temporary regressions
following the introduction of this feature/new packages along the way.

Cheers,

--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Holger Wansing

2024-05-10 06:50:01 UTC

Hi,

Would the installer-team be ok with taking blendsel under its umbrella,
as tasksel is, to get it uploaded?

Looks good to me.

Now blendsel being moved to installer-team, would you mind giving me dm
permissions, so I can upload? Thanks

Holger

--
Holger Wansing <***@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

Cyril Brulebois

2024-05-10 07:10:02 UTC

Post by Holger Wansing
Now blendsel being moved to installer-team, would you mind giving me
dm permissions, so I can upload? Thanks

I seem to recall that only works for existing packages?

May I suggest to think about turning your DD account into a
non-non-uploading one? :)

Cheers,

--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Holger Wansing

2024-05-10 07:40:02 UTC

Hi,

Post by Holger Wansing
Now blendsel being moved to installer-team, would you mind giving me
dm permissions, so I can upload? Thanks

I seem to recall that only works for existing packages?

Ah ok, yes that makes sense.
Then anyone else will have to do the upload :-(

Post by Cyril Brulebois
May I suggest to think about turning your DD account into a
non-non-uploading one? :)

I know you repeatedly suggested this.
Especially every time I ask for more packages to get dm permissions for :-))

My problem with this:
am I really capable of being a DD? You might remember that I am not a
programmer, I have no real skills in this direction.
I can do some scripting, gained by self-learning, but that does not make
a programmer of me IMO ;-)
So I am unsure if I can successfully go the apply-for-DD path...
I fear I lack some basic knowledge for this.
Don't want to waste my and the application manager's time and effort for
something, that does not lead to anything at the end.

Holger

--
Holger Wansing <***@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

John Paul Adrian Glaubitz

2024-05-10 07:40:02 UTC

Post by Holger Wansing
am I really capable of being a DD? You might remember that I am not a
programmer, I have no real skills in this direction.
I can do some scripting, gained by self-learning, but that does not make
a programmer of me IMO ;-)
So I am unsure if I can successfully go the apply-for-DD path...
I fear I lack some basic knowledge for this.
Don't want to waste my and the application manager's time and effort for
something, that does not lead to anything at the end.

You don't need to be a professional programmer to become a DD. It's more
important to be passionate about Debian and free software and a dedicated
contributor to both. Also, being a good community member is essential.

And that all definitely applies to you. I would support your DD application!

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Cyril Brulebois

2024-05-11 20:10:01 UTC

Hi,

I know you repeatedly suggested this. Especially every time I ask for
more packages to get dm permissions for :-))

Just in case that's not clear: I'm not trying to get rid of you as if
you were a burden (which you're clearly not), I'm suggesting you get
recognized as an uploading DD (which you certainly qualify for
already!).

My problem with this: am I really capable of being a DD? You might
remember that I am not a programmer, I have no real skills in this
direction. I can do some scripting, gained by self-learning, but that
does not make a programmer of me IMO ;-)

You certainly don't need to be any kind of programmer (professional or
self-taught) to be a DD.

Given a package that you'd like to upload, are you able to look around
in its source code, spot issues or things you want to improve, to come
up with a patch that you'd be confident to upload? That's what matters.
That's already happening for the packages you're DM-allowed to upload.

When facing an issue or question, do you pick a random solution, hope
for the best, upload, and watch the fireworks? Or do you ask others,
gather feedback, and come up with a solution that has high chances to
work? Definitely the latter, and that's what matters.

Being knowledgeable about packages you're uploading (be it via a
sponsor, a DM approval for this package or because you're a DD) is
important. But that doesn't mean you need to understand and know its
codebase by heart. Being reasonably sure that the changes to be uploaded
are improving the situation as a whole, minimizing risks on the rest of
the ecosystem (other packages in general, not breaking the installer in
this specific case) is really what seems to be most important to me.

You're definitely acquainted with the a bunch of things in the installer
ecosystem, you're also knowledgeable about l10n topics, and you're
definitely an excellent team player.

As far as I'm concerned, the only bug is that your key is not in the
right keyring! :)

So I am unsure if I can successfully go the apply-for-DD path...
I fear I lack some basic knowledge for this.
Don't want to waste my and the application manager's time and effort
for something, that does not lead to anything at the end.

I suppose you already went through questions/checks around the Social
Contract, Debian Free Software Guidelines, Debian Machine Usage
Policies, etc. during the non-uploading DD application, so I'm not
putting any focus on those (important nonetheless!) topics.

I'd imagine the main difference between both types of application to be
aroundâŠ package manangement/uploads. And you definitely know how to
upload packages already, as evidenced by:
https://qa.debian.org/developer.php?login=Wansing

Please let me know if I can do anything to help you get set up as a DD.

Cheers,

--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Steve McIntyre

2024-05-11 21:10:01 UTC

Post by Cyril Brulebois
Hi,

I know you repeatedly suggested this. Especially every time I ask for
more packages to get dm permissions for :-))

+1000

Holger, you're great. Stop arguing :-)

--
Steve McIntyre, Cambridge, UK. ***@einval.com
“Changing random stuff until your program works is bad coding
practice, but if you do it fast enough it’s Machine Learning.”
-- https://twitter.com/manisha72617183

Holger Wansing

2024-05-13 16:30:01 UTC

Hi,

Post by Cyril Brulebois
You're definitely acquainted with the a bunch of things in the installer
ecosystem, you're also knowledgeable about l10n topics, and you're
definitely an excellent team player.
As far as I'm concerned, the only bug is that your key is not in the
right keyring! :)

So, let's see if I can fix this bug:
https://nm.debian.org/process/1292/

--
Holger Wansing <***@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

Holger Wansing

2024-12-11 22:30:02 UTC

Hi kibi,

blendsel is now ready to be integrated into d-i, pkgsel and tasksel need an
upload to make this happen.

What are your thoughts for this?
Do you want to make a first alpha/beta d-i release, as a "clean basis" without
this Blend integration approach?

Or am I allowed to upload now and we get a the blendsel solution in the first
alpha/beta for Trixie?

If someone wants to give it a try, to see how it looks like:
I have a branch
https://salsa.debian.org/holgerw/pkgsel-install-blendsel-unconditionally
where blendsel is installed automatically together with tasksel, and
blendsel's dialog appears automatically after the tasksel run has finished.

To test this branch, you can download a mini.iso built on this branch from
https://salsa.debian.org/holgerw/pkgsel-install-blendsel-unconditionally/-/jobs/6707524/artifacts/download

Cheers
Holger

--
Holger Wansing <***@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

Cyril Brulebois

2024-12-12 06:30:01 UTC

Hi,

Post by Holger Wansing
blendsel is now ready to be integrated into d-i, pkgsel and tasksel need an
upload to make this happen.
What are your thoughts for this?
Do you want to make a first alpha/beta d-i release, as a "clean basis" without
this Blend integration approach?
Or am I allowed to upload now and we get a the blendsel solution in the first
alpha/beta for Trixie?

Feel free to go ahead and deal with the missing bits, we have other
things that aren't ready anyway.

Cheers,

--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Philip Hands

2024-12-12 08:50:01 UTC

Hi Holger,

Thanks for working on this, it's been left undone for way too long
(which makes me feel guilty, as I really ought to have managed to do
more to make it happen, so I really appreciate that you're working on
it).

Post by Holger Wansing
I have a branch
https://salsa.debian.org/holgerw/pkgsel-install-blendsel-unconditionally
where blendsel is installed automatically together with tasksel, and
blendsel's dialog appears automatically after the tasksel run has finished.

I can see why you opted to put blendsel there from the point of view of
it being minimally invasive, but I think that after tasksel is too late
for blend selection.

Some blends may want to do things like preseed the desktop, or change
preferences for disk partitioning, or do other more radical things to
the way D-I works.

Debian-Edu's installer looks quite different at the tasksel stage for
instance:

https://openqa.debian.net/tests/320732#step/edu_profile/1

and the only thing before that in the Debian-Edu installer is locale
selection, so if we wanted to be able to offer Debian-Edu as a blend
we'd need to be asking about blends very early on, presumably
immediately after locale selection.

I would hope to have time to contribute some effort to helping make this
happen in the near future, and am much more likely to get round to it if
prodded, so please ask if there's anything I can help with.

In particular, I'll be happy to set up openqa tests for attempts to get
things working, and modify the existing tests so we can show that D-I
still works with this in place. I can also help you with getting
openqa-link setup, so that you can launch your own tests from salsa's CI.

Cheers, Phil.

--
Philip Hands -- https://hands.com/~phil

Andreas Tille

2024-12-12 10:30:01 UTC

Hi Phil,

Prodding! ;-P

Thank you Phil and for sure lots of thanks to Holger
Andreas.

--
https://fam-tille.de

Holger Wansing

2024-12-12 15:50:01 UTC

Hi Phil,

Post by Philip Hands
I can see why you opted to put blendsel there from the point of view of
it being minimally invasive, but I think that after tasksel is too late
for blend selection.
Some blends may want to do things like preseed the desktop, or change
preferences for disk partitioning, or do other more radical things to
the way D-I works.
Debian-Edu's installer looks quite different at the tasksel stage for
https://openqa.debian.net/tests/320732#step/edu_profile/1
and the only thing before that in the Debian-Edu installer is locale
selection, so if we wanted to be able to offer Debian-Edu as a blend
we'd need to be asking about blends very early on, presumably
immediately after locale selection.

I fear, what you describe here is not what was my goal, when I
started to work on this.
I acted on the approach, to modify tasksel so it can have a
hierachical structure for blends installation.

So, my path was to create a possibility, to install packages for
blends by selection. Not more.

What you describe above is a much more invasive approach, that
has effects in much more aspects of the installer.

I see two issues with this approach (at this time):

1.
I doubt I personally can perform such wide set of changings/functionality

2.
I'm unsure if it's the right time for such comprehensive changings
in this time of the Trixie development cycle.
That smells like more time needed for development and testing
to me?

Regards
Holger

Post by Philip Hands
I would hope to have time to contribute some effort to helping make this
happen in the near future, and am much more likely to get round to it if
prodded, so please ask if there's anything I can help with.
In particular, I'll be happy to set up openqa tests for attempts to get
things working, and modify the existing tests so we can show that D-I
still works with this in place. I can also help you with getting
openqa-link setup, so that you can launch your own tests from salsa's CI.

--
Sent from /e/ OS on Fairphone3

Philip Hands

2024-12-12 19:10:01 UTC

Post by Andreas Tille
Hi Phil,

I fear, what you describe here is not what was my goal, when I
started to work on this.
I acted on the approach, to modify tasksel so it can have a
hierachical structure for blends installation.
So, my path was to create a possibility, to install packages for
blends by selection. Not more.
What you describe above is a much more invasive approach, that
has effects in much more aspects of the installer.
1.
I doubt I personally can perform such wide set of changings/functionality
2.
I'm unsure if it's the right time for such comprehensive changings
in this time of the Trixie development cycle.
That smells like more time needed for development and testing
to me?

I think I was perhaps forgetting that tasksel (and so blendsel) rely on
the installed system to do what they do, so one cannot push them earlier
in the order without more effort than I had in mind.

I still think it might be worth having an early question where it might
be possible to add more complexity later, just to provide a hook where
people like Debian-Edu could start developing things.

On the other hand, having a "Do you want to install a Blend?" question
immediately after the locale selection seems a bit weird, and would be
rather annoying if answering it wrong would lead to blendsel not
appearing after tasksel, when one had hoped it would.

I guess some feedback from blends folk about what they're hoping for
would help at this point. Perhaps blendsel is just what most people had
in mind, in which case the likes of Debian-Edu just need to continue
with their custom D-I.

Cheers, Phil.

--
Philip Hands -- https://hands.com/~phil

Cyril Brulebois

2024-12-13 01:20:01 UTC

Post by Philip Hands
I think I was perhaps forgetting that tasksel (and so blendsel) rely on
the installed system to do what they do, so one cannot push them earlier
in the order without more effort than I had in mind.
I still think it might be worth having an early question where it might
be possible to add more complexity later, just to provide a hook where
people like Debian-Edu could start developing things.
On the other hand, having a "Do you want to install a Blend?" question
immediately after the locale selection seems a bit weird, and would be
rather annoying if answering it wrong would lead to blendsel not
appearing after tasksel, when one had hoped it would.
I guess some feedback from blends folk about what they're hoping for
would help at this point. Perhaps blendsel is just what most people had
in mind, in which case the likes of Debian-Edu just need to continue
with their custom D-I.

As far as I can remember, at least Andreas was fine/happy with the idea
proposed by Holger (which also matched what I had in mind to make some
progress there), so I don't see why we should disrupt the install flow
with an early question for very specific usecasesâŠ

Cheers,

--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Andreas Tille

2024-12-13 07:30:01 UTC

Hi,

I know Debian Edu members are reading the debian-blends list but to
be very sure I put their list in CC.

I confirm I was very happy about Holger's proposal and it might make
sense to keep things as simple as possible for the moment. My gut
feeling is that Debian Edu people consider their pre-seeding as a solved
problem. Since the request to offer some Blends selection inside the
installer did not came from Debian Edu its fine for them to stick to the
original proposal doing the Blends selection after tasksel. I could
imagine since the pre-seeding is done earlier its clear the user wants
Debian Edu (and no other Blend) so the Blends selection in this case
might be redundant and some option should be provided to skip blendsel.

Kind regards
Andreas.

--
https://fam-tille.de

Holger Wansing

2024-12-13 14:30:01 UTC

Hi all,

Post by Andreas Tille
I confirm I was very happy about Holger's proposal and it might make
sense to keep things as simple as possible for the moment. My gut
feeling is that Debian Edu people consider their pre-seeding as a solved
problem. Since the request to offer some Blends selection inside the
installer did not came from Debian Edu its fine for them to stick to the
original proposal doing the Blends selection after tasksel. I could
imagine since the pre-seeding is done earlier its clear the user wants
Debian Edu (and no other Blend) so the Blends selection in this case
might be redundant and some option should be provided to skip blendsel.

The idea is, that we add an entry to tasksel, which makes blendsel to
appear, if chosen.

So, if the Edu preseed file does not set this option, blendsel will not be shown.
All good.

Holger

--
Sent from /e/ OS on Fairphone3

Mike Gabriel

2024-12-16 12:40:01 UTC

Hi Holger,

Post by Holger Wansing
Hi all,

The idea is, that we add an entry to tasksel, which makes blendsel to
appear, if chosen.
So, if the Edu preseed file does not set this option, blendsel will not be shown.
All good.

Sounds good to me (with Debian Edu dev hat on). Thanks for the initiative!

Mike

--
DAS-NETZWERKTEAM
c\o Technik- und Ãkologiezentrum EckernfÃ¶rde
Mike Gabriel, Marienthaler Str. 17, 24340 EckernfÃ¶rde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: ***@das-netzwerkteam.de, http://das-netzwerkteam.de

Philip Hands

2024-12-14 22:30:01 UTC

Post by Andreas Tille
Hi,
I know Debian Edu members are reading the debian-blends list but to
be very sure I put their list in CC.

That's good to know -- In that case it sounds like this is going to deal
with many/most blends' needs while only needing minimal changes to D-I,
which is great. :-)

Cheers, Phil.

--
Philip Hands -- https://hands.com/~phil

Andreas Tille

2024-05-10 09:40:01 UTC

Hi Holger,

thanks a lot for your effort. Its really appreciated and very valuable
for the Blends effort.

Post by Holger Wansing
could we just "copy tasksel with its UI and infrastructure" into a new package
(I name it 'blends-di-tasks' here), which has all the blends listed, and add
one entry to tasksel with a name like "Debian Pure Blends" or similar?
If one then selects "Debian Pure Blends" in the good all known tasksel, the
blends-di-tasks package would be installed on /target, and later a new dialog
would appear, listing all the blends, where the user could select which one to
install.
(If the "Debian Pure Blends" entry stays unchecked, as would be the default
value, everything stays as is: the new dialog would not appear, no difference
to previous releases.)
Would that be a possible solution for all involved parties?

I worked on this in the meantime, and would like to propose my current

While I guess the natural place for your packages is installer-team I've
just added you to the team in case you want to maintain some
(additional?) packages there.

- I adapted tasksel, to become an installer for Debian pure blends. The
new package is blendsel, see https://salsa.debian.org/holgerw/blendsel/

I've build this package and besides a nitpicking comment thet you should
probably fix your ID in Uploaders field.

- I prepared a change in pkgsel, to call blendsel depending on the
descision, if Debian pure blends are wanted or not.
See https://salsa.debian.org/holgerw/pkgsel/
testing is problematic as long as the new blendsel package is not in the
archive, and the same with the changed pkgsel.
So I had to "live-patch" the d-i for testing of blendsel, and therefore
I cannot provide a working test image or the like (or I don't know how).

I admit I have no idea how to test in d-i but Cyril has given some
answers according to this.

Anyway, I think I have it running so far, the blendsel dialog appears
and shows the items to select; I'm attaching a screenshot showing the
current state (please note, that the dialog shows three desktop environments
as placeholder for now; the tasksel - and therefore blendsel as well -
logic does not allow to have packages|tasks|blends listed that don't
have the corresponding task-* packages in the archive).

I've build the package locally and confirm it works as described.

However, there will most likely be some glitches and edges to fix in
blendsel, a review would be more than welcome...
The template should be rephrased, I would ask for review on debian-l10n-english
when the time comes, but I guess there is still time for that...

ACK.

Just let me know if you need any support besides questions that can only
be answered by installer team.

Thanks again for your work
Andreas.

--
https://fam-tille.de

Holger Wansing

2025-01-05 18:50:01 UTC

Hi blends people,

Post by Andreas Tille
thanks a lot for your effort. Its really appreciated and very valuable
for the Blends effort.

We now reached the point, where all this can be seen/tested in the wild aka
via daily built images.
Please note, that the last relevant change did not reach testing yet, so you
will have to install sid from a trixie daily build image, to test this.

The usual, good old tasksel dialog now has an additional entry at the bottom
"Choose a Debian blend for installation" (this is not chosen by default)
[blendsel_1.png].

If you choose this [blendsel_2.png], the blendsel dialog will appear after
tasksel has done its work [blendsel_3.png].

So, the infrastructure is ready now, and I want to ask blend people for a
list of blends, that you want to be included in this mechanism.
I already came across the list in
<https://salsa.debian.org/blends-team/blends/-/blob/master/doc/en/04_existing_blends.xml?ref_type=heads>

Maybe that list could serve as template?
Please provide a list at your choice.

Also, if you would like to adapt the wording of the dialog, feel free to
tell me.

so long
Holger

--
Holger Wansing <***@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

Andreas Tille

2025-01-05 21:30:01 UTC

Hi Holger,

Post by Holger Wansing
We now reached the point, where all this can be seen/tested in the wild aka
via daily built images.
Please note, that the last relevant change did not reach testing yet, so you
will have to install sid from a trixie daily build image, to test this.

Sounds really good

Post by Holger Wansing
The usual, good old tasksel dialog now has an additional entry at the bottom
"Choose a Debian blend for installation" (this is not chosen by default)
[blendsel_1.png].
If you choose this [blendsel_2.png], the blendsel dialog will appear after
tasksel has done its work [blendsel_3.png].
So, the infrastructure is ready now, and I want to ask blend people for a
list of blends, that you want to be included in this mechanism.
I already came across the list in
<https://salsa.debian.org/blends-team/blends/-/blob/master/doc/en/04_existing_blends.xml?ref_type=heads>
Maybe that list could serve as template?
Please provide a list at your choice.

Since not everybody is reading the Blends list I've added the relevant
mailing lists in CC. I personally confirm for

Debian Med and
Debian Science

Post by Holger Wansing
Also, if you would like to adapt the wording of the dialog, feel free to
tell me.

Please spell Blend in
"Choose a Debian _b_lend for installation
with upper case _B_ (its a noun).

In the Blends selection I would start the actual selection (third image) with the
real Blend name like (and alphabetic ordering) and the "official" short description
(which each Blend in CC should answer)

Debian Astro
Debian Med (life sciences and medicine)
Debian Junior

Debian Science (various sciences)

Thanks again for working on this
Andreas.

--
https://fam-tille.de

Holger Wansing

2025-01-08 07:50:01 UTC

Hi all,

Post by Andreas Tille
Hi Holger,

Sounds really good

Since not everybody is reading the Blends list I've added the relevant
mailing lists in CC. I personally confirm for
Debian Med and
Debian Science

Post by Holger Wansing
Also, if you would like to adapt the wording of the dialog, feel free to
tell me.

Please spell Blend in
"Choose a Debian _b_lend for installation
with upper case _B_ (its a noun).
In the Blends selection I would start the actual selection (third image) with the
real Blend name like (and alphabetic ordering) and the "official" short description
(which each Blend in CC should answer)
Debian Astro
Debian Med (life sciences and medicine)
Debian Junior
Debian Science (various sciences)

I just noticed some mails on debian-blends, which I missed until now.
Please always keep debian-boot in the loop for the installer-team!
I'm not subscribed to all these lists!

--------

Post by Andreas Tille
It'd be worth checking in with others listed on [1] that have missed the
discussion so far, and also pruning the list! I note Debian multimedia is
dropped from [2] in the past but still on the website.
I'm slowly working on Debian Hamradio having picked up it from irl and would
be interested in being on the list (and in the existing blends doc) too!
I don't know if Debian Design and DebianParl are active.
[1] https://www.debian.org/blends/
[2] https://salsa.debian.org/blends-team/blends/-/blob/master/doc/en/
04_existing_blends.xml?ref_type=heads

Maybe it would be good, to have https://www.debian.org/blends/ in sync
with what we have in the installer, when Trixie is released?

--------

Post by Andreas Tille
We should add also the Debian-pan blends.
It is activelay maintain by myself and the french synchrotron SOLEIL.

That's on the blends people's decision.

--------

Post by Andreas Tille
* Debian Junior (children and their guides)
* Debian Junior (Debian for children and their guides)
For Debian Junior it would be nice to install the package
junior-desktop when the user selects "Debian Junior".
https://packages.debian.org/trixie/junior-desktop

Ok.

Regards
Holger

--
Holger Wansing <***@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

Holger Wansing

2025-01-14 21:30:01 UTC

Hi,

Post by Holger Wansing
Also, if you would like to adapt the wording of the dialog, feel free to
tell me.

Please spell Blend in
"Choose a Debian _b_lend for installation
with upper case _B_ (its a noun).
In the Blends selection I would start the actual selection (third image) with the
real Blend name like (and alphabetic ordering) and the "official" short description
(which each Blend in CC should answer)
Debian Astro
Debian Med (life sciences and medicine)
Debian Junior
Debian Science (various sciences)

The above has been applied, and also for Astro:
Debian Astro (professional and hobby astronomers)

and Junior:
Debian Junior (children and their guides)

Holger

--
Holger Wansing <***@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

Philip Hands

2024-05-11 18:30:01 UTC

Hi Holger,

Well done for deciding to put your shoulder to this old rock, I think we've
got a pretty good chance of getting to the top of the mountain this time :-)

testing is problematic as long as the new blendsel package is not in the
archive, and the same with the changed pkgsel.
So I had to "live-patch" the d-i for testing of blendsel, and therefore
I cannot provide a working test image or the like (or I don't know how).

It is possible to persuade salsa-CI to do this.

In order to do that, I've cloned your blendsel & pkgsel repos, and
tweaked them slightly:

https://salsa.debian.org/philh/pkgsel/-/tree/blendsel?ref_type=heads
https://salsa.debian.org/philh/blendsel/-/tree/blendsel?ref_type=heads

The main trick is to set BRANCH2REPO_EXTRA_PROJECTS so that the other
package gets included in the aptly repo in the pipeline, so that the
resulting mini-ISO gets to show off all the changes in both packages.

BTW I also had to tweak pkgsel's postinst to ensure that blendsel gets
installed (this is mostly required because an `apt update` is required
to make the salsa aptly repo visible in the target, so should not end up
in a release).

Having done that, one gets a mini-ISO, such as this:

https://salsa.debian.org/philh/pkgsel/-/jobs/5713711/artifacts/file/debian/output/debian-202306XX+salsaci+20240511+6-amd64-gtkmini.iso

which when tested on openQA looks like this:

https://openqa.debian.net/tests/260723

So I guess I'll need to write a new test to match that next :-)

BTW there's nothing to stop one creating new task packages, and adding
them to BRANCH2REPO_EXTRA_PROJECTS, so you don't need to wait for them
to be released to test them.

I think that should work for your user on salsa too, if you pull those
changes into your repos, and set the CI config to `debian/salsa-ci.yml`
in both repos. If not, just say and we can work out what's missing.

HTH

Cheers, Phil.

P.S. Please don't stress about whether you qualify as a DD. Imposter
Syndrome is a healthy sign of humility IMO. I'd hope that most of us
feel like imposters at least some of the time, because the alternative
is not godlike competence but rather the DunningâKruger effect.

--
Philip Hands -- https://hands.com/~phil

Philip Hands

2024-05-11 23:20:01 UTC

Post by Philip Hands
https://openqa.debian.net/tests/260723

I got bored waiting for the timeout, so sent that mail before the job
had ended. The bit you want to see is:

https://openqa.debian.net/tests/260723#step/grub/3

Cheers, Phil.

--
Philip Hands -- https://hands.com/~phil

Cyril Brulebois

2024-05-12 07:00:01 UTC

Hallo wieder,

TL;DR = blendsel looks uploadable, even if that mail looks long and full
of nitpicks, that's all they are: minor things. A bunch of them being in
passing comments about tasksel itself. ;)

- I adapted tasksel, to become an installer for Debian pure blends. The
new package is blendsel, see https://salsa.debian.org/holgerw/blendsel/

Now moved under installer-team's namespace.

Keeping the whole git history of tasksel without its tag is probably
fine, in case anyone needs to dig up why this thing is done that way,
but I'm not sure we should keep tasksel entries in debian/changelog; I
would probably only keep the blendsel entry, adding a reference to the
version of tasksel it was forked off from. Unless some others feel
strongly we should keep the whole tasksel history in debian/changelog?

I've fixed a few minor things for the rename. It looks to me the README
could probably be stripped down to mention blendsel's being a fork of
tasksel, and pointing at tasksel's README for more information. Less
duplication would be best (and I'm not sure how current the contents are
anyway). Ditto for tasks/README.

I think you know best how to adjust README.translators :)

I'm happy to upload it as-is (modulo debian/changelog), but I suspect
it'd make sense to adjust tasks/ before doing so? Happy either way.

- I prepared a change in pkgsel, to call blendsel depending on the
descision, if Debian pure blends are wanted or not.
See https://salsa.debian.org/holgerw/pkgsel/

That I didn't check yet, my focus is on the current blocker (as far as
the DM vs. DD limitation is concerned).

Understood, but please let me know if it makes sense to have them in the
0.1 upload, or if you'd like to introduce them in 0.2 once 0.1 has been
accepted.

The template should be rephrased, I would ask for review on
debian-l10n-english when the time comes, but I guess there is still
time for that...

You should talk to our beloved l10n coordinator!

And yeah, lintian/bookworm reports some things we don't normally do:

W: blendsel: using-first-person-in-templates blendsel/tasks [templates:16]

Seriously though, I'm not familiar with the semantics behind /first vs.
/tasks in tasksel. Do we want/need the same semantics in blendsel?

I think we should have lintian-overrides for the main package, just like
tasksel, at least for those (again, only running lintian/bookworm):

E: blendsel: no-debconf-config
W: blendsel: debconf-is-not-a-registry [usr/lib/blendsel/blendsel-debconf:3]

Finally, this should probably go away from both packages, I don't even
remember having managed that package:

Conflicts: base-config (<< 2.32)

(And indeed, that was 20 years ago.)

Bonus points: maybe clean up tasksel's debian/source/lintian-overrides?

Cheers,

--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Holger Wansing

2024-05-12 10:00:02 UTC

Hi,

Post by Cyril Brulebois
Keeping the whole git history of tasksel without its tag is probably
fine, in case anyone needs to dig up why this thing is done that way,
but I'm not sure we should keep tasksel entries in debian/changelog; I
would probably only keep the blendsel entry, adding a reference to the
version of tasksel it was forked off from. Unless some others feel
strongly we should keep the whole tasksel history in debian/changelog?

I only kept that for completeness; didn't intended to keep it on the long
run. Now cleaned up.

Post by Cyril Brulebois
I've fixed a few minor things for the rename. It looks to me the README
could probably be stripped down to mention blendsel's being a fork of
tasksel, and pointing at tasksel's README for more information. Less
duplication would be best (and I'm not sure how current the contents are
anyway). Ditto for tasks/README.

Adapting READMEs is my todo list.

Post by Cyril Brulebois
I think you know best how to adjust README.translators :)
I'm happy to upload it as-is (modulo debian/changelog), but I suspect
it'd make sense to adjust tasks/ before doing so? Happy either way.

I would like to leave it as is for now.
Thank you very much for taking care of this thingy!

- I prepared a change in pkgsel, to call blendsel depending on the
descision, if Debian pure blends are wanted or not.
See https://salsa.debian.org/holgerw/pkgsel/

That I didn't check yet, my focus is on the current blocker (as far as
the DM vs. DD limitation is concerned).

Ok, fine with me.
Just wanted to illustrate to whole idea behind this approach.

Understood, but please let me know if it makes sense to have them in the
0.1 upload, or if you'd like to introduce them in 0.2 once 0.1 has been
accepted.

I would like to keep that for future releases, even if I already went one step
further: thanks to Phil's Salsa CI black-magic tests it's proven that basically
it works in the wild as expected. Thanks Phil!

The template should be rephrased, I would ask for review on
debian-l10n-english when the time comes, but I guess there is still
time for that...

You should talk to our beloved l10n coordinator!

Need to find some time when being along at home, to prevent my wife from
pondering "Hmm, Holger is getting bewildered, he's having a discussion with
himself!" :-)))

Post by Cyril Brulebois
W: blendsel: using-first-person-in-templates blendsel/tasks [templates:16]
Seriously though, I'm not familiar with the semantics behind /first vs.
/tasks in tasksel. Do we want/need the same semantics in blendsel?

I already realized, that blendsel/first is not used at all, so that can go away
I think.

Post by Cyril Brulebois
I think we should have lintian-overrides for the main package, just like
E: blendsel: no-debconf-config
W: blendsel: debconf-is-not-a-registry [usr/lib/blendsel/blendsel-debconf:3]

Done.

Post by Cyril Brulebois
Finally, this should probably go away from both packages, I don't even
Conflicts: base-config (<< 2.32)
(And indeed, that was 20 years ago.)

Done.
So ready for first upload! Get the ball rolling :-)

Post by Cyril Brulebois
Bonus points: maybe clean up tasksel's debian/source/lintian-overrides?

On the todo list now.

Holger

--
Holger Wansing <***@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

ishikawa

2017-03-31 07:20:01 UTC

Hi,

Recently I have hit into the issue of automatic partition done during the
installation of Debian jessie
creating too small root (/) partition, and tried to find out where to report
this and found the following post which is quoted below.

Sorry I am not sure how to quote a post to debian-boot mail archive, which I
found at
https://lists.debian.org/debian-boot/2014/10/msg00115.html.
The subject was "root-fs too small [was: Re: Debian Installer Jessie Beta 2
release]".
So I simply copy and paste the web page below.

* /Subject/: root-fs too small [was: Re: Debian Installer Jessie Beta 2
release]
* /Date/: Mon, 06 Oct 2014 10:53:30 +0200
<https://lists.debian.org/debian-boot/2014/10/msg00115.html>>
<https://lists.debian.org/debian-boot/2014/10/msg00095.html>>
<https://lists.debian.org/debian-boot/2014/10/msg00095.html>>
----------------------------------------------------------------------------
Hello,

I still can confirm #740330 "root-fs should be larger". You will only
run into this problem when you autopartition and later you get a kernel
update (e.g. 3.16-1 > 3.16-2 or coming kernel security updates).
If / is too small a jessie+1 will run into this problem, too.
Please raise the size. Thank you.:)
--
Noël Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org
*Attachment: signature.asc
<https://lists.debian.org/debian-boot/2014/10/pgpLDkSppej9z.pgp>*
/Description:/ This is a digitally signed message part
----------------------------------------------------------------------------

Does the recent netinstaller for jessie I downloaded last weekend contain
the fix for above?
I doubt it because I just hit the too small root partition issue
after I was upgrading and doing some installation stuff on a new installation.

I think in today's bloated kernel (and other related stuff) world, we should
set aside 20G for root (/)
[maybe much more. I found the suggestion for 32GB which may be a tad too
large, but...] at the minimum during automatic partition.
We probably should warn the user if the installer finds the root partition
too small.

I would rather live with smaller /home partition and larger /root partition.
There was enough space in /home to make /root bigger in my case.

I got bitten with this issue three times on different machines in the past
three years and so decided to the manual partition for a fresh install based
on my experience, but I was in a hurry this time
and tried netinstall with automatic partition and hit into this problem again.
The machine is in limbo because I cannot even remove packages. (I tried
setting TMP, TMPDIR, etc. to point to a non-root partition, but to no avail.)
I will try re-installing this weekend, but I wanted to report the issue to
debian bug system.

Where should I report this? Since the installation of Debian GNU/Linux
system is NOT in usable state [the partition filled up and many commands
refused to run.],
I cannot send the bug report from THAT machine.

Thank you in advance for your attention.

Chiaki Ishikawa

Ben Hutchings

2017-03-31 13:50:01 UTC