Re: Making Debian available

[Andrew M.A. Cater]

On Fri, Jan 15, 2021 at 03:15:14PM -0500, Theodore Ts'o wrote:
> On Fri, Jan 15, 2021 at 09:35:01AM -0800, Russ Allbery wrote:
> > 
> > The point is to make things easier for our users.  Right now, we're doing
> > that for you but not for the users who don't care whether firmware is
> > non-free.  I think the idea is that we should consider making things
> > easier for both groups of users.  There's no reason to make things worse
> > for you and others who want the fully free installer in the process.
> 
> I wonder if a compromise would be to make an install CD/DVD which
> contains the non-free packages, but which gives the user the option to
> abstain from using said non-free packages --- it can explain that the
> non-free packages may be needed for some hardware, but why people who
> are committed to Free Software might prefer loss of functionality to
> using non-free software.
> 
It already does: the second or third question gives you the option to install
 non-free firmware, if needed, from a USB stick. That method does work but 
very few people use it.

The state of firmware: (personal opinion)

Sound drivers used to be a problem - that's mostly been solved, though as 
we've seen with signed drivers for Lenovo and others, that problem may be 
coming back. Software modem drivers were always a problem. There are problems 
with non-free firmware for a few Ethernet cards - though there's generally 
some fallback mode. If you can use a wired interface to install - even if 
that's via USB-Ethernet dongle, do so because it's reliable and you can 
install the wireless drivers later. [And we are _so_ much further forward
than we were for Debian 1.2 or 1.3]

Video drivers: we have some basic video modes that work for text mode on 
nearly all cards / embedded chipsets. Other than that, almost everything 
requires a non-free driver. AMD/Intel/Nvidia are all, in their own ways, 
equally bad. Video chipsets change fairly frequently: invariably, newest 
laptops are always a pain.  

We're discovering an additional class of problems for anybody still booting in 
Legacy/BIOS mode because some newer cards only really work with UEFI. It's 
generally true that the drivers in stable won't work for latest/greatest cards
/chipsets and you'll need backports (and sometimes even a newer kernel) 
[And don't get us started on jumping through hoops for gaming laptops with 
two chipsets - either Intel and Nvidia or AMD and Nvidia!!]

Wifi is the tough one: The companies that dominate laptop chipsets - 
Broadcom/Realtek/Qualcomm don't make it easy to find out which particular 
chipset it is. For USB Wifi connectors it's even harder - lots of Realtek 
chipsets in cheap dongles seem to require you to go and get a repository
from git and build DKMS - RTL8812* springs to mind.

We're explicit about the status of non-free drivers - the problems are that we
can't fix them when they break, we can distribute them but we can't sort out
any problematic behaviour. We are very dependent on others to make the 
fixes and have no timeline for improvements. Non-free drivers are not in our 
control in any way. There is no incentive on major manufacturers to 
change this.

Ubuntu *just ship* many of the drivers we consider as non-free : their 
priorities are different and that's OK - but I still notice people with Ubuntu 
laptops asking the same questions about how to get wifi working / folks with
Ubuntu derivatives coming to Debian lists for help.

> We might still need to continue to ship a CD/DVD which completely
> omits the non-free software, since for some people they might object
> to having any non-free bits on their install media, regardless of
> whether or not they are used.
> 
Having a CD which is "completely free" is useful for VMs / containers - and 
is also a good basis for Trisquel and other derivatives. The way we have it
set up at the minute also means that if we have one buggy non-free driver we
don't have to remaster every image. It's all a trade off.

> But having a non-free installer where the use of non-free packages is
> optional, perhaps that might be a sufficient compromise that we could
> make that installer more easily findable, instead of leaving it in
> a "locked filing cabinet stuck in a disused lavatory with a sign on the
> door saying ‘Beware of the Leopard.'".

See above - we have a free isntaller where the use of non-free is optional and 
flagged.
> 
> After all, for people who very on the "non-free is evil and must be
> avoided at all costs" spectrum, this installer would help them get
> their message out --- and after providing the pro-Free-Software-at-all
> costs message to users that might oherwise might not get it (remember,
> these are people who had previously been using Windows 10), we trust
> users to choose how they come down on the question.
> 
> Just a thought
> 
>   - Ted
> 

Maybe all of this comes down to a huge FAQ for -devel, -user and other lists 
including la

Re: Making Debian available

[The Wanderer]

On 2021-01-16 at 05:58, Andrew M.A. Cater wrote:

