Re: Vulkan with Radeon RX 5700 XT

[The Wanderer]

On 2021-07-10 at 21:30, Geoff wrote:

> The Wanderer wrote:
> 
>> (Warning, this is fairly long, and the situation involved includes
>> a fair number of potentially-moving pieces.)
>> 
>> 
>> I've recently built a new computer, installed Debian, configured it
>> to largely match my previous setup, and migrated my data across.
>> 
>> Now, I'm trying to take advantage of one of the hardware
>> improvements over the system I migrated away from: a newer,
>> better-performing GPU. In particular, I want to run software which
>> makes use of the Vulkan API for improved graphics performance.
> 
> I have an nvidia card but afaik the AMD driver is part of the kernel,
> what kernel version are you running? If your on stable and haven't
> already try getting a kernel from backports.

I think you're referring to the 'amdgpu' driver, correct?

As I indicated in my original post, that driver is already in use, and
in fact I already have (what appears to be) 3D acceleration via OpenGL.
It's just Vulkan that doesn't seem to see the card.

-- 
   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

Re: Vulkan with Radeon RX 5700 XT

[Geoff]

The Wanderer wrote:

(Warning, this is fairly long, and the situation involved includes a
fair number of potentially-moving pieces.)


I've recently built a new computer, installed Debian, configured it to
largely match my previous setup, and migrated my data across.

Now, I'm trying to take advantage of one of the hardware improvements
over the system I migrated away from: a newer, better-performing GPU. In
particular, I want to run software which makes use of the Vulkan API for
improved graphics performance.



I have an nvidia card but afaik the AMD driver is part of the kernel, what 
kernel version are you running? If your on stable and haven't already try 
getting a kernel from backports.

Regards
Geoff

Re: Buster no release file

[Greg Wooledge]

On Sat, Jul 10, 2021 at 09:25:51PM -0400, rhkra...@gmail.com wrote:
> On Saturday, July 10, 2021 06:44:47 PM Greg Wooledge wrote:
> > I was going to link you to the DebianBuster wiki page where I had put
> > the standard sources.list for buster, but it appears someone doesn't
> > want you to have that information.
> > 
> > https://wiki.debian.org/DebianBuster?action=diff=23=22
> > 
> > You can thank the person who goes by the name PaulWise for making your
> > Debian wiki a less informative and less useful place.
> > 
> > I *REALLY* and truly hate assholes like that.
> 
> +1
> 
> Do you know him or have had any contact with him (other than by virtue of the 
> change he made to the wiki)?

No, I've never heard of him before.

