Bug in Clamav Package

[Volker Bäurer]

Hello,

I use the Clamav/Buster. When restarting the service I get:

"... mkdir[17696]: /bin/mkdir: cannot create directory '/run/clamav': File 
exists"

This message is useless because the directory exists and I have seen it since 
Btretch. Perhaps it was current already bevore.

To get rid o fit, I changed in 
/etc/systemd/system/clamav-daemon.service.d/extend.conf

Edit:ExecStartPre=-/bin/mkdir /run/clamav
to
Edit:ExecStartPre=-/bin/mkdir -p /run/clamav

because the /etc/init.d/clamav-daemon already contains "mkdir -p".

Best regards

Volker Bäurer
IT-Specialist

Mitutoyo CTL Germany GmbH
Von-Gunzert-Straße 17
D-78727 Oberndorf
GERMANY
T +49-7423-8776-0
volker.baeu...@mitutoyo-ctl.de
www.mitutoyo-ctl.de

Registered Company: Mitutoyo CTL Germany GmbH
Registered Office: Von Gunzert Straße 17, D-78727 Oberndorf am Neckar
Commercial register of the local court: Amtsgericht Stuttgart, HRB 734157
VAT number: DE272400711
Managing Director: Hans-Peter Klein

Re: Bug in Clamav Package

[Andrei POPESCU]

On Vi, 11 sep 20, 07:26:21, Volker Bäurer wrote:
> Hello,
> 
> I use the Clamav/Buster. When restarting the service I get:
> 
> "... mkdir[17696]: /bin/mkdir: cannot create directory '/run/clamav': File 
> exists"
> 
> This message is useless because the directory exists and I have seen it since 
> Btretch. Perhaps it was current already bevore.
> 
> To get rid o fit, I changed in 
> /etc/systemd/system/clamav-daemon.service.d/extend.conf
> 
> Edit:ExecStartPre=-/bin/mkdir /run/clamav
> to
> Edit:ExecStartPre=-/bin/mkdir -p /run/clamav
> 
> because the /etc/init.d/clamav-daemon already contains "mkdir -p".

Hello,

This is the user support list, which is the recommended contact point in 
case you are not sure if a bug exists and/or where it belongs.

In this particular case you seem to have diagnosed the issue and found a 
fix for it. I would recommend you use 'reportbug' to report this against 
the appropriate package ('clamav-daemon'?).

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


signature.asc
Description: PGP signature

Re: Possible bug with my laptop built-in keyboard after update

[David Wright]

On Sat 05 Sep 2020 at 09:04:48 (+), Jose Mojada wrote:
> It is the first time that I have a problem with debian that I have not been 
> able to solve by searching for information on the web.
> 
> After the last system updates at the end of August, the built-in keyboard of 
> my laptop "Chuwi minibook" has stopped working. In the Grub menu it works 
> correctly, but once you start the system it stops works, and there is no 
> other way to get to use the PC than with a USB keyboard.

If you normally boot directly into a DM, does the keyboard work when you
boot into single-user mode? (ie could this be an X/Wayland problem?)

Cheers,
David.

Re: Possible bug with my laptop built-in keyboard after update

[riveravaldez]

On 9/5/20, Jose Mojada  wrote:
> Hello,
> After the last system updates at the end of August, the built-in keyboard of
> my laptop "Chuwi minibook" has stopped working. In the Grub menu it works
> correctly, but once you start the system it stops works, and there is no
> other way to get to use the PC than with a USB keyboard.

Hola, José,

are you on debian stable or testing (or sid)?

If in testing, maybe you can try with a previous kernel (for instance
the one you had before the update?), at least to check if that fix the
issue and gives you some clue...

Good luck.

Possible bug with my laptop built-in keyboard after update

[Jose Mojada]

Hello,
It is the first time that I have a problem with debian that I have not been 
able to solve by searching for information on the web.

After the last system updates at the end of August, the built-in keyboard of my 
laptop "Chuwi minibook" has stopped working. In the Grub menu it works 
correctly, but once you start the system it stops works, and there is no other 
way to get to use the PC than with a USB keyboard.

I have been looking for how the bug report should be done, but the truth is 
that I cannot clarify myself, I do not know what packages are affected, how 
should I proceed?

Thank you very much in advance and excuse me, I imagine these are questions 
that all newbies ask.
Regards !Jose Mojada

Re: bug: MT7601U Wireless Adapter not work in buster 4 amd

[Matthew Graybosch]

On Thu, 27 Aug 2020 03:04:21 + (UTC)
Long Wind  wrote:

> it crash, reboot can also fail
> at first i thought it's hard disk faultlater i realize that it's more
> likely caused by wireless bug i don't have time to file bug report

It looks like this issue has come up before in Buster.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931561

-- 
Matthew Graybosch   https://matthewgraybosch.com
#include  gemini://starbreaker.org
gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

bug: MT7601U Wireless Adapter not work in buster 4 amd

[Long Wind]

it crash, reboot can also fail
at first i thought it's hard disk faultlater i realize that it's more likely 
caused by wireless bug
i don't have time to file bug report

FW: Bug#968033: RM: wicd -- ROM; Version in unstable depends on Python 2.x, Python3 version only in experimental so far

[Andrei POPESCU]

Heads-up for those using wicd from sid.

- Forwarded message from Axel Beckert  -

Date: Fri, 07 Aug 2020 05:45:41 +0200
From: Axel Beckert 
To: Debian Bug Tracking System 
Subject: Bug#968033: RM: wicd -- ROM; Version in unstable depends on Python 
2.x, Python3 version only in experimental so far
Reply-To: Axel Beckert , 968...@bugs.debian.org
X-Mailer: reportbug 7.7.0

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: w...@packages.debian.org

Please remove wicd from Debian Unstable (and only Unstable). The
version in Debian Unstable depends on Python 2.x and it doesn't look
as if upstream gets the Python 3 port in shape for unstable very soon.

The plan is that those who also have Debian Experimental in their
sources.list might be prompted to update to the incomplete Python 3
port in Debian Experimental instead of staying with the Python 2.x
version and blocking the Python 2 removal on their installations.

I will bring back wicd into Debian Unstable once the Python 3 port is
in an appropriate state.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

- End forwarded message -


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


signature.asc
Description: PGP signature

help with bug report for boot delay in networking

[Armin Faltl]

Hi,

occasionally I experience a hang in booting during the network setup.
The boot screen shows a timeout of 5min 7sec going to 6min 37sec after
the former expired. Then the system starts normally and the networks
work, including openvpn and barracudavpn (when in use).

I didn't file a report with reportbug, since I believe it has to do with
the interaction of packages and not a single package.

As far as I remember, the behavior appeared when I installed openvpn.
With it came the WiFi package and the first use of the
Network-Manager-Applet. My normal network connection is cable based to a
LAN and routed out via a DSL modem to the internet. It is configured
manually via /etc/network/interfaces.

Since my tower machine has no WiFi, I suspect that the WiFi package(s)
look for one, for six and a half minutes and then gives up.

Apart from this behavior I wonder, why WiFi packages would be in a
dependency list of the openvpn package.

I can't tell with certainty now, since I don't have detailed records,
but the hang does not occur every boot, and may have some relation to
hardware initialization, as it may be rarer or not happen, when I reboot
into Debian from Windows 7.
Sometimes the machine hangs in networking for about 2 minutes in
shutdown too, again showing a timeout and counting seconds.

My system runs Debian 10.5 now but the behavior is much older. If you
tell me how, I can send you when I installed what.

Kind Regards,

Armin Faltl

Re: I discovered a bug in the no-ip dynamic dns free hostname auto renewal/confirmation script written by loblab

[Turritopsis Dohrnii Teo En Ming]

Noted.



On 2020-08-16 20:01, Henning Follmann wrote:
On Sun, Aug 16, 2020 at 05:44:51PM +0800, Turritopsis Dohrnii Teo En 
Ming wrote:
Subject: I discovered a bug in the no-ip dynamic dns free hostname 
auto

renewal/confirmation script written by loblab


[...]
Then I downloaded the no-ip ddns free hostname auto 
renewal/confirmation

script using git clone.

Software: Script to auto renew/confirm noip.com free hosts
Download link: https://github.com/loblab/noip-renew
Programmer: loblab


[...]

You downloaded a program from github. This is not
a debian issue.
Please contact the developer on github.

-H


--
-BEGIN EMAIL SIGNATURE-

The Gospel for all Targeted Individuals (TIs):

[The New York Times] Microwave Weapons Are Prime Suspect in Ills of
U.S. Embassy Workers

Link: 
https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html




Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic
Qualifications as at 14 Feb 2019 and refugee seeking attempts at the 
United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 
2019) and Australia (25 Dec 2019 to 9 Jan 2020):


[1] https://tdtemcerts.wordpress.com/

[2] https://tdtemcerts.blogspot.sg/

[3] https://www.scribd.com/user/270125049/Teo-En-Ming

-END EMAIL SIGNATURE-

Re: I discovered a bug in the no-ip dynamic dns free hostname auto renewal/confirmation script written by loblab

[Turritopsis Dohrnii Teo En Ming]

Does ddclient support automatic confirmation of noip.com free hostnames?


On 2020-08-16 21:55, Charles Curley wrote:

On Sun, 16 Aug 2020 17:44:51 +0800
Turritopsis Dohrnii Teo En Ming  wrote:


Subject: I discovered a bug in the no-ip dynamic dns free hostname
auto renewal/confirmation script written by loblab


You may be better off using the debian package ddclient. It supports
no-ip.com.


--
-BEGIN EMAIL SIGNATURE-

The Gospel for all Targeted Individuals (TIs):

[The New York Times] Microwave Weapons Are Prime Suspect in Ills of
U.S. Embassy Workers

Link: 
https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html




Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic
Qualifications as at 14 Feb 2019 and refugee seeking attempts at the 
United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 
2019) and Australia (25 Dec 2019 to 9 Jan 2020):


[1] https://tdtemcerts.wordpress.com/

[2] https://tdtemcerts.blogspot.sg/

[3] https://www.scribd.com/user/270125049/Teo-En-Ming

-END EMAIL SIGNATURE-

Re: I discovered a bug in the no-ip dynamic dns free hostname auto renewal/confirmation script written by loblab

[Charles Curley]

On Sun, 16 Aug 2020 17:44:51 +0800
Turritopsis Dohrnii Teo En Ming  wrote:

> Subject: I discovered a bug in the no-ip dynamic dns free hostname
> auto renewal/confirmation script written by loblab

You may be better off using the debian package ddclient. It supports
no-ip.com.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: I discovered a bug in the no-ip dynamic dns free hostname auto renewal/confirmation script written by loblab

[Henning Follmann]

On Sun, Aug 16, 2020 at 05:44:51PM +0800, Turritopsis Dohrnii Teo En Ming wrote:
> Subject: I discovered a bug in the no-ip dynamic dns free hostname auto
> renewal/confirmation script written by loblab
> 
[...] 
> Then I downloaded the no-ip ddns free hostname auto renewal/confirmation
> script using git clone.
> 
> Software: Script to auto renew/confirm noip.com free hosts
> Download link: https://github.com/loblab/noip-renew
> Programmer: loblab
> 
[...]

You downloaded a program from github. This is not
a debian issue.
Please contact the developer on github.

-H


-- 
Henning Follmann   | hfollm...@itcfollmann.com

I discovered a bug in the no-ip dynamic dns free hostname auto renewal/confirmation script written by loblab

[Turritopsis Dohrnii Teo En Ming]

Subject: I discovered a bug in the no-ip dynamic dns free hostname auto 
renewal/confirmation script written by loblab


Good day from Singapore,

Programming code troubleshooting person: Mr. Turritopsis Dohrnii Teo En 
Ming (Targeted Individual)

Country: Singapore
Date: 15 to 16 August 2020 Singapore Time (Saturday and Sunday)

My IT consulting company in Singapore asked me to install a Linux 
virtual machine so that we can run no-ip dynamic dns free hostname auto 
renewal/confirmation script written by loblab. I am an IT consultant in 
Singapore, 42 years old as of 16 Aug 2020.


I am not a Python or Java programmer or software developer. The last 
time I had formal training in structured C programming (not C++ objected 
oriented programming) was more than 20 years ago at Singapore 
Polytechnic (Diploma in Mechatronics Engineering course year 1995-1998). 
Although I am not a programmer or software developer, I can still more 
or less understand the flow of programming code.


I chose Debian 10.5 64-bit Linux to install as my virtual machine/guest 
operating system because loblab mentioned that his scripts have been 
tested on Debian 9.x/10.x. But first I have to install VMware 
Workstation Pro 15.5.6 in my Ubuntu 18.04.3 LTS Linux desktop operating 
system. The iso file I downloaded is debian-10.5.0-amd64-netinst.iso.


The virtual network adapter in my Debian 10.5 Linux virtual machine was 
configured to use Network Address Translation (NAT). You can verify the 
IP address of your VM with the following Linux commands:


$ ip a

$ ip route

Give your Debian 10.5 Linux VM at least 2 GB of RAM.

After installing Debian 10.5 Linux virtual machine (minimal installation 
with SSH server and standard system utilities), I need to do a few more 
things, as follows.


# apt install sudo

# usermod -aG sudo teo-en-ming

# groups teo-en-ming

So that I can sudo as a regular Linux user.

# apt install git

Then I downloaded the no-ip ddns free hostname auto renewal/confirmation 
script using git clone.


Software: Script to auto renew/confirm noip.com free hosts
Download link: https://github.com/loblab/noip-renew
Programmer: loblab

I believe programmer loblab is based in China.

The version of the scripts I downloaded is 1.1 dated 18 May 2020.

The composition of the software is 58.4% Python programming language, 
36% Linux shell scripts, and 5.6% Dockerfile.


I tried to run setup.sh Linux shell script and choose "Install/Repair 
Script". But I found out that nothing is being installed in 
/usr/local/bin after a few installation attempts.


I thought the scripts/installation were being blocked by AppArmor, so I 
went to disable AppArmor using the following Linux commands.


$ sudo mkdir -p /etc/default/grub.d
$ echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT 
apparmor=0"' \

  | sudo tee /etc/default/grub.d/apparmor.cfg
$ sudo update-grub
$ sudo reboot

$ aa-enabled
$ sudo aa-status

But AppArmor is NOT the cause of the problem.

I began to examine the Python programming code and Linux shell scripts.

For the setup.sh script, when you choose "Install/Repair Script", it 
will call the installer() function. Inside the installer() function, it 
will call the following functions, in sequence:


config(), install(), deploy()

When the install() function was called, it tried to execute the 
following Linux command:


$SUDO apt -y install chromium-browser # Update Chromium Browser or 
script won't work.


Executing the above Linux command resulted in an ERROR because Debian 
10.5 Linux does not have the chromium-browser software package. Instead 
it has the chromium package.


When the above error is encountered, the installer script ABORTED 
PREMATURELY and could not continue running. The installer script could 
not run to completion. This is the bug.


To fix the bug, I have to COMMENT OUT/DISABLE the following line in 
setup.sh script:


$SUDO apt -y install chromium-browser # Update Chromium Browser or 
script won't work.


And add the following line below the above-mentioned line:

$SUDO apt -y install chromium

It fixed the bug. I ran setup.sh script again, choose "Install/Repair 
Script", and the installer ran to completion. Finally the scripts are 
installed in /usr/local/bin.


Please DO NOT add your no-ip account password to noip-renew.sh script 
manually in plain text because it has to be Base64 encoded/encrypted. If 
you add your no-ip account password directly to noip-renew.sh script, 
you will get an "Incorrect Padding" Python programming base64 error 
code.


You need to supply the no-ip account password when you run the installer 
script. When the installer script calls the deploy() function, it will 
also call the noip() function.


The noip() function is as follows:

function noip() {
echo "Enter your No-IP Account details..."
read -p 'Username: ' uservar
read -sp 'Pass

Re: Bug #961990

[Michael Lange]

Hi,

On Sun, 19 Jul 2020 18:47:37 -0400
The Wanderer  wrote:

> Looking at it, I don't see anything which strikes me as qualifying as
> buggy. Can you clarify what about it you see as being a misbehavior
> problem?
> 
(...)
> It appears that the software previously provided in libgcc1 is now being
> provided, in a newer version, in libgcc-s1.

not sure if I am missing something here, but from the things I read in
this thread this strikes me as a situation that is crying for a
transitional meta-package "libgcc1" which would remove the old libgcc1,
pull in libgcc1-s1 and thus leave dependencies intact.

Just a thought, though.

Regards

Michael


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

There's coffee in that nebula!
-- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"

Re: Bug #961990

[The Wanderer]

On 2020-07-19 at 18:14, Default User wrote:

> On 2020-07-19 at 16:27, Stefan Monnier wrote:
> 
>>> This has been going on since the beginning of June, 2020, with
>>> no end in sight.
>>> Bug #961990 - IIUC, no activity since 2020-06-02.
>>>
>> You show a session where you reject all the proposed solutions, but
>> I don't see any justification why you reject those choices, so I don't
>> know what you consider to be a bug.
>>
>>> Remove the following packages:
>>> 1) libgcc1 [1:10.1.0-1 (now, unstable)]
>>> Accept this solution? [Y/n/q/?] n
>> 
>> I said `y` here and lived happily ever after.
> 
> Yes.  Each time (many times, since the beginning of June) I went
> through the solutions offered, each worse than the last.  I consider
> Bug #961990 to be just that - a bug.  I do wish that if this bug is
> not going to be fixed, that the maintainers would say so.

