Re: Be careful when editing /etc/fstab

[Andrei POPESCU]

On Mi, 24 iun 20, 19:07:40, Anders Andersson wrote:
> I agree, but documentation doesn't seem to have high priority in
> debian, it's a cultural issue. For example, in OpenBSD a developer
> never changes anything without also making sure that the documentation
> everywhere is up to date. It's become part of the mindset.

Most documentation comes from upstream.

Debian Developers are already doing a lot in this regard, e.g. by 
writing man pages where missing (as per Debian Policy requirement).

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


signature.asc
Description: PGP signature

Re: why foxit hasn't been included in buster?

[Long Wind]

 Thank Ben, i've just installed qpdfview.

On Thursday, June 25, 2020, 1:22:21 AM EDT, Ben Caradoc-Davies 
 wrote:  
 
 On 25/06/2020 17:01, Long Wind wrote:
>  oh, i see, it's not free, so it isn't included in debian mainthen i will try 
>evince

qpdfview is also nice. Qt application so takes a little fiddling to get 
consistent theming if you are using Gnome or other GTK-based desktop.

Kind regards,

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

  

Re: why foxit hasn't been included in buster?

[Ben Caradoc-Davies]

On 25/06/2020 17:01, Long Wind wrote:

  oh, i see, it's not free, so it isn't included in debian mainthen i will try 
evince


qpdfview is also nice. Qt application so takes a little fiddling to get 
consistent theming if you are using Gnome or other GTK-based desktop.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: why foxit hasn't been included in buster?

[Anders Andersson]

On Thu, Jun 25, 2020 at 6:45 AM Long Wind  wrote:
>
> some say it's among best pdf reader for linux
> how to install it in buster or stretch?

Not sure why you expect it to be included, it looks like commercial
software. Is the source even available on their website?

why foxit hasn't been included in buster?

[Long Wind]

some say it's among best pdf reader for linuxhow to install it in buster or 
stretch?

Re: Reminder about the Debian Code of Conduct

[davidson]

On Wed, 24 Jun 2020 Pierre-Elliott Bécue wrote:

Dear users,

In the past days we saw multiple emails discussing about non
Debian-related things and infringing the Code of Conduct[0] of the
Project in the same time.


Oh, crap. I think I know what this is about. Sorry everybody.


The Community Team would like to remind you that this Code of
Conduct is to be followed when communicating on any Debian
Discussion Medium, even by non Debian Members.

Following the CoC guidelines isn't hard, it's essentially about not
being unrespectful to other people,


Oh god. Look, this is about my signature, isn't it?

It's a joke, man. A reductio ad absurdum, if you will.


and it helps avoiding situations where any form of official
moderation would be needed.


Woah, slow down. If you really think it's a problem, I can change the
sig. All you gotta do is ask.


Anybody of course may have an opinion, but voicing it in
disrespectful ways can't be accepted, as it could drive other
members of the Community away.


Look, for the last time, it's not *my* opinion. It is (allegedly)
Horatio Nelson's. And the whole point is that it is a very, very DUMB
opinion. Held by nobody but chauvinist troglodytes that need to be
excluded from polite society for the good of all.

I know, I know. It is so sad. But there is no alternative if truly
open and accepting collaboration is to flourish in Freedomland.

In fact, the main point is that it is SO worthy of scorn that it needs
no more commentary than its own presentation, verbatim.


With best regards,


I hope that I have made myself perfectly clear so that you can stop
worrying and have a good week.

Next time (if there is one) maybe you could be a little more explicit
though?

And you will have to send me some links to videos of this Community
band, because I have never ever heard of them but I'm really into all
kinds of zombie apocalypse stuff.


[0] https://www.debian.org/code_of_conduct


--
Firstly, you must always implicitly obey orders, without attempting to
form any opinion of your own respecting their propriety. Secondly, you
must consider every man your enemy who speaks ill of your king; and
thirdly, you must hate a Frenchman, as you do the devil. --H. Nelson

Re: Advice on encrypted filesystem

[David Wright]

On Wed 24 Jun 2020 at 21:28:38 (-0400), rhkra...@gmail.com wrote:
> On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file 
> system 
> on a dedicated partition

What were the contents of this partition: the OS itself, or /home,
or an independent filesystem that you'd probably mount under /media?
Same this time around?

> (actually, two filesystems).

Do you mean you did this twice, or what?

> It was a PITA learning how to do it, and it was 6 years ago, and it looks 
> like 
> I have to relearn it to do it again on Jessie and / or Buster (and on a 
> backup 
> device).  (I have my "stream of consciousness" notes from when I did it back 
> then, but there were so many false starts / blind paths that the notes are 
> very confusing.)

Laptops? Do you use suspend? Desktops? Do you boot them remotely?

> I'm wondering if cryptsetup is still something like "state of the art" or if 
> there is anything more secure and simpler to learn to setup?

Cheers,
David.

Re: Advice on encrypted filesystem

[David Christensen]

On 2020-06-24 18:34, Roberto C. Sánchez wrote:

On Wed, Jun 24, 2020 at 09:28:38PM -0400, rhkra...@gmail.com wrote:

On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file system
on a dedicated partition (actually, two filesystems).

It was a PITA learning how to do it, and it was 6 years ago, and it looks like
I have to relearn it to do it again on Jessie and / or Buster (and on a backup
device).  (I have my "stream of consciousness" notes from when I did it back
then, but there were so many false starts / blind paths that the notes are
very confusing.)

I'm wondering if cryptsetup is still something like "state of the art" or if
there is anything more secure and simpler to learn to setup?



Assuming you are considering a new installation, which you seem to have
implied, then you should probably just try the Debian Installer.  The
support for installing to an encrypted partition has improved
considerably with each installer release.  The last time I did it with a
Buster installer it was not even necessary to consult my notes.


+1


Running cryptsetup(8) by hand is not very hard.  The challenge is 
deciding how to fit encryption into everything else -- passphrases, 
keys, boot, devices, partitioning, md RAID, LVM, file systems, ZFS, 
etc..  Post your requirements and people can guide you.



David

Re: Advice on encrypted filesystem

[Roberto C . Sánchez]

On Wed, Jun 24, 2020 at 09:28:38PM -0400, rhkra...@gmail.com wrote:
> On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file 
> system 
> on a dedicated partition (actually, two filesystems).
> 
> It was a PITA learning how to do it, and it was 6 years ago, and it looks 
> like 
> I have to relearn it to do it again on Jessie and / or Buster (and on a 
> backup 
> device).  (I have my "stream of consciousness" notes from when I did it back 
> then, but there were so many false starts / blind paths that the notes are 
> very confusing.)
> 
> I'm wondering if cryptsetup is still something like "state of the art" or if 
> there is anything more secure and simpler to learn to setup?
> 

Assuming you are considering a new installation, which you seem to have
implied, then you should probably just try the Debian Installer.  The
support for installing to an encrypted partition has improved
considerably with each installer release.  The last time I did it with a
Buster installer it was not even necessary to consult my notes.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Advice on encrypted filesystem

[rhkramer]

On my Wheezy system, I used cryptsetup to set up a LUKs  encrypted file system 
on a dedicated partition (actually, two filesystems).

It was a PITA learning how to do it, and it was 6 years ago, and it looks like 
I have to relearn it to do it again on Jessie and / or Buster (and on a backup 
device).  (I have my "stream of consciousness" notes from when I did it back 
then, but there were so many false starts / blind paths that the notes are 
very confusing.)

I'm wondering if cryptsetup is still something like "state of the art" or if 
there is anything more secure and simpler to learn to setup?

Re: Jupyter

[l0f4r0]

24 juin 2020 à 21:43 de nicolas.franc...@free.fr:

> Et ? Qu'est-ce que j'aurais du faire ? J'ai installé les paquets avec
> apt-get. Les commandes systemd sont exécutées en tant que
> super-utilisateur.
>
Comme indiqué sur le Wiki Debian, simplement :
systemctl --user enable jupyter-notebook.service
systemctl --user start jupyter-notebook.service

Ça marche toujours pas ?

l0f4r0

Reminder about the Debian Code of Conduct

[Pierre-Elliott Bécue]

