Re: Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Jonathan de Boyne Pollard]

Thorsten Glaser:

> Just accept that this idea, originating from the systemd people at 
Fedora/Freedesktop, is NOT welcome to classical Unix people.


Ahem!  We classical Unix people experienced this idea in the late 1980s, 
from where it *really* originated, Sun and AT


* https://groups.google.com/d/msg/comp.sys.sun/K9286yRtZ8c/Abwzdo05gMMJ

The separate /sbin that you are asserting to be classical Unix and 
suggesting as the place to put things here, actually was not classical 
Unix in the first place.  Sun's Rusty Sandberg is credited with 
inventing the ideas of /var and /sbin which the world gained with SunOS 
4.0 in 1988, a year before AT System 5 Release 4 put it into /usr as 
/usr/sbin with only a symbolic link at /sbin, and two years before 
4.3BSD Reno adopted it in 1990, the BSD world having to that point used 
/etc for such binaries.  Having things in lots of directories under /usr 
(/usr/amdahl/bin, /usr/ucb, /usr/5bin, /usr/3bin, /usr/eun, 
/usr/stanford/bin, /usr/brl, /usr/bbn, /usr/jerq/bin, and so on) 
*pre-dates* the very idea of /sbin on Unix and was how things were for 
most of the 1980s and the 1970s.


* 
https://groups.google.com/d/msg/comp.unix.questions/g9DsvKQx8h8/QNs0F-mHpR4J


* https://unix.stackexchange.com/a/448799/5132

* https://groups.google.com/d/msg/comp.unix.wizards/pLc_jhCUDtU/WD92a732Nx4J

Almost everything in *lots* of pseudo-user directories under /usr was 
the actual classical Unix way.

Bug#132542: Info received (Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian sysvinit maintainers 

If you wish to submit further information on this problem, please
send it to 132...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
132542: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=132542
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Debian Bug Squashing Party (BSP) in Venlo, the Netherlands, 12 and 13 January 2018

[Joost van Baal-Ilić]

Hi,

The Debian Bug Squashing Party earlier this month in Venlo, Netherlands was
productive and fun.  Thanks a lot to Transceptor Technology, part of the
insign.it Group, for hosting[1] us, sponsoring food and being very hospitable
(you might know this company as the people behind the SiriDB[2] time series
database server).

Some of the results:

 Forwarded bugs -- Important bugs (1 bug)

 Pending Upload bugs: 3 bugs
 -- Serious (policy violations or makes package unfit for release) (2 bugs)
 -- Normal bugs (1 bug)
 Resolved bugs: 27 bugs
 -- Grave functionality bugs (1 bug)
 -- Serious (policy violations or makes package unfit for release) (14 bugs)
 -- Important bugs (2 bugs)
 -- Normal bugs (3 bugs)
 -- Wishlist items (7 bugs)

Next to squashing bugs, we spend time discussing upcoming FOSDEM conference in
Brussels, discussing the "Proposal: Repository for fast-paced package
backports" [3], discussing autopkgtest and migrations, and doing some PGP
keysigning.

Participating were Dekkers, elbrus, ivodd, joostvb, mechtilde, michael, Myon,
Natureshadow, stappers, stew and 2 others.

More details at our list of tagged bugs[4], at the wiki[5] and at the gobby
document at gobby.debian.org : BSP/2019/01-Venlo.

Bye,
Joost

[1] 
https://www.insign.it/nieuws/debian-bug-squashing-party-met-transceptor-technology
[2] https://packages.debian.org/siridb-server
[3] 
https://lists.debian.org/msgid-search/20181225204607.gd32...@portux.naturalnet.de
[4] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-rele...@lists.debian.org;tag=bsp-2019-01-nl-venlo
[5] https://wiki.debian.org/BSP/2019/01/nl/Venlo


signature.asc
Description: Digital signature

Re: report bug

[Celejar]

On Fri, 25 Jan 2019 12:59:16 +
Paul Sutton  wrote:

> Hi
> 
> I have set up report-bug however upon running I am informs me that 
> gir1.2-vte-2.91
>  is missing, this is required to run the program with the GUI. 
> 
> I have no problem installing this (and have done) but just thought I
> would mention it.

This is explained in reportbug's "README.Users" file:

> If you tried to set the new GTK+ UI (named in reportbug as gtk2 ui)
> and it fails to start (falling back to text mode, hopefully), chances
> are that you are missing some of the packages listed as Suggests, in
> particular:
> 
>  - python3-gi
>  - python3-gi-cairo
>  - gir1.2-gtk-3.0
>  - gir1.2-vte-2.91
>  - python3-gtkspellcheck
> 
> or, install the reportbug-gtk package to get the needed dependencies.
> 
> If after installing both of them still GTK+ UI doesn't show up, please
> file a report (in text ui :) ).

>  report bug defaults to the CLI version anyway.

Celejar

report bug

[Paul Sutton]

Hi

I have set up report-bug however upon running I am informs me that 
gir1.2-vte-2.91
 is missing, this is required to run the program with the GUI. 

I have no problem installing this (and have done) but just thought I
would mention it.

 report bug defaults to the CLI version anyway.

Paul


-- 

Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/




signature.asc
Description: OpenPGP digital signature

Help filing a bug report

[Chris Talbot]

Good Evening,

I have a rather specific bugthat I can reliably recreate, but I really don't 
know how to file it or how to give detailed logs on, and I would appreciate any 
advice.

I am running Debian Stable with a Cimmamon Desktop, and have it set to sign me 
in automaically. I am running it on top of an encrypted ZFS set up.  Recently, 
I purchased a 2TB hard drive and formatted it to ext4. I added this to my 
/etc/fstab:

UUID=31320a26-0b89-413f-a628-b8e10041183f /home/chris/Android ext4 defaults 0 0

On the next reboot, Cinnamon did not automatically log me in, but presented the 
log in screen to me. WHen I logged in, the command line reappeared, then the 
log in screen reappeared. I could log in as root, and if I used ctrl+alt+F1 to 
log in as "chris" on CLI, I would log in no problem.

I discovered this because I reverted the ZFS snapshot to before having the hard 
drive, and I could log in just fine. HOwever, adding that line again triggered 
the same error state. WHen I tried to remove the line from /etc/fstab and 
reboot, the error state persisted.

I have additionally found that mounting the ext4 partition through Nemo does 
not trigger this behavior.

As this is a rather odd bug, I am unsure how to gather more information, nor am 
I sure what is causing it, as I have a feeling that it is a compilation of 
issues.

Any help would be appreciated. Thank you!

Respectfully,
Chris Talbot

Re: Apt bug & redirects

[Curt]

On 2019-01-23, Richard Hector  wrote:
>
> Ok, it seems if I go through the list on the dsa page above, I can then
> download the packages from their respective pages on
> packages.debian.org, where they're listed along with checksums. Tedious,
> but should work :-)
>
> Richard
>
>

Not certain why running

 apt update -o Acquire::http::AllowRedirect=false

before updating apt updating itself is inoperative in your case.

For me, unfortunately, the camel has just now arrived with the news, and
I installed the update that addressed this vulnerability yesterday in
the usual manner (apt update; etc...).

Maybe I've been pwned.

Bug In Unknown Package

[Cole Creps]