Looking at it, I don't see anything which strikes me as qualifying as
buggy. Can you clarify what about it you see as being a misbehavior
problem?

> The least "damaging" solution offered seemed to be, as you noted, to
> remove libgcc1.  I have often been tempted to do that, just to not
> have 12 stale packages hanging around each time I update. I may end up
> removing libgcc1, since I do not currently do any C programming, but I
> hope that would not "come back to bite me".

It appears that the software previously provided in libgcc1 is now being
provided, in a newer version, in libgcc-s1.

So you aren't losing any software, just changing which package it comes
in. The only real downside of this is breaking dependency expectations
from packages built against the previous package name. As long as you
don't need to install any such packages, then you shouldn't have any
problems.

(Doing or not doing C programming isn't really relevant to whether you
want to have a particular library installed; more important is whether
you want to use any program which has been compiled against that
library.)

> On Sun, Jul 19, 2020 at 4:42 PM The Wanderer 
> wrote:
> 
>> As he made clear later on, he rejected this because he has (or
>> wants to
>> have) packages from external repositories which depend on libgcc1 by
>> that name and which he isn't willing to give up.
>>
>> IOW, not only is he running sid (unofficial motto: "whenever it breaks,
>> you get to keep all the pieces"), he's also running a partial
>> FrankenDebian (those external repositories' URLs indicate that they
>> correspond to buster, not to sid), and is complaining that an apparently
>> internally consistent state of packages in sid isn't consistent with the
>> state of packages in those external repositories.

> I am puzzled that you refer to a FrankenDebian, using external repositories.
> The original installation was made 2018-08-10, just before the switch
> from Stretch to Buster.  I IMMEDIATELY upgraded to Unstable, with this
> /etc/apt/sources.list:



> I did not use Testing on the way to Unstable, and have always
> scrupulously avoided third party repositories of any kind.  And I have
> no intention of trying to downgrade to Buster, or even Testing.  I do
> not mix repositories between Stable, Testing and Unstable.  I really
> do know better than that.
> 
> 
> 
> Am I missing something?

I'm sorry - I somehow managed to blindly misread bug #961990 as being
(and involving comments) from you. Looking at it again, I see that it's
from someone else, and the references to third-party repositories which
mention buster are from that same person. My previous FrankenDebian,
etc., comments should be taken as being in regard to that person.

If you aren't interested in external repositories in that way, then you
should have no hesitation about removing libgcc1 in favor of libgcc-s1.

> BTW, I love the classic quote from George Bernard Shaw.
> : )

Thanks. ^_^

-- 
   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: Bug #961990

[Default User]

On 2020-07-19 at 16:27, Stefan Monnier wrote:

>> This has been going on since the beginning of June, 2020, with no end in 
>> sight.
>> Bug #961990 - IIUC, no activity since 2020-06-02.
>>
> You show a session where you reject all the proposed solutions, but
> I don't see any justification why you reject those choices, so I don't
> know what you consider to be a bug.
>
>> Remove the following packages:
>> 1) libgcc1 [1:10.1.0-1 (now, unstable)]
>> Accept this solution? [Y/n/q/?] n
>>
> I said `y` here and lived happily ever after.

Yes.  Each time (many times, since the beginning of June) I went
through the solutions offered, each worse than the last.  I consider
Bug #961990 to be just that - a bug.  I do wish that if this bug is
not going to be fixed, that the maintainers would say so.

The least "damaging" solution offered seemed to be, as you noted, to
remove libgcc1.  I have often been tempted to do that, just to not
have 12 stale packages hanging around each time I update. I may end up
removing libgcc1, since I do not currently do any C programming, but I
hope that would not "come back to bite me".


On Sun, Jul 19, 2020 at 4:42 PM The Wanderer  wrote:
> As he made clear later on, he rejected this because he has (or wants to
> have) packages from external repositories which depend on libgcc1 by
> that name and which he isn't willing to give up.
>
> IOW, not only is he running sid (unofficial motto: "whenever it breaks,
> you get to keep all the pieces"), he's also running a partial
> FrankenDebian (those external repositories' URLs indicate that they
> correspond to buster, not to sid), and is complaining that an apparently
> internally consistent state of packages in sid isn't consistent with the
> state of packages in those external repositories.
>
> The only solution here I can think of offhand would be to rebuild the
> packages from those external repositories to reflect the new package
> names that exist in sid. As it happens, libgcc-s1 is also the package in
> testing at the moment (albeit at an earlier version), so there's more of
> a case for convincing the upstreams of those repositories to do that
> rebuild now rather than later - but it's probably theoretically possible
> to do it locally, too.
>
> (Well, switching to track a newer-than-buster version of those external
> repositories, or to track buster itself instead of sid for the internal
> repositories, would also resolve the conflict. But the former may not
> exist, and the latter would involve significant downgrades from what
> he's probably already installed, so neiterh is likely to be considered a
> real solution.)
>
> --
>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
>


I am puzzled that you refer to a FrankenDebian, using external repositories.
The original installation was made 2018-08-10, just before the switch
from Stretch to Buster.  I IMMEDIATELY upgraded to Unstable, with this
/etc/apt/sources.list:

# deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST
20180310-11:21]/ buster contrib main non-free

debhttp://ftp.us.debian.org/debian/unstable
main  non-free  contrib
deb-srchttp://ftp.us.debian.org/debian/unstable
main  non-free  contrib

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

# buster-updates, previously known as 'volatile'
# deb  http://ftp.us.debian.org/debian/buster-updates
main  non-free  contrib
# deb-src  http://ftp.us.debian.org/debian/buster-updates
main  non-free  contrib


Here is my current /etc/apt/sources.list:



# deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST
20180310-11:21]/ buster contrib>

  deb  http://ftp.us.debian.org/debian/unstable
main  contrib  non-free
# deb-src  http://ftp.us.debian.org/debian/unstable
main  contrib  non-free

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

# buster-updates, previously known as 'volatile'
# deb  http://ftp.us.debian.org/debian/buster-updates
main  contrib  non-free
# deb-src  http://ftp.us.debian.org/debian/buster-updates
main  contrib  non-free



The only uncommented line seems to be:

  deb  

Re: Bug #961990

[The Wanderer]

On 2020-07-19 at 16:27, Stefan Monnier wrote:

>> This has been going on since the beginning of June, 2020, with no end in 
>> sight.
>> Bug #961990 - IIUC, no activity since 2020-06-02.
> 
> You show a session where you reject all the proposed solutions, but
> I don't see any justification why you reject those choices, so I don't
> know what you consider to be a bug.
> 
>>  Remove the following packages:
>> 1) libgcc1 [1:10.1.0-1 (now, unstable)]
>> Accept this solution? [Y/n/q/?] n
> 
> I said `y` here and lived happily ever after.

As he made clear later on, he rejected this because he has (or wants to
have) packages from external repositories which depend on libgcc1 by
that name and which he isn't willing to give up.

IOW, not only is he running sid (unofficial motto: "whenever it breaks,
you get to keep all the pieces"), he's also running a partial
FrankenDebian (those external repositories' URLs indicate that they
correspond to buster, not to sid), and is complaining that an apparently
internally consistent state of packages in sid isn't consistent with the
state of packages in those external repositories.

The only solution here I can think of offhand would be to rebuild the
packages from those external repositories to reflect the new package
names that exist in sid. As it happens, libgcc-s1 is also the package in
testing at the moment (albeit at an earlier version), so there's more of
a case for convincing the upstreams of those repositories to do that
rebuild now rather than later - but it's probably theoretically possible
to do it locally, too.

(Well, switching to track a newer-than-buster version of those external
repositories, or to track buster itself instead of sid for the internal
repositories, would also resolve the conflict. But the former may not
exist, and the latter would involve significant downgrades from what
he's probably already installed, so neiterh is likely to be considered a
real solution.)

-- 
   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: Bug #961990

[Stefan Monnier]

> This has been going on since the beginning of June, 2020, with no end in 
> sight.
> Bug #961990 - IIUC, no activity since 2020-06-02.

You show a session where you reject all the proposed solutions, but
I don't see any justification why you reject those choices, so I don't
know what you consider to be a bug.

>  Remove the following packages:
> 1) libgcc1 [1:10.1.0-1 (now, unstable)]
> Accept this solution? [Y/n/q/?] n

I said `y` here and lived happily ever after.


Stefan

Bug #961990

[Default User]

Hi.

I'm running 64-bit Debian Unstable.

This has been going on since the beginning of June, 2020, with no end in sight.
Bug #961990 - IIUC, no activity since 2020-06-02.


dimwit@dimwit:~$ date; sudo aptitude -Pvvv update
Sun 19 Jul 2020 02:25:08 PM EDT
Hit http://ftp.us.debian.org/debian unstable InRelease

Current status: 0 (+0) broken, 12 (+0) upgradable, 59230 (+0) new.


dimwit@dimwit:~$ date; sudo aptitude -Pvvv full-upgrade
Sun 19 Jul 2020 02:25:20 PM EDT
The following packages will be upgraded:
  gcc-10-base libatomic1 libcc1-0 libgcc-s1 libgfortran5 libgomp1
libitm1 liblsan0 libquadmath0
  libstdc++6 libtsan0 libubsan1
12 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,368 kB of archives. After unpacking 10.2 kB will be used.
The following packages have unmet dependencies:
 libgcc1 : Depends: gcc-10-base (= 10.1.0-1) but 10.1.0-6 is to be installed
The following actions will resolve these dependencies:

  Keep the following packages at their current version:
1)  gcc-10-base [10.1.0-1 (now)]
2)  libatomic1 [10.1.0-1 (now)]
3)  libcc1-0 [10.1.0-1 (now)]
4)  libgcc-s1 [10.1.0-1 (now)]
5)  libgfortran5 [10.1.0-1 (now)]
6)  libgomp1 [10.1.0-1 (now)]
7)  libitm1 [10.1.0-1 (now)]
8)  liblsan0 [10.1.0-1 (now)]
9)  libquadmath0 [10.1.0-1 (now)]
10) libstdc++6 [10.1.0-1 (now)]
11) libtsan0 [10.1.0-1 (now)]
12) libubsan1 [10.1.0-1 (now)]



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

 Remove the following packages:
1) libgcc1 [1:10.1.0-1 (now, unstable)]



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

  Remove the following packages:
1)  build-essential [12.8 (now, unstable)]
2)  g++ [4:9.2.1-3.1 (now, unstable)]
3)  g++-9 [9.3.0-15 (now, unstable)]
4)  gcc [4:9.2.1-3.1 (now, unstable)]
5)  gcc-9 [9.3.0-15 (now, unstable)]
6)  libgcc-9-dev [9.3.0-15 (now, unstable)]
7)  libstdc++-9-dev [9.3.0-15 (now, unstable)]
8)  libubsan1 [10.1.0-1 (now)]

  Install the following packages:
9)  tcc [0.9.27-8 (unstable)]

  Keep the following packages at their current version:
10) gcc-10-base [10.1.0-1 (now)]
11) libatomic1 [10.1.0-1 (now)]
12) libcc1-0 [10.1.0-1 (now)]
13) libgcc-s1 [10.1.0-1 (now)]
14) libgfortran5 [10.1.0-1 (now)]
15) libgomp1 [10.1.0-1 (now)]
16) libitm1 [10.1.0-1 (now)]
17) liblsan0 [10.1.0-1 (now)]
18) libquadmath0 [10.1.0-1 (now)]
19) libstdc++6 [10.1.0-1 (now)]
20) libtsan0 [10.1.0-1 (now)]

  Leave the following dependencies unresolved:
21) dpkg-dev recommends build-essential
22) python3-pip recommends build-essential



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

  Remove the following packages:
1)  build-essential [12.8 (now, unstable)]
2)  g++ [4:9.2.1-3.1 (now, unstable)]
3)  g++-9 [9.3.0-15 (now, unstable)]
4)  gcc [4:9.2.1-3.1 (now, unstable)]
5)  gcc-9 [9.3.0-15 (now, unstable)]
6)  libcc1-0 [10.1.0-1 (now)]

  Install the following packages:
7)  tcc [0.9.27-8 (unstable)]

  Keep the following packages at their current version:
8)  gcc-10-base [10.1.0-1 (now)]
9)  libatomic1 [10.1.0-1 (now)]
10) libgcc-s1 [10.1.0-1 (now)]
11) libgfortran5 [10.1.0-1 (now)]
12) libgomp1 [10.1.0-1 (now)]
13) libitm1 [10.1.0-1 (now)]
14) liblsan0 [10.1.0-1 (now)]
15) libquadmath0 [10.1.0-1 (now)]
16) libstdc++6 [10.1.0-1 (now)]
17) libtsan0 [10.1.0-1 (now)]
18) libubsan1 [10.1.0-1 (now)]

  Leave the following dependencies unresolved:
19) dpkg-dev recommends build-essential
20) python3-pip recommends build-essential



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

  Remove the following packages:
1)  build-essential [12.8 (now, unstable)]
2)  g++ [4:9.2.1-3.1 (now, unstable)]
3)  g++-9 [9.3.0-15 (now, unstable)]
4)  gcc [4:9.2.1-3.1 (now, unstable)]
5)  gcc-9 [9.3.0-15 (now, unstable)]
6)  libatomic1 [10.1.0-1 (now)]
7)  libgcc-9-dev [9.3.0-15 (now, unstable)]
8)  libstdc++-9-dev [9.3.0-15 (now, unstable)]

  Install the following packages:
9)  tcc [0.9.27-8 (unstable)]

  Keep the following packages at their current version:
10) gcc-10-base [10.1.0-1 (now)]
11) libcc1-0 [10.1.0-1 (now)]
12) libgcc-s1 [10.1.0-1 (now)]
13) libgfortran5 [10.1.0-1 (now)]
14) libgomp1 [10.1.0-1 (now)]
15) libitm1 [10.1.0-1 (now)]
16) liblsan0 [10.1.0-1 (now)]
17) libquadmath0 [10.1.0-1 (now)]
18) libstdc++6 [10.1.0-1 (now)]
19) libtsan0 [10.1.0-1 (now)]
20) libubsan1 [10.1.0-1 (now)]

  Leave the following dependencies unresolved:
21) dpkg-dev recommends build-essential
22) python3-pip recommends build-essential

. . .

