Re: exif --remove not idempotent, and a Debian man page bug

[Emanuel Berg]

Greg Wooledge wrote:

>> The "-o" means: "Write output image to FILE". And it does
>> so, as far as I can see.
>
> The question is whether specifying "-o f f" where the output file
> has the same name as the input file actually overwrites the original
> input file.  Another person reported that it does *not* -- that you get
> a *.modified.jpeg file as output instead.

Does happen _without_ -o ...

> If I had the first inkling of a clue what an exif tag
> actually *was* I might try testing it myself. I'm gathering
> that it has something to do with JPEG images, based on the
> *.modified.jpeg default output filename. Beyond that,
> I know nothing.
>
> One of you people who knows this software and has a testable
> input file should (please!) try it, and show us the results.

See the first post ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: exif --remove not idempotent, and a Debian man page bug

[Emanuel Berg]

hede wrote:

> "Idempotent" means, that a task with the same input data and
> the same config (for example to remove a tag via exif-tool)
> results in the same output data.

Determinism.

-- 
underground experts united
https://dataswamp.org/~incal

Re: exif --remove not idempotent, and a Debian man page bug

[Emanuel Berg]

The Wanderer wrote:

>>> That's maintainership history, with E-mail
>>> addresses attached.
>> 
>> There should be no history entries in the man pages that
>> relates to practical aspects that are no
>> longer operational.
>
> The E-mail address doesn't relate to a practical
> aspect, though.

Ikr? Since it doesn't work! Just remove it.

-- 
underground experts united
https://dataswamp.org/~incal

Re: feedback on install of bullseye

[David Wright]

On Sat 24 Sep 2022 at 18:48:13 (-0700), Ray Andrews wrote:
> On 2022-09-24 13:52, Dan Ritter wrote:
> > Ray Andrews wrote:
> > > To whom might read this.  I can't boil this down to a formal bug report 
> > > but
> > > for what it's worth:
> > > 
> > > BULLSEYE INSTALL, 2022-09-23:
> > > 
> > > Decided to do a virgin install of bullseye to my /dev/sdb while keeping
> > > /dev/sda devoted to Stretch. Got the installer onto a USB stick, and
> > > proceeding normally. The 'normal' install (sorry, I forget the exact name)
> > > ... I get as far as partitioning and although the disk (sdb) is already
> > > partitioned and formatted and working fine, it seemed to be impossible to
> > > just leave things as they were and install to the existing partitions, it
> > > kept complaining that a necessary step was not completed. Erasing the
> > > partitions (overwrite with zeros) didn't help. I couldn't figure out how 
> > > to
> > > make it work so backed up and selected 'use whole disk'.
> > You are lacking vital information to pass on to us here: what
> > necessary step was not completed?
> When I tried to bypass partitioning.  As I said,  the disk was already
> partitioned and formatted and had a working copy of Debian 9 on it, so
> my thought was to just zero out the existing partitions, which was
> offered, and then proceed to install, but the the installer refused to
> let me proceed.  It seemed to feel the need to create partitions not
> reuse them. 

That would correspond with my reading of §6.3.4.2.

> The final partitioning screen showed the partitions
> marked 'K' (keep) and I couldn't explain to the installer that they
> were free to use.

I would only expect to see partitions marked K where the contents were
to be strictly left alone by the partitioner, but were to be available
for the installer to use. This would include (for GPT disks) EFI and
BIOS Boot partitions, and filesystems like, say, /home or /opt that
had preexisting contents that were to be mounted in the installer just
after the partitioning step.

Here's an example of mine that's closest to the setup that you have.
The first disk is an internal SSD with Windows on it, and the second
is the installer stick.

The third disk is an external caddy, sdb, and has #1 backup provision
for Windows, #2 BIOS Boot for Grub (necessary with a GPT disk), #3 EFI
for booting, #4 an oldoldstable root filesystem that is the one I'm
overwriting in the installer, #5 an oldstable root filesystem that I'm
keeping but don't need mounting in the installer, and #6 which is an
encrypted filesystem that is /home to #5, and will be /home to #4 when
I've configured (say, the next day) the new installation to decrypt
and mount it.

So I'd expect you to have a line like that of #4, and you'd probably
also have a line for swap like:

  │  > #N524.3 MB F  swapLinux swapswap

which I don't have, as the systems on this caddy aren't intended for
any sort of heavy work.

  ┌┤ [!!] Partition disks ├─┐
  │ │
  │ This is an overview of your currently configured partitions and mount   │
  │ points. Select a partition to modify its settings (file system, mount   │
  │ point, etc.), a free space to create partitions, or a device to │
  │ initialize its partition table. │
  │ │
  │  Configure iSCSI volumes↑   │
  │ ▒   │
  │  /dev/nvme0n1 - 512.1 GB THNSN5512GPUK TOSHIBA  ▒   │
  │  > 1.0 MBFREE SPACE ▒   │
  │  > #1367.0 MB  B fat32   EFI system p   ▒   │
  │  > #2134.2 MBMicrosoft re   ▒   │
  │  > #3510.6 GBntfsBasic data p   ▒   │
  │  >   871.9 kBFREE SPACE ▒   │
  │  > #4987.8 MBntfs   ▒   │
  │  > 1.4 MBFREE SPACE ▒   │
  │  SCSI1 (0,0,0) (sda) - 4.0 GB SMI USB DISK  ▒   │
  │  SCSI2 (0,0,0) (sdb) - 1.0 TB Seagate BUP Slim BK   ▒   │
  │  > 1.0 MBFREE SPACE ▒   │
  │  > #1666.8 GBntfsMicrosoft ba   ▒   │
  │  > #2  7.3 MB K  biosgrubBIOS boot pa   ▒   │
  │  > #3268.4 MB  B  K  ESP EFI System ▒   │
  │  > #4 31.5 GB F  ext4Quiz-A/▒   │
  │  > #5 31.5 GBext4Quiz-B ▒   │
  │  > #6270.2 GBQuiz-Home  ▒

Re: feedback on install of bullseye

[David]

On Sun, 25 Sept 2022 at 04:03, Ray Andrews  wrote:

>  ... I get as far as partitioning and although the disk (sdb) is
> already partitioned and formatted and working fine, it seemed to be
> impossible to just leave things as they were and install to the existing
> partitions, it kept complaining that a necessary step was not completed.
> Erasing the partitions (overwrite with zeros) didn't help. I couldn't
> figure out how to make it work so backed up and selected 'use whole disk'.

Hi Ray, I always install to existing partitions, so it is definitely possible.

Debian is very flexible. There are countless installation methods and
options and variations. And they mostly work. They are designed
to be powerful and flexible, but sometimes there is a learning curve.
This is great for people who aren't confused by them, but it makes
it hard to answer questions like yours. Unless you describe exactly
every step, we don't know exactly what you saw or did. And we understand
that providing such information isn't easy for you, either.

The installation guide is here:
  https://www.debian.org/releases/stable/i386/ch06s03.en.html#di-partition

If I was to take a guess based on just the above paragraph ... "it kept
complaining that a necessary step was not completed" sounds like you
did not specify appropriate values for "use as" and "mount point".

I'm guessing that you would likely require
'use as' = "ext4 journalling file system" and 'mount point' = "/".

If that was the situation, the installer won't proceed because it won't
touch partitions that have not been specified to "use as", and it cannot
install Debian until it is told where you want the root filesystem ("/").

I have only ever used the installer in expert mode (that just means more
questions have to be answered), so I'm not experienced with how
it behaves in the simpler modes. I guess manual partitioning is the
same in both, if available. I have never used the GUI installer.

> Why couldn't I use existing, functioning ext4 partitions?

