Graphics in Debian 9 & Zero-K

[Oflameo]

First issue:

https://springrts.com/mantis/view.php?id=5634

This Kloot character keeps closing my promoted Zero-K tickets that get
promoted because of Spring engine issues. On Debian 8, the game ran
slow. On Debian 9 the game doesn't start.

A couple days ago, he said that my POLARIS10 drivers were Obviously
VMWare drivers and closed the ticket looking straight at my dmesg
output and said I misconfigured my system, which I just did a clean
install on so I can dodge the accusation.

I am looking to find undeniable evidence that I am infact using my
RX470 with POLARIS10 drivers and not VMWare Drivers. If it takes
getting multiple Debian Developers to verify and sign off on the
drivers I am using to discredit Kloot, it is wort it to me.

Second issue:

https://springrts.com/mantis/view.php?id=5620

Even though my glxinfo also obviously says I am running my Graphics
using POLARIS10 drivers like dmesg did, it says it only supports OpenGL
3.0 when my card supports OpenGL 4.5.

http://www.thinkcomputers.org/sapphire-nitro-rx-470-oc-graphics-card-re
view/

Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD POLARIS10 (DRM 3.8.0 / 4.9.0-3-amd64, LLVM 3.9.1)
(0x67df)
Version: 13.0.6
Accelerated: yes
Video memory: 4037MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.8.0 /
4.9.0-3-amd64,
 LLVM 3.9.1)
OpenGL version string: 3.0 Mesa 13.0.6

How do I get OpenGL 4.5 support out of Mesa on Debian 9?

Re: Replace systemd

[Joel Rees]

On Fri, Jul 7, 2017 at 12:42 AM, Reco  wrote:
>   [...]
>> >
>> >> This behaviour on a critical component is mere madness.
>> >
>> > OpenBSD folks beg to differ.
>> >
>> > https://marc.info/?l=openbsd-tech=149902196520920=2
>>
>> They were mocking systemd, not adopting the behaviour...
>
> Rly? But why? That's legitimate patch aimed on improving compatibility
> and interoperability. I certainly expect this patch to land in sudo
> upstream.

You can hurt yourself cherry picking from the openbsd lists.

If you want to know whether Ted was serious, the best approach is to
watch the source tree:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/doas/

Check the date on the message, and, BTW, read the whole thread,
while you're at it, if you haven't. Ask yourself why the debate fizzled.

Check the date again, check who owns doas, check the last change
to the source tree.

What is missing?

-- 
Joel Rees

One of these days I'll get someone to pay me
to design a language that combines the best of Forth and C.
Then I'll be able to leap wide instruction sets with a single #ifdef,
run faster than a speeding infinite loop with a #define,
and stop all integer size bugs with my bare cast.
http://defining-computers.blogspot.com/2017/06/reinventing-computers.html

More of my delusions:
http://reiisi.blogspot.com/2017/05/do-not-pay-modern-danegeld-ransomware.html
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

Re: Re: Replace systemd

[Tom Dial]

On 07/06/2017 10:00 AM, Reco wrote:
>   Hi.
> 
> On Thu, 6 Jul 2017 15:49:41 +0200
> Erwan David  wrote:
> 
>>> True. But does libsystemd0 count? It's a library, not an executable.
>>>
>> There are also packages which add a dependency on systemd whereas the
>> same software works perfectly on FreeBSD, thus without anything
>> ressembling it (eg hplip).
>> This leads to upgrade from a jessie without systemd will install it.

I am not a particular fan of systemd, but have learned to live with it,
on the basis that deviations from the default install are likely to lead
to more work, possibly exponentially, down the line.

That said, the hplip in Devuan 2.0 seems to be identical to that in
Stretch, and neither, therefore would depend on (or recommend) systemd.

The output of "dpkg --status hplip" is identical on the two systems.


> 
> I did obligatory 'apt-get upgrade; apt-get dist-upgrade' at least 5
> times so far (jessie→stretch). Different architectures, different
> purposes. There was no systemd on those before the upgrade, and there
> is no systemd after it.
> 
> But, I don't use GNOME and do not force it on users. Using GNOME may be
> considered a cruel and unusual punishment in some countries, I don't
> need that.
> 
> And I prefer to keep hplip on a printserver, 'cause I see no reason to
> install the thing on a desktops multiple times. Same thing with cups.
> 
> If apt insists on installing unwanted packages into your system - I can
> only suggest you to consider learning the way apt works.
> 
> 
> Besides, there's no point in complaining about it here.
> To actually change something they suggest users to invoke an excellent
> reportbug utility and transfer their wishes directly to bugs.debian.org.
> 
> Reco
> 

Tom Dial

Fwd: firmware-realtek: Add support for the rtl8812au/rtl8814au 802.11ac devices (already packaged in Ubuntu, Kali Linux)

[Jason Wittlin-Cohen]

I made a wishlist bug to add support for the rtl8812au/rtl8814au hardware.
Given that it's already made its way into Ubuntu, perhaps there's a chance
this will get included in Debian at some point.

-- Forwarded message --
From: Jason Cohen 
Date: Thu, Jul 6, 2017 at 8:35 PM
Subject: firmware-realtek: Add support for the rtl8812au/rtl8814au 802.11ac
devices (already packaged in Ubuntu, Kali Linux)
To: Debian Bug Tracking System 


Package: firmware-realtek
Version: 20161130-3
Severity: wishlist

Dear Maintainer,

Please provide support for the rtl8812au (802.11ac 2x2) and rtl8814au
(802.11ac
3x3 MIMO) devices. Drivers for this hardware is provided by:
https://github.com/astsam/rtl8812au. These drivers are already packaged in
Ubuntu since 16.04 LTS (and derivatives) as well as Kali Linux 2017.1
[3],[4].
There are relatively few 802.11ac USB adapters on the market and many of the
available devices appear to use this chipset. You can provide some examples
of
hardware using this chipset here [5].  In my case, I am using an Edimax
Edimax
EW-7822UAC (Bus 003 Device 023: ID 7392:a822 Edimax Technology Co., Ltd).
The
COMFAST CF-917AC is an example of the faster rtl18814au hardware[6].


[1]
http://www.realtek.com.tw/products/productsView.aspx?
Langid=1=57=5=4=397
[2]
http://www.realtek.com.tw/products/productsView.aspx?
Langid=1=21=57=5=4=392
[3] https://packages.ubuntu.com/search?keywords=rtl8812au-dkms
[4] https://www.kali.org/news/kali-linux-20171-release/ and
https://bugs.kali.org/view.php?id=3260
[5] https://wiki.gentoo.org/wiki/AC1200_Wireless_Adapters
[6] https://www.amazon.com/dp/B01B75MHR0



-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.130

-- no debconf information

Re: Driver/firmware for Realtek RTL8814U WiFi USB Adapter?

[Jason Cohen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Larry,

The drivers you need are not available as a backport because no Debian
release packages said drivers.  You'll need to compile them
yourself.  However, the process should be fairly easy.

I think you want the drivers from here: https://github.com/astsam/rtl88
12au

1) This is the easy way but will only work for your existing kernel,
and presumably any future ABI compatible kernel

#Install dependencies
sudo apt-get install linux-headers-$(uname -r) build-essential git

#Clone the git repository
git clone https://github.com/astsam/rtl8812au.git 
cd rtl8812au

#Compile driver for your hardware
make RTL8814=1

#Install Module
make install

#Load Module (I compiled this myself and the created module appears to
be 8812au, not rtl8814.  If this doesn't work, just reboot with the
device connected, and it will load the correct module.)
modprobe 8812au

I don't have your hardware so I can only test the compilation, which
worked on my Debian Stretch system.  This appears to be the driver that
is used by Kali Linux, so it should work for you.

2) This method is a bit more involved but will use DKMS to ensure that
the drivers are recompiled when your kernel is updated.

#Install dependencies
sudo apt-get install linux-headers-$(uname -r) build-essential dkms git

#Set environmental variables for DKMS
DRV_NAME=rtl8814
DRV_VERSION=4.3.21

#Make directory for driver
mkdir /usr/src/${DRV_NAME}-${DRV_VERSION}

#Clone the git repository
git clone https://github.com/astsam/rtl8812au.git
/usr/src/${DRV_NAME}-${DRV_VERSION}

#Use DKMS to build and install the driver
dkms add -m ${DRV_NAME} -v ${DRV_VERSION}
dkms build -m ${DRV_NAME} -v ${DRV_VERSION}
dkms install -m ${DRV_NAME} -v ${DRV_VERSION}

Note:  I don't know if these DKMS steps will work for you since it may
compile the driver for 8812au and not 8814.  YMMV.

Sources:

Driver Source: https://github.com/astsam/rtl8812au
DKMS Instructions for rtl8812au: https://edimax.freshdesk.com/support/s
olutions/articles/1441287-how-to-install-ew-78xx-11ac-adapter-in-
linux-with-kernel-higher-than-v4-1
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEq7ncLkwZsndhZmLWsskfuEl+i10FAlle0qkACgkQsskfuEl+
i11RcQ//WAbNE8IjLbBMqJLCRlwD2jOLB52MKIBrQRWvUXZyRvuvHJgK1XTRaDBf
qTY5KR69Ct9NG7TKmvVGuBqb8CZAOAH5ukuz323ophxVefZS9FpSSi6SUDNhrlrg
cW1jas87IjVihiXnNaiU0Lza14fUSR6+dP0MjixgSC9tbX2o/mIZasReb0pjII2Y
Zw6O+whVbjm+7DjD2PRaslSon+xvVtpI90dhDVqghqQZr3d6tJIE9aFsgGj/MvF+
WV9fVXgWKyGDaUmqMPyxMj++kWahei4Bj4UM77XOMYpWHYQuVkGgv3hdIUFy7s5z
uKeZmtwOkQHYiOdhBk6TE2DJJ+TMuJ6P4La/SVLKKdff/0lqLgifjPl2W/fSxHxN
xc4T9byFkLiRiARv075JI/hGBqZRV7oani1aWXl7SawkMhx5PlDRlSedOYg2WXTB
IMMqZmXV4saOGVgKpYxWOWI2H89t0W6dis2qBFWVp6jaTryOh3zLCs0MLAGxc3GZ
28msgv4u+cLHCIlDT/MNRIkvwF2BWAVd4aTEjmAf2KrmjoPSKvtNCU1fk0y8y5L3
i10qgT1Dhid9K7xXcVtxBBb/1atiOvG+AXxcKmsGGD7qBuDFprl8zcDq63xB2fX9
uXI3WdAJ9jQf91qTsHo2ImInAVE1oT3XVDqIgJVZpMwxZuBCaWU=
=CGy1
-END PGP SIGNATURE-

Re: Replace systemd

[Patrick Bartek]

On Thu, 6 Jul 2017 20:55:48 +0100 Jonathan Dowland 
wrote:

> On Thu, Jul 06, 2017 at 09:02:24AM -0700, Patrick Bartek wrote:
> >Even in Expert Mode, there's no choice to install an alternate init.
> >And with systemd being a major system dependency in Debian, it's
> >always going to be around regardless of which init you migrate to.
> 
> I believe expert mode offers you a choice to select packages manually,
> at which point you can select the init of your choice. But tell you
> what, I'll actually try this Tomorrow to ensure that it is still the
> case.

I would be interested if there were.  I've never seen such an option
previously.