Accept this solution? [Y/n/q

Re: Re: How do I report bug on Old machine via this New Laptop?

[PaulG]

Thanks Greg,

I will report it on Kali (not Debian).

Re: How do I report bug on Old machine via this New Laptop?

[Greg Wooledge]

On Mon, Jul 13, 2020 at 02:16:03PM -0700, Paul Gerken wrote:
> Fri 7/10  installed Kali linux from USB, burned from
> kali-linux-2020.2-installer-amd64  download of 7/7.

> Installed as Kali on different AMD Athalon 64x2 tower machine which has no
> email on it.

> Distro is  5.7.0-kali1-amd64 #1 SMP Debian 5.7.6-1kali2 (2020-07-01) x86_64
> GNU /Linux

> How do I go about reporting this problem? w/o email on target Kali linux
> machine?

You type "kali bug report" into Google, and then you follow whatever
the instructions are for reporting a bug to your operating system
vendor (Kali).

This is not a Debian system, so I don't know why you think Debian users
are going to be able to help you.

Re: How do I report bug on Old machine via this New Laptop?

[Andrei POPESCU]

On Lu, 13 iul 20, 19:27:22, The Wanderer wrote:
> 
> The short answer is that when you cancel an otherwise-complete bug
> report from the 'reportbug' program, it saves the result into a file,
> and you can take that file to another machine and (with a little work)
> turn it into an E-mail that can be sent from there.
> 
> I use a similar method on my own computer, since although I do have the
> ability to send E-mail from here, I can't do it from the command line or
> via reportbug. I suspect I don't have a working SMTP configuration
> defined anywhere those mail systems know how to access.

Run 'reportbug --configure' and choose reportbug.debian.org as 
smarthost.

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


signature.asc
Description: PGP signature

Re: How do I report bug on Old machine via this New Laptop?

[The Wanderer]

On 2020-07-13 at 17:16, Paul Gerken wrote:

> Hi User,
> 
>apt-get install cups cups-client "foomatic-db*"  
> 
> fails with  foomatic-db-compressed-ppds  : Conflicts:   foomatic-db  Breaks:
> foomatic-db  
> 
>   Unable to correct problems, you have held broken packages.

That appears to be because it's not supposed to be possible to install
both of these two packages side-by-side.

They apparently both provide files that satisfy the same requirement,
such that having both of them present on the same running system
wouldn't make sense.

You'll need to narrow down your list of packages to be installed, by not
using the wildcard.

The list of package which that wildcard pattern would match can be
identified in a number of ways, but I just did it by the following:

$ apt-cache search foomatic | grep ^foomatic

(I'd expect 'apt-cache search ^foomatic' to do it, but apparently that
also matches the cups-filters package. I don't care enough to
investigate why at the moment.)

> How do I go about reporting this problem? w/o email on target Kali
> linux machine?

I did write out a fairly lengthy, step-by-step answer to this, but I
think the answer had started to become condescending and generally
unproductive, so I'm not going to include it here.

The short answer is that when you cancel an otherwise-complete bug
report from the 'reportbug' program, it saves the result into a file,
and you can take that file to another machine and (with a little work)
turn it into an E-mail that can be sent from there.

I use a similar method on my own computer, since although I do have the
ability to send E-mail from here, I can't do it from the command line or
via reportbug. I suspect I don't have a working SMTP configuration
defined anywhere those mail systems know how to access.

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

How do I report bug on Old machine via this New Laptop?

[Paul Gerken]

Hi User,

   apt-get install cups cups-client "foomatic-db*"  

fails with  foomatic-db-compressed-ppds  : Conflicts:   foomatic-db  Breaks:
foomatic-db  

  Unable to correct problems, you have held broken packages.

  unmet dependencies

 

Fri 7/10  installed Kali linux from USB, burned from
kali-linux-2020.2-installer-amd64  download of 7/7.

D/L on this laptop Intel i7  WIN7 machine that has email.  

Installed as Kali on different AMD Athalon 64x2 tower machine which has no
email on it.

 

Distro is  5.7.0-kali1-amd64 #1 SMP Debian 5.7.6-1kali2 (2020-07-01) x86_64
GNU /Linux

 

How do I go about reporting this problem? w/o email on target Kali linux
machine?

Which package is it against?  foomatic-db-compressed-ppds   OR   foomatic-db
??

New-ish to Linux, fast learning, have programmed in different O/S-s back to
1961.

 

More importantly, how do I go about fixing it? 

Or does someone else need to change the source and re-gen?

 

Tkx, Paul Gerken

 

 

Re: which package to file a bug against?

[Andrei POPESCU]

On Sb, 20 iun 20, 08:54:52, Matt Zagrabelny wrote:
> Greetings d-u,
> 
> I have a new-ish laptop and a pair of the function keys (screen
> brighter/dimmer) are mapped to the wrong function (mic mute/unmute).

Are you using the correct keyboard layout?

You could try 'dpkg-reconfigure keyboard-configuration' and selecting 
the one that comes closest to yours.

If that doesn't work either you might need a custom keymap (that could 
also be submitted upstream for inclusion).

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


signature.asc
Description: PGP signature

Re: bug report

[Andrei POPESCU]