Hello, I recently upgraded to Debian Buster and now experience severe 
graphical lag(10-15FPS on a blank desktop, less with a window open 
according to KDE's built in FPS monitor) after resuming from suspend.  
Reportbug said to contact this address because I don't know which 
package is causing the problem - how would I go about finding that out?

Re: Apt bug & redirects

[Richard Hector]

On 23/01/19 5:05 PM, Richard Hector wrote:
> Hi all,
> 
> I just read about the current apt security update on The Register:
> 
> https://www.theregister.co.uk/2019/01/22/debian_package_manager_flaws/
> 
> It suggests running apt update with redirects disallowed ... but
> security.debian.org appears to do a redirect.
> 
> There's a tip at https://www.debian.org/security/2019/dsa-4371 , but
> using the cdn-fastly url doesn't seem to work, at least for jessie
> (haven't tried my stretch machines yet).
> 
> Anyone know if there's a direct url for (jessie) security updates that
> doesn't rely on redirects?

Ok, it seems if I go through the list on the dsa page above, I can then
download the packages from their respective pages on
packages.debian.org, where they're listed along with checksums. Tedious,
but should work :-)

Richard




signature.asc
Description: OpenPGP digital signature

Apt bug & redirects

[Richard Hector]

Hi all,

I just read about the current apt security update on The Register:

https://www.theregister.co.uk/2019/01/22/debian_package_manager_flaws/

It suggests running apt update with redirects disallowed ... but
security.debian.org appears to do a redirect.

There's a tip at https://www.debian.org/security/2019/dsa-4371 , but
using the cdn-fastly url doesn't seem to work, at least for jessie
(haven't tried my stretch machines yet).

Anyone know if there's a direct url for (jessie) security updates that
doesn't rely on redirects?

Cheers,
Richard



signature.asc
Description: OpenPGP digital signature

Debian Bug Squashing Party (BSP) in Gothenburg, Sweden - 7 April 2019

[Chris Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Debian Bug Squashing Party (BSP) in Gothenburg, Sweden - 7 April 2019
=

I am very happy to invite you to a Debian Bug Squashing Party in
Gothenburg, Sweden, on Sunday April 7th 2019.

The BSP will be held as part of the foss-north 2019 [0] who have
have offered Debian a room as part of the conference's "Community
Day". Free tickets to the conference itself will be provided by the
organisers.

A short registration on the wiki page [1] is required to ease the
organisation of the event. On the same page you will find
information regarding transport, accommodation and other useful
information:

  https://wiki.debian.org/BSP/2019/04/se/Gothenburg

Even if you are not a Debian Developer or Maintainer yet (but are
otherwise interested in fixing bugs and helping Debian) please do
not hesitate to attend; there will be enough people around to
sponsor uploads and/or offer advice. Team meetings/sprints during
the BSP are naturally welcome.

More information about BSPs and Release Critical bugs can be found
at [2][3][4]. In particular, don't forget that Debian is willing to
reimburse the equivalent of 100 USD to attend BSPs.

Hope to see you there.

  [0] http://foss-north.se/2019/
  [1] https://wiki.debian.org/BSP/2019/04/se/Gothenburg
  [2] http://wiki.debian.org/BSP
  [3] http://people.debian.org/~vorlon/rc-bugsquashing.html
  [4] http://bugs.debian.org/release-critical/


Regards,

- - -- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAlw/ougACgkQHpU+J9Qx
HlgcNxAAsDKutJ9EPgdr7KOveLZkEVInKbfhMJDkn0hHWb+A/TnnIjrkyvIiNVip
aqynlavotqRrc9q9/ZrUJtOnhrZifDrLa7jmJKjNcivsAnEQD4aZneCdM/kXq61C
R7XD0lpZCQ0XwPD+8mVT6hAGbOISslbTnTkb1nUCmZvbpXX8TQU1Sqg77mYijz99
zvW25aNosiEuQXROVfAy/DceqVPF6/6EmNFz1Sb9+gDqaeOqBPcKDZjp1kA4EuWq
LRj3OZbUPmok26p36YNyG+CKfm9s4bDNWRkdLxUhBcbKReu21w7xpfRHB9eli4ke
nyJFQfLhFyTRqbMfGXxE602kHssPI+jVZY2QGBGF2ipUfaRNv70ktSfelSuv9wDs
tJdCRzXIvQdWHxZkGFrcpnPwOMvoWJBMAIbv27ieXOwGC4OFoekCePa3bxp6y04Z
YOOryZdIaoaVFTeySHc6SBLP7hOr4HT2ajeC+7PRj0tuLGMfeY29wFoEMqQgmzsR
6PqZnnDvbhn8TgcGSdYePdSZ/DE2uDBjc2ud1ju640ttUGt4A5pNggVOJ7+qQqTK
Sz07tTKx+/cTsBChDS+TP1Luw+HMVHg7hL+X3j1W8EEwGIviTWiRdfZ2mXFCa8yI
Mk5mdaddUJaCdcPi6TIK3hXoqCm07w66uvzaTqivQgYM5TrEh68=
=3MqF
-END PGP SIGNATURE-

Debian Bug Squashing Party (BSP) in Gothenburg, Sweden - 7 April 2019

[Chris Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Debian Bug Squashing Party (BSP) in Gothenburg, Sweden - 7 April 2019
=

I am very happy to invite you to a Debian Bug Squashing Party in
Gothenburg, Sweden, on Sunday April 7th 2019.

The BSP will be held as part of the foss-north 2019 [0] who have
have offered Debian a room as part of the conference's "Community
Day". Free tickets to the conference itself will be provided by the
organisers.

A short registration on the wiki page [1] is required to ease the
organisation of the event. On the same page you will find
information regarding transport, accommodation and other useful
information:

  https://wiki.debian.org/BSP/2019/04/se/Gothenburg

Even if you are not a Debian Developer or Maintainer yet (but are
otherwise interested in fixing bugs and helping Debian) please do
not hesitate to attend; there will be enough people around to
sponsor uploads and/or offer advice. Team meetings/sprints during
the BSP are naturally welcome.

More information about BSPs and Release Critical bugs can be found
at [2][3][4]. In particular, don't forget that Debian is willing to
reimburse the equivalent of 100 USD to attend BSPs.

Hope to see you there.

  [0] http://foss-north.se/2019/
  [1] https://wiki.debian.org/BSP/2019/04/se/Gothenburg
  [2] http://wiki.debian.org/BSP
  [3] http://people.debian.org/~vorlon/rc-bugsquashing.html
  [4] http://bugs.debian.org/release-critical/


Regards,

- - -- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAlw/ougACgkQHpU+J9Qx
HlgcNxAAsDKutJ9EPgdr7KOveLZkEVInKbfhMJDkn0hHWb+A/TnnIjrkyvIiNVip
aqynlavotqRrc9q9/ZrUJtOnhrZifDrLa7jmJKjNcivsAnEQD4aZneCdM/kXq61C
R7XD0lpZCQ0XwPD+8mVT6hAGbOISslbTnTkb1nUCmZvbpXX8TQU1Sqg77mYijz99
zvW25aNosiEuQXROVfAy/DceqVPF6/6EmNFz1Sb9+gDqaeOqBPcKDZjp1kA4EuWq
LRj3OZbUPmok26p36YNyG+CKfm9s4bDNWRkdLxUhBcbKReu21w7xpfRHB9eli4ke
nyJFQfLhFyTRqbMfGXxE602kHssPI+jVZY2QGBGF2ipUfaRNv70ktSfelSuv9wDs
tJdCRzXIvQdWHxZkGFrcpnPwOMvoWJBMAIbv27ieXOwGC4OFoekCePa3bxp6y04Z
YOOryZdIaoaVFTeySHc6SBLP7hOr4HT2ajeC+7PRj0tuLGMfeY29wFoEMqQgmzsR
6PqZnnDvbhn8TgcGSdYePdSZ/DE2uDBjc2ud1ju640ttUGt4A5pNggVOJ7+qQqTK
Sz07tTKx+/cTsBChDS+TP1Luw+HMVHg7hL+X3j1W8EEwGIviTWiRdfZ2mXFCa8yI
Mk5mdaddUJaCdcPi6TIK3hXoqCm07w66uvzaTqivQgYM5TrEh68=
=3MqF
-END PGP SIGNATURE-

Re: Em podeu donar un cop de ma amb un bug?

[Robert Marsellés]

El 12/1/19 a les 12:40, a...@probeta.net ha escrit:
> Bon dia a tothom,
> 
> Fa molt de temps que em barallo amb un bug, que intento acorralar, però
> no hi ha manera.
> 
> Afecta a Debian Testing en el sistema gràfic, i aquí em veig molt
> perdut, entre controladors, servidors de finestres, gestors de
> finestres, compositors, mesas, cairos, egl, etc.

[...]
> 
> Crec que el bug afecta a molta gent, i que alguns missatges que es poden
> 

[...]

> 
> Treballo amb targeta gràfica [AMD/ATI] Turks XT [Radeon HD 6670/7670] a
> Debian Testing, actualment amb nucli 4.19
> 
> Fins al nucli 4.13 tot anava bé, però en actualitzar al nucli 4.14
> l’escriptori Gnome es «congelava» cada pocs minuts. A tots els següents
> nuclis fins el 4.19 el problema persisteix. A aquest enllaç hi ha els
> canvis que aporta el nucli 4.14 a Radeon, però no els sé interpretar:
> https://kernelnewbies.org/Linux_4.14#Graphics
> 
>  Pista: Es congelava Gnome amb Xorg, però no Gnome amb Wayland
> 

Jo també en tinc un de llarga durada i uso Debian Testin g des d'uns 3 -
4 mesos després del darrer canvi d'estable (juny o juliol 2017). El
primer nucli que vaig usar tot anava bé. A partir del següent (no
recordo quin) van començar els maldecaps.

El meu hardware no té rés a veure amb el teu. Tot i això, els problemes
que descrius són força similars als que a mi m'afecten i, en el meu cas,
estan relacionats amb la targeta gràfica [1,2].

De vegades ni tant sols es carregava el sistema gràfic. D'altres no
podia canviar entre entorn gràfic o no (usant CTRL+ALT+n), d'altres és
"gelava" la imatge, d'altres és bloquejava mentre parava la maquina.

L'únic en comú entre la multitud de diverses marques de proveïdors de
portàtils afectats sembla ser el fet de tenir el sistema gràfic integrat
Intel + targeta gràfica dedicada NVIDIA (diversos models):

$ lspci | egrep "VGA|3D"
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630
(rev 04)
01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Ti
Mobile] (rev a1)


>
>  Pista: no es congelava XFCE
> 

Únicament he provat GNOME. Als "bugs" que jo he revisat no importa gaire
l'entorn gràfic usat però hi ha majoria de GNOMEs. Suposo que el motiu
és que és l'entorn majoritari.

>  Pista: fent CTRL+ALT+F8 i després CTRL+ALT+F7 tot tornava a funcionar
> 

No ho vaig provar això.

[...]

> 
> No sé ni per on començar. Algun consell?
> 

Jo vaig provar altres coses. Al final, solament funciona bé modificar
les opcions del nucli a /etc/default/grub. Concretament, jo tinc:

GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=!"

hi ha gent que ho combina amb diferents versions de Windows:

"acpi_osi='Windows '"

he vist molts 2009 i 2015 però altres també. Tots amb resultats
diversos. Jo vaig provar-ho amb 2009 i funciona de la mateixa manera que
sense.

Totes les noves versions del nucli que han sortit a Testing les provo
sense les opcions de nucli i es tornen a reproduir els problemes.

Salut i peles,

robert

[1] https://bugzilla.kernel.org/show_bug.cgi?id=156341
[2] https://github.com/Bumblebee-Project/Bumblebee/issues/764

Re: Em podeu donar un cop de ma amb un bug?

[Ernest Adrogué]

Àlex  writes:
> Sí així vaig fer. Vaig descarregar el nucli 4.9 de la Debian estable i
> el vaig instal.lar, i quan vull veure vídeo arrenco amb aquest nucli.
> Des de la versió 4.14 a la 4.19 la cosa ha anat malament i no sé si amb
> el temps es corregirà, però sempre puc canviar de hardware gràfic.
>
> A internet vaig llegir usuaris de Linux amb problemes semblants que
> comentaven que encara guardaven la partició de Windows per poder veure
> vídeos, i em va sabre greu.

A vegades hi ha algun problema, però en general les targetes AMD estan
ben suportades a Linux.  Un dels motius és que AMD col·labora amb els
programadors dels drivers oberts, a diferència d'altres fabricants.

Fa bastant temps vaig tenir un problema semblant al teu.  Al final els
de Xfce em van recomanar que utilitzés el driver X11 "modesetting" en
lloc del "radeon", i es va solucionar.  Tampoc tinc gaire idea de com
funciona el sistema gràfic de Linux, però em sembla entendre que
actualment el driver de X11 és un driver genèric per a totes les
targetes (el tal "modesetting"), i el driver específic per a cada
targeta ara es troba integrat en el kernel.  L'usuari no ha de
configurar res.  Si ho tens de l'altra manera, es van trencant coses
perquè els drivers antics de X11 actualment ja no es desenvolupen.

Re: Em podeu donar un cop de ma amb un bug?

[Eduard Selma]

El 14/1/19 a les 13:09, Àlex ha escrit:


El teu hardware gràfic és Radeon?


- Sí, és el AMD/ATI Richland (Radeon HD 8670D). Està integrat amb la 
CPU: Quad Core AMD A10-6800K, és el que anomenen APU. Deu ser del 2013 o 
14, tecnologia de 32 nm. Res de darrera generació. Evidenment, és un 
model diferent del teu.


Cordialment,

Eduard Selma.

Re: Em podeu donar un cop de ma amb un bug?

[Àlex]

El 12/1/19 a les 18:33, Eduard Selma ha escrit:
> El 12/1/19 a les 12:40, a...@probeta.net ha escrit:
>> Bon dia a tothom,
>>
>> Fa molt de temps que em barallo amb un bug, que intento acorralar,
>> però no hi ha manera.
>>
>> Afecta a Debian Testing en el sistema gràfic, i aquí em veig molt
>> perdut, entre controladors, servidors de finestres, gestors de
>> finestres, compositors, mesas, cairos, egl, etc.
>
> - No crec que t'ajudi gaire, només són més dades... (i potser més
> "soroll"):
>
> Treballo amb Debian 9.6 (Stretch, stable) però amb nucli
> 4.17.0-0.bpo.3-amd64 (el que instal·la per omissió Neptune). El
> servidor gràfic és X.Org 1.19.6, gestor de finestres i compositor
> kwin-X11. L'Open GL és AMD ARUBA (DRM 2.50.0 / 4.17.0-0.bpo.3-amd64
> LLVM 6.0.0) v: 4.3 Mesa 18.2.6.
>
> El meu entorn d'escriptori és KDE/Plasma Frameworks 5.45.0 amb Qt 5.7.1.
>
> No uso cap altre compositor, panels virguers, ni rés més quant a
> gràfics. El meu reproductor VLC és el 3.0.3.
>
> Fins ara, no he observat el fenomen que ens descrius. 


Gràcies Eduard


El teu hardware gràfic és Radeon?


Salutacions



    Àlex

Re: Em podeu donar un cop de ma amb un bug?

[Àlex]

> Pel que dius, semblaria un problema del compositor, que no actualitza
> l'estat de la pantalla correctament.  Ara bé, si et passa amb Gnome i
> també amb Xfce, que utilitzen compositors diferents, aleshores m'inclino
> a pensar que és una altra cosa.


Sí, i amb Gnome amb Xorg es congelava tot l'escriptori i amb Gnome amb
Wayland no. Tot molt estrany.


La pròxima trobada Debian, si algú s'anima a fer una xerrada tècnica per
explicar tots els elements que formen el sistema gràfic de Linux, jo ho
agrairé molt.



> Probablement és més pràctic tornar a una versió anterior que saps que
> funciona i posar-la en estat "hold", i esperar que solucionin el
> problema a les versions més recents.


Sí així vaig fer. Vaig descarregar el nucli 4.9 de la Debian estable i
el vaig instal.lar, i quan vull veure vídeo arrenco amb aquest nucli.
Des de la versió 4.14 a la 4.19 la cosa ha anat malament i no sé si amb
el temps es corregirà, però sempre puc canviar de hardware gràfic.

A internet vaig llegir usuaris de Linux amb problemes semblants que
comentaven que encara guardaven la partició de Windows per poder veure
vídeos, i em va sabre greu.

A mi, que m'agrada buscar bugs, m'ha servit per no asumir que quan una
aplicació es "congela" es l'aplicació, sino que l'aplicació pot no estar
congelada i es tracta del sistema gràfic de Linux que ha deixat de
renovar el contingut de la finestra o de tot l'escriptori.


Salut

Re: Em podeu donar un cop de ma amb un bug?

[Ernest Adrogué]

Hola,

2019-01-12, 12:40 (+0100); a...@probeta.net escriu:
> Fins al nucli 4.13 tot anava bé, però en actualitzar al nucli 4.14
> l’escriptori Gnome es «congelava» cada pocs minuts. A tots els següents
> nuclis fins el 4.19 el problema persisteix. A aquest enllaç hi ha els canvis
> que aporta el nucli 4.14 a Radeon, però no els sé interpretar:
> https://kernelnewbies.org/Linux_4.14#Graphics
> 
>  Pista: Es congelava Gnome amb Xorg, però no Gnome amb Wayland
> 
>  Pista: no es congelava XFCE
> 
>  Pista: fent CTRL+ALT+F8 i després CTRL+ALT+F7 tot tornava a funcionar
> 
> Vaig treure Gnome i vaig continuar amb XFCE i amb Mate, però algunes
> aplicacions importants es continuen congelant cada pocs minuts: VLC,
> Mplayer, Chromium, però no Firefox
> 
>  Pista: fent CTRL+ALT+F8 i després CTRL+ALT+F7 tot torna a funcionar
> 
>  Pista: no apareix res als logs amb «dmesg», ni als logs de Xorg, ni als
> logs de VLC
> 
>  Pista potser gran: en realitat he descobert que les aplicacions «no es
> congelen». Continuen funcionant bé, però ja no es «dibuixen» a la finestra,
> el que fa semblar que l’aplicació «s’ha congelat».

Pel que dius, semblaria un problema del compositor, que no actualitza
l'estat de la pantalla correctament.  Ara bé, si et passa amb Gnome i
també amb Xfce, que utilitzen compositors diferents, aleshores m'inclino
a pensar que és una altra cosa.

> Resum: del kernel 4.14 en endavant, amb targetes gràfiques Radeon, i amb
> Xorg però no amb Wayland, alguna cosa fa que aleatòriament les finestres de
> VLC, Mplayer, Chromium es deixin de dibuixar («es congelin») malgrat
> aquestes aplicacions estiguin funcionant perfectament. Tot torna a funcionar
> fent CTRL+ALT+F8 seguit de CTRL+ALT+F7
> 
> No sé ni per on començar. Algun consell?

Els problemes que tenen a veure amb el sistema gràfic són difícils de
solucionar pel teu compte, a no ser que siguis un expert en el tema.  Si
el bug és reproduïble (és a dir es produeix sempre que fas alguna cosa
concreta), pots anar provant diferents versions del programari sospitós
de causar-lo i veure exactament quina versió introdueix el problema.
Amb aquest mètode podries veure fins i tot quina línia de codi és la
culpable, però clar, si has d'anar compilant versions i sub-versions del
kernel, o de altres components complexos, és una feinada considerable.
Probablement és més pràctic tornar a una versió anterior que saps que
funciona i posar-la en estat "hold", i esperar que solucionin el
problema a les versions més recents.

Salut.

Re: Em podeu donar un cop de ma amb un bug?

[Eduard Selma]

El 12/1/19 a les 12:40, a...@probeta.net ha escrit:

Bon dia a tothom,

Fa molt de temps que em barallo amb un bug, que intento acorralar, però 
no hi ha manera.


Afecta a Debian Testing en el sistema gràfic, i aquí em veig molt 
perdut, entre controladors, servidors de finestres, gestors de 
finestres, compositors, mesas, cairos, egl, etc.


- No crec que t'ajudi gaire, només són més dades... (i potser més "soroll"):

Treballo amb Debian 9.6 (Stretch, stable) però amb nucli 
4.17.0-0.bpo.3-amd64 (el que instal·la per omissió Neptune). El servidor 
gràfic és X.Org 1.19.6, gestor de finestres i compositor kwin-X11. 
L'Open GL és AMD ARUBA (DRM 2.50.0 / 4.17.0-0.bpo.3-amd64 LLVM 6.0.0) v: 
4.3 Mesa 18.2.6.


El meu entorn d'escriptori és KDE/Plasma Frameworks 5.45.0 amb Qt 5.7.1.

No uso cap altre compositor, panels virguers, ni rés més quant a 
gràfics. El meu reproductor VLC és el 3.0.3.


Fins ara, no he observat el fenomen que ens descrius.

Són els meus cinc cèntims.  

Eduard Selma

Re: Em podeu donar un cop de ma amb un bug?

[alex]

Fins al nucli 4.13 tot anava bé, però en actualitzar al nucli 4.14
l’escriptori Gnome es «congelava» cada pocs minuts. A tots els
següents nuclis fins el 4.19 el problema persisteix. A aquest enllaç
hi ha els canvis que aporta el nucli 4.14 a Radeon, però no els sé
interpretar: https://kernelnewbies.org/Linux_4.14#Graphics




He oblidat dir que això només em passa al PC de sobretaula amb el que 
treballo, on tinc una targeta gràfica Radeon.


Tinc dos portàtils més amb hardware gràfic diferent treballant amb 
Debian Testing i van perfectes.

Em podeu donar un cop de ma amb un bug?

[alex]

Bon dia a tothom,

Fa molt de temps que em barallo amb un bug, que intento acorralar, però 
no hi ha manera.


Afecta a Debian Testing en el sistema gràfic, i aquí em veig molt 
perdut, entre controladors, servidors de finestres, gestors de 
finestres, compositors, mesas, cairos, egl, etc.


Si em podeu adreçar un bon document on expliqui com funciona a fons el 
sistema gràfic de Linux us ho agrairé.


Crec que el bug afecta a molta gent, i que alguns missatges que es poden 
trobar als cercadors sobre Gnome+Debian+freezes, VLC+Debian+freezes, 
Chromium+Debian+freezes venen del mateix.


Passo a explicar el problema per si em podeu donar consells. Sento si 
fallo en la precissió o si fins i tot dic alguna bajanada.




Treballo amb targeta gràfica [AMD/ATI] Turks XT [Radeon HD 6670/7670] a 
Debian Testing, actualment amb nucli 4.19


Fins al nucli 4.13 tot anava bé, però en actualitzar al nucli 4.14 
l’escriptori Gnome es «congelava» cada pocs minuts. A tots els següents 
nuclis fins el 4.19 el problema persisteix. A aquest enllaç hi ha els 
canvis que aporta el nucli 4.14 a Radeon, però no els sé interpretar: 
https://kernelnewbies.org/Linux_4.14#Graphics


 Pista: Es congelava Gnome amb Xorg, però no Gnome amb Wayland

 Pista: no es congelava XFCE

 Pista: fent CTRL+ALT+F8 i després CTRL+ALT+F7 tot tornava a funcionar

Vaig treure Gnome i vaig continuar amb XFCE i amb Mate, però algunes 
aplicacions importants es continuen congelant cada pocs minuts: VLC, 
Mplayer, Chromium, però no Firefox


 Pista: fent CTRL+ALT+F8 i després CTRL+ALT+F7 tot torna a funcionar

 Pista: no apareix res als logs amb «dmesg», ni als logs de Xorg, ni als 
logs de VLC


 Pista potser gran: en realitat he descobert que les aplicacions «no es 
congelen». Continuen funcionant bé, però ja no es «dibuixen» a la 
finestra, el que fa semblar que l’aplicació «s’ha congelat».


Resum: del kernel 4.14 en endavant, amb targetes gràfiques Radeon, i amb 
Xorg però no amb Wayland, alguna cosa fa que aleatòriament les finestres 
de VLC, Mplayer, Chromium es deixin de dibuixar («es congelin») malgrat 
aquestes aplicacions estiguin funcionant perfectament. Tot torna a 
funcionar fent CTRL+ALT+F8 seguit de CTRL+ALT+F7


No sé ni per on començar. Algun consell?

Gràcies


   Àlex

Bug regarding audio in "stable" branch

[Jul']

Hello,

Sorry to disturb you, but I have a problem regarding audio on Debian 9 stable :

- after booting and login in, the default source is not chosen ; therefore no 
sound is transmitted to the output (you can select again a proper audio source 
with the GNOME Sound GUI and it will work again afterwards); it is important to 
note that it does not happen after every boot)
- I do not know whether it can be linked to GNOME or any other package down to 
pulseaudio
- I do not know which details could be useful ; I would be happy to submit a 
much more detailed bug report as soon as I know how I can identify which 
package is responsible for this bug.

I planned to wait on having the faulty package identified before submitting my 
bug (via the reportbug command) with many more technical details, but feel free 
to tell me the right way to do it.

Best regards,

Julien-Benjamin

Re: digikam: does it make sense to report a bug already fixed upstream but not in debian?

[Andrea Borgia]

Il 06/01/19 12:41, Étienne Mollier ha scritto:



Since you can reproduce the bug in Debian, I guess it is worth a
report, with a mention to the upstream bug page and, if possible
the patch fixing it.  Put information necessary to the context,
but no need to copy the entire thread on KDE bug tracker.


Hello, Étienne.

Done, #918478

Re: digikam: does it make sense to report a bug already fixed upstream but not in debian?

[Étienne Mollier]

On 1/6/19 12:26 PM, Andrea Borgia wrote:
> Hi.
> 
> Case in point: https://bugs.kde.org/show_bug.cgi?id=395875
> 
> There is no corresponding bugreport for the Debian package; had I not found 
> the upstream bug, I would have filed a report with nearly the same 
> information, since my tests match the issue perfectly.
> 
> Question is, for tracking purposes in Debian, does it still make sense to 
> file a bugreport now?
> 
> Thanks,
> Andrea.

Hi Andrea,

Since you can reproduce the bug in Debian, I guess it is worth a
report, with a mention to the upstream bug page and, if possible
the patch fixing it.  Put information necessary to the context,
but no need to copy the entire thread on KDE bug tracker.

Kind Regards
-- 
Étienne Mollier 

digikam: does it make sense to report a bug already fixed upstream but not in debian?

[Andrea Borgia]

Hi.

Case in point: https://bugs.kde.org/show_bug.cgi?id=395875

There is no corresponding bugreport for the Debian package; had I not 
found the upstream bug, I would have filed a report with nearly the same 
information, since my tests match the issue perfectly.


Question is, for tracking purposes in Debian, does it still make sense 
to file a bugreport now?


Thanks,
Andrea.

Possible bug: "safely remove drive" freeze the system

[Daniele Gervasoni]

Hello,

I have the issue in the subject when a right click on a USB drive and click
on "safely remove drive". I am on Debian 9.6 with gnome.
It happen with different drives and different usb ports.
Looking on the www it was an old 2.6 kernel bug.
Below hostnamectl output concerning architecture.
If a patch already exist may you point me there?
Thank you.
Daniele

:~$ hostnamectl

  Operating System: Debian GNU/Linux 9 (stretch)
Kernel: Linux 4.9.0-8-amd64
  Architecture: x86-64

Re: How do I report a bug to Debian? ... as ReportBug has bugs.

[John Hasler]

Howard writes:
> The URL for the Debian Bug project apparently isn't working or has
> changed.  I've found two links that are not working.  The first one is
> here in ReportBug, where the blue link for "Homepage of reportbug
> project" is broken.  (The yellow tool tip shows the bad URL being
> tried).