When I did my test evaluation installs of Stretch RC3 a few weeks ago, I
used the LXDE install disk since LXDE uses Openbox as its window
manager, the one I prefer, to save time instead of messing with the
Expert Mode, which I normally use.

I'm about to do a final test install in VirtualBox before doing it for
real, but it won't be tomorrow.  Maybe in a week.

Let the list know what you discover.

Thanks

B

Inte accepterat mail

[Antoine Naccache]

Hej,

Har varit medlem här länge, sen början av 2000. Visserligen  passiv sista åren, 
men aktiv tidigare under 2000 talet.

Skickade en fråga häromdagen, men blev nekad enligt hotmail och undrar varför ?

antoine_nacca...@hotmail.com

Sent from my iPad

Re: Plus de notification d'arrivée de courriel ni tâches Osmo

[Benoit B]

Le 6 juillet 2017 à 12:51, maderios  a écrit :
>>
> Si on rencontre un problème après un changement de version, il est souvent
> plus efficace et plus propre de supprimer complètement la vieille conf de
> l'utilisateur, de redémarrer l'environnement de bureau puis de le
> personnaliser.
>
En effet, c'est judicieux, j'ai le même problème avec un utilisateur
vierge de toute personnalisation.
J'ai oublié de préciser.

Bonne soirée
--
Benoit

Re: Plus de notification d'arrivée de courriel ni tâches Osmo

[Benoit B]

Le 6 juillet 2017 à 10:50, Alain Rpnpif  a écrit :
> Le  5 juillet 2017, Benoit B a écrit :
>
> /etc/xdg/autostart/notification-daemon.desktop

Je n'ai pas ce fichier dans autostart tu l'as rajouté ?

Bonne soirée

--
Benoit

Re: Scanner et Stretch

[Randy11]

On 03/06/2017 19:09, Georges wrote:

Bonjour,

 J'utilise une Brother DCP-195C et son scanner.

 Tout marchait bien avec Jessie.

 Je n'ai pas réussi à installer Stretch en changeant jessie pour
 stretch dans mon sources.list.

[...]

Georges



Bonsoir,

Ma vieille EPSON EPL700 avec port parallèle rend l'âme, je n'ai pas de
scanner, aussi j’envisageai une imprimante multifonction sous Stretch.

Les commentaires sur Brother sont assez différents et cela me fait hésiter.

J'ai trouvé cela  https://wiki.debian.org/Brother/MFC7440N.

Quelqu'un a-t-il un retour avec Stretch pour une imprimante + scanner ?

Je sais, c'est une question très générale, mais vous avez tellement l'air de
galérer ..

Vue scan (https://www.hamrick.com/fr/vuescan/brother-dcp-135c-pilote.html)
à l'air très bien, mais la version Pro est proche du prix de l'imprimante !

Merci pour vos avis.

Bonne soirée.

Randy11

Re: Relative stability of Testing vs Unstable

[songbird]

John Hasler wrote:
> songbird writes:
>> i've been running testing with bits from unstable and/or experimental
>> for quite some time now.
>
> Experimental is a completely different kettle of fish.

  of course.  :)  it is not like i'm using a lot of
things from there.  more like one or two items.


>  Unstable
> contains packages that the developer hopes and expects will migrate to
> Testing and end up in Stable without incident, and he's usually right.
> Experimental, on the other hand, contains packages that the developer
> wants people to experiment with.  It is not a mistake or policy
> violation to upload a package known to contain a grave bug to
> Experimental.

  i usually check if there is a newer version there
if i'm experiencing a bug in a version that is in
testing or unstable to see if the newer version solves
the bug.  most recently it was libreoffice, but the
newer version didn't make any difference so i purged
it and reinstalled the testing version again (and then
worked around the issue).


  songbird

[testing] impression pdf depuis firefox

[Gaëtan PERRIER]

Bonjour,

Arrivez-vous à imprimer un pdf depuis le lecteur pdf de firefox 54.0-1 sur
testing ?

A+

Gaëtan


pgp2zsqptzz86.pgp
Description: PGP signature

Re: Replace systemd

[Jonathan Dowland]

On Thu, Jul 06, 2017 at 09:02:24AM -0700, Patrick Bartek wrote:

Even in Expert Mode, there's no choice to install an alternate init.
And with systemd being a major system dependency in Debian, it's always
going to be around regardless of which init you migrate to.


I believe expert mode offers you a choice to select packages manually,
at which point you can select the init of your choice. But tell you
what, I'll actually try this Tomorrow to ensure that it is still the
case.

--

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland

⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: "ACPI error" depuis passage à Stretch

[Gaëtan PERRIER]

Le Thu, 6 Jul 2017 10:35:44 +0200
Alain Rpnpif  a écrit:

> Le  5 juillet 2017, Benoit B a écrit :
> 
> > Idem pour moi,
> > 
> > ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x5) is beyond
> > end of object (length 0x5) (20160831/exoparg2-427)
> > [   14.235257] ACPI Error: Method parse/execution failed
> > [\_SB.PCI0.GFX0._DOD] (Node 9317bb0ab500), AE_AML_PACKAGE_LIMIT
> > (20160831/psparse-543)
> > [   14.235269] ACPI Exception: AE_AML_PACKAGE_LIMIT, Evaluating _DOD
> > (20160831/video-1254)
> 
> Pour moi aussi sur une carte MSI avec microprocesseur AMD A4-5300 APU,
> récente.
> 
> Je n'ai pas remarqué d'autres dysfonctionnements liés à cette erreur. Je
> suis sous Jessie-backports avec pratiquement le même noyau que Sketch
> (4.9).
> 
> -- 
> Alain Rpnpif

De même de mon côté sur une ASUS P8P67-LE


[1.505990] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND
(20170119/psargs-363) [1.506092] ACPI Error: Method parse/execution failed
[\_SB.PCI0.SAT0.SPT1._GTF] (Node 9fb48e0c5780), AE_NOT_FOUND
(20170119/psparse-543) [1.506282] ACPI Error: [DSSP] Namespace lookup
failure, AE_NOT_FOUND (20170119/psargs-363) [1.506382] ACPI Error: Method
parse/execution failed [\_SB.PCI0.SAT0.SPT2._GTF] (Node 9fb48e0c5aa0),
AE_NOT_FOUND (20170119/psparse-543) [1.506530] ata5.00: ATAPI: PLEXTOR
DVDR   PX-880SA, 1.10, max UDMA/100 [1.506552] ata7: SATA link down
(SStatus 0 SControl 300) [1.506577] ata6: SATA link up 3.0 Gbps (SStatus
123 SControl 300) [1.506593] ata8: SATA link down (SStatus 0 SControl 300)
[1.506603] ata4.00: ATA-9: C300-CTFDDAC064MAG, 0007, max UDMA/100
[1.506605] ata4.00: 125045424 sectors, multi 16: LBA48 NCQ (depth 31/32),
AA [1.506967] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND
(20170119/psargs-363) [1.507067] ACPI Error: Method parse/execution failed
[\_SB.PCI0.SAT0.SPT1._GTF] (Node 9fb48e0c5780), AE_NOT_FOUND
(20170119/psparse-543) [1.507340] ata4.00: configured for UDMA/100
[1.507487] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND
(20170119/psargs-363) [1.507597] ACPI Error: Method parse/execution failed
[\_SB.PCI0.SAT0.SPT2._GTF] (Node 9fb48e0c5aa0), AE_NOT_FOUND
(20170119/psparse-543) [1.507748] ata5.00: configured for UDMA/100
[1.507797] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND
(20170119/psargs-363) [1.507896] ACPI Error: Method parse/execution failed
[\_SB.PCI0.SAT0.SPT3._GTF] (Node 9fb48e0c5b68), AE_NOT_FOUND
(20170119/psparse-543) [1.508331] ata6.00: ATA-8: TOSHIBA DT01ACA200,
MX4OABB0, max UDMA/133 [1.508333] ata6.00: 3907029168 sectors, multi 16:
LBA48 NCQ (depth 31/32), AA [1.509518] ACPI Error: [DSSP] Namespace lookup
failure, AE_NOT_FOUND (20170119/psargs-363) [1.509617] ACPI Error: Method
parse/execution failed [\_SB.PCI0.SAT0.SPT3._GTF] (Node 9fb48e0c5b68),
AE_NOT_FOUND (20170119/psparse-543) [1.510159] ata6.00: configured for
UDMA/133 [1.510770] ata10: SATA link down (SStatus 0 SControl 330)
[1.514582] ata9: SATA link down (SStatus 0 SControl 330) [1.515881]
ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [1.516251] ACPI
Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20170119/psargs-363)
[1.516350] ACPI Error: Method parse/execution failed
[\_SB.PCI0.SAT0.SPT0._GTF] (Node 9fb48e0c55f0), AE_NOT_FOUND
(20170119/psparse-543) [1.516498] ata3.00: supports DRM functions and may
not be fully accessible [1.517477] ata3.00: ATA-10:
Crucial_CT250MX200SSD1, MU04, max UDMA/133 [1.517479] ata3.00: 488397168
sectors, multi 16: LBA48 NCQ (depth 31/32), AA [1.518769] ACPI Error:
[DSSP] Namespace lookup failure, AE_NOT_FOUND (20170119/psargs-363)
[1.518869] ACPI Error: Method parse/execution failed
[\_SB.PCI0.SAT0.SPT0._GTF] (Node 9fb48e0c55f0), AE_NOT_FOUND
(20170119/psparse-543)

A+

Gaëtan


pgpDpQSRc5nXT.pgp
Description: PGP signature

oui oui

[eric marque]

‌

Re:Tu voudrais bien m’aider à devenir plus bavarde avec toi? Clemence

[pirate . vincent]

- message précédent - Je sens qu’on pourra trouver une langue commune 
sur plusieurs sujets. Bonjour mademoiselle ! Êtes vous de la police ? Car si 
c'est une blague ! Elle est de mauvais goût ! Merci de m'envoyer votre vraie 
image et vos désirs réels par internet sur cet email ! Comme cela si vous êtes 
vraiment majeur et pas flic ! Je le saurai ! Merci d'avance... C'était Roger 
rabbit le lapin dans son terrier ! Mais à qui sont ces carottes ? À vous de les 
deviner ! Afin que comme Trinity vous descendiez au plus profond du terrier 
avec lui ! Cordialement Bugs Bunny ! Take care miss Jane !

Re: Replace systemd

[Patrick Bartek]

On Thu, 6 Jul 2017 10:57:55 +0100 Jonathan Dowland 
wrote:

> On Wed, Jul 05, 2017 at 04:32:17PM -0700, Patrick Bartek wrote:
> >If you're referring to "preseed" or "debootstrap" scenerios, those
> >are more "work-arounds" than a choice from within the installer --
> >What my original query was about.  While they work, so does the
> >other option of switching inits after the system install is
> >complete.  The latter, I think, is less problematical.  No matter ...
> 
> No, I was referring to the expert mode option where you get to select
> the exact packages you want. But yes, the preseeding and debootstrap
> options are there too, you are right.

Even in Expert Mode, there's no choice to install an alternate init.
And with systemd being a major system dependency in Debian, it's always
going to be around regardless of which init you migrate to. 

B

Re: Replace systemd

[Reco]

Hi.

On Thu, 6 Jul 2017 15:49:41 +0200
Erwan David  wrote:

> > True. But does libsystemd0 count? It's a library, not an executable.
> > 
> There are also packages which add a dependency on systemd whereas the
> same software works perfectly on FreeBSD, thus without anything
> ressembling it (eg hplip).
> This leads to upgrade from a jessie without systemd will install it.

I did obligatory 'apt-get upgrade; apt-get dist-upgrade' at least 5
times so far (jessie→stretch). Different architectures, different
purposes. There was no systemd on those before the upgrade, and there
is no systemd after it.

But, I don't use GNOME and do not force it on users. Using GNOME may be
considered a cruel and unusual punishment in some countries, I don't
need that.

And I prefer to keep hplip on a printserver, 'cause I see no reason to
install the thing on a desktops multiple times. Same thing with cups.

If apt insists on installing unwanted packages into your system - I can
only suggest you to consider learning the way apt works.


Besides, there's no point in complaining about it here.
To actually change something they suggest users to invoke an excellent
reportbug utility and transfer their wishes directly to bugs.debian.org.

Reco

Re: Replace systemd

[Reco]

Hi.


On Thu, 6 Jul 2017 15:27:04 +0200
Erwan David  wrote:

> Le 07/06/17 à 13:48, Reco a écrit :
> > Hi.
> > 
> > On Thu, Jul 06, 2017 at 12:53:29PM +0200, Erwan David wrote:
> >> Le 07/03/17 à 22:48, Dejan Jocic a écrit :
> >>>
> >>> You can still use Debian without systemd as init. Explained here:
> >>>
> >>> https://lists.debian.org/debian-user/2017/05/msg00538.html
> >>>
> >>> If you would prefer that it is some derivate/fork of Debian without
> >>> systemd, I do not have personal experience with those, but I'm sure that
> >>> you will get few hints.
> >>>
> >> init is a small part of systemd. And judging y the bug reported and how
> >> they are treated, I do not trust any part of it.
> >> Neither resolved, logind, etc...
> > 
> > So you do not trust udev as well?
> > 
> > 
> >> Too many critical bugs found in them and treated by the upstream
> >> developpers with only contempt for the people reporting them
> >> (see https://github.com/systemd/systemd/issues/6237#issuecomment-312458445)
> > 
> > By that logic (in)famous libc bug 4980 shoud've stopped by from using
> > any sane Linux distribution 10 years ago. Did it?
> >
> Most important is not the presence of bugs. It is the way people in
> charge deal with them.

My point exactly. #4980 is the reason they call Ulrich Drepper 'Stop
Reopening'. But also, #4980 was fixed.
Just the same as #6237 will be fixed in a sane way. At least that's the
fine folks on oss-security are promising right now.


> > 
> >> This behaviour on a critical component is mere madness.
> > 
> > OpenBSD folks beg to differ.
> > 
> > https://marc.info/?l=openbsd-tech=149902196520920=2
> 
> They were mocking systemd, not adopting the behaviour...

Rly? But why? That's legitimate patch aimed on improving compatibility
and interoperability. I certainly expect this patch to land in sudo
upstream.

Reco

Re: Driver/firmware for Realtek RTL8814U WiFi USB Adapter?

[Larry Dighera]

>On Wed, Jul 5, 2017 at 2:41 PM, Larry Dighera  wrote:
>
>> Which Debian Stretch package provides firmware for the Realtek
>> RTL8814U chip?  In particular, the Comfast CF-917AC 1750Mbps USB3
>> adapter: https://www.amazon.com/dp/B01B75MHR0 .
>>
>> Kali Linux supports the RTL8814 natively:
>> https://www.kali.org/news/kali-linux-20171-release/ .  Further, there
>> are some clues here: https://bugs.kali.org/view.php?id=3260
>> https://github.com/diederikdehaas/rtl8812AU
>> https://github.com/astsam/rtl8812au
>> https://github.com/lwfinger/rtlwifi_new
>>
>> But, I'm looking for an "official" Debian firmware package.
>>
>> I wasn't able to find the rt8814 mentioned here:
>> https://www.debian.org/distrib/packages nor here:
>> http://linux-wless.passys.nl/query_chipset.php?chipset=Realtek
>> nor here: https://wireless.wiki.kernel.org/en/users/drivers
>>
On Wed, 5 Jul 2017 18:57:44 -0400, Jason Wittlin-Cohen
 wrote:

>I have the Edimax EW-7822UAC (2x2 802.11ac) which uses the rtl8812AU
>chipset.  I can confirm that the firmware-realtek package does not contain
>support for the rtl8812AU chipset, and presumably also does not
>support the RTL8814U
>chipset.  Neither are listed on https://wiki.debian.org/rtl819x.  In
>contrast, Ubuntu and its derivatives, such as Mint, do package this
>driver.  For example, see
>https://packages.ubuntu.com/xenial/kernel/rtl8812au-dkms.
>
>Fortunately, I was able to compile and install the rtl8812AU driver from
>https://github.com/diederikdehaas/rtl8812AU without difficulty.  I have
>been using this wireless card on a desktop system with Stretch.  It has
>been reliable and I had no problem configuring it with networks running
>WPA2-PSK and WPA2-Enterprise (EAP-TLS).  I'm getting speeds around 300
>Mbit/sec @ 65-70 dbm when connected to a Ubiquiti AC-LR.  In contrast, Mint
>installed the driver for me without issue but had constant issues with
>EAP-TLS due to bugs in network-manager.
>

Hello Jason,

Thank you for the information you have provided.  

Is there a chance the rtl8814AU driver might be available as a backport?

I was hoping that I wouldn't have to compile the driver, but your experience
has left little doubt that it will be necessary.  Although I have
successfully built several Software Defined Radio applications, I've never
been successful in building drivers.  Will ModuleAssistant
 assist in building the driver?  Or
is there another "assistant" package that may be of help?  

Best regards,
Larry

Re: Dare to be stupid

[Hans Vogelsberger]

Am Wed,  5 Jul 2017 13:00:04 -0400 (EDT)
schrieb Anonymous :

> You can be a coffee achiever
> You can sit around the house and watch Leave It To Beaver
> The future's up to you
> So what you gonna do
> 
> Dare to be stupid

But never dare to tell who you are - fie!

Re: Replace systemd

[Patrick Bartek]

On Thu, 6 Jul 2017 11:50:24 +0100 Jonathan Dowland 
wrote:

> On Wed, Jul 05, 2017 at 04:41:42PM -0700, Patrick Bartek wrote:
> >All that can be done on a window manager only system, too.  Just
> >install the utility needed, either terminal or X-based..
> 
> You are missing the point entirely. I was not arguing it was
> impossible to get that functionality without using a desktop
> environment. I was arguing that some people *want* the desktop
> environment to do that for them. Of course you can DIY. But not
> everyone wants to.

Yes, I misunderstood you.. Some people for whatever reasons
believe window manager only GUIs are "limited" or "inferior" to desktop
environments.  I thought you were one, and was trying to correct that
misconception.  My apologies.  For the record, I'm not advocating
abolishing the Desktop environment.  I believe in choice.  As much as
possible. Most people want automatic transmission.  I prefer manual.
To each his own.

B

Re: glusterfs and qemu/kvm

[Dave Sherohman]

On Thu, Jul 06, 2017 at 09:43:48AM -0400, Jason Wittlin-Cohen wrote:
> The last post on the bug report indicates that this issue has been fixed.
> The changelog for the fixed version states:
> 
>* enable glusterfs support (glusterfs-common), in qemu-block-extra
> 
> Stretch and newer contain qemu-block-extra, and it depends on 
> glusterfs-common.

Ah, I missed that.  I didn't go through the details of the final message
because the "wontfix" tag is still there, so I assumed it still applied.

However, even after installing qemu-block-extra and restarting libvirtd,
it's still a no-go:

~$ sudo apt-get install qemu-block-extra

~$ sudo systemctl restart libvirtd
~$ cat gluster.xml 

  gluster-test
  
palantir


  

~$ virsh pool-define gluster.xml 
error: Failed to define pool from gluster.xml
error: internal error: missing backend for pool type 10 (gluster)

This is on a fully up-to-date stretch install (qemu 1:2.8+dfsg-6, libvirt 
3.0.0-4, gluster 3.8.8-1).

-- 
Dave Sherohman

Re: Replace systemd

[JPlews]

On 06/07/17 13:10, Greg Wooledge wrote:

On Thu, Jul 06, 2017 at 07:34:04AM -0400, The Wanderer wrote:

But that is not the scenario I am discussing. I am discussing the
experience which an ordinary user, who simply selects from the options
which the installer lists, will have. (My use of the term "option" in
the quoted paragraph, as well as the one preceding it in my last mail,
was referring to the options which the installer presents.)



...


As Don Armstrong already said, the Debian developers are *not* going
to change the installer to add the option you keep yelling for.  Just
get over it.



The installer needs less, perhaps only choosing between network and 
physically accessible systems and installing ssh or a single default DE.


Being invited to use a CLI during the installer would be good for the 
health of new users and support all esoteric choices*, and if not 
desirable does this person care about what's managing their windows any 
more than what's doing their init? If they are is this because they are 
invited to think about the choices?

Re: Replace systemd

[Erwan David]

Le 07/06/17 à 15:27, Reco a écrit :
> On Thu, Jul 06, 2017 at 08:45:30AM -0400, The Wanderer wrote:
>> On 2017-07-06 at 07:48, Reco wrote:
>>
>>> Hi.
>>>
>>> On Thu, Jul 06, 2017 at 12:53:29PM +0200, Erwan David wrote:
>>>
 Le 07/03/17 à 22:48, Dejan Jocic a écrit :

> You can still use Debian without systemd as init. Explained
> here:
>
> https://lists.debian.org/debian-user/2017/05/msg00538.html
>
> If you would prefer that it is some derivate/fork of Debian
> without systemd, I do not have personal experience with those,
> but I'm sure that you will get few hints.

 init is a small part of systemd. And judging y the bug reported and
 how they are treated, I do not trust any part of it. Neither
 resolved, logind, etc...
>>>
>>> So you do not trust udev as well?
>>
>> I consider it unfortunate that udev is maintained as part of the systemd
>> suite, rather than being maintained independently (even if by the same
>> people), purely from a separation-of-distinct-things perspective.
>>
>> I haven't seen any relevant problems with it to date, however; the worst
>> aspect of that maintenance situation is that it means upgrading udev
>> shows the systemd changelog (which rarely has any relevant changes
>> listed), rather than only a changelog for udev itself.
> 
> Um. So called Predictable Network Interface Names, for starters.
> Does *very funny* things to Debian (anything that have net.ifnames=1
> really) running in ESXi.
> 
> Somewhat old, but truly golden story about udev and firmware loading -
> https://lwn.net/Articles/518942/
> 
> And, of course #762018 deserves a honorable mention.
> 
> 
 And it is NOT possible to use debian without any part of systemd.
>>>
>>> Indeed it is. It is not possible to use Debian without udev.
>>> Everything else is optional though.
>>
>> You do at least also need libsystemd0 - or at any rate, trying to remove
>> that on my (otherwise systemd-free) system results in removing 735
>> packages, and leaving at least a few hundred others in "automatically
>> installed, would be removed by autoremove" state.
> 
> True. But does libsystemd0 count? It's a library, not an executable.
> 
> Reco
> 
There are also packages which add a dependency on systemd whereas the
same software works perfectly on FreeBSD, thus without anything
ressembling it (eg hplip).
This leads to upgrade from a jessie without systemd will install it.

Re: Replace systemd

[Erwan David]

Le 07/06/17 à 13:48, Reco a écrit :
>   Hi.
> 
> On Thu, Jul 06, 2017 at 12:53:29PM +0200, Erwan David wrote:
>> Le 07/03/17 à 22:48, Dejan Jocic a écrit :
>>>
>>> You can still use Debian without systemd as init. Explained here:
>>>
>>> https://lists.debian.org/debian-user/2017/05/msg00538.html
>>>
>>> If you would prefer that it is some derivate/fork of Debian without
>>> systemd, I do not have personal experience with those, but I'm sure that
>>> you will get few hints.
>>>
>> init is a small part of systemd. And judging y the bug reported and how
>> they are treated, I do not trust any part of it.
>> Neither resolved, logind, etc...
> 
> So you do not trust udev as well?
> 
> 
>> Too many critical bugs found in them and treated by the upstream
>> developpers with only contempt for the people reporting them
>> (see https://github.com/systemd/systemd/issues/6237#issuecomment-312458445)
> 
> By that logic (in)famous libc bug 4980 shoud've stopped by from using
> any sane Linux distribution 10 years ago. Did it?
>
Most important is not the presence of bugs. It is the way people in
charge deal with them.

> 
>> This behaviour on a critical component is mere madness.
> 
> OpenBSD folks beg to differ.
> 
> https://marc.info/?l=openbsd-tech=149902196520920=2

They were mocking systemd, not adopting the behaviour...

Re: Replace systemd

[Reco]

On Thu, Jul 06, 2017 at 08:45:30AM -0400, The Wanderer wrote:
> On 2017-07-06 at 07:48, Reco wrote:
> 
> > Hi.
> > 
> > On Thu, Jul 06, 2017 at 12:53:29PM +0200, Erwan David wrote:
> > 
> >> Le 07/03/17 à 22:48, Dejan Jocic a écrit :
> >> 
> >>> You can still use Debian without systemd as init. Explained
> >>> here:
> >>> 
> >>> https://lists.debian.org/debian-user/2017/05/msg00538.html
> >>> 
> >>> If you would prefer that it is some derivate/fork of Debian
> >>> without systemd, I do not have personal experience with those,
> >>> but I'm sure that you will get few hints.
> >> 
> >> init is a small part of systemd. And judging y the bug reported and
> >> how they are treated, I do not trust any part of it. Neither
> >> resolved, logind, etc...
> > 
> > So you do not trust udev as well?
> 
> I consider it unfortunate that udev is maintained as part of the systemd
> suite, rather than being maintained independently (even if by the same
> people), purely from a separation-of-distinct-things perspective.
> 
> I haven't seen any relevant problems with it to date, however; the worst
> aspect of that maintenance situation is that it means upgrading udev
> shows the systemd changelog (which rarely has any relevant changes
> listed), rather than only a changelog for udev itself.

Um. So called Predictable Network Interface Names, for starters.
Does *very funny* things to Debian (anything that have net.ifnames=1
really) running in ESXi.

Somewhat old, but truly golden story about udev and firmware loading -
https://lwn.net/Articles/518942/

And, of course #762018 deserves a honorable mention.


> >> And it is NOT possible to use debian without any part of systemd.
> > 
> > Indeed it is. It is not possible to use Debian without udev.
> > Everything else is optional though.
> 
> You do at least also need libsystemd0 - or at any rate, trying to remove
> that on my (otherwise systemd-free) system results in removing 735
> packages, and leaving at least a few hundred others in "automatically
> installed, would be removed by autoremove" state.

True. But does libsystemd0 count? It's a library, not an executable.

Reco

Re: glusterfs and qemu/kvm

[Jason Wittlin-Cohen]

The last post on the bug report indicates that this issue has been fixed.
The changelog for the fixed version states:

   * enable glusterfs support (glusterfs-common), in qemu-block-extra

Stretch and newer contain qemu-block-extra, and it depends on glusterfs-common.


On Jul 6, 2017 8:10 AM, "Dave Sherohman"  wrote:

I'm currently running a number of virtual hosts under qemu/kvm backed by
iscsi storage and would like to move the storage onto glusterfs.
Unfortunately, Debian's qemu does not come with gluster support.  When
searching for information on this, I came across this bug report:

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

It was tagged wontfix in Oct 2015 and closed Dec 2016.  The basic reason
for the wontfix is that gluster is packaged in a way which makes it
infeasible to provide gluster support in the core qemu package, or even
to create a qemu-glusterfs package, and this in turn is because upstream
does things in a way which would make it difficult to maintain a stable
glusterfs-dev package.

Has this situation changed at all since then?  Assuming it hasn't, is
there a recommended procedure for replacing the standard Debian qemu
with a version which adds gluster support?

--
Dave Sherohman

Re: Replace systemd

[Jonathan Dowland]

On Thu, Jul 06, 2017 at 07:34:04AM -0400, The Wanderer wrote:

Am I?


I'm bored now of repeating myself.


Certainly there are ways to set things up in advance so that the
installer will never install the systemd-sysv package (or at least there
are reported to be - I've never tried any of them myself


*screeching halt*

Let me know when you have, and I may be prepared to discuss it with
you again.


--

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland

⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

a bug in apt-mirror ??

[Abdelkader Belahcene]

Hi everybody

I 've written a bash script and 2 small python files,  to fix a problem I
found in apt-mirror. I don't know if I don't use correctly apt-mirror.
I give my problem  and the script which solve the problem.

before that I don't understand this error ???:

Use of uninitialized value $config{"options"} in pattern match (m//) at
/usr/bin/apt-mirror line 300,  line 17.

The problem:   When I run  the apt-mirror  it gives the size to download to
update my local repos

if I run it again it gives the same (or approxiamativl) size to download,
so noting is added to my repos, when I check I found many packages not
updated. Here is the example ( just a part of the output)
:
5.4 GiB will be downloaded into archive.
Downloading 231 archive files using 20 threads...
Begin time: Thu Jul  6 09:17:29 2017
[20]... [19]... [18]... [17]... [16]... [15]... [14]... [13]... [12]...
[11]... [10]... [9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]...
[1]... [0]...
End time: Thu Jul  6 09:20:34 2017

4.5 MiB in 22 files and 0 directories can be freed.



just after that if run a get the same size to download

5.4 GiB will be downloaded into archive.
Downloading 207 archive files using 20 threads...
Begin time: Thu Jul  6 09:36:56 2017
[20]... [19]... [18]... [17]... [16]... [15]... [14]... [13]... [12]...
[11]... [10]... [9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]...
[1]... [0]...
End time: Thu Jul  6 09:37:26 2017

4.5 MiB in 22 files and 0 directories can be freed


MYSOLUTION: maybe somebody wants to use  or improves them
I send in attached file 3 scripts : aptMirrorMod.sh ,
OfficialPackages.py  and  differences.py
The goal of them scripts is to determine the  packages which are different
in the local and remote mirror ( the size is different  or not installed at
all).
It is not necessary to check the checksum since the remote site (official)
is supposed correct.



I hope these programs will serve some people

best regrads

### OfficialPackages.py
##  Construct the legal name for Package
## from nam, version, ...

s=open('Size.txt', 'r')
p=open('Paq.txt', 'r')
v=open('Vers.txt', 'r')
a=open('Arch.txt', 'r')
fd=open('remotePackages.sort', 'w')

while 1:
ss=s.readline()
if ss=='':  break
pp = p.readline()
vv = v.readline()
aa = a.readline()
ls=len(ss)
sss=ss[0:ls-1]
ls=len(pp)
ppp=pp[0:ls-1]
ls=len(vv)
vvv=vv[0:ls-1]
ls=len(aa)
aaa=aa[0:ls-1]

res= sss+'\t'+ppp+'_'+vvv+'_'+aaa+'.deb\n'
  
fd.write(res)
s.close()
p.close()
v.close()
a.close()
fd.close()
### differences.py program
## gives the list of the missed Packages
##  or the  wrong size Package
##  comparing to the official site


r=open('remotePackages.sort', 'r')### The oficial Packages 
p=open('localPackages.sort', 'r')  ###  local Files


fd=open('Result.sort', 'w')

while 1:
pp=p.readline()
if pp=='':  break
ppp=pp.split()
rr = r.readline()
rrr=rr.split()
while  rrr[1] <  ppp[1]:
res=rrr[0]+"  "+ rrr[1]+ "\t\t\t  00  \t\t missing\n"
print (res)
fd.write(res)
rr = r.readline()
rrr=rr.split()

aaa=rrr[0]+"  "+ rrr[1]+ " \t\t"+ rrr[0]+"  "+ rrr[1]+'\n'
print(aaa)
fd.write(aaa)


p.close()
r.close()




aptMirrorMod.sh
Description: Bourne shell script

Re: Replace systemd

[The Wanderer]

On 2017-07-06 at 07:48, Reco wrote:

> Hi.
> 
> On Thu, Jul 06, 2017 at 12:53:29PM +0200, Erwan David wrote:
> 
>> Le 07/03/17 à 22:48, Dejan Jocic a écrit :
>> 
>>> You can still use Debian without systemd as init. Explained
>>> here:
>>> 
>>> https://lists.debian.org/debian-user/2017/05/msg00538.html
>>> 
>>> If you would prefer that it is some derivate/fork of Debian
>>> without systemd, I do not have personal experience with those,
>>> but I'm sure that you will get few hints.
>> 
>> init is a small part of systemd. And judging y the bug reported and
>> how they are treated, I do not trust any part of it. Neither
>> resolved, logind, etc...
> 
> So you do not trust udev as well?

I consider it unfortunate that udev is maintained as part of the systemd
suite, rather than being maintained independently (even if by the same
people), purely from a separation-of-distinct-things perspective.

I haven't seen any relevant problems with it to date, however; the worst
aspect of that maintenance situation is that it means upgrading udev
shows the systemd changelog (which rarely has any relevant changes
listed), rather than only a changelog for udev itself.

>> And it is NOT possible to use debian without any part of systemd.
> 
> Indeed it is. It is not possible to use Debian without udev.
> Everything else is optional though.

You do at least also need libsystemd0 - or at any rate, trying to remove
that on my (otherwise systemd-free) system results in removing 735
packages, and leaving at least a few hundred others in "automatically
installed, would be removed by autoremove" state.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: Relative stability of Testing vs Unstable

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jul 06, 2017 at 06:52:13AM -0500, John Hasler wrote:
> tomas writes:
> > Big, heavily interdependent systems [...]

> I have full Perl and Python environments and I sometimes run CFD, FEM
> and CAD packages.  I think that the key is that I scan debian-dev for
> warnings and don't try to "track" Unstable by upgrading daily.  It's
> best not to upgrade during the first few weeks after a release.

Yes, those two practices go a long way towards keeping you out of
trouble.

> I don't think "just a window manager" quite describes FVWM.

:-)

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlleLSUACgkQBcgs9XrR2kb/kQCfd7EJWLCfr+qFAt+onx0OIjLK
+YUAnR/QS64aAQQTB6j0MapnfInICfy/
=N1zi
-END PGP SIGNATURE-

Re: Replace systemd

[Greg Wooledge]

On Thu, Jul 06, 2017 at 07:34:04AM -0400, The Wanderer wrote:
> But that is not the scenario I am discussing. I am discussing the
> experience which an ordinary user, who simply selects from the options
> which the installer lists, will have. (My use of the term "option" in
> the quoted paragraph, as well as the one preceding it in my last mail,
> was referring to the options which the installer presents.)

The experience of the ordinary user installing Debian is that they
will have systemd, and things will just work.

Of course, this may require that they use an installer with non-free
firmware for support of their proprietary hardware, but that's outside
the context of your init system activism/trolling.

They also need to *NOT* use a live CD image, because those have never
worked.  Again, a separate issue, but it's far more important than
yours.  We get multiple users *per day* in #debian asking how to work
around whatever their live-CD-install broke.  Care to guess how many
users we get per day asking how to replace systemd?

As Don Armstrong already said, the Debian developers are *not* going
to change the installer to add the option you keep yelling for.  Just
get over it.

glusterfs and qemu/kvm

[Dave Sherohman]

I'm currently running a number of virtual hosts under qemu/kvm backed by
iscsi storage and would like to move the storage onto glusterfs.
Unfortunately, Debian's qemu does not come with gluster support.  When
searching for information on this, I came across this bug report:

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

It was tagged wontfix in Oct 2015 and closed Dec 2016.  The basic reason
for the wontfix is that gluster is packaged in a way which makes it
infeasible to provide gluster support in the core qemu package, or even
to create a qemu-glusterfs package, and this in turn is because upstream
does things in a way which would make it difficult to maintain a stable
glusterfs-dev package.

Has this situation changed at all since then?  Assuming it hasn't, is
there a recommended procedure for replacing the standard Debian qemu
with a version which adds gluster support?

-- 
Dave Sherohman

Re: Relative stability of Testing vs Unstable

[John Hasler]

songbird writes:
> i've been running testing with bits from unstable and/or experimental
> for quite some time now.

Experimental is a completely different kettle of fish.  Unstable
contains packages that the developer hopes and expects will migrate to
Testing and end up in Stable without incident, and he's usually right.
Experimental, on the other hand, contains packages that the developer
wants people to experiment with.  It is not a mistake or policy
violation to upload a package known to contain a grave bug to
Experimental.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Replace systemd

[Reco]

Hi.

On Thu, Jul 06, 2017 at 12:53:29PM +0200, Erwan David wrote:
> Le 07/03/17 à 22:48, Dejan Jocic a écrit :
> > 
> > You can still use Debian without systemd as init. Explained here:
> > 
> > https://lists.debian.org/debian-user/2017/05/msg00538.html
> > 
> > If you would prefer that it is some derivate/fork of Debian without
> > systemd, I do not have personal experience with those, but I'm sure that
> > you will get few hints.
> > 
> init is a small part of systemd. And judging y the bug reported and how
> they are treated, I do not trust any part of it.
> Neither resolved, logind, etc...

So you do not trust udev as well?


> Too many critical bugs found in them and treated by the upstream
> developpers with only contempt for the people reporting them
> (see https://github.com/systemd/systemd/issues/6237#issuecomment-312458445)

By that logic (in)famous libc bug 4980 shoud've stopped by from using
any sane Linux distribution 10 years ago. Did it?


> This behaviour on a critical component is mere madness.

OpenBSD folks beg to differ.

https://marc.info/?l=openbsd-tech=149902196520920=2


> And it is NOT possible to use debian without any part of systemd.

Indeed it is. It is not possible to use Debian without udev. Everything
else is optional though.

Reco

Re: Replace systemd

[The Wanderer]

On 2017-07-06 at 04:09, Dejan Jocic wrote:

> On 06-07-17, David Griffith wrote:
> 
>> I'm aware of that technique.  What I was talking about is a menu
>> option that pops up when the install is running that explicitly
>> asks the person installing which init to use.
> 
> There was no such option when SysVinit was default. Why would it
> exist now?

Because now there are multiple prominent init-system alternatives from
which to choose, and the question has been brought to the forefront
since we are no longer running purely on inertia in this matter.

My own preferred way of addressing the init-system dispute would have
been to add exactly this sort of installer option for jessie, without
changing the default away from sysvinit, and then change the default to
systemd for *stretch*, while retaining the installer option.

We had no option for a long time because there was only one init system
that was meaningfully available, and then because the possible
alternatives (even if being seriously considered) were not particularly
controversial. That was inertia and laziness, and is not a good way of
doing things.

Now that the fact of this omission has been brought to our attention,
the right thing to do would be to provide such an option, and once the
option is established in the ecosystem, *then* change which alternative
is selected by default.

I would say that even if sysvinit were still the default alternative.
Once the fact that you've been omitting an option to choose where
meaningful choice exists is known, to fail to correct that omission is a
fault.

> There are also no options to choose default browser, editor, video 
> player, music player and so on. But everyone is free to install and
> set as default whatever they like. Including init system.

IIRC there is an option to choose default WM or DE, however, albeit from
a limited list (I'm thinking of task-gnome-desktop, task-kde-desktop,
task-xfce-desktop, etc.) - and there is the option to install without
any of the above and make the decision later, whereas there is no such
option for the init system.

Most of those aren't nearly as controversial as the init-system choice
has proven, either - and the ones which are (vi vs. emacs, anyone?)
don't tend to install *any* of the controversial options by default,
last time I checked. Since not installing an init system isn't a
meaningful possibility, providing a "select your choice" option is the
next best thing.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: Bash Question

[Greg Wooledge]

On Thu, Jul 06, 2017 at 05:25:05PM +1000, David wrote:
> Shells do not set this variable to identify themselves.

> On jessie, 'man 1 login', states that it sets SHELL. I understand this to
> mean that 'login' exports SHELL as an environment variable to child
> processes of 'login'.
> 
> I believe 'login' sets SHELL to the value of the user's login shell, as read
> from /etc/passwd. Once. And after that it does not change.

Yes, this is correct.  The SHELL variable is used by programs like vi
that have a "shell escape" feature, so that they know which shell to
execute.  (And also X terminal emulators, etc.)  It's what shell you
*want*, not what shell you *are*.

Other login-type programs should also export SHELL, including sshd and
the various Display Managers.

If you want to know which shell you're currently in, the best command
I've found so far is:

ps -p $$

Works in Bourne family shells, csh family shells, SysV family ps, and
BSD family ps.  Of course, it's only as accurate as the output of ps,
which a clever user can spoof by overriding argv[0], or by creating
a symlink.

wooledg:~$ (exec -a tentaclesh bash)
wooledg:~$ ps -fp $$
UIDPID  PPID  C STIME TTY  TIME CMD
wooledg  19021  2244  0 07:47 pts/600:00:00 tentaclesh
wooledg:~$ ps -p $$
  PID TTY  TIME CMD
19021 pts/600:00:00 bash

wooledg:~$ ln -s /bin/bash tentaclesh
wooledg:~$ ./tentaclesh
wooledg:~$ ps -p $$
  PID TTY  TIME CMD
19029 pts/600:00:00 tentaclesh
wooledg:~$ ps -fp $$
UIDPID  PPID  C STIME TTY  TIME CMD
wooledg  19029  2244  0 07:51 pts/600:00:00 ./tentaclesh

ps's output is inherently unreliable, but "ps -p $$" with *NO* other
options gives you the best chance you will get.  Still, nothing is
perfect.

Re: Relative stability of Testing vs Unstable

[John Hasler]

tomas writes:
> Big, heavily interdependent systems consisting of lots of packages
> (big language environments à la Perl, Python, Java -- but most
> prominently big desktop environments) are especially vulnerable to
> version churn, which typically happens in testing once in its life
> cycle.

I have full Perl and Python environments and I sometimes run CFD, FEM
and CAD packages.  I think that the key is that I scan debian-dev for
warnings and don't try to "track" Unstable by upgrading daily.  It's
best not to upgrade during the first few weeks after a release.

> People with a simple setup (e.g. just a window manager) perhaps won't
> even notice anything happened.

I don't think "just a window manager" quite describes FVWM.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Replace systemd

[The Wanderer]

On 2017-07-06 at 06:54, Jonathan Dowland wrote:

> On Wed, Jul 05, 2017 at 10:57:14PM -0400, The Wanderer wrote:
> 
>> Since it is not even conceptually possible to install Debian with
>> no init system at all (even if an option to do so existed, what
>> would it *do* in practice?), having there be an option to select
>> which of the available init systems should be installed - rather
>> than having to let the system install one, then clean it up later
>> on if that one is not the one you wanted -
> 
> You are arguing from a false premise: that the only way to install
> Debian is to first install systemd, then replace it with sysvinit.

Am I?

Certainly there are ways to set things up in advance so that the
installer will never install the systemd-sysv package (or at least there
are reported to be - I've never tried any of them myself, so I can't
speak from personal experience, but I also have no reason to doubt the
people who say that they exist).

But that is not the scenario I am discussing. I am discussing the
experience which an ordinary user, who simply selects from the options
which the installer lists, will have. (My use of the term "option" in
the quoted paragraph, as well as the one preceding it in my last mail,
was referring to the options which the installer presents.)

If there is a way to achieve the result you describe in that limited
context, I am not aware of it.

If my argument is based on that premise in some other way, I'm not
seeing how; could you clarify?

>> can seem like the solution least biased in favor of any particular
>> init system.
> 
> It seems quite proper that there *is* a bias here: towards the system
> that Debian recommends, that is judged to be the best choice for the
> majority of users, and will receive the most testing.

There's still room to argue about the degree to which that bias should
be manifest, however.

It seems hard to dispute that that bias should extend at least as far as
determining which init system will be installed if the user does not
take action to select an alternative one. That's more or less the
definition of "default" in this context.

It also seems hard to dispute that the bias should *not* extend as far
as actively impeding the ability to install and make active another init
system. Fortunately, Debian does not actually do that, and I'm not sure
I've seen anyone argue that it should.

That would establish the outer bounds; in between, disputing any
specific proposition becomes easier, and arguing against such becomes
harder. For example, it seems considerably harder to argue that the bias
should extend as far as refusing to present the (few) mature,
established alternatives to be selected - and yet that is exactly what
people arguing against having the installer include an option for this
seem to be doing.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: Relative stability of Testing vs Unstable

[songbird]

Jason Cohen wrote:
...
> My question is how Debian Testing and Unstable compare in terms of
> stability.  The Debian documentation suggests that Testing is more
> stable than Unstable because packages are delayed by 2-10 days and can
> only be promoted if no RC bugs are opened in that period [1].  Yet,
> other sources indicate that Testing can stay broken for weeks due to
> large transitions or the freeze before a new stable release [2]. 

  i keep two bootable partitions available and upgrade
them out of step so that i always have at least one
that works well enough i can get my required tasks done.

  i've been running testing with bits from unstable
and/or experimental for quite some time now.  i've 
had problems here or there with different pieces but
only rarely been bitten where i did not have things
running at all.  luckily all situations were fixable
without reinstallation.

  i'm very happy with how it has been going.  i think 
Debian rocks and i'm very appreciative of everyone who 
makes any sort of contribution to the on-going 
development and packaging.


  songbird

Re: Bash Question

[Rainer Dorsch]

Am Donnerstag, 6. Juli 2017, 11:50:44 CEST schrieb to...@tuxteam.de:
> On Thu, Jul 06, 2017 at 09:57:50AM +0100, Darac Marjal wrote:
> > On Thu, Jul 06, 2017 at 12:22:29AM +0200, Javier Barroso wrote:
> > >Hi,
> > >
> > >On Wed, Jul 5, 2017 at 11:12 PM, Rainer Dorsch  wrote:
> > >>Hi,
> > >>
> > >>
> > >>
> > >>can anybody help to explain what is going on here ?
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>rd@mohot:~$ echo $SHELL
> > >>/bin/bash
> > >>rd@mohot:~$ if [ "abc" > "dec" ]; then echo bad; fi
> > >>bad
> > >>rd@mohot:~$ if [ "abc" < "dec" ]; then echo good; fi
> > >>good
> > >>rd@mohot:~$
> > >>
> > >>How can abc sort before and after dec at the same time?
> > >
> > >You need to scape "<" and ">":
> > >
> > >if [ "abc" \> "dec" ] ; then ... ;fi
> > >if [ "abc" '>' "dec" ]; then ... ; fi
> > >if [ "abc" ">" "dec" ]; then ... ; fi
> > >
> > >
> > >Delete "dec" file, ( ">" is redirection in bash, so you was creating that
> > >file> 
> > That's a very good point. ">" and "<" are NOT the greater-than/less-than
> > operators in bash.
> 
> They are (in bash: see below!) -- just check bash's manual page under
> "conditional expressions".
> 
> For strings, they list '==' and '=', '!=', '<' and '>'.
> 
> Now *if* you use '[' (single square bracket) as above, you are not using
> bash's built in [this is a little white lie[1], see below], but the external
> command 'test' or some cousin of that (just try "ls -l /usr/bin/[" to see
> what I mean. This one doesn't understand < and >.
> 
> If you want bash's builtin, use '[[' (double square bracket). It's faster
> (one less fork/exec), but also more convenient, because it "knows" that
> there's special syntax inside, so you don't need to escape < and > (as
> someone pointed out in this thread, see (again) below).
> 
> This works:
> 
>   if [[ "abc" < "bcd" ]] ; then  echo "yo" ; else echo "no" ; fi
> 
> Or this
> 
>   if [[ -n "abc" && ( "abc" < "bcd" ) ]] ; then  echo "yo" ; else echo "no"
> ; fi
> 
> (note I didn't have to escape the parens, which would wreak havoc
> elsewhere in the command line, because they have a special meaning
> for the shell, and the shell does expansion before calling commands.
> Only a builtin can achieve that).
> 
> Now try this:
> 
>   if [ "abc" < "bcd" ] ; then  echo "yo" ; else echo "no" ; fi
> 
> (note I chose '<' -- and hope there's no file 'bcd' lying around).
> Then I get:
> 
>   bash: bcd: No such file or directory
> 
> Now this all was a lie :-)
> 
> Or half. The '[' can be a builtin, after all (in bash). You can
> switch that on or off with the enable -- uh -- builtin.
> 
> Just type "help enable" at your favourite bash instance to learn
> about that.
> 
> But the '[' builtin has to behave as far as possible like the
> /usr/bin/[ of yore (aka POSIX 'test'). Including the way the
> shell "expands its innards" before handing things to the command.
> 
> That's why there is [[. Much easier to write and much easier on
> the eye.
> 
> BUT: this all won't work on dash (Debian's preferred non-interactive
> shell: much smaller and faster). There you have to spell things like
> so:
> 
>   if [ "abc" \< "bcd" ] ; then  echo "yo" ; else echo "no" ; fi
> 
> So dash's '[' is a builtin too (remember: /usr/bin/[ doesn't grok
> '<' at all). But dash hasn't the '[[' with its syntactic convenience.
> 
> Hope that helps, somewhat :-)
> 

Many thanks for all the answers (and scaring that kmail just omitted some 
stuff in the Text mail and just included it in the HTML part...this time w/o 
html). They helped a lot to solve my problem...

Thanks again
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Re: Relative stability of Testing vs Unstable

[John Hasler]

> My experience, solely as a user, has been that sometimes the unstable
> distribution breaks and you're hosed.  I can't remember when I was
> last burned by running testing.

I can't remember when I was last burned by Unstable.  It is necessary to
follow debian-dev to know when not to upgrade.  I also do not upgrade
very frequently
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

KDE & k3b & cdr0

[JAP]

Estimados:

Tengo dos equipos muy similares, casi idénticos, corriendo "buster".
En ambos, el entorno es KDE 16.08.3, con Plasma 5.8.7.
Las lectograbadoras se identifican como "/dev/sr0" y se montan en 
"/media/cdrom0", con un enlace a "/media/cdrom".


Ayer, por casualidad, me di cuenta que el notificador de dispositivos no 
"detecta" los CD/DVD en blanco.


Me explico.
Hasta no hace mucho, cuando insertaba un CD o DVD en blanco, 
automáticamente el notificador lo indicaba con una ventana emergente, y 
me preguntaba qué hacer; por ejemplo, iniciar k3b.


Ahora no lo hace, en ninguno de los dos sistemas.

Vale aclarar que si inserto un CD o DVD con datos, lo detecta y muestra 
opciones como siempre: copiar, abrir en el navegador, reproducir 
multimedia, etcétera.


Lo de que "no detecta" es relativo, dado que si abro las opciones para 
"Configurar dispositivos extraíbles" del notificador, en la primera 
parte donde indica "Dispositivos conectados", aparece graciosamente que 
la lectograbadora tiene insertado un CD/DVD en blanco.


Si abro k3b, también lo tiene detectado y listo a grabar.

En otros dos equipos que corren "jessie", muy distintos ellos entre sí, 
detectan como siempre la inserción de un CD/DVD en blanco.


No es un problema, es una curiosidad, dado que empecé a revolver la web, 
y alrededor del 2008 hubo un tema similar; los foros de KUbuntu están 
plagado de ello.


La única "pega" es que alguna hija mía muy chica que quiere grabar algo, 
me dice que "la grabadora no anda", pues no le aparece la notificación 
como antes. (Así fue como me di cuenta del "problema").


Gracias en adelanto.

JAP

Re: Tu es vraiment le centre d’attention sur ce site Lea

[corentin95]

Le 2017-07-06 11:05, Lea Bookfa a écrit :

Je suppose que tu ne vas même pas me parler…
http://bitly.com/2sP8vAv


Qui est rapi...@orange.fr 

Re: Replace systemd

[Jonathan Dowland]

On Wed, Jul 05, 2017 at 10:57:14PM -0400, The Wanderer wrote:

Since it is not even conceptually possible to install Debian with no
init system at all (even if an option to do so existed, what would it
*do* in practice?), having there be an option to select which of the
available init systems should be installed - rather than having to let
the system install one, then clean it up later on if that one is not the
one you wanted -


You are arguing from a false premise: that the only way to install 
Debian is to first install systemd, then replace it with sysvinit.



can seem like the solution least biased in favor of any
particular init system.


It seems quite proper that there *is* a bias here: towards the system that
Debian recommends, that is judged to be the best choice for the majority of
users, and will receive the most testing.


--

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland

⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Replace systemd

[Erwan David]

Le 07/03/17 à 22:48, Dejan Jocic a écrit :
> 
> You can still use Debian without systemd as init. Explained here:
> 
> https://lists.debian.org/debian-user/2017/05/msg00538.html
> 
> If you would prefer that it is some derivate/fork of Debian without
> systemd, I do not have personal experience with those, but I'm sure that
> you will get few hints.
> 
init is a small part of systemd. And judging y the bug reported and how
they are treated, I do not trust any part of it.
Neither resolved, logind, etc...
Too many critical bugs found in them and treated by the upstream
developpers with only contempt for the people reporting them
(see https://github.com/systemd/systemd/issues/6237#issuecomment-312458445)

This behaviour on a critical component is mere madness.
And it is NOT possible to use debian without any part of systemd.

For me debian stretch is inherently unsecure because of this and I am in
the process of replacing it on any machine I own (mostly by FreeBSD), I
may try a gentoo or a devuan.

Re: Replace systemd

[Jonathan Dowland]

On Wed, Jul 05, 2017 at 04:49:41PM -0700, Jimmy Johnson wrote:
Is it true that systemd only allows sysvinit to run inside of systemd, in fact 
systemd is starting your computer and shutting down your computer and still 
running in the background while you are using your computer?


No. It is not true.

--

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland

⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Replace systemd

[Jonathan Dowland]

On Wed, Jul 05, 2017 at 04:41:42PM -0700, Patrick Bartek wrote:

All that can be done on a window manager only system, too.  Just install
the utility needed, either terminal or X-based..


You are missing the point entirely. I was not arguing it was impossible
to get that functionality without using a desktop environment. I was
arguing that some people *want* the desktop environment to do that for
them. Of course you can DIY. But not everyone wants to.

--

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland

⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Einstellungen in Kontact

[Jonathan Dowland]

https://lists.debian.org/debian-user-german/


--

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland

⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Plus de notification d'arrivée de courriel ni tâches Osmo

[maderios]

On 07/06/2017 10:50 AM, Alain Rpnpif wrote:

Le  5 juillet 2017, Benoit B a écrit :


Bonjour,

Depuis la mise à jour en stretch, je n'ai plus de notification
visuelle sous LXDE.

Dans un terminal graphique :
~$ notify-send "test"
Rien ne se passe.

https://packages.debian.org/stretch/libnotify-bin
  est installé

Si je lance manuellement
/usr/lib/notification-daemon/notification-daemon

Ca marche, je peux donc contourner le problème en l'ajoutant dans :
$HOME/.config/lxsession/LXDE/autostart

Est-ce une bonne idée ? Je ne saurai pas ce qui a changé durant la
mise à jour et d'où vient le problème...


Oui pourquoi pas.
Moi je l'ai ici :
/etc/xdg/autostart/notification-daemon.desktop
qui contient :

[Desktop Entry]
Name=Notification Daemon
Comment=Display notifications
Exec=/usr/lib/notification-daemon/notification-daemon
Terminal=false
Type=Application
NoDisplay=true
OnlyShowIn=LXDE;OPENBOX;GNOME;
AutostartCondition=GNOME3 unless-session gnome

Si on rencontre un problème après un changement de version, il est 
souvent plus efficace et plus propre de supprimer complètement la 
vieille conf de l'utilisateur, de redémarrer l'environnement de bureau 
puis de le personnaliser.


--
Maderios

gros soucis avec xrdp et rdesktop

[bernard . schoenacker]

bonjour,

je n'arrive plus à obtenir un affichage avec rdesktop et xrdp
 depuis que j'ai fait la migration vers stretch ...

comment faire pour avoir un desktop en rdp ?


pour mémoire (sur le serveur) :

apt-cache policy  xrdp
xrdp:
  Installé : 0.9.1-9
  Candidat : 0.9.1-9
 Table de version :
 *** 0.9.1-9 500
500 http://ftp.fr.debian.org/debian sid/main amd64 Packages
500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
 0.9.1-4~bpo8+1 100
100 http://ftp.fr.debian.org/debian jessie-backports/main amd64 Packages
 0.6.1-2 500
500 http://ftp.fr.debian.org/debian jessie/main amd64 Packages






et sur le poste client :

apt-cache policy rdesktop
rdesktop:
  Installé : 1.8.3-2+b1
  Candidat : 1.8.3-2+b1
 Table de version :
 *** 1.8.3-2+b1 500
500 http://httpredir.debian.org/debian sid/main amd64 Packages
500 http://httpredir.debian.org/debian testing/main amd64 Packages
500 http://httpredir.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status


alors que avec xrdp en version jessie ça marche


merci d'éclairer ma lanterne

slt
bernard

DESABONNEMENT

[Claire Andina]

Le 06/07/2017 à 10:18, Melissa Pouengpet a écrit :


Je suppose que tu ne vas même pas me parler…
http://bit.ly/2sPhVfd





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: Replace systemd

[Jonathan Dowland]

On Wed, Jul 05, 2017 at 04:32:17PM -0700, Patrick Bartek wrote:

If you're referring to "preseed" or "debootstrap" scenerios, those are
more "work-arounds" than a choice from within the installer -- What
my original query was about.  While they work, so does the other option
of switching inits after the system install is complete.  The latter, I
think, is less problematical.  No matter ...


No, I was referring to the expert mode option where you get to select the
exact packages you want. But yes, the preseeding and debootstrap options
are there too, you are right.

--

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland

⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

RE: Si seulement tu savais combien je suis épuisée de cette solitude Anais

[Mohamed MESSAOUDENE]

montre ton profil,ce que tu attends.Ton email est vide et l'adresse email 
n'existe pas



De : Anais Adiksayo 
Envoyé : mercredi 5 juillet 2017 10:39
À : debian-user@lists.debian.org
Objet : Si seulement tu savais combien je suis épuisée de cette solitude Anais


Voudrais-tu être mon étoile polaire ce soir?
http://bit.ly/2sLAroO

Re: Bash Question

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jul 06, 2017 at 09:57:50AM +0100, Darac Marjal wrote:
> On Thu, Jul 06, 2017 at 12:22:29AM +0200, Javier Barroso wrote:
> >Hi,
> >
> >On Wed, Jul 5, 2017 at 11:12 PM, Rainer Dorsch  wrote:
> >>Hi,
> >>
> >>
> >>
> >>can anybody help to explain what is going on here ?
> >>
> >>
> >>
> >>
> >>
> >>rd@mohot:~$ echo $SHELL
> >>/bin/bash
> >>rd@mohot:~$ if [ "abc" > "dec" ]; then echo bad; fi
> >>bad
> >>rd@mohot:~$ if [ "abc" < "dec" ]; then echo good; fi
> >>good
> >>rd@mohot:~$
> >>
> >>How can abc sort before and after dec at the same time?
> >
> >You need to scape "<" and ">":
> >
> >if [ "abc" \> "dec" ] ; then ... ;fi
> >if [ "abc" '>' "dec" ]; then ... ; fi
> >if [ "abc" ">" "dec" ]; then ... ; fi
> >
> >
> >Delete "dec" file, ( ">" is redirection in bash, so you was creating that 
> >file
> 
> That's a very good point. ">" and "<" are NOT the greater-than/less-than
> operators in bash.

They are (in bash: see below!) -- just check bash's manual page under
"conditional expressions".

For strings, they list '==' and '=', '!=', '<' and '>'.

Now *if* you use '[' (single square bracket) as above, you are not using
bash's built in [this is a little white lie[1], see below], but the external
command 'test' or some cousin of that (just try "ls -l /usr/bin/[" to see
what I mean. This one doesn't understand < and >.

If you want bash's builtin, use '[[' (double square bracket). It's faster
(one less fork/exec), but also more convenient, because it "knows" that
there's special syntax inside, so you don't need to escape < and > (as
someone pointed out in this thread, see (again) below).

This works:

  if [[ "abc" < "bcd" ]] ; then  echo "yo" ; else echo "no" ; fi

Or this

  if [[ -n "abc" && ( "abc" < "bcd" ) ]] ; then  echo "yo" ; else echo "no" ; fi

(note I didn't have to escape the parens, which would wreak havoc
elsewhere in the command line, because they have a special meaning
for the shell, and the shell does expansion before calling commands.
Only a builtin can achieve that).

Now try this:

  if [ "abc" < "bcd" ] ; then  echo "yo" ; else echo "no" ; fi

(note I chose '<' -- and hope there's no file 'bcd' lying around).
Then I get:

  bash: bcd: No such file or directory

Now this all was a lie :-)

Or half. The '[' can be a builtin, after all (in bash). You can
switch that on or off with the enable -- uh -- builtin.

Just type "help enable" at your favourite bash instance to learn
about that.

But the '[' builtin has to behave as far as possible like the
/usr/bin/[ of yore (aka POSIX 'test'). Including the way the
shell "expands its innards" before handing things to the command.

That's why there is [[. Much easier to write and much easier on
the eye.

BUT: this all won't work on dash (Debian's preferred non-interactive
shell: much smaller and faster). There you have to spell things like
so:

  if [ "abc" \< "bcd" ] ; then  echo "yo" ; else echo "no" ; fi

So dash's '[' is a builtin too (remember: /usr/bin/[ doesn't grok
'<' at all). But dash hasn't the '[[' with its syntactic convenience.

Hope that helps, somewhat :-)

Cheers
[1] OK, OK. A dirty grey lie. Read on :-)

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

iEYEARECAAYFAlleB/QACgkQBcgs9XrR2kZQqgCfbCXMBkw2vwJd2xtfqNSc2/bI
NBkAn1MM8uGnehVTxNQWAP07ptBwJSI9
=r8rB
-END PGP SIGNATURE-

And the UNasked questions are? - was [Re: Replace systemd]

[Richard Owlett]

On 07/05/2017 10:25 PM, David Griffith wrote:

[snip]
I'm aware of that technique.  What I was talking about is a menu
option that pops up when the install is running that explicitly
asks the person installing which init to use.



On 07/06/2017 01:28 AM, Ansgar Burchardt replied:

But there are far more urgent questions that don't get asked
at install time either:

1. Which editor to use at the default editor.
   (Even worse: emacs isn't even included in the install by default!)
2. Which shell to use as the login shell.
   I still have to install my favorite shell (zsh) manually :-(
3. Which web browser to install. Not everyone prefers Firefox.>
4. Which mail user agent to install.

I can go on.  All have to be chosen after install and I don't think
there is a good reason the init system should be special: likely a
larger number people cares more about the software they use all the
time.  So if anything, one should probably ask about that.


On 07/06/2017 03:09 AM, Dejan Jocic also replied:

There was no such option when SysVinit was default. Why would it
exist now? There are also no options to choose default browser,
editor, video player, music player and so on. But everyone is
free  to install and set as default whatever they like.
Including init system.



I would include among those UNasked questions:
  1. What is a common feature of the above and others in this thread?
  2.Thus, what is the Catch-22 quagmire faced by the installer team?

Re: Replace systemd

[David Griffith]

On July 5, 2017 9:11:27 AM PDT, The Wanderer  wrote:
>On 2017-07-05 at 11:27, Don Armstrong wrote:
>
>> On Tue, 04 Jul 2017, David Griffith wrote:
>
>>> It would be nice to have an install-time option for selecting the
>desired init.
>> 
>> It already exists:
>> 
>> https://lists.debian.org/debian-user/2017/04/msg00097.html
>> 
>> «
>> You can just append:
>> 
>> preseed/late_command="in-target apt-get install -y sysvinit-core"
>> 
>> to the installer command line.
>
>I suspect that what the people who ask for this are thinking of is a
>step in the installer sequence at which you are prompted to choose
>which
>init system you want to be installed, such that the installer will
>never
>even attempt to install any other init system.
>
>This differs from the suggested methods to date not only in avoiding
>"systemd-sysv was installed, then sysvinit-core replaced it later on"
>(which some of the suggested methods may also do), but also in the UX;
>having it presented to you as a choice, rather than having to know
>about
>it in advance and take separate steps on your own, makes a significant
>cosmetic and psychological difference, as well as affecting
>discoverability.
>
>If the installer doesn't present the option, then it's not really "an
>install-time option" in a certain sense; it takes on more the shape of
>advanced / expert hackery, rather than appearing to be something the
>developers actually support.
>
>I think that's the mindset, anyway.
>
>-- 
>   The Wanderer
>
>The reasonable man adapts himself to the world; the unreasonable one
>persists in trying to adapt the world to himself. Therefore all
>progress depends on the unreasonable man. -- George Bernard
>Shaw

These are exactly my motivations for an install-time prompt.
-- 
David Griffith
d...@661.org

Re: Je bent een ware aandachtspunt op deze site Sabrina

[rudi.louage]

No more mail

Verstuurd vanaf mijn iPad

> Op 6 jul. 2017 om 10:21 heeft Sabrina Narimissa  het 
> volgende geschreven:
> 
> Ik denk dat je niet eens met mij wilt praten... 
> http://bit.ly/2sPbWY0

Re: Bash Question

[Darac Marjal]

On Thu, Jul 06, 2017 at 12:22:29AM +0200, Javier Barroso wrote:

Hi,

On Wed, Jul 5, 2017 at 11:12 PM, Rainer Dorsch  wrote:

Hi,



can anybody help to explain what is going on here ?





rd@mohot:~$ echo $SHELL
/bin/bash
rd@mohot:~$ if [ "abc" > "dec" ]; then echo bad; fi
bad
rd@mohot:~$ if [ "abc" < "dec" ]; then echo good; fi
good
rd@mohot:~$

How can abc sort before and after dec at the same time?


You need to scape "<" and ">":

if [ "abc" \> "dec" ] ; then ... ;fi
if [ "abc" '>' "dec" ]; then ... ; fi
if [ "abc" ">" "dec" ]; then ... ; fi


Delete "dec" file, ( ">" is redirection in bash, so you was creating that file


That's a very good point. ">" and "<" are NOT the greater-than/less-than
operators in bash. [ "abc" > "dec" ] tests whether the result of "abc"
can be written to the file "dec". Note, however, the subtle difference
between, say [ echo "abc" > "dec" ] where echo executes and copies its
arguments to stdout, which is then written to the file - the success of
this operation is tested; [ "abc" > "dec" ] will try to run "abc". It
looks like bash will interpret the string as a command, so this is
equivalent to [ abc > dec ], i.e. running the command "abc" and
redirecting its output to the file "dec".

The correct operators are actually "-lt" and "-gt". However, these
operators only work on INTEGERs. If you really need to test for "sorts
before", then you may need to resort to using sort itself. 



Regards



--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Plus de notification d'arrivée de courriel ni tâches Osmo

[Alain Rpnpif]

Le  5 juillet 2017, Benoit B a écrit :

> Bonjour,
> 
> Depuis la mise à jour en stretch, je n'ai plus de notification
> visuelle sous LXDE.
> 
> Dans un terminal graphique :
> ~$ notify-send "test"
> Rien ne se passe.
> 
> https://packages.debian.org/stretch/libnotify-bin
>  est installé
> 
> Si je lance manuellement
> /usr/lib/notification-daemon/notification-daemon
> 
> Ca marche, je peux donc contourner le problème en l'ajoutant dans :
> $HOME/.config/lxsession/LXDE/autostart
> 
> Est-ce une bonne idée ? Je ne saurai pas ce qui a changé durant la
> mise à jour et d'où vient le problème...

Oui pourquoi pas.
Moi je l'ai ici :
/etc/xdg/autostart/notification-daemon.desktop
qui contient :

[Desktop Entry]
Name=Notification Daemon
Comment=Display notifications
Exec=/usr/lib/notification-daemon/notification-daemon
Terminal=false
Type=Application
NoDisplay=true
OnlyShowIn=LXDE;OPENBOX;GNOME;
AutostartCondition=GNOME3 unless-session gnome

-- 
Alain Rpnpif

Re: "ACPI error" depuis passage à Stretch

[Alain Rpnpif]

Le  5 juillet 2017, Benoit B a écrit :

> Idem pour moi,
> 
> ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x5) is beyond
> end of object (length 0x5) (20160831/exoparg2-427)
> [   14.235257] ACPI Error: Method parse/execution failed
> [\_SB.PCI0.GFX0._DOD] (Node 9317bb0ab500), AE_AML_PACKAGE_LIMIT
> (20160831/psparse-543)
> [   14.235269] ACPI Exception: AE_AML_PACKAGE_LIMIT, Evaluating _DOD
> (20160831/video-1254)

Pour moi aussi sur une carte MSI avec microprocesseur AMD A4-5300 APU,
récente.

Je n'ai pas remarqué d'autres dysfonctionnements liés à cette erreur. Je
suis sous Jessie-backports avec pratiquement le même noyau que Sketch
(4.9).

-- 
Alain Rpnpif

Re: Relative stability of Testing vs Unstable

[Fungi4All]

I can not help much in developing or bug analysis, so my contribution has been 
to test
what is handed out to me for testing. I have yet not been able to contribute 
much as
nothing seems to break in testing or sid (amd64 openbox/lxde) ever. Sometimes I
wonder when I read the list or archives things being problematic for stable 
that I
have never encountered. Maybe lucky, maybe not trying hard enough.
What I have learned testing different distributions is that "stable" and secure 
are not
nearly associated as many people think. My latest favority other distribution 
has been
Manjaro. I currently run linux 4.9/4.11/4.12 in testing there, no problems. 
Some packages
in Manjaro stable are 2-3 years advanced in development than what is maintained 
in
Debian. Very few functionality problems (they can't seem to work along with the 
grub team).
But, is everything going through the same kind of scrutiny with debian or are 
people
exposed to 2-3 years of risk before debian discovers the problem before it 
introduces a
package version in sid? I can not yet tell.
So when I am in worry free mode of whatever happens happens, I use Manjaro.
For everything else I use testing and sid.
9/10 of debian based distros has been a waste of time and 0 learning value. My
ordered favorites within the 1/10 has been kali, siduction, tails (for the 
shake of
keeping an eye of what is changing in that field and getting security ideas) .
But they are almost clean debian with some custom extra packages.
Switching from Debian to Manjaro is like parking the dodge (slant 6) van for
daily use and picking up the sportbike for a careless rural ride. You just can't
go to work with a full leather uniform or park it at the metro station.
This is my experience with it all.
PS There has been a glimpse of an issue of "security for nothing" in Debian
as I have been able to place files or edit files at my Debian /home from
Manjaro but not the other way around. So I wonder, if manjaro root can
read and write in my debian-user's /home where is the security in being
unable as debian root to even take a peak at the user's directory?
Don't trust your arch/manjaro sys-admin but feel comfortable with Debian
sys-admin, unless he is booting a different system? For a single
user system Debian makes your life harder, hopefully not for nothing.

Re: CUPS

[Alain Rpnpif]

Le  5 juillet 2017, Benoit B a écrit :

> J'ai donc supprimé, l'imprimante et en ai ajouté une nouvelle en
> utilisant un autre pilote.
> Driver:Brother HL-2030 - CUPS+Gutenprint v5.2.11 (grayscale, 2-sided printing)
> 
> Comme Règles d'erreur, j'ai essayé "abort-job" puis "retry-job".
> 
> L'impression d'une page de test fonctionne parfaitement directement
> par le panneau de commande de l'imprimante(sans passer par le pilote).
> 
> Pour obtenir des log j'ai activé debug-logging comme indiqué plus haut.
> ~# cupsctl --debug-logging
> 
> Quand j'imprime une page de test via l'interface web de cups, rien ne
> se passe (pas de réaction de l'imprimante).
> Voici les log.
> access_log :
> localhost - - [05/Jul/2017:10:45:18 +0200] "POST
> /printers/Brother_HL-2030_series HTTP/1.1" 200 427 Print-Job
> successful-ok
> -
> page_log
> Ne réagit pas.
> -
> error_log est trop long en mode debug, je joins un fichier : cups_error_log
> 
> Quelqu'un a une idée ?

Parfois, une tâche (du filtre CUPS) sur le poste client plante ou est
très longue à se terminer.
Ghostscript a ce problème.

Juste après l'impression, lancer ps ax ou et top pour voir et
vérifier qu'une tâche d'impression ne tourne pas. Sur un ordinateur
relativement rapide, j'ai déjà vu une tâche d'impression mettre 10 min
avant de sortir. De la faiblesse de certains filtres de CUPS.

Je ferais des essais d'impression avec un fichier dont le filtre est
censé être simple du genre un fichier texte pur ou bien un PDF ne
contenant que du texte avec une seule police simple. En effet le PDF
est assez bien supporté par CUPS.

Avant, vérifier dans l'interface client de CUPS, que l'imprimante n'est
pas bloquée.

Que dit :
lpstat -p
?

-- 
Alain Rpnpif

Re: Replace systemd

[Dejan Jocic]

On 06-07-17, David Griffith wrote:
> 
> I'm aware of that technique.  What I was talking about is a menu option that
> pops up when the install is running that explicitly asks the person
> installing which init to use.
> 
> 
> -- 
> David Griffith
> d...@661.org
> 
> A: Because it fouls the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?


There was no such option when SysVinit was default. Why would it exist
now? There are also no options to choose default browser, editor, video
player, music player and so on. But everyone is free to install and set
as default whatever they like. Including init system.

Re: crontab

[jordi]

El dc 05 de 07 de 2017 a les 14:50 +0200, en/na Narcis Garcia va
escriure:
> __
> 
> > 
> > Pots provar amb systemd-cron o similar. Tens més detalls a:
> > 
> > https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_repla
> > cement
> > 
> > La gràcia de fer-ho amb systemd és que pots indicar que aquesta
> > execució té una dependència de la xarxa posant això:
> > 
> > [Unit]
> > Description=...
> > After=network.target
> > 
> > Salut,
> > Alex
> > 
> 
> Aviat caldrà afegir més cognoms a Debian:
> Debian GNU/Linux/Systemd
> 

Hola, gracies per la resposta. He canviat el cron pel systemd-cron i al
menys, en els dos reinicis que he fet ha funcionat correctament. Ara em
falta provar-ho uns dies més per veure si està del tot arreglat.
Veig però que cada entrada a crontab afegeix un timer a systemd:
cron-jordi-jordi-0.timer
... 
cron-jordi-jordi-n.timer

cron-root-root-0.timer ..

Si em sorgeix algun problema sempre puc tornar al cron pelat i fer un
petit nyap. I m'hauré de llegir més a fons l'enllaç que has enviat.

Gracies.

Re: Relative stability of Testing vs Unstable

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jul 05, 2017 at 09:24:08PM -0500, John Hasler wrote:
> Jimmy Johnson writes:
> > From what I read, very serious bugs are likely to be caught before
> > making it to Testing, while Unstable benefits from getting security
> > updates (in the form of new upstream releases) sooner, and is more
> > likely to be consistent during transitions.
> 
> Unstable is not required to be consistent at all.
> 
> That said, I've always used it on my desktop and have not had a problem
> for at least ten years.  However, I use FVWM rather than a desktop
> environment.

I think that's an important point: it's not only "what do you use it
for" or "how much you enjoy tinkering" but also "what is on your system".

Big, heavily interdependent systems consisting of lots of packages
(big language environments à la Perl, Python, Java -- but most prominently
big desktop environments) are especially vulnerable to version churn,
which typically happens in testing once in its life cycle.

People with a simple setup (e.g. just a window manager) perhaps won't
even notice anything happened.

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlld7fUACgkQBcgs9XrR2kbJnwCfTj6q41PaTpNujGElKv7PQA+y
kBIAnjvSouQZysPYLU3SxOov+1RuX3ls
=lKZ3
-END PGP SIGNATURE-

Re: Présence par défaut d'Aptitude sur Stretch

[Alain Rpnpif]

Le 27 juin 2017, maderios a écrit :

> Oui, mais... Des dépendances installées automatiquement puis classées 
> "inutiles" par aptitude peuvent s'avérer indispensables.
> Aucun gestionnaire de paquets ne peut connaître les tréfonds de l'âme 
> humaine... Dans ce cas, le gestionnaire ne doit pas jouer au malin à 
> coups de suppressions intempestives mais afficher ses propositions comme 
> le font apt, apt-get et synaptic.

Bonjour,
Je confirme ce que dit Maderios. J'ai utilisé aptitude pendant un temps
mais il peut faire du massacre trop facilement. Je trouve apt-get (ou
apt aujourd'hui ?) plus fiable, plus souple quand on le connais mieux.
Avec apt-mark (ou apt aujourd'hui ?), on peut garder certaines choses.

Mais quand j'ai un problème compliqué et que mon système de gestion
de paquets s'affolent parce que j'ai fais une erreur ou un truc hardi,
j'utilise aptitude. C'est de plus en plus rare (une fois tous les 6
mois). 

-- 
Alain Rpnpif

Re: Bash Question

[David]

On 6 July 2017 at 07:53, der.hans  wrote:
>
> "$SHELL" is a builtin variable that tells you what shell you're currently
> running.

No, that's "not accurate", as indeed you wrote later.

Shells do not set this variable to identify themselves.

This can be easily tested by starting any shell interactively and inspecting
$SHELL.

For example, in a terminal start a 'dash' shell and then run 'echo $SHELL'
inside it.

For more enlightenment, start a 'dash' shell with 'SHELL=foo dash' and
run 'echo $SHELL' inside it.

Below I refer to man pages (on jessie). I have not read any relevant
source code, nor do I know if systemd does anything different, someone
else is welcome to comment on that.

On jessie, 'man 1 login', states that it sets SHELL. I understand this to
mean that 'login' exports SHELL as an environment variable to child
processes of 'login'.

I believe 'login' sets SHELL to the value of the user's login shell, as read
from /etc/passwd. Once. And after that it does not change.

And 'man bash' states that 'bash' sets SHELL only if it was previously not
set, and that in that situation it sets SHELL to the value of the user's login
shell.

And 'man dash' doesn't mention SHELL, so I presume it does not touch
it at all.

> When using subshells ( including a shell script ) I find it to
> not be accurate. Could well be that I just don't consistently quote it
> properly.

It is accurate, just not in the way you imagined. Quoting isn't the reason :)

It is simply that the "shell you're currently running" can easily be different
to the login shell, which is what $SHELL is expected to contain.

Re: Replace systemd

[Ansgar Burchardt]

David Griffith writes:
> I'm aware of that technique.  What I was talking about is a menu
> option that pops up when the install is running that explicitly asks
> the person installing which init to use.

But there are far more urgent questions that don't get asked at install
time either:

1. Which editor to use at the default editor.
   (Even worse: emacs isn't even included in the install by default!)

2. Which shell to use as the login shell.
   I still have to install my favorite shell (zsh) manually :-(

3. Which web browser to install. Not everyone prefers Firefox.

4. Which mail user agent to install.

I can go on.  All have to be chosen after install and I don't think
there is a good reason the init system should be special: likely a
larger number people cares more about the software they use all the
time.  So if anything, one should probably ask about that.

Ansgar