[it's likely you are not subscribed, sorry for the Cc: in case you are]

On Sb, 20 iun 20, 07:58:33, gilleswicki wrote:
> Hello, I found a bug on my system and tried to report it using the 
> reportbug software. But as I don't know which packet is the cause of 
> the bug, following the procedure of the reportbug software, I write 
> here to ask what I should do.

Excelent!

> My bug is that when I try to change the brightness of the screen 
> either using the keyboard shortcut for that or the cinnamon graphical 
> tool, the value in the file "brightness" located in 
> "/sys/class/backlight/acpi_video0" changes but the brightness of the 
> screen does not.

Annoying.

> I have Debian 10 with cinnamon as desktop environment.
> My hardware is a laptop "Why! P775DM3"
> What should I do to report this bug?

This appears to be an issue with the kernel (improper support for your 
laptop), however...

... reporting the bug in Debian is not going to be very useful, because 
the kernel in Debian 10 (also known as 'buster') is quite "old" now, and 
because Debian uses mostly what the upstream kernel developers are 
providing.  

Even if a fix (patch) was available, it would have to be included in a 
newer version upstream before even considering to apply it to the kernel 
in buster (if ever).

My suggestion would be to first try the kernel from "backports", which 
is reasonably recent.
https://backports.debian.org/Instructions/

(you might want to install the package 'linux-image-amd64' from 
'backports', this way your kernel will be automatically upgraded to the 
newest one available in 'backports')

If this doesn't fix your issue and you are willing to experiment you 
could compile the latest kernel from upstream. In case that doesn't 
support your laptop's backlight controls either you could then report 
the issue there (not Debian).

That would be outside the scope of this list, though you are likely to 
receive some useful advice here for that as well if you ask.

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: which package to file a bug against?

[Marko Randjelovic]

Hi Matt Zagrabelny,

On Sat, 20 Jun 2020 08:54:52 -0500
Matt Zagrabelny  wrote:

> Greetings d-u,
> 
> I have a new-ish laptop and a pair of the function keys (screen
> brighter/dimmer) are mapped to the wrong function (mic mute/unmute).
> 
> Where should I look to file the bug?

Use reportbug tool to file a bug.
> 
> I'm aware it is ACPI related, but I do not have any packages installed
> that have "acpi" in the package name.

Try this to list all packages that are installed and have acpi in
either package name and description:

apt-cache search acpi | while read package_name rest; do if dpkg -l 
$package_name &>/dev/null; then echo $package_name; fi; done

Also, kernel has support for ACPI.

And it's not necessary to know exact package which is to blame, as
package maintainers can reassign a bug report to another package.

Regards, 
Marko

which package to file a bug against?

[Matt Zagrabelny]

Greetings d-u,

I have a new-ish laptop and a pair of the function keys (screen
brighter/dimmer) are mapped to the wrong function (mic mute/unmute).

Where should I look to file the bug?

I'm aware it is ACPI related, but I do not have any packages installed
that have "acpi" in the package name.

The tech stack for my desktop environment (MATE) is somewhat tall, so
I don't quite know where to invest time for the bug report.

Thanks for any guidance!

-m

bug report

[gilleswicki]

Hello, I found a bug on my system and tried to report it using the reportbug 
software. But as I don't know which packet is the cause of the bug, following 
the procedure of the reportbug software, I write here to ask what I should do.
My bug is that when I try to change the brightness of the screen either using 
the keyboard shortcut for that or the cinnamon graphical tool, the value in the 
file "brightness" located in "/sys/class/backlight/acpi_video0" changes but the 
brightness of the screen does not.
I have Debian 10 with cinnamon as desktop environment.
My hardware is a laptop "Why! P775DM3"
What should I do to report this bug?
Thank you
Gilles Wicki

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: apt has a bug, cannot believe it!

[Jonathan Dowland]

On Mon, May 25, 2020 at 10:04:45PM +0200, Marco Möller wrote:

Even worth, apt is one out of a very few priority reasons to use Debian, or?


When I first used Debian, 20 years ago, apt(-get) was indeed one of the
primary reasons to use Debian. But back then it did not have Recommends:
nor auto-removal of auto-installed packages.

--
👱🏻  Jonathan Dowland
✎   j...@dow.land
🔗   https://jmtd.net

Re: apt has a bug, cannot believe it!

[Andrei POPESCU]

On Lu, 25 mai 20, 22:04:45, Marco Möller wrote:
> If installing (default parameters in use: with recommends) a package, and
> right afterwards removing it, then the by recommendation drawn in packages
> do not become removed automatically. 

This behaviour is intended and controlled by the 
AutoRemove::RecommendsImportant and AutoRemove::SuggestsImportant 
configuration directives (both enabled by default).

See apt-get(8) and apt.conf(5) for how to disable them per invocation or 
globally.

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


signature.asc
Description: PGP signature

Re: apt has a bug, cannot believe it!

[Liam O'Toole]

On Mon, 25 May, 2020 at 23:55:02 +0200, Marco Möller wrote:
> On 25.05.20 23:24, Liam O'Toole wrote:
> > 
> > [...]
> > 
> > It's OK. I understood your question the first time.
> > 
> > The simple answer is that the '--no-install-recommends' option applies
> > only to the current install command. The result of a subsequent remove
> > command will depend on the state of the dependency graph as a whole at
> > the time.
> > 
> 
> So, no "undo" is in apt available, its database does not store sufficient
> information for it.  :-(  This is what I see as a severe bug.
> 
> Not your fault, thanks for your input! I have had hope for a moment that
> there would exist some "undo" solution, maybe some not by default installed
> package carrying a command for it, a package somewhere in the repository and
> I missed to find it.
> 
> Manual bumbling is now needed. Fortunately I have only used the 'apt'
> command for all installations, from the beginning, and not used apt-get
> directly or aptitude or synaptic. Therefore I at least have a complete log
> on all manually given 'apt install' commands  in /var/log/apt/history.log  ,
> to which the 'apt' command also registers the full command with all its
> parameters as having been used (some of the other mentioned tools do not log
> the exact given command, only the result of it). I now would have to write
> some script, some LogFile to InstallationScript parser, in order to get what
> I thought would happen as an "undo" by 'apt purge package'.

See the output of the command 'dpkg --get-selections', and the script
/etc/cron.daily/dpkg, for inspiration.

> 
> As I am still quite new here on the Debian mailing lists, was this a topic
> before? Does it qualify for a bug report for motivating some clever
> programmers to enhance the apt cache with logging the necessary information?
> Or was it already an overheating topic in the past and I better don't spark?

Both APT and this mailing list have been around for a long time. I'd be
surprised if the topic has not been discussed before.

Re: apt has a bug, cannot believe it!

[Dan Ritter]

Marco M??ller wrote: 
> So, no "undo" is in apt available, its database does not store sufficient
> information for it.  :-(  This is what I see as a severe bug.

There is no undo for apt. There is uninstall, and purge. 

Suppose you install Feeblix, which recommends libfoo, and Barganza,
which also recommends libfoo, and you then write Scrobblo which 
uses libfoo.

Now you uninstall Feeblix. What should happen to libfoo?

> Manual bumbling is now needed. Fortunately I have only used the 'apt'
> command for all installations, from the beginning, and not used apt-get
> directly or aptitude or synaptic.

Those all update the same installed package database and draw
from the same sources.


> Therefore I at least have a complete log
> on all manually given 'apt install' commands  in /var/log/apt/history.log  ,

That file should update from any action from apt, apt-get,
aptitude or synaptic.

> As I am still quite new here on the Debian mailing lists, was this a topic
> before? Does it qualify for a bug report for motivating some clever
> programmers to enhance the apt cache with logging the necessary information?
> Or was it already an overheating topic in the past and I better don't spark?

It's just the way it is. If you wanted to implement an apt undo
action, you could define its behavior carefully and send in a
patch. You should probably look through the apt maintainer team
archives, first, though.

https://lists.debian.org/deity/

-dsr-

Re: apt has a bug, cannot believe it!

[Marco Möller]

On 25.05.20 23:24, Liam O'Toole wrote:


[...]

It's OK. I understood your question the first time.

The simple answer is that the '--no-install-recommends' option applies
only to the current install command. The result of a subsequent remove
command will depend on the state of the dependency graph as a whole at
the time.



So, no "undo" is in apt available, its database does not store 
sufficient information for it.  :-(  This is what I see as a severe bug.


Not your fault, thanks for your input! I have had hope for a moment that 
there would exist some "undo" solution, maybe some not by default 
installed package carrying a command for it, a package somewhere in the 
repository and I missed to find it.


Manual bumbling is now needed. Fortunately I have only used the 'apt' 
command for all installations, from the beginning, and not used apt-get 
directly or aptitude or synaptic. Therefore I at least have a complete 
log on all manually given 'apt install' commands  in 
/var/log/apt/history.log  , to which the 'apt' command also registers 
the full command with all its parameters as having been used (some of 
the other mentioned tools do not log the exact given command, only the 
result of it). I now would have to write some script, some LogFile to 
InstallationScript parser, in order to get what I thought would happen 
as an "undo" by 'apt purge package'.


As I am still quite new here on the Debian mailing lists, was this a 
topic before? Does it qualify for a bug report for motivating some 
clever programmers to enhance the apt cache with logging the necessary 
information? Or was it already an overheating topic in the past and I 
better don't spark?

Re: apt has a bug, cannot believe it!

[Liam O'Toole]

On Mon, 25 May, 2020 at 23:04:17 +0200, Marco Möller wrote:
> On 25.05.20 22:34, Liam O'Toole wrote:
> > On Mon, 25 May, 2020 at 22:12:58 +0200, Erwan David wrote:
> > > Le 25/05/2020 à 22:04, Marco Möller a écrit :
> > > > If installing (default parameters in use: with recommends) a package,
> > > > and right afterwards removing it, then the by recommendation drawn in
> > > > packages do not become removed automatically. The system is swelling
> > > > with no more wanted packages!
> > > > I hope I am simply missing the simple step how to return to the former
> > > > system state after having tested a package. Otherwise this is a bug.
> > > > To me it appears to be a severe bug, as apt is not managing the
> > > > packages in my system as expected.
> > 
> > [...]
> > 
> > > dialog may be recommended by another package, in which case apt won't
> > > remove it automatically.
> > That's my guess too. If aptitude is installed, the command 'aptitude why
> > deborphan' will provide the answer. If not, the command 'apt rdepends
> > deborphan' will give at least a clue.
> > 
> 
> Yes, I know. Sorry, I obviously was not clear enough in my question and need
> to complete it:

[...]

It's OK. I understood your question the first time.

The simple answer is that the '--no-install-recommends' option applies
only to the current install command. The result of a subsequent remove
command will depend on the state of the dependency graph as a whole at
the time.

Re: apt has a bug, cannot believe it!

[Marco Möller]

On 25.05.20 22:34, Liam O'Toole wrote:

On Mon, 25 May, 2020 at 22:12:58 +0200, Erwan David wrote:

Le 25/05/2020 à 22:04, Marco Möller a écrit :

If installing (default parameters in use: with recommends) a package,
and right afterwards removing it, then the by recommendation drawn in
packages do not become removed automatically. The system is swelling
with no more wanted packages!
I hope I am simply missing the simple step how to return to the former
system state after having tested a package. Otherwise this is a bug.
To me it appears to be a severe bug, as apt is not managing the
packages in my system as expected.


[...]


dialog may be recommended by another package, in which case apt won't
remove it automatically.
  
That's my guess too. If aptitude is installed, the command 'aptitude why

deborphan' will provide the answer. If not, the command 'apt rdepends
deborphan' will give at least a clue.



Yes, I know. Sorry, I obviously was not clear enough in my question and 
need to complete it:
Packages which before have been installed with "--no-install-recommends" 
might have some recommends defined in their control file. But is was 
explicitly ordered to not install the recommends. If afterwards 
test-installing some package WITH recommends and wanting to undo this 
action right afterwards, then the newly installed recommended packages 
remain installed because they appear in other package's recommendation 
lists, although for those other packages it was explicitly said that 
WITHOUT recommends was requested for them.
'apt' argues that those others packages would ask for them although for 
those other packages it was explicitly ordered that no recommends should 
be installed because of them.

Re: apt has a bug, cannot believe it!

[Liam O'Toole]

On Mon, 25 May, 2020 at 22:12:58 +0200, Erwan David wrote:
> Le 25/05/2020 à 22:04, Marco Möller a écrit :
> > If installing (default parameters in use: with recommends) a package,
> > and right afterwards removing it, then the by recommendation drawn in
> > packages do not become removed automatically. The system is swelling
> > with no more wanted packages!
> > I hope I am simply missing the simple step how to return to the former
> > system state after having tested a package. Otherwise this is a bug.
> > To me it appears to be a severe bug, as apt is not managing the
> > packages in my system as expected.

[...]

> dialog may be recommended by another package, in which case apt won't
> remove it automatically.
 
That's my guess too. If aptitude is installed, the command 'aptitude why
deborphan' will provide the answer. If not, the command 'apt rdepends
deborphan' will give at least a clue.

Re: apt has a bug, cannot believe it!

[Erwan David]

Le 25/05/2020 à 22:04, Marco Möller a écrit :
> If installing (default parameters in use: with recommends) a package,
> and right afterwards removing it, then the by recommendation drawn in
> packages do not become removed automatically. The system is swelling
> with no more wanted packages!
> I hope I am simply missing the simple step how to return to the former
> system state after having tested a package. Otherwise this is a bug.
> To me it appears to be a severe bug, as apt is not managing the
> packages in my system as expected.
>
>
> Commandline: apt install deborphan
> Install: deborphan:amd64 (1.7.33), dialog:amd64 (1.3-20190808-1,
> automatic)
>
> Commandline: apt purge deborphan
> Purge: deborphan:amd64 (1.7.33)
>
> apt autoremove
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
>
> You might argue, that this is easy to solve. In this example, yes, it
> could be solved easily, especially as I remember clearly all the
> details of the screen output from a second ago. But I have tested (and
> removed) packages which drew in many recommended packages some months
> ago, and they are now all leftover in my system!
>
> Even worth, apt is one out of a very few priority reasons to use
> Debian, or?
>
> So, is this a bug and apt in the past managed the packages thoroughly,
> or am I simply missing the correct way how to test-install and purge a
> package without manual bumbling?
>
> Asking for enlightenment! Marco
>
>
dialog may be recommended by another package, in which case apt won't
remove it automatically.

Re: apt has a bug, cannot believe it!

[The Wanderer]

On 2020-05-25 at 16:04, Marco Möller wrote:

> If installing (default parameters in use: with recommends) a package,
>  and right afterwards removing it, then the by recommendation drawn
> in packages do not become removed automatically. The system is
> swelling with no more wanted packages!

If I'm parsing you correctly: as I understand matters, this is because
for all the package system knows, you might have started using the
previously-Recommended package for some other reason, and removing it
might leave you surprised when that other thing doesn't work anymore.

The solution is to tell apt to remove all automatically-installed
packages that don't have anything depending on them:

$ apt autoremove

You need to run this manually (or explicitly from within a wrapper
script of some kind) after each removal, but that's not a major burden,
and it avoids the "something broke that I didn't realize was installed
as a recommendation" downside from above.

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

apt has a bug, cannot believe it!

[Marco Möller]

If installing (default parameters in use: with recommends) a package, 
and right afterwards removing it, then the by recommendation drawn in 
packages do not become removed automatically. The system is swelling 
with no more wanted packages!
I hope I am simply missing the simple step how to return to the former 
system state after having tested a package. Otherwise this is a bug. To 
me it appears to be a severe bug, as apt is not managing the packages in 
my system as expected.



Commandline: apt install deborphan
Install: deborphan:amd64 (1.7.33), dialog:amd64 (1.3-20190808-1, automatic)

Commandline: apt purge deborphan
Purge: deborphan:amd64 (1.7.33)

apt autoremove
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.


You might argue, that this is easy to solve. In this example, yes, it 
could be solved easily, especially as I remember clearly all the details 
of the screen output from a second ago. But I have tested (and removed) 
packages which drew in many recommended packages some months ago, and 
they are now all leftover in my system!


Even worth, apt is one out of a very few priority reasons to use Debian, or?

So, is this a bug and apt in the past managed the packages thoroughly, 
or am I simply missing the correct way how to test-install and purge a 
package without manual bumbling?


Asking for enlightenment! Marco

Re: bug report

[Celejar]

On Thu, 30 Apr 2020 15:13:29 +0300
deuxb...@gmail.com wrote:

> hello,
> i would like to report a bug on Debian.
> fresh install on my system (Chuwi minibook) - trying to shutdown causes
> reboot (windows works without a problem).

Thank you! Please use the reportbug' tool:

https://www.debian.org/Bugs/Reporting

Celejar

bug report

[deuxbina]

hello,
i would like to report a bug on Debian.
fresh install on my system (Chuwi minibook) - trying to shutdown causes
reboot (windows works without a problem).

thank you

Re: Question regarding an ACPI BIOS Error (bug)

[didier gaumet]

fwupd is worth noting: https://en.wikipedia.org/wiki/Fwupd
and not only does it manage PC firmwares (UEFI) but peripheral cards
firmwares  too

but it is far from widely adopted :-(

Re: Question regarding an ACPI BIOS Error (bug)

[Andrei POPESCU]

On Sb, 28 mar 20, 14:40:54, G.W. Haywood wrote:
> 
> Perhaps you should read
> 
> https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1
> 
> but do please note that this document is out of date - it refers to
> "Stretch" as the stable distribution, instead of "Buster", which has
> been the stable distribustion since July 6th 2019.

If it's just the name of the stable distribution it doesn't matter, the 
general principle is still the same.

Anyway, if you find anything outdated/wrong/missing you could report a 
bug against the 'debian-faq' package. Ideally with a patch ;)

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


signature.asc
Description: PGP signature

Re: Question regarding an ACPI BIOS Error (bug)

[G.W. Haywood]

Hi there,

On Sat, 28 Mar 2020, rba777 wrote:


...
[    0.457794] ACPI BIOS Error (bug): Failure creating named object 
[\_GPE._E4A], AE_ALREADY_EXISTS (20190816/dswload2-323)
[    0.457802] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20190816/psobject-220)
...
Using apt and apt-file, I found numerous packages related to ACPI


Yes, that's to be expected. :)

It's also expected that, at startup, there will be messages logged
about workarounds for known bugs in computer firmware (e.g. BIOS).
Most of the time these messages are benign, and need no action to be
taken by you.  Apart from the existence of these error messages, do
you know that there is some sort of a problem related to the messages?


... I'm running a Debian testing ...


Under most circumstances I advise a stable version, since if you use
other versions then you can almost expect to run into problems, and
you are almost expected to be able to cope with them by yourself.

Perhaps you should read

https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1

but do please note that this document is out of date - it refers to
"Stretch" as the stable distribution, instead of "Buster", which has
been the stable distribustion since July 6th 2019.


... I'm not sure of the package name I should use to report ...


I wonder if the issue is in the BIOS (firmware) in your computer, not
in a Debian package.  In that case you might not need to report it at
all, because it might already have been fixed, or your BIOS might be
obsolete.  UEFI has been relacing BIOS almost everywhere, for several
years, so if it is the latest version, I'd almost expect any BIOS to
be obsolete and therefore not fixable.  What is the computer?  Exactly
what model and version, and roughly how old, is the BIOS?

--

73,
Ged.

Re: Question regarding an ACPI BIOS Error (bug)

[Dan Ritter]

Jude DaShiell wrote: 
> 
> Does any Linux app exist to let systems know when bios updates become
> available for the bios running on those systems?

No. It would require a mechanism supported by each manufacturer,
and they tend not to even be consistent on their own websites.

Server manufacturers sometimes have mailing lists that you can
subscribe to for notifications. 

The best you can do otherwise is find the page for your
motherboard, figure out your current BIOS revision (dmidecode
will help), and then watch it periodically.

That said, once you have everything you care about working,
there's rarely a good reason to upgrade.

-dsr-

Re: Question regarding an ACPI BIOS Error (bug)

[Jude DaShiell]

On Sat, 28 Mar 2020, Darac Marjal wrote:

> Date: Sat, 28 Mar 2020 06:55:55
> From: Darac Marjal 
> To: debian-user@lists.debian.org
> Subject: Re: Question regarding an ACPI BIOS Error (bug)
>
>
> On 28/03/2020 09:35, rba...@protonmail.ch wrote:
> > Hi all, I've been redirected to this list while using reportbug. I
> > would gladly accept some help regarding the determination of the
> > Debian package responsible for those traces during boot:
>
> That would be the kernel itself. The number in square brackets at the
> start of the line is the time (in seconds) since the kernel started. At
> less than a second after startup, you're unlikely to have any user-space
> components loaded yet and, besides, the kernel is what is responsible
> for talking to ACPI.
>
>
> >
> > [??? 0.410073] ACPI: Added _OSI(Processor Device)
> > [??? 0.410073] ACPI: Added _OSI(3.0 _SCP Extensions)
> > [??? 0.410073] ACPI: Added _OSI(Processor Aggregator Device)
> > [??? 0.410073] ACPI: Added _OSI(Linux-Dell-Video)
> > [??? 0.410073] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
> > [??? 0.410073] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
>
> These aren't errors; these ones are just informative.
>
>
> > [??? 0.457794] ACPI BIOS Error (bug): Failure creating named object
> > [\_GPE._E4A], AE_ALREADY_EXISTS (20190816/dswload2-323)
> > [??? 0.457802] ACPI Error: AE_ALREADY_EXISTS, During name
> > lookup/catalog (20190816/psobject-220)
> > [??? 0.457805] ACPI: Skipping parse of AML opcode: OpcodeName
> > unavailable (0x0014)
> > [??? 0.457807] ACPI BIOS Error (bug): Failure creating named object
> > [\_GPE._E47], AE_ALREADY_EXISTS (20190816/dswload2-323)
> > [??? 0.457811] ACPI Error: AE_ALREADY_EXISTS, During name
> > lookup/catalog (20190816/psobject-220)
> > [??? 0.457813] ACPI: Skipping parse of AML opcode: OpcodeName
> > unavailable (0x0014)
>
> These are errors. However, as the message says, these are BIOS errors.
> ACPI machine language (AML) is basically a program inside your BIOS
> which the OS can use to list and control devices. Sometimes these AML
> programs have bugs in them; sometimes they are a little too focussed on
> what Windows likes (rather than what is proper). The generally accepted
> solution to these is: if there is a noticeable issue with your computer
> (some device doesn't work or behaves improperly), then consider a BIOS
> upgrade. Otherwise, if there is no apparent effect, then you can ignore
> these errors.
>
>
> > [??? 0.458226] ACPI: 10 ACPI AML tables successfully acquired and loaded
> > [??? 0.459880] ACPI: EC: EC started
> > [??? 0.459881] ACPI: EC: interrupt blocked
> > [??? 0.461706] ACPI: \: Used as first EC
> > [??? 0.461708] ACPI: \: GPE=0x27, EC_CMD/EC_SC=0x66, EC_DATA=0x62
> > [??? 0.461708] ACPI: EC: Boot ECDT EC used to handle transactions
> >
> > Using apt and apt-file, I found numerous packages related to ACPI and
> > there are also a few kernel modules dedicated to ACPI (in the last
> > case I would say the package is linux-image-5.4.0-4-amd64 version
> > 5.4.19-1 since I'm running a Debian testing) so I'm not sure of the
> > package name I should use to report this issue.
> >
> > Regards,
> >
> > -- Rapha?l BAZAUD
> >
Does any Linux app exist to let systems know when bios updates become
available for the bios running on those systems?
>
>
>

--

Re: Question regarding an ACPI BIOS Error (bug)

[Darac Marjal]

On 28/03/2020 09:35, rba...@protonmail.ch wrote:
> Hi all, I've been redirected to this list while using reportbug. I
> would gladly accept some help regarding the determination of the
> Debian package responsible for those traces during boot:

That would be the kernel itself. The number in square brackets at the
start of the line is the time (in seconds) since the kernel started. At
less than a second after startup, you're unlikely to have any user-space
components loaded yet and, besides, the kernel is what is responsible
for talking to ACPI.


>
> [    0.410073] ACPI: Added _OSI(Processor Device)
> [    0.410073] ACPI: Added _OSI(3.0 _SCP Extensions)
> [    0.410073] ACPI: Added _OSI(Processor Aggregator Device)
> [    0.410073] ACPI: Added _OSI(Linux-Dell-Video)
> [    0.410073] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
> [    0.410073] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)

These aren't errors; these ones are just informative.


> [    0.457794] ACPI BIOS Error (bug): Failure creating named object
> [\_GPE._E4A], AE_ALREADY_EXISTS (20190816/dswload2-323)
> [    0.457802] ACPI Error: AE_ALREADY_EXISTS, During name
> lookup/catalog (20190816/psobject-220)
> [    0.457805] ACPI: Skipping parse of AML opcode: OpcodeName
> unavailable (0x0014)
> [    0.457807] ACPI BIOS Error (bug): Failure creating named object
> [\_GPE._E47], AE_ALREADY_EXISTS (20190816/dswload2-323)
> [    0.457811] ACPI Error: AE_ALREADY_EXISTS, During name
> lookup/catalog (20190816/psobject-220)
> [    0.457813] ACPI: Skipping parse of AML opcode: OpcodeName
> unavailable (0x0014)

These are errors. However, as the message says, these are BIOS errors.
ACPI machine language (AML) is basically a program inside your BIOS
which the OS can use to list and control devices. Sometimes these AML
programs have bugs in them; sometimes they are a little too focussed on
what Windows likes (rather than what is proper). The generally accepted
solution to these is: if there is a noticeable issue with your computer
(some device doesn't work or behaves improperly), then consider a BIOS
upgrade. Otherwise, if there is no apparent effect, then you can ignore
these errors.


> [    0.458226] ACPI: 10 ACPI AML tables successfully acquired and loaded
> [    0.459880] ACPI: EC: EC started
> [    0.459881] ACPI: EC: interrupt blocked
> [    0.461706] ACPI: \: Used as first EC
> [    0.461708] ACPI: \: GPE=0x27, EC_CMD/EC_SC=0x66, EC_DATA=0x62
> [    0.461708] ACPI: EC: Boot ECDT EC used to handle transactions
>
> Using apt and apt-file, I found numerous packages related to ACPI and
> there are also a few kernel modules dedicated to ACPI (in the last
> case I would say the package is linux-image-5.4.0-4-amd64 version
> 5.4.19-1 since I'm running a Debian testing) so I'm not sure of the
> package name I should use to report this issue.
>
> Regards,
>
> -- Raphaël BAZAUD
>




signature.asc
Description: OpenPGP digital signature

Question regarding an ACPI BIOS Error (bug)

[rba777]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all, I've been redirected to this list while using reportbug. I would gladly 
accept some help regarding the determination of the Debian package responsible 
for those traces during boot:

[    0.410073] ACPI: Added _OSI(Processor Device)
[    0.410073] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.410073] ACPI: Added _OSI(Processor Aggregator Device)
[    0.410073] ACPI: Added _OSI(Linux-Dell-Video)
[    0.410073] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[    0.410073] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[    0.457794] ACPI BIOS Error (bug): Failure creating named object 
[\_GPE._E4A], AE_ALREADY_EXISTS (20190816/dswload2-323)
[    0.457802] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20190816/psobject-220)
[    0.457805] ACPI: Skipping parse of AML opcode: OpcodeName unavailable 
(0x0014)
[    0.457807] ACPI BIOS Error (bug): Failure creating named object 
[\_GPE._E47], AE_ALREADY_EXISTS (20190816/dswload2-323)
[    0.457811] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20190816/psobject-220)
[    0.457813] ACPI: Skipping parse of AML opcode: OpcodeName unavailable 
(0x0014)
[    0.458226] ACPI: 10 ACPI AML tables successfully acquired and loaded
[    0.459880] ACPI: EC: EC started
[    0.459881] ACPI: EC: interrupt blocked
[    0.461706] ACPI: \: Used as first EC
[    0.461708] ACPI: \: GPE=0x27, EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    0.461708] ACPI: EC: Boot ECDT EC used to handle transactions

Using apt and apt-file, I found numerous packages related to ACPI and there are 
also a few kernel modules dedicated to ACPI (in the last case I would say the 
package is linux-image-5.4.0-4-amd64 version 5.4.19-1 since I'm running a 
Debian testing) so I'm not sure of the package name I should use to report this 
issue.

Regards,

-- Raphaël BAZAUD
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsFcBAEBCAAGBQJefxpXAAoJEOzVCCaRTXlv8HgP/RCnoM8yhXI7QVnLbPVZ
fgLMose7xgTWVGPGyaktkzCtj6VQ9zb6wk2jQcd39ARgbIKHmjHmZ7k4usCh
7MLqRnn6+k4K6gJJzhT9IV4zBA50ttdvXdzAkFeHGh5sOSMXiNkMGfiZ9SDO
K94ZbYR5DZ0nW98Ql9/2O5nLZtEBvz2RPehaiKVak0F+ldms+5p5Ha82iemL
NlvTqpQ75UbYFi5PH+7e0b79G9LED394fEdzBTYbQWYvsnLu2odW8BW7FV+I
jo1rMg28tMyJeRKNtjcR8Kcjn3FlPPHq0VCj+YwLLkHlo0UYKVoktsRyBpSC
edyWZ8pa+/oIJw+foCKL6OrkODqw3kgFvq4t/TAZpW8VpN6mZ2wsa1TTOYbk
vg793H1LSTEwcHldI96OzS06fe/CDBmTlQUjF2eB44IhJ7hPhiDxvxkLfVyc
Lo2TzKzjbivPVBPyQ/hk7jX4f9CydB5Hcf+ox+48pjBqqqrkr3mewPwYzZJF
peLkuRrTLv/VnLUlA8UC/M6+4PoCXyfnykC1Hyh4wecxjEkpsW+GEji8g9Nx
e8yKbdtJOgHu8wCZ0YzxpKb4qc5NE/m+bA4vWmHeIthBbAHS3h2/R84djN08
kNlGcBbkKia1tHNExraAIFf18hpYw79jOutV8sX5m/Mxs9/s/L7FpWic09kN
aOxw
=Pksl
-END PGP SIGNATURE-

Re: Re: Bug#522358: AIGLX error: dlopen of /usr/lib/dri/swrast_dri.sofailed

[呆呆]

possible BUG: gnome freeze for a wile every some minutes

[Eri]

Hi,
I'm having a problem after an update some weeks ago, every few minutes the
pc is freezing for a while and after it recover, it seem to be the same as
writte on this:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861294
I'm getting also the same errors:
[50928.830285] GpuWatchdog[27129]: segfault at 0 ip 55622c3b4fa2 sp
7f337299d4c0 error 6 in chrome[55622846e000+7287000]
[50928.830296] Code: 83 c3 e8 75 e9 41 8b 85 00 01 00 00 85 c0 0f 84 99 00
00 00 48 8d 3d f3 60 4b fb be 01 00 00 00 ba 03 00 00 00 e8 be 17 a6 fe
 04 25 00 00 00 00 37 13 00 00 c6 05 fc 76 b9 03 01 80 7d 8f 00

I'm using
Linux moleub 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64
GNU/Linux
on
Debian GNU/Linux bullseye/sid \n \l
I would like to report a possible bug but I don't know on which package and
how to do, as this freezing happens also if chrome is not running.
Thanks
Enrico Maria

Re: [OT] JFYI: Lets Encrypt CAA bug, how to check certificate

[Nate Bargmann]

Thanks for passing that along,  Didar.  It shows my cert is OK as well.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

[OT] JFYI: Lets Encrypt CAA bug, how to check certificate

[Didar Hossain]

Hi,

This post is informational:

Lets Encrypt discovered a bug in their CA software (boulder) related to CAA
checking code. They have decided to revoke a subset of certificates issued on
March 4, 2020.

More information:
https://arstechnica.com/information-technology/2020/03/lets-encrypt-revoking-https-certs-due-to-certificate-authority-bug/

If you are using letsencrypt certificate(s) as I am, here is a way to check
whether you are affected -

curl -d 'fqdn=example.com' https://unboundtest.com/caaproblem/checkhost

* replace "example.com" with your own domain(s).

Found the helpful command from the comments on slashdot about this issue.

Kind regards,
Didar

-- 
The odds are a million to one against your being one in a million.

Re: How to report bug / enhancement request for official debian docker image

[tomas]

On Mon, Mar 02, 2020 at 01:14:59PM +1030, heman wrote:
> hi Tomas, thanks for the response, pretty sure the docker image was the 
> official debian:buster from dockerhub. I'll double check.
> 
> I hadn't thought of looking for an issue reporting link on dockerhub, as I 
> figured it would be part of the main Debian product, however indeed the page 
> for the Debian image has provided me a link to the git repo for reporting 
> issues, which seems to be:
>  https://github.com/debuerreotype/docker-debian-artifacts/issues
> 
> thanks again, I'll file an enhancement request there

Glad I could be of help -- and thanks for reporting the
issue :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: How to report bug / enhancement request for official debian docker image

[Jonathan Dowland]

On Sun, Feb 23, 2020 at 11:40:36PM +1030, heman wrote:

I've read https://www.debian.org/Bugs/Reporting
but it is still completely unclear to me how I can report what I
consider to be a bug or flaw with the debian docker image, as it is
not a package, but a container image created from multiple packages.


If you mean this one <https://hub.docker.com/_/debian>
(i.e. what docker gives you if you do "docker pull debian…")

Then the correct place to file issues is
<https://github.com/debuerreotype/docker-debian-artifacts/issues>

The maintainer is aware the package is missing; c.f.
<https://github.com/debuerreotype/docker-debian-artifacts/issues/37>
and
<https://github.com/debuerreotype/docker-debian-artifacts/issues/36#issuecomment-385336558>
although reading those I don't think they've clearly ruled out including
it. You could file a new issue or pull request to add it.

And it seems netbase is indeed not present in any of the Debian images,
going by the metadata in


--
👱🏻  Jonathan Dowland
🔗   https://jmtd.net

Re: How to report bug / enhancement request for official debian docker image

[tomas]

On Sun, Feb 23, 2020 at 11:40:36PM +1030, heman wrote:
> Hi,
> 
> I've read https://www.debian.org/Bugs/Reporting
> but it is still completely unclear to me how I can report what I
> consider to be a bug or flaw with the debian docker image [...]

That depends on where you got this Debian docker image from. I think
the relevant address for those bug reports is more that way?

Cheers
-- t


signature.asc
Description: Digital signature

How to report bug / enhancement request for official debian docker image

[heman]

Hi,

I've read https://www.debian.org/Bugs/Reporting
but it is still completely unclear to me how I can report what I
consider to be a bug or flaw with the debian docker image, as it is
not a package, but a container image created from multiple packages.
(from reading the page at the above URL it would seem you don't have
anything like bugzilla and I need to use the reportbug tool and file
a bug against a specific package).

The root of the problem that I'm trying to report is that the debian
docker image (for buster) seems to be missing the 'netbase' package,
which is almost a critical package, as it provides /etc/services and
/etc/protocols (and nothing else). This package is tiny and is essential
for system routines such as 'getprotobyname' to function.

For example, the tiger vncserver package uses getprotobyname and fails
to open a listening tcp socket if the netbase package is not installed.
I could file a bug against the tiger vncserver standalone package,
however in my opinion this missing dependency has highlighted a bigger
problem with the debian docker image, as /etc/services and
/etc/protocols should be included by any base image!

The cost of adding this package to the base image is extremely minimal,
as it basically provides 3 tiny system files,
/etc/protocols, /etc/services, and /etc/rpc (plus a changelog, copyright
file and so on)

Please advise on where/how I can submit a bug report / feature request
for getting the 'netbase' package included in the official debian docker
image.

cheers

Bug #949471 --- help needed to figure which component it is in

[Chris Ward]

Please take a look at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949471 . I have 
reported it as a bug in open-infrastructure-system-build , but I don't 
think the problem is in this component; I think the problem is in one of 
the components that it installs ( maybe ca-certificates ) . Please help 
by diagnosing which component has the bug and reassign the bug to that 
component. There should be sufficient information in 
http://tjcw.freeshell.org/oisb-fail/ to make progress.


--
Chris Ward

Re: hdd partition alignment parted vs fdisk, partition 1 does not start on physical sector boundary, parted bug?

[Toni Mas]

I could be an offset defined.
Could you post following files?

/sys/block/sdd/queue/optimal_io_size
/sys/block/sdd/queue/minimum_io_size
/sys/block/sdd/alignment_offset
/sys/block/sdd/queue/physical_block_size
/sys/block/sdd/queue/logical_block_size






Toni Mas

Missatge de Sergey Spiridonov  del dia dc., 4 de des.
2019 a les 13:30:
>
> Hi all
>
> I am trying to partition 14TB HDD and get the following problem with an
> alignment:
>
> # hdparam -I /dev/sdd tells that
>
> Logical  Sector size:   512 bytes
> Physical Sector size:  4096 bytes
>
>
> # parted -a opt /dev/sdd
>
> (parted) mkpart primary 0% 100%
> ...
>
> (parted) print
>
> Number  Start   End SizeFile system  Name Flags
>  1  33,6MB  14,0TB  14,0TB   primary
>
> Now checking alignment:
>
> (parted) align-check opt
> 1 1 aligned
>
>
> So far, so good. Now let's look at the same disk with fdisk:
>
> # fdisk /dev/sdd
>
> : p
>
> Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors
> Disk model: IB-366StU3+B
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
> Disklabel type: gpt
> Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26
>
> Device Start End Sectors  Size Type
> /dev/sdd1  65535 27344740889 27344675355 12,8T Linux filesystem
>
> Partition 1 does not start on physical sector boundary.
>
>
> What? Why?
>
>
> man parted tells that
>
>optimal
>   Use optimum alignment as given by the disk
>   topology  in‐ formation.  This  aligns  to  a
>   multiple of the physical block size in a way that
>   guarantees optimal performance
>
>
> 1. Probably parted detected physical sector size as 512
> instead of 4096? Why?
>
> 2. Even if parted thinks that physical sector is 512 instead of
> 4096, why start from 65535 and not from 65536? What is the logic
> behind? How using odd multiplier can improve performance?
>
> Is it a bug in parted or I am missing something?
> --
> Best regards, Sergey Spiridonov
>
>
>

Re: hdd partition alignment parted vs fdisk, partition 1 does not start on physical sector boundary, parted bug?

[David Wright]

On Wed 04 Dec 2019 at 13:15:51 (+0100), Sergey Spiridonov wrote:
> I am trying to partition 14TB HDD and get the following problem with an 
> alignment:
> 
> # hdparam -I /dev/sdd tells that 
> 
>   Logical  Sector size:   512 bytes
>   Physical Sector size:  4096 bytes
> 
> # parted -a opt /dev/sdd
> 
> (parted) mkpart primary 0% 100%
> ...
> (parted) print 
> 
> Number  Start   End SizeFile system  Name Flags
>  1  33,6MB  14,0TB  14,0TB   primary
> 
> Now checking alignment:
> 
> (parted) align-check opt
> 1 1 aligned
> 
> So far, so good. Now let's look at the same disk with fdisk:
> 
> # fdisk /dev/sdd
> : p
> 
> Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors
> Disk model: IB-366StU3+B
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
> Disklabel type: gpt
> Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26
> 
> Device Start End Sectors  Size Type
> /dev/sdd1  65535 27344740889 27344675355 12,8T Linux filesystem
> 
> Partition 1 does not start on physical sector boundary.
> 
> What? Why?
> man parted tells that
> 
>optimal
>   Use optimum alignment as given by the disk
>   topology  in‐ formation.  This  aligns  to  a
>   multiple of the physical block size in a way that
>   guarantees optimal performance
> 
> 1. Probably parted detected physical sector size as 512
> instead of 4096? Why?
> 
> 2. Even if parted thinks that physical sector is 512 instead of
> 4096, why start from 65535 and not from 65536? What is the logic
> behind? How using odd multiplier can improve performance?
> 
> Is it a bug in parted or I am missing something?

Bug #923561 has a long discussion about alignment and optimal transfer
size, and it would appear to be a bit of a mess, with no conclusion on
the root cause of the problem, how to document it, or which software
should deal with it (as best I can understand it).

I think the straightforward way of coping with this is to use the
"unit s" command (so that sectors are the default unit), and then
create the partition with something like:
(parted) mkpart primary 2048s 100%
ie give an explicit alignment.

(I've always used gdisk for creating partitions ever since GPT disks
came on the scene, worked in sectors, and relied on gdisk to calculate
the last sector number.)

Regardless of the partitioning, I see messages like:
Optimal transfer size 33553920 bytes not a multiple of physical block size 
(2048 bytes)
Optimal transfer size 33553920 bytes not a multiple of physical block size 
(4096 bytes)
Optimal transfer size 268431360 bytes not a multiple of physical block size 
(16384 bytes)
in the kernel log when I plug some of my disks in. Adding to the
mystery, the first two messages quoted here were given by the same
1TB disk. fdisk agrees with 4096 as the physical block size.
This leads me to ignore the transfer size, let alone calculate
anything from it.

Cheers,
David.

Re: hdd partition alignment parted vs fdisk, partition 1 does not start on physical sector boundary, parted bug?

[Pascal Hambourg]

Le 04/12/2019 à 13:15, Sergey Spiridonov a écrit :


Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26

Device Start End Sectors  Size Type
/dev/sdd1  65535 27344740889 27344675355 12,8T Linux filesystem

Partition 1 does not start on physical sector boundary.

What? Why?


Probably because of the reported "optimal" I/O size.
65535 * 512 = 33553920

Don't know where this value is taken from.

Re: Bug - but where

[Felix Miata]

Kamil Jońca composed on 2019-11-27 22:31 (UTC+0100):

>...X.org 1.20.4 driver: modesetting... 

To switch to nouveau from modesetting could be as simple as installing
xserver-xorg-video-nouveau. If it's already installed, you may need to specify 
it
in /etc/X11/xorg.conf.d/50-device.conf to contain as follows and restarting X:

Section "Device"
Identifier "DefaultDevice"
driver  "nouveau"
EndSection

If it doesn't help you might want to ask on the nouveau mailing list:
https://lists.freedesktop.org/mailman/listinfo/nouveau

If you do, give https://01.org/linuxgraphics/documentation/how-report-bugs a 
read
first. Maybe it's worth trying IceWM or other WM before.
-- 
Evolution as taught in public schools is religion, not science.

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

Felix Miata  ***  http://fm.no-ip.com/

Re: Bug - but where

[Kamil Jońca]

Felix Miata  writes:

> Kamil Jońca composed on 2019-11-27 21:35 (UTC+0100):
>
>> Felix Miata writes:
>  
>>> Kamil Jońca composed on 2019-11-27 19:23 (UTC+0100):
>>  
 There is debian box
>
>>> Which Debian version?
>  
>> sid.
>
> I don't have Sid on my box with G84.
> ...
>>> # inxi -V | head -n1
>>> inxi 3.0.37-00 (2019-11-19)
>>> # inxi -GxxSM
> ...
>>> Graphics:  ...
>>>Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: 
>>> fbdev,vesa resolution: 1920x1200~60Hz
>
>>> Which DDX are you using? If nouveau, try switching to modesetting. If 
>>> modesetting,
>
>> How to check it?
>
> As shown above, inxi -G reports it. egrep -i 'eset\(|veau\(' 
> /var/log/Xorg.0.log
> will show many lines reporting which, if either are in use.

sudo inxi -GxxSM 
System:Host: alfa Kernel: 5.3.11+1+kjonca x86_64 bits: 64 compiler: gcc v: 
9.2.1 Desktop: FVWM 2.6.8 dm: XDM 
   Distro: Debian GNU/Linux bullseye/sid 
Machine:   Type: Desktop System: FUJITSU SIEMENS product: CELSIUS R640 v: N/A 
serial: YKTJ018045 Chassis: type: 6 
Graphics:  Device-1: NVIDIA G84 [GeForce 8600 GT] vendor: eVga.com. driver: 
nouveau v: kernel bus ID: 08:00.0 
   chip ID: 10de:0402 
   Display: server: X.org 1.20.4 driver: modesetting unloaded: 
fbdev,vesa tty: 315x76 
   Message: Advanced graphics data unavailable for root. 

KJ
-- 
http://wolnelektury.pl/wesprzyj/teraz/
Sed quis custodiet ipsos Custodes?
[Who guards the Guardians?]

Re: Bug - but where

[Felix Miata]

Kamil Jońca composed on 2019-11-27 21:35 (UTC+0100):

> Felix Miata writes:
 
>> Kamil Jońca composed on 2019-11-27 19:23 (UTC+0100):
>  
>>> There is debian box

>> Which Debian version?
 
> sid.

I don't have Sid on my box with G84.
...
>> # inxi -V | head -n1
>> inxi 3.0.37-00 (2019-11-19)
>> # inxi -GxxSM
...
>> Graphics:  ...
>>Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: 
>> fbdev,vesa resolution: 1920x1200~60Hz

>> Which DDX are you using? If nouveau, try switching to modesetting. If 
>> modesetting,

> How to check it?

As shown above, inxi -G reports it. egrep -i 'eset\(|veau\(' /var/log/Xorg.0.log
will show many lines reporting which, if either are in use.
-- 
Evolution as taught in public schools is religion, not science.

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

Felix Miata  ***  http://fm.no-ip.com/

Re: Bug - but where

[Kamil Jońca]

Felix Miata  writes:

> Kamil Jońca composed on 2019-11-27 19:23 (UTC+0100):
>  
>> There is debian box
>
> Which Debian version?

sid.

>
>> with:
>> --8<---cut here---start->8---
>> 08:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] 
>> (rev a1)
>> --8<---cut here---end--->8---
>> in it.
>  
>> I have feeling that graphic drivers have bug, but I am not sure:
>> My simple test:
>> ebook-viewer anthing.epub
>
> What provides ebook viewer? aptitude search ebook shows me nothing by that 
> name.

%dpkg -S ebook-viewer|cut -f1 -d":" |sort -u
calibre

>
> ...
>> The same actions on laptops wiht intel graphics are successful.
>  
>> Any hints if this a bug in xserver-xorg-video-nouveau libdrm-nouveau2 or
>> kernel driver? 
>
> No apparent graphics problem with G84 here on Buster:
> # dmesg | grep veau
> [3.335371] fb: switching to nouveaufb from VESA VGA

I can see that  I have no nouveaufb. Hm.

> [3.337938] nouveau :01:00.0: NVIDIA G84 (084200a2)
> [3.452225] nouveau :01:00.0: bios: version 60.84.58.00.11
> [3.474419] nouveau :01:00.0: fb: 512 MiB GDDR3
> [3.605226] nouveau :01:00.0: DRM: VRAM: 512 MiB
> [3.605228] nouveau :01:00.0: DRM: GART: 1048576 MiB
> [3.605231] nouveau :01:00.0: DRM: TMDS table version 2.0
> [3.605233] nouveau :01:00.0: DRM: DCB version 4.0
> [3.605235] nouveau :01:00.0: DRM: DCB outp 00: 02000300 0028
> [3.605236] nouveau :01:00.0: DRM: DCB outp 01: 01000302 00010030
> [3.605238] nouveau :01:00.0: DRM: DCB outp 02: 04011310 0028
> [3.605239] nouveau :01:00.0: DRM: DCB outp 03: 02011312 00010030
> [3.605241] nouveau :01:00.0: DRM: DCB outp 04: 010223f1 00c0c080
> [3.605242] nouveau :01:00.0: DRM: DCB conn 00: 2030
> [3.605243] nouveau :01:00.0: DRM: DCB conn 01: 1130
> [3.605244] nouveau :01:00.0: DRM: DCB conn 02: 0210
> [3.605245] nouveau :01:00.0: DRM: DCB conn 03: 0211
> [3.605247] nouveau :01:00.0: DRM: DCB conn 04: 0213
> [3.607103] nouveau :01:00.0: DRM: failed to create encoder 0/1/0: -19
> [3.607105] nouveau :01:00.0: DRM: TV-1 has no encoders, removing
> [3.608558] nouveau :01:00.0: DRM: MM: using CRYPT for buffer copies
> [3.676852] nouveau :01:00.0: DRM: allocated 1440x900 fb: 0x7, bo 
> (ptrval)
> [3.708441] fbcon: nouveaufb (fb0) is primary device
> [3.863411] nouveau :01:00.0: fb0: nouveaufb frame buffer device
> [3.882487] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on 
> minor 0

My: 
2019-11-24T22:49:41.745477+01:00 alfa kernel: [  117.524335] fbcon: 
nouveaudrmfb (fb0) is primary device
2019-11-24T22:49:41.861473+01:00 alfa kernel: [  117.642247] Console: switching 
to colour frame buffer device 240x67
2019-11-24T22:49:41.865476+01:00 alfa kernel: [  117.644356] nouveau 
:08:00.0: fb0: nouveaudrmfb frame buffer device
2019-11-24T22:49:41.884054+01:00 alfa kernel: [  117.664233] [drm] Initialized 
nouveau 1.3.1 20120801 for :08:00.0 on minor 0

> # inxi -V | head -n1
> inxi 3.0.37-00 (2019-11-19)
> # inxi -GxxSM
> System:Host: big41 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 compiler: gcc 
> v: 8.3.0 Desktop: Trinity R14.0.7 tk: Qt 3.5.0
>wm: Twin dm: TDM Distro: Debian GNU/Linux 10 (buster)
> Machine:   Type: Desktop Mobo: BIOSTAR model: T41 HD v: ' serial: N/A BIOS: 
> American Megatrends v: 080015 date: 09/22/2009
> Graphics:  Device-1: NVIDIA G84 [GeForce 8600 GT] vendor: XFX Pine driver: 
> nouveau v: kernel bus ID: 01:00.0
>chip ID: 10de:0402
>Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: 
> fbdev,vesa resolution: 1920x1200~60Hz
>OpenGL: renderer: NV84 v: 3.3 Mesa 18.3.6 direct render: Yes
>
> Which DE or WM are you using?

fvwm, no desktop environment 
>
> Which DDX are you using? If nouveau, try switching to modesetting. If 
> modesetting,
How to check it?

> Caps went bad on my G84 years ago. I replaced the bad ones, and it has worked 
> fine
> ever since.

I mostly also have no problems, until recently.
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
A beautiful woman is a blessing from Heaven, but a good cigar is a smoke.
-- Kipling

Re: Bug - but where

[Felix Miata]

Kamil Jońca composed on 2019-11-27 19:23 (UTC+0100):
 
> There is debian box

Which Debian version?

> with:
> --8<---cut here---start->8---
> 08:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] 
> (rev a1)
> --8<---cut here---end--->8---
> in it.
 
> I have feeling that graphic drivers have bug, but I am not sure:
> My simple test:
> ebook-viewer anthing.epub

What provides ebook viewer? aptitude search ebook shows me nothing by that name.

...
> The same actions on laptops wiht intel graphics are successful.
 
> Any hints if this a bug in xserver-xorg-video-nouveau libdrm-nouveau2 or
> kernel driver? 

No apparent graphics problem with G84 here on Buster:
# dmesg | grep veau
[3.335371] fb: switching to nouveaufb from VESA VGA
[3.337938] nouveau :01:00.0: NVIDIA G84 (084200a2)
[3.452225] nouveau :01:00.0: bios: version 60.84.58.00.11
[3.474419] nouveau :01:00.0: fb: 512 MiB GDDR3
[3.605226] nouveau :01:00.0: DRM: VRAM: 512 MiB
[3.605228] nouveau :01:00.0: DRM: GART: 1048576 MiB
[3.605231] nouveau :01:00.0: DRM: TMDS table version 2.0
[3.605233] nouveau :01:00.0: DRM: DCB version 4.0
[3.605235] nouveau :01:00.0: DRM: DCB outp 00: 02000300 0028
[3.605236] nouveau :01:00.0: DRM: DCB outp 01: 01000302 00010030
[3.605238] nouveau :01:00.0: DRM: DCB outp 02: 04011310 0028
[3.605239] nouveau :01:00.0: DRM: DCB outp 03: 02011312 00010030
[3.605241] nouveau :01:00.0: DRM: DCB outp 04: 010223f1 00c0c080
[3.605242] nouveau :01:00.0: DRM: DCB conn 00: 2030
[3.605243] nouveau :01:00.0: DRM: DCB conn 01: 1130
[3.605244] nouveau :01:00.0: DRM: DCB conn 02: 0210
[3.605245] nouveau :01:00.0: DRM: DCB conn 03: 0211
[3.605247] nouveau :01:00.0: DRM: DCB conn 04: 0213
[3.607103] nouveau :01:00.0: DRM: failed to create encoder 0/1/0: -19
[3.607105] nouveau :01:00.0: DRM: TV-1 has no encoders, removing
[3.608558] nouveau :01:00.0: DRM: MM: using CRYPT for buffer copies
[3.676852] nouveau :01:00.0: DRM: allocated 1440x900 fb: 0x7, bo 
(ptrval)
[3.708441] fbcon: nouveaufb (fb0) is primary device
[3.863411] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[3.882487] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on 
minor 0
# inxi -V | head -n1
inxi 3.0.37-00 (2019-11-19)
# inxi -GxxSM
System:Host: big41 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 compiler: gcc v: 
8.3.0 Desktop: Trinity R14.0.7 tk: Qt 3.5.0
   wm: Twin dm: TDM Distro: Debian GNU/Linux 10 (buster)
Machine:   Type: Desktop Mobo: BIOSTAR model: T41 HD v: ' serial: N/A BIOS: 
American Megatrends v: 080015 date: 09/22/2009
Graphics:  Device-1: NVIDIA G84 [GeForce 8600 GT] vendor: XFX Pine driver: 
nouveau v: kernel bus ID: 01:00.0
   chip ID: 10de:0402
   Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: 
fbdev,vesa resolution: 1920x1200~60Hz
   OpenGL: renderer: NV84 v: 3.3 Mesa 18.3.6 direct render: Yes

Which DE or WM are you using?

Which DDX are you using? If nouveau, try switching to modesetting. If 
modesetting,
try switching to nouveau. 

Caps went bad on my G84 years ago. I replaced the bad ones, and it has worked 
fine
ever since.
-- 
Evolution as taught in public schools is religion, not science.

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

Felix Miata  ***  http://fm.no-ip.com/

Bug - but where

[Kamil Jońca]

There is debian box with:
--8<---cut here---start->8---
08:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] 
(rev a1)
--8<---cut here---end--->8---
in it.

I have feeling that graphic drivers have bug, but I am not sure:
My simple test:
ebook-viewer anthing.epub

after some page changes I got:
--8<---cut here---start->8---
nouveau: kernel rejected pushbuf: No such file or directory
nouveau: ch10: krec 0 pushes 0 bufs 2 relocs 0
nouveau: ch10: buf  0002 0004 0004 
nouveau: ch10: buf 0001 0006 0004  0004
nouveau: kernel rejected pushbuf: No such file or directory
nouveau: ch10: krec 0 pushes 0 bufs 2 relocs 0
nouveau: ch10: buf  0003 0004 0004 
nouveau: ch10: buf 0001 0006 0004  0004
zsh: segmentation fault  ebook-viewer 
--8<---cut here---end--->8---

dmesg shows:
[245160.258576] nouveau :08:00.0: Xorg[1264]: Unknown handle 0x001d
[245160.258596] nouveau :08:00.0: Xorg[1264]: validate_init
[245160.258598] nouveau :08:00.0: Xorg[1264]: validate: -2
[245162.486435] nouveau :08:00.0: Xorg[1264]: Unknown handle 0x001d
[245162.486443] nouveau :08:00.0: Xorg[1264]: validate_init
[245162.486446] nouveau :08:00.0: Xorg[1264]: validate: -2
[245163.693374] Chrome_InProcGp[137021]: segfault at 8 ip 7fe615c6bafc sp 
7fe5ceffc1e0 error 4 in libdrm_nouveau.so.2.0.0[7fe615c69000+4000]
[245163.693400] Code: b8 02 00 00 00 89 d1 41 56 41 55 49 89 fd 41 54 49 89 f4 
55 89 d5 53 89 d3 48 83 ec 28 83 e5 01 4c 8b 37 4c 8b 7f 48 0f 45 e8 <8b> 7e 08 
45 8b 46 18 89 e8 83 c8 04 f6 c2 02 0f 45 e8 c1 e9 09 83


The same actions on laptops wiht intel graphics are successful.

Any hints if this a bug in xserver-xorg-video-nouveau libdrm-nouveau2 or
kernel driver?
KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/
Hindsight is always 20:20.
-- Billy Wilder

Re: How to report bug

[Hans]

Am Montag, 25. November 2019, 20:07:56 CET schrieb Goran Delcev:
Hi Goran,

this bug is known since almost 2 years. I reported it in the list, sent a 
bugreport tzo 
powerdevil (and askeds the list, which package might be responsible for it), 
but got 
no solution. People told me, the kernel itself is the one, that controls all 
hibernation 
things. However, afaik there are other tools responsible, too (like 
laptop-mode, 
uswsuspm, tuxonice and others).
Hope, someone might helpö you.

Good luck and all the best

Hans
I have a bug to report. I have used reportbug tool, and the tool suggested to 
use 
this mailing list.
The bug is in that system is not waking up from "suspend to RAM". I get black 
screen and I have to do hardware reset. In log files there is nothing that 
could 
suggest what is wrong. Because I don't know in which package the bug is 
occurring 
I am writing to this list.
Thanks.
Goran Delcev






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

Re: Problem to locate bug

[Jonas Smedegaard]

Hi Julian,

Quoting sj...@uranus.uni-freiburg.de (2019-11-21 11:39:14)
> if it (from around June 28th) still matters for somebody: I 
> re-installed my whole system and I couldn't re-recognise the behaviour 
> described. I also can't remember having changed anything in the 
> "deeper settings of the system"…

Thanks for sharing.

In future, however, please strongly consider debbugs to, well, track 
bugs: https://www.debian.org/Bugs/Reporting


Debbugs is kinda designed for that, unlike this mailinglist which is not 
very good for tracking issues and triangulating them with time and 
dependencies and versions and other states.


Thanks for considering, and sincerely hope you enjoy Debian,

 - Jonas

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

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


signature.asc
Description: signature

Re: Problem to locate bug

[sj126]

Hi,
if it (from around June 28th) still matters for somebody: I re-installed my 
whole system and I couldn't re-recognise the behaviour described. I also can't 
remember having changed anything in the "deeper settings of the system"…

However, best regards,
 Julian Schreck
--
> Hi,
> 
> Julian Schreck wrote:
> > I could narrow it down to lxterminal (autostarted),
> 
> You could start another terminal program from the lxterminal and then
> end the lxterminal. (I use "xterm", the old and sparse one.)
> You could also check whether the lxterm menus give you an opportunity
> to disable any fancy dynamic effects.
> 
> 
> > openbox or an automatically started process.
> 
> An automatic process as culprit seems somewhat far-fetched. I understand
> that you do not see a clear time pattern with the system freezes.
> With an automat i'd expect some regularity.
> 
> Did you already find out whether the whole system freezes or whether it's
> only about graphics and/or local user interaction ?
> 
> 
> > Any other advice than changing the window manager
> > (in case that was suggested/your intention)?
> 
> The window manager and its interaction with the system appears as first
> suspect, when i ask the web.
> 
> 
> > description: Desktop Computer
> >description: Motherboard
> >vendor: ASRock
> >product: Z270M Pro4
> > *-display
> > description: VGA compatible controller
> > product: Intel Corporation
> > vendor: Intel Corporation
> 
> ASRock says the mainboard has AMD/ATI "Quad CrossfireX".
> Am i mistaken if i assume that you currently use a plugged-in graphics
> board ?
> 
> 
> Have a nice day :)
> 
> Thomas

Re: debian snort and systemd bug?

[Sven Hartge]

Eero Volotinen  wrote:

> Any clue why systemctl start snort is not running start section of init
> script? (if start is already run once?)

Don't use the snort package from the Debian repository, it is ancient
(last upload was in 2015) and might as well be orphaned or better yet
removed from Debian in its current state.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: debian snort and systemd bug?

[Roberto C . Sánchez]

On Wed, Nov 13, 2019 at 03:23:52PM +0200, Eero Volotinen wrote:
>Hi,
>Any clue why systemctl start snort is not running start section of init
>script? (if start is already run once?)
>For example, if snort daemon is killed then only way to start it is run
>command systemctl restart snort
>    Sounds like a bug?
>Eero

That could be a bug.  On the other hand, "killed" implies that it may
not have had the opportunity to perform a clean shutdown, perhaps
leaving behind a PID file or some other cruft that must be cleaned up
prior to the next start.  I am not specifically familiar with snort, but
the pattern is certainly common enough.

Regards,

-Roberto
-- 
Roberto C. Sánchez

debian snort and systemd bug?

[Eero Volotinen]

Hi,

Any clue why systemctl start snort is not running start section of init
script? (if start is already run once?)

For example, if snort daemon is killed then only way to start it is run
command systemctl restart snort

Sounds like a bug?



Eero

Re: Debian Installer Bug -Wifi driver not installed

[황병희]

Peter Ehlert  writes:

> SOLVED

Thank You Very Much, Peter^^^
(because that is very important part in installing i think)

Sincerely,

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

Re: Debian Installer Bug -Wifi driver not installed

[Peter Ehlert]

SOLVED

add  this to /etc/NetworkManager/NetworkManager.conf
per  bug #835553

 [device]
 wifi.scan-rand-mac-address=no


That worked for me with a Ralink Technology, Corp. RT5370 Wireless
Adapter on Debian Stretch. Thank you very much.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842422#40

On 11/9/19 8:18 AM, Peter Ehlert wrote:
I have a desktop computer running Debian Buster Mate that I want to 
move to a different location and use Wifi.
Using a cheap USB dongle NetworkManager Applet detects the device, 
lets me select from available networks, accepts password, but will not 
connect..and after a few moments it closes..


Thinking the drivers were not installed (user error) I tried a fresh 
Net install alongside.

 firmware-10.1.0-amd64-netinst.iso
I unplugged the ethernet cable was unplugged, the installer detected 
the USB device, install worked as expected.
First boot, again the device is detected with NetworkManager Applet, 
but same thing... will not connect and after a few moments it closes.


I also tried Buster Mate Live.
 debian-live-10.1.0-amd64-mate+nonfree.iso
D-I installer works but the result is the same as the Net installer. 
device detected, but will not connect.

Running a Live session device detected, but will not connect.

Ubuntu Mate works, Linux Mint Mate works.

... I am at a loss of where to begin.




Network:
  Device-1: Intel 82579LM Gigabit Network driver: e1000e
  IF: eno1 state: up speed: 100 Mbps duplex: full mac: 10:60:4b:73:2b:08
  Device-2: Ralink RT5370 Wireless Adapter type: USB driver: rt2800usb
  IF: wlx0013efcc2c72 state: down mac: 2e:be:92:09:c9:f5


System:
  Host: 6300buster Kernel: 4.19.0-6-amd64 x86_64 bits: 64
  Desktop: MATE 1.20.4 Distro: Debian GNU/Linux 10 (buster)
Machine:
  Type: Desktop System: Hewlett-Packard product: HP Compaq Pro 6300 SFF
===
as a reality check I moved the USB Wifi dongle to another machine one 
meter away and it has the same problem

device detected, but will not connect.

System:
  Host: z620-9 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 Desktop: MATE 
1.20.4

  Distro: Debian GNU/Linux 10 (buster)

Re: Debian Installer Bug -Wifi driver not installed

[Jude DaShiell]

On Sat, 9 Nov 2019, Peter Ehlert wrote:

> Date: Sat, 9 Nov 2019 13:28:02
> From: Peter Ehlert 
> To: debian-user@lists.debian.org
> Subject: Re: Debian Installer Bug -Wifi driver not installed
> Resent-Date: Sat,  9 Nov 2019 18:45:09 + (UTC)
> Resent-From: debian-user@lists.debian.org
>
>
> On 11/9/19 9:25 AM, Patrick Bartek wrote:
> > On Sat, 9 Nov 2019 06:16:17 -0800
> > Peter Ehlert  wrote:
> >
> >> I have a desktop computer running Debian Buster Mate that I want to move
> >> to a different location and use Wifi.
> >> Using a cheap USB dongle NetworkManager Applet detects the device, lets
> >> me select from available networks, accepts password, but will not
> >> connect..and after a few moments it closes..
> >>
> >> Thinking the drivers were not installed (user error) I tried a fresh Net
> >> install alongside.
> >>   ?firmware-10.1.0-amd64-netinst.iso
> >> I unplugged the ethernet cable was unplugged, the installer detected the
> >> USB device, install worked as expected.
> >> First boot, again the device is detected with NetworkManager Applet, but
> >> same thing... will not connect and after a few moments it closes.
> >>
> >> I also tried Buster Mate Live.
> >>   ?debian-live-10.1.0-amd64-mate+nonfree.iso
> >> D-I installer works but the result is the same as the Net installer.
> >> device detected, but will not connect.
> >> Running a Live session device detected, but will not connect.
> >>
> >> Ubuntu Mate works, Linux Mint Mate works.
> >>
> >> ... I am at a loss of where to begin.
> >>
> >>
> >>
> >>
> >> Network:
> >>   ? Device-1: Intel 82579LM Gigabit Network driver: e1000e
> >>   ? IF: eno1 state: up speed: 100 Mbps duplex: full mac: 10:60:4b:73:2b:08
> >>   ? Device-2: Ralink RT5370 Wireless Adapter type: USB driver: rt2800usb
> >>   ? IF: wlx0013efcc2c72 state: down mac: 2e:be:92:09:c9:f5
> >>
> >>
> >> System:
> >>   ? Host: 6300buster Kernel: 4.19.0-6-amd64 x86_64 bits: 64
> >>   ? Desktop: MATE 1.20.4 Distro: Debian GNU/Linux 10 (buster)
> >> Machine:
> >>   ? Type: Desktop System: Hewlett-Packard product: HP Compaq Pro 6300 SFF
> >> ===
> >> as a reality check I moved the USB Wifi dongle to another machine one
> >> meter away and it has the same problem
> >> device detected, but will not connect.
> >>
> >> System:
> >>   ? Host: z620-9 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 Desktop: MATE
> >>   1.20.4
> >>   ? Distro: Debian GNU/Linux 10 (buster)
> >>
> > A few months ago I had to do the same thing -- switch from wired to
> > wireless on this box that only had ever run wired -- but with Stretch.
> > Since I don't run a desktop environment (window manager only Openbox)
> > and sysvinit instead of systemd, I did the configuration manually.  I
> > didn't need a network config tool as I would only be connecting to one
> > wireless (and only one) access point.
> >
> > Have you installed wpa supplicant?  And is it configured properly?
> wpasupplicant is installed
> >
> > Have you installed the firmware for your particular USB dongle? As
> > you're using a ralink device, it will be named firmware-ralink or
> > something similar. It's in the non-free repo.
> firmware-ralink is installed
> > Check /etc/network/interfaces and /etc/NetworkManager/  Is all
> > configured properly?
> I will review, but don't have much of an idea what the configurations should
> be
> >
> > Read the man pages for interfaces, wpa_supplicant, etc.  Also Debian
> > does have wikis on configuring wireless.
> thanks, I will work on understanding that too
> >
> > B
> >
Check version numbers on network manager packages on all three of these
systems.  It could be you need to wait for debian to update network
manager so its version number matches linux mint mate and ubuntu mate.

> >
> > >
>

--

Re: Debian Installer Bug -Wifi driver not installed

[Peter Ehlert]

On 11/9/19 9:25 AM, Patrick Bartek wrote:

On Sat, 9 Nov 2019 06:16:17 -0800
Peter Ehlert  wrote:


I have a desktop computer running Debian Buster Mate that I want to move
to a different location and use Wifi.
Using a cheap USB dongle NetworkManager Applet detects the device, lets
me select from available networks, accepts password, but will not
connect..and after a few moments it closes..

Thinking the drivers were not installed (user error) I tried a fresh Net
install alongside.
   firmware-10.1.0-amd64-netinst.iso
I unplugged the ethernet cable was unplugged, the installer detected the
USB device, install worked as expected.
First boot, again the device is detected with NetworkManager Applet, but
same thing... will not connect and after a few moments it closes.

I also tried Buster Mate Live.
   debian-live-10.1.0-amd64-mate+nonfree.iso
D-I installer works but the result is the same as the Net installer.
device detected, but will not connect.
Running a Live session device detected, but will not connect.

Ubuntu Mate works, Linux Mint Mate works.

... I am at a loss of where to begin.




Network:
    Device-1: Intel 82579LM Gigabit Network driver: e1000e
    IF: eno1 state: up speed: 100 Mbps duplex: full mac: 10:60:4b:73:2b:08
    Device-2: Ralink RT5370 Wireless Adapter type: USB driver: rt2800usb
    IF: wlx0013efcc2c72 state: down mac: 2e:be:92:09:c9:f5


System:
    Host: 6300buster Kernel: 4.19.0-6-amd64 x86_64 bits: 64
    Desktop: MATE 1.20.4 Distro: Debian GNU/Linux 10 (buster)
Machine:
    Type: Desktop System: Hewlett-Packard product: HP Compaq Pro 6300 SFF
===
as a reality check I moved the USB Wifi dongle to another machine one
meter away and it has the same problem
device detected, but will not connect.

System:
    Host: z620-9 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 Desktop: MATE 1.20.4
    Distro: Debian GNU/Linux 10 (buster)


A few months ago I had to do the same thing -- switch from wired to
wireless on this box that only had ever run wired -- but with Stretch.
Since I don't run a desktop environment (window manager only Openbox)
and sysvinit instead of systemd, I did the configuration manually.  I
didn't need a network config tool as I would only be connecting to one
wireless (and only one) access point.

Have you installed wpa supplicant?  And is it configured properly?

wpasupplicant is installed


Have you installed the firmware for your particular USB dongle? As
you're using a ralink device, it will be named firmware-ralink or
something similar. It's in the non-free repo.

firmware-ralink is installed

Check /etc/network/interfaces and /etc/NetworkManager/  Is all
configured properly?
I will review, but don't have much of an idea what the configurations 
should be


Read the man pages for interfaces, wpa_supplicant, etc.  Also Debian
does have wikis on configuring wireless.

thanks, I will work on understanding that too


B

Re: Debian Installer Bug -Wifi driver not installed

[Patrick Bartek]

On Sat, 9 Nov 2019 06:16:17 -0800
Peter Ehlert  wrote:

> I have a desktop computer running Debian Buster Mate that I want to move 
> to a different location and use Wifi.
> Using a cheap USB dongle NetworkManager Applet detects the device, lets 
> me select from available networks, accepts password, but will not 
> connect..and after a few moments it closes..
> 
> Thinking the drivers were not installed (user error) I tried a fresh Net 
> install alongside.
>   firmware-10.1.0-amd64-netinst.iso
> I unplugged the ethernet cable was unplugged, the installer detected the 
> USB device, install worked as expected.
> First boot, again the device is detected with NetworkManager Applet, but 
> same thing... will not connect and after a few moments it closes.
> 
> I also tried Buster Mate Live.
>   debian-live-10.1.0-amd64-mate+nonfree.iso
> D-I installer works but the result is the same as the Net installer. 
> device detected, but will not connect.
> Running a Live session device detected, but will not connect.
> 
> Ubuntu Mate works, Linux Mint Mate works.
> 
> ... I am at a loss of where to begin.
> 
> 
> 
> 
> Network:
>    Device-1: Intel 82579LM Gigabit Network driver: e1000e
>    IF: eno1 state: up speed: 100 Mbps duplex: full mac: 10:60:4b:73:2b:08
>    Device-2: Ralink RT5370 Wireless Adapter type: USB driver: rt2800usb
>    IF: wlx0013efcc2c72 state: down mac: 2e:be:92:09:c9:f5
> 
> 
> System:
>    Host: 6300buster Kernel: 4.19.0-6-amd64 x86_64 bits: 64
>    Desktop: MATE 1.20.4 Distro: Debian GNU/Linux 10 (buster)
> Machine:
>    Type: Desktop System: Hewlett-Packard product: HP Compaq Pro 6300 SFF
> ===
> as a reality check I moved the USB Wifi dongle to another machine one 
> meter away and it has the same problem
> device detected, but will not connect.
> 
> System:
>    Host: z620-9 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 Desktop: MATE 1.20.4
>    Distro: Debian GNU/Linux 10 (buster)
> 

A few months ago I had to do the same thing -- switch from wired to
wireless on this box that only had ever run wired -- but with Stretch.
Since I don't run a desktop environment (window manager only Openbox)
and sysvinit instead of systemd, I did the configuration manually.  I
didn't need a network config tool as I would only be connecting to one
wireless (and only one) access point.

Have you installed wpa supplicant?  And is it configured properly?

Have you installed the firmware for your particular USB dongle? As
you're using a ralink device, it will be named firmware-ralink or
something similar. It's in the non-free repo.

Check /etc/network/interfaces and /etc/NetworkManager/  Is all
configured properly?

Read the man pages for interfaces, wpa_supplicant, etc.  Also Debian
does have wikis on configuring wireless.

B 

Debian Installer Bug -Wifi driver not installed

[Peter Ehlert]

I have a desktop computer running Debian Buster Mate that I want to move 
to a different location and use Wifi.
Using a cheap USB dongle NetworkManager Applet detects the device, lets 
me select from available networks, accepts password, but will not 
connect..and after a few moments it closes..


Thinking the drivers were not installed (user error) I tried a fresh Net 
install alongside.

 firmware-10.1.0-amd64-netinst.iso
I unplugged the ethernet cable was unplugged, the installer detected the 
USB device, install worked as expected.
First boot, again the device is detected with NetworkManager Applet, but 
same thing... will not connect and after a few moments it closes.


I also tried Buster Mate Live.
 debian-live-10.1.0-amd64-mate+nonfree.iso
D-I installer works but the result is the same as the Net installer. 
device detected, but will not connect.

Running a Live session device detected, but will not connect.

Ubuntu Mate works, Linux Mint Mate works.

... I am at a loss of where to begin.




Network:
  Device-1: Intel 82579LM Gigabit Network driver: e1000e
  IF: eno1 state: up speed: 100 Mbps duplex: full mac: 10:60:4b:73:2b:08
  Device-2: Ralink RT5370 Wireless Adapter type: USB driver: rt2800usb
  IF: wlx0013efcc2c72 state: down mac: 2e:be:92:09:c9:f5


System:
  Host: 6300buster Kernel: 4.19.0-6-amd64 x86_64 bits: 64
  Desktop: MATE 1.20.4 Distro: Debian GNU/Linux 10 (buster)
Machine:
  Type: Desktop System: Hewlett-Packard product: HP Compaq Pro 6300 SFF
===
as a reality check I moved the USB Wifi dongle to another machine one 
meter away and it has the same problem

device detected, but will not connect.

System:
  Host: z620-9 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 Desktop: MATE 1.20.4
  Distro: Debian GNU/Linux 10 (buster)

Debian Installer Bug -Wifi driver not installed

[Peter Ehlert]

I have a desktop computer running Debian Buster Mate that I want to move 
to a different location and use Wifi.
Using a cheap USB dongle NetworkManager Applet detects the device, lets 
me select from available networks, accepts password, but will not 
connect..and after a few moments it closes..


Thinking the drivers were not installed (user error) I tried a fresh Net 
install alongside.

 firmware-10.1.0-amd64-netinst.iso
I unplugged the ethernet cable was unplugged, the installer detected the 
USB device, install worked as expected.
First boot, again the device is detected with NetworkManager Applet, but 
same thing... will not connect and after a few moments it closes.


I also tried Buster Mate Live.
 debian-live-10.1.0-amd64-mate+nonfree.iso
D-I installer works but the result is the same as the Net installer. 
device detected, but will not connect.

Running a Live session device detected, but will not connect.

Ubuntu Mate works, Linux Mint Mate works.

... I am at a loss of where to begin.




Network:
  Device-1: Intel 82579LM Gigabit Network driver: e1000e
  IF: eno1 state: up speed: 100 Mbps duplex: full mac: 10:60:4b:73:2b:08
  Device-2: Ralink RT5370 Wireless Adapter type: USB driver: rt2800usb
  IF: wlx0013efcc2c72 state: down mac: 2e:be:92:09:c9:f5


System:
  Host: 6300buster Kernel: 4.19.0-6-amd64 x86_64 bits: 64
  Desktop: MATE 1.20.4 Distro: Debian GNU/Linux 10 (buster)
Machine:
  Type: Desktop System: Hewlett-Packard product: HP Compaq Pro 6300 SFF
===
as a reality check I moved the USB Wifi dongle to another machine one 
meter away and it has the same problem

device detected, but will not connect.

System:
  Host: z620-9 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 Desktop: MATE 1.20.4
  Distro: Debian GNU/Linux 10 (buster)

Re: Is it a bug that the iptable_filter module isn't loaded automatically with Debian 10 iptables-nft?

[Pascal Hambourg]

Le 28/10/2019 à 09:14, Andy Smith a écrit :


I will take a guess that the switching of the iptables commands to
use the nftables framework has somehow caused this iptable_filter
module to not be loaded even though the firewall still works.


Correct.


Is it a bug that loading rules into the filter table using
iptables-nft command (actually called as "iptables" due to
alternatives) no longer causes iptable_filter module to be loaded
and thus "filter" to appear in /proc/net/ip_tables_names?


No, it is expected. iptable_* modules and /proc/net/ip_tables_names are 
part of the iptables framework. But iptables-nft uses the nftables 
framework (by translating iptables rules into nftables rules).


I understand that a management software using iptables may look up 
/proc/net/ip_tables_names to check whether a tables is active, for 
instance so that it can initialize or list it properly (initializing or 
listing an unused inactive table would needlessly activate it).



Is there a different proc file that will list the active netfilter
tables?


There are no netfilter tables. Tables belong to frameworks running 
inside netfilter such as iptables and nftables.



Is it safe for me to continue forcing the load of the iptable_file
and ip6table_filter modules, or should I stop doing that and seek to
get the management software fixed instead? Though doing that will
need some other way to obtain the same information. >
If it is bad to force load those modules, perhaps I should be using
update-alternatives to go back to using iptables-legacy?


Loading an iptables table makes it process packets needlessly. Also, 
some some iptables extensions are not supported by nftables 
compatibility layer. So yes, IMO you should go back to using 
iptables-legacy, even though I cannot think of any undesirable side 
effect beside performance when the chains are empty with policy ACCEPT.



I am aware that we should be switching to nftables now


IMO there is no hurry yet.

Re: FFADO-mixer does not load - patch to fix bug

[Andrei POPESCU]

On Sb, 14 sep 19, 04:20:42, Yoann LE BARS wrote:
> 
>   Well, I think this patch should probably be added to the package. Can
> anyone tell me what I should do to propose this patch? Should I open a
> bug issue on Debian bug tracker, then send the patch? Should I do
> something else?
 
Yes, attaching the patch to a (new) bug report would be very good.

It's recommended to use reportbug for new bug reports.

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


signature.asc
Description: PGP signature

Re: Workaround for bug #874598 - Ardour: GUI doesn't load

[Andrei POPESCU]

On Sb, 14 sep 19, 04:00:08, Yoann LE BARS wrote:
> 
>   But as it is the first time I propose some workaround to a bug, I want
> to make sure I have done what is needed. So, can anyone confirm my
> message is sufficient of if I should do something more?

Depends on what you mean by "sufficient" ;)