Dear users,

In the past days we saw multiple emails discussing about non
Debian-related things and infringing the Code of Conduct[0] of the
Project in the same time.

The Community Team would like to remind you that this Code of Conduct
is to be followed when communicating on any Debian Discussion Medium,
even by non Debian Members.

Following the CoC guidelines isn't hard, it's essentially about not
being unrespectful to other people, and it helps avoiding situations
where any form of official moderation would be needed.

Anybody of course may have an opinion, but voicing it in disrespectful
ways can't be accepted, as it could drive other members of the Community
away.

With best regards,

[0] https://www.debian.org/code_of_conduct

-- 
Pierre-Elliott Bécue (for the Community Team)
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Looping Shell Scripts and System Load

[Martin McCormick]

Greg Wooledge  writes:
> All-caps names are reserved for environment variables (HOME, PATH),
> and internal shell variables (IFS, PWD, HISTFILE).
> 
> Avoiding all-caps names allows you to avoid collisions with a variable
> name that might be used for something else.  Most of the time.  This
> being the Unix shell, there are *always* stupid exceptions (http_proxy
> and friends on the environment side, and auto_resume and histchars in
> bash).

Thank you.  I learned something today that I didn't
expect to learn which is why I posted the question in the first
place.  I just wasn't thinking, I guess and used the all-caps
names to indicate that they stood for files.  If one collided
with an environment variable name, it could make the script fail
in strange ways that would be totally unpredictable, depending on
which variable one preempted.

Martin

Re: Jupyter

[Nicolas FRANCOIS]

Le Wed, 24 Jun 2020 21:08:19 +0200 (CEST),
l0f...@tuta.io a écrit :

> Bonjour,
> 
> 24 juin 2020 à 13:25 de nicolas.franc...@free.fr:
> 
> > Salut.
> >
> > J'ai installé sur mon ordinateur Jupyter (jupyter, jupyter-client,
> > jupyter-console, jupyter-core, jupyter-notebook, jupyter-qtconsole,
> > ipython), et je voudrais que le service soit lancé automatiquement
> > au démarrage du système.
> >
> > Sur la page https://wiki.debian.org/Jupyter, il est dit qu'on peut
> > faire cela avec systemd :
> > systemctl --user enable jupyter-notebook.service
> > systemctl --user start jupyter-notebook.service
> >
> > Mais quand je tape la première ligne (ou la deuxième), j'obtiens
> > ceci :
> >
> > nico@Gaston:~$ sudo systemctl enable jupyter-notebook.service
> > Failed to enable unit: Unit file jupyter-notebook.service does not
> > exist.
> >
> > Pourtant, j'ai ce qu'il faut, il me semble :
> > nico@Gaston:~$ locate jupyter-notebook.service
> > /usr/lib/systemd/user/jupyter-notebook.service
> >
> > Je ne suis pas très à l'aise avec systemd. Faut-il que je copie ce
> > script à un endroit où systemd peut le trouver ?
> >
> > D'avance merci pour toute explication :-)
> >  
> Probablement parce que tu as tapé les commandes en tant que
> super-administrateur via sudo et que tu n'as pas utilisé le switch
> --user ? La preuve, ton service est dans /usr/lib/systemd/user/

Et ? Qu'est-ce que j'aurais du faire ? J'ai installé les paquets avec
apt-get. Les commandes systemd sont exécutées en tant que
super-utilisateur.

Faut-il que je déplace le fichier du service autre part ? Si oui, où ?

D'avance merci. Et désolé pour la direction incorrecte, comme je le
signale dans la mailing liste anglophone, j'ai réglé mon client Claws
pour que les messages envoyés quand je suis dans ce dossier soient
dirigés vers la liste francophone... sauf que j'ai du me gourancer
quelque part :-(

\bye
 
> NB : je mets en Cc la ML debian-user-french
> 
> Bien cordialement,
> l0f4r0
> 



-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin


pgpSpktPZgB5q.pgp
Description: Signature digitale OpenPGP

Re: Jupyter

[Nicolas FRANCOIS]

Le Wed, 24 Jun 2020 13:47:25 +0200,
john doe  a écrit :

> This is an English mailing list, you might be better off in a French
> one! :)

Oups, sorry, I thought I had setup my Claws Mail client to post on the
french list when I'm in the french list directory.

Sorry for the noise.
 
\bye

-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin


pgpUNQ2hVYdVD.pgp
Description: Signature digitale OpenPGP

Re: Looping Shell Scripts and System Load

[David Christensen]

On 2020-06-24 10:19, Martin McCormick wrote:

I wrote a shell script that unzips documents and I originally
wrote it such that it gets document #1, unzips it then gets
document #2, etc and it does that just fine so I wondered if I
could make it run faster by starting several processes at once,
each one unzipping a file.  It's certainly still running and will
eventually finish but I created a monster because it starts as
many processes as there are items to unzip.

#!/bin/sh
unarchive ()  {
  unzip $1
return 0
}
MEDIADIR=`pwd`
mountpoint /mags >/dev/null  ||mount /mags
mountpoint /mags >/dev/null || exit 1
cd /mags
#rm -r -f *
  for MEDIAFILE in `ls $MEDIADIR/*`; do
dirname=`basename $MEDIAFILE`
mkdir $dirname
cd $dirname
unarchive $MEDIAFILE &
cd ../
done
wait
cd ~
umount /mags
exit 0

If there are 3 zipped files, it's probably going to be ok
and start 3 unzip processes.  This directory had 13 zip files and
the first 2 or 3 roared to life and then things slowed down as
they all tried to run.

I expected this and I've been doing unix shell scripts
for literally 31 years this Summer so it is no mystery as each
new job spawns a whole new set of processes to unzip the file it
is working on while all the others are still grinding on.

Miscreants have been known to deliberately create
loops that keep starting processes until the system crashes.

Fortunately, this is one of my systems but this made me
wonder before I reinvent the wheel if there is a way to make a
shell script throttle itself based on current load so it keeps
slurping resources until the next iteration starts too many and
things start to bog down.  When some of the earlier or shorter
processes finish, the loop can restart and start some more unzips
until all are done.

Right now, uptime looks like:

  11:48:07 up 26 days, 23:10,  7 users,  load average: 16.15, 15.60, 10.65

That's pretty loaded so ideally, one could start the
looping script and it would fire up processes until things got
really busy and then not allow any more new procs to start until
some have stopped so cron and other system utilities don't stop
running which is what happens when systems get too busy.

Thanks for any constructive suggestions.

Martin McCormick   WB5AGZ


GNU Parallel looks like a possibility:

https://packages.debian.org/stretch/parallel

https://www.gnu.org/software/parallel/


David

Re: Looping Shell Scripts and System Load

[Kamil Jońca]

Greg Wooledge  writes:

> On Wed, Jun 24, 2020 at 08:23:18PM +0200, Roger Price wrote:
>> On Wed, 24 Jun 2020, Greg Wooledge wrote:
>> 
>> > > MEDIADIR=`pwd`
>> > 
>> > Don't use all caps variable names.
>> 
>> Without getting into syntax-religious wars, what is the reasoning behind
>> this recommendation?  Roger
>
> All-caps names are reserved for environment variables (HOME, PATH),
> and internal shell variables (IFS, PWD, HISTFILE).
Is it described somewhere in docs?
>
> Avoiding all-caps names allows you to avoid collisions with a variable
> name that might be used for something else.  Most of the time.  This
Well, I think that reasonable prefix ("KJ_" :) ) prevent this :)

KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Re: Jupyter

[l0f4r0]

Bonjour,

24 juin 2020 à 13:25 de nicolas.franc...@free.fr:

> Salut.
>
> J'ai installé sur mon ordinateur Jupyter (jupyter, jupyter-client,
> jupyter-console, jupyter-core, jupyter-notebook, jupyter-qtconsole,
> ipython), et je voudrais que le service soit lancé automatiquement au
> démarrage du système.
>
> Sur la page https://wiki.debian.org/Jupyter, il est dit qu'on peut
> faire cela avec systemd :
> systemctl --user enable jupyter-notebook.service
> systemctl --user start jupyter-notebook.service
>
> Mais quand je tape la première ligne (ou la deuxième), j'obtiens ceci :
>
> nico@Gaston:~$ sudo systemctl enable jupyter-notebook.service
> Failed to enable unit: Unit file jupyter-notebook.service does not
> exist.
>
> Pourtant, j'ai ce qu'il faut, il me semble :
> nico@Gaston:~$ locate jupyter-notebook.service
> /usr/lib/systemd/user/jupyter-notebook.service
>
> Je ne suis pas très à l'aise avec systemd. Faut-il que je copie ce
> script à un endroit où systemd peut le trouver ?
>
> D'avance merci pour toute explication :-)
>
Probablement parce que tu as tapé les commandes en tant que 
super-administrateur via sudo et que tu n'as pas utilisé le switch --user ?
La preuve, ton service est dans /usr/lib/systemd/user/

NB : je mets en Cc la ML debian-user-french

Bien cordialement,
l0f4r0

Re: Looping Shell Scripts and System Load

[Greg Wooledge]

On Wed, Jun 24, 2020 at 08:23:18PM +0200, Roger Price wrote:
> On Wed, 24 Jun 2020, Greg Wooledge wrote:
> 
> > > MEDIADIR=`pwd`
> > 
> > Don't use all caps variable names.
> 
> Without getting into syntax-religious wars, what is the reasoning behind
> this recommendation?  Roger

All-caps names are reserved for environment variables (HOME, PATH),
and internal shell variables (IFS, PWD, HISTFILE).

Avoiding all-caps names allows you to avoid collisions with a variable
name that might be used for something else.  Most of the time.  This
being the Unix shell, there are *always* stupid exceptions (http_proxy
and friends on the environment side, and auto_resume and histchars in
bash).

Re: Looping Shell Scripts and System Load

[Roger Price]

On Wed, 24 Jun 2020, Greg Wooledge wrote:


MEDIADIR=`pwd`


Don't use all caps variable names.


Without getting into syntax-religious wars, what is the reasoning behind this 
recommendation?  Roger

Re: Looping Shell Scripts and System Load

[D. R. Evans]

Martin McCormick wrote on 6/24/20 11:19 AM:

> 
>   Right now, uptime looks like:
> 
>  11:48:07 up 26 days, 23:10,  7 users,  load average: 16.15, 15.60, 10.65
> 
>   That's pretty loaded so ideally, one could start the
> looping script and it would fire up processes until things got
> really busy and then not allow any more new procs to start until
> some have stopped so cron and other system utilities don't stop
> running which is what happens when systems get too busy.
> 
>   Thanks for any constructive suggestions.
> 

My general approach is to use sem to create N-1 parallel jobs, where N is the
number of CPUs on the machine.

Not /exactly/ what you're asking for, but something along those lines would
probably help the situation. At least, it works for me :-)

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

RE: [External] Re: No Dual Monitors on AMD Ryzen 7 Pro + Radeon Graphics

[Curtis Tucker1]

Ok.  Thanks., Dan   I now see that the AMDGPU module was loaded without the 
driver.

C

-Original Message-
From: Dan Ritter  
Sent: Wednesday, June 24, 2020 1:40 PM
To: Curtis Tucker1 
Cc: Greg Wooledge ; debian-user@lists.debian.org
Subject: Re: [External] Re: No Dual Monitors on AMD Ryzen 7 Pro + Radeon 
Graphics

Curtis Tucker1 wrote: 
> No output in "~/.local", but I'll keep that in mind for future reference.  I 
> am starting to see that directory used more often, eg, fonts.
> 
> Looking at the log in "/var/log", is loads the Radeon module, but then 
> unloads it because it cannot find the right chipset on the board.  The same 
> for the fallback "fbdev/fbdevhw" because it could not find a framebuffer.  
> Finally, it settles on "int10", makes a call into BIOS to initialize the GPU 
> display as VESA with extensions VBE.  Next it starts to configure other 
> associated devices/components, ie, events, kb, touch screen, camera, etc., & 
> hands over to udev control of HDMI/DP & HD audio/digital because it couldn't 
> find any drivers.
> 
> BTW:  I posted this question before I discovered that there was no xorg.conf.
> 

OK. The driver you actually want is "amdgpu", not "radeon" and definitely not 
VESA.

Set that in xorg.conf and you should have full access to all your screens.

-dsr-

Re: Looping Shell Scripts and System Load

[Greg Wooledge]

On Wed, Jun 24, 2020 at 01:24:23PM -0400, Roberto C. Sánchez wrote:
> I recommend you look at the parallel package.  It is specifically geared
> toward parallelization of constructed shell command lines.  Think
> something along the lines of "find  -exec " but with the ability
> to parallelize (in a way that considers the available CPU cores on your
> system).

In all honesty, many of us have *tried* to find a use for GNU parallel,
but it really seems to be a hammer looking for a nail.  The aggressive
self-promotion, the huge blob of nagging that it does... all of that, and
it's not even better than GNU xargs -P for 99% of the jobs that need a
tiny bit of parallelization.

Re: Looping Shell Scripts and System Load

[Greg Wooledge]

On Wed, Jun 24, 2020 at 12:19:30PM -0500, Martin McCormick wrote:
> #!/bin/sh

Why?  Use bash.