You definitely can. But you have to also specify somewhere for the new
installation to go, using the above method.

You might find the below video helpful for overview. Although I don't
necessarily agree with every detail, it might provide context if you
have any further questions.
  https://www.youtube.com/watch?v=zMCFQwgtN-g

If you have further questions after reading the documentation, the
more specific you can make the question, so that we can exactly
reproduce your situation, the easier it is for volunteers with limited
time to answer you.

Re: feedback on install of bullseye

[David Wright]

On Sat 24 Sep 2022 at 10:45:56 (-0700), Ray Andrews wrote:
> To whom might read this.  I can't boil this down to a formal bug
> report but for what it's worth:
> 
> BULLSEYE INSTALL, 2022-09-23:
> 
> Decided to do a virgin install of bullseye to my /dev/sdb while
> keeping /dev/sda devoted to Stretch. Got the installer onto a USB
> stick, and proceeding normally.

For a wireless netinst install, you'd need the firmware inclusive
version of the installer, but for a wired netinst install, either
with or without firmware would normally suffice.

> The 'normal' install (sorry, I forget
> the exact name) ...

I'm assuming, by contrast with the expert one, it's default installer,
in either text or graphics mode. As far as I can glean from the
Installation Guide, I think you can either (§6.3.4) automatically
partition a whole disk, or (§6.3.4.2) manually /create/ partitions
in one of three ways. That would suggest that to re-use existing
partitions, as I do, you need to use the advanced installer.

As Dan says, the two installers are the same, but just ask different
levels of questions. The partitioner can be told which existing
partitions are to be used for what perpose, and even whether they
should be formatted or not. (Obviously reusing an existing filesystem
with files on it is at your own risk.)

> I get as far as partitioning and although the disk
> (sdb) is already partitioned and formatted and working fine, it seemed
> to be impossible to just leave things as they were and install to the
> existing partitions, it kept complaining that a necessary step was not
> completed.

If this is the «Finish partitioning and write changes to disk» step,
then yes, I believe it's essential because it's the step that actually
ties together the partitions, mount points, and usages in the "mind"
of the installer. As far as actions are concerned, this step can
involve almost none.

> Erasing the partitions (overwrite with zeros) didn't help.

This would be futile in any case, as the installer is expected to
format them with a filesystem (or swap).

> I couldn't figure out how to make it work so backed up and selected
> 'use whole disk'.
> 
> Proceeding, the installer couldn't establish a connection to the web.

That surprised me, in that the installer should have set the clock via
machines on the internet, but I do see (§6.3.3) that the non-expert
installer can side-step the issue in that step. I don't know why that
is the case, or whether it could be related to using a DVD of packages.

> I aborted the install since I couldn't go forward anyway. Boot to sda
> and ... the installer had trashed the MBR of *both* disks and the
> machine was unbootable. I attached another backup disk, booted to
> that, mounted my Stretch partitions on sda, reran LILO, and that was
> fine, I could boot Stretch. But the installer also trashed the swap
> partition on sda -- I had to run mkswap. But no permanent damage was
> done.
> 
> Why would the installer trash the MBR on a disk that was not involved?

Your narrative doesn't contain enough detail to even begin to answer
that question. We don't even knows what you mean by trash. In general,
MBRs are written (by "installation") or executed (at boot time) but
not read. Did you compare them with a known good copy, or see they
were, say, zeroed, or did it/they just not work?

You don't say whether any letters of L I L O appeared, or whether any
boot flagged partitions had lost their flag. What happens if both
disks have flagged partitions, and what mechanism chooses which
disk to boot from. Is it easy to distinguish the sda/sdb disks apart
from each other using only what's displayed in the partitioner or
by the installer (sdX assignments being unstable). These are some
of the factors involved.

> Trying again, I disconnected sda to keep it from getting mauled a
> second time and proceeded with the 'advanced' installer, again
> selecting 'use entire disk', this time the installer took the extra
> steps to get the network up and running and the install completed
> quite smoothly.

That certainly suggests that an appropriate installer was chosen
(my first paragraph).

> Shouldn't the 'normal' install do whatever is needed to get the
> network running? the advanced install had no problem there, I didn't
> have to intervene it just got it done.

I think I covered that at §6.3.3. As I said, I don't know the rationale.

> Why couldn't I use existing, functioning ext4 partitions?

The advanced installer can use existing partitions; you just didn't
select that method according to the narrative above. I'm not sure
what you imply by "functioning"; whether anything more than that
you've used them in the past. I don't know of a method to install
Debian into a preexisting encrypted filesystem, something I've never
needed to attempt. (Disclaimer: I know nothing about any limitations
of disk size, geometry, or addressability concerning LILO booting.)

> If one does have to abort, wouldn't it be better if no 

Re: feedback on install of bullseye

[Ray Andrews]

On 2022-09-24 13:52, Dan Ritter wrote:

Ray Andrews wrote:

To whom might read this.  I can't boil this down to a formal bug report but
for what it's worth:


BULLSEYE INSTALL, 2022-09-23:

Decided to do a virgin install of bullseye to my /dev/sdb while keeping
/dev/sda devoted to Stretch. Got the installer onto a USB stick, and
proceeding normally. The 'normal' install (sorry, I forget the exact name)
... I get as far as partitioning and although the disk (sdb) is already
partitioned and formatted and working fine, it seemed to be impossible to
just leave things as they were and install to the existing partitions, it
kept complaining that a necessary step was not completed. Erasing the
partitions (overwrite with zeros) didn't help. I couldn't figure out how to
make it work so backed up and selected 'use whole disk'.

You are lacking vital information to pass on to us here: what
necessary step was not completed?
When I tried to bypass partitioning.  As I said,  the disk was already 
partitioned and formatted and had a working copy of Debian 9 on it, so 
my thought was to just zero out the existing partitions, which was 
offered, and then proceed to install, but the the installer refused to 
let me proceed.  It seemed to feel the need to create partitions not 
reuse them.  The final partitioning screen showed the partitions marked 
'K' (keep) and I couldn't explain to the installer that they were free 
to use.

Proceeding, the installer couldn't establish a connection to the web.

What network hardware do you have? Wired or wireless?
Wired.  Pretty basic.  As I said, the 'advanced' installer had no 
trouble whatsoever.  The only thing I interacted with was setting the 
delay time to ten seconds from the IIRC default of three seconds.  Seems 
to me the 'basic' installer could/should be able to handle that.



Trying again, I disconnected sda to keep it from getting mauled a second
time and proceeded with the 'advanced' installer, again selecting 'use
entire disk', this time the installer took the extra steps to get the
network up and running and the install completed quite smoothly.

Shouldn't the 'normal' install do whatever is needed to get the network
running? the advanced install had no problem there, I didn't have to
intervene it just got it done.

The normal installer is the advanced installer but it
pre-answers a lot of questions with the most common answers.


Sure, and it was good enough for me, except that it wouldn't connect to 
the internet as I just mentioned.






Why would the installer trash the MBR on a disk that was not involved?

Why couldn't I use existing, functioning ext4 partitions?

You can. Somewhere in the missing error messages are the clues.


It could be that I just wasn't interacting with it properly.  If there 
was a log or something I'd be happy to attach another disk to the 
machine and try again and send you the results.  As long as you guys are 
interested I'll do anything to help.



Thanks Dan





-dsr-

Re: placa de sonido ALC887-VD no detectada

[Marcelo Eduardo Giordano]

No encuentro solución a este problema pero sigo intentando.

que les parece esto que encuentro? Si ejecuto el comando "pulseaudio" 
pasa lo siguiente. Gracias desde ya a todos


pulseaudio
E: [pulseaudio] pid.c: Daemon already running.
E: [pulseaudio] main.c: Ha fallado pa_pid_file_create().