As you might have noticed, your message does show up in the bug log, so 
it is available both for the maintainer (to maybe implement a solution) 
and for other users.

As a next possible step, depending on your skill level and available 
time you could come up with a patch and submit that to the bug as well.

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


signature.asc
Description: PGP signature

Is it a bug that the iptable_filter module isn't loaded automatically with Debian 10 iptables-nft?

[Andy Smith]

Hi,

I noticed a few hours ago that a particular piece of firewall
management software wasn't working correctly with my Debian 10
hosts.

After quite a lot of investigation I worked out that the software in
question was looking at the content of /proc/net/ip_tables_names to
determine the names of the tables that are currently active
('filter', 'mangle', etc).

On my Debian 10 hosts, this file is empty even though they have
active rules loaded by iptables.

I then noticed that on my Debian 9 hosts, the modules iptable_filter
and ip6table_filter are loaded as soon as a rule is added to any of
the chains in the filter table ('INPUT', 'OUTPUT, 'FORWARD').

By manually loading the module iptable_filter on my Debian 10 hosts
I was able to populate the file /proc/net/ip_tables_names with the
active tables ('filter') and the management software works again. I
have for the moment made this change permanent by adding those
modules to a file in /etc/modules-load.d/.

I will take a guess that the switching of the iptables commands to
use the nftables framework has somehow caused this iptable_filter
module to not be loaded even though the firewall still works.

Is it a bug that loading rules into the filter table using
iptables-nft command (actually called as "iptables" due to
alternatives) no longer causes iptable_filter module to be loaded
and thus "filter" to appear in /proc/net/ip_tables_names?

Is there a different proc file that will list the active netfilter
tables?

Is it safe for me to continue forcing the load of the iptable_file
and ip6table_filter modules, or should I stop doing that and seek to
get the management software fixed instead? Though doing that will
need some other way to obtain the same information.

If it is bad to force load those modules, perhaps I should be using
update-alternatives to go back to using iptables-legacy?

I am aware that we should be switching to nftables now, but I have
quite a few servers all managed by config management. As I will need
to switch the method by which I manage the firewalling in the config
management, and don't want to run two different things
simultaneously, I was planning to wait until my oldest hosts have
been upgraded enough and then do them all at once. I don't really
want to starting rewriting the firewalls on older Debian 8 servers
when they should go away within a year anyway.

Cheers,
Andy

potential bug: buster: systemd-networkd not working reliable

[Markus Rathgeb]

Hi,

it seems systemd-networkd of the Buster distribution does not work
reliable on some of my systems.
Can you help me to further analyze the problem in front of bug creation?

Short summary:
If an interface uses static addresses and the cable is unplugged and
plugged in again, the interface does not go up anymore.

Detailed summary:

Architecture: amd64
Kernel: Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28)
x86_64 GNU/Linux
systemd: Version: 241-7~deb10u1

