Re: Bookworm Fasttrack and Virtualbox
On Mon, Mar 18, 2024 at 3:12 PM Andrew M.A. Cater wrote: > On Sun, Mar 17, 2024 at 10:49:16PM +0100, Miguel A. Vallejo wrote: > > Greg Wooledge () wrote: > > > > > It's not just you. The use of three "b" names in a row (buster, > > > bullseye, bookworm) was in my opinion a poor decision. I've taken > > > to calling the releases by their numbers (10, 11, 12) instead of > > > their codenames to avoid confusion wherever possible. > > > > I feel ashamed. > > Don't feel ashamed: the time_t 64 transition has meant that May be he _should_ feel ashamed? It could be a cathartic or constructive experience for him? May be he __wants__ to feel ashamed? Just postulating possibilities ...
Re: shellcheck, bashism's and one liners.
On 17/03/2024 23:56, Greg Wooledge wrote:
On Sun, Mar 17, 2024 at 11:14:56PM +0700, Max Nikulin wrote:
args() { printf '%s\0' a b c d; }
args | xargs -0 sh -c 'count() { echo $#; }; count "$@"' sh-count
It would be easier in the case of script file instead of shell function. An
assumption is that all arguments may be passed through command line.
Tim's assumption here is that he can write a function which emits a
stream of whitespace-separated words, and use this safely in an unquoted
command substitution.
count $(args)
I'm guessing "count" is a stand-in for something more complex, but $(args)
is pretty much exactly what he wants to do in his real script.
A rudimentary variant of xargs may be implemented in shell. I have no
idea how to get null-delimited list from apt-get.
sh-xargs() {
declare -a args
mapfile -t args
"$@" "${args[@]}"
}
count () {
echo $#
}
# shellcheck disable=SC2016
apt-get indextargets --format '$(FILENAME)' 'Identifier: Packages' |
sh-xargs count
I find it acceptable to suppress warnings from static code analyzers at
specific lines. As to variables that sometimes expands to nothing,
perhaps their values may be collected to arrays. However it is the point
when a full-fledged programming language becomes a better alternative.
Re: shellcheck, bashism's and one liners.
On Sun, 17 Mar 2024, Greg Wooledge wrote: Tim's assumption here is that he can write a function which emits a stream of whitespace-separated words, and use this safely in an unquoted command substitution. count $(args) I'm guessing "count" is a stand-in for something more complex, but $(args) is pretty much exactly what he wants to do in his real script. Yes, thanks, this is exactly it. Taken me most of the weekend but I've managed to get rid of everything except a handful of places where shellcheck can't understand/follow. Some "computed" sourced files, a few places I'm using sed where it says to try // / stuff - and I might revisit one day, and a couple of other places that I don't want to change but are correct. This exercise found two bugs - one had a workaround that I now need to revisit. The other was because I could no longer use an associative array to hold a space split string but had to use a computed variable to hold a list. There was nothing wrong with the data in the array but the array index was wrong, which shellcheck couldn't spot either way but v_$a was not a valid variable name, which it would have been if the array index was correct. And then I've spent a lot of time tracking down the new bugs. The hardest of which was down to changing $a into "$a" resulted in a leading space in a function parameter. The problem is that this works *brilliantly* with inputs that are heavily restricted to a specific set of characters, and fails *utterly* if the inputs do not conform to that limitation. There is no middle ground, and there is no way to fix it up. Once your inputs take off their training wheels, you have to throw this script away and rewrite it from the ground up. This is true, but at the point debian has an architecture with a space in the name is probably the point I rewrite it in python :-) That's why shellcheck gives warnings about this kind of thing. (Well, one of many reasons.)
Re: Bookworm Fasttrack and Virtualbox
On Sun, Mar 17, 2024 at 10:49:16PM +0100, Miguel A. Vallejo wrote: > Greg Wooledge () wrote: > > > It's not just you. The use of three "b" names in a row (buster, > > bullseye, bookworm) was in my opinion a poor decision. I've taken > > to calling the releases by their numbers (10, 11, 12) instead of > > their codenames to avoid confusion wherever possible. > > > > I feel ashamed. > Don't feel ashamed: the time_t 64 transition has meant that unstable is genuinely unstable. It's OK to have difficulty: the main thing is that you've got it to work now. This is _exactly_ the right approach: you've explained your problems, you asked for advice, you've managed to solve them. I wish other people could do the same :) All the very best, as ever, Andy > > Now my sources.list is with bookworm, and virtualbox is working just fine, > like it was in unstable. > > Thank you and sorry for the inconveniences.
Re: Re: Libreoffice y fuentes del paquete xfonts-scalable.
Muchas gracias Camaleón por la aclaracion! Pues nada, a la vieja usanza: $ mkdir .fonts; cd .fonts; wget https://cdn1.maisfontes.com/temp/courier-10-pitch-maisfontes.f169.zip $ unzip courier-10-pitch-maisfontes.f169.zip; rm courier-10-pitch-maisfontes.f169.zip Y solucionao! Mira que me jode que en el software libre no se mantenga la integracion, la retrocompatibilidad y las rutas/estetica de las cosas... Es por eso que solo uso el escritorio de Mate... Las cosas estan donde deben estar, donde siempre! Venga, un saludo a tod@s! Jac.
Re: Bookworm Fasttrack and Virtualbox
Greg Wooledge () wrote: > It's not just you. The use of three "b" names in a row (buster, > bullseye, bookworm) was in my opinion a poor decision. I've taken > to calling the releases by their numbers (10, 11, 12) instead of > their codenames to avoid confusion wherever possible. > I feel ashamed. I tried to force the time_t 64 transition in unstable because the system was in a state no longer usable: more than 700 kept back packages and were unable to install anything new so after manually forcing the transition it became unusable, with a lot of broken things. So I set up a stable installation and I wanted Virtualbox for some virtual machines I use. I saw the fasttrack wiki page, I saw the instructions were for bullseye, and I assumed changing bullseye with bookworm will work, but I do not know why bullseye survived in the sources.list even after changing it manually at least two times. I do not know if KDE's klipper was playing with me pasting the incorrect data or what, but bullseye survived... I also didn't notice the error message trying to install virtualbox was referencing bullseye... Bullseye and bookworm are totally different words but maybe for no english native speakers they are easily mistaken I don't know. Now my sources.list is with bookworm, and virtualbox is working just fine, like it was in unstable. Thank you and sorry for the inconveniences.
Re: Bookworm Networking Issues
> Can anybody suggest how to get the networking running? Have you searched the web for answered? I suspect searching for "get the networking running" or "fix my problems" will get you up and running in no time. Stefan
Re: Bookworm Networking Issues
On Sun, Mar 17, 2024 at 08:46:26PM +0100, Marco Moock wrote: > Am 17.03.2024 um 16:54:27 Uhr schrieb David: > > > Can anybody suggest how to get the networking running? > > You have to tell us what doesn't work in your network. > > Also show the output of > ip a > cat /etc/resolv.conf I have a feeling everyone's over-thinking this. I suspect what the OP wants is the *literal command* they should type. Unfortunately, without knowing the contents of /etc/network/interfaces we can't give the literal command. You'd have to know the name(s) of the network interfaces that are defined. Then, for each interface, you would run an "ifup" command. For example, on my current machine, the network interface is named "eno1". To bring this interface up, if it's not already up, I would run: ifup eno1 Of course, there's also a desire to ensure that the network interfaces are correctly brought up when you boot. Therefore, the ultimate test is to reboot the machine. If the interfaces come up when you boot, then things are probably configured correctly. If they don't, then you have a problem to solve.
Re: Bookworm Networking Issues
Am 17.03.2024 um 16:54:27 Uhr schrieb David: > Can anybody suggest how to get the networking running? You have to tell us what doesn't work in your network. Also show the output of ip a cat /etc/resolv.conf -- Gruß Marco Send spam to 1710690867mu...@cartoonies.org
Re: Bookworm Networking Issues
On Sun, Mar 17, 2024 at 04:54:27PM +, David wrote: > I am running Bookworm on a thin client and Network-Manger seems to be > the source of my problems. > > I have purged Network-Manager from this thin client, but I can't find > out how to get /etc/network/interface to run. I have added to 2 NIC's > that I need. > > Can anybody suggest how to get the networking running? Package ifupdown is installed? Cheers -- t signature.asc Description: PGP signature
Re: Bookworm Networking Issues
On Sun, 17 Mar 2024 16:54:27 + David wrote: > I am running Bookworm on a thin client and Network-Manger seems to be > the source of my problems. > > I have purged Network-Manager from this thin client, but I can't find > out how to get /etc/network/interface to run. I have added to 2 NIC's > that I need. > > Can anybody suggest how to get the networking running? > > Thank you, > > David. > "man interfaces" might help. The name of the file is "/etc/network/interfaces". Note the s on the end. Do you have other typos, say, in the file? Also, you could show us verbatim the contents of your /etc/network/interfaces. You might also look at systemd-networkd. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Bookworm Fasttrack and Virtualbox
On Sun, Mar 17, 2024 at 01:31:40PM -0400, Roy J. Tellason, Sr. wrote: > On Sunday 17 March 2024 08:48:29 am Greg Wooledge wrote: > > On Sun, Mar 17, 2024 at 12:35:33PM +0100, Miguel A. Vallejo wrote: > > > Well... it seems my brain can't distinguish Bookworm from Bullseye. > > > > It's not just you. The use of three "b" names in a row (buster, > > bullseye, bookworm) was in my opinion a poor decision. I've taken > > to calling the releases by their numbers (10, 11, 12) instead of > > their codenames to avoid confusion wherever possible. > > The use of those codenames drives me nuts... > > I don't, for the most part, have any idea what numeric version is being > referred to, and would far prefer to see those numbers used instead, myself. > It works both ways - there is a place for both to coexist. The one thing that is consistently difficult is when people refer to "I have a system running Debian stable" and you don't know _which_ version they're talking about. 10, 11 and 12 have all been stable at some point: if someone says "Oh, I've found an old system running stretch" I have some idea how old it is. Bear in mind that the first version of Debian to have a codename was one of the earliest precisely *because* the numbers were problematic. (A third party CD vendor put out "Debian 1.0" which was Debian 0.97 and a pre-release - the release proper had to be 1.1) Debian has more or less dropped the importance of the number in the point release space as significant. It doesn't make a great deal of difference if you're running 12.4 or 12.5 unless you're significantly out of date and haven't updated for months or years. The significance of the codename in /etc/apt/sources.list is that it's an enduring token - it's easy to see the difference between buster and bullseye when you see the word. As a Debain developer, I'm watching the changes in unstable at the minute to make Debian 64 bit time safe: it's taking longer than anyone would want but I know that it's meant for Trixie not Forky. "The usrmerge transition has been talked about for several releases - it will likely be ready for Trixie but we might have to support some legacy provision into Forky (or even Forky+1). i386 deprecation will happen in Trixie, with likely full removal in Forky." (say) is meaningful to me even if I have to think that Trixie (will be) Debian 13 at release and that Forky is the as yet largely unplanned Debian 14. That code name is stable for all stages of the release cycle and that's important, even as I don't know when the final releases will be. Notably, Ubuntu has both a very defined release cycle and a defined series of codenames in alphabetical order (except for Wily Wombat) and you have to remember which versions are LTS. I know that Precise is newer than older variants and older than Trusty but I couldn't tell you which versions are LTS from codenames alone. I just know to pick versions that are 14.04, 16.04, 18.04 etc. - likewise, I can't tell you know what the end dates for ten year support are because that was only introduced latterly. [Wily Wombat was 5.04, Nimble Numbat will be 24.04]. Other distributions have codenames that are effectively meaningless and largely internal - Red Hat, anybody? Debian tends to use both for overlapping purposes. For you as an end user - use whichever you feel happiest with. All the best, as ever, Andy > > -- > Member of the toughest, meanest, deadliest, most unrelenting -- and > ablest -- form of life in this section of space, a critter that can > be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" > - > Information is more dangerous than cannon to a society ruled by lies. --James > M Dakin >
Re: Notificació d'incidències de Debian
Hola Narcis, > Algú sap explicar-me el perquè? Si estàs en una llista de correu on s'envien les notificacions o bé en algun moment t'has subscrit als avisos d'algun paquet via tracker.debian.org. Les capçaleres dels correus de notificació haurien de contenir més pistes sobre el seu origen. Si en comparteixes algun amb mi et puc donar un cop de mà en resoldre el misteri, però assegura't que s'inclouen totes les capçaleres, especialment les Received. Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: Bookworm Networking Issues
On Sonntag, 17. März 2024 13:54:27 -03 David wrote: > I am running Bookworm on a thin client and Network-Manger seems to be > the source of my problems. > > I have purged Network-Manager from this thin client, but I can't find > out how to get /etc/network/interface to run. I have added to 2 NIC's > that I need. > > Can anybody suggest how to get the networking running? > > Thank you, > > David. David, with all respect, your post is bare of any information which would enable someone without a crystal ball to help with the issue. Maybe start here: 'man if' and or 'man ifconfig' All the best -- Eike Lantzsch KY4PZ / ZP5CGE
Bookworm Networking Issues
I am running Bookworm on a thin client and Network-Manger seems to be the source of my problems. I have purged Network-Manager from this thin client, but I can't find out how to get /etc/network/interface to run. I have added to 2 NIC's that I need. Can anybody suggest how to get the networking running? Thank you, David.
Re: Bookworm Fasttrack and Virtualbox
On Sunday 17 March 2024 08:48:29 am Greg Wooledge wrote: > On Sun, Mar 17, 2024 at 12:35:33PM +0100, Miguel A. Vallejo wrote: > > Well... it seems my brain can't distinguish Bookworm from Bullseye. > > It's not just you. The use of three "b" names in a row (buster, > bullseye, bookworm) was in my opinion a poor decision. I've taken > to calling the releases by their numbers (10, 11, 12) instead of > their codenames to avoid confusion wherever possible. The use of those codenames drives me nuts... I don't, for the most part, have any idea what numeric version is being referred to, and would far prefer to see those numbers used instead, myself. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
Re: shellcheck, bashism's and one liners.
On Sun, 17 Mar 2024, Greg Wooledge wrote:
On Sun, Mar 17, 2024 at 09:25:10AM +, Tim Woodall wrote:
In almost all other cases, the space separated items cannot, even in
theory, contain a rogue space, so suppressing the warning is fine
Famous Last Words™.
As one example, it calls out to an external program that builds a cache
in a temporary dir and it can be told to keep that temporary dir for
future runs.
$ cat test
#!/bin/bash
do_work()
{
local f=0
while [[ $1 =~ ^-- ]]; do
[[ $1 = "--fast" ]] && f=1
shift
done
echo -n "first file arg = '$1'"
[[ ${f} -eq 1 ]] && echo -n " running with --fast"
echo
}
loopitems=(
aitem1
aitem2
bitem1
bitem2
)
declare -A fast
echo "No quoting"
for i in "${loopitems[@]}"; do
do_work ${fast[${i:0:1}]} --option1 --option2 "${i}"
fast[${i:0:1}]=--fast
done
echo
echo "Quoting"
unset fast
declare -A fast
for i in "${loopitems[@]}"; do
do_work "${fast[${i:0:1}]}" --option1 --option2 "${i}"
fast[${i:0:1}]=--fast
done
$ shellcheck test
In test line 26:
do_work ${fast[${i:0:1}]} --option1 --option2 "${i}"
^---^ SC2086: Double quote to prevent globbing and word
splitting.
Did you mean:
do_work "${fast[${i:0:1}]}" --option1 --option2 "${i}"
$ ./test
No quoting
first file arg = 'aitem1'
first file arg = 'aitem2' running with --fast
first file arg = 'bitem1'
first file arg = 'bitem2' running with --fast
Quoting
first file arg = ''
first file arg = 'aitem2' running with --fast
first file arg = ''
first file arg = 'bitem2' running with --fast
because fast is an array I can't use the trick that "${x[@]}"
expands to nothing at all when fast is a list because you cannot have an
array of lists.
I could, instead, use something like (I haven't tested these exactly
lines so tweaks are possibly needed)
declare -a "fast_${i:0:1}=( --fast )"
and
declare -n "v=fast_${i:0:1}"
do_work "${v[@]}" ...
Which is what I've now done in the one place where filenames were
involved.
Re: shellcheck, bashism's and one liners.
On Sun, Mar 17, 2024 at 10:57:43AM -0500, Nate Bargmann wrote:
> What errors do you get if you use sh instead of bash?
He's not getting any errors. His script actually works for his current
inputs. He was just getting warnings from shellcheck, which is an
external script validation tool.
One of the warnings is harmless in this context. He's doing something
that *looks* like a common newbie mistake, but actually isn't, and the
reason he's doing it is out of his control (design of apt-get).
The other warning is a valid one, because what he's doing won't work
in the general case, where filenames contain whitespace or globbing
characters. It works fine with "naive" filenames (alphanumeric plus
a very limited set of punctuation, such as . _ - characters), but
doesn't generalize.
On Sun, Mar 17, 2024 at 11:14:56PM +0700, Max Nikulin wrote:
> On 17/03/2024 16:25, Tim Woodall wrote:
> > args() { echo a b c d; }
> > count() { echo $#; }
> > count $(args)
>
> args() { printf '%s\0' a b c d; }
> args | xargs -0 sh -c 'count() { echo $#; }; count "$@"' sh-count
>
> It would be easier in the case of script file instead of shell function. An
> assumption is that all arguments may be passed through command line.
Tim's assumption here is that he can write a function which emits a
stream of whitespace-separated words, and use this safely in an unquoted
command substitution.
count $(args)
I'm guessing "count" is a stand-in for something more complex, but $(args)
is pretty much exactly what he wants to do in his real script.
The problem is that this works *brilliantly* with inputs that are
heavily restricted to a specific set of characters, and fails *utterly*
if the inputs do not conform to that limitation. There is no middle
ground, and there is no way to fix it up. Once your inputs take off
their training wheels, you have to throw this script away and rewrite
it from the ground up.
That's why shellcheck gives warnings about this kind of thing. (Well,
one of many reasons.)
Re: shellcheck, bashism's and one liners.
On 17/03/2024 16:25, Tim Woodall wrote:
args() { echo a b c d; }
count() { echo $#; }
count $(args)
args() { printf '%s\0' a b c d; }
args | xargs -0 sh -c 'count() { echo $#; }; count "$@"' sh-count
It would be easier in the case of script file instead of shell function.
An assumption is that all arguments may be passed through command line.
Re: shellcheck, bashism's and one liners.
Hi Tim. What errors do you get if you use sh instead of bash? On Debian systems sh should be a symbolic link to dash. On Debian dash is preferred for system shell scripts (perhaps even required now) and I use it for my personal scripts unless there is some need to use bash instead. I still use bash for my login shell. I've used shellcheck to point me in the right direction and figure that if dash runs the script without errors then it's close enough to POSIX compatible for my needs. I don't anticipate my scripts needing to run on some ancient Unix shell. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: [testing] plus de session graphique !
Non, il faut chercher la commande correspondante pour gnome, à lancer en tant que utilisateur. Ou lightdm ou qc de ce genre pour lancer le gestionnaire de connexion graphique installé. Mais si X ne fonctionne pas du tout, ça ne peut pas fonctionner non plus Klaus
[resolu] Re: [testing] plus de session graphique !
Problème résolu ! Je ne sais pas comment ça s'est fait mais gdm3, gnome-shell et gnome- session avaient été déinstallés ... Après les avoir remis tout est rentré dans l'ordre. Ouf ! Gaëtan
Re: [testing] plus de session graphique !
Le dimanche 17 mars 2024 à 16:47 +0100, Gaëtan Perrier a écrit : > Le dimanche 17 mars 2024 à 16:25 +0100, Klaus Becker a écrit : > > > > Salut, > > > > j'ai parfois un problème du même genre sous instable. Comme > > workaround, > > je démarre XFCE4 en tty avec "startxfce4". > > > > Pour Gnome, est-ce que c'est startx ? > > Gaëtan > Si je lance startx, j'ai un écran noir avec curseur de la souris uniquement. Gaëtan
Re: [testing] plus de session graphique !
Le dimanche 17 mars 2024 à 16:25 +0100, Klaus Becker a écrit : > > Salut, > > j'ai parfois un problème du même genre sous instable. Comme > workaround, > je démarre XFCE4 en tty avec "startxfce4". > Pour Gnome, est-ce que c'est startx ? Gaëtan
Re: [testing] plus de session graphique !
J'ai pu lancer synaptic via ssh -X et j'ai pu constater que le problème n'est pas lié aux paquets que je voulais retirer car en fait ils n'ont pas été retirés. Le plantage de X est donc intervenu juste avant et sans rapport. C'est donc liés aux mises à jours d'aujourd'hui... Le dimanche 17 mars 2024 à 15:53 +0100, Gaëtan Perrier a écrit : > Bonjour, > > Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets > libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme > plus disponibles j'ai perdu ma session graphique. Elle s'est fermée > pendant la mise à jour ... > Depuis elle ne démarre plus mais je ne vois pas d'erreur dans syslog > ou > dans journalctl. > J'utilise les pilotes nvidia-legacy-driver-390xx. > J'ai juste le service ocserv qui est failed mais je ne pense pas que > ça > ait un lien ? > Bref j'aimerai remettre ces 2 paquets libt* mais pas moyen de les > retrouver. J'ai regardé sur la machine depuis laquelle j'écris et qui > est sous stable mais je ne vois pas de paquet pouvant correspondre > ... > > C'était un nom court et dans un des deux il me semble qu'il y avait > 64. > > Si quelqu'un a une idée je suis preneur. > > Gaëtan >
Re: [testing] plus de session graphique !
Am 17/03/2024 um 15:53 schrieb Gaëtan Perrier: Bonjour, Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme plus disponibles j'ai perdu ma session graphique. Elle s'est fermée pendant la mise à jour ... Depuis elle ne démarre plus mais je ne vois pas d'erreur dans syslog ou dans journalctl. J'utilise les pilotes nvidia-legacy-driver-390xx. J'ai juste le service ocserv qui est failed mais je ne pense pas que ça ait un lien ? Bref j'aimerai remettre ces 2 paquets libt* mais pas moyen de les retrouver. J'ai regardé sur la machine depuis laquelle j'écris et qui est sous stable mais je ne vois pas de paquet pouvant correspondre ... C'était un nom court et dans un des deux il me semble qu'il y avait 64. Si quelqu'un a une idée je suis preneur. Gaëtan Salut, j'ai parfois un problème du même genre sous instable. Comme workaround, je démarre XFCE4 en tty avec "startxfce4". librement Klaus
Re : apt pas content
On 17/03/2024 14:26:24, Gaëtan Perrier wrote:
> Justement, je suis en testing ;)
> Mais ce je ne comprends pas c'est que gnutls semble à jour:
Bonjour,
J’ai un peu le même problème avec Sid.
# apt full-upgrade
[coupe coupe coupe]
794 mis à jour, 265 nouvellement installés, 318 à enlever et 18 non mis à jour.
Il est nécessaire de prendre 1 579 Mo dans les archives.
Après cette opération, 180 Mo d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] n
Annulation.
Les 18 paquets qui ne veulent pas se mettre à jour sont des paquets qui
semblent définitivement passés en 64 bits (oui, je sais), mais ça vire trop de
trucs.
# apt upgrade
[coupe coupe coupe]
58 mis à jour, 0 nouvellement installés, 0 à enlever et 784 non mis à jour.
Il est nécessaire de prendre 83,0 Mo dans les archives.
Après cette opération, 173 ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n]o
Ensuite, j’essaie ça :
# aptitude full-upgrade fluidsynth fontforge
[coupe coupe coupe]
Jusqu’à trouver, éventuellement une solution qui ne désinstalle pas trop de
trucs :
Les NOUVEAUX paquets suivants vont être installés :
libpipewire-0.3-0t64{a} libpython3.11t64{a}
Les paquets suivants seront ENLEVÉS :
libpipewire-0.3-0{a} libpython3.11{a}
Les paquets suivants seront mis à jour :
fluidsynth fontforge fontforge-common fontforge-extras gstreamer1.0-pipewire
libfontforge4
libpipewire-0.3-modules libpython3.11-dev libpython3.11-minimal
libpython3.11-stdlib libspa-0.2-bluetooth
libspa-0.2-modules pipewire pipewire-bin pipewire-pulse python3.11
python3.11-dev python3.11-minimal
python3.11-venv
19 paquets mis à jour, 2 nouvellement installés, 2 à enlever et 765 non mis à
jour.
aptitude est plus bourrin qu'apt et quelques paquets perdent des dépendances.
En fait, il s’agit de paquets (chez moi) qui bénéficient d’un suffixe t64 mais
qui ne cassent rien d’autre. Le contenu du paquet est bien là puisque les
applications dans les paquets qui officiellement dépendent encore du paquet
sans le suffixe fonctionnent toujours.
Bref, je prends des risques calculés puisque je vois passer petit à petit dans
apt upgrade des paquets qui ne passaient pas auparavant, même avec aptitude
full-upgrade.
nicolas patrois : pts noir asocial
--
RÉALISME
M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ?
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...
[testing] plus de session graphique !
Bonjour, Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme plus disponibles j'ai perdu ma session graphique. Elle s'est fermée pendant la mise à jour ... Depuis elle ne démarre plus mais je ne vois pas d'erreur dans syslog ou dans journalctl. J'utilise les pilotes nvidia-legacy-driver-390xx. J'ai juste le service ocserv qui est failed mais je ne pense pas que ça ait un lien ? Bref j'aimerai remettre ces 2 paquets libt* mais pas moyen de les retrouver. J'ai regardé sur la machine depuis laquelle j'écris et qui est sous stable mais je ne vois pas de paquet pouvant correspondre ... C'était un nom court et dans un des deux il me semble qu'il y avait 64. Si quelqu'un a une idée je suis preneur. Gaëtan
Re: apt pas content
Le samedi 16 mars 2024 à 15:29 +0100, BERTRAND Joël a écrit : > Bonjour, > > Il y a un gros problème avec gnutls mais je pensais que ça se > limitais > à testing. J'ai réussi à m'en sortir hier en forçant l'installation de > la mise à jour de gnutls et de ses dépendances et en _réinstallant_ le > reste qui a été viré par un dist-upgrade. Seul cups est toujours cassé. > > JB > Bonjour, Justement, je suis en testing ;) Mais ce je ne comprends pas c'est que gnutls semble à jour: $ apt-show-versions | grep gnutls gnutls-bin:amd64/testing 3.8.3-1 uptodate gnutls-bin:i386 not installed libcurl3-gnutls:amd64/testing 8.5.0-2 uptodate libcurl3-gnutls:i386/testing 8.5.0-2 uptodate libcurl4-gnutls-dev:amd64/testing 8.5.0-2 uptodate libcurl4-gnutls-dev:i386 not installed libgnutls-dane0:amd64/testing 3.8.3-1 uptodate libgnutls-dane0:i386/testing 3.8.3-1 uptodate libgnutls-openssl27:amd64/testing 3.8.3-1 uptodate libgnutls-openssl27:i386/testing 3.8.3-1 uptodate libgnutls28-dev:amd64/testing 3.8.3-1 uptodate libgnutls28-dev:i386 not installed libgnutls30:amd64/testing 3.8.3-1 uptodate libgnutls30:i386/testing 3.8.3-1 uptodate libneon27-gnutls:amd64/testing 0.33.0-1 uptodate libneon27-gnutls:i386 not installed libsrt1.5-gnutls:amd64/testing 1.5.3-1+b1 uptodate libsrt1.5-gnutls:i386/testing 1.5.3-1+b1 uptodate libxmlsec1-gnutls:amd64/testing 1.2.38-1+b1 uptodate libxmlsec1-gnutls:i386 not installed Donc je ne vois pas quoi forcer ? Gaëtan signature.asc Description: This is a digitally signed message part
Re: Bookworm Fasttrack and Virtualbox
On 2024-03-17 at 08:48, Greg Wooledge wrote: > On Sun, Mar 17, 2024 at 12:35:33PM +0100, Miguel A. Vallejo wrote: > >> Well... it seems my brain can't distinguish Bookworm from >> Bullseye. > > It's not just you. The use of three "b" names in a row (buster, > bullseye, bookworm) was in my opinion a poor decision. I tend to concur. The closest thing to a helpful mnemonic for it that I've found (which isn't very close, and often isn't very helpful, given how frequently I fail to remember it when I would need it) is that the names are in reverse alphabetical order. > I've taken to calling the releases by their numbers (10, 11, 12) > instead of their codenames to avoid confusion wherever possible. Because of the contexts (including, but not limited to, sources.list) where you can't use those numbers, and have to use codenames instead, that hasn't been helpful to me. The numbers also don't have any intuitive correlation with the names, so mapping from one to another requires looking them up in some appropriate document, which is inconvenient enough that in practice it mostly won't be done. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bookworm Fasttrack and Virtualbox
On Sun, Mar 17, 2024 at 12:35:33PM +0100, Miguel A. Vallejo wrote: > Well... it seems my brain can't distinguish Bookworm from Bullseye. It's not just you. The use of three "b" names in a row (buster, bullseye, bookworm) was in my opinion a poor decision. I've taken to calling the releases by their numbers (10, 11, 12) instead of their codenames to avoid confusion wherever possible.
Re: shellcheck, bashism's and one liners.
On Sun, Mar 17, 2024 at 09:25:10AM +, Tim Woodall wrote:
> I have this one-liner (which works but shellcheck doesn't like the
> quoting)
>
> idxsrc="$( newest_file $( APT_CONFIG=${APT_CONFIG} apt-get indextargets
> --format '$(FILENAME)' 'Identifier: Packages' ))"
>
> SC2016: Expressions don't expand in single quotes, use double quotes for that.
> SC2046: Quote this to prevent word splitting.
I can't say that I blame it. I don't like that quoting either.
However, the thing that *it* doesn't like isn't the same as the thing
that *I* don't like.
It's complaining about '$(FILENAME)' which is a questionable design
choice by the authors of apt-get. Not much to be done about that.
I'd complain about newest_file $(cmd) instead. It looks like you're
running a command which returns a bunch of filenames, and you want to
select one of the names from this bunch. Right?
This only works when none of the filenames contain any whitespace or
globbing characters. Otherwise, there's no way to know which sets of
characters constitute a single filename. Is "a b c d" one filename,
or two filenames, or three, or four? There's no way to tell.
> The first is easy enough to avoid by using backslash instead. But the
> second I can't see how to fix as a one-liner.
Oh, I see. It actually *did* complain about the same thing that I
complained about. I didn't understand at first that these were two
separate warnings.
> I can make shellcheck happy by doing it like this:
>
> mapfile -t idxpackages < <( APT_CONFIG=${APT_CONFIG} apt-get indextargets
> --format \$\(FILENAME\) 'Identifier: Packages' )
> idxsrc="$( newest_file "${idxpackages[@]}")"
Ah, so apt-get returns one filename per line, and you're splitting the
stream on newlines? I suppose that works well enough in practice, for
the output of apt-get. It's not too likely that any of your packages
will contain filenames with newlines in them.
In any case, this is *definitely* better than your first command, which
splits on *all* whitespace, not just newlines, and additionally performs
globbing. If we ignore the possibility of filenames with newlines,
then this fixes all of the issues I can see.
> I have a number of other places where I'm relying on a variable
> containing a number of space separated items that I DO want word
> splitting and so the shellcheck warning is incorrect and I either
> suppress it or find a fix similar to the above.
All such cases fail when one of your "words" may contain whitespace
or globbing characters.
> In almost all other cases, the space separated items cannot, even in
> theory, contain a rogue space, so suppressing the warning is fine
Famous Last Words™.
Re: shellcheck, bashism's and one liners.
On Sun, 17 Mar 2024, Geert Stappers wrote:
On Sun, Mar 17, 2024 at 09:25:10AM +, Tim Woodall wrote:
Hi,
I've been cleaning up some bash scripts
Good
and, where possible, addressing things reported by shellcheck.
Oh, shellcheck, https://www.shellcheck.net/
I have this one-liner (which works but shellcheck doesn't like the
quoting)
idxsrc="$( newest_file $( APT_CONFIG=${APT_CONFIG} apt-get indextargets --format
'$(FILENAME)' 'Identifier: Packages' ))"
SC2016: Expressions don't expand in single quotes, use double quotes for that.
SC2046: Quote this to prevent word splitting.
The first is easy enough to avoid by using backslash instead. But the
second I can't see how to fix as a one-liner.
I can make shellcheck happy by doing it like this:
mapfile -t idxpackages < <( APT_CONFIG=${APT_CONFIG} apt-get indextargets
--format \$\(FILENAME\) 'Identifier: Packages' )
idxsrc="$( newest_file "${idxpackages[@]}")"
For what it is worth:
- a shell is nice and good tool
- shellcheck is an afterthought
- my shellcheck experience learnt me that it can't see the difference
between "dangerous" and "potentionally dangerous"
Thing I'm trying to tell: Avoid that shellcheck blocks you
Oh, it's not blocking me. Where I know it's OK I've added a
# shellcheck disable=
to silence the warning.
But I've got one more case where it's *possible* that a quoting error
that shellcheck doesn't like could cause things to break.
I have an array of filenames (inc paths). These are all local files
generated by the script so they will never contain a space in the script
controlled bit. But if, for some reason, I decided to do:
mv /mnt/mirror "/mnt/m i r r o r"
then it would get very upset.
But these lists are in an associative array, so it's hard to make
shellcheck safe. I was hoping that an easy answer to my one liner would
give me a clue to this harder case.
I could write some very convoluted code, generating lists on the fly
with eval and then using namerefs in the associative array, but that
would be letting the shellcheck tail wag the scripting dog!
Re: Bookworm Fasttrack and Virtualbox
Well... it seems my brain can't distinguish Bookworm from Bullseye. Virtualbox is now installed from Fasttrack repository and is working fine. Sorry for the inconveniences
Re: shellcheck, bashism's and one liners.
On Sun, Mar 17, 2024 at 09:25:10AM +, Tim Woodall wrote:
> Hi,
>
> I've been cleaning up some bash scripts
Good
> and, where possible, addressing things reported by shellcheck.
Oh, shellcheck, https://www.shellcheck.net/
> I have this one-liner (which works but shellcheck doesn't like the
> quoting)
>
> idxsrc="$( newest_file $( APT_CONFIG=${APT_CONFIG} apt-get indextargets
> --format '$(FILENAME)' 'Identifier: Packages' ))"
>
> SC2016: Expressions don't expand in single quotes, use double quotes for that.
> SC2046: Quote this to prevent word splitting.
>
> The first is easy enough to avoid by using backslash instead. But the
> second I can't see how to fix as a one-liner.
>
> I can make shellcheck happy by doing it like this:
>
> mapfile -t idxpackages < <( APT_CONFIG=${APT_CONFIG} apt-get indextargets
> --format \$\(FILENAME\) 'Identifier: Packages' )
> idxsrc="$( newest_file "${idxpackages[@]}")"
For what it is worth:
- a shell is nice and good tool
- shellcheck is an afterthought
- my shellcheck experience learnt me that it can't see the difference
between "dangerous" and "potentionally dangerous"
Thing I'm trying to tell: Avoid that shellcheck blocks you
Groeten
Geert Stappers
--
Silence is hard to parse
Re: shellcheck, bashism's and one liners.
On Sun, Mar 17, 2024 at 09:25:10AM +, Tim Woodall wrote:
> Hi,
[...]
> Is there a one-liner way to make shellcheck happy on the count line
> below (other than # shellcheck disable=SC2046)?
>
> args() { echo a b c d; }
> count() { echo $#; }
> count $(args)
>
> Obviously, any correct solution should output 4
Hm. Another way of counting words? Would "wc" count as cheating?
If yes, in which way?
(I'm trying to get a grasp of your problem by throwing possibly
flawed solutions at it, so I won't be hurt if you say so :-)
Cheers
--
t
signature.asc
Description: PGP signature
Notificació d'incidències de Debian
Bon dia, No sóc mantenidor de cap paquet de Debian ni porto cap tema dels repositoris o distribució però, des de fa un temps (ara ja anys), de tant en tant rebo notificació de què algú ha enregistrat una proposta o error al sistema de bugs.debian.org No estic parlant tampoc d'inciències prèvies a les quals jo he participat, sinó de quan se'n creen de noves. Algú sap explicar-me el perquè? Gràcies. -- Narcis Garcia __ I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should remove and omit any @, dot and mailto combinations against automated addresses collectors.
shellcheck, bashism's and one liners.
Hi,
I've been cleaning up some bash scripts and, where possible, addressing
things reported by shellcheck.
I have this one-liner (which works but shellcheck doesn't like the
quoting)
idxsrc="$( newest_file $( APT_CONFIG=${APT_CONFIG} apt-get indextargets --format
'$(FILENAME)' 'Identifier: Packages' ))"
SC2016: Expressions don't expand in single quotes, use double quotes for that.
SC2046: Quote this to prevent word splitting.
The first is easy enough to avoid by using backslash instead. But the
second I can't see how to fix as a one-liner.
I can make shellcheck happy by doing it like this:
mapfile -t idxpackages < <( APT_CONFIG=${APT_CONFIG} apt-get indextargets
--format \$\(FILENAME\) 'Identifier: Packages' )
idxsrc="$( newest_file "${idxpackages[@]}")"
I have a number of other places where I'm relying on a variable
containing a number of space separated items that I DO want word
splitting and so the shellcheck warning is incorrect and I either
suppress it or find a fix similar to the above.
In almost all other cases, the space separated items cannot, even in
theory, contain a rogue space, so suppressing the warning is fine but
the above one could, therefore I wanted to find a proper fix.
Is there a one-liner way to make shellcheck happy on the count line
below (other than # shellcheck disable=SC2046)?
args() { echo a b c d; }
count() { echo $#; }
count $(args)
Obviously, any correct solution should output 4
Thanks.
For background, this script builds a debian image and this part of the
script checks to see if any of the packages in the minimal image have
been updated since it was built and so it needs rebuilding.
As an optimization, this script first checks the timestamp on the
Packages files that are used to build the image, if they're older than
the image then it's not possible for there to be a newer package and so
I don't need to do the checks on individual packages.