You must mean reportbug-ng.  Reportbug is working fine but it isn't
graphical.  Reportbug-ng also seems to work here, but I don't know what
you mean by the "blue link".

Your attempt to insert the stuff from Synaptic failed.


-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: How do I report a bug to Debian? ... as ReportBug has bugs.

[john doe]

On 12/6/2018 8:22 AM, Howard Johnson wrote:
> Aloha,
> 
> The URL for the Debian Bug project apparently isn't working or has
> changed.  I've found two links that are not working.  The first one is
> here in ReportBug, where the blue link for "Homepage of reportbug
> project" is broken.  (The yellow tool tip shows the bad URL being tried).
> 
> Here is the version info for reportbug as reported in synaptic package
> manager:
> 
> 
> Also in synaptic, the link to "Visit Homepage" is also not working here:
> 
> 
> I searched for a replacement link and found this page
> *https://wiki.debian.org/reportbug*, but unfortunately it says,
> 
>    "*Note*: this page is not maintained by reportbug maintainers, so
>    the information in here might be outdated or no longer correct."
> 
> :-(
> 
> Searched again and found this page:
> *https://packages.debian.org/stable/utils/reportbug*
> 
> *
> *
> 
> *SO, *I previously tonight spent an hour and submitted a bug, only to
> have it vanish in this bugreport tool.  I clicked the save.  It gave me
> a new dialog box, for what I still don't know. I put my home path into
> it.  And clicked ok or whatever, and it was gone.
> 
> Some days are like this...
> 
> Hope you can help. Thanks.
> 

If the reportbug utility is not working, you can always send the bug
report per e-mail (1).

"How to report a bug in Debian using email (and advanced usage of
reportbug)"

HTH.


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

-- 
John Doe

Re: ajuda reportar bug letsencrypt (systemd) - [Off-topic]

[cubells]

El 5/12/18 a les 16:37, Alex Muntada ha escrit:

...

> 
> * [0] https://bugs.debian.org/810216
> * [1] https://bugs.debian.org/902620

Àlex:

ja estàs completament dins de Matrix, comptes ja basat en zero[1]

:

* [1]:
https://en.wikipedia.org/wiki/Zero-based_numbering#In_computer_programming


-- 
Atentament, cubells.
--



signature.asc
Description: OpenPGP digital signature

How do I report a bug to Debian? ... as ReportBug has bugs.

[Howard Johnson]

Aloha,

The URL for the Debian Bug project apparently isn't working or has 
changed.  I've found two links that are not working.  The first one is 
here in ReportBug, where the blue link for "Homepage of reportbug 
project" is broken.  (The yellow tool tip shows the bad URL being tried).


Here is the version info for reportbug as reported in synaptic package 
manager:



Also in synaptic, the link to "Visit Homepage" is also not working here:


I searched for a replacement link and found this page 
*https://wiki.debian.org/reportbug*, but unfortunately it says,


   "*Note*: this page is not maintained by reportbug maintainers, so
   the information in here might be outdated or no longer correct."

:-(

Searched again and found this page: 
*https://packages.debian.org/stable/utils/reportbug*


*
*

*SO, *I previously tonight spent an hour and submitted a bug, only to 
have it vanish in this bugreport tool.  I clicked the save.  It gave me 
a new dialog box, for what I still don't know. I put my home path into 
it.  And clicked ok or whatever, and it was gone.


Some days are like this...

Hope you can help. Thanks.

Re: ajuda reportar bug letsencrypt (systemd)

[Alex Muntada]

Hola Pedro,

> Referència d'això que dius? Vols dir que si està systemd i el
> cron llavors systemd té prioritat (i el cron en qüestió no
> s'executa?). Que si paro el timer llavors només fa el cron?

El certbot executa això al cron:

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl 
-e 'sleep int(rand(3600))' && certbot -q renew

Per tant, si existeix el directori /run/systemd/system ja no
s'executa l'ordre certbot del final.

A la versió de Debian 10 (ara mateix és la mateixa a testing i
unstable), a més a més, han afegit un comentari explicant-ho,
que també tanca un bug al respecte demanant més detalls:

https://salsa.debian.org/letsencrypt-team/certbot/certbot/blob/master/debian/certbot.cron.d
https://bugs.debian.org/908841

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer - log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: ajuda reportar bug letsencrypt (systemd)

[Pedro]

Hola Narcís,

inline:

On Wed, Dec 5, 2018 at 3:54 PM Narcis Garcia  wrote:
>
> Amb "systemctl status certbot" veuràs que se t'ha disparat el mateix
> dia. Això vol dir que és un servei que fa una tasca (one-shot) i s'atura
> fins el següent torn, que no sé si són una o dues vegades al dia.

OK, però per aturar la tasca has d'atacar el timer, no el oneshot (que
en aquest cas és llençat per un timer)

Com he posat al fitxer de timer (i per lo que he vist als logs) és al
voltant de les 12:00

OnCalendar=*-*-* 00,12:00:00

> Segons està anotat als «scripts», la tasca del Cron no té efecte si
> Systemd està present. Aleshores aturant i deshabilitant només el
> certbot.timer ja no hauria d'actuar en cap moment.

Referència d'això que dius? Vols dir que si està systemd i el cron
llavors systemd té prioritat (i el cron en qüestió no s'executa?). Que
si paro el timer llavors només fa el cron?

Salut,
Pedro

Re: ajuda reportar bug letsencrypt (systemd)

[Pedro]

Narcís,

no era així del tot així, ja que `systemctl disable certbot`
sobreentén que es refereix a certbot.service així com `systemctl
status certbot`, i si el veiem diu que està mort de per sí. Algú li
està donant vida...

Resulta que certbot per la part de systemd té un cron també i d'aquesta manera:

- l'script /lib/systemd/system/certbot.service [1]
- el disparador /lib/systemd/system/certbot.timer [2]

per tant, es pot deshabilitar així per la sessió actual:

systemctl stop certbot.timer

per sessions futures (només aquest no fa sessió actual):

systemctl disable certbot.timer

Crec que continua sent un bug perquè està duplicat en cron i en
systemd, perquè no avisa, és a dir: mal muntat en general, lo qual les
modificacions per una banda i no l'altre no es propaguen bé. Però el
meu problema sembla que ja està resolt!

Gràcies!
Pedro

[1]

# cat /lib/systemd/system/certbot.service
[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

[2]

# cat /lib/systemd/system/certbot.timer
[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target

ajuda reportar bug letsencrypt (systemd)

[guifipedro]

Hola,

Crec que letsencrypt té un bug per com està empaquetat a debian

Acostumo a treure els permisos de root a letsencrypt (i fer-ho amb un
usuari dedicat), això implica que al meu /etc/cron.d/certbot [1]
l'executa l'usuari letsencrypt enlloc de root

que intel·ligentment m'avisa si el vull modificar en futures actualitzacions

sorprenentment vaig veure que en paral·lel hi ha un servei systemd que
fa el mateix aquí: /lib/systemd/system/certbot.service [2]

per tant el modifico, però a les actualitzacions no m'avisa de canvis,
directament el sobreescriu i aquí és on crec que es tracta d'un error.

Degut a que utilitzo el meu usuari propi pel letsencrypt, si un procés
com aquest de systemd s'executa com a root, llavors canvia els
permisos d'alguns fitxers i directoris i letsencrypt ja no pot renovar
/ ho fa de la manera que jo no vull / problemes per a mi.

Gràcies!
Pedro

[1]

0 */12 * * * letsencrypt test -x /usr/bin/certbot -a \! -d
/run/systemd/system && perl -e 'sleep int(rand(3600))' && su -
letsencrypt -s /bin/bash -c "certbot -q renew"

[2]

[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
#ExecStart=/usr/bin/certbot -q renew
ExecStart=su - letsencrypt -s /bin/bash -c "certbot -q renew"
PrivateTmp=true

Re: I'd like help reporting an anomaly/bug with wifi and NetworkManager under Buster

[Celejar]

On Mon, 3 Dec 2018 09:41:21 -0600
craig macdonald  wrote:

> Hello all,
> 
> I've discovered a small bug in linux (wifi?) networking, but I haven't
> been able to report it because I don't seem to know the correct package
> to report the bug against.
> 
> I bought an older, "obsolete" usb wifi adapter (D-Link DWA-130, Rev. F)
> after reading of the difficulties using up-to-date wifi adapters and
> after confirming more or less that this one ought to work with firmware
> and driver available in the firmware-ralink package.
> 
> I installed the usb wifi adapter and firmware-misc-nonfree on a desktop
> computer running Buster. The computer could then see several nearby
> wifi routers, including my own, but it COULD NOT connect to any of
> them, even with the access passwords.
> 
> The computer uses NetworkManager to manage the wifi connenction.

To provide more useful information, you need to test things using
simpler, lower level tools, such as ifconfig / iwconfig and ip, and
record the terminal output, and even more importantly, the messages
that appear in syslog.

> ==Troubleshooting:==
> I installed the same D-Link adapter on another computer (same make and
> model) running Jessie, along with the firmware-ralink package (as it
> was called under Jessie) and it all works fine together, again using
> NetworkManager to manage the wifi connection. The D-Link DWA-130 usb
> wifi adapter is able to see the nearby wifi routers and to connect to
> the internet with the appropriate router password.
> 
> I found a workaround (detailed below) to allow this usb wifi adapter to
> work under Buster. Wishing to be a good FOSS citizen, I filed a bug
> report against the firmware-misc-nonfree (firmware-ralink) package
> (that was my best guess for the location of the problem).

...

> === Workaround: ===
> I am able to make the D-link usb wifi adapter work under Debian Buster by 
> creating the file
> /lib/udev/rules.d/70-wifi.rules
> 
> which contains this single line (address comes from device name 
> "wlx74dada1c2b5d"):
> 
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="74:da:da:1c:2b:5d", 
> NAME="wlan0"

...

> After a day or so, the maintainer of the package firmware-ralink closed
> the bug report, saying "This has nothing to do with firmware-ralink.
> Neither the firmware nor the driver cares what the device name is."

That certainly sounds correct, although a more helpful / less busy
maintainer might have helped figure out where to reassign the bug.

> OK, fine, but how should I now proceed at this point?
> I'd like to help the community correct what seems to be a problem
> somewhere in the linux networking system, possibly specific to wifi,
> but I have NO IDEA what package to mention when filing a new bug report
> if it wouldn't be firmware-misc-nonfree.

As above, more useful system output would be helpful in figuring out
where the problem lies.

In the non-working configuration, try to use iwconfig / ifconfig / ip
to connect to an access point and bring the interface up, and if it
doesn't work, post the output and logs (copy and paste the exact text
- don't summarize or paraphrase), and we'll see if we can figure out
what's going on.

And thanks for trying to report bugs!

Celejar

Re: I'd like help reporting an anomaly/bug with wifi and NetworkManager under Buster

[Reco]

Hi.

Here, at debian-user, we reply to the list so the whole community would
benefit from the answers. Writing to a list participant directly can be
OK as long as something private is discussed. Which is clearly not the
case here.

On Mon, Dec 03, 2018 at 01:26:10PM -0600, craig macdonald wrote:
> Hi again Reco.
> 
> What would be the best way to "blacklist" 
> /lib/udev/rules.d/73-usb-net-by-mac.rules?

Execute this as a root, verbatim:

touch /etc/udev/rules.d/73-usb-net-by-mac.rules
update-initramfs -k all -u

Reco

Re: I'd like help reporting an anomaly/bug with wifi and NetworkManager under Buster

[Reco]

Hi.

On Mon, Dec 03, 2018 at 09:41:21AM -0600, craig macdonald wrote:
> Hello all,
> 
> I've discovered a small bug in linux (wifi?) networking, but I haven't
> been able to report it because I don't seem to know the correct
> package to report the bug against.

Actually you've discovered a Network Manager's inability to associate
with AP. You shown nothing that proves something else.


> The computer uses NetworkManager to manage the wifi connenction.

What's more important is that:

1) The computer in question has udev which likes to rename network
interface names to be 'Predictable'. udev can be considered a part of
systemd, for the simplicity.

2) The wifi dongle in question is a USB device, so a rather dumb ruleset
called 73-usb-net-by-mac.rules applies to it.

3) Network Manager likes to use randomly generated MAC for WiFi AP
scanning, but it reverts to a 'native' MAC before actual AP association.

4) There are WiFi dongles which firmware does not allow you to change
their MAC, but Ralink does not have this deficiency.


Remove a single variable from this and it solves the problem:

1) Make a network interface name in question static. 
Any name that does not depends on MAC should do the trick.