> On Fri, Jan 15, 2021 at 03:15:14PM -0500, Theodore Ts'o wrote:
> 
>> On Fri, Jan 15, 2021 at 09:35:01AM -0800, Russ Allbery wrote:
>> 
>>> The point is to make things easier for our users.  Right now,
>>> we're doing that for you but not for the users who don't care
>>> whether firmware is non-free.  I think the idea is that we should
>>> consider making things easier for both groups of users.  There's
>>> no reason to make things worse for you and others who want the
>>> fully free installer in the process.
>> 
>> I wonder if a compromise would be to make an install CD/DVD which 
>> contains the non-free packages, but which gives the user the option
>> to abstain from using said non-free packages --- it can explain
>> that the non-free packages may be needed for some hardware, but why
>> people who are committed to Free Software might prefer loss of
>> functionality to using non-free software.
> 
> It already does: the second or third question gives you the option to
> install non-free firmware, if needed, from a USB stick. That method
> does work but very few people use it.

That's not what Ted seems to be suggesting, though. It still requires
you to obtain the firmware separately and provide them separately - and,
per comment seen elsewhere just this morning (#980205), apparently
doesn't make clear *where* and *how* to provide that firmware.

What I read Ted as suggesting is that there be available an installer
image which *has those files / packages already present*, but prompts
the user to decide whether or not the installer should make use of them.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Videoconference tomorrow, Sunday 2021-01-17 18:00 UTC (Was: For those who want to keep on contributing (Was: Debian @ COVID-19 Biohackathon (April 5-11, 2020))

[Andreas Tille]

Hi,

this is the call for the nect video conference of the Debian Med team
that are an established means to continue the COVID-19 hackathon in
April[1] and we do it twice per month on every

   2th  and  17th

of a month.  So the next meeting is tomorrow 18:00 UTC

For those who would like to join our next videomeeting it will happen at
   
 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Debian+CoViD-19+Biohackathon+Video+Conference&iso=20210117T19&p1=37&ah=1

The meeting is on the Debian Social channel

 https://jitsi.debian.social/DebianMedCovid19

These video meetings were started in the Debian Med Biohackathon[1].
The topic is what contributors have done in the past week and to
coordinate the work for next week.  Here are the reports of some past
meetings:

 https://wiki.debian.org/DebianMed/Meeting/WeeklyCovid19

I'd like to repeat myself: Newcomers are always welcome.

Lets keep on the great work
   
   Andreas.

[1] https://lists.debian.org/debian-devel-announce/2020/03/msg00010.html
[2] https://lists.debian.org/debian-med/2020/11/msg00334.html

-- 
http://fam-tille.de

uscan/watch regexp and multiple versions

[Alastair McKinstry]

Hi,

I'm adding watch files for projects, and have a problem with multiple 
version number epochs in a github release.


Some of the stack(s) i'm watching have versions, eg. "3.4.1" but also 
bundled version numbers "2020.10.1" that I wish to ignore;


Is there any examples how to set watch files to _ignore_ patterns as 
well as watch them?


Thanks

Alastair


--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Re: uscan/watch regexp and multiple versions

[David Prévot]

Hi Alastair,

Le 16/01/2021 à 08:02, Alastair McKinstry a écrit :

Some of the stack(s) i'm watching have versions, eg. "3.4.1" but also 
bundled version numbers "2020.10.1" that I wish to ignore;


Why not use a regex that matches the first one but not the last one, 
maybe something like .*/v?(\d\d?\d?\..+).tar\.gz?


Regards

David

Re: Making Debian available

[Russ Allbery]

"Andrew M.A. Cater"  writes:

> It already does: the second or third question gives you the option to
> install non-free firmware, if needed, from a USB stick. That method does
> work but very few people use it.

This is the method that I personally always use, but I install systems
infrequently and every time I install a new system I have to work out
again from scratch how to make this work.  It sounds like it should be
simple, and yet it never is.  Something always goes wrong: I can't figure
out the right place to put the firmware, the firmware files are in the
wrong format, the prompts for when to switch USB sticks from the installer
to the firmware stick aren't at the right time, or *something*.

I have always managed to get it to work, but usually it's an hour of
cursing and Googling things and making different USB sticks in different
formats with different file systems and retrying parts of the installation
until I hit on the magic combination of factors to make it work.  And then
I promptly forget how to do it in the two years before I get another new
computer for some reason.

The installer with non-free firmware built in would, I think, be better.
I know it exists, but last time I wasn't able to use it because I needed a
testing installer, not a stable installer, for some hardware reason, and I
couldn't find the non-free testing installer for some reason.  (This was
probably my failing.)

I'm sure that much of this is my personal problem, but I can say that even
a person who is quite familiar with Debian and has installed a lot of
Debian systems struggles with the current set of options and has a hard
time finding a path that works.

> Wifi is the tough one: The companies that dominate laptop chipsets -
> Broadcom/Realtek/Qualcomm don't make it easy to find out which
> particular chipset it is. For USB Wifi connectors it's even harder -
> lots of Realtek chipsets in cheap dongles seem to require you to go and
> get a repository from git and build DKMS - RTL8812* springs to mind.

For the record, this is always the problem I have.  The last system I
installed didn't have an Ethernet port.  I think there was some way to
make Ethernet work over USB, but I didn't have the right hardware.

-- 
Russ Allbery (r...@debian.org)  

Re: Making Debian available

[Andrey Rahmatullin]

On Sat, Jan 16, 2021 at 09:27:28AM -0800, Russ Allbery wrote:
> The installer with non-free firmware built in would, I think, be better.
> I know it exists, but last time I wasn't able to use it because I needed a
> testing installer, not a stable installer, for some hardware reason, and I
> couldn't find the non-free testing installer for some reason.  (This was
> probably my failing.)
No, this is explicitly failing of the Debian websites, specifically their
parts covering the ISOs.
Looks like the only sane way to get the ISOs is to remember the domain
that you used previously and so open https://cdimage.debian.org/ directly
(which of course redirects to https://www.debian.org/CD/), then navigate
to https://www.debian.org/CD/http-ftp/, then choose between stable and
testing, to get either to https://www.debian.org/CD/http-ftp/#stable and
then to https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ or to
https://cdimage.debian.org/cdimage/weekly-builds/ and then manually to
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/. There you
are supposed to read the opening text and find the usable ISO pointer in a
statement "For convenience for some users, there is an alternative
unofficial netinst CD build which includes non-free firmware for extra
support for some awkward hardware." (I think I won't provide any public
comments on the content of this statement).
I'm not sure how to find the stable firmware ISO easier than the testing
one (or easier than the way described above), as from
https://www.debian.org/, if you know where to click, you can get in 3
clicks to https://www.debian.org/distrib/netinst which lists direct ISO
links. Maybe it was possible on the old design though (but I suspect not).