Re: Re: Mal particionado?...

[judedi sago]

El 2022-09-23 a las 22:41 -0300, Gonzalo Rivero escribió:

> El 23/9/22 a las 18:08, judedi sago escribió:
> > Buenas tardes…
> > Otra vez a molestarlos un poco con una justa inquietud.
> >
> > Según me muestra fdisk, aquí se están perdiendo 52.2 G en la partición
> > extendida que quedó como primera partición.

La partición extendida es una partición lógica que sirve a modo de
contenedor y que en tu caso, ocupa 51,2 GiB donde tienes instalado
Linux, entiendo.

> > Disco /dev/sda: 465,76 GiB, 500107862016 bytes, 976773168 sectores
> > Modelo de disco: WDC WD5000AVDS-6
> > Unidades: sectores de 1 * 512 = 512 bytes
> > Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
> > Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
> > Tipo de etiqueta de disco: dos
> > Identificador del disco: 0xcbe73cf0
> >
> > Disposit.  Inicio  Comienzo Final  Sectores Tamaño Id Tipo
> > /dev/sda1  *   2046 107438079 107436034  51,2G  5 Extendida
> > /dev/sda2 107438080 976773167 869335088 414,5G  7
HPFS/NTFS/exFAT
> > /dev/sda5  2048  20269055  20267008   9,7G 83 Linux
> > /dev/sda6  20271104  27674623   7403520   3,5G 83 Linux
> > /dev/sda7  27676672  31848447   4171776 2G 82 Linux swap /
Solaris
> > /dev/sda8  31850496  33257471   1406976   687M 83 Linux
> > /dev/sda9  33259520 107438079  74178560  35,4G 83 Linux
> >
> > Las entradas de la tabla de particiones no están en el orden del disco.
> >
> > (Hasta aquí fdisk)...
> >
> > Es verdad?…
> >
> > Y es posible recuperarlos sin que haya que borrar las otras
particiones?…

Ojo, si la borras pierdes todo lo que contiene la partición, que en tu
caso es el sistema y datos de Linux.

Fíjate que el tamaño que te ocupa la partición extendida es 51,5 GiB
que es la suma de sda5 + sda6 + sda7 + sda8 + sda9.

Además, ahora mismo la tienes marcada como partición de arranque (*),
que es donde tienes GRUB2, si la eliminas no iniciará el sistema,
tendrás que cambiar la bandera a otra partición que contenga un
cargador de arranque, claro está.
RESPUESTA:

Muchas gracias a todos.

Dejaré todo quietico ya que entonces no se esta perdiendo nada.
La confusión nace de que 414.5 + 51.2 = 465.7 y el disco es de 500G.
Hay una diferencia de 34.3G y eso es normal. Entonces supongo que es normal.

Sean felices.

Re: OT: mysql-workbench alternative

[Nicholas Geovanis]

On Sat, Sep 24, 2022, 2:47 PM Gareth Evans  wrote:

> Given what looks to be the ongoing absence of mysql-workbench in stable:
>
> https://tracker.debian.org/pkg/mysql-workbench
>
> Can anyone recommend a free (at least as in beer) alternative that creates
> ERDs automatically from MariaDB?
>

It's just an educated guess but can't doxygen do that?

I tried installing mysql-workbench-community from mysql.com on Ubuntu
> 22.04, but it wouldn't find MariaDB (which was running) to attempt to
> connect with, so not sure if that's what I really want anyway!
>
> Running under Wine is an option if necessary.
>
> Thanks,
> Gareth
>
>

Re: feedback on install of bullseye

[Dan Ritter]

Ray Andrews wrote: 
> To whom might read this.  I can't boil this down to a formal bug report but
> for what it's worth:
> 
> 
> BULLSEYE INSTALL, 2022-09-23:
> 
> Decided to do a virgin install of bullseye to my /dev/sdb while keeping
> /dev/sda devoted to Stretch. Got the installer onto a USB stick, and
> proceeding normally. The 'normal' install (sorry, I forget the exact name)
> ... I get as far as partitioning and although the disk (sdb) is already
> partitioned and formatted and working fine, it seemed to be impossible to
> just leave things as they were and install to the existing partitions, it
> kept complaining that a necessary step was not completed. Erasing the
> partitions (overwrite with zeros) didn't help. I couldn't figure out how to
> make it work so backed up and selected 'use whole disk'.

You are lacking vital information to pass on to us here: what
necessary step was not completed?

> Proceeding, the installer couldn't establish a connection to the web.

What network hardware do you have? Wired or wireless?

> Trying again, I disconnected sda to keep it from getting mauled a second
> time and proceeded with the 'advanced' installer, again selecting 'use
> entire disk', this time the installer took the extra steps to get the
> network up and running and the install completed quite smoothly.
> 
> Shouldn't the 'normal' install do whatever is needed to get the network
> running? the advanced install had no problem there, I didn't have to
> intervene it just got it done.

The normal installer is the advanced installer but it
pre-answers a lot of questions with the most common answers.

> Why would the installer trash the MBR on a disk that was not involved?
> 
> Why couldn't I use existing, functioning ext4 partitions?

You can. Somewhere in the missing error messages are the clues.

-dsr-

Re: Grosse fatigue

[Pierre-Elliott Bécue]

BERTRAND Joël  wrote on 23/09/2022 at 10:31:52+0200:

> Pierre-Elliott Bécue a écrit :
>> Une ligne de log, quelque chose qui montre que systemd a bien tué X
>> et éventuellement pourquoi, ou bien on est juste sur yet another
>> mail de baseless FUD?
>
> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0...
> Sep 23 08:49:31 hilbert systemd[577146]: Activating special unit Exit
> the Session...
> Sep 23 08:49:31 hilbert systemd[577146]: Removed slice User Core
> Session Slice.
> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Main User Target.
> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Basic System.
> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Paths.
> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Sockets.
> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Timers.
> Sep 23 08:49:31 hilbert systemd[577146]: Closed D-Bus User Message Bus
> Socket.
> Sep 23 08:49:31 hilbert systemd[577146]: Closed GnuPG network
> certificate management daemon.
> Sep 23 08:49:31 hilbert systemd[577146]: Closed Socket to launch
> DrKonqi for a systemd-coredump crash.
> Sep 23 08:49:31 hilbert systemd[577146]: Closed GCR ssh-agent wrapper.
> Sep 23 08:49:31 hilbert systemd[577146]: Closed GNOME Keyring daemon.
> ...
> Sep 23 08:49:31 hilbert systemd[577146]: Reached target Shutdown.
> Sep 23 08:49:31 hilbert systemd[577146]: Finished Exit the Session.
> Sep 23 08:49:31 hilbert systemd[577146]: Reached target Exit the Session.
> Sep 23 08:49:31 hilbert systemd[1]: user@0.service: Deactivated
> successfully.
> Sep 23 08:49:31 hilbert systemd[1]: Stopped User Manager for UID 0.
> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Runtime Directory
> /run/user/0...
> Sep 23 08:49:31 hilbert systemd[1]: run-user-0.mount: Deactivated
> successfully.
> Sep 23 08:49:31 hilbert systemd[1]: user-runtime-dir@0.service:
> Deactivated successfully.
> Sep 23 08:49:31 hilbert systemd[1]: Stopped User Runtime Directory
> /run/user/0.
> Sep 23 08:49:31 hilbert systemd[1]: Removed slice User Slice of UID 0.
> ...