The system contains two ethernet links "enp1s0" and "eno1".
The kernel module used for this interfaces is "igb".

===
Oct 08 09:38:44 sb-0001c0237244 kernel: igb: Intel(R) Gigabit Ethernet
Network Driver - version 5.4.0-k
Oct 08 09:38:44 sb-0001c0237244 kernel: igb: Copyright (c) 2007-2014
Intel Corporation.
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :01:00.0 enp1s0:
renamed from eth0
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :01:00.0: added PHC on enp1s0
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :01:00.0: Intel(R)
Gigabit Ethernet Network Connection
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :01:00.0: enp1s0:
(PCIe:2.5Gb/s:Width x1) 00:01:c0:23:72:44
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :01:00.0: enp1s0: PBA
No: FF-0FF
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :01:00.0: Using MSI-X
interrupts. 2 rx queue(s), 2 tx queue(s)
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :02:00.0 eno1: renamed from eth0
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :02:00.0: added PHC on eno1
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :02:00.0: Intel(R)
Gigabit Ethernet Network Connection
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :02:00.0: eno1:
(PCIe:2.5Gb/s:Width x1) 00:01:c0:23:72:51
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :02:00.0: eno1: PBA
No: FF-0FF
Oct 08 09:38:44 sb-0001c0237244 kernel: igb :02:00.0: Using MSI-X
interrupts. 2 rx queue(s), 2 tx queue(s)
Oct 08 09:38:47 sb-0001c0237244 kernel: igb :01:00.0 enp1s0: igb:
enp1s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Oct 08 09:38:48 sb-0001c0237244 kernel: igb :02:00.0 eno1: igb:
eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
===