2) Blacklist 73-usb-net-by-mac.rules. Does more harm than good anyway.

3) Remove Network Manager and use wpa_supplicant which *is* the
cornerstone of Linux wireless networking.

4) Or use PCI Wifi, not USB one.


> I found a workaround (detailed below) to allow this usb wifi adapter
> to work under Buster. Wishing to be a good FOSS citizen, I filed a bug
> report against the firmware-misc-nonfree (firmware-ralink) package
> (that was my best guess for the location of the problem).
...
> After a day or so, the maintainer of the package firmware-ralink
> closed the bug report, saying "This has nothing to do with
> firmware-ralink. Neither the firmware nor the driver cares what the
> device name is."

The maintainer is correct.
One should fix Network Manager, or udev rule, or convince systemd
upstream to ditch this '(Un)Predictable Network Interface Names', but
there's nothing to fix in either the firmware or the kernel.


> OK, fine, but how should I now proceed at this point?

See above.


> I'd like to help the community correct what seems to be a problem somewhere 
> in the linux networking system,

No that's not the problematic part if you mean the kernel.
And there's nothing wrong in udev.
And whoever wrote that AP-scanning part in Network Manager surely had
the best intentions (users' privacy and the like).

> possibly specific to wifi,

Nope. Any USB-provided NIC can be 'broken' the same way.

> but I have NO IDEA what package to mention

Network Manager, of course. Unless you can prove (with a simple
reproducible wpa_supplicant/iproute combo) otherwise.

Reco

I'd like help reporting an anomaly/bug with wifi and NetworkManager under Buster

[craig macdonald]

Hello all,

I've discovered a small bug in linux (wifi?) networking, but I haven't been 
able to report it because I don't seem to know the correct package to report 
the bug against.

I bought an older, "obsolete" usb wifi adapter (D-Link DWA-130, Rev. F) after 
reading of the difficulties using up-to-date wifi adapters and after confirming more or 
less that this one ought to work with firmware and driver available in the 
firmware-ralink package.

I installed the usb wifi adapter and firmware-misc-nonfree on a desktop 
computer running Buster. The computer could then see several nearby wifi 
routers, including my own, but it COULD NOT connect to any of them, even with 
the access passwords.

The computer uses NetworkManager to manage the wifi connenction.

==Troubleshooting:==
I installed the same D-Link adapter on another computer (same make and model) 
running Jessie, along with the firmware-ralink package (as it was called under 
Jessie) and it all works fine together, again using NetworkManager to manage 
the wifi connection. The D-Link DWA-130 usb wifi adapter is able to see the 
nearby wifi routers and to connect to the internet with the appropriate router 
password.

I found a workaround (detailed below) to allow this usb wifi adapter to work 
under Buster. Wishing to be a good FOSS citizen, I filed a bug report against 
the firmware-misc-nonfree (firmware-ralink) package (that was my best guess for 
the location of the problem).

The contents of the bug report and a follow-up message with more detail are 
here:

====== BUG REPORT FILED: === (contains details of the workaround 
mentioned above)
To: Debian Bug Tracking System 
Subject: firmware-ralink: none
X-Debbugs-Cc: none

Package: firmware-ralink
Version: 20180825+dfsg-1
Severity: normal

Dear Maintainer,

Under Debian Buster, a usb wi-fi adapter D-link DWA-130, rev. F1 can display 
available wifi services but could not connect
to any of them. An "ip link" command shows:

wlx74dada1c2b5d:  mtu 1500 qdisc mq state 
UP mode DORMANT group default qlen 1000
link/ether 74:da:da:1c:2b:5d brd ff:ff:ff:ff:ff:ff

The same D-link usb wifi adapter installed on a same make and model computer 
but running under Debian Jessie works without problem, able to connect to any 
chosen wifi service.
On that Debian Jessie system, ip link shows:

wlan0:  mtu 1500 qdisc mq state UP mode 
DORMANT group default qlen 1000
link/ether 74:da:da:1c:2b:5d brd ff:ff:ff:ff:ff:ff

I noted the difference in the generated device name between Buster and Jessie.

=== Workaround: ===
I am able to make the D-link usb wifi adapter work under Debian Buster by 
creating the file
/lib/udev/rules.d/70-wifi.rules

which contains this single line (address comes from device name 
"wlx74dada1c2b5d"):

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="74:da:da:1c:2b:5d", 
NAME="wlan0"

After rebooting the Debian Buster system with that file in place, the D-link usb wifi adapter 
works, and "ip link" shows the now shorter device name, "wlan0":

wlan0:  mtu 1500 qdisc mq state UP mode 
DORMANT group default qlen 1000
link/ether 74:da:da:1c:2b:5d brd ff:ff:ff:ff:ff:ff

The workaround solution comes from:
https://askubuntu.com/questions/826325/how-to-revert-usb-wifi-interface-name-from-wlx-to-wlanx

The discussion in that thread mentions a (Ubuntu studio) kernel having a low 
latency, wondering whether the long device name is the source of the problem?

I have not tried forcing names other than "wlan0" to determine whether it is 
"wlan0" that is magical or whether other names would work.

I would expect the D-link usb wifi adapter to work under Debian Buster without 
this workaround, as the adapter works fine under Jessie.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firmware-ralink depends on:
ii  firmware-misc-nonfree  20180825+dfsg-1

firmware-ralink recommends no packages.

firmware-ralink suggests no packages.

-- no debconf information
== END of BUG REPORT FILED 

= ADDITIONAL INFORMATION SENT TO BUG LIST =
Concerning bug 914920, sorry, the subject line ought to be something like "firmware 
rt2870 cannot connect until device name is shortened"

Here's more information about the firmware being
loaded when the system detects the D-link DWA-130 usb wifi adapter.

$ "dmesg | grep rt" excerpts:

[7.617423] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5392, rev 0223 
detected
[7.632788] ieee80211 phy0: rt2x00_set_r

[SOLVED] Re: Buster: Kvirc: Bug 908420: Am I the only one who's having this issue?

[local10]

Nov 29, 2018, 3:52 PM by etienne.moll...@mailoo.org:

> I'm not a user of Kvirc myself, sticking to irssi.  However, out
> of curiosity, I installed kvirc in a fully fledged KDE
> environment (package task-kde-desktop) to see if I could
> reproduce the problem.  And I believe I've been able to pinpoint
> something.
>
> It would seem that there is a trap with the naming convention of
> the configuration *file* ~/.config/kvirc and the configuration
> *directory* called ~/.config/KVIrc.  I've got both of these at
> the end of a clean install, and after the first pass of the
> wizard:
>
>  ~/.config/KVIrc/
>  ~/.config/kvirc
>

Yes.


> Currently, is your ~/.config/kvirc a file or a directory storing
> your configuration ?
>
> If that is a directory storing your configuration, what happens
> if you rename it as, say, ~/.config/KVIrc and try to load this
> one configuration directory instead?
>

I actually noticed it too and tried the trick with renaming directories before 
I filed the bug, it did not work for me. Now trying different things I found 
the winning combination I think that solves the issue:

1. Rename "old" ~/.config/kvirc into ~/.config/KVIrc
2. Create ~/.config/kvirc file (file, not folder) as follows:

$ ls -l ~/.config/kvirc
-rw--- 1 luser luser 76 Nov 29 17:34 /home/luser/.config/kvirc

$ cat ~/.config/kvirc
[Main]
LocalKvircDirectory=/home/luser/.config/KVIrc/
SourcesDate=538312962

The above solves the issue for me. The bug stands though as something really 
does not work right in the setup wizard.

Thanks for your help.

Re: Buster: Kvirc: Bug 908420: Am I the only one who's having this issue?

[Étienne Mollier]

local10, on 2018-11-29:
> Nov 27, 2018, 7:24 PM by loca...@tutanota.com:
> > Am I the only one who's having this issue? It's kind of
> > annoying and there's no response from the maintenance team:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908420
>
> Anyone using Kvirc at all? Thanks

Good Day,

I'm not a user of Kvirc myself, sticking to irssi.  However, out
of curiosity, I installed kvirc in a fully fledged KDE
environment (package task-kde-desktop) to see if I could
reproduce the problem.  And I believe I've been able to pinpoint
something.

It would seem that there is a trap with the naming convention of
the configuration *file* ~/.config/kvirc and the configuration
*directory* called ~/.config/KVIrc.  I've got both of these at
the end of a clean install, and after the first pass of the
wizard:

~/.config/KVIrc/
~/.config/kvirc

Currently, is your ~/.config/kvirc a file or a directory storing
your configuration ?

If that is a directory storing your configuration, what happens
if you rename it as, say, ~/.config/KVIrc and try to load this
one configuration directory instead?

Kind Regards,
-- 
Étienne Mollier 

Re: Buster: Kvirc: Bug 908420: Am I the only one who's having this issue?

[local10]

Nov 27, 2018, 7:24 PM by loca...@tutanota.com:

> Am I the only one who's having this issue? It's kind of annoying and there's 
> no response from the maintenance team:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908420 
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908420>
>

Anyone using Kvirc at all? Thanks

Buster: Kvirc: Bug 908420: Am I the only one who's having this issue?

[local10]

Hi,

Am I the only one who's having this issue? It's kind of annoying and there's no 
response from the maintenance team:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908420 
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908420>

Regards,

Re: Possible BUG: Unable to change the ip of network interfaces without reboot in text mode

[Greg Wooledge]

On Fri, Nov 23, 2018 at 11:39:48AM -0200, Luciano Andress Martini wrote:
> 2- Try to change the ip in /etc/network/interfaces
> 3- Run ifdown enp0s3
> 4- Run ifup enp0s3

Perhaps you want to do it this way instead:

2- ifdown enp0s3
3- edit /etc/network/interfaces
4- ifup enp0s3

Possible BUG: Unable to change the ip of network interfaces without reboot in text mode

[Luciano Andress Martini]

I am not sure if my answers are reaching the users because i did not
received it back so sorry to creating a new thread, but i think this
is very important, please follow this steps to emulate it:

1- Install Debian 9.6 without graphical interface.
2- Try to change the ip in /etc/network/interfaces
3- Run systemctl restart networking
ping 8.8.8.8
(network stopped working!)
If system is restarted everything is ok again, and ip is changed properly .

New try, now with ifdown and ifup:
1- Install Debian 9.6 without graphical interface.
2- Try to change the ip in /etc/network/interfaces
3- Run ifdown enp0s3
4- Run ifup enp0s3
5- That's right ,but now you have two ips configured instead of changing it.

Is this is expected, i am so sorry for boring you, i will get out of
here the faster as i can.




-- 
Luciano Andress Martini - Analista UNIX

Re: IT IS A BUG -- Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Curt]

On 2018-11-05, Greg Wooledge  wrote:
>
> In this case, he probably "told it to run in a terminal", and whether
> the terminal uses a login shell or not is irrelevant.  The fact that
> now it's running the program inside a terminal (or possibly a terminal
> plus a shell), instead of directly executing the program within an X11
> session but outside of a terminal, is what causes the changed behavior.

So this comes down to him running the vitiated program from a terminal
and therefore getting an error message (rather than dead silence) of
some sort (like, "Ouch, you clumsy brute, think I got prepended by a man
page and became inoperable") and believes this should be the default
behavior when running any and all programs/executables from his file
manager. 

> See my previous message in this thread for a discussion of the treatment
> of ENOEXEC by various shells and non-shell programs.
>
> It would be helpful if we knew *which* GUI launcher was in use.  Someone
> may know precisely how it operates, so we could avoid guesswork and
> assumptions.

I think he did mention Caja at one point.

> Also remember to whom you're responding here.  Richard Owlett has quite
> a reputation on this list, and some research into his past threads might
> be informative.
>
>


-- 
“If a person is not talented enough to be a novelist, not smart enough to be a
lawyer, and his hands are too shaky to perform operations, he becomes a
journalist.” --Norman Mailer 

Re: IT IS A BUG -- Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Greg Wooledge]

