I'd be really happy if you would find some time to answer my questions
at the end of this mail (preferably in public on the list but private
answers are fine as well.
I'd like to officially contact all our teams to learn about potential
issues that might affect your work. I would love to learn how you
organise / share your workload. If you do some regular meetings - be it
on IRC, video conference or whatever I'm interested in joining one of
your next meetings.
Like previous DPLs, I'm open to any inquiries or requests for
assistance. I personally prefer public discussion whenever possible,
as they can benefit a wider audience. You can find a list of contact
options at the bottom of my page on people.d.o[1].
I prefer being offline when I'm away from my keyboard, so I don't
carry a phone. In urgent situations, I can provide the number of my
dumb phone, though it may not always be within reach. Feel free to
ping me via email if I don't respond promptly to ensure I address your concerns.
Please let me know whether I can do something for you. I'm fine
joining your IRC channel if needed but please invite me in case I
should be informed about some urgent discussion there since I normally
do not lurk on this channel.
I'd also like to inform you that I've registered a BoF for DebConf24
in Busan with the following description:
I'm sure not everybody will be able to travel this distance but it
would be great if you would at least consider joining that BoF
remotely. I'll care for a somehow TimeZone aware scheduling - if
needed we'll organise two BoFs to match all time zones. I'm also
aware that we have pretty different teams and it might make sense to
do some infrastructure related BoF with your team and other teams that
are caring for Debian infrastructure.
I have some specific questions to the Debian Boot team.
- Do you feel good when doing your work in Debian Boot team?
- Do you consider the workload of your team equally shared amongst its
members and who actually is considered a team member? (I added some
persons in CC who have recently answered to questions on the mailing
list.)
- Do you have some strategy to gather new contributors for your team?
- Can you give some individual estimation how many hours per week you
are working on your tasks in youre team? Does this fit the amount of
time you can really afford for this task?
- I recently had some discussion on Chemnitzer Linuxtage what might
be the reason for derivatives to write their own installers. While
I'm personally perfectly happy with the way I can install Debian I'm
somehow wondering why others are spending time into a problem we
are considering "solved" and whether we can learn something from this,
- I once had a amr64 based laptop (Pinebook) and had to learn that I
can't use the Debian installer which was frustrating. I was told
that this is the case for hardware that is not featuring some BIOS-like
boot system.
Do you see any chance to let the installer work for
non-Intel architectures (or should I rather ask this question on
Debian CD (sorry for my ignorance if I miss responsibility here.)
- Can I do anything for you?
I have some specific questions to the Debian Boot team.
- Do you feel good when doing your work in Debian Boot team?
- Do you consider the workload of your team equally shared amongst its
members and who actually is considered a team member? (I added some
persons in CC who have recently answered to questions on the mailing
list.)
- Do you have some strategy to gather new contributors for your team?
- Can you give some individual estimation how many hours per week you
are working on your tasks in youre team? Does this fit the amount of
time you can really afford for this task?
- I recently had some discussion on Chemnitzer Linuxtage what might
be the reason for derivatives to write their own installers. While
I'm personally perfectly happy with the way I can install Debian I'm
somehow wondering why others are spending time into a problem we
are considering "solved" and whether we can learn something from this,
- I once had a amr64 based laptop (Pinebook) and had to learn that I
can't use the Debian installer which was frustrating. I was told
that this is the case for hardware that is not featuring some BIOS-like
boot system. Do you see any chance to let the installer work for
non-Intel architectures (or should I rather ask this question on
Debian CD (sorry for my ignorance if I miss responsibility here.)
- Can I do anything for you?
It probably wouldn't harm to offer some funding to osuosl, because they
let us use their systems for various things and making sure that they
are sustainable would be wise. (that's who host most of what I'm running openqa on at present, and they also host jenkins and reproducible things AFAIK)
- Do you feel good when doing your work in Debian Boot team?
- Do you consider the workload of your team equally shared amongst its
members and who actually is considered a team member? (I added some
persons in CC who have recently answered to questions on the mailing
list.)
- Do you have some strategy to gather new contributors for your team?
- Can you give some individual estimation how many hours per week you
are working on your tasks in youre team? Does this fit the amount of
time you can really afford for this task?
- I recently had some discussion on Chemnitzer Linuxtage what might
be the reason for derivatives to write their own installers. While
I'm personally perfectly happy with the way I can install Debian I'm
somehow wondering why others are spending time into a problem we
are considering "solved" and whether we can learn something from this,
- I once had a amr64 based laptop (Pinebook) and had to learn that I
can't use the Debian installer which was frustrating. I was told
that this is the case for hardware that is not featuring some BIOS-like
boot system. Do you see any chance to let the installer work for
non-Intel architectures (or should I rather ask this question on
Debian CD (sorry for my ignorance if I miss responsibility here.)
- Can I do anything for you?
What follows is only my point of view, and anyone active within the
installer team is welcome to share their own.
ACK. TL;DR: no strong organization, mainly some coordination around
releases, but otherwise debian-boot gets to consume whatever ends up in testing/unstable, and has to adapt accordingly. Of course we have some packages on our own in addition to all the dependencies that we don't maintain.
You might have notice some heavy pushes in the past to get firmware
support improved (enough to avoid black or unreadable screens post installation, in earlier releases), or to get non-free-firmware included
(in Debian 12).
I don't have any important or urgent needs at the moment, but I won't hesitate if I spot something that could benefit from your input.
I'm sure not everybody will be able to travel this distance but it
would be great if you would at least consider joining that BoF
remotely. I'll care for a somehow TimeZone aware scheduling - if
needed we'll organise two BoFs to match all time zones. I'm also
aware that we have pretty different teams and it might make sense to
do some infrastructure related BoF with your team and other teams that
are caring for Debian infrastructure.
Anticipating and planning a full week (or more) off that much in the
future is something I can't do at this point, but I'm usually fairly
flexible when it comes to timezones, so joining remotely should work, at least in principle.
I have some specific questions to the Debian Boot team.
- Do you feel good when doing your work in Debian Boot team?
That's been the case from the moment I joined (around 2012, even if
first contact happened in 2010-2011 with the DirectFB → X.Org
transition, see https://mraw.org/blog/2010/01/31/Saving_private_GI/).
And until last year, right after the Bookworm release, for reasons I
cannot and wouldn't want to express publicly at this time (relevant team Bcc'd). What should have been a thumbs-up-all-around celebration turned
into the most severe burnout I've ever felt, personally, professionally,
and “debian-ly”, right after having sacrificed a lot (on all 3
accounts).
I can endure hard work. Feelings like betrayal or distrust is something
else entirely.
I've come back to doing a few things here and there (including dealing
with 64-bit time_t fallouts on the d-i side, reviewing Netplan's initial integration, or blends stuff as you know), but I'm nowhere near to
feeling good again about doing d-i things.
Which is absolutely heartbreaking because I've been doing that for a
while, still enjoy doing it, and really don't want to leave it. And even
if I'm not one to boast, I thought I had been doing a pretty fucking
good job. Until last year that is.
We have a very diverse team with people dealing mostly (but not only!)
with i18n/l10n coordination (Holger), with QA (Phil), with some specific components (flash-kernel), with specific set(s) of images, etc. It's
more a bits & pieces depending on one's area(s) of interest.
In the end, I'm the one making sure things look “good enough” when preparing a release makes sense, usually in coordination with various
teams (see frequent mails to -boot, -release, -kernel, -cd, and -live
during the bookworm release cycle, and also in previous ones). I don't
think I need to prepare any statistical analysis, but if memory serves,
those mails have usually been met with silence, tacit or explicit
approval, and I don't remember any crazy ideas from mine needing to be
shot down or rehashed differently -- even I wouldn't mind if it
happened: I know freezing testing can impact any maintainer, but the -boot/-cd release process has been quite improved over the years (also
with the help of -ftp), and it's usually about skipping a few britney
runs for /some/ packages anyway, so overall impact should still be
minimal.
- Do you have some strategy to gather new contributors for your team?
I've always tried to communicate about what we're doing (via list, blog, talks…), but I don't have any plan to get more people involved.
Even if we had brand new people joining all of a sudden, the learning
curve is steep, and they would likely need some mentor to guide them
through, which also requires time and effort, and time is the scarcest resource in the world in my view.
...
As alluded to above, 2023 was different, since we've had a decision via
GR about non-free-firmware for several months and nobody doing anything,
and I ended doing most of the work in many areas (thankfully with people ACKing/deploying changes I submitted and/or further changes where I
couldn't do that myself), which required sacrifices. I wouldn't want
that to happen again, but I'm not aware of any more such game changers,
so a redux seems unlikely (famous last words, eh?).
- I recently had some discussion on Chemnitzer Linuxtage what might
be the reason for derivatives to write their own installers. While
I'm personally perfectly happy with the way I can install Debian I'm
somehow wondering why others are spending time into a problem we
are considering "solved" and whether we can learn something from this,
I've already said that multiple times: we have people regularly coming
up with brand new ideas on how d-i sucks and how they're going to do
better. They're absolutely free to do that, and we already have various
ways to use d-i, plus debian-live's installer.
Actual work and commitment, that I haven't quite seen.
I don't want to put words into debian-cd's mouth, but I think Steve and
I already agreed a few times we could be running extra build steps to generate different images with different approaches to the install
process, and I've never stopped anyone from doing so.
Keeping the status quo requires quite some work already, and I cannot
(and also don't want) to lead any “let's break it all down” revamp. But again, I'm not stopping anyone from proposing something different.
- I once had a amr64 based laptop (Pinebook) and had to learn that I
can't use the Debian installer which was frustrating. I was told
that this is the case for hardware that is not featuring some BIOS-like
boot system.
[citation needed]
Do you see any chance to let the installer work for
non-Intel architectures (or should I rather ask this question on
Debian CD (sorry for my ignorance if I miss responsibility here.)
debian-boot is fine, and we work hand-in-hand with debian-cd anyway
(the intersection between team rosters is… not empty).
I'm not sure why you have the impression the installer only work on
Intel… See the architectures for which we provide images,
the installer
is expected to work on all of them. Of course there could still be
specific problems for this or that model of a given architecture. But
that means filing a bug with details, then see what it can be done.
arm* are special as they can be booted in many different ways, like a specific bootloader (Raspberry), u-boot (maybe a vendored copy), and/or flash-kernel (details depend on the board, revision, configuration,
etc.), and possibly others.
Last I heard about Pinebook, some patches were missing in the upstream
(and Debian's kernel) to work at full speed, but the claim above is
overly broad and totally false.
- Can I do anything for you?
Not at this time.
Tschüs!
sorry for my late reply - I was basically offline the last couple
of days.
However, my question was rather whether you know some valid reasons
why derivatives are exchanging the install method - maybe that
question should be better asked on Debian-Boot (if so feel free to
ignore this question). I was rather wondering about the motivation
for the usage of Ubiquity or Calamares (or others?). I might be naive
but from my perspective installing is something that just needs to
work and having a lot of ways to make this working is somehow burning developer time. So what according to your insight is motivating
derivatives to solve a problem in a different way that is IMHO solved
by Debian.
Sure there is an arm64 image and I started with copying this to some
USB stick. But that hardware did not booted from an USB device but
only from eprom that had to be flashed via SD card. Its not your
fault definitely but was frustrating for me not beeing able to simply
run the Debian installer.
It was not really a claim but a question based on my experience with a
single piece of hardware. I was hoping for some ideas how we could
motivate hardware vendors to deliver hardware that can be easily
booted by simply plugging in some USB device featuring the installer
images we provide on our web page.
Just keep in mind my offer to contact me in private if needed.
This is mostly because I found that I wasn't able to devote the time
required to test things to my satisfaction when my first daughter came
along,
as I'd be distracted before I completed my tests, so I decided to
do something about automating testing, and I've been down that rabbit
hole ever since. When I'm working on that, I'm pretty happy.
I'd say that that work is now bearing some fruit, finally. I had
originally hoped that I'd then be able to put more effort into D-I
itself, but I suspect that maintaining openQA and the Salsa pipeline
stuff may continue to eat a fair amount of my time.
- Do you consider the workload of your team equally shared amongst its
members and who actually is considered a team member? (I added some
persons in CC who have recently answered to questions on the mailing
list.)
My contributions are pretty-much background noise recently, so I guess
that means that the load is very unequal if you were including me in the stats.
Cyril has been responsible for keeping D-I viable in recent times, and
Holger also does _loads_ of (mostly translation related) work too.
- Do you have some strategy to gather new contributors for your team?
One of my intentions with the salsa/openQA work is that I'm trying to
make it possible for people to make simple changes to bits of D-I and
have them receive feedback about whether the result is an improvement.
Hopefully that will lower the bar to new people contributing.
- Can you give some individual estimation how many hours per week you
are working on your tasks in youre team? Does this fit the amount of
time you can really afford for this task?
My work on D-I is pretty sporadic, because I generally pick some small
thing in D-I to use as a test of the current salsa/openqa setup, and
then spend significantly more time sorting out some new wrinkle that's revealed in the salsa and/or openqa setup by this new example.
Often this means that by the time I've finished, someone else has
already dealt with the original bug/patch in D-I. I'm not sure to what
extent that counts as D-I work, but I'm happy with the time I spend on
it.
- I recently had some discussion on Chemnitzer Linuxtage what might
be the reason for derivatives to write their own installers. While
I'm personally perfectly happy with the way I can install Debian I'm
somehow wondering why others are spending time into a problem we
are considering "solved" and whether we can learn something from this,
I quite like it as it is, but I'm sure many would not find the installer particularly pretty, and it is quite hard to work on (being in busybox
shell, and lacking popular things like python), and I personally have no
idea how easy/possible it is to e.g. change its branding (if a
downstream wanted to do that).
If one doesn't care about installing on our minority architectures, then
it's possible to do something that's much easier to work on by booting a
live image. One can then have something that'll ask all the questions up-front (especially if one is opinionated about what should be on the resulting system), and then apply that to the system without further interaction.
Some arm64 things certainly can be installed with D-I, because I have
openQA workers running on altra.debian.net testing D-I installs, but I
don't know that much about the details.
- Can I do anything for you?
I'm currently looking into the options that might be worth exploring for getting more openqa-workers running. I suppose at some point that might involve asking for funds to be spent, but I'm not at that stage yet.
It probably wouldn't harm to offer some funding to osuosl, because they
let us use their systems for various things and making sure that they
are sustainable would be wise. (that's who host most of what I'm running openqa on at present, and they also host jenkins and reproducible things AFAIK)
However, my question was rather whether you know some valid reasons
why derivatives are exchanging the install method - maybe that
question should be better asked on Debian-Boot (if so feel free to
ignore this question). I was rather wondering about the motivation
for the usage of Ubiquity or Calamares (or others?). I might be naive
but from my perspective installing is something that just needs to
work and having a lot of ways to make this working is somehow burning developer time. So what according to your insight is motivating derivatives to solve a problem in a different way that is IMHO solved
by Debian.
You seem to be asking the wrong person. I don't know about downstream's motivation, the various alternatives/competitors, etc., and I wouldn't
have time to investigate if I wanted to (and I'm not saying that's the
case).
Sure there is an arm64 image and I started with copying this to some
USB stick. But that hardware did not booted from an USB device but
only from eprom that had to be flashed via SD card. Its not your
fault definitely but was frustrating for me not beeing able to simply
run the Debian installer.
I understand the frustration (“welcome to the ARM world…”) but (1) the initial statements were a very wrong conclusion from your findings and
(2) even with hardware that's supposed to be supported by free software
we might need time to spot, fix, or workaround bugs (hardware, software, firmware, doc, etc.) or integrate new features to support new boards.
That's not specific to d-i, that's just how IT works.
It was not really a claim but a question based on my experience with a single piece of hardware. I was hoping for some ideas how we could motivate hardware vendors to deliver hardware that can be easily
booted by simply plugging in some USB device featuring the installer
images we provide on our web page.
UEFI/arm64 is a thing. Whether HW vendors actually implement/enable UEFI
is another matter entirely (see early EEPROM versions on e.g. Pi 4).
Andreas Tille <tille@debian.org> wrote (Sun, 26 May 2024 11:31:24 +0200):
- Do you feel good when doing your work in Debian Boot team?
While I have to admit that I'm mostly doing just the simple things :-)
I consider myself being only a small candle on the cake.
Being not a programmer, I don't do difficult or critical changings most of the time, so relaxed gaming here ;-)
- Do you consider the workload of your team equally shared amongst its
members and who actually is considered a team member? (I added some
persons in CC who have recently answered to questions on the mailing
list.)
My impression is, that kibi might be kind of overloaded (at least some time), since he's the mainly active part, when it comes to the "difficult or critical things", which I leave around ...
(and his answer to this survey confirms this)
But I cannot see what I can do against this :-( (see below)
(ok, that's not strictly correct generally, there are some people taking care of specific packages, taking workload from kibi's shoulders, but that's not for the majority of packages)
- Do you have some strategy to gather new contributors for your team?
Since I lack the skills to lead new contributors into doing the difficult
or critical things from above (where we would mostly need more manpower,
if at all), I'm a bit lost here ...
- Can you give some individual estimation how many hours per week you
are working on your tasks in youre team? Does this fit the amount of
time you can really afford for this task?
This ranges from zero to 5-10 hours per week, depending on variables like
the state of development cycle of release (when the next release comes nearer, I try to get missing translation updates, which leads to more
commits and uploads, as an example).
And: I'm fine with this time effort.
- I recently had some discussion on Chemnitzer Linuxtage what might
be the reason for derivatives to write their own installers. While
I'm personally perfectly happy with the way I can install Debian I'm
somehow wondering why others are spending time into a problem we
are considering "solved" and whether we can learn something from this,
That was often mentioned, and the arguments for the Debian Installer was the broader range of architectures, and as well as the support for older hardware.
You can easily create a nicer installer, if you develop from scratch for only a small variety of up-to-date devices.
OTOH since Buster we have the Calamares installer on the live images as well, to serve such approaches.
The idea behind the Calamares installer is exactly that: develop a framework, which can be used to install a variety of distributions, to solve those distributions from developing their own installer.
So I think we are on a not that bad position here ... (?)
- I once had a amr64 based laptop (Pinebook) and had to learn that I
can't use the Debian installer which was frustrating. I was told
that this is the case for hardware that is not featuring some BIOS-like
boot system. Do you see any chance to let the installer work for
non-Intel architectures (or should I rather ask this question on
Debian CD (sorry for my ignorance if I miss responsibility here.)
- Can I do anything for you?
I guess most teams are undermanned in the free software world, and there's nothing one can do against easily, but I consider this being the main "issue",
if any...
Any experiences with Lenovo Thinkpad X13S? Finally Lenovo is present on DebConfs and we can talk to them. Just from reading[1] it seems to be
what I'm looking for in principle - provided they might unbundle Win11
from it and I can just plugin the Debian installer USB to install
Debian.
Trixie runs fine on it, though there are some rough edges. Full details
on https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s
For details of the work done on the kernel/installer/cd/live images: https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Rocca
Am Fri, Jun 07, 2024 at 09:29:18AM +0200 schrieb Emanuele Rocca:
Trixie runs fine on it, though there are some rough edges. Full details
on https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s
Two things somehow would prevent me from buying:
Hibernation: {X} Unsupported(No Driver)
Sleep / Suspend: /!\ (works, but drains battery in a day)
Is there any progress to let Hibernate / Suspend working properly?
"Given that the next step needs Windows anyways, we're documenting the Windows option here."
Argh, I need Windows to install Linux. That's IMHO a no-go. I do not
buy and hardware which has Windows preinstalled / needs Windows for
whatever purpose. Do you think that this could/should be a topic to
talk about with some Lenovo representative at DebConf?
I have no hardware to try this on,
but don't think Windows is strictly
required. None of the usual tools liked the self-extracting exe, but it extracted fine under Wine on x86. The archive contains instructions on
how to create a bootable USB stick with an EFI application and the new firmware image. Nothing there you must have or use Windows for. Just
create the USB stick and boot from it.
Additional fun fact - their Bootaa64.efi application includes this string:
/mnt/c/Ubuntu/LenovoTools-GCC-BuildEnv/Scripts/Ubuntu/Build/LenovoToolsPkg/RELEASE_GCC5/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll
So you can do without Windows, but they can't do without Debian :-)
Argh, I need Windows to install Linux. That's IMHO a no-go. I do not
buy and hardware which has Windows preinstalled / needs Windows for whatever purpose. Do you think that this could/should be a topic to
talk about with some Lenovo representative at DebConf?
Well, buying this thing without Windows is still going to be hard...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 483 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 17:39:13 |
| Calls: | 9,617 |
| Calls today: | 3 |
| Files: | 13,692 |
| Messages: | 6,156,571 |