> I'm sure that much of this is my personal problem, but I can say that even
> a person who is quite familiar with Debian and has installed a lot of
> Debian systems struggles with the current set of options and has a hard
> time finding a path that works.
I'm sure that nothing of this is a failure of anyone or anything other
than the pages listed above.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Making Debian available

[Andrew M.A. Cater]

On Sat, Jan 16, 2021 at 10:50:19PM +0500, Andrey Rahmatullin wrote:
> On Sat, Jan 16, 2021 at 09:27:28AM -0800, Russ Allbery wrote:
> > The installer with non-free firmware built in would, I think, be better.
> > I know it exists, but last time I wasn't able to use it because I needed a
> > testing installer, not a stable installer, for some hardware reason, and I
> > couldn't find the non-free testing installer for some reason.  (This was
> > probably my failing.)
> No, this is explicitly failing of the Debian websites, specifically their
> parts covering the ISOs.
> Looks like the only sane way to get the ISOs is to remember the domain
> that you used previously and so open https://cdimage.debian.org/ directly
> (which of course redirects to https://www.debian.org/CD/), then navigate
> to https://www.debian.org/CD/http-ftp/, then choose between stable and
> testing, to get either to https://www.debian.org/CD/http-ftp/#stable and
> then to https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ or to
> https://cdimage.debian.org/cdimage/weekly-builds/ and then manually to
> https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/. There you
> are supposed to read the opening text and find the usable ISO pointer in a
> statement "For convenience for some users, there is an alternative
> unofficial netinst CD build which includes non-free firmware for extra
> support for some awkward hardware." (I think I won't provide any public
> comments on the content of this statement).

That's the trail of breadcrumbs: 
* I'm not sure _even if_ you put the non-free installer up on the front page, 
that it would solve wifi problems for all values of wifi firmware
* I'm not sure that we can solve the video firmware problems by incorporating 
all firmware for all possible chipsets on CD media - and I'm not sure that you
can meaningfully know ahead of time exactly which of several you'll need. If 
you need to find one set of firmware, then it's all in one place in 
non-free