On Mon, Nov 05, 2018 at 12:31:11PM +, Andy Smith wrote:
> - You have a launcher file that references an executable. In normal
>   cases calling the launcher from your desktop environment (I don't
>   know if this is by menu or button or something else) causes the
>   binary to run. I'm assuming it is a command line binary and you've
>   told it to run in a terminal, so, the expected result is a
>   terminal window with this program running in it.

I would not assume that he "told it to run in a terminal".  I would
in fact assume the exact opposite.

> - You told the launcher to run a terminal with a login shell and now
>   it does do something to indicate there was a failure of the
>   binary.

In this case, he probably "told it to run in a terminal", and whether
the terminal uses a login shell or not is irrelevant.  The fact that
now it's running the program inside a terminal (or possibly a terminal
plus a shell), instead of directly executing the program within an X11
session but outside of a terminal, is what causes the changed behavior.

See my previous message in this thread for a discussion of the treatment
of ENOEXEC by various shells and non-shell programs.

It would be helpful if we knew *which* GUI launcher was in use.  Someone
may know precisely how it operates, so we could avoid guesswork and
assumptions.

Also remember to whom you're responding here.  Richard Owlett has quite
a reputation on this list, and some research into his past threads might
be informative.

Re: IT IS A BUG -- Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Andy Smith]

Hello,

On Mon, Nov 05, 2018 at 06:18:17AM -0600, Richard Owlett wrote:
> On 11/04/2018 07:34 AM, Andy Smith wrote:
> >I don't think the login shell setting has anything to do with it.
> 
> You obviously could not be bothered trying it!

I don't run any of the same software as you so it would be a lot of
work to try this out. I'm only trying to help you file the right bug
against the right software, but if that is not welcome just say so
and I am happy to leave you to it.

If I understand correctly:

- You have a launcher file that references an executable. In normal
  cases calling the launcher from your desktop environment (I don't
  know if this is by menu or button or something else) causes the
  binary to run. I'm assuming it is a command line binary and you've
  told it to run in a terminal, so, the expected result is a
  terminal window with this program running in it.

- You accidentally overwrote the binary with the textual output of
  "man" resulting in a file which was still marked executable but
  was not a valid Linux binary or script.

- Now when you call the launcher there is no visual feedback to
  indicate that there was a problem.

- You told the launcher to run a terminal with a login shell and now
  it does do something to indicate there was a failure of the
  binary.

- You therefore conclude that every launcher which uses a terminal
  should default to using a login shell and wish to file a bug to
  that effect.

I'm expressing disbelief that the terminal using a login shell is
what is making the difference, but you weren't clear about what the
difference actually is.

So, assuming I understand the situation (as above), what is the
actual difference in behaviour when you run this corrupt binary from
a launcher that is set to terminal+login as opposed to just
terminal?

Cheers,
Andy

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

"I remember the first time I made love.  Perhaps it was not love exactly but I
 made it and it still works." — The League Against Tedium

Re: IT IS A BUG -- Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Richard Owlett]

On 11/04/2018 07:34 AM, Andy Smith wrote:

On Sun, Nov 04, 2018 at 07:24:04AM -0600, Richard Owlett wrote:

Turns out there was a *YUCKY* choice for a default setting.
In the default profile for mate-terminal there is a choice titled
"Run command as a login shell".
The option is *not* enabled.

That makes the choice "given"(sic) by Caja of
"Run in terminal"
and
"Run"
moot.






I don't think the login shell setting has anything to do with it. 


You obviously could not be bothered trying it!

Re: IT IS A BUG -- Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Andy Smith]

On Sun, Nov 04, 2018 at 07:24:04AM -0600, Richard Owlett wrote:
> Turns out there was a *YUCKY* choice for a default setting.
> In the default profile for mate-terminal there is a choice titled
>"Run command as a login shell".
> The option is *not* enabled.
> 
> That makes the choice "given"(sic) by Caja of
>"Run in terminal"
> and
>"Run"
> moot.

I think your real issue here is that whatever this GUI launcher is,
it does nothing visible when told to launch an executable file that
is not a valid binary. It may have spewed some error into some log
file, but did not pop up a dialog saying "That isn't a valid binary"
or whatever. I don't think that you would get different results no
matter what setting you had for running terminals as login or not.

So if it bothers you that trying to execute garbage produces no
visible feedback, I think that is the bug you should file.

I don't think the login shell setting has anything to do with it. I
can't see why whether it is a login shell or not has any bearing on
what happens when the system tries to execute a file of junk.