Ok, donc systemd ne tue pas X. systemd met un terme à la session de
root. La raison est que systemd détermine au moment où il le fait que le
dernier processus interactif (c'est-à-dire contrôlé par un utilisateur)
a terminé, et par défaut dans ce cas, il clos la session, et termine
donc tout programme lancé depuis cette session (logique, ça évite que
des trucs traînent ad-vitam comme résidus d'une session interactive).

Dans la mesure où tu as a priori une session graphique qui tourne, c'est
effectivement surprenant, mais il est possible (vu que tu ne postes que
les logs qui t'intéressent, qui ne sont pas forcément les logs
pertinents) que ta session utilisateur meure pour une raison ou une
autre et qu'en conséquence, systemd considère qu'il n'y a plus aucun
programme interactif qui tourne.

Il y a une façon d'éviter que systemd ferme une session en cas de fin de
tous les programmes interactifs d'un utilisateur, via "loginctl
enable-linger $username". Ici ça ressemble à du scotch sur une jambe de
bois car cela ne t'aidera pas à comprendre ce qu'il se passe
derrière.

Creuser les logs (un cron qui se lance? ton wm qui meurt/crashe?) serait
sans doute plus pertinent, voire activer certains debugs sur certains
progs. Après l'enable-linger peut aider à voir ce qu'il se passe et
trouver le nœud du problème si c'est effectivement un programme qui
meurt (puisque dans ce cas il mourra toujours mais le reste ne sera pas
buté).

>   Au passage, systemd va jusqu'à tuer ypbind :
>
> Sep 23 08:49:46 hilbert systemd[1]: ypbind.service: Main process
> exited

Non, systemd constate juste que ypbind a terminé, il ne le tue pas, et
n'a rien à voir avec son arrêt. C'est bien de critiquer, c'est mieux de
lire les lignes de logs que tu colles.

>   On se demande bien pourquoi.
>
>   Et il relance le tout comme si rien ne s'était passé (enfin, là,
> parce que par moment il tue ypbind sans le redémarrer, ce qui pose des
> problèmes amusants sur une machine diskless en NIS/NFS).

Il le relance parce qu'en cas d'arrêt inopiné, c'est ce que le service
est supposé faire.

> De toute façon, la question n'est pas là. systemd décide pour une
> raison inconnue de clôturer la session. Naturellement, il n'y a AUCUNE
> erreur avant la première ligne de log. Je veux donc me séparer à la
> fois de cette saleté qui est une brique pour essuyer les plâtres et
> d'usrmerge.

Feel free to go elsewhere, mais ici le souci c'est avant tout que tu as
décidé que c'était un bug ou un comportement inexplicable plutôt que
d'essayer de comprendre ce qu'il se passe.

Tu auras donc d'autres problèmes sur d'autres systèmes, et tu trouveras
un autre outil à blâmer.

>   Je précise que ce genre de chose arrive tous les deux ou trois jours
> et que c'est gavant.

C'est sûr que ça doit l'être, mais c'est pas pour autant qu'il faut
devenir fainéant et juste rentrer dans le FUD. :)

-- 
PEB


signature.asc

OT: mysql-workbench alternative

[Gareth Evans]

Given what looks to be the ongoing absence of mysql-workbench in stable:

https://tracker.debian.org/pkg/mysql-workbench

Can anyone recommend a free (at least as in beer) alternative that creates ERDs 
automatically from MariaDB?

I tried installing mysql-workbench-community from mysql.com on Ubuntu 22.04, 
but it wouldn't find MariaDB (which was running) to attempt to connect with, so 
not sure if that's what I really want anyway!

Running under Wine is an option if necessary.  

Thanks,
Gareth

Re: LibreOffice - any way to recover not saved changes to the file?

[Curt]

On 2022-09-24, David Wright  wrote:
>
> It's odd: virtually all the software I use (eg emacs, gnumeric,
> inkscape, even mutt) modifies either the title bar or a status bar
> as soon as I make any modification of a document (typically an
> asterisk), and removes it if I revert the change, or save it.

lowriter puts an asterisk on the floppy drive icon (saves when you click
it) that sits on the taskbar.

> I can't see any such indication in LO, and I did try reverting a
> change to one cell in a spreadsheet, and when I quit with ^Q, it
> asked if I wanted to Save the document even though it was unaltered.
>
> Not being a DE user, I don't know whether this is typical of software
> more closely associated with DEs. Is the feature missed by users?
>
> Cheers,
> David.
>
>


-- 

Re: carte son externe de qualité HIFI USB

[Virgile Jarrige]

Bonsoir,

>Certaines personnes appellent aussi ce produit un DAC.

Pour moi, un DAC n'est pas une carte son, mais un "convertisseur" de son 
numérique en "son potable" ^^ On trouve également des amplis hi-fi avec DAC 
intégré. 

En entrée d'un DAC tu peux mettre la sortie d'une carte son, et la sortie du 
DAC va sur l'entrée de l'ampli hifi - c'est cette config que j'ai chez moi, et 
ça a l'avantage de pouvoir brancher n'importe quelle source de son (un 
smartphone,...) et d'avoir un son potable sur mon système audio de salon. Je 
suis surtout content de ne pas avoir eu à changer mon ampli qui a une bonne 
quinzaine d'années.

Pour récapituler :
Source audio --> DAC --> ampli --> enceintes

Le DAC que j'ai a onze ans, je pense que ça a évolué entre temps.

Une rapide recherche "DAC usb fibre optique" donne des résultats intéressants 
:) 

Après, on peut peut-être trouver une carte son avec DAC intégré mais sur un 
système existant je ne vois pas trop l'intérêt. À moins que ton système audio 
soit vraiment vraiment costaud et que tu recherches un son vraiment vraiment 
soigné. Mais dans ce cas là, n'utilise pas ton ordi pour le son, et passe par 
des pros comme Klinger Favre. ;)

Bonne soirée,

-- 
Virgile

Re: Will firefox-esr move to version 102 in bullseye?

[Tixy]

On Sat, 2022-09-24 at 20:36 +0200, Anders Andersson wrote:
> Yes, I may have been "lucky" in the sense that I probably already had
> the prerequisite libraries installed, and had perhaps already messed
> with the required settings. There seem to be two orthogonal components
> necessary to get smooth fullscreen video from youtube in firefox:
> "Accelerated web page rendering" and "Hardware accelerated video
> decoding".

18 months ago, this was working for me after forcing acceleration to be
enabled in Firefox config. Then when Debian moved to next ESR it broke,
and I spent ages looking at packages and option to try and fix it,
without success. I tried Mozilla's Firefox deb package which worked
fine, as did the Google Chrome and Vivaldi binaries from them.

I now find myself using Debian's Firefox for general browsing, Vivaldi
for watching video and Google Chrome exclusively for accessing my
Google account services (chat and video meetings).

-- 
Tixy

Re: Will firefox-esr move to version 102 in bullseye?

[Anders Andersson]

On Sat, Sep 24, 2022 at 7:53 PM Tixy  wrote:
>
> On Sat, 2022-09-24 at 18:46 +0100, Tixy wrote:
> > On Sat, 2022-09-24 at 18:52 +0200, Anders Andersson wrote:
> > [...]
> > > What's more, I no longer have to continue my research about
> > > hardware-accelerated video playback in the browser which prompted all
> > > of this - it just started working automatically after the upgrade.
> >
> > I just checked and you're right, no more tearing :-)
>
> Actually, I'm wrong, just ran tearing test video from YouTube and
> latest Firefox still tears, will stick with Vivaldi.
>
> --
> Tixy

Yes, I may have been "lucky" in the sense that I probably already had
the prerequisite libraries installed, and had perhaps already messed
with the required settings. There seem to be two orthogonal components
necessary to get smooth fullscreen video from youtube in firefox:
"Accelerated web page rendering" and "Hardware accelerated video
decoding".

