Re: packages built with golang
Cousin Stanley wrote: > Reading this newsgroup earlier today > someone mentioned the hugo package > for static site generation. > > I was curious about the package > so I tried > > $ apt-cache show hugo ... i have been building hugo on my Debian system for quite a while now. grab the whole repository and build it. it will be more up to date. 1. git clone : 2. cd hugo 3. go install -tags extended i need the extended version but if you don't you can leave that option off. the hugo binary ends up in $HOME/go/bin if you need a specific version you can check it out before building. all those golang packages are then not needed. just the base ones are installed. ii golang-1.17-doc 1.17.8-1 all Go programming language - documentation ii golang-1.17-go 1.17.8-1 amd64Go programming language compiler, linker, compiled stdlib ii golang-1.17-src 1.17.8-1 all Go programming language - source files ii golang-go:amd64 2:1.17~1 amd64Go programming language compiler, linker, compiled stdlib ii golang-src 2:1.17~1 all Go programming language - source files songbird
Re: packages built with golang
On Mon, Mar 14, 2022 at 05:37:30PM -0700, Cousin Stanley wrote:
> David Wright wrote:
>
> > How about:
> >
> > $ apt-cache show hugo | grep -v '^Built-Using:'
> >
> > which you could wrap into a function.
> >
>
> I don't mind the Built-Using list at all
> for reasonable sized lists and I wouldn't
> care to remove it altogether.
Here's one example of a thing you could do:
apt-cache() {
command apt-cache "$@" |
awk '/^Built-Using:/ {if (length > 80) print "Built-Using: MANY THINGS";
else print; next}
1'
return "${PIPESTATUS[0]}"
}
And I found some packages to test it with:
grub-efi-amd64-signed
libguice-java
libsisu-guice-java
hugo
That was almost as tricky as writing the wrapper function.
Re : Re: Régler luminosité écran carte vidéo Intel
Bonjour, > le contraste. > Plus chaque valeur tend vers 0 plus le contraste augmente et inversement Pour du texte, le contraste est la différence entre le fond et le texte. Test pratique : Transformez une capture d'écran en noir et blanc. avec une pipette, mesurez la valeur de la couleur la plus claire et notez sa valeur mesurez la valeur de la couleur la plus sombre et notez sa valeur Si votre outil de dessin est paramétré en valeurs de 0 à 100 pour les niveaux de gris, la différence entre vos deux valeurs indiqueront le contraste. Si votre outil de dessin est paramétré en d'autres valeurs (0 à 63 ou bien 0 à 255) vous devrez faire des règles de 3 pour obtenir un pourcentage. Les valeurs de contrastes minimales ne doivent pas descendre au-dessous de 35. Mais si vous voulez intéresser les personnes ayant des difficultés à lire, ne descendez pas au dessous de 45. Bonne expérimentation Cassis - Mail d'origine - De: ajh-valmer À: pierre estrem Cc: debian-user-french@lists.debian.org Envoyé: Mon, 14 Mar 2022 15:44:40 +0100 (CET) Objet: Re: Régler luminosité écran carte vidéo Intel On Friday 11 March 2022 00:56:31 Pierre ESTREM wrote: > A mon avis c'est en baissant chaque valeur pour R, V et B qu'on change > le contraste. > Plus chaque valeur tend vers 0 plus le contraste augmente et inversement > plus elles tendent vers 255 plus on le baisse (blanc !). > $ xgamma -gamma 0.8 , brightness... : Merci pour l'aide et les fichiers envoyés, ça marche. > >> On Wednesday 09 March 2022 00:51:30 Haricophile wrote: > >> ton système fonctionne au niveau matériel-kernel-firmware. > >> Après c'est un problème logiciel : Par contre, les touches clavier du portable, F11 (luminosité -) et F12 (luminosité +), bien pratiques, ne fonctionnent pas du tout et pourquoi ? Bonne journée, André Valmer
Re: packages built with golang
David Wright wrote: > How about: > > $ apt-cache show hugo | grep -v '^Built-Using:' > > which you could wrap into a function. > I don't mind the Built-Using list at all for reasonable sized lists and I wouldn't care to remove it altogether. I can use your suggestion to remove it after I have first seen a l o n g list for a more tidy view of packages that I was not familar with. -- Stanley C. Kitching Human Being Phoenix, Arizona
Re: packages built with golang
Dan Ritter wrote: > > Not having Built-Using is just like not having dependencies. Thanks for the explanation. I can understand the need for the Built-Using list for the developers that need it. In cases such as that for the l o n g list returned for golang built packages like hugo perhaps returning a link to the required list might work avoiding what Andy Smith referred to as information overload and that would save a bit of bandwidth as a bonus since those l o n g lists go out to all readers :-) -- Stanley C. Kitching Human Being Phoenix, Arizona
Re: packages built with golang
On Mon 14 Mar 2022 at 16:33:42 (-0700), Cousin Stanley wrote: > Andy Smith wrote: > > > > So this information is needed for the developers and packagers, > > but I suppose you could argue that it is information overload > > for the casual user of "apt show". > > It seems to be information overload for me pesonally. > > Perhaps a link to the relevant golang list > using the hugo package as an example > ah lah > > Complete documentation > is available at https://gohugo.io/ > > Complete golang package used list > is available at How about: $ apt-cache show hugo | grep -v '^Built-Using:' which you could wrap into a function. Cheers, David.
Re: packages built with golang
Andy Smith wrote: > > So this information is needed for the developers and packagers, > but I suppose you could argue that it is information overload > for the casual user of "apt show". It seems to be information overload for me pesonally. Perhaps a link to the relevant golang list using the hugo package as an example ah lah Complete documentation is available at https://gohugo.io/ Complete golang package used list is available at -- Stanley C. Kitching Human Being Phoenix, Arizona
Re: got a mdadm puzzler
On Monday, 14 March 2022 17:10:10 EDT Andy Smith wrote: > Gene, > > I just don't know where to start with finding relevant bits to quote > from your text. > > I find it unlikely that several of the drives you have bought should > all be failed and dead. I'm concerned that you're prematurely > jumping to conclusions and junking them. > Plugged back in, on different cables, they are incomunicado. Smartctl sees them, and hangs the system boot when it gets no response. Only way to boot is to powerdown and remove them, them the raid10 is found and the rest of the boot is fine. And I am beginning to think in terms of a mobo problem, the bios is only seeing the cpu bus a .9 something volts, and the cpu fan at 721 rpm, but nothing else and gkrellm isn't even seeing any of that. > It's normal for the device nodes to change as you unplug and plug > drives. They will increment through the alphabet until /dev/sdz > turns into /dev/sdaa and so on. If you are referring to drives by > the device node then this will confuse you and inevitably lead to a > catastrophic error. You may be better off consistently using the > links in /dev/disk/by-id/ which will be based upon the drive serial > numbers. > > Maybe it would be best to put the 4 drives aside and try to get a > stable working system before you mess with them again. This talk of > not being able to reboot sounds like a more serious thing to get > straightened out. > > Cheers, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting > > . Thanks Andy Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: packages built with golang
Cousin Stanley wrote: > Reading this newsgroup earlier today > someone mentioned the hugo package > for static site generation. > > I was curious about the package > so I tried > > $ apt-cache show hugo > > The usual package information was returned > along with, in my opinion, an unsightly mess > entailing a long string of 88 entries > naming individual golang packages > following Built-Using: > > A simple message such as the following > might be sufficient > > Built-Using: golang , golang libraries and packages > > I have seen this with a few packages other than hugo > that were built using golang as well. Oh, no. An ordinary package is built with, say, glibc and openssl and a couple of parsers. All of them are already in Debian, so they go into the Depends categories. Each of them have their own dependencies, but you mostly don't have to install them because they are already on your system. When a Go package is built, it probably has about the same number of libraries that it depends on, but because Go is static, all of them have to be linked in to the binary that gets built and distributed. Now, when there's a problem in libfoo=2.1 which allows anyone to supply the password NSA31415926535 for authentication as root, Debian has to issue libfoo=2.2 as a security update. Every package that uses libfoo gets fixed at the same time. (Running programs may need to be restarted.) If the same problem is in go-foo, every package that was Built-Using go-foo needs to be tracked down, rebuilt, and a separate security update issued. Not having Built-Using is just like not having dependencies. -dsr-
Re: got a mdadm puzzler
Gene, I just don't know where to start with finding relevant bits to quote from your text. I find it unlikely that several of the drives you have bought should all be failed and dead. I'm concerned that you're prematurely jumping to conclusions and junking them. It's normal for the device nodes to change as you unplug and plug drives. They will increment through the alphabet until /dev/sdz turns into /dev/sdaa and so on. If you are referring to drives by the device node then this will confuse you and inevitably lead to a catastrophic error. You may be better off consistently using the links in /dev/disk/by-id/ which will be based upon the drive serial numbers. Maybe it would be best to put the 4 drives aside and try to get a stable working system before you mess with them again. This talk of not being able to reboot sounds like a more serious thing to get straightened out. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: packages built with golang
Hello, On Mon, Mar 14, 2022 at 12:53:21PM -0700, Cousin Stanley wrote: > $ apt-cache show hugo > > The usual package information was returned > along with, in my opinion, an unsightly mess > entailing a long string of 88 entries > naming individual golang packages > following Built-Using: > > A simple message such as the following > might be sufficient > > Built-Using: golang , golang libraries and packages As far as I understand it this is needed because being a static binary, the hugo package would need to be rebuilt whenever any of the go packages it depends upon is changed. So this information is needed for the developers and packagers, but I suppose you could argue that it is information overload for the casual user of "apt show". Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
packages built with golang
Reading this newsgroup earlier today someone mentioned the hugo package for static site generation. I was curious about the package so I tried $ apt-cache show hugo The usual package information was returned along with, in my opinion, an unsightly mess entailing a long string of 88 entries naming individual golang packages following Built-Using: A simple message such as the following might be sufficient Built-Using: golang , golang libraries and packages I have seen this with a few packages other than hugo that were built using golang as well. -- Stanley C. Kitching Human Being Phoenix, Arizona
Re: Wayland vs X
On Mon, Mar 14, 2022, 2:21 PM Marco Möller < ta...@debianlists.mobilxpress.net> wrote: > On 14.03.22 18:28, Anssi Saari wrote: > > Marco Möller writes: > > > >> I am not sure if I understood your answer. Is it a suggestion of what > >> should be of importance, or is it the confirmation that Wayland is > >> capable to configure clipboard access restrictive like this? > > > > Um, I thought a question mark is a fairly common indication of a > > question? I asked a question. > > Ah, now I understood. Well, then I try to answer to my best knowledge > assuming that my knowledge is not outdated. I am not a developer and > only repeat what I found stated by others, again not having a reference > but am citing from memory: > > > On 14.03.22 16:23, Anssi Saari wrote: > > Nicholas Geovanis writes: > > > >> Isn't it all about X by design to not be able to safely protect a > >> running X applications to snoop on other running X applications, > >> something like the content of a window cannot safely kept private? > > > > Well, what about something basic like allowing only specific apps to > > read the clipboard? Or maybe just the app that has focus, sort of like > > Android does it. > > > Wayland does not provide clipboard access restrictions out of the box. > But Wayland, other than X, makes it possible that restrictions like this > could be implemented! > I'm being misquoted, it wasn't actually me :-) Not a big deal. As Marco points out, there is no reason that actions at the window level could not be individually restricted. Modified windowing systems were doing that in secure computing in the early 1990s at least. Even restricted at the level of granularity of SElinux-style Mandatory Access Control. My comment is that one of the strengths of X Windows was the view of the graphics workstation as the server, but each application a client somewhere on the network, maybe local to the X server also. Diskless X workstations then implemented X servers partially in firmware (sometimes), tossing away local execution. No problem, in my experience. But has Wayland tossed out the functional separation between the X server hardware (in your box) and the OS? So that it can be closer to the graphics card? XFree86 did that if I'm not mistaken. Is that still necessary for performance or graphics compatibility reasons? The implementation would have to take place at the level of the > compositor, which is kind of the equivalent of the X Server. Brilliant. Exactly my point. As there > could be developed quite different compositors for Wayland, it thus will > > > Regards, Marco. >
Re: Wayland vs X
On 14.03.22 18:28, Anssi Saari wrote: Marco Möller writes: I am not sure if I understood your answer. Is it a suggestion of what should be of importance, or is it the confirmation that Wayland is capable to configure clipboard access restrictive like this? Um, I thought a question mark is a fairly common indication of a question? I asked a question. Ah, now I understood. Well, then I try to answer to my best knowledge assuming that my knowledge is not outdated. I am not a developer and only repeat what I found stated by others, again not having a reference but am citing from memory: On 14.03.22 16:23, Anssi Saari wrote: > Nicholas Geovanis writes: > >> Isn't it all about X by design to not be able to safely protect a >> running X applications to snoop on other running X applications, >> something like the content of a window cannot safely kept private? > > Well, what about something basic like allowing only specific apps to > read the clipboard? Or maybe just the app that has focus, sort of like > Android does it. Wayland does not provide clipboard access restrictions out of the box. But Wayland, other than X, makes it possible that restrictions like this could be implemented! The implementation would have to take place at the level of the compositor, which is kind of the equivalent of the X Server. As there could be developed quite different compositors for Wayland, it thus will depend on the particular compositor in use, if and which security rules are finally available. In some more or less popular library, making available to developers of compositors some basic functionality, it is implemented the restriction, that only an app in the foreground can write to the clipboard, and only an app in the foreground can read from it. This should help that a third party hidden in the background can not interfere with the clipboard while the users copies something from app A to app B by switching between exactly these two apps. Better than nothing! But this library has not implemented further treatment of the clipboard following further rules. For instance it would depend on an app, if it removes the content from the clipboard after having received it. Thus, if the user doesn't delete the clipboard right away, then a formerly hidden app C becoming a foreground app could read it. And alike, if the user would not switch directly from A to B, but my mistake brings to the foreground app C before having pasted to app B and deleted the clipboard content, then app C could have overwritten the clipboard without the user having noticed it. Now, which compositor is using this library with at least this foreground-app-only access rule being implemented, and which compositor is using a different implementation, and how do the individual apps finally make use of their right to read/write the clipboard when in the foreground? This are many unanswered questions. There is certainly a need of improvement. But at least, if someone would like to contribute more sophisticated access control functionality, then, other than X, this, as far as I remember, would be possible in Wayland. Regards, Marco.
Re: adding trouble on the trouble (using apt upgrade)
ps: sorry, on a Debian Sid system for sure. Le lun. 14 mars 2022 à 19:41, Patrice Duroux a écrit : > > Hi, > > Since some versions ago, apt/dpkg(?) is stopping its process (upgrade > here) whatever the packaging trouble it is facing. But in some cases, it > may leave the system more broken than it would become just by 'skipping' > the troubling package. > For instance, in the upgrading transaction list were some ldap related > packages that were left not working, mainly the sudo-ldap in my case was > not functional before completing the process by 'apt -f install' or 'dpkg > --configure --pending'. But for that I normally use sudo. By chance I can > use 'su -' ;-) > > I suspect that I am not the only one to face such a situation. > Is it something expected with new dpkg versions? Or is this already the > subject of a bug report or have to be reported to dpkg? > > Regards, > Patrice > > [...] > Dépaquetage de xserver-xorg-input-wacom (1.0.0-1) sur (0.34.99.1-1+b1) ... > Préparation du dépaquetage de .../106-gnupg-utils_2.2.27-3+b1_amd64.deb ... > Dépaquetage de gnupg-utils (2.2.27-3+b1) sur (2.2.27-3) ... > Des erreurs ont été rencontrées pendant l'exécution : > /tmp/apt-dpkg-install-wr0Tro/051-nodejs_12.22.10~dfsg-1_amd64.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) >
adding trouble on the trouble (using apt upgrade)
Hi, Since some versions ago, apt/dpkg(?) is stopping its process (upgrade here) whatever the packaging trouble it is facing. But in some cases, it may leave the system more broken than it would become just by 'skipping' the troubling package. For instance, in the upgrading transaction list were some ldap related packages that were left not working, mainly the sudo-ldap in my case was not functional before completing the process by 'apt -f install' or 'dpkg --configure --pending'. But for that I normally use sudo. By chance I can use 'su -' ;-) I suspect that I am not the only one to face such a situation. Is it something expected with new dpkg versions? Or is this already the subject of a bug report or have to be reported to dpkg? Regards, Patrice [...] Dépaquetage de xserver-xorg-input-wacom (1.0.0-1) sur (0.34.99.1-1+b1) ... Préparation du dépaquetage de .../106-gnupg-utils_2.2.27-3+b1_amd64.deb ... Dépaquetage de gnupg-utils (2.2.27-3+b1) sur (2.2.27-3) ... Des erreurs ont été rencontrées pendant l'exécution : /tmp/apt-dpkg-install-wr0Tro/051-nodejs_12.22.10~dfsg-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
Re: Comment recharger un module noyau planté ?
Bonjour, Au vu du kern.log, j'ai l'impression que c'est la carte wifi qui plante et non le module : Mar 10 10:14:13 dell kernel: [146989.982839] ath10k_pci :02:00.0: failed to wake target for write32 of 0x0579 at 0x0003543c: -110 [plein de failed to wake target] Mar 10 10:17:23 dell kernel: [147179.685280] ath10k_pci :02:00.0: failed to wake target for read32 at 0x0003a028: -110 Mar 10 10:17:26 dell kernel: [147182.767232] ath10k_pci :02:00.0: failed to read device register, device is gone Mar 10 10:17:26 dell kernel: [147182.768293] ieee80211 phy0: Hardware restart was requested Je tenterais une réinitialisation au niveau du bus PCI (remove et rescan) : echo 1 > /sys/bus/pci/devices/\:02\:00.0/remove echo 1 > /sys/bus/pci/rescan Chez moi ça donne ça dans le kern.log : Mar 14 19:09:05 W520 kernel: [3050195.682506] pci :03:00.0: [8086:0085] type 00 class 0x028000 Mar 14 19:09:05 W520 kernel: [3050195.682577] pci :03:00.0: reg 0x10: [mem 0xd520-0xd5201fff 64bit] Mar 14 19:09:05 W520 kernel: [3050195.682836] pci :03:00.0: PME# supported from D0 D3hot D3cold Mar 14 19:09:05 W520 kernel: [3050195.683162] pci :03:00.0: BAR 0: assigned [mem 0xd520-0xd5201fff 64bit] Mar 14 19:09:05 W520 kernel: [3050195.683313] iwlwifi :03:00.0: can't disable ASPM; OS doesn't have ASPM control Mar 14 19:09:05 W520 kernel: [3050195.683936] iwlwifi :03:00.0: firmware: direct-loading firmware iwlwifi-6000g2a-6.ucode Mar 14 19:09:05 W520 kernel: [3050195.684130] iwlwifi :03:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm Mar 14 19:09:05 W520 kernel: [3050195.684146] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUG disabled Mar 14 19:09:05 W520 kernel: [3050195.684147] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled Mar 14 19:09:05 W520 kernel: [3050195.684148] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled Mar 14 19:09:05 W520 kernel: [3050195.684150] iwlwifi :03:00.0: Detected Intel(R) Centrino(R) Advanced-N 6205 AGN, REV=0xB0 Mar 14 19:09:05 W520 kernel: [3050195.712640] ieee80211 phy6: Selected rate control algorithm 'iwl-agn-rs' Mar 14 19:09:05 W520 kernel: [3050195.723818] iwlwifi :03:00.0 wlp3s0: renamed from wlan0 @+ Hugues --- Original Message --- Le samedi 12 mars 2022 à 19:19, didier gaumet a écrit : > Le samedi 12 mars 2022 à 11:58 +0100, Daniel Caillibaud a écrit : > > > Le 12/03/22 à 09:50, didier gaumet didier.gau...@gmail.com a écrit > > > > Oui, j'ai > > > > lsmod|grep ath > > > > ath10k_pci 49152 0 > > > > ath10k_core 430080 1 ath10k_pci > > > > ath 36864 1 ath10k_core > > > > mac80211 1077248 1 ath10k_core > > > > cfg80211 1052672 3 ath,mac80211,ath10k_core > > > > modinfo me dit aussi pour ath10k_pci > > > > depends: ath10k_core > > > > (qui lui ne dépend de personne) > > [...] > > un modinfo ath10k_core confirme les lignes ci-dessus: > > ath10k_core dépend des modules mac80211,cfg80211,ath > > Si tu forces le déchargement du module ath10k_pci, il faut peut-être > > aussi (à confirmer) que tu forces le déchargement des modules > > ath10_core et ath, voire même (ça me paraît moins probable vu ton > > message d'erreur, mais bon...) de mac80211 et cfg80211 publickey - hlarrive@pm.me - 0xE9429B87.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Wayland vs X
Marco Möller writes: > I am not sure if I understood your answer. Is it a suggestion of what > should be of importance, or is it the confirmation that Wayland is > capable to configure clipboard access restrictive like this? Um, I thought a question mark is a fairly common indication of a question? I asked a question.
Re: Wayland vs X
On 14.03.22 16:23, Anssi Saari wrote: Nicholas Geovanis writes: Isn't it all about X by design to not be able to safely protect a running X applications to snoop on other running X applications, something like the content of a window cannot safely kept private? Well, what about something basic like allowing only specific apps to read the clipboard? Or maybe just the app that has focus, sort of like Android does it. I am not sure if I understood your answer. Is it a suggestion of what should be of importance, or is it the confirmation that Wayland is capable to configure clipboard access restrictive like this? Regards, Marco!
Re: Wayland vs X
Nicholas Geovanis writes: > Isn't it all about X by design to not be able to safely protect a > running X applications to snoop on other running X applications, > something like the content of a window cannot safely kept private? Well, what about something basic like allowing only specific apps to read the clipboard? Or maybe just the app that has focus, sort of like Android does it.
Re: Régler luminosité écran carte vidéo Intel
On Friday 11 March 2022 00:56:31 Pierre ESTREM wrote: > A mon avis c'est en baissant chaque valeur pour R, V et B qu'on change > le contraste. > Plus chaque valeur tend vers 0 plus le contraste augmente et inversement > plus elles tendent vers 255 plus on le baisse (blanc !). > $ xgamma -gamma 0.8 , brightness... : Merci pour l'aide et les fichiers envoyés, ça marche. > >> On Wednesday 09 March 2022 00:51:30 Haricophile wrote: > >> ton système fonctionne au niveau matériel-kernel-firmware. > >> Après c'est un problème logiciel : Par contre, les touches clavier du portable, F11 (luminosité -) et F12 (luminosité +), bien pratiques, ne fonctionnent pas du tout et pourquoi ? Bonne journée, André Valmer
Re: iwd + systemd-networkd + resolvconf wrinkles
David Wright wrote: I was casting round for a simple way to run iwd + resolvconf + systemd-networkd as replacement. I run a similar setup, with iwd, systemd-networkd and systemd-resolved. This has been working without problems on my host for for quite a while now. Make a copy of your /etc/resolv.conf file, then enable and restart the systemd-resolved service. Finally link the /etc/resolv.conf file to either /run/systemd/resolve/resolv.conf or /run/systemd/resolve/stub-resolv.conf. I use the latter: # ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 37 Jun 28 2020 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf You can configure various settings for the DNS resolver in your systemd-networkd setting and in /etc/systemd/resolved.conf. On bookworm you also have the resolvectl tool, which helps debugging DNS issues. Thomas