$ dd if=/dev/urandom bs=1k count=100 of=/tmp/foo
100+0 records in
100+0 records out
102400 bytes (102 kB) copied, 0.0142731 s, 7.2 MB/s
$ chmod -c +x /tmp/foo
mode of ‘/tmp/foo’ changed from 0644 (rw-r--r--) to 0755 (rwxr-xr-x)
$ /tmp/foo
/tmp/foo: line 10: syntax error near unexpected token `('
bfooB�B��A�>O���g�  
[j%�9̋Ov��g��í�<���ᲾU��9hj�y3j��(�c5�S��S]Ub���l��)�xdƁU]D�Hho{�v�z� �=}3��
  
(���;g�:5��o���a\Yg��/�┘ˬ�R�L┬�·��*→·V&���d6TEeC/�ܨ�A�⎺�)/S���;O]Pڣ��⎼K���G┤�*ɾ%�π�!ĵ�5_";S��]
 c�$
N≠·(&%↓Z�V�│���L⎻/─�┌��7�ݢ≤←b���\ʿ┬:���*2��˸�ٜ���⎼>@'M[�;�K�⎺HL≤�ʠ
   ���→X@�;�πO$⎽@┴��≥⎺�C9π"≠�)8�⎼�R���)π�b�ߨ�┌π��/��Ѝ│ج�

┌���S(�↓⎺��▒�┌�◆ꍺ)H?#┘≥?�E_#��O#���1Џ�_�,̆
*ׅM� J*�c��%�==�KI��KH��GL≥$≤�=�!▮⎼�R�6�װ��UZ�m��d�'1Dsy"}R�)G
 
��q=[|�5C-M]2  0��!ԧG=q�j�hj'
$


Cheers,
Andy

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

IT IS A BUG -- Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Richard Owlett]

On 10/31/2018 09:14 AM, Richard Owlett wrote:

Debian 9.1 with MATE installed from DVD set.

Due a non-reproducible sequence of events, a binary executable was over 
written by the contents of a man page in pure text format. For unknown 
reason, the resulting file was tagged as executable.


A custom MATE launcher pointed the corrupted file.
When the launcher icon was clicked there was no response whatsoever.
Including *NO ERROR MESSAGE*
Is this a bug or a feature?
If a feature, why?


Turns out there was a *YUCKY* choice for a default setting.
In the default profile for mate-terminal there is a choice titled
   "Run command as a login shell".
The option is *not* enabled.

That makes the choice "given"(sic) by Caja of
   "Run in terminal"
and
   "Run"
moot.

I consider this a Debian, not Upstream, bug as each distro should be 
responsible for choosing their defaults.


Please contact me offline if you are willing to help a first time bug 
reporter.

TIA

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Curt]

On 2018-10-31, rhkra...@gmail.com  wrote:
>> >> 
>> >> Due a non-reproducible sequence of events, a binary executable was over
>> >> written by the contents of a man page in pure text format.
>> > 
>> > Just to (maybe?) help with the proper focus, was this a human error or
>> > something that seemed to happen without human intervention?
>> 
>> As I replied to Reco, "Cannot reproduce detailed PEBKAC ;< "
>
> Ok, then, it doesn't seem to indicate a disk problem (as some seemed to 
> suspect).
>

Yeah, I didn't get that hard drive failure part either but thought it
was a question of superior knowledge and cleverness on the part of Mr.
R.

The OP probably should have started by saying, "I don't know how, but I
fucked up and overwrote a binary executable with a man page," and then
we all could've had a good laugh. At least he's reading those man pages.
I do note, however, he didn't say *info* page. 

But I don't have a firm grasp of the issues involved here (if there are
any whatsoever), so I'll bow out (once again).

-- 
When you have fever you are heavy and light, you are small and swollen, you
climb endlessly a ladder which turns like a wheel. 
--Jean Rhys, Voyage in the Dark

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Richard Owlett]

On 10/31/2018 10:57 AM, rhkra...@gmail.com wrote:

On Wednesday, October 31, 2018 11:45:15 AM Richard Owlett wrote:

On 10/31/2018 10:31 AM, rhkra...@gmail.com wrote:

On Wednesday, October 31, 2018 10:14:40 AM Richard Owlett wrote:

Debian 9.1 with MATE installed from DVD set.

Due a non-reproducible sequence of events, a binary executable was over
written by the contents of a man page in pure text format.


Just to (maybe?) help with the proper focus, was this a human error or
something that seemed to happen without human intervention?


As I replied to Reco, "Cannot reproduce detailed PEBKAC ;< "


Ok, then, it doesn't seem to indicate a disk problem (as some seemed to
suspect).



Reco's comment that it could be a "(mis)feature" and Greg's response led 
me to investigate further. I'm personally convinced there is a bug 
having some aspects of being a "corner case".


I think I can create some repeatable test cases. It'll take some time.
I may not be a computer geek, but decades in engineering and/or customer 
support can be enlightening.

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[rhkramer]

On Wednesday, October 31, 2018 11:45:15 AM Richard Owlett wrote:
> On 10/31/2018 10:31 AM, rhkra...@gmail.com wrote:
> > On Wednesday, October 31, 2018 10:14:40 AM Richard Owlett wrote:
> >> Debian 9.1 with MATE installed from DVD set.
> >> 
> >> Due a non-reproducible sequence of events, a binary executable was over
> >> written by the contents of a man page in pure text format.
> > 
> > Just to (maybe?) help with the proper focus, was this a human error or
> > something that seemed to happen without human intervention?
> 
> As I replied to Reco, "Cannot reproduce detailed PEBKAC ;< "

Ok, then, it doesn't seem to indicate a disk problem (as some seemed to 
suspect).

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Richard Owlett]

On 10/31/2018 10:31 AM, rhkra...@gmail.com wrote:

On Wednesday, October 31, 2018 10:14:40 AM Richard Owlett wrote:

Debian 9.1 with MATE installed from DVD set.

Due a non-reproducible sequence of events, a binary executable was over
written by the contents of a man page in pure text format.


Just to (maybe?) help with the proper focus, was this a human error or
something that seemed to happen without human intervention?


As I replied to Reco, "Cannot reproduce detailed PEBKAC ;< "





For unknown
reason, the resulting file was tagged as executable.

A custom MATE launcher pointed the corrupted file.
When the launcher icon was clicked there was no response whatsoever.
Including *NO ERROR MESSAGE*
Is this a bug or a feature?
If a feature, why?

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[rhkramer]

On Wednesday, October 31, 2018 10:14:40 AM Richard Owlett wrote:
> Debian 9.1 with MATE installed from DVD set.
> 
> Due a non-reproducible sequence of events, a binary executable was over
> written by the contents of a man page in pure text format. 

Just to (maybe?) help with the proper focus, was this a human error or 
something that seemed to happen without human intervention?


> For unknown
> reason, the resulting file was tagged as executable.
> 
> A custom MATE launcher pointed the corrupted file.
> When the launcher icon was clicked there was no response whatsoever.
> Including *NO ERROR MESSAGE*
> Is this a bug or a feature?
> If a feature, why?

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Richard Owlett]

On 10/31/2018 09:27 AM, Reco wrote:

Hi.

On Wed, Oct 31, 2018 at 09:14:40AM -0500, Richard Owlett wrote:

Debian 9.1 with MATE installed from DVD set.

Due a non-reproducible sequence of events, a binary executable was over written 
by the contents of a man page in pure text format. For unknown reason, the
resulting file was tagged as executable.


Replace your HDD today, don't give it another chance to corrupt your
data.



Cannot reproduce detailed PEBKAC ;<




A custom MATE launcher pointed the corrupted file.
When the launcher icon was clicked there was no response whatsoever.
Including *NO ERROR MESSAGE*
Is this a bug or a feature?
If a feature, why?


A (mis)feature. Any executable text file without defined shebang is a
shell script. In this case - a syntactically invalid shell script.
So it can be executed, but the child shell will exit immediately.


I think I understand.
Thank you.

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Gene Heskett]

On Wednesday 31 October 2018 10:39:17 Gene Heskett wrote:

> On Wednesday 31 October 2018 10:31:40 Reco wrote:
> > Hi.
> >
> > On Wed, Oct 31, 2018 at 09:29:52AM -0500, Richard Owlett wrote:
> > > On 10/31/2018 09:18 AM, Curt wrote:
> > > > On 2018-10-31, Richard Owlett  wrote:
> > > > > Debian 9.1 with MATE installed from DVD set.
> > > > >
> > > > > Due a non-reproducible sequence of events, a binary executable
> > > > > was over written by the contents of a man page in pure text
> > > > > format. For unknown reason, the resulting file was tagged as
> > > > > executable.
> > > >
> > > > I want to predict immediately that this can of worms will
> > > > produce the longest thread in the history of debian user.
>
> And will follow that rule about opening a can of worms will also
> immediately at least double the size of the can to put them back into.

Correction inserted above, this keyboard is a great keyboard around messy 
machinery, but it silently shifts from insert to overwrite mode entirely 
too easily with my short, somewhat fat fingers trying to type rapidly on 
it. So adjacent keys get pushed which apparently interpreted as the 
magic twanger that controls that particular function.

> > > ONLY if members of this group can't or wont read.
> > > I believe I rigorously complied with
> > > [http://www.catb.org/esr/faqs/smart-questions.html]
> >
> > 'smartctl -a /dev/sda' output would be nice, but I won't insist on
> > it.

I will. Show us Richard.

> > Reco



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Curt]

On 2018-10-31, Richard Owlett  wrote:
> On 10/31/2018 09:18 AM, Curt wrote:
>> On 2018-10-31, Richard Owlett  wrote:
>>> Debian 9.1 with MATE installed from DVD set.
>>>
>>> Due a non-reproducible sequence of events, a binary executable was over
>>> written by the contents of a man page in pure text format. For unknown
>>> reason, the resulting file was tagged as executable.
>> 
>> I want to predict immediately that this can of worms will produce the
>> longest thread in the history of debian user.
>
> ONLY if members of this group can't or wont read.
> I believe I rigorously complied with
> [http://www.catb.org/esr/faqs/smart-questions.html]
>

I guess I stumbled immediately upon "non-reproducible sequence of
events." Then I kind of wondered, like, well, can those events be
briefly described, at least? Or maybe 'non-reproducible' means you just
don't know what the hell happened? 

But Reco extracted marrow from your post, and I will gracefully bow
out now and let you boys have at it without further ado.

>> 
>>> A custom MATE launcher pointed the corrupted file.
>>> When the launcher icon was clicked there was no response whatsoever.
>>> Including *NO ERROR MESSAGE*
>>> Is this a bug or a feature?
>>> If a feature, why?
>>>
>>>
>>>
>> 
>> 
>
>
>


-- 
When you have fever you are heavy and light, you are small and swollen, you
climb endlessly a ladder which turns like a wheel. 
--Jean Rhys, Voyage in the Dark

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Greg Wooledge]

On Wed, Oct 31, 2018 at 05:27:58PM +0300, Reco wrote:
> A (mis)feature. Any executable text file without defined shebang is a
> shell script.

Not quite.  An attempt to execute a file that doesn't have a valid magic
number in the first few bytes triggers an ENOEXEC from the execve(2) call.
If this attempt was made by a C program, then that's that.  You handle
the error however you choose to handle it.

However, it the attempt to execute the file was done by a shell, then
the shell will typically catch the ENOEXEC and then make a second attempt.
The exact mechanism for this secondary attempt depends on the shell.
Bash reads the first hundred bytes or so looking for NUL bytes.   If it
sees a NUL byte, it decides the file is *not* a script, and you get
"Exec format error" printed on stderr.  If there are no NUL bytes, then
bash launches a child bash process to read the file as a script.

Other shells may launch a copy of themselves, or they may choose to
launch /bin/sh or sh instead, or they may print an error.  GNU's find
-exec launches sh, but I'm uncertain whether that's a GNUism, or a de
facto standard practice.

> In this case - a syntactically invalid shell script.
> So it can be executed, but the child shell will exit immediately.

If there's a syntax error, you'd expect to see a message.  It's possible
that the "script" simply does nothing (e.g. it runs "exit" or "exec true"
or something similar before any commands that would produce output or
errors).

There's really no way to be more precise without a copy of the file's
content for analysis, and some knowledge of how and in what environment
the OP attempted to execute it.  And we all know that these things will
not be provided.

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Gene Heskett]

On Wednesday 31 October 2018 10:31:40 Reco wrote:

>   Hi.
>
> On Wed, Oct 31, 2018 at 09:29:52AM -0500, Richard Owlett wrote:
> > On 10/31/2018 09:18 AM, Curt wrote:
> > > On 2018-10-31, Richard Owlett  wrote:
> > > > Debian 9.1 with MATE installed from DVD set.
> > > >
> > > > Due a non-reproducible sequence of events, a binary executable
> > > > was over written by the contents of a man page in pure text
> > > > format. For unknown reason, the resulting file was tagged as
> > > > executable.
> > >
> > > I want to predict immediately that this can of worms will produce
> > > the longest thread in the history of debian user.
> >
> > ONLY if members of this group can't or wont read.
> > I believe I rigorously complied with
> > [http://www.catb.org/esr/faqs/smart-questions.html]
>
> 'smartctl -a /dev/sda' output would be nice, but I won't insist on it.
>
How about this Richard, let us see what smartctl thinks about this drives 
health. So I'll insist on seeing it. Please post its output.

> Reco



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Gene Heskett]

On Wednesday 31 October 2018 10:31:40 Reco wrote:

>   Hi.
>
> On Wed, Oct 31, 2018 at 09:29:52AM -0500, Richard Owlett wrote:
> > On 10/31/2018 09:18 AM, Curt wrote:
> > > On 2018-10-31, Richard Owlett  wrote:
> > > > Debian 9.1 with MATE installed from DVD set.
> > > >
> > > > Due a non-reproducible sequence of events, a binary executable
> > > > was over written by the contents of a man page in pure text
> > > > format. For unknown reason, the resulting file was tagged as
> > > > executable.
> > >
> > > I want to predict immediately that this can of worms will produce
> > > the longest thread in the history of debian user.
> >
And will follow that rule about opening a can of worms will also 
immediately at least the size of the can to put them back into.

> > ONLY if members of this group can't or wont read.
> > I believe I rigorously complied with
> > [http://www.catb.org/esr/faqs/smart-questions.html]
>
> 'smartctl -a /dev/sda' output would be nice, but I won't insist on it.
>
> Reco



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Reco]

Hi.

On Wed, Oct 31, 2018 at 09:29:52AM -0500, Richard Owlett wrote:
> On 10/31/2018 09:18 AM, Curt wrote:
> > On 2018-10-31, Richard Owlett  wrote:
> > > Debian 9.1 with MATE installed from DVD set.
> > > 
> > > Due a non-reproducible sequence of events, a binary executable was over
> > > written by the contents of a man page in pure text format. For unknown
> > > reason, the resulting file was tagged as executable.
> > 
> > I want to predict immediately that this can of worms will produce the
> > longest thread in the history of debian user.
> 
> ONLY if members of this group can't or wont read.
> I believe I rigorously complied with
> [http://www.catb.org/esr/faqs/smart-questions.html]

'smartctl -a /dev/sda' output would be nice, but I won't insist on it.

Reco

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Richard Owlett]

On 10/31/2018 09:18 AM, Curt wrote:

On 2018-10-31, Richard Owlett  wrote:

Debian 9.1 with MATE installed from DVD set.

Due a non-reproducible sequence of events, a binary executable was over
written by the contents of a man page in pure text format. For unknown
reason, the resulting file was tagged as executable.


I want to predict immediately that this can of worms will produce the
longest thread in the history of debian user.


ONLY if members of this group can't or wont read.
I believe I rigorously complied with
[http://www.catb.org/esr/faqs/smart-questions.html]





A custom MATE launcher pointed the corrupted file.
When the launcher icon was clicked there was no response whatsoever.
Including *NO ERROR MESSAGE*
Is this a bug or a feature?
If a feature, why?

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Reco]

Hi.

On Wed, Oct 31, 2018 at 09:14:40AM -0500, Richard Owlett wrote:
> Debian 9.1 with MATE installed from DVD set.
> 
> Due a non-reproducible sequence of events, a binary executable was over 
> written by the contents of a man page in pure text format. For unknown 
> reason, the
> resulting file was tagged as executable.

Replace your HDD today, don't give it another chance to corrupt your
data.


> A custom MATE launcher pointed the corrupted file.
> When the launcher icon was clicked there was no response whatsoever.
> Including *NO ERROR MESSAGE*
> Is this a bug or a feature?
> If a feature, why?

A (mis)feature. Any executable text file without defined shebang is a
shell script. In this case - a syntactically invalid shell script.
So it can be executed, but the child shell will exit immediately.

Reco

Re: Strangeness when binary executable overwritten by text -- bug or feature?

[Curt]

On 2018-10-31, Richard Owlett  wrote:
> Debian 9.1 with MATE installed from DVD set.
>
> Due a non-reproducible sequence of events, a binary executable was over 
> written by the contents of a man page in pure text format. For unknown 
> reason, the resulting file was tagged as executable.

I want to predict immediately that this can of worms will produce the
longest thread in the history of debian user.

> A custom MATE launcher pointed the corrupted file.
> When the launcher icon was clicked there was no response whatsoever.
> Including *NO ERROR MESSAGE*
> Is this a bug or a feature?
> If a feature, why?
>
>
>


-- 
When you have fever you are heavy and light, you are small and swollen, you
climb endlessly a ladder which turns like a wheel. 
--Jean Rhys, Voyage in the Dark

Strangeness when binary executable overwritten by text -- bug or feature?

[Richard Owlett]

Debian 9.1 with MATE installed from DVD set.

Due a non-reproducible sequence of events, a binary executable was over 
written by the contents of a man page in pure text format. For unknown 
reason, the resulting file was tagged as executable.


A custom MATE launcher pointed the corrupted file.
When the launcher icon was clicked there was no response whatsoever.
Including *NO ERROR MESSAGE*
Is this a bug or a feature?
If a feature, why?

Re: bug a l'X session?

[Ernest Adrogué]

Alex Muntada  writes:
> Anava a suggerir-te que per aquestes coses provis el shellcheck
> però veig que la recomanació que dóna és diferent:
>
> In gpg-tty.sh line 2:
> export GPG_TTY=$(tty)
>^-- SC2155: Declare and assign separately to avoid masking return 
> values.
>
> No tinc clar si t'hauria ajudat a trobar el problema però a mi
> m'ha estat d'ajuda en diverses ocasions fer cas de les seves
> recomanacions.

Gràcies... no coneixia aquesta eina.  Aquest cop ho he trobat activant
l'opció set -x a l'inici de l'script.  Aquesta opció mostra l'expansió
de la línia d'ordres abans d'executar-se, i amb això he vist de seguida
on era l'error.

Re: bug a l'X session?

[Alex Muntada]

Hola Ernest,

> Sí, era aquesta línia:
> 
> export GPG_TTY=$(tty)
> 
> ...
> 
> La solució és posar-ho entre cometes
> 
> export GPG_TTY="$(tty)"

Anava a suggerir-te que per aquestes coses provis el shellcheck
però veig que la recomanació que dóna és diferent:

In gpg-tty.sh line 2:
export GPG_TTY=$(tty)
   ^-- SC2155: Declare and assign separately to avoid masking return values.

No tinc clar si t'hauria ajudat a trobar el problema però a mi
m'ha estat d'ajuda en diverses ocasions fer cas de les seves
recomanacions.

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer - log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: bug a l'X session?

[Ernest Adrogué]

Antoni Villalonga  writes:
> Em sembla que alguna comanda dona un error i aquest s'acaba parsejant
> malament, resultant un error extrany.

Sí, era aquesta línia:

export GPG_TTY=$(tty)

L'ordre tty tornava el text "no és un tty", de manera que després de
la substitució quedava

export GPG_TTY=no és un tty

per tant, l'intèrpret assignava a la variable GPG_TTY el valor "no" i
després intentava exportar les variables "GPG_TTY", "és", "un" i "tty".

Quan estava en anglès no era un error perquè feia

export GPG_TTY=not a tty

i les variables "a", i "tty" són vàlides.

La solució és posar-ho entre cometes

export GPG_TTY="$(tty)"

Re: bug a l'X session?

[Antoni Villalonga]

Hola,

Em sembla que alguna comanda dona un error i aquest s'acaba parsejant
malament, resultant un error extrany.

També podries provar un altre wm.

Això pot servir com a wm dummy. Si aguanta 30 segons sense tornar al gestor
de sessions

#!/usr/bin/env bash
sleep 30

Més facil és instalar un altre wm. dwm, per exemple.

Provar amb altres idiomes també pot ajudar a diagnosticar el problema.

Salut!

On Wednesday, October 17, 2018, Ernest Adrogué  wrote:

> Hola,
>
> tictacbum  writes:
> > que hi tens a la línia 43 del /etc/X11/Xsession? al meu hi tinc un
> > comentari, per això m'estranya que et salti a aquesta línia
>
> Sí, hi ha un comentari.  És l'Xsession de Debian, no l'he tocat.  Diria
> que el número de línia no és fiable, perquè l'Xsession afegeix altres
> scripts i llavors els números de línia no corresponen amb els del fitxer
> Xsession.  Abans he fet un grep recursiu al directori /etc i no he
> trobat cap export sospitós.
>
> > has provat de comentar tot el de .environment excepte l'export
> > LANG="ca_ES.UTF-8" i provar d'entrar a veure si peta?
>
> És el que he fet... primer l'he comentat tot i llavors he anat
> descomentant per parts.  El problema apareix específicament quan
> descomento l'export del LANG.  Tots els altres exports no provoquen cap
> problema.
>
>

-- 
"You hear about the chinese godfather? He made them an offer they couldn't
understand." - The Sopranos 1x04

Antoni Villalonga i Noceras
#Bloc# ~> http://friki.cat/
#Twitter# ~> @friki

Re: bug a l'X session?

[Ernest Adrogué]

Hola,

tictacbum  writes:
> que hi tens a la línia 43 del /etc/X11/Xsession? al meu hi tinc un
> comentari, per això m'estranya que et salti a aquesta línia

Sí, hi ha un comentari.  És l'Xsession de Debian, no l'he tocat.  Diria
que el número de línia no és fiable, perquè l'Xsession afegeix altres
scripts i llavors els números de línia no corresponen amb els del fitxer
Xsession.  Abans he fet un grep recursiu al directori /etc i no he
trobat cap export sospitós.

> has provat de comentar tot el de .environment excepte l'export
> LANG="ca_ES.UTF-8" i provar d'entrar a veure si peta?

És el que he fet... primer l'he comentat tot i llavors he anat
descomentant per parts.  El problema apareix específicament quan
descomento l'export del LANG.  Tots els altres exports no provoquen cap
problema.

Re: bug a l'X session?

[tictacbum]

Hola Ernest,
que hi tens a la línia 43 del /etc/X11/Xsession? al meu hi tinc un
comentari, per això m'estranya que et salti a aquesta línia
has provat de comentar tot el de .environment excepte l'export
LANG="ca_ES.UTF-8" i provar d'entrar a veure si peta?

salut!
Lluís

Missatge de Ernest Adrogué  del dia dc., 17 d’oct. 2018 a
les 19:09:

>
> Hola,
>
> Si intento entrar amb el login gràfic lightdm, surt immediatament i em
> torna a la pantalla de login.  Al fitxer .xsession-errors hi ha les
> següents línies
>
> dbus-update-activation-environment: setting
> DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
> dbus-update-activation-environment: setting DISPLAY=:0
> dbus-update-activation-environment: setting
> XAUTHORITY=/home/ernest/.Xauthority
> /etc/X11/Xsession: 43: export: és: bad variable name
>
> O sigui, entenc que algú està intentant exportar la variable "és", i com
> que "és" no és un nom de variable vàlid, la sessió X s'atura en aquest
> punt.
>
> En el .xsessionrc només hi tinc això:
>
> if [ -r "${HOME}/.environment" ]; then
> . "${HOME}/.environment"
> fi
>
> I en el .environment he vist que si comento la línia
>
> export LANG="ca_ES.UTF-8"
>
> l'error desapareix.  A partir d'aquí ja no sé a on mirar.  Alguna idea?
>
>

bug a l'X session?

[Ernest Adrogué]

Hola,

Si intento entrar amb el login gràfic lightdm, surt immediatament i em
torna a la pantalla de login.  Al fitxer .xsession-errors hi ha les
següents línies

dbus-update-activation-environment: setting 
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting XAUTHORITY=/home/ernest/.Xauthority
/etc/X11/Xsession: 43: export: és: bad variable name

O sigui, entenc que algú està intentant exportar la variable "és", i com
que "és" no és un nom de variable vàlid, la sessió X s'atura en aquest
punt.

En el .xsessionrc només hi tinc això:

if [ -r "${HOME}/.environment" ]; then
. "${HOME}/.environment"
fi

I en el .environment he vist que si comento la línia

export LANG="ca_ES.UTF-8"

l'error desapareix.  A partir d'aquí ja no sé a on mirar.  Alguna idea?

Re: Unable To Determine Proper Package For BUG

[Roberto C . Sánchez]

On Mon, Oct 15, 2018 at 11:23:11AM -0500, Jeff Rickman wrote:
> 
> Should this be filed somewhere in Debian and if so which package?
> 
See my comment at the end.

> FYI - No, the impacted system does not support "reportbug" because the
> system is heavily firewalled for secuity reasons.
> 
You can still install reportbug, use it to generate the report, save it
to a file (this is one of the actions reportbug lets you take at the end
instead of sending), then transfer the file to a system from which you
can send the port.

> 
> [ 6787.703456] list_add corruption. next->prev should be prev
> (0533875c), but was c2b0df70. (next=c2b0df70).
> [ 6787.703475] [ cut here ]
> [ 6787.703477] kernel BUG at
> /build/linux-43CEzF/linux-4.16.12/lib/list_debug.c:25!
> [ 6787.703578] invalid opcode:  [#1] SMP PTI

I am not an expert, but the file name (lib/list_debug.c) suggests that
the problem exists in the actual kernel core itself, instead of in a
module or something like that.

I would start by searching the existing kernel bug reports in Debian
for references to that file.  If one exists, you can add your
information there and perhaps it will help achieve resolution.  If not,
you can create a new bug report.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Unable To Determine Proper Package For BUG

[Jeff Rickman]

I have a syslog capture of a BUG that I seem to routinely hit under 
specific circumstances.


I have other details that might be of interest to whomever is interested 
in this BUG. For example, this is a fully updated Debian "buster" system 
with a ext4 (OS) and ZFS (storage array) filesystems on it.


Should this be filed somewhere in Debian and if so which package?

FYI - No, the impacted system does not support "reportbug" because the 
system is heavily firewalled for secuity reasons.



[ 6787.703456] list_add corruption. next->prev should be prev 
(0533875c), but was c2b0df70. (next=c2b0df70).

[ 6787.703475] [ cut here ]
[ 6787.703477] kernel BUG at 
/build/linux-43CEzF/linux-4.16.12/lib/list_debug.c:25!

[ 6787.703578] invalid opcode:  [#1] SMP PTI
[ 6787.703625] Modules linked in: zfs(PO) zunicode(PO) zavl(PO) icp(PO) 
iTCO_wdt iTCO_vendor_support zcommon(PO) znvpair(PO) spl(O) intel_rapl 
intel_soc_dts_thermal intel_soc_dts_iosf intel_powerclamp 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate pcspkr 
lpc_ich igb i2c_i801 i915 dca sg drm_kms_helper video drm i2c_algo_bit 
button w83627ehf hwmon_vid coretemp autofs4 ext4 crc16 mbcache jbd2 
crc32c_generic fscrypto ecb crypto_simd cryptd glue_helper aes_x86_64 
evdev hid_generic usbhid hid sd_mod xhci_pci crc32c_intel xhci_hcd ahci 
libahci libata usbcore usb_common fan scsi_mod thermal
[ 6787.704159] CPU: 0 PID: 406 Comm: spl_dynamic_tas Tainted: P 
 O 4.16.0-2-amd64 #1 Debian 4.16.12-1

[ 6787.704254] Hardware name: Supermicro X10SBA/X10SBA, BIOS 1.3 01/31/2018
[ 6787.704325] RIP: 0010:__list_add_valid+0x36/0x70
[ 6787.704371] RSP: 0018:bf78c1ddfc98 EFLAGS: 00010082
[ 6787.704425] RAX: 0075 RBX: 9d1abfda1940 RCX: 

[ 6787.704494] RDX:  RSI: 9d1abfc16738 RDI: 
9d1abfc16738
[ 6787.704563] RBP: 9d1aaa859b80 R08: 0328 R09: 
0003
[ 6787.704631] R10:  R11: 0001 R12: 
9d1abfda18c0
[ 6787.704699] R13: 9d1aaa859bb0 R14: 9d1aaa859bb0 R15: 
9d1abfda22e0
[ 6787.704768] FS:  () GS:9d1abfc0() 
knlGS:

[ 6787.704845] CS:  0010 DS:  ES:  CR0: 80050033
[ 6787.704901] CR2: 5623e6ae2bd0 CR3: 73c0a000 CR4: 
001006f0

[ 6787.704970] Call Trace:
[ 6787.705004]  account_entity_enqueue+0xc5/0xf0
[ 6787.705052]  enqueue_entity+0x98/0x640
[ 6787.705094]  enqueue_task_fair+0x67/0x7e0
[ 6787.705139]  ? sched_clock+0x5/0x10
[ 6787.705179]  set_user_nice.part.70+0x183/0x1e0
[ 6787.705248]  taskq_thread_create+0xe1/0x100 [spl]
[ 6787.705306]  taskq_thread_spawn_task+0xe/0x30 [spl]
[ 6787.705362]  taskq_thread+0x2d1/0x530 [spl]
[ 6787.705408]  ? wake_up_q+0x70/0x70
[ 6787.705452]  ? taskq_thread_spawn+0x50/0x50 [spl]
[ 6787.705501]  kthread+0x113/0x130
[ 6787.705537]  ? kthread_create_worker_on_cpu+0x70/0x70
[ 6787.705591]  ret_from_fork+0x35/0x40
[ 6787.705631] Code: 18 48 8b 10 4c 39 c2 75 24 48 39 c7 74 33 48 39 d7 
74 2e b8 01 00 00 00 c3 48 89 d1 48 c7 c7 f0 e5 e5 84 48 89 c2 e8 d4 c5 
d3 ff <0f> 0b 48 89 c1 4c 89 c6 48 c7 c7 78 e6 e5 84 e8 c0 c5 d3 ff 0f

[ 6787.705860] RIP: __list_add_valid+0x36/0x70 RSP: bf78c1ddfc98
[ 6787.705922] ---[ end trace de26ea3fb015155e ]---

Re: openssl 1.1.1-1: bug?

[Reco]

Hi.

On Fri, Oct 05, 2018 at 12:41:44PM +0200, Pétùr wrote:
> Hi,
> 
> I cannot connect to WPA2 Entreprise network (PEAP + MSCHAPv2) with
> openssl 1.1.1-1 (in sid today). I can connect 1.1.0f-3+deb9u2 version
> (stable).
> 
> Is it a bug in openssl 1.1.1-1 or some kind of incompatibility between
> openssl 1.1.1-1 and my radius server?

No, it's considered a feature. openssl=1.1.1-1 changelog has this
wonderful entry:

openssl (1.1.1~~pre3-1) experimental; urgency=medium

...
  * Enable system default config to enforce TLS1.2 as a minimum.

 -- Sebastian Andrzej Siewior   Wed, 21 Mar 2018 
00:01:08 +0100


> The error log with the 1.1.1-1 version says:
> 
> Tue Oct  2 14:07:43 2018 : Error: TLS Alert write:fatal:protocol version
> Tue Oct  2 14:07:43 2018 : Error: rlm_eap: SSL error error:1408F10B:SSL
> routines:SSL3_GET_RECORD:wrong version number

Meaning that - if your RADIUS can only do SSLv3, and not higher (that's
what the log says) - your openssl won't use it whatever. Because
security.


You could try to file a wishlist bug against src:openssl and ask to
revert the change, but I predict that the answer would be 'fix your
RADIUS'.

Reco

openssl 1.1.1-1: bug?

[Pétùr]

Hi,

I cannot connect to WPA2 Entreprise network (PEAP + MSCHAPv2) with
openssl 1.1.1-1 (in sid today). I can connect 1.1.0f-3+deb9u2 version
(stable).

Is it a bug in openssl 1.1.1-1 or some kind of incompatibility between
openssl 1.1.1-1 and my radius server?

The error log with the 1.1.1-1 version says:

Tue Oct  2 14:07:43 2018 : Error: TLS Alert write:fatal:protocol version
Tue Oct  2 14:07:43 2018 : Error: rlm_eap: SSL error error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number
Tue Oct  2 14:07:43 2018 : Error: SSL: SSL_read failed in a system call
(-1), TLS session fails.
Tue Oct  2 14:07:43 2018 : Auth: Login incorrect (TLS Alert
write:fatal:protocol version): [lo...@myuniversity.com]

Pétùr

Re: Cannot update the Debian bug 896911

[Brian]

On Fri 14 Sep 2018 at 14:32:36 -0500, Richard Owlett wrote:

> On 09/14/2018 01:57 AM, Yanhui He wrote:
> > Hi,
> > 
> > I need to update a 3rd PR to Debian by sending mail
> > to896...@bugs.debian.org <mailto:896...@bugs.debian.org>, but it always
> > failed.
> > 
> > Would you please help me take a look?
> > 
> > --Error Details--
> > 
> > Reported error:
> > 
> >     
> > 
> > /550 5.0.350 Remote server returned an error -> 550 Unknown or archived bug/
> > 
> > DSN generated by:
> > 
> > 
> > 
> > BYAPR05MB4613.namprd05.prod.outlook.com
> > 
> > Remote server:
> > 
> > 
> > 
> > buxtehude.debian.org
> > 
> > If the email receiver is not correct, please help me forward it to the
> > right receiver.
> > 
> > Thanks!
> > 
> > --
> > 
> > Best Regards,
> > 
> > Yanhui
> > 
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+896911 states:
> 
> > Reported by: Shraddha Joshi 
> > 
> > Date: Wed, 25 Apr 2018 18:36:02 UTC
> > 
> > Severity: normal
> > 
> > Found in version linux/4.9.88-1
> > 
> > Fixed in version 4.16-1~exp1
> > 
> > Done: Ben Hutchings 
> > 
> > Bug is archived. No further changes may be made.
> 
> Note the last lines. I believe you will have to open a new bug.

It might be better to do as you suggest. But a bug can be unarchived.

-- 
Brian.

Re: Cannot update the Debian bug 896911

[Brian]

On Fri 14 Sep 2018 at 21:29:41 +0200, Thomas Schmitt wrote:

[snip]

> So if you do not feel entitled (or are not allowed) to send the
> "unarchive" command, then consider to contact Ben Hutchings and to ask
> about the forth-and-back in that bug.

Nobody is disallowed from writing to any bug report or manipulating
it. That is one of the strengths of Debian.

-- 
Brian.

Re: Cannot update the Debian bug 896911

[Richard Owlett]

On 09/14/2018 01:57 AM, Yanhui He wrote:

Hi,

I need to update a 3rd PR to Debian by sending mail 
to896...@bugs.debian.org <mailto:896...@bugs.debian.org>, but it always 
failed.


Would you please help me take a look?

--Error Details--

Reported error:



/550 5.0.350 Remote server returned an error -> 550 Unknown or archived bug/

DSN generated by:



BYAPR05MB4613.namprd05.prod.outlook.com

Remote server:



buxtehude.debian.org

If the email receiver is not correct, please help me forward it to the 
right receiver.


Thanks!

--

Best Regards,

Yanhui



https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+896911 states:


Reported by: Shraddha Joshi 

Date: Wed, 25 Apr 2018 18:36:02 UTC

Severity: normal

Found in version linux/4.9.88-1

Fixed in version 4.16-1~exp1

Done: Ben Hutchings 

Bug is archived. No further changes may be made.


Note the last lines. I believe you will have to open a new bug.

Re: Cannot update the Debian bug 896911

[Thomas Schmitt]

Hi,

Yanhui He wrote:
> I need to update a 3rd PR to Debian by sending mail
> to 896...@bugs.debian.org, but it always failed.
> 550 5.0.350 Remote server returned an error -> 550 Unknown or archived bug

The bug tracker page
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896911
says
  Bug is archived. No further changes may be made.

This can be revoked. See
  https://www.debian.org/Bugs/server-control#unarchive

It already happened once to that bug:
  Bug unarchived. Request was from Ben Hutchings 
  to cont...@bugs.debian.org. (Sat, 28 Jul 2018 02:36:03 GMT)
but then again:
  Bug archived. Request was from Debbugs Internal Request
   to internal_cont...@bugs.debian.org. 

So if you do not feel entitled (or are not allowed) to send the
"unarchive" command, then consider to contact Ben Hutchings and to ask
about the forth-and-back in that bug.


Have a nice day :)

Thomas

Cannot update the Debian bug 896911

[Yanhui He]

Hi,

I need to update a 3rd PR to Debian by sending mail to 
896...@bugs.debian.org<mailto:896...@bugs.debian.org>, but it always failed.

Would you please help me take a look?

--Error Details--

Reported error:

550 5.0.350 Remote server returned an error -> 550 Unknown or archived bug

DSN generated by:

BYAPR05MB4613.namprd05.prod.outlook.com

Remote server:

buxtehude.debian.org



If the email receiver is not correct, please help me forward it to the right 
receiver.

Thanks!
--
Best Regards,
Yanhui

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Brad Rogers]

On Tue, 11 Sep 2018 21:24:42 -0400
Ric Moore  wrote:

Hello Ric,

>Works a charm for me, and has for years, BUT every once in awhile 

As it does for many, I'm sure.

>the volume levels back up to 100%. Pulse rides on top of alsa, so alsa

And that's a problem.  Now, if sound goes wrong there are *two* things
to look at; ALSA & PA.  Sod's Law says I pick the wrong one to look at
first.  And that assumes there's breakage in either PA or ALSA.  There
is, of course, a third possibility - breakage in PA *and* ALSA.

I don't want to go there:  LTS.

>I also recommend cheap USB sound devices as they seem to always work. 

Except I see that Joe is having issues with a USB sound device.
Although, to be fair, the problem appears to be with sound modules,
rather than PA/ALSA.

>Whatever passes for a sound device on my laptop never seems to work,

Laptops are often a nightmare.  Not just with sound.  Shortcuts are
often taken to a) get everything inside a small enough box and b) keep
costs down.  Any deficiencies then have to be catered for in software.
Easy in Windows, since every manufacturer wants their machines to sell in
that environment.  Not so easy in Linux if the manufacturer won't
release detailed specs about their corner/cost cutting.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Gary don't need his eyes to see, Gary and his eyes have parted company
Gary Gilmore's Eyes - The Adverts


pgp0GlG3agYte.pgp
Description: OpenPGP digital signature

Re: bug

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Sep 11, 2018 at 08:28:02PM -0500, james wrote:
> E: The value 'stable-updates' is invalid for APT::Default-Release as
> such a release is not available in the sources
> E: _cache->open() failed, please report.

Please post here the contents of your /etc/apt/sources.list (and of
any file in the directory /etc/apt/sources.list.d/ if there is any).

Don't hesitate to ask if those instructions are not clear to you.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAluYxeYACgkQBcgs9XrR2kYEXACcDWAuUowa4XZ7vtdKQlBaH7uD
eZ0An3bsci1T3LeBK1XrbqRxUjz/HuTV
=q8WG
-END PGP SIGNATURE-

bug

[james]

E: The value 'stable-updates' is invalid for APT::Default-Release as 
such a release is not available in the sources

E: _cache->open() failed, please report.

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Ric Moore]

On 09/10/2018 08:27 AM, Brad Rogers wrote:

On Mon, 10 Sep 2018 11:53:01 + (UTC)
Curt  wrote:

Hello Curt,


So uninstall it then in that unfortunate case--with extreme prejudice


Time.

Oh, and I can't be arsed to try PA in the first place.   :-)


Or are we dealing with the supernatural here (software from Hell)?


I'm wary because of all the tales of woe I've read.  Obviously, there
are plenty of ppl for whom PA causes no problems at all.


Works a charm for me, and has for years, BUT every once in awhile 
something buggers alsa settings and I have to use alsamixer to raise the 
volume levels back up to 100%. Pulse rides on top of alsa, so alsa has 
to be working before pulse can do it's thing.


I also recommend cheap USB sound devices as they seem to always work. 
Whatever passes for a sound device on my laptop never seems to work, but 
plugging in a pair of USB headphones always does. Ric




--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: [beginning OT] Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[rhkramer]

On Monday, September 10, 2018 09:37:28 AM Thomas Schmitt wrote:
> I could offer my program cdrskin as real example.
> It is a cdrecord/wodim compatibility wrapper but exceeds both when it
> comes to DVD and BD media.


Thanks, for:

   * the useful example, and
   * changing the Subject: line appropriately! (for this and your later post)

[OT] Re: Wrappers and emulation (was Bug#908349)

[Thomas Schmitt]

Hi,

Reco wrote:
> Wait. You're *the* Thomas Schmitt who wrote xorriso?

Yep. I am the current developer of libburn, libisofs, libisoburn, cdrskin,
xorriso.

There were others involved, though.
libburn was forked from a half-dead project in 2006. Not more than 25
percent of the code is still from there. libisofs was founded by Vreixo
Formoso. I took over in 2008. Now i'd say 50 percent are by me.
Vreixo was involved in libisoburn, too. But that was only a short time.


> I have to take it back then. A compatibility wrapper can exceed the
> original indeed.

Well, xorriso _has_ two compatibility wrappers built in, but other than
cdrskin it _is_ a project without direct paragon. One can look at it as
the next step beyond growisofs by Andy Polyakov.

To be clear:
All my emulators or wrappers have their shortcommings towards the
originals (no exotic CD modes except data and audio, no UDF, no HFS).
But they also make use of capabilities of libburn or xorriso, which
are not present in cdrecord or mkisofs.

So trying to be compatible on user interface level does not tell much
about the pros and cons of original and emulator.


Have a nice day :)

Thomas

Re: [beginning OT] Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Reco]

Hi.

On Mon, Sep 10, 2018 at 03:37:28PM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Reco wrote:
> > > It's the usual. A compatibility wrapper can never exceed the original.
> 
> rhkra...@gmail.com wrote:
> > Hmm, I don't see why it couldn't in some sense -- I'm trying to think of how
> > to say what I want to say, let me try a made-up example.
> 
> I could offer my program cdrskin as real example.
> It is a cdrecord/wodim compatibility wrapper but exceeds both when it
> comes to DVD and BD media.

Wait. You're *the* Thomas Schmitt who wrote xorriso?
I have to take it back then. A compatibility wrapper can exceed the
original indeed.

Reco

[beginning OT] Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Thomas Schmitt]

Hi,

Reco wrote:
> > It's the usual. A compatibility wrapper can never exceed the original.

rhkra...@gmail.com wrote:
> Hmm, I don't see why it couldn't in some sense -- I'm trying to think of how
> to say what I want to say, let me try a made-up example.

I could offer my program cdrskin as real example.
It is a cdrecord/wodim compatibility wrapper but exceeds both when it
comes to DVD and BD media.


> Suppose some piece of software is running (or trying to run) on a piece of 
> hardware where some function does not work because the software was written 
> to 
> depend on a certain set of (let's say machine) instructions which don't exist 
> on that particular machine.

Or suppose a program which insists to treat every optical medium like
a CD, regardless what the specs say ...


Have a nice day :)

Thomas

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Brad Rogers]

On Mon, 10 Sep 2018 11:53:01 + (UTC)
Curt  wrote:

Hello Curt,

>So uninstall it then in that unfortunate case--with extreme prejudice

Time.

Oh, and I can't be arsed to try PA in the first place.   :-)

>Or are we dealing with the supernatural here (software from Hell)?

I'm wary because of all the tales of woe I've read.  Obviously, there
are plenty of ppl for whom PA causes no problems at all.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Only the wounded remain, the generals have all left the game
Generals - The Damned


pgpgVfhukSSpy.pgp
Description: OpenPGP digital signature

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Curt]

On 2018-09-10, Brad Rogers  wrote:
>
> The machine it does affect is the one that I routinely use, which has
> been in use for longer than PA has been around.  I /could/ install PA,
> but am reluctant to do so, since sound works here ATM and I'm concerned
> that installing PA may cause issues for me.
>

So uninstall it then in that unfortunate case--with extreme prejudice (you
know, like, purgerino time).

Or are we dealing with the supernatural here (software from Hell)?

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[rhkramer]

On Monday, September 10, 2018 05:49:01 AM Reco wrote:
> It's the usual. A compatibility wrapper can never exceed the original.

Hmm, I don't see why it couldn't in some sense -- I'm trying to think of how 
to say what I want to say, let me try a made-up example.

Suppose some piece of software is running (or trying to run) on a piece of 
hardware where some function does not work because the software was written to 
depend on a certain set of (let's say machine) instructions which don't exist 
on that particular machine.  But, on a Turing complete machine, I'd expect 
other instructions to exist which, perhaps by substituting a long series of 
such other instructions, the missing machine instructions could be emulated.

As a(n almost) real world example, at least once (and I'm pretty sure more 
than once) Intel built a chip that had some hardware errors (I'm remembering 
what I think is the first one, maybe as many as 20 years ago) when the floating 
point operations gave incorrect results for at least some inputs.

Intel created a fix (a compatibility layer, in my choice of words) that fixed 
the problem.

If the problem is that Firefox can't produce sound in some or all 
circumstances because it doesn't support ALSA, yet ALSA is the sound system 
running on the machine, a compatibility layer could be created that (without 
getting the details correct) translated the sound instructions that Firefox 
issues into ALSA instructions.

Hmm, did I react too much to that simple statement -- maybe, I just think it 
is an un-necessarily limiting statement to "our" thinking.

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Brad Rogers]

On Mon, 10 Sep 2018 12:49:01 +0300
Reco  wrote:

Hello Reco,

>On Mon, Sep 10, 2018 at 09:59:03AM +0100, Brad Rogers wrote:
>> I've not been running apulse long, but so far, no crashes in Ff 62.  
>So upstream lies then. To quote apulse's README.md:

Maybe, maybe not.  It's only been a couple of days and I've yet to
really stress load Ff.  Fear not, if I do get crashes, I'll report here.

>sandbox violation with subsequent process termination. Exception can be
>added by setting parameter `security.sandbox.content.syscall_whitelist`
>in `about:config`. That field accepts a comma separated list of system
>call numbers. Add there `16` for x86-64, or `54` for x86 or ARM.

Which I've added.  After reading various posts/complaints in multiple
places.

>It's the usual. A compatibility wrapper can never exceed the original.

Agreed.  In this case, it doesn't need to.  Well, not yet.

>But - if it works for anyone - more power to them.

I only administer a handful of machines, and this problem affects only
one of them;  All the others had PA installed when they were first set
up (bare metal installations of Debian), so no problems there.

The machine it does affect is the one that I routinely use, which has
been in use for longer than PA has been around.  I /could/ install PA,
but am reluctant to do so, since sound works here ATM and I'm concerned
that installing PA may cause issues for me.

My gut feeling/guess is that installing PA on 'virgin' hardware is fine,
by _may_ result in odd behaviour when installed on a system successfully
running ALSA and, TBH, I don't want to find out and (maybe) have to go
through another PITA session of getting sound working properly again.

Time and life are short, and spending time getting sound working isn't
something I want to waste the two on.

I'm already resigned to the fact that I'm having to use two browsers
anyway, since certain plugins I find /extremely/ useful only work in a
XUL environment, whilst others only work in a WE environment.

As I said last time;  Sometimes, you just can't win.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
This disease is catching
Into The Valley - Skids


pgpsQqWYRRuBJ.pgp
Description: OpenPGP digital signature

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Reco]

Hi.

On Mon, Sep 10, 2018 at 09:59:03AM +0100, Brad Rogers wrote:
> On Sun, 9 Sep 2018 11:43:39 +0300
> Reco  wrote:
> 
> Hello Reco,
> 
> >Moreover, apulse causes Firefox to crash since Firefox version 58, as
> 
> I've not been running apulse long, but so far, no crashes in Ff 62.

So upstream lies then. To quote apulse's README.md:

Firefox 58 (Nightly) tightened its sandbox a bit more. Now `ioctl()`
calls are forbidden too, but are used by ALSA libraries. That causes
sandbox violation with subsequent process termination. Exception can be
added by setting parameter `security.sandbox.content.syscall_whitelist`
in `about:config`. That field accepts a comma separated list of system
call numbers. Add there `16` for x86-64, or `54` for x86 or ARM.


> >apulse is a kludge, not a solution.
> 
> That's as may be (I don't have an opinion either way).

It's the usual. A compatibility wrapper can never exceed the original.
But - if it works for anyone - more power to them.

Reco

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Brad Rogers]

On Sun, 9 Sep 2018 11:43:39 +0300
Reco  wrote:

Hello Reco,

>Moreover, apulse causes Firefox to crash since Firefox version 58, as

I've not been running apulse long, but so far, no crashes in Ff 62.

>apulse is a kludge, not a solution.

That's as may be (I don't have an opinion either way).

Sadly, however, Mozilla are withdrawing ALSA support completely (slowly,
over time) and I'm disinclined to run an ever ageing version of Ff just
to maintain sound.  In part because that brings problems of its own, what
with sites no longer working because of 'Your web browser is too old'
"error" reports.

Sometimes, you just can't win.   :-(

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
We are the chosen
Changed - Judgement Centre


pgpt42fRL_7F4.pgp
Description: OpenPGP digital signature

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[deloptes]

Rob van der Putten wrote:

> Does anyone know why ALSA is no longer supported?

You mean supported by Firefox? I guess they decided PA is more easy to
implement as default interface ... whatever underlaying audio system you
use.
I still could not understand why, but this seems irreversible.

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Nicolas George]

to...@tuxteam.de (2018-09-09):
> Personally, I couldn't care less: I consider my browser's inability
> to make sounds a welcome *feature*, so not having Pulse (which is my
> default) just naturally takes care of that.

Same for me. And apulse seems to work for me anyway.

> Given the amount of passive-aggressive juice flowing there (in both
> directions, mind you!), I guess it'll stay like that.
> 
> Perhaps you could convince Mozilla if you're able to summon up
> enough devel power to take care of an alternative back-end (e.g.
> "naked" ALSA), but I guess it would have to be somewhat credible.

Or they could have used one of the front-end libraries, maybe libao. Or
chosen ALSA's libasound, because libasound can be routed to pulse
transparently.

Obviously this was a political choice. Expect Gnome's WM to be mandatory
next.

> Freedom sometimes sucks; the lack thereof always sucks :)

Hear, hear.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Sep 09, 2018 at 10:24:30AM +0200, Rob van der Putten wrote:
> Hi there
> 
> 
> Note: A reply in bugs failed.
> 
> On 09/09/18 10:08, Marco Lucidi wrote:
> 
> > On Sat, 8 Sep 2018 21:41:11 +0200 Samuel Thibault 
> > wrote:
> >  > Unfortunately AIUI upstream has stopped supporting ALSA, so we
> are stuck
> >  > with pulseaudio for firefox.
> >
> > Is there any particular reason for pulseaudio not being listed in the
> > dependencies?
> > I mean, even if it's not a "core" dependency, I think it should be
> > listed in rec or at least in sug.
> 
> Apparently there alternatives to pulseaudio. See;
> http://forums.debian.net/viewtopic.php?p=639534#p639534
> 
> Does anyone know why ALSA is no longer supported? Does Firefox run
> in a chroot? How much work would it be to add ALSA support?

It seems to be intentional:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1247056

Personally, I couldn't care less: I consider my browser's inability
to make sounds a welcome *feature*, so not having Pulse (which is my
default) just naturally takes care of that.

Given the amount of passive-aggressive juice flowing there (in both
directions, mind you!), I guess it'll stay like that.

Perhaps you could convince Mozilla if you're able to summon up
enough devel power to take care of an alternative back-end (e.g.
"naked" ALSA), but I guess it would have to be somewhat credible.

Freedom sometimes sucks; the lack thereof always sucks :)

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAluU3vEACgkQBcgs9XrR2kY1uwCdEvBKgL2cXDm7Dms6fsV0AX8N
+RAAn1i/fov9zJUfl2JtsrPoQElN23Xa
=1EKS
-END PGP SIGNATURE-

Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Reco]

Hi.

On Sun, Sep 09, 2018 at 10:24:30AM +0200, Rob van der Putten wrote:
> Hi there
> 
> 
> Note: A reply in bugs failed.
> 
> On 09/09/18 10:08, Marco Lucidi wrote:
> 
> > On Sat, 8 Sep 2018 21:41:11 +0200 Samuel Thibault 
> > wrote:
> >  > Unfortunately AIUI upstream has stopped supporting ALSA, so we are
> stuck
> >  > with pulseaudio for firefox.
> >
> > Is there any particular reason for pulseaudio not being listed in the
> > dependencies?
> > I mean, even if it's not a "core" dependency, I think it should be
> > listed in rec or at least in sug.
> 
> Apparently there alternatives to pulseaudio. See;
> http://forums.debian.net/viewtopic.php?p=639534#p639534

You mean apulse? It's a partial re-implementation of Pulseaudio in a
form of a shared library with emphasis on 'partial'.
Moreover, apulse causes Firefox to crash since Firefox version 58, as
apulse shared library makes system calls that Firefox does not
anticipate for.
apulse is a kludge, not a solution.


> Does anyone know why ALSA is no longer supported?

To quote [1],

Make Pulse Audio a hard dependency on Linux so that we reduce the
problems and maintenance associated with maintaining multiple audio
backends.


> Does Firefox run in a chroot?

Yes, but without sound.


> How much work would it be to add ALSA support?

All alsa support was deleted from Firefox codebase as of version 53
IIRC. I find it highly unlikely that 'Maintainers of Mozilla-related
packages' can be convinced to maintain Firefox fork of these
proportions even if someone was willing to revert alsa-removing change
and maintain it indefinitely.

Reco

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1345661