> I mean, it seems like if there was a good reason to delete that information 
> (which I can't imagine), he should have given a better explanation of why he 
> was deleting it.

I've dealt with people like this in other communities.  Some people
seem to feel that a wiki has a fixed format, and that certain pages
should *only* contain certain pieces of information, in a certain format,
and that any deviation from this historical format must be stamped out.

I don't know where this mindset comes from, but I'd bet there are
multiple Debian wiki editors who hold it.  There's rarely just one.
There's typically a self-appointed cabal.

If you ever wonder why the Debian wiki will never match the Arch wiki in
terms of quality, people like this are a part of the reason.

Re: Buster no release file

[rhkramer]

On Saturday, July 10, 2021 06:44:47 PM Greg Wooledge wrote:
> I was going to link you to the DebianBuster wiki page where I had put
> the standard sources.list for buster, but it appears someone doesn't
> want you to have that information.
> 
> https://wiki.debian.org/DebianBuster?action=diff=23=22
> 
> You can thank the person who goes by the name PaulWise for making your
> Debian wiki a less informative and less useful place.
> 
> I *REALLY* and truly hate assholes like that.

+1

Do you know him or have had any contact with him (other than by virtue of the 
change he made to the wiki)?

I mean, it seems like if there was a good reason to delete that information 
(which I can't imagine), he should have given a better explanation of why he 
was deleting it.

Aside: I meant to write to you some weeks ago to thank you for the information 
you maintain in your wiki.  Thank you!

Re: Buster no release file

[Polyna-Maude Racicot-Summerside]

Hi,

> I was going to link you to the DebianBuster wiki page where I had put
> the standard sources.list for buster, but it appears someone doesn't
> want you to have that information.
> 
> https://wiki.debian.org/DebianBuster?action=diff=23=22
> 
> You can thank the person who goes by the name PaulWise for making your
> Debian wiki a less informative and less useful place.
> 
> I *REALLY* and truly hate assholes like that.
> 

Those are the type of plague that give free software community a really
bad image. That kind of really stupid action of erasing others work only
because we are able to do so.

Wikipedia had the same problem and had to lock some pages.
That's a sad person to act this way.

At least we can still find what you wrote by looking thru revision but
we have to know there's something to look for.

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Vulkan with Radeon RX 5700 XT

[The Wanderer]

On 2021-07-10 at 19:08, The Wanderer wrote:

> On 2021-07-10 at 17:36, idiotei...@gmail.com wrote:

>> There you go, some packages are at the same version in Testing and
>>  Unstable, so you will see them in both.
> 
> (Just to confirm, are you the person who responded above under the
> name Brian Thompson and with the E-mail address
> tv.deb...@googlemail.com? Because the E-mail address is different,
> and I don't want to make assumptions in either direction.)

Argh. I checked this three times, and still managed to misread my
previous-mails list. The above name and E-mail address correspond to
different people; they're clearly not both you.

-- 
   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

Re: Vulkan with Radeon RX 5700 XT

[The Wanderer]

On 2021-07-10 at 17:36, idiotei...@gmail.com wrote:

> Le 10/07/2021 à 17:41, The Wanderer a écrit :
>
>> On 2021-07-10 at 07:43, tv.deb...@googlemail.com wrote:

>>> Hi, Debian unstable with bits of experimental here (because of the
>>> freeze I pull some newer packages from experimental). Same graphic
>>> card (5700XT), mesa drivers (21.1.4 at this precise moment, from
>>> experimental). Here vulkan works afaik.
>> 
>> For comparison, I have mesa-vulkan-drivers 20.3.4-1, from testing.
>> 
>>> vulkaninfo reports my card as:
>>> "Group 1:
>>>Properties:
>>>  physicalDevices: count = 1
>>>  AMD RADV NAVI10 (ACO) (ID: 0)
>>>  subsetAllocation = 0
>>>Present Capabilities:
>>>  AMD RADV NAVI10 (ACO) (ID: 0):
>>>  Can present images from the following devices: count = 1
>>>  AMD RADV NAVI10 (ACO) (ID: 0)
>>> "
>> 
>> That's excellent news; it means that, at least in principle, this
>> can work in (relatively-)clean Debian as currently constituted. (It
>> also confirms that RADV is the relevant thing here; my reading
>> wasn't conclusive as to whether or not that was specifically
>> something for older card models.)
>> 
>> Can you indicate exactly which Vulkan-related packages you're
>> running from experimental? For that matter, a list of
>> Vulkan-related packages and package versions from unstable too
>> would probably be appropriate, since I track testing and am
>> *highly* hesitant to upgrade against sid wholesale.
> 
> There you go, some packages are at the same version in Testing and 
> Unstable, so you will see them in both.

(Just to confirm, are you the person who responded above under the name
Brian Thompson and with the E-mail address tv.deb...@googlemail.com?
Because the E-mail address is different, and I don't want to make
assumptions in either direction.)

> "aptitude search '?narrow(?installed,?archive(experimental))' | egrep
>  '(mesa|vulkan)'

> aptitude search '?narrow(?installed,?archive(unstable))' | egrep 
> '(mesa|vulkan)'

> aptitude search '?narrow(?installed,?archive(testing))' | egrep 
> '(mesa|vulkan)'

Thanks; that's at least a reasonable starting reference point. It
doesn't seem to provide package versions, though, although I'm not sure
whether that would be as helpful as I originally thought to expect it to be.

I just ran

$ apt-cache policy $(aptitude search
'?narrow(?installed,?archive(testing))' | egrep '(mesa|vulkan)' | cut -d
' ' -f 3 )

and while the output is somewhat lengthier than I'd like to paste here
without reason, it does seem to tell me the versions I have installed of
each matching package.

When I have time - probably either later tonight, or tomorrow morning,
depending on GDQ interestingness levels - I'll go looking at what's in
experimental and unstable, and start experimenting with installing
specific packages from one or both of those sources. Not my ideal
preferred approach, but the alternative is to wait till testing is
released as stable and new packages start to come into the new testing,
and I don't think I wait to wait that long unless I know for a fact the
result is going to make this work.

> I also run llvm-12 from unstable, but really this gpu has been
> running fine almost from the start (more than two years ago), so I
> don't think testing packages are outdated, baring a massive
> regression or bug it should work.

ACK.

>> (There was a time when I tracked sid. That computer wound up in an 
>> inconsistent state, to the point that it wasn't worth fixing and
>> would have needed a full reinstall and possibly a few other things
>> into the bargain. I lived with it until I could build a
>> replacement, then migrated away to track testing and have never
>> considered looking back.)
> 
> I have read such horror stories, and got into some troubles with
> buggy libc6 or systemd migrations over time, but I never reinstalled
> on my desktops/workstation. Booting into a live system and chrooting
> was the most drastic steps I had to take, and no more often than a
> couple of times in years across several computers. Maybe we should
> start a thread and share our "frankensystems" setups to give
> nightmares to developers and professional sysadmins out there? I just
> don't want to be responsible for users copy/pasting verbatim and
> breaking their systems, then blaming Debian for it...

I'm honestly not sure I remember the details of that system well enough
to provide proper nightmares. I like the idea otherwise, though.

To be honest, I tend to just fall back on the standby advice line for
people running sid: "if it breaks, you get to keep the pieces". That
didn't scare me off originally, and I got to live with the result;
anyone who isn't scared off by it probably deserves to live with the
result just as much as I did.

>>> If you want a G.U.I. vulkan test app you can use "goverlay", if
>>> you want vulkan related info displayed in another game/programm
>>> you can try "mangohud".
>> 
>> What 

Re: Buster no release file

[Greg Wooledge]

On Sat, Jul 10, 2021 at 03:28:27PM -0700, kris wrote:
> Long version of error message in activities software.
> Unable to dowmload updates: Failed to update cache: E: the
> repository /cdrom://Debian GNU/ Linux 10.10.0-Buster_-Official amd64 DVD
> Binary-1 2021069-16:12 Buster Release does not have release file.  

Unless you have a specific reason to keep trying to pull packages
from your DVD, you should probably just remove those lines, and replace
them with regular Internet sources.

> I should note i have seperate swap var partitions.

Irrelevant.

> etc/apt/source.list.d is empty. I have attached sources.list
> 

> # 
> 
> # deb cdrom:[Debian GNU/Linux 10.10.0 _Buster_ - Official amd64 DVD Binary-1 
> 20210619-16:12]/ buster contrib main
> 
> deb cdrom:[Debian GNU/Linux 10.10.0 _Buster_ - Official amd64 DVD Binary-1 
> 20210619-16:12]/ buster contrib main
> 
> deb cdrom:[Debian GNU/Linux 10.10.0 _Buster_ - Official amd64 DVD Binary-2 
> 20210619-16:12]/ buster contrib main
> 
> deb http://security.debian.org/debian-security buster/updates main contrib
> deb-src http://security.debian.org/debian-security buster/updates main contrib

You've got an Internet source for the security updates, so if that's
going to work, you should be able to use an Internet source for the
regular packages as well.

Remove all of the cdrom: lines (unless, as I said, you *really* need
to use them for some reason, and have made arrangements for the DVD
to be mounted at need), and replace them with a standard buster source.

I was going to link you to the DebianBuster wiki page where I had put
the standard sources.list for buster, but it appears someone doesn't
want you to have that information.

https://wiki.debian.org/DebianBuster?action=diff=23=22

You can thank the person who goes by the name PaulWise for making your
Debian wiki a less informative and less useful place.

I *REALLY* and truly hate assholes like that.

Re: Failure to use 3840x2160 30hz with Intel 620 chipset

[Felix Miata]

Pierre Couderc composed on 2021-07-10 23:07 (UTC+0200):
 
> see : https://paste.debian.net/1203999/
 
> for( .local/share/xorg/Xorg.0.log)


What does xrandr -q report booted this way?

https://wiki.archlinux.org/title/Backlight may warrant a read.

I have to suspect acpi_backlight=vendor on kernel command line is not taken
well by the 3840x2160 screen.

Whatever caused [ 313.732] (WW) modeset(0): Option "PreferredMode" is not used
I can't tell.

> https://paste.debian.net/plain/1204000

[ 870.193] (EE) modeset(0): failed to set mode: Invalid argument appears 
multiple times quite some lines after these:
[   869.149] (II) modeset(0): Using user preference for initial modes
[   869.149] (II) modeset(0): Output eDP-1 using initial mode 1920x1080 +0+0
[   869.149] (II) modeset(0): Output HDMI-1 using initial mode 3840x2160_30.00 
+0+0

The last line indicates the screens overlap instead of side by side placement. 
It
should end +1920+0 if everything else is OK, which pretty much explains absence 
of
4k screen output.

Have you tried booting with a clean kernel command line, e.g. without
acpi_backlight=vendor in particular?

Likely dmesg and journal need to be explored to find a reason for the invalid
argument errors. Adding drm.debug=0x1e & log_buf_len=1M to kernel command line
may be needed to help diagnosis.

I only had a 4K display for 3 weeks 3 years ago, so it's hard for me to be very
helpful by trying to match behavior, or construct a configuration file free of
errors.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Buster no release file

[kris]

Long version of error message in activities software.
Unable to dowmload updates: Failed to update cache: E: the
repository /cdrom://Debian GNU/ Linux 10.10.0-Buster_-Official amd64 DVD
Binary-1 2021069-16:12 Buster Release does not have release file.  
I should note i have seperate swap var partitions.
etc/apt/source.list.d is empty. I have attached sources.list

# 

# deb cdrom:[Debian GNU/Linux 10.10.0 _Buster_ - Official amd64 DVD Binary-1 
20210619-16:12]/ buster contrib main

deb cdrom:[Debian GNU/Linux 10.10.0 _Buster_ - Official amd64 DVD Binary-1 
20210619-16:12]/ buster contrib main

deb cdrom:[Debian GNU/Linux 10.10.0 _Buster_ - Official amd64 DVD Binary-2 
20210619-16:12]/ buster contrib main

deb http://security.debian.org/debian-security buster/updates main contrib
deb-src http://security.debian.org/debian-security buster/updates main contrib

# buster-updates, previously known as 'volatile'
# A network mirror was not selected during install.  The following entries
# are provided as examples, but you should amend them as appropriate
# for your mirror of choice.
#
# deb http://deb.debian.org/debian/ buster-updates main contrib
# deb-src http://deb.debian.org/debian/ buster-updates main contrib

Re: Need help with ffmpeg installation - strange behaviour of my system - am I correct here?

[Michael Lange]

On Fri, 09 Jul 2021 22:14:23 +0300
Anssi Saari  wrote:

> Joerg Kampmann  writes:
> 
> > Hello group I wanted to install ffmpeg under Debian 9 and got some
> > errormessages (in German): 
> 
> How about errormessages not in German? LANG=en_US.utf8 apt install
> ffmpeg?
> 
> >  ffmpeg : Hängt ab von: libavcodec58 (>= 10:4.1.6) soll aber nicht
> > installiert werden
> 
> https://packages.debian.org/stretch/ffmpeg says ffmpeg in Stretch
> depends on libavcodec57, not 58. Could it be you've configured Debian
> Multimedia repository for Debian 10 for your Debian 9 system?
> 

That's what I thought. Years ago the OP might have added something to the
sources.list like

deb http://ftp.uni-kl.de/debian-multimedia/ stable main

Unfortunately now stable points to buster (debian 10).
Changing this to something like

deb http://www.deb-multimedia.org stretch main

might help.

Regards
Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Actual war is a very messy business.  Very, very messy business.
-- Kirk, "A Taste of Armageddon", stardate 3193.0

Re: apache2-doc update enables disabled conf

[Michael]

On Saturday, July 10, 2021 10:26:03 PM CEST, David Wright wrote:

I can't yet understand what you have done here.


all i did was an apt-get -V dist-upgrade



AIUI a2disconf
removes symlinks in /etc/apache2/conf-enabled/ that were previously
created there by a2enconf.


that's correct



OTOH, apache2-doc.conf is a pkg-provided conffile in
/etc/apache2/conf-available/. During an upgrade, it will be
automatically upgraded if it hasn't been altered. If you've
altered it, then there's usually a dialogue presented about
what to do¹.


afaik this applies only to 'real' config files, like the ones like 
/etc/apache/apache2.conf. apache2 configuration files in /etc/conf-* are 
probably considered different.
i never altered this config file (or any other of those)! why should i? if 
i need this file to be changed, i disable it with a2disconf (or remove the 
symlink in /etc/conf-enabled/ myself), copy the source in 
/etc/apache2/conf-available/ and change the copy. i never touch original 
package files if there is a way to circumvent it.



But in any case, that's nothing to do with
symlinks in /etc/apache2/conf-enabled/.


agreed.


A more specific description of the symptoms might help.


well, here is what '/var/log/apt/term.log' sais:
Log started: 2021-07-09  09:01:44
(Reading database ... ^M(Reading database ... 5%^M(Reading database ... 
10%^M(Reading database ... 15%^M(Reading database ... 20%^M(Reading 
database ... 25%^M(Reading database ... 30%^M(Reading database ... 
35%^M(Reading database ... 40%^M(Reading database ... 45%^M(Reading 
database ... 50%^M(Reading database ... 55%^M(Reading database ... 
60%^M(Reading database ... 65%^M(Reading database ... 70%^M(Reading 
database ... 75%^M(Reading database ... 80%^M(Reading database ... 
85%^M(Reading database ... 90%^M(Reading database ... 95%^M(Reading 
database ... 100%^M(Reading database ... 41615 files and directories 
currently installed.)

Preparing to unpack .../apache2_2.4.38-3+deb10u5_amd64.deb ...
Unpacking apache2 (2.4.38-3+deb10u5) over (2.4.38-3+deb10u4) ...
Preparing to unpack .../apache2-bin_2.4.38-3+deb10u5_amd64.deb ...
Unpacking apache2-bin (2.4.38-3+deb10u5) over (2.4.38-3+deb10u4) ...
Preparing to unpack .../apache2-data_2.4.38-3+deb10u5_all.deb ...
Unpacking apache2-data (2.4.38-3+deb10u5) over (2.4.38-3+deb10u4) ...
Preparing to unpack .../apache2-utils_2.4.38-3+deb10u5_amd64.deb ...
Unpacking apache2-utils (2.4.38-3+deb10u5) over (2.4.38-3+deb10u4) ...
Preparing to unpack .../apache2-doc_2.4.38-3+deb10u5_all.deb ...
Unpacking apache2-doc (2.4.38-3+deb10u5) over (2.4.38-3+deb10u4) ...
Setting up apache2-bin (2.4.38-3+deb10u5) ...
Setting up apache2-doc (2.4.38-3+deb10u5) ...
Package apache2 is not configured yet. Will defer actions by package 
apache2-doc.

Setting up apache2-data (2.4.38-3+deb10u5) ...
Setting up apache2-utils (2.4.38-3+deb10u5) ...
Setting up apache2 (2.4.38-3+deb10u5) ...
info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc
Enabling conf apache2-doc.
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u7) ...
Log ended: 2021-07-09  09:02:06

please recognize the lines that say:

 info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc
 Enabling conf apache2-doc.

this tells me that apt-get enables the configuration file although i 
disabled it on purpose.
fwiw: i think 'configuration files' in apache2 are not the same as the 
configuration files of packages you probably thought of (and are right 
about).


greetings...

Re: Vulkan with Radeon RX 5700 XT

[idiotei...@gmail.com]

Le 10/07/2021 à 17:41, The Wanderer a écrit :

On 2021-07-10 at 07:43, tv.deb...@googlemail.com wrote:


Le 09/07/2021 à 23:44, The Wanderer a écrit :


(Warning, this is fairly long, and the situation involved includes
a fair number of potentially-moving pieces.)


I've recently built a new computer, installed Debian, configured it
to largely match my previous setup, and migrated my data across.

Now, I'm trying to take advantage of one of the hardware
improvements over the system I migrated away from: a newer,
better-performing GPU. In particular, I want to run software which
makes use of the Vulkan API for improved graphics performance.


Hi, Debian unstable with bits of experimental here (because of the
freeze I pull some newer packages from experimental). Same graphic
card (5700XT), mesa drivers (21.1.4 at this precise moment, from
experimental). Here vulkan works afaik.


For comparison, I have mesa-vulkan-drivers 20.3.4-1, from testing.


vulkaninfo reports my card as:
"Group 1:
   Properties:
 physicalDevices: count = 1
 AMD RADV NAVI10 (ACO) (ID: 0)
 subsetAllocation = 0
   Present Capabilities:
 AMD RADV NAVI10 (ACO) (ID: 0):
 Can present images from the following devices: count = 1
 AMD RADV NAVI10 (ACO) (ID: 0)
"


That's excellent news; it means that, at least in principle, this can
work in (relatively-)clean Debian as currently constituted. (It also
confirms that RADV is the relevant thing here; my reading wasn't
conclusive as to whether or not that was specifically something for
older card models.)

Can you indicate exactly which Vulkan-related packages you're running
from experimental? For that matter, a list of Vulkan-related packages
and package versions from unstable too would probably be appropriate,
since I track testing and am *highly* hesitant to upgrade against sid
wholesale.
There you go, some packages are at the same version in Testing and 
Unstable, so you will see them in both.


"aptitude search '?narrow(?installed,?archive(experimental))' | egrep 
'(mesa|vulkan)'


i A libegl-mesa0 - free implementation of the EGL API -- Mesa vendor library
i  libegl-mesa0:i386 - free implementation of the EGL API -- Mesa vendor 
library

i  libegl1-mesa:i386 - transitional dummy package
i A libgl1-mesa-dri - free implementation of the OpenGL API -- DRI modules
i A libgl1-mesa-dri:i386 - free implementation of the OpenGL API -- DRI 
modules

i A libgl1-mesa-glx - transitional dummy package
i A libglapi-mesa - free implementation of the GL API -- shared library
i A libglapi-mesa:i386 - free implementation of the GL API -- shared library
i A libglx-mesa0 - free implementation of the OpenGL API -- GLX vendor 
library
i A libglx-mesa0:i386 - free implementation of the OpenGL API -- GLX 
vendor library

i A libosmesa6 - Mesa Off-screen rendering extension
i A libosmesa6:i386 - Mesa Off-screen rendering extension
i  mesa-opencl-icd - free implementation of the OpenCL API -- ICD runtime
i A mesa-va-drivers - Mesa VA-API video acceleration drivers
i A mesa-vdpau-drivers - Mesa VDPAU video acceleration drivers
i  mesa-vulkan-drivers - Mesa Vulkan graphics drivers
i  mesa-vulkan-drivers:i386 - Mesa Vulkan graphics drivers

aptitude search '?narrow(?installed,?archive(unstable))' | egrep 
'(mesa|vulkan)'

i A libglu1-mesa - Mesa OpenGL utility library (GLU)
i  libglu1-mesa:i386 - Mesa OpenGL utility library (GLU)
i A libglu1-mesa-dev - Mesa OpenGL utility library -- development files
i A libvulkan-dev - Vulkan loader library -- development files
i A libvulkan1 - Vulkan loader library
i A libvulkan1:i386 - Vulkan loader library
i A mesa-utils - Miscellaneous Mesa GL utilities
i  mesa-utils-extra - Miscellaneous Mesa utilies (opengles, egl)
i  vulkan-tools - Miscellaneous Vulkan utilities

aptitude search '?narrow(?installed,?archive(testing))' | egrep 
'(mesa|vulkan)'

i A libglu1-mesa - Mesa OpenGL utility library (GLU)
i  libglu1-mesa:i386 - Mesa OpenGL utility library (GLU)
i A libglu1-mesa-dev - Mesa OpenGL utility library -- development files
i A libvulkan-dev - Vulkan loader library -- development files
i A libvulkan1 - Vulkan loader library
i A libvulkan1:i386 - Vulkan loader library
i A mesa-utils - Miscellaneous Mesa GL utilities
i  mesa-utils-extra - Miscellaneous Mesa utilies (opengles, egl)
i  vulkan-tools - Miscellaneous Vulkan utilities

I also run llvm-12 from unstable, but really this gpu has been running 
fine almost from the start (more than two years ago), so I don't think 
testing packages are outdated, baring a massive regression or bug it 
should work.




(There was a time when I tracked sid. That computer wound up in an
inconsistent state, to the point that it wasn't worth fixing and would
have needed a full reinstall and possibly a few other things into the
bargain. I lived with it until I could build a replacement, then
migrated away to track testing and have never considered looking back.)
I have read such horror stories, 

Re: Failure to use 3840x2160 30hz with Intel 620 chipset

[Pierre Couderc]

On 7/10/21 2:17 AM, Felix Miata wrote:

Pierre Couderc composed on 2021-07-09 09:05 (UTC+0200):  > > >> Yes, EDID is wrong and does not show 3840x2160 warranted by 
Samsung >> for UR59C 32". > > > > With dual displays, setup is more 
complicated, instead of > /etc/X11/xorg.conf.d/50-monitor.conf try 
/etc/X11/xorg.conf with the > following content: > > Section "Device" 
Identifier "UHD620" Driver "modesetting" Option > "monitor-eDP-1" 
"eDPcon" Option "monitor-HDMI-1" "HDMIcon" > EndSection > > Section 
"Monitor" Identifier "HDMIcon" HorizSync 30-135 VertRefresh > 29-31 
Option "PreferredMode" "3840x2160" EndSection > > Section "Monitor" 
Identifier "eDPcon"Section "Monitor" Identifier > "HDMIcon" HorizSync 
30-135 VertRefresh 29-31 ModeLine > "3840x2160_30.00" 339.57 3840 4080 
4496 5152 2160 2161 2164 2197 > -HSync +Vsync Option "PreferredMode" 
"3840x2160_30.00" EndSection > > Section "Monitor" > > Option "Primary" 
"true" EndSection > > Section "Screen" Identifier "extScreen" Device 
"UHD620" Monitor > "HDMIcon" EndSection > > Section "Screen" Identifier 
"intScreen" Device "UHD620" Monitor > "eDPcon" EndSection > > Also, make 
sure your HDMI cable is up to specs for 4K.


The HDMI cable was provided with the Samsung display.

I have tried your solution which starts the 2 displays in  1920x1080

see : https://paste.debian.net/1203999/

for( .local/share/xorg/Xorg.0.log)


Then I have tried  with : (please remind that the 4K display is 
specified 30hz for 3840x2160).


Section "Monitor"
    Identifier  "HDMIcon"
    HorizSync   30-135
    VertRefresh 29-31
    ModeLine "3840x2160_30.00"  339.57  3840 4080 4496 5152 2160 
2161 2164 2197  -HSync +Vsync

    Option  "PreferredMode" "3840x2160_30.00"
EndSection

The result is  : https://paste.debian.net/1204000

It does not strictly crashes but only the first monitor is displayed in 
X mode, the second monitor (HDMI) remains as in non X mode, and the 
mouse does not want to quit the high left corner of the HDMI monitor.


I feel as if  there is some driver problem...

Than you very much, Felix, I progress !

Re: apache2-doc update enables disabled conf

[David Wright]

On Sat 10 Jul 2021 at 11:17:00 (+0200), Michael wrote:
> 
> i disabled apache2-doc.conf in apache2 via a2disconf, but after the
> latest update it was enabled again w/o my consent. at least i got a
> message in the apt-get output.

I can't yet understand what you have done here. AIUI a2disconf
removes symlinks in /etc/apache2/conf-enabled/ that were previously
created there by a2enconf.

OTOH, apache2-doc.conf is a pkg-provided conffile in
/etc/apache2/conf-available/. During an upgrade, it will be
automatically upgraded if it hasn't been altered. If you've
altered it, then there's usually a dialogue presented about
what to do¹. But in any case, that's nothing to do with
symlinks in /etc/apache2/conf-enabled/.

A more specific description of the symptoms might help.

> i do not like my decisions being ingnored since i disabled it for a reason.
> 
> it would be nice if the maintainers would check the configuration
> before modifying one's system w/o asking.

¹ Configuration file `foo/bar'
   ==> Modified (by you or by a script) since installation.
   ==> Package distributor has shipped an updated version.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** bar (Y/I/N/O/D/Z) [default=N] ? 

Cheers,
David.

Re: servidor em notebook e desligamento da tela

[Humberto A. Sousa]

José,

Essas configurações estão normalmente no setup do notebook.
Frequentemente há também a opção de desabilitar o vídeo com uma 
combinação de teclas, daí você desliga e liga quando precisar.




Saudações,



Humberto Araujo de Sousa
humbe...@dontec.com.br
https://mars.nasa.gov/layout/embed/send-your-name/mars2020/certificate/?cn=57592057281

Em 06/07/2021 23:51, José Figueiredo escreveu:

Pessoal, boa noite.

Fiz um servidor, usando Debian 10 em um notebook antigo que tenho - a 
instalação está ultra limpa - apenas a instalação do netinstall com um 
acesso SSH.


A dificuldade está em que a tela fica 100% do tempo ligada, o que é 
inútil pois faço todo acesso remotamente. Gostaria de dicas de como 
desativar a tela - tipo descanso de tela em modo texto.


Não tenho servidor X instalado nessa máquina.

Estou pesquisando há alguns dias e não consegui encontrar uma solução.

Grato.

--
José de Figueiredo
Seja Livre, use GNU/Linux. Use Debian !!!

Antes de autorizar um aborto, pense que poderia ser vc lá dentro,
esperando alguém decidir se vc morre ou não...
http://www.brasilsemaborto.com.br/ 


Venha estudar no IFSul - é público, federal e de qualidade.

Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Brian]

On Sat 10 Jul 2021 at 13:48:12 -0500, Brian Thompson wrote:

> On Sat, 2021-07-10 at 21:18 +0300, Andrei POPESCU wrote:
> >    Testing doesn't have any direct security support
> 
> Is that 100% true?  I was originally referring to

Almost, for most of the time and in normal circumstances.. It depends
on how serious the securuty breach is.

-- 
Brian.

Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Greg Wooledge]

On Sat, Jul 10, 2021 at 01:48:12PM -0500, Brian Thompson wrote:
> Thank you for the detailed response, Andrei.
> 
> On Sat, 2021-07-10 at 21:18 +0300, Andrei POPESCU wrote:
> >    Testing doesn't have any direct security support
> 
> Is that 100% true?  I was originally referring to
> http://security.debian.org/debian-security/dists/testing-security
> when I was talking about "testing security updates".  I understand that most
> mirrors don't contain this suite, but it seems to be working pretty well along
> with the "main" mirror I am using for testing updates (i.e. one that is closer
> in proximity).

Several years ago, a decision was made to offer a repository for security
updates in testing.  Perhaps some packages even appeared there, though I
cannot confirm that.

There have not been any packages there for a *really* long time.  It's
just empty.

Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Brian Thompson]

Thank you for the detailed response, Andrei.

On Sat, 2021-07-10 at 21:18 +0300, Andrei POPESCU wrote:
>    Testing doesn't have any direct security support

Is that 100% true?  I was originally referring to
http://security.debian.org/debian-security/dists/testing-security
when I was talking about "testing security updates".  I understand that most
mirrors don't contain this suite, but it seems to be working pretty well along
with the "main" mirror I am using for testing updates (i.e. one that is closer
in proximity).

Perhaps mixing mirrors is a bad practice, but I haven't run into any issues for
the past week since I started using this apt configuration.

> 
> > I wanted to do the same thing with getting testing security updates into
> > unstable, but I didn't think that was wise (plus it's the other way
> > direction).
> 
> It's unclear to me what exactly you meant with this, but I think I 
> addressed it above anyway.

Yes, you did.  Plus it wouldn't make sense to pull the testing-security suite I
mentioned above into unstable, would it?

-- 
Best regards,

Brian


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

Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Brian]

On Sat 10 Jul 2021 at 14:38:39 -0400, The Wanderer wrote:

> I'm a little surprised to see that you don't even mention the mix which
> I've been running for the last decade-plus: stable + testing, which

Most likely an oversight.

-- 
Brian.

Re: GPS, logiciels libres et Debian

[sebastien . dinot]

Le 2021-07-10 10:36, François LE GAD a écrit :

Le 09/07/2021 à 21:05, sebastien.di...@free.fr a écrit :
j'utilise donc Osmand sur Android (en version payante pour disposer de 
plus de fonds de carte) :


Tu installes le dépôt F-Droid
https://f-droid.org/
et tu y trouveras Osmand~ en version gratuite et non bridée.


Merci pour l'information, le dépôt F-Droid est déjà configuré sur mon 
smartphone et c'est ma source privilégiée d'applications. Je n'utilise 
Google Play que lorsque je ne trouve pas mon bonheur sur F-Droid.


De ce que j'ai compris, ce n'est pas l'application qui est bridée, mais 
le serveur qui donne accès ou non aux couches de données.


En outre, ce qui m'importe, c'est qu'Osmand soit libre. Si pour en vivre 
le développeur a mis en place un modèle économique tel que celui en 
vigueur, je peux jouer le jeu (de mémoire, la licence payante coute une 
dizaine d'euros).


Sébastien

Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[The Wanderer]

On 2021-07-10 at 14:18, Andrei POPESCU wrote:

> On Sb, 10 iul 21, 06:51:43, Brian Thompson wrote:
> 
>> On Sat, 2021-07-10 at 13:43 +0200, tv.deb...@googlemail.com wrote:
>> 
>>> Hi, Debian unstable with bits of experimental here
>> 
>> Is it (usually) wise to intermix different suites?
> 
> It depends :)
> 
> In my opinion I'd say the order from less to more dangerous would
> be:
> 
> 1. stable + select packages from stable-backports

> 2. oldstable + select packages from oldstable-backports-sloppy

> 3. testing + select packages from unstable

> 4. unstable + select packages from experimental

I'm a little surprised to see that you don't even mention the mix which
I've been running for the last decade-plus: stable + testing, which
works out to testing + select packages from stable (the ones which are
no longer available in testing).

Do you consider that to be so dangerous as to not even be worth mentioning?

-- 
   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

Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Andrei POPESCU]

On Sb, 10 iul 21, 06:51:43, Brian Thompson wrote:
> On Sat, 2021-07-10 at 13:43 +0200, tv.deb...@googlemail.com wrote:
> > Hi, Debian unstable with bits of experimental here 
> 
> Is it (usually) wise to intermix different suites?

It depends :)

In my opinion I'd say the order from less to more dangerous would be:

1. stable + select packages from stable-backports

   Generally quite safe, though security support for -backports is on 
   best-effort basis and could be delayed for various reasons.

2. oldstable + select packages from oldstable-backports-sloppy

   Package versions in -backports-sloppy are also from testing, so an 
   upgrade from oldstable to stable is much more likely to run into 
   issues if you start with this mix.
   
   Besides, oldstable only receives security support for one year after 
   the last stable release, to allow sufficient time to prepare the 
   dist-upgrade.

   This mix makes sense e.g. if you intend to keep running a system on 
   oldstable for a very limited time (a few moths or so), that will then 
   be decommissioned, reinstalled etc. instead of dist-upgraded to 
   stable.

3. testing + select packages from unstable

   Testing doesn't have any direct security support, but security fixes 
   should be migrated faster from unstable. Whenever this is not the 
   case (why?), it could make sense to upgrade specific packages.

   Similar considerations for bug fixes, in expectation that the package 
   will eventually migrate to testing.
   
   Be prepared to handle the situation where the package will not 
   migrate as expected (or ever).

4. unstable + select packages from experimental

   Experimental is an incomplete suite (same as -backports), it can only 
   be used on top of something, typically unstable.

   Packages in experimental can be everything from (surprise!) 
   experiments that will never make it to unstable, test packages long 
   forgotten that might not even install properly on any recent Debian, 
   pre-releases of newer upstream versions (yummy!), to release-quality 
   packages that are uploaded there instead of unstable during the 
   freeze (as per Release Team's policy).


The -backports (-sloppy probably as well) and experimental archives are 
treated specially by APT, no additional configuration should be 
necessary for the typical use case mentioned above.

For combination 3. you probably want to use a setup similar with 
-backports for security upgrades and something similar to experimental 
for bug fixes.

Understanding of APT pinning is a good prerequisite for such a setup, 
which is why I'm intentionally vague. ;)

Of course, one way to learn is by actually trying it and breaking stuff 
(as most of us probably did). At a minimum you should avoid doing this 
in "production" (whatever that means for you).

> I guess it wouldn't matter
> that much for bits and pieces of experimental in unstable since you are 
> already
> in agreeance with having an unstable system to begin with.

Experimental can be way more dangerous than unstable, see above. Most 
(but not all!) packages in unstable are meant to eventually migrate to 
testing and then become part of the next stable release.

> I wanted to do the same thing with getting testing security updates into
> unstable, but I didn't think that was wise (plus it's the other way 
> direction).

It's unclear to me what exactly you meant with this, but I think I 
addressed it above anyway.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Vulkan with Radeon RX 5700 XT

[The Wanderer]

On 2021-07-10 at 11:14, Alexander V. Makartsev wrote:

> On 10.07.2021 02:44, The Wanderer wrote:
> 
>> Does anyone have experience with using Vulkan with AMD graphics on 
>> vaguely current Debian, using an even vaguely recent GPU? (Where 
>> "vaguely current Debian" means Debian testing more recently than
>> the release of current stable, and a "vaguely recent GPU" means
>> something new enough that disabling the support for it in the
>> legacy radeon driver isn't necessary, because that driver doesn't
>> support it to begin with.)
>> 
>> Any suggestions for ways to pursue getting this working, that
>> don't involve hybridizing or Frankensteining or otherwise messing
>> up my installed system?
> 
> While being a "nvidia-guy" myself (long before ATI was bought by
> AMD), out of curiosity, I've asked myself "what would I do" and
> looked into AMD driver support in Debian.

I used to run NVIDIA - back in the days when G80-based cards were the
top of the architectural line. (A brother of mine, who does gaming on a
more regular basis and is at least as Linux-centric as I am, runs NVIDIA
to this day.)

I had enough times when I couldn't launch X (at least not with any
acceleration at all, even 2D acceleration) because an updated NVIDIA
driver which was compatible with the new X or kernel version hadn't been
released yet, and enough troubles trying to switch drivers etc. and
remnants left over on the computer afterwards, that it left me with an
antipathy towards using NVIDIA products.

The fact that NVIDIA's Linux support implementation is proprietary is
both the reason for those problems, and an entirely separate reason why
I decided that until that fact changes, I will never voluntarily buy an
NVIDIA card for a Linux system.

> And to my surprise, I didn't found a simple way like "amd-driver" 
> meta-package to install, as opposed to "nvidia-driver" package for 
> nvidia-based VGAs.

As I understand matters, this is another consequence of the fact that
the NVIDIA driver (stack) is proprietary - or rather, the only reason
why there's an nvidia-driver package is because it's not practical (or
necessarily even possible) to provide that functionality in a more
integrated way, because of the proprietary and opaque way the NVIDIA
drivers etc. are provided. In an ideal world, no such explicit separate
package(s) would be needed.

> So, if I were you, I would bite the bullet and use latest official 
> driver [1] provided by AMD, simply because there are no other
> options. Upon further examination "*.deb" packages they provide will
> be installed into paths with "*/opt/*" and because of that, they
> won't overwrite any Debian-native files, so there is little to none
> possibility to create "franken-debian" by installing them. And since
> they are packaged into ".deb" files you can always cleanly uninstall
> them.

I'll take this under advisement; at the very least, it's my fallback if
other investigations don't produce any usable results. The examination
of those packages and the results they provide is appreciated.

> The only thing I would do prior to driver installation is to enable
> i386 architecture support [2] on my system, if it wasn't enabled
> already:
>  # dpkg --add-architecture i386

I take this as such an obvious and necessary thing to do, during system
installation and setup, that it doesn't even occur to me to mention
having done it.

> I wonder why a convenient "amd-driver" meta-package wasn't created
> yet...

For one thing: because no one has found it worth the trouble to create
and undertake to maintain one.

For another - what would you suggest such a package do, and/or depend
on? Beyond maybe xserver-xorg-video-{amdgpu,ati,radeon} and
firmware-amd-graphics, I'm not sure what would be appropriate to pull
in, and at least some of that is going to be pulled in automatically
during installation of the OS anyway.

I certainly wouldn't mind having such a package exist, but I probably
wouldn't really use it, at the very least because
xserver-xorg-video-{ati,radeon} are not necessary for AMDGPU
functionality and I see no reason to keep them around taking up space.

-- 
   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

Re: Vulkan with Radeon RX 5700 XT

[The Wanderer]

On 2021-07-10 at 07:43, tv.deb...@googlemail.com wrote:

> Le 09/07/2021 à 23:44, The Wanderer a écrit :
> 
>> (Warning, this is fairly long, and the situation involved includes
>> a fair number of potentially-moving pieces.)
>> 
>> 
>> I've recently built a new computer, installed Debian, configured it
>> to largely match my previous setup, and migrated my data across.
>> 
>> Now, I'm trying to take advantage of one of the hardware
>> improvements over the system I migrated away from: a newer,
>> better-performing GPU. In particular, I want to run software which
>> makes use of the Vulkan API for improved graphics performance.
> 
> Hi, Debian unstable with bits of experimental here (because of the 
> freeze I pull some newer packages from experimental). Same graphic
> card (5700XT), mesa drivers (21.1.4 at this precise moment, from 
> experimental). Here vulkan works afaik.

For comparison, I have mesa-vulkan-drivers 20.3.4-1, from testing.

> vulkaninfo reports my card as:
> "Group 1:
>   Properties:
> physicalDevices: count = 1
> AMD RADV NAVI10 (ACO) (ID: 0)
> subsetAllocation = 0
>   Present Capabilities:
> AMD RADV NAVI10 (ACO) (ID: 0):
> Can present images from the following devices: count = 1
> AMD RADV NAVI10 (ACO) (ID: 0)
> "

That's excellent news; it means that, at least in principle, this can
work in (relatively-)clean Debian as currently constituted. (It also
confirms that RADV is the relevant thing here; my reading wasn't
conclusive as to whether or not that was specifically something for
older card models.)

Can you indicate exactly which Vulkan-related packages you're running
from experimental? For that matter, a list of Vulkan-related packages
and package versions from unstable too would probably be appropriate,
since I track testing and am *highly* hesitant to upgrade against sid
wholesale.

(There was a time when I tracked sid. That computer wound up in an
inconsistent state, to the point that it wasn't worth fixing and would
have needed a full reinstall and possibly a few other things into the
bargain. I lived with it until I could build a replacement, then
migrated away to track testing and have never considered looking back.)

> If you want a G.U.I. vulkan test app you can use "goverlay", if you
> want vulkan related info displayed in another game/programm you can
> try "mangohud".

What exactly would you recommend as a Vulkan-functionality testing
procedure with goverlay? The program launches without issues both with
and without the explicit specifying of VK_ICD_FILENAMES, but doesn't
seem to show anything indicating what graphics adapters it's using or
seeing. I don't know it or its usage well enough to judge what needs to
be done from its interface in order to test (and while I could go
digging or do trial-and-error, that's not my focus right now), and its
man page says exactly the same thing as the package description, which
isn't useful for figuring out how to run or use the program.

(I just tested mangohud with glxgears, and bizarrely enough, it appears
to reduce FPS in that demo by a factor of about 3.5 - from about 30K to
about 8.5K. Not sure if that's got to do with the fact that Vulkan isn't
working correctly on my system or not, even though glxgears is using
OpenGL.)

> For wine you probably want to install i386 (32bits) vulkan libraries
> too alongside the amd64 ones.

I am very familiar with multiarch considerations, especially for Wine.
Enabling i386 was one of the first steps I took in the software-side
build of my current machine, and I've been careful to check i386 package
versions in examining my Vulkan setup.

> Here my sons (with the same setup, radeon 5700XT and Vega56 cards)
> use the Steam "Proton" implementation of wine happily, vulkan games
> run fine. Linux native games run in vulkan mode too.
> 
> I have given up on trying to get anything to run with plain wine
> years ago, so can't help with this, but Steam "Proton" version or 
> "GloriousEggroll" (yes it's a real thing) run almost any Windows
> games my kids throw at it, in vulkan mode when available, sometime
> much better than native Linux versions (sadly).

I'm not likely to use Proton, because I have a bias against Steam; I
think it traces back in part to early-days "anything which wants you to
install it in a way that bypasses the system's package-management system
is bad" (though that's also a concern that could apply to Lutris), and
in part to an adamant stance in opposition to DRM. (And yes, unless
Steam isn't required for a given game - meaning, unless you can download
and install and run the game without needing Steam installed at any
point in the process - then Steam is DRM. Lutris, being just a
convenience method for gaining access to the installer and providing the
correct install-time and run-time environment configurations, doesn't
have that problem.)

I think I've vaguely heard of GloriousEggroll, but nothing beyond that.

Re: Donaciones y despedida de Debian

[Marcelo Eduardo Giordano]

Gracias amigo.

Seguimos en contacto

On 8/7/21 14:06, Raimundo Baravaglio wrote:

Ese link es una de las maneras de donación.
Aquí están todas las opciones: https://www.debian.org/donations 



Saludos y éxitos en la incursión sobre Arch Linux !  ;)


Raimundo Baravaglio



El jue, 8 jul 2021 a las 12:38, Marcelo Eduardo Giordano 
(mailto:contadorgiord...@gmail.com>>) 
escribió:


Amigos.

Le comento que he decido instalar Arch linux en mi PC principal,
aunque seguiré con Debian en otra computadora de mi oficina.

Quedo muy agradecido de Debian con el cual empecé en el mundo del
open source, pero hoy quiero investigar otras cosas, quizás mas
profundas y deseo mucho estar a la última, con los costes que esto
trae.

Por eso quiero hacer una donación y tengo entendido que se puede
hacer en esta página. Quisiera que me corrijan si me equivoco para
ayudar a este hermoso proyecto.

https://www.spi-inc.org/donations/


Seguiré en contacto con ustedes y siempre estaré agradecido de la
ayuda que siempre me han dado.

-- 


Marcelo E. Giordano
//

Re: Vulkan with Radeon RX 5700 XT

[Alexander V. Makartsev]

On 10.07.2021 02:44, The Wanderer wrote:

Does anyone have experience with using Vulkan with AMD graphics on
vaguely current Debian, using an even vaguely recent GPU? (Where
"vaguely current Debian" means Debian testing more recently than the
release of current stable, and a "vaguely recent GPU" means something
new enough that disabling the support for it in the legacy radeon driver
isn't necessary, because that driver doesn't support it to begin with.)

Any suggestions for ways to pursue getting this working, that don't
involve hybridizing or Frankensteining or otherwise messing up my
installed system?
While being a "nvidia-guy" myself (long before ATI was bought by AMD), 
out of curiosity, I've asked myself "what would I do" and looked into 
AMD driver support in Debian.
And to my surprise, I didn't found a simple way like "amd-driver" 
meta-package to install, as opposed to "nvidia-driver" package for 
nvidia-based VGAs.
So, if I were you, I would bite the bullet and use latest official 
driver [1] provided by AMD, simply because there are no other options.
Upon further examination "*.deb" packages they provide will be installed 
into paths with "*/opt/*" and because of that, they won't overwrite any 
Debian-native files, so there is little to none possibility to create 
"franken-debian" by installing them. And since they are packaged into 
".deb" files you can always cleanly uninstall them.
The only thing I would do prior to driver installation is to enable i386 
architecture support [2] on my system, if it wasn't enabled already:

    # dpkg --add-architecture i386

I wonder why a convenient "amd-driver" meta-package wasn't created yet...


[1] 
https://www.amd.com/en/support/graphics/amd-radeon-5700-series/amd-radeon-rx-5700-series/amd-radeon-rx-5700-xt

[2] https://wiki.debian.org/Multiarch/HOWTO

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT)

[Eike Lantzsch ZP6CGE]

On Samstag, 10. Juli 2021 09:13:57 -04 Brian Thompson wrote:
> On Sat, 2021-07-10 at 14:57 +0200, tv.deb...@googlemail.com wrote:
> > This is not the point of the OP message, so let's not derail
>
> I apologize for accidentally derailing.  I should have started a new
> thread. I'm still relatively new to the Debian community.

No problem - AMTRAK always derails and still runs. If it is a matter of
tracks or a matter of running stock or a matter of cars or trucks
passing level passings with lights flashing is a moot question.
People here on debian-user use to derail all the time.
q.e.d.
Eike

--
Eike Lantzsch ZP6CGE

Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT)

[tv.deb...@googlemail.com]

Le 10/07/2021 à 15:13, Brian Thompson a écrit :

On Sat, 2021-07-10 at 14:57 +0200, tv.deb...@googlemail.com wrote:


This is not the point of the OP message, so let's not derail


I apologize for accidentally derailing.  I should have started a new thread.
I'm still relatively new to the Debian community.

Don't worry, I am not from the list police! Lately I think a good 2/3 of 
all thread ended up really far the original subject, sometimes with 
complete disregard for the original person and his/her need for 
assistance. Maybe it's fun & free, maybe it's abusive and disrespectful, 
depends on your culture and standards I guess.


So, back to Vulkan, let's help The Wanderer get its setup up and running.

Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT)

[Brian Thompson]

On Sat, 2021-07-10 at 14:57 +0200, tv.deb...@googlemail.com wrote:
> 
> This is not the point of the OP message, so let's not derail

I apologize for accidentally derailing.  I should have started a new thread. 
I'm still relatively new to the Debian community.
-- 
Best regards,

Brian


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

Re: Vulkan with Radeon RX 5700 XT

[tv.deb...@googlemail.com]

Le 10/07/2021 à 13:51, Brian Thompson a écrit :

On Sat, 2021-07-10 at 13:43 +0200, tv.deb...@googlemail.com wrote:

Hi, Debian unstable with bits of experimental here


Is it (usually) wise to intermix different suites?  I guess it wouldn't matter
that much for bits and pieces of experimental in unstable since you are already
in agreeance with having an unstable system to begin with.

I wanted to do the same thing with getting testing security updates into
unstable, but I didn't think that was wise (plus it's the other way direction).

 This is not the point of the OP message, so let's not derail, I 
mention it because packages versions could be relevant to the OP 
problems. There are plenty of threads and post around to tell you not to 
do that, and they are right. I am "mixing" since Debian 4, all my 
stations are "hybrids" of some sorts, sometimes it breaks, I fix it. I 
don't recommend or advocate it, but I do it without much problem and for 
new hardware it is often mandatory, unless you'd rather switch to 
another distribution.


Me on Debian "melting pot", free to walk the wire. Who needs a big 
corporation to botch updates and ruin your system when you can do it 
yourself? ;-)

Re: Vulkan with Radeon RX 5700 XT

[Brian Thompson]

On Sat, 2021-07-10 at 13:43 +0200, tv.deb...@googlemail.com wrote:
> Hi, Debian unstable with bits of experimental here 

Is it (usually) wise to intermix different suites?  I guess it wouldn't matter
that much for bits and pieces of experimental in unstable since you are already
in agreeance with having an unstable system to begin with.

I wanted to do the same thing with getting testing security updates into
unstable, but I didn't think that was wise (plus it's the other way direction).
-- 
Best regards,

Brian


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

Re: Vulkan with Radeon RX 5700 XT

[tv.deb...@googlemail.com]

Le 09/07/2021 à 23:44, The Wanderer a écrit :

(Warning, this is fairly long, and the situation involved includes a
fair number of potentially-moving pieces.)


I've recently built a new computer, installed Debian, configured it to
largely match my previous setup, and migrated my data across.

Now, I'm trying to take advantage of one of the hardware improvements
over the system I migrated away from: a newer, better-performing GPU. In
particular, I want to run software which makes use of the Vulkan API for
improved graphics performance.



Hi, Debian unstable with bits of experimental here (because of the 
freeze I pull some newer packages from experimental). Same graphic card 
(5700XT), mesa drivers (21.1.4 at this precise moment, from 
experimental). Here vulkan works afaik.


vulkaninfo reports my card as:
"Group 1:
 Properties:
   physicalDevices: count = 1
   AMD RADV NAVI10 (ACO) (ID: 0)
   subsetAllocation = 0
 Present Capabilities:
   AMD RADV NAVI10 (ACO) (ID: 0):
   Can present images from the following devices: count = 1
   AMD RADV NAVI10 (ACO) (ID: 0)
"

If you want a G.U.I. vulkan test app you can use "goverlay", if you want 
vulkan related info displayed in another game/programm you can try 
"mangohud".


For wine you probably want to install i386 (32bits) vulkan libraries too 
alongside the amd64 ones.


Here my sons (with the same setup, radeon 5700XT and Vega56 cards) use 
the Steam "Proton" implementation of wine happily, vulkan games run 
fine. Linux native games run in vulkan mode too.


I have given up on trying to get anything to run with plain wine years 
ago, so can't help with this, but Steam "Proton" version or 
"GloriousEggroll" (yes it's a real thing) run almost any Windows games 
my kids throw at it, in vulkan mode when available, sometime much better 
than native Linux versions (sadly).


If I can help narrow down what package or version is causing you 
trouble, I'll do.


All the best.

Re: How do I get back the GRUB menu with the blue background?

[Stella Ashburne]

Attention: David

Hello,

I wish to add some info that might be of interest to you:

grub> ls (hd0,gpt1)/
efi/

Note: (hd0,gpt1) contains ESP (EFI System Partition)

grub> ls (hd0,gpt2)/
lost+found/ efi/ config-4.19.0.17-amd64 vmlinuz-4.19.0.17-amd64 grub/ 
System.map-4.19.0.17-amd64 initrd.img-4.19.0.17-amd64

Note: (hd0,gpt2) is the /boot partition

The version of the kernel in Debian Testing is 5.10.0-7-amd64 whereas that of 
Debian Buster is 4.19.0.17-amd64.

I'm surprised that even though installation of Debian Testing was successful, 
the version of config-, vmlinuz- System.map and initrd.img- in grub is of the 
older Debian Buster.

Do you think the problem of the missing GRUB menu can be fixed if the older 
version of config-, vmlinuz- System.map and initrd.img- can replaced with those 
of Debian Testing? What do you think?

Best regards

Re: MTA (DMARC)

[Reco]

Hi.

On Sat, Jul 10, 2021 at 05:49:44AM -0400, Polyna-Maude Racicot-Summerside wrote:
> >> Here what I got from the Debian mailing list server
> >> Got some idea ?
> > 
> > Your MTA signs these headers:
> > 
> > Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Cc:References:To:From:Subject:Sender:Reply-To:
> > 
> > Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
> > 
> > Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
> > 
> > List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
> > 
> > Of those at least these headers are modified by the list software:
> > 
> > 
> > Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
> > 
> > List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
> > 
> > Thus DKIM checks of your e-mails are bound to fail.
> > 
> I am currently using the email provided by my shared hosting.

That only means that the current setup of that MTA is unsuitable for the
list.
If you do not control it so you cannot change it - that can only mean
three things:

1) You'll continue to receive DMARC reports each time you send a e-mail
to the list, and they will show failed DKIM checks.

2) Your e-mails that are resent by bendel.d.o will fail DKIM checks, so
you have no guarantees that your e-mails will be received by all
subscribers of this list.

3) And last, but not least - it's up to the receiver MTA do decide what
to do with such broken e-mails - mark them as spam, deny receiving them,
or deliver to the intended addressee.


> For me it's somewhat complex to manage the setup of a email server,

These things require some learning indeed.


> even if I do also rent a bare metal server in a data center.

Whenever an MTA is running on a bare metal, some sort of virtualized
environment or even in a container is hardly relevant.

Reco

Re: DMARC

[Reco]

On Sat, Jul 10, 2021 at 05:45:08AM -0400, Polyna-Maude Racicot-Summerside wrote:
> > On Sat, Jul 10, 2021 at 12:20:24AM -0400, Polyna-Maude Racicot-Summerside 
> > wrote:
> >> I receive the following regarding messages sent on the mailing list...
> > 
> > A usual dmarc report, and you receive that because your domain has DMARC
> > policy set that way - it's a TXT record _dmarc.polynamaude.com.
> > 
> > BTW - why have you set "p=none" there?
> > 
> I'll go read in my note but from memory I don't remember what does
> p=none do.

Basically you agree that each and every MTA on the Internet can send an
e-mail from @polynamaude.com, and it does not have to be *your* e-mail.
With p=none you might as well remove your SPF. p=quarantine, on the
other hand, at least does something positive.


> > 2) The fact that your DKIM policy is unnecessary strict, because your
> > mails to this list routinely fail to verify DKIM.
> > 
> What you mean unnecessary strict ?

MTA that you're using signs these headers:

> Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Cc:References:To:From:Subject:Sender:Reply-To:
> Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
> 
> Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
> 
> List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;

Of those at least these headers are modified by the list software:

> 
> Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
> 
> List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;

Thus each and every e-mail you'll send to this list will fail DKIM
check. Also see my reply in your other thread.


> > 3) The fact that your SPF policy is failing, probably because your SPF
> > does not designate bendel.d.o as a permitted sender on your behalf.
> > 
> Oh, I could simply add bendel.d.o and it would work ?

Not immediately. Your SOA record has TTL of 1 hour, so changing your DNS
records (second-level domain, misconfigured DNS taken into the account)
can take 2 hours at worst to be reflected for everyone.

Reco

Re: How do I get back the GRUB menu with the blue background?

[Stella Ashburne]

Hello David

I didn't expect a rather lengthy reply from you.

> Sent: Tuesday, July 06, 2021 at 9:29 AM
> From: "David" 
> To: "debian-user mailing list" 
> Subject: Re: How do I get back the GRUB menu with the blue background?
>
>
> grub> echo "$prefix"
>
The reply is (hd0,gpt1)/boot/grub

>
> 6) Perhaps something else is broken, but attempting
> to boot from the grub> prompt will help to diagnose that.
> That is certain, and straightforward. I have given you
> the steps to try, but you have not yet reported trying it.
>
Frankly, I don't know the exact commands to type to boot from the grub> prompt.

> 7) Inside grub, the 'prefix' variable defines where
> grub finds its own code. That appears to be correct,
> otherwise you would see grub_rescue> prompt.
>
What command can I type at the grub> prompt to look inside grub so as to see 
the "prefix" variable?

>
> 9) I suppose you can use a rescue environment and
> chroot to boot your system, but it seems unnecessary
> unless you can't boot any other way. But if you have a
> broken initrd, you will need to do this.
>
How can I tell if I've a broken initrd?

> 10) Once booted, you will need to 'grub-install' to fix
> the problem of grub.cfg not being found. Because grub
> currently can't find any grub.cfg, you need to make sure
> that the new one is installed to the correct location, which
> needs to be outside your encrypted partition.

Thanks for the mini-tutorial.

> I would not
> be surprised if the /boot in your new installation is not the
> same as your boot partition, you should check that.
> Check your mountpoints. Does 'lsblk -f' show the boot
> partition is mounted at /boot?
>
After typing lsblk -f at the grub> prompt, the error message was can't find 
command 'lsblk'

> Run 'grub-install -v '
> and look for output like:
>   grub-install: info: setting the root device to 
>
After typing grub-install -v (hd0,gpt2), the error message was can't find 
command 'grub-install'

> Make sure  is your unencrypted boot partition.
> If it isn't, run 'grub-install' again with the '--boot-directory' option
> pointing to your boot partition.
> Read 'man grub-install' for documentation of its options.
>
(hd0,gpt2) is my un-encrypted boot partition

> a) Can you boot from grub> prompt?
>
No

> b) At grub>, can you check the value of $root to discover
> where it is looking for grub.cfg? grub> echo "$root"
>
hd0,gpt1

> c) At grub>, can you find grub.cfg anywhere by the
> tab-completion method I described in a prior message?
> Where?

At the grub> prompt, I typed gr and pressed the TAB key. There was no output or 
suggestions.

>
> d) After booting somehow, if you run 'grub-install -v', what
> root device does it use to to save the files that it updates,
> as explained above?

I'm unable to boot (frankly what commands to type to boot at the grub> prompt ?)

>
> e) If you reboot after running 'grub-install', does it work?
>
Unable to answer your question (e) because of (d)

> f) Is the value of '$root' above the same location that
> 'grub-install' writes to by default? If not, use its
> '--boot-directory' option.
>
Unable to answer your question (f) because of (d)

Re: MTA (DMARC)

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-10 3:46 a.m., Reco wrote:
>   Hi.
> 
> On Fri, Jul 09, 2021 at 04:24:42PM -0400, Polyna-Maude Racicot-Summerside 
> wrote:
>> Hi,
>> I've wrote a message regarding my MTA.
>>
>> I was thinking it's corrected but...
>>
>> Here what I got from the Debian mailing list server
>> Got some idea ?
> 
> Your MTA signs these headers:
> 
> Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Cc:References:To:From:Subject:Sender:Reply-To:
> Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
> 
> Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
> 
> List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
> 
> Of those at least these headers are modified by the list software:
> 
> 
> Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
> 
> List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
> 
> Thus DKIM checks of your e-mails are bound to fail.
> 
I am currently using the email provided by my shared hosting.
For me it's somewhat complex to manage the setup of a email server, even
if I do also rent a bare metal server in a data center.

The installation of software itself is not the problem but I'm worried
it would expose my system to more risk.

I'd need to play a deployment carefully.
> 
> I use this set of headers to sign for this list:
> 
> In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date:Sender:Cc:Content-Transfer-Encoding:Content-ID:Content-Description:User-Agent
> 
> It contains everything that's valuable in headers of my e-mails, and my
> e-mails to this list usually pass DKIM checks.
> 
I don't know if I can modify those header myself, I'd need to do some
research on what part of the header is set by my client and which part
is done by the server provided to me by Namecheap
> Reco
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: DMARC

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-10 3:25 a.m., Reco wrote:
>   Hi.
> 
> On Sat, Jul 10, 2021 at 12:20:24AM -0400, Polyna-Maude Racicot-Summerside 
> wrote:
>> I receive the following regarding messages sent on the mailing list...
> 
> A usual dmarc report, and you receive that because your domain has DMARC
> policy set that way - it's a TXT record _dmarc.polynamaude.com.
> 
> BTW - why have you set "p=none" there?
> 
I'll go read in my note but from memory I don't remember what does
p=none do.
> 
>> Someone understand something ?
> 
> Sure. Every time you send the e-mail to the list, multiple MTAs resent
> your e-mail to whom they deem appropriate.
> The idea of DMARC is to show you, the domain owner, how the world
> perceives e-mails sent on your behalf (or not, considering the spammers).
> 
> This particular dmarc report comes from the FastMail, and it shows,
> along with the other things:
> 
> 1) That your e-mails go through bendel.debian.org, the MTA behind this
> very list (and other Debian lists). There are others MTA there, but
> bendel.d.o is the most important.
> 
> 2) The fact that your DKIM policy is unnecessary strict, because your
> mails to this list routinely fail to verify DKIM.
> 
What you mean unnecessary strict ?
> 3) The fact that your SPF policy is failing, probably because your SPF
> does not designate bendel.d.o as a permitted sender on your behalf.
> 
Oh, I could simply add bendel.d.o and it would work ?
> Also, consider installing dmarc-cat package, it really useful in
> interpreting those DMARC reports, as it shows DMARC report as a
> human-readable text, not XML.
> 
I'll install dmarc-cat and see what it gives out. Probably I'm missing
some stuff.
> Reco
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

apache2-doc update enables disabled conf

[Michael]

hey,

i disabled apache2-doc.conf in apache2 via a2disconf, but after the latest 
update it was enabled again w/o my consent. at least i got a message in the 
apt-get output.


i do not like my decisions being ingnored since i disabled it for a reason.

it would be nice if the maintainers would check the configuration before 
modifying one's system w/o asking.


greetings...

Re: How do I get back the GRUB menu with the blue background?

[Stella Ashburne]

Hi David

> Sent: Monday, July 05, 2021 at 4:52 AM
> From: "David Wright" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I get back the GRUB menu with the blue background?
>
> 
> I find the Grub installation prompts in the d-i very confusing.
> I'm wondering whether your process incorrectly updated grub.cfg
> in the ESP on the SSD.
> 

I suspected it too because when I installed Debian Testing, I didn't delete 
both the ESP and /boot partitions that were created by Debian Buster. As a 
result, after installing Debian Testing successfully and rebooting my machine, 
there was no blue GRUB menu.

> Bear in mind there are two grub.cfg files.

Where are their locations?

> The
> second one is the familiar one, so I just give the head:
> 
> # cat /boot/efi/EFI/debian/grub.cfg

When I issued the above command at the grub> prompt, the response was 'file 
/boot/efi/EFI/debian/grub.cfg' not found.

> (I only encrypt /Home and swap.) I'm wondering whether your first
> grub.cfg is pointing to the USB stick that you used in the
> installation. That would be simple to check.

No. If you're using UEFI and the partition table scheme is gpt, Debian 10's 
installer detects that your SSD is using EFI, there's a message on the screen 
that asks "Force EFI installation to a removable media? Yes or No". My response 
is always "No".

> 
> If this guess, is correct, it might be possible to confirm it
> if you get these symptoms:
> 
> . Booting with the internal drive only: GRUB> prompt.
> . Booting with the USB stick inserted: something else appears,
>   a blue Grub menu, or a Debian installer splash screen,
>   or even Windows.

I did what you suggested by first inserting the USB stick that contains Debian 
10's installer and booting up my machine. There's no blue GRUB menu, 
whatsoever

> 
> Of course, the second scenario can only work if the USB's UUID
> hasn't been recreated by further uses.

Yes, I'm aware of that fact
> 
> ¹ With encrypted systems, you have to bear in mind what can be seen
>   outside and inside the container. This is easy to distinguish
>   with only /home encrypted, as you can inspect things with the
>   normal system tools.

My LUKS-encrypted partition consists of / and swap area. I assume the / 
contains /home, /var, /usr, etc...

Best wishes.

Re: GPS, logiciels libres et Debian

[François LE GAD]

Le 09/07/2021 à 12:29, kaliderus a écrit :

J'envisage l'achat d'un GPS (voiture/moto/bateau donc étanche).
Avez-vous des recommandations, tuyaux, marques à conseiller ou éviter,
et qui idéalement me permettraient de faire des mise à jour des cartes
sous Debian ?


Si ton GPS accepte les cartes d'extension, tu peux utiliser les cartes 
OSM. Il suffit d'y créer un répertoire GARMIN et d'y copier la carte. Tu 
vas ensuite dans les paramètres pour désactiver la carte d'origine et 
activer la carte OSM.


C'est valable uniquement pour la route. Il y a bien des cartes marines 
OSM, mais j'ignore leur fiabilité et toutes les zones ne sont pas couvertes.


--
François

Re: GPS, logiciels libres et Debian

[François LE GAD]

Le 09/07/2021 à 21:05, sebastien.di...@free.fr a écrit :
j'utilise donc Osmand sur Android (en version payante pour disposer de 
plus de fonds de carte) :


Tu installes le dépôt F-Droid
https://f-droid.org/
et tu y trouveras Osmand~ en version gratuite et non bridée.

--
François

Re: GPS, logiciels libres et Debian

[didier . gaumet]

Oui, j'ai parlé de Gnome Maps sans trop approfondir (ce en quoi j'ai eu
tort) et je viens de vérifier: la connexion réseau est obligatoire. En
plus je n'ai pas l'impression qu'il ya it de quidage vocal ou de vue
3D, ce qui est un peu pénalisant en GPS routier...

Re: MTA (DMARC)

[Reco]

Hi.

On Fri, Jul 09, 2021 at 04:24:42PM -0400, Polyna-Maude Racicot-Summerside wrote:
> Hi,
> I've wrote a message regarding my MTA.
> 
> I was thinking it's corrected but...
> 
> Here what I got from the Debian mailing list server
> Got some idea ?

Your MTA signs these headers:

Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Cc:References:To:From:Subject:Sender:Reply-To:
Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:

List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;

Of those at least these headers are modified by the list software:

Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:

List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;

Thus DKIM checks of your e-mails are bound to fail.


I use this set of headers to sign for this list:

In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date:Sender:Cc:Content-Transfer-Encoding:Content-ID:Content-Description:User-Agent

It contains everything that's valuable in headers of my e-mails, and my
e-mails to this list usually pass DKIM checks.

Reco

Re: test

[tomas]

On Fri, Jul 09, 2021 at 06:28:21PM -0400, Polyna-Maude R.-Summerside wrote:
> 
> -- 
> Polyna-Maude R.-Summerside
> https://www.polynamaude.com/
> 
> -Be smart, Be wise, Support opensource development
> 
> *Mise en garde concernant la confidentialité*
> 
> La présente communication est confidentielle et transmise sous le sceau du
> secret professionnel.

Oh, là là...

:-)

bon week-end
 - t


signature.asc
Description: Digital signature

Re: MTA (DMARC)

[tomas]

On Fri, Jul 09, 2021 at 11:43:56PM +0300, Kevin N. wrote:
> Not sure if that is the case here, but sometimes mailing list
> software alters the original message headers which then can lead to
> failed DKIM signature checks.

Most probably. This is a known problem. DKIM is (roughly speaking) a
signature over a hash over some of the mail headers. It assumes that
whoever has control over the sender's domain name in DNS can authorize
the sender to send mails[1], because DNS is where the public key for
the check is published.

Now a mailing list has to munge some of the mail headers, thus breaking
the signature. Here[2] is a readable explanation. There's even an
RFC6377[3] for that.

No idea how lists.debian.org handles that.

Cheers

[1] The result is that now a significant fraction of the spam I receive
   has a correct DKIM signature: they use throwaway Google or Hotmail
   accounts. The irony is that those Big Guys are the ones who forced
   us all to implement DKIM to "fight spam", because they'd refuse any
   mail without (now Hotmail and the other Microsoft-fueled providers
   have discovered something even better). Dirty bros. I *hate* them.

[2] https://doc.coker.com.au/internet/dkim-and-mailing-lists/

[3] RFC6377 "DomainKeys Identified Mail (DKIM) and Mailing Lists"
https://datatracker.ietf.org/doc/html/rfc6377

 - t


signature.asc
Description: Digital signature

Re: DMARC

[Reco]

Hi.

On Sat, Jul 10, 2021 at 12:20:24AM -0400, Polyna-Maude Racicot-Summerside wrote:
> I receive the following regarding messages sent on the mailing list...

A usual dmarc report, and you receive that because your domain has DMARC
policy set that way - it's a TXT record _dmarc.polynamaude.com.

BTW - why have you set "p=none" there?


> Someone understand something ?

Sure. Every time you send the e-mail to the list, multiple MTAs resent
your e-mail to whom they deem appropriate.
The idea of DMARC is to show you, the domain owner, how the world
perceives e-mails sent on your behalf (or not, considering the spammers).

This particular dmarc report comes from the FastMail, and it shows,
along with the other things:

1) That your e-mails go through bendel.debian.org, the MTA behind this
very list (and other Debian lists). There are others MTA there, but
bendel.d.o is the most important.

2) The fact that your DKIM policy is unnecessary strict, because your
mails to this list routinely fail to verify DKIM.

3) The fact that your SPF policy is failing, probably because your SPF
does not designate bendel.d.o as a permitted sender on your behalf.

Also, consider installing dmarc-cat package, it really useful in
interpreting those DMARC reports, as it shows DMARC report as a
human-readable text, not XML.

Reco