> I'm not sure how to find the stable firmware ISO easier than the testing
> one (or easier than the way described above), as from
> https://www.debian.org/, if you know where to click, you can get in 3
> clicks to https://www.debian.org/distrib/netinst which lists direct ISO
> links. Maybe it was possible on the old design though (but I suspect not).
> 
> > I'm sure that much of this is my personal problem, but I can say that even
> > a person who is quite familiar with Debian and has installed a lot of
> > Debian systems struggles with the current set of options and has a hard
> > time finding a path that works.
> I'm sure that nothing of this is a failure of anyone or anything other
> than the pages listed above.
Point about difficulty of instructions for putting firmware onto USB  noted. 
Maybe that's something that can be improved on the website itself 
fairly readily.

All best,

Andy C

> 
> 


> -- 
> WBR, wRAR

Re: Making Debian available

[Andrey Rahmatullin]

On Sat, Jan 16, 2021 at 06:18:07PM +, Andrew M.A. Cater wrote:
> That's the trail of breadcrumbs: 
> * I'm not sure _even if_ you put the non-free installer up on the front page, 
> that it would solve wifi problems for all values of wifi firmware
It won't solve wifi problems for all values of wifi *hardware*, because as
was already mentioned not all drivers are in Debian.
Not sure what *firmware* problems won't be solved, though, but I'm sure
most of them will.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Making Debian available, non-free promotor

[Philipp Kern]

On 15.01.21 13:42, Ansgar wrote:
> On Tue, 2021-01-12 at 19:30 +0100, Geert Stappers wrote:
>> Ah, yes I also wonder how much the world will improve
>> if non-free would be split in non-free and non-free-firmware.
>> Currently is non free firmware a hugh promoter of non-free in
>> /etc/apt/sources.list
> 
> I proposed moving non-free firmware to a new non-free-firmware some
> time ago[1], but then it seemed like there was no consensus on this
> which I though we had before.  Some people wanted non-free/firmware
> instead (different name), wanted packages to start appearing in
> multiple components (non-free and non-free[/-]firmware), wanted
> additional categories (e.g. non-free/doc for Free Software Foundation
> stuff), wanted non-free drivers as well, wanted major changes how
> components work (which might imply incompatible changes for mirroring
> tools and so on), ...

I idly wonder if we could call it firmware and call it a day. I tried to
propose that a bunch of times and was not successful either (e.g. it was
unclear to me if that needed a GR).

I guess better non-free filtering would not be a bad idea, though. For
the buildd network it is also still an unsolved question how to allow
build-depending on a (small, allowlisted) subset of non-free.

Kind regards
Philipp Kern

Re: Making Debian available

[Andreas Tille]

On Sat, Jan 16, 2021 at 10:58:33AM +, Andrew M.A. Cater wrote:
> It already does: the second or third question gives you the option to install
>  non-free firmware, if needed, from a USB stick. That method does work but 
> very few people use it.

>From my own experience I tried to provide those files on an USB stick in
two or three installations (in the past - sorry I do not remember when
but it was more than one year ago).  It never worked as expected and I
always was falling back to the non-free installers.  
 
> Sound drivers used to be a problem -

For me always network drivers were the problem and after I finished one
or two installations without network and fiddled around with the network
manually afterwards I stopped using the free installers in general.
Since then the machines I installed with non-free firmware right in the
beginning the installation experience was pretty smoothly on different
hardware (even quite fresh one).  IMHO the fact that people claim that
"Ubuntu is easy to use but Debian is not" is to quite some amount based
on this kind of experience of users who do not know that kind of basics
and are not able to fix a rudimentary system afterwards.

> Video drivers: we have some basic video modes that work for text mode on 
> nearly all cards / embedded chipsets. Other than that, almost everything 
> requires a non-free driver. AMD/Intel/Nvidia are all, in their own ways, 
> equally bad. Video chipsets change fairly frequently: invariably, newest 
> laptops are always a pain.  

Also here I was lucky after using the non-free driver installers in
contrast to the free ones.
 
> Ubuntu *just ship* many of the drivers we consider as non-free : their 
> priorities are different and that's OK - but I still notice people with 
> Ubuntu 
> laptops asking the same questions about how to get wifi working / folks with
> Ubuntu derivatives coming to Debian lists for help.

This might happen yes.  But my personal experience is that random users
do not even try Debian since they know from "competent friends" that
Debian is way harder to install than Ubuntu.  I admit I'm a bit bored by
this discussion and I do not really want to open that can of worms of
the relation between Debian and Ubuntu but I'm pretty sure that
providing an installer to the masses that has a high probability to
create extra work is not the best idea to attract users.
 