> unarchive ()  {
>  unzip $1

Quotes.  

> MEDIADIR=`pwd`

Don't use all caps variable names.

Don't use backticks.  Use $() for command substitution.

Don't use $(pwd) to get the current directory.  It's in the PWD variable
already.

> mountpoint /mags >/dev/null  ||mount /mags
> mountpoint /mags >/dev/null || exit 1
> cd /mags

Check the result of cd.  Exit if it fails.  cd /mags || exit 1

> #rm -r -f *
>  for MEDIAFILE in `ls $MEDIADIR/*`; do

Do not use ls.  

Quotes again.  

What you want is:   for mediafile in "$mediadir"/*; do

> dirname=`basename $MEDIAFILE`
> mkdir $dirname
> cd $dirname

Quotes, quotes, quotes.  

Always check the result of a cd.  cd "$dirname" || exit 1

> unarchive $MEDIAFILE &

Quotes!  

>   If there are 3 zipped files, it's probably going to be ok
> and start 3 unzip processes.  This directory had 13 zip files and
> the first 2 or 3 roared to life and then things slowed down as
> they all tried to run.

 has some examples
for writing "run n jobs at a time".  We found some newer ways as well,
and those haven't all made it to the wiki yet.

One of the better ones is:

13:40 =greybot> Run N processes in parallel (bash 4.3): i=0 n=5; for elem in 
"${array[@]}"; do if (( i++ >= n )); then wait -n; fi; my_job 
"$elem" & done; wait

In your script, that would be something like:

#!/bin/bash
# Requires bash 4.3 or higher.

# cd and mount and stuff

i=0 n=3
for f; do
  if ((i++ >= n)); then wait -n; fi
  unarchive "$f" &
done
wait


If you have to target older versions of bash, see the ProcessManagement
page on the wiki for alternatives.

Re: [External] Re: No Dual Monitors on AMD Ryzen 7 Pro + Radeon Graphics

[Dan Ritter]

Curtis Tucker1 wrote: 
> No output in "~/.local", but I'll keep that in mind for future reference.  I 
> am starting to see that directory used more often, eg, fonts.
> 
> Looking at the log in "/var/log", is loads the Radeon module, but then 
> unloads it because it cannot find the right chipset on the board.  The same 
> for the fallback "fbdev/fbdevhw" because it could not find a framebuffer.  
> Finally, it settles on "int10", makes a call into BIOS to initialize the GPU 
> display as VESA with extensions VBE.  Next it starts to configure other 
> associated devices/components, ie, events, kb, touch screen, camera, etc., & 
> hands over to udev control of HDMI/DP & HD audio/digital because it couldn't 
> find any drivers.
> 
> BTW:  I posted this question before I discovered that there was no xorg.conf.
> 

OK. The driver you actually want is "amdgpu", not "radeon" and
definitely not VESA.

Set that in xorg.conf and you should have full access to all
your screens.

-dsr-

Re: Looping Shell Scripts and System Load

[Roberto C . Sánchez]

On Wed, Jun 24, 2020 at 12:19:30PM -0500, Martin McCormick wrote:
> I wrote a shell script that unzips documents and I originally
> wrote it such that it gets document #1, unzips it then gets
> document #2, etc and it does that just fine so I wondered if I
> could make it run faster by starting several processes at once,
> each one unzipping a file.  It's certainly still running and will
> eventually finish but I created a monster because it starts as
> many processes as there are items to unzip.
> 

I recommend you look at the parallel package.  It is specifically geared
toward parallelization of constructed shell command lines.  Think
something along the lines of "find  -exec " but with the ability
to parallelize (in a way that considers the available CPU cores on your
system).

Regards,

-Roberto

-- 
Roberto C. Sánchez

Looping Shell Scripts and System Load

[Martin McCormick]

I wrote a shell script that unzips documents and I originally
wrote it such that it gets document #1, unzips it then gets
document #2, etc and it does that just fine so I wondered if I
could make it run faster by starting several processes at once,
each one unzipping a file.  It's certainly still running and will
eventually finish but I created a monster because it starts as
many processes as there are items to unzip.

#!/bin/sh
unarchive ()  {
 unzip $1
return 0
}
MEDIADIR=`pwd`
mountpoint /mags >/dev/null  ||mount /mags
mountpoint /mags >/dev/null || exit 1
cd /mags
#rm -r -f *
 for MEDIAFILE in `ls $MEDIADIR/*`; do
dirname=`basename $MEDIAFILE`
mkdir $dirname
cd $dirname
unarchive $MEDIAFILE &
cd ../
done
wait
cd ~
umount /mags
exit 0

If there are 3 zipped files, it's probably going to be ok
and start 3 unzip processes.  This directory had 13 zip files and
the first 2 or 3 roared to life and then things slowed down as
they all tried to run.

I expected this and I've been doing unix shell scripts
for literally 31 years this Summer so it is no mystery as each
new job spawns a whole new set of processes to unzip the file it
is working on while all the others are still grinding on.

Miscreants have been known to deliberately create
loops that keep starting processes until the system crashes.

Fortunately, this is one of my systems but this made me
wonder before I reinvent the wheel if there is a way to make a
shell script throttle itself based on current load so it keeps
slurping resources until the next iteration starts too many and
things start to bog down.  When some of the earlier or shorter
processes finish, the loop can restart and start some more unzips
until all are done.

Right now, uptime looks like:

 11:48:07 up 26 days, 23:10,  7 users,  load average: 16.15, 15.60, 10.65

That's pretty loaded so ideally, one could start the
looping script and it would fire up processes until things got
really busy and then not allow any more new procs to start until
some have stopped so cron and other system utilities don't stop
running which is what happens when systems get too busy.

Thanks for any constructive suggestions.

Martin McCormick   WB5AGZ

RE: [External] Re: No Dual Monitors on AMD Ryzen 7 Pro + Radeon Graphics

[Curtis Tucker1]

No output in "~/.local", but I'll keep that in mind for future reference.  I am 
starting to see that directory used more often, eg, fonts.

Looking at the log in "/var/log", is loads the Radeon module, but then unloads 
it because it cannot find the right chipset on the board.  The same for the 
fallback "fbdev/fbdevhw" because it could not find a framebuffer.  Finally, it 
settles on "int10", makes a call into BIOS to initialize the GPU display as 
VESA with extensions VBE.  Next it starts to configure other associated 
devices/components, ie, events, kb, touch screen, camera, etc., & hands over to 
udev control of HDMI/DP & HD audio/digital because it couldn't find any drivers.

BTW:  I posted this question before I discovered that there was no xorg.conf.

Thanks,
C

-Original Message-
From: Greg Wooledge  
Sent: Wednesday, June 24, 2020 12:39 PM
To: debian-user@lists.debian.org
Subject: Re: [External] Re: No Dual Monitors on AMD Ryzen 7 Pro + Radeon 
Graphics

On Wed, Jun 24, 2020 at 12:16:27PM -0400, Dan Ritter wrote:
> Check for a very recent file called: 
> /var/log/Xorg.0.log

Starting in Debian 9, the Xorg log file can be in two different places.
Either there, or ~/.local/share/xorg/Xorg.0.log .

Be sure to look for both, and use the one that's actually current.

Re: Be careful when editing /etc/fstab

[Anders Andersson]

I agree, but documentation doesn't seem to have high priority in
debian, it's a cultural issue. For example, in OpenBSD a developer
never changes anything without also making sure that the documentation
everywhere is up to date. It's become part of the mindset.

Yesterday I tried to learn about how LXC is integrated in
debian, at least the debian wiki article warned me that the page might
be outdated if I tried it on the brand new "stretch" distro! And "man
crypttab" explicitly says that it doesn't document what's actually
used, to read about that one has to go online.


On Wed, Jun 24, 2020 at 3:51 PM David Wright  wrote:
>
> On Wed 24 Jun 2020 at 09:32:53 (+0200), Anders Andersson wrote:
> > On Wed, Jun 24, 2020 at 1:17 AM David  wrote:
> > > I just noticed a new bug report [1]:
> > > """
> > > Dear Installer Team,
> > >
> > > Please consider adding words informing users they should run
> > > "systemctl daemon-reload" after changing /etc/fstab.
> > >
> > > With stale mount units from an older /etc/fstab, users might observe
> > > "interesting surprises", f.e. systemd might umount newly mounted
> > > filesystems, if the in-memory mount units conflict with info in
> > > /etc/fstab.
> > > ""
> > >
> > > Apparently this is old news, I found a systemd bug report [2]
> > > from 2017. It links to documentation [3] that says:
> > > """
> > > On SysV systems changes to init scripts or any other files that define
> > > the boot process (such as /etc/fstab) usually had an immediate effect
> > > on everything started later. This is different on systemd-based
> > > systems where init script information and other boot-time
> > > configuration files are only reread when "systemctl daemon-reload" is
> > > issued. (Note that some commands, notably "systemctl
> > > enable"/"systemctl disable" do this implicitly however.) This is by
> > > design, and a safety feature, since it ensures that half-completed
> > > changes are not read at the wrong time.
> > > """
> > >
> > > Anyway I was not aware of this so I thought to share it here.
> > > Further information is welcome, if you have any.
> > >
> > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963573
> > > [2] https://github.com/systemd/systemd/issues/7291
> > > [3] https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
> >
> >
> > Yep, I always do a "systemctl daemon-reload" directly after editing
> > these files and looking in /var/run/systemd/generator/ to see if it
> > did everything right. The problem is how a user should know which
> > files are affected and not.
> >
> > I'm personally mostly affected by /etc/fstab and /etc/crypttab, but I
> > assume there are more auto-generated files.
>
> AFAICT neither of their man pages knows of the existence of systemctl,
> and man fstab seems completely unaware of the behaviour of systemd.
> The latter hardly seems surprising, as it was last updated when the
> stable version was wheezy.
>
> These factors might be one reason why some users write that systemd
> is poorly documented, or that they can't find the documentation for it.
> Yes, there's copious documentation of systemd itself, but some of the
> subsystems profoundly affected by it seem unaware of that in their
> own documentation.
>
> > A while back I started writing custom systemd unit files for mounts
> > and such, but now I've reverted back to using /etc/fstab directly for
> > most things and then possibly just dropping in custom extra options in
> > /etc/systemd/system/ if necessary. I did that because all of my
> > systems run on multiple fully encrypted raid disks, and it used to be
> > a mess trying systemd to understand that it has to decrypt everything
> > first and then try to assemble it and mount it. These days it's much
> > more clever.
>
> Cheers,
> David.
>

Re: [External] Re: No Dual Monitors on AMD Ryzen 7 Pro + Radeon Graphics

[Greg Wooledge]

On Wed, Jun 24, 2020 at 12:16:27PM -0400, Dan Ritter wrote:
> Check for a very recent file called: 
> /var/log/Xorg.0.log

Starting in Debian 9, the Xorg log file can be in two different places.
Either there, or ~/.local/share/xorg/Xorg.0.log .

Be sure to look for both, and use the one that's actually current.

Re: Pacote LSB

[Christian Erick]

Boa tarde!

Ignorei os drivers do fabricante e segui a orientação do

https://wiki.debian.org/SystemPrinting#Software_Installation


Impressora funcionando perfeitamente

Agradeço a ajuda de todos

Att
Christian Costa


Em 24/06/2020 12:41, Leandro Guimarães Faria Corcete DUTRA escreveu:

Le mardi 23 juin 2020 à 15:54 -0300, Christian Erick a écrit :

é uma Epson L3110

Razoavelmente recente.  Deve funcionar como falamos.




--

Re: [External] Re: No Dual Monitors on AMD Ryzen 7 Pro + Radeon Graphics

[Dan Ritter]

Curtis Tucker1 wrote: 
> Hi Dan,
> 
> "xrandr | grep connect" output:
> 
> xrandr: Failed to get size of gamma for output default
> default connected  primary 1920x1080+0+0 0mm  x  0mm

That suggests that your X server is not actually using the
amdgpu driver.

Here's one of mine, using amdgpu:

DisplayPort-0 connected 3840x2160+0+0 (normal left inverted
right x axis y axis) 953mm x 543mm
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)


Check for a very recent file called: 
/var/log/Xorg.0.log

and start reading at the top. This should describe what happened
in your most recent X session, and include items looking for
your video card and eventually settling on a driver that fits it.

If it isn't amdgpu, we'll need to convince your X server to use
it.

-dsr-

RE: [External] Re: No Dual Monitors on AMD Ryzen 7 Pro + Radeon Graphics

[Curtis Tucker1]

Hi Dan,

"xrandr | grep connect" output:

xrandr: Failed to get size of gamma for output default
default connected  primary 1920x1080+0+0 0mm  x  0mm

Thanks,
C

-Original Message-
From: Dan Ritter  
Sent: Wednesday, June 24, 2020 10:22 AM
To: Curtis Tucker1 
Cc: debian-user@lists.debian.org
Subject: [External] Re: No Dual Monitors on AMD Ryzen 7 Pro + Radeon Graphics

Curtis Tucker1 wrote: 
> Hi,
> 
> After installing firmware-bullseye + xserver-xorg-video-amdgpu + 
> firmware-amd-graphics on an AMD Ryzen 7 Pro + Radeon Graphics platform, there 
> is no dual monitor capability via HDMI.
> 
> I thought the amdgpu from xorg would take care of things like xinerama or 
> twinview.

At this point, you should be able to do this with xrandr, or any of the 
frontend substitutes.

What does 

xrandr |grep connect  

give you? From an xterm or similar, please.

-dsr-

Re: Pacote LSB

[Leandro Guimarães Faria Corcete DUTRA]

Le mardi 23 juin 2020 à 15:54 -0300, Christian Erick a écrit :
> é uma Epson L3110

Razoavelmente recente.  Deve funcionar como falamos.


-- 
/¯\
\ / +55 (61) 3546 7191 xmpp:leand...@jabber.org
 X  +55 (61) 99302 2691
/ \ BRAZIL GMT−3  https://useplaintext.email/#why-plaintext

Re: one liner, how do you know which match happened ...

[Albretch Mueller]

On 6/24/20, Greg Wooledge  wrote:
> If you want to match N files against M strings (or regexes) and collate
> them into groups according to which string is first seen in each file,
> use a real programming language.

  Oh, well! I was just too hopeful.

> Stop trying to use inappropriate tools.  You're just making your life
> harder.

  Thank you

 lbrtchx

Re: No Dual Monitors on AMD Ryzen 7 Pro + Radeon Graphics

[Dan Ritter]

Curtis Tucker1 wrote: 
> Hi,
> 
> After installing firmware-bullseye + xserver-xorg-video-amdgpu + 
> firmware-amd-graphics on an AMD Ryzen 7 Pro + Radeon Graphics platform, there 
> is no dual monitor capability via HDMI.
> 
> I thought the amdgpu from xorg would take care of things like xinerama or 
> twinview.

At this point, you should be able to do this with xrandr, or any
of the frontend substitutes.

What does 

xrandr |grep connect  

give you? From an xterm or similar, please.

-dsr-

Re: [?]Identify BT Card, enable BT to pair with BT enabled Loudspeaker

[deloptes]

Susmita/Rajib wrote:

> I shall have to arrange for means to improve sound quality of the
> played sound.
> 
> Any suggestion in this regard would be welcome.

I've read some advises to increase latency tolerance or similar in pulse.
may be try searching for advises on the internet in this regards.

Re: Be careful when editing /etc/fstab

[David Wright]

On Wed 24 Jun 2020 at 09:32:53 (+0200), Anders Andersson wrote:
> On Wed, Jun 24, 2020 at 1:17 AM David  wrote:
> > I just noticed a new bug report [1]:
> > """
> > Dear Installer Team,
> >
> > Please consider adding words informing users they should run
> > "systemctl daemon-reload" after changing /etc/fstab.
> >
> > With stale mount units from an older /etc/fstab, users might observe
> > "interesting surprises", f.e. systemd might umount newly mounted
> > filesystems, if the in-memory mount units conflict with info in
> > /etc/fstab.
> > ""
> >
> > Apparently this is old news, I found a systemd bug report [2]
> > from 2017. It links to documentation [3] that says:
> > """
> > On SysV systems changes to init scripts or any other files that define
> > the boot process (such as /etc/fstab) usually had an immediate effect
> > on everything started later. This is different on systemd-based
> > systems where init script information and other boot-time
> > configuration files are only reread when "systemctl daemon-reload" is
> > issued. (Note that some commands, notably "systemctl
> > enable"/"systemctl disable" do this implicitly however.) This is by
> > design, and a safety feature, since it ensures that half-completed
> > changes are not read at the wrong time.
> > """
> >
> > Anyway I was not aware of this so I thought to share it here.
> > Further information is welcome, if you have any.
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963573
> > [2] https://github.com/systemd/systemd/issues/7291
> > [3] https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
> 
> 
> Yep, I always do a "systemctl daemon-reload" directly after editing
> these files and looking in /var/run/systemd/generator/ to see if it
> did everything right. The problem is how a user should know which
> files are affected and not.
> 
> I'm personally mostly affected by /etc/fstab and /etc/crypttab, but I
> assume there are more auto-generated files.

AFAICT neither of their man pages knows of the existence of systemctl,
and man fstab seems completely unaware of the behaviour of systemd.
The latter hardly seems surprising, as it was last updated when the
stable version was wheezy.

These factors might be one reason why some users write that systemd
is poorly documented, or that they can't find the documentation for it.
Yes, there's copious documentation of systemd itself, but some of the
subsystems profoundly affected by it seem unaware of that in their
own documentation.

> A while back I started writing custom systemd unit files for mounts
> and such, but now I've reverted back to using /etc/fstab directly for
> most things and then possibly just dropping in custom extra options in
> /etc/systemd/system/ if necessary. I did that because all of my
> systems run on multiple fully encrypted raid disks, and it used to be
> a mess trying systemd to understand that it has to decrypt everything
> first and then try to assemble it and mount it. These days it's much
> more clever.

Cheers,
David.

Re: Radeon graphics work with 4.19.0-8 but not 4.19.0-9

[Scott Lair]

On Tue, 23 Jun 2020 20:07:29 -0400
Scott Lair  wrote:

> I installed a Radeon WX 3100 a few days ago on my buster system. It
> failed to bring up the X server. I installed the proprietary drivers
> from AMD's site, but still no dice.  Just for fun I tried to boot the
> previous kernel 4.19.0-8 and the system worked fine.
> 
> I have install the amd-graphics-firmware from buster backports
> version 20190717-2.  Also installed xserver-xorg-video-amdgpu version
> 18.1.99+git20190207-1. 
> 
> I have reconfigured the kernel and ran update-initramfs.  Also purged
> the amdgpu xorg driver and reinstalled.
> 
> Any ideas on how to get the system to run X with the 4.19.0-9 kernel.
> 
> 
> log snippet from xorg log on 4.19.0-9  - failed
> [60.114] (II) systemd-logind: logind integration requires
> -keeptty and -keeptty was not provided, disabling logind integration
> [60.116] (--) PCI:*(1@0:0:0) 1002:6985:103c:0b0e rev 0, Mem @
> 0xe000/268435456, 0xf000/2097152, 0xf7e0/262144, I/O @
> 0xe000/256, BIOS @ 0x/131072 [60.116] (II)
> LoadModule: "glx" [60.116] (II)
> Loading /usr/lib/xorg/modules/extensions/libglx.so [60.116] (II)
> Module glx: vendor="X.Org Foundation" [60.116]compiled for
> 1.20.4, module version = 1.0.0 [60.116]ABI class: X.Org
> Server Extension, version 10.0 [60.116] (==) Matched ati as
> autoconfigured driver 0
> 
> drm is not loaded and amdgpu is not matched
> 
> log snippet from xorg log on 4.19.0-8 - worked OK
> [54.191] (II) systemd-logind: logind integration requires
> -keeptty and -keeptty was not provided, disabling logind integration
> [54.191] (II) xfree86: Adding drm device (/dev/dri/card0)
> [54.203] (--) PCI:*(1@0:0:0) 1002:6985:103c:0b0e rev 0, Mem @
> 0xe000/268435456, 0xf000/2097152, 0xf7e0/262144, I/O @
> 0xe000/256, BIOS @ 0x/131072 [54.204] (II)
> LoadModule: "glx" [54.240] (II)
> Loading /usr/lib/xorg/modules/extensions/libglx.so [54.500] (II)
> Module glx: vendor="X.Org Foundation" [54.500]compiled for
> 1.20.4, module version = 1.0.0 [54.500]ABI class: X.Org
> Server Extension, version 10.0 [54.500] (II) Applying OutputClass
> "AMDgpu" to /dev/dri/card0 [54.500]loading driver: amdgpu
> [54.500] (==) Matched amdgpu as autoconfigured driver 0
> [54.500] (==) Matched ati as autoconfigured driver 1
> 
> 
> thanks
> 
> 
> 

Turned out to be that the amdgpu drivers were missing in the newer
kernel. A reinstall of the kernel got it back and video is back to
normal.

Re: Jupyter

[tomas]

On Wed, Jun 24, 2020 at 01:25:51PM +0200, Nicolas FRANCOIS wrote:
> Salut.
> 
> J'ai installé sur mon ordinateur Jupyter (jupyter, jupyter-client,
> jupyter-console, jupyter-core, jupyter-notebook, jupyter-qtconsole,
> ipython), et je voudrais que le service soit lancé automatiquement au
> démarrage du système.

Comment avez-vous installé jupyter? Avec un paquet Debian?

> Sur la page https://wiki.debian.org/Jupyter, il est dit qu'on peut
> faire cela avec systemd :
> systemctl --user enable jupyter-notebook.service
> systemctl --user start jupyter-notebook.service
> 
> Mais quand je tape la première ligne (ou la deuxième), j'obtiens ceci :
> 
> nico@Gaston:~$ sudo systemctl enable jupyter-notebook.service
> Failed to enable unit: Unit file jupyter-notebook.service does not
> exist.
> 
> Pourtant, j'ai ce qu'il faut, il me semble :
> nico@Gaston:~$ locate jupyter-notebook.service
> /usr/lib/systemd/user/jupyter-notebook.service
> 
> Je ne suis pas très à l'aise avec systemd.

Moi non plus, désolé. En plus, mon Français est catastrophique.

Vous trouvez une liste francophone ici:

  https://lists.debian.org/debian-user-french/
  https://wiki.debian.org/fr/FrenchLists

salut
-- tomás


signature.asc
Description: Digital signature

Re: paquete de configuracion

[JAP Debian]

El 24/6/20 a las 04:36, Antonio Trujillo Carmona escribió:

Hola

Quería crear un paquete de configuración para la empresa.

En concreto, quiero crear un paquete que instale el ocsinventory pero
que contenga la configuración de la empresa de forma que no pregunte
nada, seria algo como:

apt install miocs ...

se instalan por dependencias ocsinventory-agents ...

Me podéis dar norte de como aprender a hacerlo.

Gracias





https://wiki.debian.org/HowToPackageForDebian
https://www.debian.org/doc/manuals/maint-guide/build.es.html
https://linuxconfig.org/easy-way-to-create-a-debian-package-and-local-package-repository
https://www.debian.org/doc/manuals/maint-guide/build.es.html
https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf

JAP

Re: Unable to verify 64-bit live ISO signature

[davidson]

On Wed, 24 Jun 2020 davidson wrote:

One clarification...

[dd]

Here are three mutually exclusive cases, of what a system may tell
you, depending on how your reality conforms to conditions (1) and (2)
above.


...regarding the third case:


SIGNING KEY UNKNOWN, bailing out: When (2) is NO

gpg: Signature made Wed 24 Jun 2020 06:58:06 AM EDT
gpg:using RSA key 2E3F09D22FFDC4ABF32DF441EB18A1C0111F5F49
gpg: Can't check signature: No public key

All is not well. SUMFILE was not signed by a debian role key (or, at

   ^^^

least, not by one in the keyring you specified).


I should restate that last bit more clearly:

 "SUMFILE.sign does not contain a signature from a debian role key"
  


For all you know, SUMFILE.sign could contain the Hamburglar's
signature! Or Marilyn Monroe's!

And it remains unknown in this case whether (1) is YES or NO. In other
words, we don't know whether SUMFILE.sign contains *anyone*'s
signature for SUMFILE.


If I have said anything incorrect or misleading above, I hope somebody
will correct me.


--
Firstly, you must always implicitly obey orders, without attempting to
form any opinion of your own respecting their propriety. Secondly, you
must consider every man your enemy who speaks ill of your king; and
thirdly, you must hate a Frenchman, as you do the devil. --H. Nelson

Visitors List of Southern California 2020 Linux Expo

[Marc Daniels]

Hi,

I am following up to check if you are interested in the Pre-registered 
attendees List.

Event Name: Southern California 2020 Linux Expo
Date: Mar 05 - Mar 08, 2020
Place: Pasadena Convention Center, Los Angeles, California

Attendees Counts: 4,327

Let me know your interest to get back with pricing & more info.

Thank you and I look forward to hearing from you.

Regards,
Marc Daniels
Sr. Marketing Analyst

Re: one liner, how do you know which match happened ...

[Greg Wooledge]

On Wed, Jun 24, 2020 at 12:59:03PM +0200, to...@tuxteam.de wrote:
> On Wed, Jun 24, 2020 at 12:33:19PM +0200, Albretch Mueller wrote:
> > > "grep -l" will stop at the first hit, so even if you could ask
> > > grep which one of the alternatives it found, it'll miss Hegel
> > > in a file where Kant figures first. Is that what you want?
> > 
> >  Yes, I am fine with that. I include the matches in the Array in a way
> > that the first one is the most important to me anyway, but I need to
> > know which one, which I think should be someone possible, since grep
> > must go through the array using some index, no?

Grep doesn't know anything about "arrays".  Grep is a separate utility,
which has its own specification (from POSIX, which in turn derives from
historical implementations), and GNU grep has its own specific
implementation and extensions.

Grep receives its input from the command-line arguments, and standard
input if no filename arguments are given.  That's all.  It doesn't know
anything else about its parent process's variables, or your intentions.

> OK, if you just want the first hit, there is "--max-count" (aka "-m"),
> which you can use with the combined regular expression. This (given
> the value 1) will spit out the first matching line, which you can
> then post-process to extract the exact match.
> 
> Post-processing is left as an exercise to the reader :-)
> 
> That should be about as fast as "grep -l" can get, take or give.

One small problem here:

   -l, --files-with-matches
  Suppress normal output; instead print the  name  of  each  input
  file  from  which  output would normally have been printed.  The
  scanning will stop on the first match.

You don't *see* the matching line when using the -l option.

Once again, bash and grep are really NOT good choices for this goal,
insofar as I've been able to deduce what the goal is.

If you want to match N files against M strings (or regexes) and collate
them into groups according to which string is first seen in each file,
use a real programming language.  Open each file, then read line by line,
and match each line against each of your input strings, until a match
is found, or you hit the end of the file.  Store results accordingly.

Stop trying to use inappropriate tools.  You're just making your life
harder.

Re: Unable to verify 64-bit live ISO signature

[davidson]

On Wed, 24 Jun 2020 sebarosa...@protonmail.com wrote:


Hi! I have been trying to veify the debian live iso signature, but I
can't find the command to import the debian gpg keys for the
sha256sum.sign file. What is the command?


OP appears satisfied with answers already received, all of which
appear to involve obtaining keys from a keyserver.

I would supplement those answers as follows:

On a debian system, the debian project's optical media signing keys
appear to live in the file

 /usr/share/keyrings/debian-role-keys.gpg

which is supplied by package "debian-keyring".

So on debian, if you have

 A. debian-keyring installed (and gpg as well),

 B. a checksum file SUMFILE, and

 C. a file SUMFILE.sign, allegedly containing a signature for the
checksums in SUMFILE

then you can find out

  1. whether SUMFILE.sign is indeed a signature for SUMFILE (meaning
 you may remove the qualifier "allegedly" from (C) above), and

  2. whether that signature was made by somebody in control of a key
 that the debian project trusts to sign its releases,

by examining the output of this command:

 $ gpg --verify --keyring /usr/share/keyrings/debian-role-keys.gpg SUMFILE.sign 
SUMFILE

(Of course, substitute "SHA256SUMS" or "SHA512SUMS" or whatever, as
appropriate, for "SUMFILE".)

Here are three mutually exclusive cases, of what a system may tell
you, depending on how your reality conforms to conditions (1) and (2)
above.


SUMFILE signed, and by debian role key: When both (1) and (2) are YES

 gpg: Signature made Sat 09 May 2020 08:17:30 PM EDT
 gpg:using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
 gpg: Good signature from "Debian CD signing key " 
[marginal]
 gpg: WARNING: This key is not certified with sufficiently trusted signatures!
 gpg:  It is not certain that the signature belongs to the owner.
 Primary key fingerprint: DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B

You were told all is fine, so far as the system can tell.


SUMFILE not signed: When (1) is NO but (2) is still YES

 gpg: Signature made Sat 09 May 2020 08:17:30 PM EDT
 gpg:using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
 gpg: BAD signature from "Debian CD signing key " 
[marginal]

That is your system telling you SUMFILE.sign is *not* actually a
signature for SUMFILE. It is possible that SUMFILE has been tampered
with.


SIGNING KEY UNKNOWN, bailing out: When (2) is NO

 gpg: Signature made Wed 24 Jun 2020 06:58:06 AM EDT
 gpg:using RSA key 2E3F09D22FFDC4ABF32DF441EB18A1C0111F5F49
 gpg: Can't check signature: No public key

All is not well. SUMFILE was not signed by a debian role key (or, at
least, not by one in the keyring you specified).

For all you know, SUMFILE.sign could contain the Hamburglar's
signature! Or Marilyn Monroe's!

And it remains unknown in this case whether (1) is YES or NO. In other
words, we don't know whether SUMFILE.sign contains *anyone*'s
signature for SUMFILE.


If I have said anything incorrect or misleading above, I hope somebody
will correct me.

--
Firstly, you must always implicitly obey orders, without attempting to
form any opinion of your own respecting their propriety. Secondly, you
must consider every man your enemy who speaks ill of your king; and
thirdly, you must hate a Frenchman, as you do the devil. --H. Nelson

Re: Jupyter

[john doe]

On 6/24/2020 1:25 PM, Nicolas FRANCOIS wrote:

Salut.

J'ai installé sur mon ordinateur Jupyter (jupyter, jupyter-client,
jupyter-console, jupyter-core, jupyter-notebook, jupyter-qtconsole,
ipython), et je voudrais que le service soit lancé automatiquement au
démarrage du système.

Sur la page https://wiki.debian.org/Jupyter, il est dit qu'on peut
faire cela avec systemd :
systemctl --user enable jupyter-notebook.service
systemctl --user start jupyter-notebook.service

Mais quand je tape la première ligne (ou la deuxième), j'obtiens ceci :

nico@Gaston:~$ sudo systemctl enable jupyter-notebook.service
Failed to enable unit: Unit file jupyter-notebook.service does not
exist.

Pourtant, j'ai ce qu'il faut, il me semble :
nico@Gaston:~$ locate jupyter-notebook.service
/usr/lib/systemd/user/jupyter-notebook.service

Je ne suis pas très à l'aise avec systemd. Faut-il que je copie ce
script à un endroit où systemd peut le trouver ?



This is an English mailing list, you might be better off in a French one! :)

--
John Doe

Jupyter

[Nicolas FRANCOIS]

Salut.

J'ai installé sur mon ordinateur Jupyter (jupyter, jupyter-client,
jupyter-console, jupyter-core, jupyter-notebook, jupyter-qtconsole,
ipython), et je voudrais que le service soit lancé automatiquement au
démarrage du système.

Sur la page https://wiki.debian.org/Jupyter, il est dit qu'on peut
faire cela avec systemd :
systemctl --user enable jupyter-notebook.service
systemctl --user start jupyter-notebook.service

Mais quand je tape la première ligne (ou la deuxième), j'obtiens ceci :

nico@Gaston:~$ sudo systemctl enable jupyter-notebook.service
Failed to enable unit: Unit file jupyter-notebook.service does not
exist.

Pourtant, j'ai ce qu'il faut, il me semble :
nico@Gaston:~$ locate jupyter-notebook.service
/usr/lib/systemd/user/jupyter-notebook.service

Je ne suis pas très à l'aise avec systemd. Faut-il que je copie ce
script à un endroit où systemd peut le trouver ?

D'avance merci pour toute explication :-)

\bye

-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin


pgpK6IYQ8S7wm.pgp
Description: Signature digitale OpenPGP

Re: one liner, how do you know which match happened ...

[tomas]

On Wed, Jun 24, 2020 at 12:33:19PM +0200, Albretch Mueller wrote:
> > "grep -l" will stop at the first hit, so even if you could ask
> > grep which one of the alternatives it found, it'll miss Hegel
> > in a file where Kant figures first. Is that what you want?
> 
>  Yes, I am fine with that. I include the matches in the Array in a way
> that the first one is the most important to me anyway, but I need to
> know which one, which I think should be someone possible, since grep
> must go through the array using some index, no?

OK, if you just want the first hit, there is "--max-count" (aka "-m"),
which you can use with the combined regular expression. This (given
the value 1) will spit out the first matching line, which you can
then post-process to extract the exact match.

Post-processing is left as an exercise to the reader :-)

That should be about as fast as "grep -l" can get, take or give.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: one liner, how do you know which match happened ...

[Albretch Mueller]

> "grep -l" will stop at the first hit, so even if you could ask
> grep which one of the alternatives it found, it'll miss Hegel
> in a file where Kant figures first. Is that what you want?

 Yes, I am fine with that. I include the matches in the Array in a way
that the first one is the most important to me anyway, but I need to
know which one, which I think should be someone possible, since grep
must go through the array using some index, no?

 lbrtchx

Re: [?]Identify BT Card, enable BT to pair with BT enabled Loudspeaker

[Susmita/Rajib]

Dear  illustrious Team Leaders,

I am returning to inform that the problem has been solved, though the
sound played through my External BT enabled Loudspeakers is
erratically chopped in between.

I shall have to arrange for means to improve sound quality of the
played sound.

Any suggestion in this regard would be welcome.

The Last Mile tweak was outrageously simple:
I just had to rename to file, like it was mentioned by Taron
Saribekyan, BCM43142A0-0a5c-216c.hcd to bcm.hcd, then restarting the
laptop. Now the BT package works as intended, every option activated.

The solution has been posted to the Debian Forums, link:
http://forums.debian.net/viewtopic.php?f=7=145792=718471 , also
informed earlier.

I thank you all, particularly, Dr./Mr. Haskett, Wright, Curt, Follmann
and Joe, for staying with me till the end.

Regards,
Rajib Bandopadhyay
Etc.

Re: Be careful when editing /etc/fstab

[songbird]

Anders Andersson wrote:
...
> A while back I started writing custom systemd unit files for mounts
> and such, but now I've reverted back to using /etc/fstab directly for
> most things and then possibly just dropping in custom extra options in
> /etc/systemd/system/ if necessary. I did that because all of my
> systems run on multiple fully encrypted raid disks, and it used to be
> a mess trying systemd to understand that it has to decrypt everything
> first and then try to assemble it and mount it. These days it's much
> more clever.

  and then there are those of us who keep things simple 
and don't need all this complexity or interference.

  when i edit /etc/fstab i don't expect or want any
changes to happen to file systems until i reboot or 
manually unmount and remount a file system.

  to me having a system interfere in what i'm doing
is annoying and wrong - i consider it a bug.


  songbird

Re: paste.debian.net for screenshots?

[tomas]

On Wed, Jun 24, 2020 at 02:32:45AM +, Andy Smith wrote:

[...]

> I don't really see there is any need to use Debian's pastebin in
> preference to any other anyway [...]

Persistence might be one reason. As time passes, pastebin services
might disappear and the links break.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Unable to verify 64-bit live ISO signature / How to download signatures

[Thomas Schmitt]

Hi,

sorry for carrying the subject line from one thread to the other.
(At least they are closely related ...)


Have a nice day :)

Thomas

Re: Unable to verify 64-bit live ISO signature

[SeBarosanul]

Thank you for the excellent help! I'm happy to join this awesome community!

Re: Unable to verify 64-bit live ISO signature

[Thomas Schmitt]

Hi,

sebarosa...@protonmail.com wrote:
> I am
> trying to download the sha256sums and the sha256sums.sign, but clicking on
> them only seems to open the contents of the file

With my browser i can click on the link with the rightmost mouse button
to get a menu which offers me to "Save Link As".
You could also use copy+paste to bring the displaid file content into
a file on your local disk.

Finally, the command line should help

  wget https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/SHA256SUMS

  wget 
https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/SHA256SUMS.sign



In advance:

If gpg --verify says

  gpg: Good signature from "Debian CD signing key "
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:  There is no indication that the signature belongs to the owner.
  Primary key fingerprint: DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B


then it is ok. But you should then check the "key fingerprint" whether
it is one of those listed at
  https://www.debian.org/CD/verify


Have a nice day :)

Thomas

Re: How to download signatures

[Joe]

On Wed, 24 Jun 2020 08:15:38 +
sebarosa...@protonmail.com wrote:

> Thank you for the very fast response to my first question! Right now,
> I am trying to download the sha256sums and the sha256sums.sign, but
> clicking on them only seems to open the contents of the file, and not
> download it. I am unsure if I am doing the right thing.

You should be able to:

Right click and 'Save link as..' or similar

or

Highlight the text of the file, copy and paste it into a text editor,
then save. It doesn't have to be Emacs, something like Leafpad or
Mousepad will be fine.

-- 
Joe

Re: Unable to verify 64-bit live ISO signature

[john doe]

On 6/24/2020 9:44 AM, Thomas Schmitt wrote:

Hi,

sebarosa...@protonmail.com wrote:

I can't
find the command to import the debian gpg keys for the sha256sum.sign file.


I was told that verification works without knowing the key id by:

   gpg --keyserver keyring.debian.org --verify SHA256SUMS.sign SHA256SUMS



I would rather use the below command to automatically fetch the key:

$ gpg --keyserver-options auto-key-retrieve verify SHA512SUMS.sign
SHA512SUMS

--
John Doe

How to download signatures

[SeBarosanul]

Thank you for the very fast response to my first question! Right now, I am 
trying to download the sha256sums and the sha256sums.sign, but clicking on them 
only seems to open the contents of the file, and not download it. I am unsure 
if I am doing the right thing.

paquete de configuracion

[Antonio Trujillo Carmona]

Hola

Quería crear un paquete de configuración para la empresa.

En concreto, quiero crear un paquete que instale el ocsinventory pero
que contenga la configuración de la empresa de forma que no pregunte
nada, seria algo como:

apt install miocs ...

se instalan por dependencias ocsinventory-agents ...

Me podéis dar norte de como aprender a hacerlo.

Gracias




signature.asc
Description: OpenPGP digital signature

Re: Unable to verify 64-bit live ISO signature

[Thomas Schmitt]

Hi,

sebarosa...@protonmail.com wrote:
> I can't
> find the command to import the debian gpg keys for the sha256sum.sign file.

I was told that verification works without knowing the key id by:

  gpg --keyserver keyring.debian.org --verify SHA256SUMS.sign SHA256SUMS

but never tested it without having the key already fetched.
I normally use a fetched key with one of the key ids from
  https://www.debian.org/CD/verify
E.g.

  gpg --keyserver keyring.debian.org --recv-keys 6294BE9B

and then

  gpg --verify SHA256SUMS.sign SHA256SUMS


Have a nice day :)

Thomas

Re: Be careful when editing /etc/fstab

[Anders Andersson]

On Wed, Jun 24, 2020 at 1:17 AM David  wrote:
>
> Hi,
>
> I just noticed a new bug report [1]:
> """
> Dear Installer Team,
>
> Please consider adding words informing users they should run
> "systemctl daemon-reload" after changing /etc/fstab.
>
> With stale mount units from an older /etc/fstab, users might observe
> "interesting surprises", f.e. systemd might umount newly mounted
> filesystems, if the in-memory mount units conflict with info in
> /etc/fstab.
> ""
>
> Apparently this is old news, I found a systemd bug report [2]
> from 2017. It links to documentation [3] that says:
> """
> On SysV systems changes to init scripts or any other files that define
> the boot process (such as /etc/fstab) usually had an immediate effect
> on everything started later. This is different on systemd-based
> systems where init script information and other boot-time
> configuration files are only reread when "systemctl daemon-reload" is
> issued. (Note that some commands, notably "systemctl
> enable"/"systemctl disable" do this implicitly however.) This is by
> design, and a safety feature, since it ensures that half-completed
> changes are not read at the wrong time.
> """
>
> Anyway I was not aware of this so I thought to share it here.
> Further information is welcome, if you have any.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963573
> [2] https://github.com/systemd/systemd/issues/7291
> [3] https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/


Yep, I always do a "systemctl daemon-reload" directly after editing
these files and looking in /var/run/systemd/generator/ to see if it
did everything right. The problem is how a user should know which
files are affected and not.

I'm personally mostly affected by /etc/fstab and /etc/crypttab, but I
assume there are more auto-generated files.

A while back I started writing custom systemd unit files for mounts
and such, but now I've reverted back to using /etc/fstab directly for
most things and then possibly just dropping in custom extra options in
/etc/systemd/system/ if necessary. I did that because all of my
systems run on multiple fully encrypted raid disks, and it used to be
a mess trying systemd to understand that it has to decrypt everything
first and then try to assemble it and mount it. These days it's much
more clever.

Re: Unable to verify 64-bit live ISO signature

[Reco]

Hi.

On Wed, Jun 24, 2020 at 07:23:14AM +, sebarosa...@protonmail.com wrote:
> Hi! I have been trying to veify the debian live iso signature, but I
> can't find the command to import the debian gpg keys for the
> sha256sum.sign file. What is the command?

gpg --recv-keys DF9B9C49EAA9298432589D76DA87E80D6294BE9B

See also: https://www.debian.org/CD/verify

Reco

Re: from screen to tmux

[Victor Sudakov]

davidson wrote:
> > 
> > In my Gnu screen setup, the corresponding key sequence (unchanged from
> > package defaults in this respect, afaict) is
> > 
> >   Ctrl-a a
> > 
> > And so to emulate that I would probably replace this line
> > 
> >   bind-key C-a send-prefix
> > 
> > with this one instead
> > 
> >   bind-key a send-prefix
> > 
> > so that old muscle-memory would remain useful.
> 
> Yes, this is much better, thank you.

And now that C-a has become vacant in tmux, we can 
"bind-key C-a last-window"
(yet another case of muscle-memory).

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Unable to verify 64-bit live ISO signature

[SeBarosanul]

Hi! I have been trying to veify the debian live iso signature, but I can't find 
the command to import the debian gpg keys for the sha256sum.sign file. What is 
the command?