The network configuration for "eno1" looks like (10-ethernet-eno1.network)
===
[Match]
Name=eno1

[Network]
DHCP=no
Address=10.10.69.1/24
Address=10.10.69.200/24
Address=10.10.69.201/24
Address=10.10.69.202/24
===

The network configuration for "enp1s0" looks like (10-ethernet-enp1s0.network)
===
[Match]
Name=enp1s0

[Network]
DHCP=ipv4
===

If the network cable on enp1s0 is unplugged the assigned address is
dropped and the interface went down. If the cable is plugged in again,
the interface goes up and requests an address using DHCP.

If the network cable on eno1 is unplugged the assigned addresses are
dropped and the interface went down. If the cable is plugged in again,
the interface does NOT go up but stays down.

I enabled the debug log level for systemd-networkd.
If the cable of eno1 is unplugged I see:
===
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: Flags
change: -LOWER_UP -RUNNING
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: Sent message
type=signal sender=n/a destination=n/a
path=/org/freedesktop/network1/link/_35
interface=org.freedesktop.DBus.Properties member=PropertiesChanged
cookie=37 reply_cookie=0 signature=sa{sv}as error-name=n/a
error-message=n/a
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: Lost carrier
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: NDISC: Stopping
IPv6 Router Solicitation client
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: Removing
address 10.10.69.202
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: Removing
address 10.10.69.200
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: Removing
address 10.10.69.201
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: Removing
address 10.10.69.1
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: State is
configured, dropping config
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: Removing
address: 10.10.69.202/24 (valid forever)
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: Removing
address: 10.10.69.200/24 (valid forever)
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: Removing
address: 10.10.69.201/24 (valid forever)
Oct 08 09:45:26 sb-0001c0237244 systemd-networkd[294]: eno1: Removing
address: 10.10.69.1/24 (valid forever)
===