Kind regards

  Andreas. 

-- 
http://fam-tille.de

Re: Making Debian available

[Russell Stuart]

On 17/1/21 3:27 am, Russ Allbery wrote:

"Andrew M.A. Cater"  writes:
Wifi is the tough one: The companies that dominate laptop chipsets 
- Broadcom/Realtek/Qualcomm don't make it easy to find out which 
particular chipset it is. For USB Wifi connectors it's even harder 
- lots of Realtek chipsets in cheap dongles seem to require you to 
go and get a repository from git and build DKMS - RTL8812* springs 
to mind.


For the record, this is always the problem I have.  The last system I
installed didn't have an Ethernet port.  I think there was some way 
to make Ethernet work over USB, but I didn't have the right 
hardware.


To me, this is *the* problem. I always use netinst. Once the thing is
running editing /etc/apt isn't hard, so all netinst has to do is a base
image install. But, if I can't get the network up and see the disks I
can't install.

Seeing the disks is invariably caused by the kernel not recognising a
modern chipset, which means I must install with testing that has a
matching modern kernel. Working WiFi almost always requires firmware.
Testing doesn't produce netinst with non-free firmware and I'm normally
installing several of these things, so I have now become proficient in
rolling my own non-free netinst.

I guess it might be possible to make it harder to install Debian on a
new laptop, but rolling your own netinst sets a pretty high bar so you
would have to work at it. I occasionally get asked to install Debian,
and it's hard enough that I carry a USB with one of these netinst's on
me at all times, along with my GPG fingerprints.

So for me at least, the fix doesn't require putting all of non-free on
the install media. It just requires firmware-*. (Which brings me to
another whinge: why doesn't firmware-linux-nonfree include things like
firmware-iwlwifi so I don't have to go on a whumpus hunt for every
firmware package. Sigh.)

I happen to strongly agree with the sharp distinction between free and
non-free in the archive. But in this case, I think we should be carving
out an exception.

If you want a softener for those rigid ideals (I need one myself), try
this: these firmware blobs are peculiar. They don't run on the same CPU,
we talk to them with strictly open API's and protocols. In that way,
they aren't anything new. We already talk to and depend on megabytes of
nonfree software to get our laptop's booted, but we tolerate it because
it lives in ROM. We don't consider firmware in ROM to be part of Debian
even though it must be running for our Debian machines to run. It's true
the difference is these problematic firmware blobs do live in Debian
packages, but it's not because we package them in most of the usual
senses: we don't compile them, or modify them and no software packages
by Debian inspects their contents. For these firmware packages the
packaging system has been reduced to something that does a good
imitation of a copper wire: faithfully coping some bits from the
manufacturer to the hardware they made.

My suggestion is we could create a new section of the archive for
packages that places far stronger restrictions on what Debian is allowed
to do with the packages contents (to wit: be a conduit between two
external parties, and no nothing else), and in return we do tolerate it
on our install images.

We already tolerate something similar. fwupdate pulls down non-free
blobs onto our Debian boxes, and installs them so our Debian machines
can use the firmware therein. It's in free, and AFAICT no one has a
problem with that. This is a step beyond fwupdate of course, as the
firmware is coming from our servers rather than someone else's. But I
would have thought that would make the situation better, not worse. This
is software we can vet at our leisure, take down / revert if it turns
out it violates our sensibilities, like say discovering a new version
has critical CVE's.  Firmware coming from our own servers, signed by our
keys gives us far more say on what non-free software we allow on our
machines than fwupdate does now.


OpenPGP_0xF5231C62E7843A8C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: Making Debian available

[Paul Wise]

On Sat, Jan 16, 2021 at 11:52 PM Russell Stuart wrote:

> Testing doesn't produce netinst with non-free firmware

There are both daily and weekly testing netinsts with firmware:

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/daily-builds/sid_d-i/current/amd64/iso-cd/
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/iso-cd/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

testing/bullseye: Still installing vino when we really should be installing gnome-remote-desktop

[Philip Wyett]

Hi,

Installing Debian testing and now also using bullseye-DI-alpha3, the
default desktop install/gnome is still installing vino and not
installing gnome-remote-desktop by default.

As we know, vino does not work with wayland and is not being actively
developed and focus has shifted to the wayland ready gnome-remote-
desktop.

Could we pre bullseye general availability (GA), rectify this issue and
have gnome-remote-desktop as the default installed?

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


signature.asc
Description: This is a digitally signed message part