For what it's worth, I now get smooth fullscreen 1080p video from
youtube with very little CPU load on a state of the art 14 year old
CPU and mediocre Radeon RX 460 from 2016 on a 3084x1600 monitor, all
on a standard debian stable gnome+wayland+firefox and free drivers (as
far as I know!) so it's definitely doable without much tweaking other
than having the right packages and maybe one or two settings in
firefox.

carte son externe de qualité HIFI USB

[Alex PADOLY]

Bonsoir à tous,

Connaissez-vous une ou des cartes son USB reconnues par LINUX et 
produisant un son de qualité HIFI.


Certaines personnes appellent aussi ce produit un DAC.

Merci pour vos réponses.

Bonne soirée.

Re: LibreOffice - any way to recover not saved changes to the file?

[David Wright]

On Sat 24 Sep 2022 at 06:43:03 (-0400), Eike Lantzsch KY4PZ wrote:
> On Samstag, 24. September 2022 00:11:01 -04 piorunz wrote:
> > On 24/09/2022 01:38, Eike Lantzsch KY4PZ wrote:
> > > did you realize that, if the backup copy fails for any reason, also
> > > the document cannot be saved and thus *all* work is lost? I
> > > experienced this behaviour recently to my dismay (not to say
> > > anger).
> > 
> > I never used Backup copy feature, I just enabled it. Its doing no
> > harm, right? I never relied on this feature because I never used it.
> > 
> The problem is: if you enabled it and for some reason the backup copy 
> cannot be written, LibreOffice also does not write the original.
> The warning LibreOffice emits is: "Cannot write backup copy" but it does 
> not tell you that it will not even write the original, even if that 
> *could* be written.

It's odd: virtually all the software I use (eg emacs, gnumeric,
inkscape, even mutt) modifies either the title bar or a status bar
as soon as I make any modification of a document (typically an
asterisk), and removes it if I revert the change, or save it.

I can't see any such indication in LO, and I did try reverting a
change to one cell in a spreadsheet, and when I quit with ^Q, it
asked if I wanted to Save the document even though it was unaltered.

Not being a DE user, I don't know whether this is typical of software
more closely associated with DEs. Is the feature missed by users?

Cheers,
David.

feedback on install of bullseye

[Ray Andrews]

To whom might read this.  I can't boil this down to a formal bug report 
but for what it's worth:



BULLSEYE INSTALL, 2022-09-23:

Decided to do a virgin install of bullseye to my /dev/sdb while keeping 
/dev/sda devoted to Stretch. Got the installer onto a USB stick, and 
proceeding normally. The 'normal' install (sorry, I forget the exact 
name) ... I get as far as partitioning and although the disk (sdb) is 
already partitioned and formatted and working fine, it seemed to be 
impossible to just leave things as they were and install to the existing 
partitions, it kept complaining that a necessary step was not completed. 
Erasing the partitions (overwrite with zeros) didn't help. I couldn't 
figure out how to make it work so backed up and selected 'use whole disk'.


Proceeding, the installer couldn't establish a connection to the web. I 
aborted the install since I couldn't go forward anyway. Boot to sda and 
... the installer had trashed the MBR of *both* disks and the machine 
was unbootable. I attached another backup disk, booted to that, mounted 
my Stretch partitions on sda, reran LILO, and that was fine, I could 
boot Stretch. But the installer also trashed the swap partition on sda 
-- I had to run mkswap. But no permanent damage was done.


Trying again, I disconnected sda to keep it from getting mauled a second 
time and proceeded with the 'advanced' installer, again selecting 'use 
entire disk', this time the installer took the extra steps to get the 
network up and running and the install completed quite smoothly.


Shouldn't the 'normal' install do whatever is needed to get the network 
running? the advanced install had no problem there, I didn't have to 
intervene it just got it done.


Why would the installer trash the MBR on a disk that was not involved?

Why couldn't I use existing, functioning ext4 partitions?

If one does have to abort, wouldn't it be better if no changes at all 
were made to anything? Why have a trashed system even when one had to 
abort? In other words, why not check that the network is available 
*before* trashing the MBR of both disks and the partition table of sdb 
and the swap partition of the other disk?


... just in case anyone is interested.

Re: Will firefox-esr move to version 102 in bullseye?

[Tixy]

On Sat, 2022-09-24 at 18:46 +0100, Tixy wrote:
> On Sat, 2022-09-24 at 18:52 +0200, Anders Andersson wrote:
> [...]
> > What's more, I no longer have to continue my research about
> > hardware-accelerated video playback in the browser which prompted all
> > of this - it just started working automatically after the upgrade.
> 
> I just checked and you're right, no more tearing :-)

Actually, I'm wrong, just ran tearing test video from YouTube and
latest Firefox still tears, will stick with Vivaldi.

-- 
Tixy

Re: Will firefox-esr move to version 102 in bullseye?

[Tixy]

On Sat, 2022-09-24 at 18:52 +0200, Anders Andersson wrote:
[...]
> What's more, I no longer have to continue my research about
> hardware-accelerated video playback in the browser which prompted all
> of this - it just started working automatically after the upgrade.