If the cable is plugged in again, no additional message appears.

Before I updated to Buster I run into this bug:
https://github.com/systemd/systemd/issues/5625
This could be worked around using: "IPv6AcceptRA=no" and
"LinkLocalAddressing=no"
I don't run into this error after updating anymore (it has been about DHCP).
Using that lines (regardless if no or yes is choosen) for the static
interface on Buster does not make any difference, so the 

Debian firmaware bug in graphical installer

[Valerio Pachera]

Hi, I installed Debian 10 on my old laptop (BIOS mode) using the
unsupported firmware iso.
I noticed that using the Graphical installer it fails connecting to the
wifi.
Using the classic ncurses installer, it connects successfully.
I checked also with the latest firmware-10.1.0-amd64-netinst.iso and it
still fails.

This is my wifi network card:

05:00.0 Network controller: Intel Corporation WiFi Link 5100
Subsystem: Intel Corporation WiFi Link 5100 AGN
Flags: bus master, fast devsel, latency 0, IRQ 27
Memory at d810 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-21-6b-ff-ff-0d-19-28
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

The laptop is an Acer Aspire 6935G.

Did any of you experience the same problem?

Re: Bug?

[Thomas H. George]

Yes, I was originally using another desktop, lxde, and switched to 
gnome. Now I can't switch back


On 09/18/2019 08:01 AM, songbird wrote:

Thomas H. George wrote:
...

Two problems after a distribution upgrade to Buster

1. At login window after boot up the desktop selection is locked a
Gnome. That is, if the symbol to change the desktop selection is
selected a list of available desktops is displayed with a dot indicating
Gnome is the current selections. There is no way to move this dot to
another selection. The mouse is frozen and I have tried every key on the
key board.

   are you sure you have yet another desktop installed and
available to select?  you don't mention if you've actually
installed another desktop that should show up in the menu
or not.

   so it may not actually be a bug because there is nothing
else to select.



2. There is no sound. The alsamixer and the Gnome sound tool show only
an HDMI option but my monitor has no speakers. If I reboot to Stretch
there is a line out option and there is sound from my external speakers.

So rebooting to Stretch solves the sound problem but not the desktop
selection problem.

Kernel problem? Gnome problem? Pulseaudio problem?

   i'm not a sound expert by far, so this i will leave for
others to answer/ask about.


   songbird

Re: Bug?

[songbird]

Thomas H. George wrote:
...
> Two problems after a distribution upgrade to Buster
>
> 1. At login window after boot up the desktop selection is locked a 
> Gnome. That is, if the symbol to change the desktop selection is 
> selected a list of available desktops is displayed with a dot indicating 
> Gnome is the current selections. There is no way to move this dot to 
> another selection. The mouse is frozen and I have tried every key on the 
> key board.

  are you sure you have yet another desktop installed and
available to select?  you don't mention if you've actually
installed another desktop that should show up in the menu
or not.

  so it may not actually be a bug because there is nothing
else to select.


> 2. There is no sound. The alsamixer and the Gnome sound tool show only 
> an HDMI option but my monitor has no speakers. If I reboot to Stretch 
> there is a line out option and there is sound from my external speakers.
>
> So rebooting to Stretch solves the sound problem but not the desktop 
> selection problem.
>
> Kernel problem? Gnome problem? Pulseaudio problem?

  i'm not a sound expert by far, so this i will leave for
others to answer/ask about.


  songbird

Bug?

[Thomas H. George]

Two problems after a distribution upgrade to Buster

1. At login window after boot up the desktop selection is locked a 
Gnome. That is, if the symbol to change the desktop selection is 
selected a list of available desktops is displayed with a dot indicating 
Gnome is the current selections. There is no way to move this dot to 
another selection. The mouse is frozen and I have tried every key on the 
key board.


2. There is no sound. The alsamixer and the Gnome sound tool show only 
an HDMI option but my monitor has no speakers. If I reboot to Stretch 
there is a line out option and there is sound from my external speakers.


So rebooting to Stretch solves the sound problem but not the desktop 
selection problem.


Kernel problem? Gnome problem? Pulseaudio problem?

FFADO-mixer does not load - patch to fix bug

[Yoann LE BARS]

Hello everybody out there!

I am using Debian 10:

$ cat /etc/debian_version
10.1

I am using FFADO-mixer from standard distribution repositories:

$ aptitude versions ffado-mixer-qt4
i   2.4.1-0.1 stable
900

I have experimented a bug I have not seen in Debian bug tracker system:
when I tried to launch FFADO-mixer, it failed to load (see log at the
end of this message).

I have asked for help on FFADO mailing list:

https://sourceforge.net/p/ffado/mailman/ffado-user/?viewmonth=201909&viewday=11

Jonathan Whoithe has then sent a patch which solves the problem:

https://sourceforge.net/p/ffado/mailman/message/36760579/

Well, I think this patch should probably be added to the package. Can
anyone tell me what I should do to propose this patch? Should I open a
bug issue on Debian bug tracker, then send the patch? Should I do
something else?

Best regards.

$ ffaddo-mixer-qt4
Traceback (most recent call last):
  File "/usr/share/ffado-mixer-qt4/ffado/import_pyqt.py", line 35, in

from PyQt4.QtCore import QByteArray, QObject, QTimer, Qt,
pyqtSignal, QString, pyqtSlot
ImportError: cannot import name 'QString' from 'PyQt4.QtCore'
(/usr/lib/python3/dist-packages/PyQt4/QtCore.cpython-37m-x86_64-linux-gnu.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/ffado-mixer", line 31, in 
from ffado.ffadowindow import *
  File "/usr/share/ffado-mixer-qt4/ffado/ffadowindow.py", line 27, in

from ffado.config import *
  File "/usr/share/ffado-mixer-qt4/ffado/config.py", line 35, in 
from ffado.import_pyqt import *
  File "/usr/share/ffado-mixer-qt4/ffado/import_pyqt.py", line 39, in

from PyQt5 import QtGui, Qt, QtCore, Qt, QtWidgets, uic
RuntimeError: the PyQt5.QtCore and PyQt4.QtCore modules both wrap the
QObject class

-- 
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org

Workaround for bug #874598 - Ardour: GUI doesn't load

[Yoann LE BARS]

Hello everybody out there!

I am using Debian 10 :

$ cat /etc/debian_version
10.1

I am using Ardour 5 from standard distribution repositories:

$ aptitude versions ardour
i   1:5.12.0-3stable
900

I have experimented bug #874598, i.e. Ardour GUI does not load. I have
asked for help on Ardour forum:

https://discourse.ardour.org/t/no-graphical-interface-with-ardour-5-on-debian-10/101633

It turned out that this bug is a bug from GTK 2. As most developing
efforts from GTK team are on GTK 3 and 4, it seems quite unlikely that
the bug will be solved at all. But there is a quite simple workaround to
this, as indicated on Ardour bug tracker:

https://tracker.ardour.org/view.php?id=5605

It is quite simple. Before running Ardour, you have to set a variable:

$ export GTK2_RC_FILES=/usr/share/themes/Adwaita/gtk-2.0/gtkrc

Then run Ardour. I have tested this, with this workaround Ardour GUI
does load. I have sent a comment to Debian bug tracker for bug #874598 :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874598

But as it is the first time I propose some workaround to a bug, I want
to make sure I have done what is needed. So, can anyone confirm my
message is sufficient of if I should do something more?

Best regards.

-- 
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org

Bug#934203: Please make it easier to trust external repositories without trusting their key for everything else

[Andrei POPESCU]

Package: apt
Severity: wishlist

On Ma, 06 aug 19, 16:22:34, Keith Bainbridge wrote:
> 
> I found a simple guide at
> 
> 
> https://www.linuxbabe.com/debian/install-latest-virtualbox-6-0-10-debian-10-buster
> 
> 
> In summary:
> Create new sources file:
> sudo nano /etc/apt/sources.list.d/oracle-virtualbox.list
> 
> with this text:
> deb https://download.virtualbox.org/virtualbox/debian buster contrib
> 
> 
> Run this command to add key:
> wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo
> apt-key add -
> 
> 
> apt(-get) update
> and install
> apt(-get) install virtualbox-6.0
> 
> This installed Version 6.0.10 r132072 (Qt5.9.5)

This procedure will automatically make the Oracle key trusted for *all* 
configured repositories (notably Debian).

If my reading of sources.list(5) is correct one could store the key in a 
directory that is *not* /etc/apt/trusted.gpg.d/ and use Signed-By in 
sources.list to point apt to the correct key.

Please make this more obvious/easier to setup, e.g. by shipping an 
external.gpg.d/ directory, or making this setup more obvious in the 
manpage.

Another idea would be for apt to consider only repository keys installed 
in a repository-specific location (e.g. path/filename based on 
origin/label/etc.).

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


signature.asc
Description: PGP signature

Re: Possible Bug issues in kernel.

[deloptes]

Reco wrote:

> lsinitramfs /boot/initrd.img* | grep ttf$

Hmm here it does not find anything, but plymouth is in the initram

When looking for ttf
grep
ttf -r /etc/initramfs-tools /usr/share/initramfs-tools/ 
/usr/share/lintian/overrides
/usr/share/initramfs-tools/hooks/plymouth:  if
[ -e /usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf ]

which brings me to the idea that I always wanted to look into this beast a
bit closer

Re: Possible Bug issues in kernel.

[Reco]

On Sun, Jul 28, 2019 at 01:54:01PM +0200, deloptes wrote:
> Reco wrote:
> 
> > plymouth, maybe? You know, that fancy bootloader program?
> 
> yes I know and use it - much better than 80s dos style boot up screen,
> but ... perhaps needs a check out of curiosity.
> 
> Do you know how/where to check this?

I'd start with a straightforward approach:

lsinitramfs /boot/initrd.img* | grep ttf$

Reco

Re: Possible Bug issues in kernel.

[deloptes]

Reco wrote:

> plymouth, maybe? You know, that fancy bootloader program?
> 

yes I know and use it - much better than 80s dos style boot up screen,
but ... perhaps needs a check out of curiosity.

Do you know how/where to check this?

thanks in advance

regards

Re: Possible Bug issues in kernel.

[Reco]

Hi.

On Sun, Jul 28, 2019 at 12:07:33PM +0200, deloptes wrote:
> J.W. Foster wrote:
> 
> > OK I got it sorted out. Seems it was a font issue. i had to install ttf
> > dejavu  and it all installed ok
> 
> Jut curious what a dejavu ttf font might have to do with building initramfs 

plymouth, maybe? You know, that fancy bootloader program?

Reco

Re: Possible Bug issues in kernel.

[deloptes]

J.W. Foster wrote:

> OK I got it sorted out. Seems it was a font issue. i had to install ttf
> dejavu  and it all installed ok

Jut curious what a dejavu ttf font might have to do with building initramfs 

regards

Re: Possible Bug issues in kernel.

[Andy Smith]

Hi,

On Thu, Jul 25, 2019 at 02:55:13AM +, J.W. Foster wrote:
E: initramfs-tools: installed initramfs-tools package post-installation script 
subprocess returned error exit status 1

There can be many reasons why this package's post-installation
script may have failed. I don't think you have shown the full
output.

Running "apt upgrade" again will probably either repeat the action
or tell you what to type to repeat the action, so please do that and
show us the full output.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: How to report a source bug?

[Reco]

Hi.

On Tue, Jul 09, 2019 at 11:17:08AM +0100, Frediano Ziglio wrote:
> But what about a bug in a package packaged in Debian and which you
> manage the sources knowing Debian packaged one has surely a bug and
> you want to report?

reportbug --src 


> What if this is a security bug?

It's outlined at [1], chapter "How can I help with security".

Reco

[1] https://www.debian.org/security/faq