I just checked and you're right, no more tearing :-) A year ago I
resorted to installing Vivaldi for video watching as that had graphics
acceleration that worked with Debian, whereas Debian's browser didn't
:-(

-- 
Tixy

Re: Will firefox-esr move to version 102 in bullseye?

[Anders Andersson]

Sorry for top-posting, but it makes sense for this summary.

As indicated by the replies to my initial email, it is now late
September and firefox-esr has moved to version 102 in the stable
branch. I just upgraded without even noticing any difference,
definitely nothing that broke.

What's more, I no longer have to continue my research about
hardware-accelerated video playback in the browser which prompted all
of this - it just started working automatically after the upgrade. As
a "seasoned" linux user I'm not used to things going this smooth, so
thanks everyone involved for making this upgrade as painless and
invisible as expected from Debian stable.

On Wed, Aug 24, 2022 at 9:13 PM Sven Joachim  wrote:
>
> On 2022-08-24 15:01 -0400, Greg Wooledge wrote:
>
> > On Wed, Aug 24, 2022 at 07:52:44PM +0100, Tixy wrote:
> >> Mozilla stops supporting the old ESR a few months after a new one is
> >> released [1]. So I assume Debian would ship the new one, certainly at
> >> least at the point the old one gets known security vulnerabilities.
> >>
> >> [1] https://support.mozilla.org/en-US/kb/firefox-esr-release-cycle
> >
> > Yes, this is correct.  A current timeline seems to be here:
> >
> > https://wiki.mozilla.org/Release_Management/Calendar
> >
> > Looking at the ESR column in the first table, 2022-08-23 brought us
> > ESR versions 91.13 and 102.2, while 2022-09-20 will have only version
> > 102.3.
> >
> > So, as of Sept. 20th (projected), the 91.x ESR branch will be unsupported,
> > and we'll all have to move to the 102.x branch, whether we want it or not.
>
> For Debian stable, I expect Firefox and Thunderbird to move to the 102
> branch after the next Bullseye point release, scheduled for September
> 10[1].  To build them, at least rustc 1.59 is needed, and Bullseye
> currently only has version 1.51 (packaged as rustc-mozilla).
>
> Cheers,
>Sven
>
>
> 1. https://lists.debian.org/debian-live/2022/08/msg6.html
>

Re: LibreOffice - any way to recover not saved changes to the file?

[Eike Lantzsch KY4PZ]

On Samstag, 24. September 2022 11:27:24 -04 Charles Curley wrote:
> On Sat, 24 Sep 2022 15:50:04 +0100
>
> piorunz  wrote:
> > On 24/09/2022 11:43, Eike Lantzsch KY4PZ wrote:
> > > The problem is: if you enabled it and for some reason the backup
> > > copy cannot be written, LibreOffice also does not write the
> > > original. The warning LibreOffice emits is: "Cannot write backup
> > > copy" but it does not tell you that it will not even write the
> > > original, even if that *could* be written.
> >
> > That's very interesting. Where does backup copy is being written? To
> > the same folder where original supposed to be? Like Kate text editor
> > writes backups as "filename.txt~" in the same folder?
>
> ~/.config/libreoffice/4/user/backup/

That's like Camelot - "Let's not go there. It's a silly place."
Under ~/.config there ought to be config files - not backup files. But just
my personal opinion. Beauty is in the eye of the beholder ...
>
> Incidentally, it won't hurt to prune those files occasionally.
+1

All the best
Eike

Re: LibreOffice - any way to recover not saved changes to the file?

[piorunz]

On 24/09/2022 16:27, Charles Curley wrote:


That's very interesting. Where does backup copy is being written? To
the same folder where original supposed to be? Like Kate text editor
writes backups as "filename.txt~" in the same folder?


~/.config/libreoffice/4/user/backup/

Incidentally, it won't hurt to prune those files occasionally.


Thanks. Exactly, that's what I found in LO settings after Eike post. I
will leave them in this location, my /home folder does not malfunction,
like never, so I don't expect this to fail.

--
With kindest regards, Piotr.

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

Re: LibreOffice - any way to recover not saved changes to the file?

[Charles Curley]

On Sat, 24 Sep 2022 15:50:04 +0100
piorunz  wrote:

> On 24/09/2022 11:43, Eike Lantzsch KY4PZ wrote:
> 
> > The problem is: if you enabled it and for some reason the backup
> > copy cannot be written, LibreOffice also does not write the
> > original. The warning LibreOffice emits is: "Cannot write backup
> > copy" but it does not tell you that it will not even write the
> > original, even if that *could* be written.  
> 
> That's very interesting. Where does backup copy is being written? To
> the same folder where original supposed to be? Like Kate text editor
> writes backups as "filename.txt~" in the same folder?

~/.config/libreoffice/4/user/backup/

Incidentally, it won't hurt to prune those files occasionally.

-- 
Does anybody read signatures any more?

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

Re: exif --remove not idempotent, and a Debian man page bug

[David Wright]

On Sat 24 Sep 2022 at 12:13:09 (+1200), Alex King wrote:
> On 24/09/22 03:32, Greg Wooledge wrote:
> > On Fri, Sep 23, 2022 at 11:22:31AM -0400, The Wanderer wrote:
> > > 'man bash' cites Brian Fox and Chet Ramey as the authors, and gives an
> > > E-mail address for each. (It's possible that they may be the active
> > > upstream maintainers, as well.)
> > 
> > Chet Ramey is the current upstream bash maintainer.  Brian Fox has not
> > been involved with bash development for decades.  Nevertheless, removing
> > Brian's email address from the AUTHORS section is neither necessary nor
> > desirable.  Everyone knows it's a historical section.
> > 
> I've been using Debian as my main OS since 1997 or earlier.  I've
> spent 100s of hours reading man pages.  Although it's a reasonable
> assumption (since there are a lot of man pages with outdated AUTHORS
> sections), I didn't know the AUTHORS section is supposed to be an
> historical record.
> 
> Have you got a reference to that somewhere?  After all (some) man
> pages have a HISTORY section for historical information.

Unless you come up with a patch to do this, and maintain it to cope
with upstream modifications, you're at the mercy of the upstream
and, of course, the Author.

> > In the case of the bash(1) page, it's actually followed by a BUG REPORTS
> > section, telling you how to submit bug reports to the upstream maintainer.
> > That's not common in man pages, but clearly not unheard of either.
> > 
> > As a Debian user, however, one is expected to know how to file bug reports
> > correctly.  It is NOT done by trudging through the man page looking for
> > the first email address one can find.  It's done by using the reportbug
> > tool, or by following the instructions on the 
> > web site.
> 
> Again, I sometimes report bugs to Debian and sometimes to upstream,
> and occasionally email maintainers directly, especially if I can't
> work out if any upstream still exists and especially if the software
> is not (any longer) in Debian.
> 
> How is it expected that a new user will have learnt "how to file bug
> reports correctly?"  What is the typical path for a Debian user to
> pick up that knowledge?  What even is the correct way to report bugs,
> and where is that documented?  I see
> https://www.debian.org/Bugs/Reporting, which mentions "Don't file bugs
> upstream, if you file a bug in Debian" Perhaps you can point to some
> documentation discussing whether to report a bug to Debian or through
> other channels.  Or perhaps a statement recommending (particularly
> newbies) to report all bugs direct to Debian.  It seems to be implied,
> but I didn't see where it was stated explicitly.

Typically, the maintainer is given in several places, like the Bugs
page, the Packages page, the Tracker page, and the Packages file.
The last of these gives the URL of the software's home page as well.

> I see at https://www.debian.org/support, that after IRC, this list is
> the second channel mentioned for people seeking support with Debian.
> 
> I believe using phrases like "Everyone knows it's a historical
> section." when the OP didn't seem to know that, and "one is expected
> to know how" is not particularly helpful.  Especially on the channel
> that is the first (usable) point of contact for new users seeking
> support, if they are not familiar with IRC.
> 
 [ … ]
> 
> In relation to man pages, perhaps everyone could agree that ideally
> historical email addresses could be removed from the AUTHORS section
> and moved to a HISTORY section.  I'm sure we can all agree this should
> not be mandatory, but those who feel most strongly about it could
> contribute patches...

Good to see that they're identifying themselves here :)

Cheers,
David.

Re: LibreOffice - any way to recover not saved changes to the file?

[Eike Lantzsch KY4PZ]

On Samstag, 24. September 2022 10:50:04 -04 piorunz wrote:
> On 24/09/2022 11:43, Eike Lantzsch KY4PZ wrote:
> > The problem is: if you enabled it and for some reason the backup
> > copy
> > cannot be written, LibreOffice also does not write the original.
> > The warning LibreOffice emits is: "Cannot write backup copy" but it
> > does not tell you that it will not even write the original, even if
> > that *could* be written.
> 
> That's very interesting. Where does backup copy is being written? To
> the same folder where original supposed to be? Like Kate text editor
> writes backups as "filename.txt~" in the same folder?
> 
> 
> --
> With kindest regards, Piotr.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄
It can be configured under Options - LibreOffice - Paths
At the moment I do not recall the default. I put them into
/home/username/tmp
after the disaster which I experienced once.
It is not LibreOffice that is to blame, I think, but KDE in my case. Maybe 
if working with Gnome it wouldn't happen. I don't know.
There is an edge case in KDE which impedes sometimes the write of temp 
files no matter where you put them. It is difficult to reproduce. It does 
not have to do with file ownership or the destination being writable.
I tried all that.
It is a real malfunction - "mal funktioniert's und mal nicht" in German.

The part for which I do blame LibreOffice is that, if unable to save the 
backup copy, it ought to write the original if that can be written at 
all - which in my case *is possible* even when the temp-file-problem 
happens.

Cheers
Eike
-- 
Eike Lantzsch KY4PZ / ZP6CGE

Re: exif --remove not idempotent, and a Debian man page bug

[David Wright]

On Sat 24 Sep 2022 at 10:43:04 (-0400), Greg Wooledge wrote:
> On Sat, Sep 24, 2022 at 03:17:31PM +0200, hede wrote:
> > Am 21.09.2022 14:46, schrieb Emanuel Berg:
> > > Maybe related to the '-o f f' part as your imagination
> > > tells you ...
> > 
> > The "-o" means: "Write output image to FILE". And it does so, as far as I
> > can see.
> 
> The question is whether specifying "-o f f" where the output file
> has the same name as the input file actually overwrites the original
> input file.  Another person reported that it does *not* -- that you get
> a *.modified.jpeg file as output instead.

That was me, and I think I used the wrong file to test (IFD had been
stripped already), and I think I confused the output from several
runs (I hadn't used exif before, excepting a while back, when I
determined that it couldn't read the photos off my Samsung Gusto2
mobile, which means it's useless for me).

> If I had the first inkling of a clue what an exif tag actually *was* I
> might try testing it myself.  I'm gathering that it has something to do
> with JPEG images, based on the *.modified.jpeg default output filename.
> Beyond that, I know nothing.
> 
> One of you people who knows this software and has a testable input file
> should (please!) try it, and show us the results.  Make an empty
> directory.  Copy the JPEG file into it.  Show "ls -l" output.  Run the
> exif command.  Show "ls -l" again.

I showed the EXIF itself instead.

Cheers,
David.

Re: exif --remove not idempotent, and a Debian man page bug

[David Wright]

On Fri 23 Sep 2022 at 16:14:43 (+0200), Emanuel Berg wrote:
> David Wright wrote:
> >> exif(1) which says on line 57 that --remove
> >> 
> >>   Remove the tag or (if no tag is specified) the entire IFD.
> >> 
> >> Only if it does, why is it there the next time to be removed
> >> as well?
> >
> > Have you tried it?
> 
> Yes, see the first post runs, they show that the same result
> is obtained from running the same supposedly remove command on
> the same files, 1, 2, and it would seem n number of times.

I made an error in my testing, in that I think I used a
(published) stripped jpeg for the same-filename test.

Using a photograph from my own archives shows that --remove
is stripping the IFD and   -o foo foo   is overwriting the
original file, though I don't know what its mechanism is
(one hopes it makes safeguards).

> No, in that case I would have .modified. img files over the
> whole disk.

Yes, that would seem to be correct.

> > It's up to you to overwrite the original.
> 
> You mean don't use the -o, or use the -o to point to a new
> file, and then manually overwrite the old file with the
> new one?

To be honest, I don't use exif but exifprobe -L, and I wouldn't
want to make modifications without keeping modified copies in a
separate tree (I've done this for lower resolution publication
on web pages). I can see why you might be doing the same sort
of thing (perhaps for tree-houses?).

BTW exif can't read photos off a Samsung Gusto2 mobile.

> re: exif I don't know why processing happens again if the
> material has already been removed.

It wouldn't be the first filter program to behave in this way.

> The '-o' shouldn't
> matter since step one should be "is the material present?" and
> if it isn't, nothing should be outputted. It should just say
> "this file is already OK".

That would be asking a filter program to treat the construction
--remove -o foo foo   as a unique case, where it conditionally
doesn't write an output file.

Anyway, here's a test on an old photograph of mine:

$ exif 2005-05-24-18-20-44.jpg
EXIF tags in '2005-05-24-18-20-44.jpg' ('Intel' byte order):
+--
Tag |Value
+--
Image Description   |01
Manufacturer|FUJIFILM
Model   |DS-300
Orientation |Top-left
X-Resolution|72
Y-Resolution|72
Resolution Unit |Inch
White Point |0.3127, 0.3290
Primary Chromaticiti|0.640, 0.330, 0.300, 0.600, 0.150, 0.060
YCbCr Coefficients  |0.299, 0.587, 0.114
YCbCr Positioning   |Co-sited
Reference Black/Whit| 0, 255, 128, 255, 128, 255
Exif Version|Exif Version 1.1
Date and Time (Origi|2005:05:24 18:20:43
Components Configura|Y Cb Cr -
Compressed Bits per | 2
Shutter Speed   |6.50 EV (1/91 sec.)
Aperture|3.50 EV (f/3.4)
FlashPixVersion |FlashPix Version 1.0
Color Space |Uncalibrated
+--
$ exif --remove -o 2005-05-24-18-20-44.jpg 2005-05-24-18-20-44.jpg
Wrote file '2005-05-24-18-20-44.jpg'.
$ exif 2005-05-24-18-20-44.jpg
EXIF tags in '2005-05-24-18-20-44.jpg' ('Intel' byte order):
+--
Tag |Value
+--
X-Resolution|72
Y-Resolution|72
Resolution Unit |Inch
Exif Version|Exif Version 2.1
FlashPixVersion |FlashPix Version 1.0
Color Space |Uncalibrated
+--
$ exif --remove -o 2005-05-24-18-20-44.jpg 2005-05-24-18-20-44.jpg
Wrote file '2005-05-24-18-20-44.jpg'.
$ exif 2005-05-24-18-20-44.jpg
EXIF tags in '2005-05-24-18-20-44.jpg' ('Intel' byte order):
+--
Tag |Value
+--
X-Resolution|72
Y-Resolution|72
Resolution Unit |Inch
Exif Version|Exif Version 2.1
FlashPixVersion |FlashPix Version 1.0
Color Space |Uncalibrated
+--
$ 

… idempotent ad infinitum.

Cheers,
David.

Re: exif --remove not idempotent, and a Debian man page bug

[Curt]

On 2022-09-24, Alex King  wrote:
>
>
> I've been using Debian as my main OS since 1997 or earlier.  I've spent 
> 100s of hours reading man pages.  Although it's a reasonable assumption 
> (since there are a lot of man pages with outdated AUTHORS sections), I 
> didn't know the AUTHORS section is supposed to be an historical record.
>

How can an AUTHORS section be outdated? F. Scott Fitzgerald is dead,
and fan mail will fail to reach him, but he remains the author of *The
Great Gatsby*.

Re: LibreOffice - any way to recover not saved changes to the file?

[piorunz]

On 24/09/2022 11:43, Eike Lantzsch KY4PZ wrote:


The problem is: if you enabled it and for some reason the backup copy
cannot be written, LibreOffice also does not write the original.
The warning LibreOffice emits is: "Cannot write backup copy" but it does
not tell you that it will not even write the original, even if that
*could* be written.


That's very interesting. Where does backup copy is being written? To the
same folder where original supposed to be? Like Kate text editor writes
backups as "filename.txt~" in the same folder?


--
With kindest regards, Piotr.

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

Re: exif --remove not idempotent, and a Debian man page bug

[Greg Wooledge]

On Sat, Sep 24, 2022 at 03:17:31PM +0200, hede wrote:
> Am 21.09.2022 14:46, schrieb Emanuel Berg:
> > Maybe related to the '-o f f' part as your imagination
> > tells you ...
> 
> The "-o" means: "Write output image to FILE". And it does so, as far as I
> can see.

The question is whether specifying "-o f f" where the output file
has the same name as the input file actually overwrites the original
input file.  Another person reported that it does *not* -- that you get
a *.modified.jpeg file as output instead.

If I had the first inkling of a clue what an exif tag actually *was* I
might try testing it myself.  I'm gathering that it has something to do
with JPEG images, based on the *.modified.jpeg default output filename.
Beyond that, I know nothing.

One of you people who knows this software and has a testable input file
should (please!) try it, and show us the results.  Make an empty
directory.  Copy the JPEG file into it.  Show "ls -l" output.  Run the
exif command.  Show "ls -l" again.

Re: exif --remove not idempotent, and a Debian man page bug

[hede]

Am 21.09.2022 14:46, schrieb Emanuel Berg:

I don't know what the intended behaviof of "exif --remove -o
file file" is. I'm imagining [...]


exif(1) which says on line 57 that --remove

  Remove the tag or (if no tag is specified) the entire IFD.


"Idempotent" means, that a task with the same input data and the same 
config (for example to remove a tag via exif-tool) results in the same 
output data. Is this the case here?




Only if it does, why is it there the next time to be removed
as well?

Maybe related to the '-o f f' part as your imagination
tells you ...


The "-o" means: "Write output image to FILE". And it does so, as far as 
I can see.


hede

Re: Mal particionado?...

[JavierDebian]

El 23/9/22 a las 18:08, judedi sago escribió:

Buenas tardes…
Otra vez a molestarlos un poco con una justa inquietud.

Según me muestra fdisk, aquí se están perdiendo 52.2 G en la partición
extendida que quedó como primera partición.

Disco /dev/sda: 465,76 GiB, 500107862016 bytes, 976773168 sectores
Modelo de disco: WDC WD5000AVDS-6
Unidades: sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
Tipo de etiqueta de disco: dos
Identificador del disco: 0xcbe73cf0

Disposit.  Inicio  Comienzo Final  Sectores Tamaño Id Tipo
/dev/sda1  *   2046 107438079 107436034  51,2G  5 Extendida
/dev/sda2 107438080 976773167 869335088 414,5G  7 HPFS/NTFS/exFAT
/dev/sda5  2048  20269055  20267008   9,7G 83 Linux
/dev/sda6  20271104  27674623   7403520   3,5G 83 Linux
/dev/sda7  27676672  31848447   4171776 2G 82 Linux swap / Solaris
/dev/sda8  31850496  33257471   1406976   687M 83 Linux
/dev/sda9  33259520 107438079  74178560  35,4G 83 Linux

Las entradas de la tabla de particiones no están en el orden del disco.

(Hasta aquí fdisk)...

Es verdad?…

Y es posible recuperarlos sin que haya que borrar las otras particiones?…



Se entiende el particionado.
La pregunta: ¿Qué está montado en cada una de ellas?
Para eso, como root:

#  lsblk

y

# blkid


JAP

Re: LibreOffice - any way to recover not saved changes to the file?

[Eike Lantzsch KY4PZ]

On Samstag, 24. September 2022 00:11:01 -04 piorunz wrote:
> On 24/09/2022 01:38, Eike Lantzsch KY4PZ wrote:
> > did you realize that, if the backup copy fails for any reason, also
> > the document cannot be saved and thus *all* work is lost? I
> > experienced this behaviour recently to my dismay (not to say
> > anger).
> 
> I never used Backup copy feature, I just enabled it. Its doing no
> harm, right? I never relied on this feature because I never used it.
> 
The problem is: if you enabled it and for some reason the backup copy 
cannot be written, LibreOffice also does not write the original.
The warning LibreOffice emits is: "Cannot write backup copy" but it does 
not tell you that it will not even write the original, even if that 
*could* be written.

All the best
Eike

> I intend to rely on normal file save as a first thing, then on
> built-in recovery in case of reboots (I use Debian Testing and these
> happens when GPU driver freezes, LibreOffice always recover opened
> files without fail). As a third thing and last thing I will rely on
> backup copy feature which I never used.
> Additionally, selected important files are synced via SyncThing with
> one year of versioning history.
> 
> > So beware: If you get the warning that the backup copy cannot be
> > written, then save your document in another way. E.g. ctrl-a and
> > paste it into an editor or whatever so at least you have your text
> > safe even without the formatting and whatnot.
> > 
> > This is a very silly behaviour of LibreOffice. If the backup copy
> > cannot be written but the document can be written - why not at
> > least save the document before closing the LibreOffice Writer?
> 
> Thanks for your advice, I will keep that in mind, although I never
> experienced read-only tmp folder or LibreOffice being unable to save
> file.
> > After this experience I disabled backup copies because it is even
> > more dangerous than working without backup copies. The reasons why
> > backup copies sometimes cannot be written is very obscure. It seems
> > to be a hickup of KDE which affects LibreOffice because similar
> > things happen sometimes with Okular which sometimes is unable to
> > write its tmp files.
> --
> With kindest regards, Piotr.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄


-- 
Eike Lantzsch KY4PZ / ZP6CGE
Ag. Molas Lopez
Casilla de Correo 13005
01726 Asuncion / Paraguay
SIPgate: +49-4131-9279632
Land-line: +595-21-553984
Cell-phone: +595-971-696909
Skype: eikelan
Signal: zp6cge Eike Lantzsch
WIRE: @eikelantzsch

Re: Mal particionado?...

[Camaleón]

El 2022-09-23 a las 22:41 -0300, Gonzalo Rivero escribió:

> El 23/9/22 a las 18:08, judedi sago escribió:
> > Buenas tardes…
> > Otra vez a molestarlos un poco con una justa inquietud.
> > 
> > Según me muestra fdisk, aquí se están perdiendo 52.2 G en la partición
> > extendida que quedó como primera partición.

La partición extendida es una partición lógica que sirve a modo de 
contenedor y que en tu caso, ocupa 51,2 GiB donde tienes instalado 
Linux, entiendo.

> > Disco /dev/sda: 465,76 GiB, 500107862016 bytes, 976773168 sectores
> > Modelo de disco: WDC WD5000AVDS-6
> > Unidades: sectores de 1 * 512 = 512 bytes
> > Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
> > Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
> > Tipo de etiqueta de disco: dos
> > Identificador del disco: 0xcbe73cf0
> > 
> > Disposit.  Inicio  Comienzo Final  Sectores Tamaño Id Tipo
> > /dev/sda1  *   2046 107438079 107436034  51,2G  5 Extendida
> > /dev/sda2 107438080 976773167 869335088 414,5G  7 HPFS/NTFS/exFAT
> > /dev/sda5  2048  20269055  20267008   9,7G 83 Linux
> > /dev/sda6  20271104  27674623   7403520   3,5G 83 Linux
> > /dev/sda7  27676672  31848447   4171776 2G 82 Linux swap / 
> > Solaris
> > /dev/sda8  31850496  33257471   1406976   687M 83 Linux
> > /dev/sda9  33259520 107438079  74178560  35,4G 83 Linux
> > 
> > Las entradas de la tabla de particiones no están en el orden del disco.
> > 
> > (Hasta aquí fdisk)...
> > 
> > Es verdad?…
> > 
> > Y es posible recuperarlos sin que haya que borrar las otras particiones?…

Ojo, si la borras pierdes todo lo que contiene la partición, que en tu 
caso es el sistema y datos de Linux.

Fíjate que el tamaño que te ocupa la partición extendida es 51,5 GiB 
que es la suma de sda5 + sda6 + sda7 + sda8 + sda9.

Además, ahora mismo la tienes marcada como partición de arranque (*), 
que es donde tienes GRUB2, si la eliminas no iniciará el sistema, 
tendrás que cambiar la bandera a otra partición que contenga un 
cargador de arranque, claro está.

> En realidad no estás perdiendo nada, parece que estás usando el formato de
> particiones que al no recordar el nombre real le llamaré "clásico". En este
> esquema solo podías tener hasta 4 particiones. Cuando se vió que se podría
> necesitar mas que 4 inventaron las particiones extendidas, que básicamente
> es otra partición con particiones dentro.
> 
> En ese disco, sda5,sda6,sda7,sda8 y sda9 viven dentro de sda1. Entonces tu
> disco está organizado mas o menos así:
> 
> [sda1(sda5 |sda6 |sda7 |sda8 |sda9) | sda2]
> 
> Y por eso también se estará quejando que las particiones no aparecen en 
> orden. A menos que tengas un backup de todo el disco, no vayas a borrar nada.
> 
> pd/offtopic: no veo en thunderbird una opción para enviar como texto
> plano... espero que el mail no salga en html

Hum... está donde siempre. En el modo de edición de un nuevo correo, 
Opciones →  Formato → Sólo texto sin formato.

Saludos,

-- 
Camaleón