Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
On Mon, Dec 11, 2023 at 04:31:22AM +0100, Stella Ashburne wrote: > Hi Michael > > > Sent: Sunday, December 10, 2023 at 9:29 PM > > From: "Michael Kjörling" <2695bd53d...@ewoof.net> > > To: debian-user@lists.debian.org > > Subject: Re: Need clarifications about how to deal with the installed > > problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) > > > > > > This combination is expected under the circumstances, assuming that > > you mean /etc/debian_version. Booting into a different kernel does not > > change the files installed by the base-files package, which is where > > /etc/debian_version comes from; if you want to, you can verify this > > with dpkg -S /etc/debian_version. > > > Someone on a social media platform stated that there are only two "canonical" > [sic] ways to verify the version of Debian installed on a system. They are: > > uname -a > As you will have discovered this weekend - that one tells you which kernel you're running, not which Debian version per se. > /proc/version > Likewise. > Do you agree with the above statement? > > > > > > > > Question #2b > > > > > > Suppose I need to re-install linux-image-6.1.0-13-amd64 but some users > > > told me that it is no longer in the repos. > > > > > > I can just download it manually by using the following link: > > > > > > https://packages.debian.org/bookworm/amd64/linux-image-6.1.0-13-amd64/download > > > > > > And then in a terminal, I type the commands: > > > > > > sudo dpkg -i linux-image-6.1.0-13-amd64 > > > > > > sudo update-grub > > > > > > sudo shutdown -r now > > > > > > Is the above the correct way to install kernels that are not in the > > > official repos? > > > > Not quite, because dpkg -i wants a file path, not a package name > > (that's for apt/apt-get). Also dpkg won't automatically pull in any > > dependencies that may have been uninstalled after the upgrade, or > > necessarily handle any DKMS modules that would need to be recompiled > > for the older kernel version, so you'd need to take care with those. > > Could you help me to understand what you meant when you wrote: "Not quite, > because dpkg -i wants a file path, not a package name" please? > > Please allow me to give you an example of how I use dpkg on a regular basis. > dpkg is low level: it will work to install one .deb, usually this has to be one in the same directory. Apt will install more than one because it also keeps tabs on dependencies. > The version of OpenVPN software in the official Debian repos is lamentably > outdated. It has version 2.6.3-1+deb12u2 whereas the official community > version by OpenVPN Inc. has version 2.6.8 (By the way, Fedora users are lucky > because David S., one of the developers of OpenVPN, is personally maintaining > OpenVPN in Fedora's official repos; meaning, the version in Fedora's repos is > in sync with the official OpenVPN's version.) > > Whenever OpenVPN's developers release an update for OpenVPN, they will also > publish the corresponding version for Debian users. > Please ask OpenVPN to set up an apt repository :) > Below are the URLs for the latest version (2.6.8): > > https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn/openvpn_2.6.8-bookworm0_amd64.deb > > https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn/openvpn-dbgsym_2.6.8-bookworm0_amd64.deb > > https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn-dco-dkms/openvpn-dco-dkms_0.2.20231117-bookworm0_all.deb > > This is how I install the latest version of OpenVPN on my Debian Bookworm: > > 1. sudo apt remove openvpn > > **Sometimes I sudo apt purge openvpn instead of sudo apt remove openvpn in > order to remove the configuration files** > > 2. sudo dpkg -i openvpn_2.6.8-bookworm0_amd64.deb > > 3. sudo shutdown -r now > > Based on your statement, what file path should I supply to dpkg? > > > Someone on the Fediverse posted an apt preferences recipe to block the > > broken kernel package from installation. I haven't tested it, but it > > looks reasonable: > > > > > create a file: > > > > > > /etc/apt/preferences.d/buggy-kernel > > > > > > with the contents: > > > # avoid kernel with ext4 bug > > > # 1057843 > > > Package: linux-image-* > > > Pin: version 6.1.64-1 > > > Pin-Priority: -1 > > > > Copied from https://octodon.social/@alienghic/111552556796482609 > > > Thanks, Michael for your tip. > > But I find the following command to be much simpler to use: > > sudo apt-mark hold linux-image-amd64 > > Said command achieves the same goal, yes? > > Best wishes. > > Stella >
Release process notes [WAS Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]
On Mon, Dec 11, 2023 at 03:32:55AM +0100, Stella Ashburne wrote: > Hi Greg > > > Sent: Sunday, December 10, 2023 at 11:08 PM > > From: "Greg Wooledge" > > To: debian-user@lists.debian.org > > Subject: Re: Need clarifications about how to deal with the installed > > problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) > > > > > > Note that purging 6.1.0-14 will also remove the linux-image-amd64 > > metapackage, which has a hard dependency on it (at the moment). > > What is/was the hard dependency? > linux-image-[foo]-amd64 always points to the latest available kernel image for amd64 (and the same for other architectures). It's a metapackage that pulls in other packages When you first install, I suspect it's that package that makes sure your kernel version is up to date. When you update between point releases likewise. Hard removing the latest kernel _and_ the metapackage prevents you from updating to the buggy kernel but you have to do some tidying up afterwards. :) > > Only if you reinstall the kernel metapackage as soon as you notice that > > there's been another point release. > > > > This is not a criticism of Andrew's post. I'm just reminding everyone, > > including myself, that we're going to have to remember to do this extra > > step. > > > As of writing this reply, there's a new point release, 12.4.0 > > What if I don't reinstall the kernel's metapackage as soon as there's a new > point release? Or if I forget to reinstall it? > If you don't reinstall it, then the metapackage won't be there. I installed it as soon as the point release was being published before the install images were out. [Sequence: release team publish the packages - and they can get put out to mirrors, daily updates etc. Images team build and test media to check that there's no regressions. Images get published and pushed. Formal release notification goes out. 12.3 was stopped as image releases were being tested and the release team had to replace the buggy kernel, make a decision as to where to put the fix, run through the whole process. Images release team then had to build and test the media - which always takes a few hours more. "Release" varies which way you look at it] This time round the main release team had to effectively do two point releases in very quick succession and the images team did two full sets of testing > Thanks for your clarification. > > Best wishes. > > Stella > Andy (amaca...@debian.org)
Re: 6.1.0-15/6.1.66-1 broken too?
Hello everybody I can confirm the same problems. At first I thought the network problem was due to proprietary Broadcom driver because network connectivity was the most obvious problem. However, most problems persisted after removing the driver. I do not have any other proprietary or custom kernel modules. My hardware is a 2014 Macbook Pro (Intel CPU and graphics). Regards Stephan signature.asc Description: This is a digitally signed message part
Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
Hi Greg > Sent: Monday, December 11, 2023 at 11:27 AM > From: "Greg Wooledge" > To: debian-user@lists.debian.org > Subject: Re: Need clarifications about how to deal with the installed > problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) > > > Well, the question is what you want. *snip* *snip* > Or use other solutions, for other desired outcomes. > Thanks for your detailed explanation. I learnt some new stuff today. Best wishes. Stella
Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
On Mon, Dec 11, 2023 at 04:31:22AM +0100, Stella Ashburne wrote: > Someone on a social media platform stated that there are only two "canonical" > [sic] ways to verify the version of Debian installed on a system. They are: > > uname -a > > /proc/version > > Do you agree with the above statement? The second one isn't even a command. Neither one of them tells you what version of Debian is installed, even if you fix the second one. All these tell you is which kernel is running. It's completely possible, and supported, to run a Debian system with a custom kernel that you built yourself, in which case the kernel version revealed by these commands tells you nothing about which OS is running on top of that kernel. To see the version of Debian, the correct command is: cat /etc/debian_version This works for any *release* version of Debian. It will not differentiate among various pre-releases, including testing and unstable. For those, you'll need to go deeper. "apt policy" and "cat /etc/apt/sources.list" and "tail -n+1 /etc/apt/sources.list.d/*" would be good starts for that.
Re: Debian 12.3 image release delayed
> Sent: Monday, December 11, 2023 at 11:05 AM > From: "Yves Bellefeuille" > To: debian-user@lists.debian.org > Subject: Re: Debian 12.3 image release delayed > > Is the problem solved? Is it safe to upgrade? According to Steve McIntyre, it is. Click the following link to read his announcement: https://lists.debian.org/debian-user/2023/12/msg00593.html As for me, I won't be upgrading to the latest kernel just yet because a user, Kevin Price, reported problems with the latest kernel version (cf. https://lists.debian.org/debian-user/2023/12/msg00570.html) Best wishes. Stella
Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
Hi Michael > Sent: Sunday, December 10, 2023 at 9:29 PM > From: "Michael Kjörling" <2695bd53d...@ewoof.net> > To: debian-user@lists.debian.org > Subject: Re: Need clarifications about how to deal with the installed > problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) > > > This combination is expected under the circumstances, assuming that > you mean /etc/debian_version. Booting into a different kernel does not > change the files installed by the base-files package, which is where > /etc/debian_version comes from; if you want to, you can verify this > with dpkg -S /etc/debian_version. > Someone on a social media platform stated that there are only two "canonical" [sic] ways to verify the version of Debian installed on a system. They are: uname -a /proc/version Do you agree with the above statement? > > > > Question #2b > > > > Suppose I need to re-install linux-image-6.1.0-13-amd64 but some users told > > me that it is no longer in the repos. > > > > I can just download it manually by using the following link: > > > > https://packages.debian.org/bookworm/amd64/linux-image-6.1.0-13-amd64/download > > > > And then in a terminal, I type the commands: > > > > sudo dpkg -i linux-image-6.1.0-13-amd64 > > > > sudo update-grub > > > > sudo shutdown -r now > > > > Is the above the correct way to install kernels that are not in the > > official repos? > > Not quite, because dpkg -i wants a file path, not a package name > (that's for apt/apt-get). Also dpkg won't automatically pull in any > dependencies that may have been uninstalled after the upgrade, or > necessarily handle any DKMS modules that would need to be recompiled > for the older kernel version, so you'd need to take care with those. Could you help me to understand what you meant when you wrote: "Not quite, because dpkg -i wants a file path, not a package name" please? Please allow me to give you an example of how I use dpkg on a regular basis. The version of OpenVPN software in the official Debian repos is lamentably outdated. It has version 2.6.3-1+deb12u2 whereas the official community version by OpenVPN Inc. has version 2.6.8 (By the way, Fedora users are lucky because David S., one of the developers of OpenVPN, is personally maintaining OpenVPN in Fedora's official repos; meaning, the version in Fedora's repos is in sync with the official OpenVPN's version.) Whenever OpenVPN's developers release an update for OpenVPN, they will also publish the corresponding version for Debian users. Below are the URLs for the latest version (2.6.8): https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn/openvpn_2.6.8-bookworm0_amd64.deb https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn/openvpn-dbgsym_2.6.8-bookworm0_amd64.deb https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn-dco-dkms/openvpn-dco-dkms_0.2.20231117-bookworm0_all.deb This is how I install the latest version of OpenVPN on my Debian Bookworm: 1. sudo apt remove openvpn **Sometimes I sudo apt purge openvpn instead of sudo apt remove openvpn in order to remove the configuration files** 2. sudo dpkg -i openvpn_2.6.8-bookworm0_amd64.deb 3. sudo shutdown -r now Based on your statement, what file path should I supply to dpkg? > Someone on the Fediverse posted an apt preferences recipe to block the > broken kernel package from installation. I haven't tested it, but it > looks reasonable: > > > create a file: > > > > /etc/apt/preferences.d/buggy-kernel > > > > with the contents: > > # avoid kernel with ext4 bug > > # 1057843 > > Package: linux-image-* > > Pin: version 6.1.64-1 > > Pin-Priority: -1 > > Copied from https://octodon.social/@alienghic/111552556796482609 > Thanks, Michael for your tip. But I find the following command to be much simpler to use: sudo apt-mark hold linux-image-amd64 Said command achieves the same goal, yes? Best wishes. Stella
Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...
On Mon, Dec 11, 2023 at 02:53:07AM +, Albretch Mueller wrote:
> echo "abc123" > file.txt
> ftype=$(file --brief file.txt)
> echo "// __ \$ftype: |${ftype}|"
> ftypelen=${#ftype}
> echo "// __ \$ftypelen: |${ftypelen}|"
>
> # removing spaces ...
> ftype2=$(echo "${ftype}" | tr --complement --squeeze-repeats
> '[A-Za-z0-9.]' '_');
> echo "// __ \$ftype2: |${ftype2}|"
> ftype2len=${#ftype2}
> echo "// __ \$ftype2len: |${ftype2len}|"
Please tell us:
* What you are trying to do.
* What you did (is the previous code all in a script? if so, this is a
good answer for this part).
* What result you got.
* What you expected to get.
Re: Debian 12.3 image release delayed
I was expecting a follow-up to yesterday's announcement that the 12.3 image had a data corruption bug. Is the problem solved? Is it safe to upgrade? -- Yves Bellefeuille
Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
On Mon, Dec 11, 2023 at 03:26:16AM +0100, Stella Ashburne wrote: > What command did you use? Was it > > sudo dpkg -i linux-image-amd64_6.1.55-1_amd64.deb Yes. On Mon, Dec 11, 2023 at 03:32:55AM +0100, Stella Ashburne wrote: > As of writing this reply, there's a new point release, 12.4.0 > > What if I don't reinstall the kernel's metapackage as soon as there's a new > point release? Or if I forget to reinstall it? Well, the question is what you want. If you want to use the new point release, then you can simply do "apt update", "apt install linux-image-amd64" and "apt upgrade" or whatever you would normally do. That would get you back to normal, on the new point release. If you want to stick with the 6.1.0-13 kernel for a little while, but use the point release for the other packages, then you can leave the linux-image-amd64 package removed for now. Whenever you're ready to try the new kernel, install linux-image-amd64 at that time. If you want to stick with 6.1.0-13, but use the point release for other stuff, but you're afraid you'll forget to reinstall linux-image-amd64, then you could install the old version of it (as I did), but DO NOT use "apt upgrade", as that pulls in new packages. Use "apt-get upgrade" instead, and you won't get any new packages, including kernels with new ABI version numbers. Or use other solutions, for other desired outcomes.
why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...
echo "abc123" > file.txt
ftype=$(file --brief file.txt)
echo "// __ \$ftype: |${ftype}|"
ftypelen=${#ftype}
echo "// __ \$ftypelen: |${ftypelen}|"
# removing spaces ...
ftype2=$(echo "${ftype}" | tr --complement --squeeze-repeats
'[A-Za-z0-9.]' '_');
echo "// __ \$ftype2: |${ftype2}|"
ftype2len=${#ftype2}
echo "// __ \$ftype2len: |${ftype2len}|"
lbrtchx
Re: Unattended Upgrades Ran Anyway.
On 11/12/2023 06:12, Charles Curley wrote: Sorry. I had already stopped the apt-daily-upgrade.timer, which triggers the unattended upgrade service. (The couldn't give them similar names to act as a mnemonic?) This refers to disabling the unattended upgrade service. I have not tested it, but from unit and scripts content my impression is that apt-daily-upgrade.service may apply security updates even when the unattended-upgrades package is not installed. Despite apt-daily-upgrade.timer is enabled out of the box, without unattended-upgrades, the service does nothing in default configuration. There are apt.conf settings to enable/diable upgrades. As to "systemctl mask UNIT.service", the valid use case is suppressing a service that may be activated through D-Bus. The price is noise in logs on each attempt to invoke a D-Bus method. I am unsure if D-Bus specs allows to hide a D-Bus .service file (do not confuse with systemd services) installed by some package. Usually it is enough to "systemdctl disable --now UNIT" for a .timer or a .socket that may cause activation of the service. I assume unit dependencies and preventing accidental start from command line are rather specific use cases.
Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
Hi Greg > Sent: Sunday, December 10, 2023 at 11:08 PM > From: "Greg Wooledge" > To: debian-user@lists.debian.org > Subject: Re: Need clarifications about how to deal with the installed > problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) > > > Note that purging 6.1.0-14 will also remove the linux-image-amd64 > metapackage, which has a hard dependency on it (at the moment). What is/was the hard dependency? > Only if you reinstall the kernel metapackage as soon as you notice that > there's been another point release. > > This is not a criticism of Andrew's post. I'm just reminding everyone, > including myself, that we're going to have to remember to do this extra > step. As of writing this reply, there's a new point release, 12.4.0 What if I don't reinstall the kernel's metapackage as soon as there's a new point release? Or if I forget to reinstall it? Thanks for your clarification. Best wishes. Stella
Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
Hi Greg > Sent: Monday, December 11, 2023 at 2:06 AM > From: "Greg Wooledge" > To: debian-user@lists.debian.org > Subject: Re: Need clarifications about how to deal with the installed > problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) > > > In order to avoid having to remember to re-install the metapackage at a > future date, I've installed the prior version from snapshot: > > http://snapshot.debian.org/archive/debian/20231002T025920Z/pool/main/l/linux-signed-amd64/linux-image-amd64_6.1.55-1_amd64.deb > What command did you use? Was it sudo dpkg -i linux-image-amd64_6.1.55-1_amd64.deb
Re: 12.4.0 point release published
Hi guys > Sent: Monday, December 11, 2023 at 9:17 AM > From: "Steve McIntyre" <93...@debian.org> > To: debian-user@lists.debian.org > Subject: 12.4.0 point release published > > Hi folks, > > The new 12.4.0 point release is now out. It contains the needed fixes > for the ext4 data corruption bug (https://bugs.debian.org/1057843). Thanks for your update. However, as of writing this reply, your news hasn't been posted on micronews.debian.org > It's now safe to upgrade as normal, panic over. No thanks as I've yet to get over the shock of having installed the buggy linux-image-6.1.0-14-amd64. Perhaps a week from now? > Many thanks to all the people who spent all of their weekend making > this happen... Totally agreed. To all the awesome people who sacrificed their time to making it happen, many thanks!! Best wishes. Stella
Re: Image handling in mutt
wrote: > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote: >> wrote: there is rarely a need to e-mail me directly. >> ... >> > That's why I cringe when people name executables "foo.sh". What do you >> > do when you decide to rewrite the thing in C (or Rust, or whatever)? >> > >> > Do you go over all calling sites and change the caller's code? >> >> no, i would just consider it a transition or a change >> in versions. :) > > Again. You have one script, say /usr/local/bin/ring-the-bells.sh > You use it in several other scripts. If you now re-implement it > in your favourite Pascal as ring-the-bells.pas or something, you > go over all your executables and fix that? > > IMO an executable name should indicate /what/ an executable does, > not /how/. i'm fine with that, but i'm also capable enough to know how to search through a code base to find all the strings i might need to change. i just scanned a few of my projects and noted i do not use the .sh extension much at all for the binaries/executables, but parts of the code may have that extension. >> i was always glad when people wrote descriptive names >> for their programs instead of "f" or "f(x)". > > This is something totally different. Call the function by > what it does, but -- again -- not by how. :) >> since my first major programs were written in Assembler >> Pascal and C whatever extensions needed for those were >> used, i didn't see it as any fault. > > It is your prerogative, of course. I'm happy that ls is ls > and git, git (not ls.i-was-implemented-in-c or something). sure. songbird
12.4.0 point release published
Hi folks, The new 12.4.0 point release is now out. It contains the needed fixes for the ext4 data corruption bug (https://bugs.debian.org/1057843). It's now safe to upgrade as normal, panic over. Many thanks to all the people who spent all of their weekend making this happen... -- Steve McIntyre, Cambridge, UK Debian images team
Re: Unattended Upgrades Ran Anyway.
Dan Ritter wrote: > Stefan Monnier wrote: >> On my trusty Thinkpad X30, upgrades are sufficiently taxing that having >> them run unexpectedly can be a real problem, so I tried to prevent >> unattended upgrades a few months ago. > > > I have always preferred the apticron package, which by default > updates daily and sends an email letting me know that they are > available, rather than doing the upgrade itself. as everyone can have their own reasons for what they are doing i would not expect anyone else to do what i am but since we're on the topic. :) i do not run auto updates of any kind for Debian (for either testing or stable or any other instances i may have set up). currently i don't have any oddities out there running. instead, each morning i cold start my computer (i prefer it being off when i am not using it) and it boots into testing i drag in my new e-mails and usenet group posts and then fire up the update of the indexes for the various Debian package repositories it needs. after the update finishes then i check to see what kind of updates are there. some days i scan the list and just pull it all and apply them, other days i will hold certain packages because i don't want to deal with it that day. i run a few packages from sid/unstable but they usually are self-contained enough that i don't worry about it. songbird
Re: Image handling in mutt
> Finally, occasionally I need to cleanly dump html, this one seems a bit > simpler: > > text/html; lynx -stdin -dump -width=$COLS; copiousoutput; compose=vim %s I meant "cleanly _view_ html ..."
Re: Synaptic Problem
On 12/10/23 15:48, Stephen P. Molnar wrote: On 12/10/2023 01:22 PM, gene heskett wrote: On 12/10/23 10:47, Stephen P. Molnar wrote: I have just reinstalled Bookworm. Unfortunately, when I tru tto use synaptic I get the following error: E: The package brscan4 needs to be reinstalled, but I can't find an archive for it. E: Internal error opening cache (1). Please report. Unfortunately, Google has not been of any help. A solution to the problem would be appreciated. Tanks in advance. A solution may already exist on your machine if it knows about brscan. Brother has a deb containing their smartinstaller as a bash script, named in my case "linux-brprinter-installer-2.2.1-1" or your can get the latest version from brothers sites, visit with firefox. Unpack it, run it from a cli, it asks for the model number string of the printer or scanner, goes to brother'sown linux repo and downloads the latest version available for that device and installs and configures it to Just Work with cups IF you have removed cups-browsed thereby disallowing cups from setting up the default printer driver which cannot drive the printer in anything but waste paper mode. Brothers own drivers support every feature the printer has, accessible from the web interface cups serves at localhost:631. Despite the poor publicity I've seen about factory drivers, brothers drivers for linux work 100% here. Linux support is excellent for their products. Cheers, Gene Heskett. Gene Thank you for your encouraging reply. I have the Brother MCF-L2710DW Laser printer and am very pleased with it. I followed your directions and ran: sudo bash linux-brprinter-installer-2.2.3-1 Here are the CUPS results: Description:MFCL2710DW Location: Driver: Brother MFCL2710DW for CUPS (grayscale, 2-sided printing) Connection: dnssd://Brother%20MFC-L2710DW%20series._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-b42200417fc9 Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided I ran "Prnt Test Page" anmd got: Description:MFCL2710DW Location: Driver: Brother MFCL2710DW for CUPS (grayscale, 2-sided printing) Connection: dnssd://Brother%20MFC-L2710DW%20series._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-b42200417fc9 Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided Well since you specced A4 paper, did you have A4 paper in the tray? and of course, did it work? You may need to goto locolhost:631 with your browser and configure the options to suit your environment. Also, that uuid is unique to that printer, so it must be correct. else you'd collect a no such device error. An ls of /dev/serial/by-id might serve as a checking src. klipper, the better 3d printer driver, uses that to make sure its driving the right printer since usb has rather poor id mechanisms. from my printers output: root@mkspi:~# ls -l /dev/serial/by-id total 0 lrwxrwxrwx 1 root root 13 Dec 3 01:17 usb-Klipper_rp2040_E5D94D950DCD5658-if00 -> ../../ttyACM0 the E5D9. is a unique to that chip serial number, no other rp2040 has it. So do all the stm32 controller chips. Unforch that is not always true, as witnessed by this machine: gene@coyote:~/src/klipper-docs$ ls -l /dev/serial/by-id total 0 lrwxrwxrwx 1 root root 13 Dec 7 11:39 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB1 lrwxrwxrwx 1 root root 13 Dec 7 11:39 usb-FTDI_USB_HS_SERIAL_CONVERTER_FTDHG45D-if00-port0 -> ../../ttyUSB0 where there aren't any chip serial numbers, but cups seems to have other ways of assuring its driving the correct device as a printer. One of those is actually driving a CM11A X10 home controller. Probably more info than you need if the test page worked, -- Stephen P. Molnar, Ph.D. https://insilicochemistry.net (614)312-7528 (c) Skype: smolnar1 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: Unattended Upgrades Ran Anyway.
On Sun, 10 Dec 2023 17:27:39 -0500 Greg Wooledge wrote: > > > > Thanks. I will disable as well. > > Disable *what*? Disabling a .service unit which is triggered by a > timer event isn't going to stop it from running. Sorry. I had already stopped the apt-daily-upgrade.timer, which triggers the unattended upgrade service. (The couldn't give them similar names to act as a mnemonic?) This refers to disabling the unattended upgrade service. > > *Masking* a .service would prevent it from running when requested by a > timer event. > > Apart from that, you'd have to remove the timer event. However you do > that. I've never used systemd timers yet. I *think* that's got it. Now to be sure I remember all this when it comes time to allow automatic upgrades again. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Image handling in mutt
> Second, how do I fix this so that mutt uses feh to display images? Here is my mailcap entry, which works for me - had to deal with annoying filename munging by mutt, and getting the "close the viewer" bit working - this is quite a few years ago and now I can't even remember why the ; test=test -n "$DISPLAY" or the sleep are needed, but they were - heuristics annoy, but sometimes they are necessary: image/*; (mv %s %s-\; feh -Z %s-\; rm -f %s-)& sleep 0.2s; test=test -n "$DISPLAY" Similarly my mailcap entry for pdf files: application/pdf; (mv %s %s-.pdf\; evince %s-.pdf 2\>\&1 \; rm -f %s-.pdf)& sleep 0.2s; test=test -n "$DISPLAY" image/pdf; /usr/bin/display-im6 %s; test=test -n "$DISPLAY" Finally, occasionally I need to cleanly dump html, this one seems a bit simpler: text/html; lynx -stdin -dump -width=$COLS; copiousoutput; compose=vim %s
Re: Backup système
Bonsoir, Alex PADOLY a écrit : > Je recherche donc un outil qui privilégie, la fiabilité de la > sauvegarde, la simplicité, la prise en charge du MBR et donc de GRUB > et bien entendu la restauration. Ayant lu cette phrase, je vais me permettre de ne pas répondre à la question et d'interroger le besoin. Si vous souhaitez sauvegarder le MBR et tutti quanti, c'est que vous souhaitez faire une image du disque, et non sauvegarder le système. Or, de manière générale, faire une image du disque me semble être la plus mauvaise des solutions. Certes, en sauvegardant l'image du disque, vous sauvegardez tout, donc vous n'oubliez rien. Mais vous sauvegardez l'utile, comme l'inutile, les données comme ce qui n'en est pas. Ce faisant, la sauvegarde va surconsommer de l'espace disque sur le système de sauvegarde. Elle va être bien plus longue qu'une sauvegarde intelligente de plus haut niveau qui, en ayant une compréhension de ce qu'elle sauvegarde, pourrait être sélective et optimiser le processus. Du coup, pourquoi vouloir agir à si bas niveau ? Le seul cas de figure où un « ghost » me semble pertinent est celui de l'administration d'un parc de machines semblables, sur lesquelles on souhaite pouvoir (ré)installer un système à l'identique à partir de l'image du disque de la première machine installée. Dans ce cas, on peut même décider de restaurer périodiquement le système, même en l'absence de problème déclaré, pour nettoyer le système de potentielles scories ou cochonneries laissées par les utilisateurs précédents. Mais les gens qui adoptent cette approche ne le font pas de manière récurrente. Et du coup, soit ils ne souhaitent sauvegarder ni le dernier état du système, ni les éventuelles données enregistrées par les utilisateurs, soit ces données sont sauvegardées d'une autre manière (et le ghost ne traite alors pas le problème le plus essentiel qui est la sauvegarde des données). Je comprends bien que la restauration « bête et méchante » d'une image disque est plus rapide que la réinstallation classique d'un système, même automatisée. Mais en revanche, la copie du disque ne peut se faire qu'à froid. Elle nécessite l'arrêt de la machine. Cela me semble un peu « lourdingue » et pas automatisable du tout. À titre personnel, même si la restauration (évènement exceptionnel) prend plus de temps, je préfère au quotidien disposer d'un système de sauvegarde : * efficace et performant, qui ne sauvegarde que ce qui doit l'être ; * dédupliquant les données, afin d'optimiser la sauvegarde en temps et en disque ; * me permettant d'effectuer des restauration sélectives (besoin le plus courant dans la pratique) ; * ne nécessitant pas l'arrêt du système et affecte le moins possible le fonctionnement des services (même si l'arrêt des services le temps de sauvegarder les données associées peut être nécessaire dans certains cas pour assure l'intégrité de ces données) ; * qui me permette d'avoir un long historique de sauvegarde ; * qui chiffre mes données ; * qui est automatisable. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: 6.1.0-15/6.1.66-1 broken too?
I confirm that 6.1.66-1 (6.1.0-15) severely breaks my amd64/bookworm/gnome physical machine, which runs fine with 6.1.52-1 and 6.1.55-1. Am 10.12.23 um 20:24 schrieb Andrew M.A. Cater: > On Sun, Dec 10, 2023 at 08:02:03PM +0100, Kevin Price wrote: >> Am 09.12.23 um 19:09 schrieb Dan Ritter: >>> The new kernel release is reported to contain an ext4 data >>> corruption bug. It's prudent not to upgrade, or if you have >>> started to upgrade, not to reboot, until a new kernel release >>> is prepared. >> >> Thanks for your announcement. I'm running out of time to properly report >> a bug against 6.1.66-1. >> >> #1057843 states that it's fixed with 6.1.0-15/6.1.66-1. This I highly >> doubt. I handpicked that version from >> https://deb.debian.org/debian/pool/main/l/ , and installed the 6.1.66-1 >> packages[1]. That was totally messed up and made my amd64 system highly >> unresponsive and erratic to the point it would hang shutting down. So I >> booted back into 6.1.0-13, which still works fine, and purged 6.1.0-14 >> and 6.1.0-15, and IOT have two working options, I reinstalled 6.0.1-12, >> which had been autoremoved with the update. >> >> [1] Packages I used: >> >> [src:linux] >> linux-compiler-gcc-12-x86_6.1.55-1_amd64.deb >> linux-headers-6.1.0-13-amd64_6.1.55-1_amd64.deb >> linux-headers-6.1.0-13-common_6.1.55-1_all.deb >> linux-kbuild-6.1_6.1.55-1_amd64.deb >> linux-libc-dev_6.1.55-1_amd64.deb >> >> [src:linux-signed-amd64] >> linux-headers-amd64_6.1.55-1_amd64.deb (optional meta-pkg) >> linux-image-6.1.0-13-amd64_6.1.55-1_amd64.deb >> linux-image-amd64_6.1.55-1_amd64.deb (optional meta-pkg) >> >> Other versions I tried: >> 6.1.0-12/6.1.52-1 works >> 6.1.0-13/6.1.55-1 works >> 6.1.0-14/6.1.64-1 broken, according to #1057843 >> 6.1.0-15/6.1.66-1 broken as experienced >> >> For now, I've purged the broken ones, and put the working ones on hold >> with dpkg. >> >> Any ideas? >> -- >> Kevin Price >> > > If you hand-picked packages: I would suggest using apt to upgrade the whole > system . Done that, now that 6.1.0-15/6.1.66-1 is available through apt. > Kevin: Do you have any logs to show brokenness? Which ones? > For what it's worth, > there were other updates and fixes besides just #1057843 in the new > release. Some of that must be the culprit, breaking my system. What happens, at a first glance: 1. Bootup to the gdm greeter works, but there I get an unusal keyboard layout. And everything takes longer. 2. There seems to be no network connectivity. (no WiFi icon) 3. Launching Firefox apparently does nothing. 4. Launching gnome-teminal works, but many commands just stall, such as "sudo dmesg" or "ip a". 5. Shutting down takes ages, with systemd waiting for a bunch of services to terminate, most of which seem to be network-related. After much more that 10 min I used hard power-off. I'm uncertain whether such an unstable system is even capable of going through the reportbug script. Any ideas, which logfiles might be useful to debug this issue, and whom to address this to, IOT to prevent similar experiences from many more users? Also what kind of testing could I usefully perform? Any kernel parameters maybe? -- Kevin Price
Re: Unattended Upgrades Ran Anyway.
On Sun, Dec 10, 2023 at 02:10:43PM -0700, Charles Curley wrote: > On Sun, 10 Dec 2023 14:51:48 -0600 > David Wright wrote: > > > I think it might be worth googling and reading "three levels of off" > > (with the quotes). > > > > 1. You can stop a service. That simply terminates the running > > instance of the service and does little else. If due to some form > > of activation (such as manual activation, socket activation, bus > > activation, activation by system boot or activation by hardware > > plug) the service is requested again afterwards it will be > > started. Stopping a service is hence a very simple, temporary and > > superficial operation. > > Thanks. I will disable as well. Disable *what*? Disabling a .service unit which is triggered by a timer event isn't going to stop it from running. *Masking* a .service would prevent it from running when requested by a timer event. Apart from that, you'd have to remove the timer event. However you do that. I've never used systemd timers yet.
Re: IMPORTANT: do NOT upgrade to new stable point release
On Sun, Dec 10, 2023 at 02:27:38PM -0700, Charles Curley wrote: > On Sat, 9 Dec 2023 13:09:23 -0500 > Dan Ritter wrote: > > > https://fulda.social/@Ganneff/111551628003050712 > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843 > > > > The new kernel release is reported to contain an ext4 data > > corruption bug. It's prudent not to upgrade, or if you have > > started to upgrade, not to reboot, until a new kernel release > > is prepared. > > > > > > -dsr- > > > > It appears the new, repaired, kernel and minor version of Bookworm have > landed. Now, who wants to live dangerously? :-) > > root@tiassa:~# apt update > Get:1 http://security.debian.org/debian-security bookworm-security InRelease > [48.0 kB] > Get:2 http://deb.debian.org/debian bookworm InRelease [151 kB] > Get:3 http://deb.debian.org/debian bookworm/main amd64 Packages [8,787 kB] > Get:4 http://deb.debian.org/debian bookworm/main Translation-en [6,109 kB] > Fetched 15.1 MB in 3s (4,432 kB/s) > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > 38 packages can be upgraded. Run 'apt list --upgradable' to see them. > N: Repository 'http://deb.debian.org/debian bookworm InRelease' changed its > 'Version' value from '12.3' to '12.4' > root@tiassa:~# apt list --upgradable > Listing... Done > … > libudev1/stable 252.19-1~deb12u1 amd64 [upgradable from: 252.17-1~deb12u1] > linux-image-amd64/stable 6.1.66-1 amd64 [upgradable from: 6.1.55-1] > linux-libc-dev/stable 6.1.66-1 amd64 [upgradable from: 6.1.55-1] > … > root@tiassa:~# > > > -- > Does anybody read signatures any more? > > https://charlescurley.com > https://charlescurley.com/blog/ > I'd suggest apt-get update ; apt-get dist-upgrade or equivalent. There were a few other bug fixes as well in this point release but I think you've got the three major packages that changed. Base files also changed, obviously :) All the very best, as ever, Andy
Re: IMPORTANT: do NOT upgrade to new stable point release
On Sat, 9 Dec 2023 13:09:23 -0500 Dan Ritter wrote: > https://fulda.social/@Ganneff/111551628003050712 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843 > > The new kernel release is reported to contain an ext4 data > corruption bug. It's prudent not to upgrade, or if you have > started to upgrade, not to reboot, until a new kernel release > is prepared. > > > -dsr- > It appears the new, repaired, kernel and minor version of Bookworm have landed. Now, who wants to live dangerously? :-) root@tiassa:~# apt update Get:1 http://security.debian.org/debian-security bookworm-security InRelease [48.0 kB] Get:2 http://deb.debian.org/debian bookworm InRelease [151 kB] Get:3 http://deb.debian.org/debian bookworm/main amd64 Packages [8,787 kB] Get:4 http://deb.debian.org/debian bookworm/main Translation-en [6,109 kB] Fetched 15.1 MB in 3s (4,432 kB/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done 38 packages can be upgraded. Run 'apt list --upgradable' to see them. N: Repository 'http://deb.debian.org/debian bookworm InRelease' changed its 'Version' value from '12.3' to '12.4' root@tiassa:~# apt list --upgradable Listing... Done … libudev1/stable 252.19-1~deb12u1 amd64 [upgradable from: 252.17-1~deb12u1] linux-image-amd64/stable 6.1.66-1 amd64 [upgradable from: 6.1.55-1] linux-libc-dev/stable 6.1.66-1 amd64 [upgradable from: 6.1.55-1] … root@tiassa:~# -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Unattended Upgrades Ran Anyway.
On Sun, 10 Dec 2023 14:51:48 -0600 David Wright wrote: > I think it might be worth googling and reading "three levels of off" > (with the quotes). > > 1. You can stop a service. That simply terminates the running > instance of the service and does little else. If due to some form > of activation (such as manual activation, socket activation, bus > activation, activation by system boot or activation by hardware > plug) the service is requested again afterwards it will be > started. Stopping a service is hence a very simple, temporary and > superficial operation. Thanks. I will disable as well. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Unattended Upgrades Ran Anyway.
Stefan Monnier wrote: > On my trusty Thinkpad X30, upgrades are sufficiently taxing that having > them run unexpectedly can be a real problem, so I tried to prevent > unattended upgrades a few months ago. I have always preferred the apticron package, which by default updates daily and sends an email letting me know that they are available, rather than doing the upgrade itself. -dsr-
Re: [accessibility@ Orca cause trop
Bonjour,
j'apporte juste une correction. pour ouvrir les préférences spécifiques
à une applications, on utilise le raccourcis ctrl + orca + espace et non
maj + orca + espace.
Jerem
Le 10/12/2023 à 06:38, Jean-Philippe MENGUAL a écrit :
Bonjour Pierre,
Ce genre de question n'est jamais très somple, parce que c'est souvent
un compromis à trouver entre trop ou pas assez bavard. Dans les
préférences, onglet Synthèse vocale, tu peux demander à Orca de ne
lire que le texte affiché, si vraiment tu n'as jamais besoin
d'entendre la description des éléments à l'écran. L'expression "auto
complétion" est en eeffet la description que fait le lecteur d'écran
de la zone où se trouve ton curseur. Tout comme Bouton, case à cocher,
liste déroulante, etc
Dans ce même onglet et alternativement à ce qui précède, tu peux aussi
décocher Lire la description, u bien Annoncer les champs de formulaire.
Si toutefois tu veux restreindre ce comportement (s'il fonctionne) à
Thunderbird, il te faudra utiliser orca+maj+espace pour le faire dans
les préférences d'Orca spécifiques à Thunderbird, tandis que
orca+espace est global.
Espérant que cela aidera,
Cordialement,
Jean-Philippe MENGUAL
Debian Developer non uploading
Community team member
Accessibility team member
debian-l10n-french team member
President of Debian France non-profit organization
Le 10/12/2023 à 04:43, Pierre ESTREm a écrit :
Bonsoir la liste,
J'utilise Orca et avec Thunderbird je ne voudrais ne plus entendre
"auto completion" une fois arrivé dans la zone de saisie du sujet
(lors de la création d'un message).
Je crois l'entendre aussi dans bien d'autres occasions.
Je pense qu'il s'agit d'un message du système car la chaîne
n'apparaît pas suite à "Sujet" .
Ca expliquerait que modifier la prononciation dans les Préférences
de Orca ne donne rien ("auto-completion" => "").
Auriez-vous une méthode pour éviter ces lectures (que je juge
inutiles) ?
Remarque: cette chaîne devrait être cependant prononcée si elle
apparaissait à l'écran !
pierre estrem
Re: Unattended Upgrades Ran Anyway.
On Sun 10 Dec 2023 at 13:39:50 (-0700), Charles Curley wrote: > On Sun, 10 Dec 2023 14:17:36 -0600 > David Wright wrote: > > > Why is the service loaded, enabled and enabled then? Don't you need > > to disable or mask it? Presumably it sits there, dead, all day > > normally, and pops up at an appropriate time. > > As I understand things, start and stop are for immediate changes. > enable and disable are for boot time. So the service is turned off > until I either start it up again manually or reboot the computer. > > Then there's masking, which is a whole nother can of lawyers. And a > slew of other states. See Table 1. is-enabled output, in man systemctl. I think it might be worth googling and reading "three levels of off" (with the quotes). 1. You can stop a service. That simply terminates the running instance of the service and does little else. If due to some form of activation (such as manual activation, socket activation, bus activation, activation by system boot or activation by hardware plug) the service is requested again afterwards it will be started. Stopping a service is hence a very simple, temporary and superficial operation. Cheers, David.
Re: Image handling in mutt
Sent from my iPad > On Dec 10, 2023, at 3:05 PM, David Wright wrote: > > On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote: >>> On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote: >>> On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote: I'm on Debian bookworm, using neomutt for email. Where there is an image to view, viewing it in neomutt calls up one of the ImageMagick programs. I've set the mailcap_path variable in my neomutt config to point to ~/.mailcap, > > Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is > a specially crafted subset of /etc/mailcap with a few additions > (like converting webp to a jpeg rather than opening in gimp, > and playing midi files the way I want). > and set an entry in there for image/jpg to point to /usr/bin/feh. I've even set >>> ↑↑↑ try jpeg >>> the "display" alternative to feh with update-alternatives. Still, mutt is calling an imagemagick program to display jpgs. First, if alternatives doesn't point to the imagemagick program, and the mailcap file doesn't point to it, and there's nothing in the neomutt config pointing to the imagemagick program, then where the heck is it getting that as the program to use to display images? > > An email would contain headers with the attachment. > >↓ > Content-Type: image/jpeg > Content-Disposition: attachment; filename="don.jpg" > Content-Transfer-Encoding: base64 > > By default, mutt searches six directories for a mailcap file. When > found, the line in the mailcap starting with image/jpeg selects the > program to run. > > If you see an extension in a mailcap field like nametemplate=%s.jpg > that's to show that a filename matching that pattern should be given > to a copy of the attachment to satisfy the program that's going to > read it. But it's the attachment /content type/ that selects the > program, not the extension¹. > Second, how do I fix this so that mutt uses feh to display images? >> >> I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and >> the files I was looking at had a "jpg" extension. >> >> But thanks for the tip. > > A couple of programs in my /etc/mailcap (gpicview and gm) have > image/jpg lines, duplicating the image/jpeg entries, perhaps > as a "catch-all" for malformed emails containing image/jpg. > I don't know whether image/jpg is an official legacy type/iana-token. > > ¹ Re the argument raging in this thread about "extension", the > term is clearly appropriate, as a glance at /etc/mime.types > demonstrates. The literature is full of the term. > > I wouldn't want to use "suffix" myself, as it's too general: > anything stuck on the end is a suffix, but not necessarily > a filename extension. Suffixes are used for other purposes. Suffix is the correct term. File names in Linux are a character string of 255 chars. Again there are not file extensions in a Linux file name. People are conflating the issue. Read the code, code good. > > Cheers, > David. >
Re: Synaptic Problem
On 12/10/2023 01:22 PM, gene heskett wrote: On 12/10/23 10:47, Stephen P. Molnar wrote: I have just reinstalled Bookworm. Unfortunately, when I tru tto use synaptic I get the following error: E: The package brscan4 needs to be reinstalled, but I can't find an archive for it. E: Internal error opening cache (1). Please report. Unfortunately, Google has not been of any help. A solution to the problem would be appreciated. Tanks in advance. A solution may already exist on your machine if it knows about brscan. Brother has a deb containing their smartinstaller as a bash script, named in my case "linux-brprinter-installer-2.2.1-1" or your can get the latest version from brothers sites, visit with firefox. Unpack it, run it from a cli, it asks for the model number string of the printer or scanner, goes to brother'sown linux repo and downloads the latest version available for that device and installs and configures it to Just Work with cups IF you have removed cups-browsed thereby disallowing cups from setting up the default printer driver which cannot drive the printer in anything but waste paper mode. Brothers own drivers support every feature the printer has, accessible from the web interface cups serves at localhost:631. Despite the poor publicity I've seen about factory drivers, brothers drivers for linux work 100% here. Linux support is excellent for their products. Cheers, Gene Heskett. Gene Thank you for your encouraging reply. I have the Brother MCF-L2710DW Laser printer and am very pleased with it. I followed your directions and ran: sudo bash linux-brprinter-installer-2.2.3-1 Here are the CUPS results: Description:MFCL2710DW Location: Driver: Brother MFCL2710DW for CUPS (grayscale, 2-sided printing) Connection: dnssd://Brother%20MFC-L2710DW%20series._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-b42200417fc9 Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided I ran "Prnt Test Page" anmd got: Description:MFCL2710DW Location: Driver: Brother MFCL2710DW for CUPS (grayscale, 2-sided printing) Connection: dnssd://Brother%20MFC-L2710DW%20series._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-b42200417fc9 Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided -- Stephen P. Molnar, Ph.D. https://insilicochemistry.net (614)312-7528 (c) Skype: smolnar1
Re: Unattended Upgrades Ran Anyway.
On Sun, 10 Dec 2023 14:17:36 -0600 David Wright wrote: > Why is the service loaded, enabled and enabled then? Don't you need > to disable or mask it? Presumably it sits there, dead, all day > normally, and pops up at an appropriate time. As I understand things, start and stop are for immediate changes. enable and disable are for boot time. So the service is turned off until I either start it up again manually or reboot the computer. Then there's masking, which is a whole nother can of lawyers. And a slew of other states. See Table 1. is-enabled output, in man systemctl. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Unattended Upgrades Ran Anyway.
On Sun 10 Dec 2023 at 11:00:37 (-0700), Charles Curley wrote: > On Sun, 10 Dec 2023 16:11:44 + > Michael Kjörling <2695bd53d...@ewoof.net> wrote: > > > On 10 Dec 2023 08:49 -0700, from charlescur...@charlescurley.com > > (Charles Curley): [...] > > > > Exactly how did you "shut down" unattended-upgrades? > > > > root@chaffee:/etc/dhcp# systemctl stop unattended-upgrades.service > root@chaffee:/etc/dhcp# systemctl status unattended-upgrades.service > ● unattended-upgrades.service - Unattended Upgrades Shutdown > Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; > enabled; vendor preset: enabled) > Active: inactive (dead) since Sat 2023-12-09 19:06:51 MST; 6s ago >Docs: man:unattended-upgrade(8) > Process: 540 > ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown > --wait-for-signal (code=exited, status=0/SUCCESS) >Main PID: 540 (code=exited, status=0/SUCCESS) > CPU: 1.661s > > Oct 09 02:02:20 chaffee systemd[1]: Started Unattended Upgrades Shutdown. > Dec 09 19:06:42 chaffee systemd[1]: Stopping Unattended Upgrades Shutdown... > Dec 09 19:06:51 chaffee systemd[1]: unattended-upgrades.service: Succeeded. > Dec 09 19:06:51 chaffee systemd[1]: Stopped Unattended Upgrades Shutdown. > Dec 09 19:06:51 chaffee systemd[1]: unattended-upgrades.service: Consumed > 1.661s CPU time. > root@chaffee:/etc/dhcp# Why is the service loaded, enabled and enabled then? Don't you need to disable or mask it? Presumably it sits there, dead, all day normally, and pops up at an appropriate time. Cheers, David.
Re: Image handling in mutt
On Sun 10 Dec 2023 at 19:48:29 (+0100), to...@tuxteam.de wrote: > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote: > > wrote: > > ... > > > That's why I cringe when people name executables "foo.sh". What do you > > > do when you decide to rewrite the thing in C (or Rust, or whatever)? > > > > > > Do you go over all calling sites and change the caller's code? > > > > no, i would just consider it a transition or a change > > in versions. :) > > Again. You have one script, say /usr/local/bin/ring-the-bells.sh > You use it in several other scripts. If you now re-implement it > in your favourite Pascal as ring-the-bells.pas or something, you > go over all your executables and fix that? I've done that sort of thing, generally between bash and python. It's so simple to implement with a symlink, ring-the-bells, that points to the preferred version. But there's some topic drift here. Most people are emailing documents rather than executables most of the time. Should I assume this disapproval of metadata in the filename doesn't apply to them? > IMO an executable name should indicate /what/ an executable does, > not /how/. AIUI executables fall into a different class, as the kernel can recognise them by their magic number and take account of that. You can't do that with the metadata inside, say, a PDF. Cheers, David.
Re: Image handling in mutt
On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote: > On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote: > > On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote: > > > > > > I'm on Debian bookworm, using neomutt for email. Where there is an image > > > to > > > view, viewing it in neomutt calls up one of the ImageMagick programs. > > > I've set > > > the mailcap_path variable in my neomutt config to point to ~/.mailcap, Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is a specially crafted subset of /etc/mailcap with a few additions (like converting webp to a jpeg rather than opening in gimp, and playing midi files the way I want). > > > and > > > set an entry in there for image/jpg to point to /usr/bin/feh. I've even > > > set > > ↑↑↑ try jpeg > > > > > the "display" alternative to feh with update-alternatives. Still, mutt is > > > calling an imagemagick program to display jpgs. > > > > > > First, if alternatives doesn't point to the imagemagick program, and the > > > mailcap file doesn't point to it, and there's nothing in the neomutt > > > config > > > pointing to the imagemagick program, then where the heck is it getting > > > that > > > as the program to use to display images? An email would contain headers with the attachment. ↓ Content-Type: image/jpeg Content-Disposition: attachment; filename="don.jpg" Content-Transfer-Encoding: base64 By default, mutt searches six directories for a mailcap file. When found, the line in the mailcap starting with image/jpeg selects the program to run. If you see an extension in a mailcap field like nametemplate=%s.jpg that's to show that a filename matching that pattern should be given to a copy of the attachment to satisfy the program that's going to read it. But it's the attachment /content type/ that selects the program, not the extension¹. > > > Second, how do I fix this so that mutt uses feh to display images? > > I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and > the files I was looking at had a "jpg" extension. > > But thanks for the tip. A couple of programs in my /etc/mailcap (gpicview and gm) have image/jpg lines, duplicating the image/jpeg entries, perhaps as a "catch-all" for malformed emails containing image/jpg. I don't know whether image/jpg is an official legacy type/iana-token. ¹ Re the argument raging in this thread about "extension", the term is clearly appropriate, as a glance at /etc/mime.types demonstrates. The literature is full of the term. I wouldn't want to use "suffix" myself, as it's too general: anything stuck on the end is a suffix, but not necessarily a filename extension. Suffixes are used for other purposes. Cheers, David.
Please don't clutter list
Please start new threads when sidelining into silly arguments. The "IMPORTANT: do NOT upgrade" thread is getting cluttered with useless junk making it hard to determine the current status of the problem. Also, use a new thread, don't just change the subject line. Some threading mail readers follow the "References" headers still creating confusion. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone
Re: IMPORTANT: do NOT upgrade to new stable point release
On Sun, Dec 10, 2023 at 01:36:52PM -0600, Nicholas Geovanis wrote: > On Sun, Dec 10, 2023, 12:47 PM Curt wrote: [...] > > It is the notion of simultaneity itself (the now of now) that is > > relative rather than universal. > > > > I thought metaphysics was off-topic for this group. Moderators!! :-) Hold on. Since Einstein this is plain old boring physics ;-P Cheers -- t signature.asc Description: PGP signature
Re: IMPORTANT: do NOT upgrade to new stable point release
On Sun, Dec 10, 2023, 12:47 PM Curt wrote: > On 2023-12-10, Gary Dale wrote: > > > > On 2023-12-10 12:24, Greg Wooledge wrote: > >> On Sun, Dec 10, 2023 at 05:09:15PM -, Curt wrote: > >>> On 2023-12-10, Andrew M.A. Cater wrote: > "Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023 > >>> You mean in the Zulu Time Zone (as I am all at sea)? > >> Use "date -u" to see current UTC time. That should be sufficient to > >> let you know how long it has been since Andrew's "now". > >> > > You're getting too complicated. The date stamp on his e-mail will > > display the correct local time (as you have set it) so I can see that he > > wrote it 30 minutes ago. That relative time is universal across time > zones. > > > > > > It is the notion of simultaneity itself (the now of now) that is > relative rather than universal. > I thought metaphysics was off-topic for this group. Moderators!! :-) >
Re: 6.1.0-15/6.1.66-1 broken too?
On Sun, Dec 10, 2023 at 08:02:03PM +0100, Kevin Price wrote: > Am 09.12.23 um 19:09 schrieb Dan Ritter: > > The new kernel release is reported to contain an ext4 data > > corruption bug. It's prudent not to upgrade, or if you have > > started to upgrade, not to reboot, until a new kernel release > > is prepared. > > Thanks for your announcement. I'm running out of time to properly report > a bug against 6.1.66-1. > > #1057843 states that it's fixed with 6.1.0-15/6.1.66-1. This I highly > doubt. I handpicked that version from > https://deb.debian.org/debian/pool/main/l/ , and installed the 6.1.66-1 > packages[1]. That was totally messed up and made my amd64 system highly > unresponsive and erratic to the point it would hang shutting down. So I > booted back into 6.1.0-13, which still works fine, and purged 6.1.0-14 > and 6.1.0-15, and IOT have two working options, I reinstalled 6.0.1-12, > which had been autoremoved with the update. > > [1] Packages I used: > > [src:linux] > linux-compiler-gcc-12-x86_6.1.55-1_amd64.deb > linux-headers-6.1.0-13-amd64_6.1.55-1_amd64.deb > linux-headers-6.1.0-13-common_6.1.55-1_all.deb > linux-kbuild-6.1_6.1.55-1_amd64.deb > linux-libc-dev_6.1.55-1_amd64.deb > > [src:linux-signed-amd64] > linux-headers-amd64_6.1.55-1_amd64.deb (optional meta-pkg) > linux-image-6.1.0-13-amd64_6.1.55-1_amd64.deb > linux-image-amd64_6.1.55-1_amd64.deb (optional meta-pkg) > > Other versions I tried: > 6.1.0-12/6.1.52-1 works > 6.1.0-13/6.1.55-1 works > 6.1.0-14/6.1.64-1 broken, according to #1057843 > 6.1.0-15/6.1.66-1 broken as experienced > > For now, I've purged the broken ones, and put the working ones on hold > with dpkg. > > Any ideas? > -- > Kevin Price > If you hand-picked packages: I would suggest using apt to upgrade the whole system . For anybody who followed my initially erroneous advice to remove linux-image-amd64 - installing that package should pull in 6.1.0-15 correctly as a dependency. Kevin: Do you have any logs to show brokenness? For what it's worth, there were other updates and fixes besides just #1057843 in the new release. With every good wish, as ever, Andy [amaca...@debian.org]
6.1.0-15/6.1.66-1 broken too?
Am 09.12.23 um 19:09 schrieb Dan Ritter: > The new kernel release is reported to contain an ext4 data > corruption bug. It's prudent not to upgrade, or if you have > started to upgrade, not to reboot, until a new kernel release > is prepared. Thanks for your announcement. I'm running out of time to properly report a bug against 6.1.66-1. #1057843 states that it's fixed with 6.1.0-15/6.1.66-1. This I highly doubt. I handpicked that version from https://deb.debian.org/debian/pool/main/l/ , and installed the 6.1.66-1 packages[1]. That was totally messed up and made my amd64 system highly unresponsive and erratic to the point it would hang shutting down. So I booted back into 6.1.0-13, which still works fine, and purged 6.1.0-14 and 6.1.0-15, and IOT have two working options, I reinstalled 6.0.1-12, which had been autoremoved with the update. [1] Packages I used: [src:linux] linux-compiler-gcc-12-x86_6.1.55-1_amd64.deb linux-headers-6.1.0-13-amd64_6.1.55-1_amd64.deb linux-headers-6.1.0-13-common_6.1.55-1_all.deb linux-kbuild-6.1_6.1.55-1_amd64.deb linux-libc-dev_6.1.55-1_amd64.deb [src:linux-signed-amd64] linux-headers-amd64_6.1.55-1_amd64.deb (optional meta-pkg) linux-image-6.1.0-13-amd64_6.1.55-1_amd64.deb linux-image-amd64_6.1.55-1_amd64.deb (optional meta-pkg) Other versions I tried: 6.1.0-12/6.1.52-1 works 6.1.0-13/6.1.55-1 works 6.1.0-14/6.1.64-1 broken, according to #1057843 6.1.0-15/6.1.66-1 broken as experienced For now, I've purged the broken ones, and put the working ones on hold with dpkg. Any ideas? -- Kevin Price
Re: Image handling in mutt
On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote: > wrote: > ... > > That's why I cringe when people name executables "foo.sh". What do you > > do when you decide to rewrite the thing in C (or Rust, or whatever)? > > > > Do you go over all calling sites and change the caller's code? > > no, i would just consider it a transition or a change > in versions. :) Again. You have one script, say /usr/local/bin/ring-the-bells.sh You use it in several other scripts. If you now re-implement it in your favourite Pascal as ring-the-bells.pas or something, you go over all your executables and fix that? IMO an executable name should indicate /what/ an executable does, not /how/. > i was always glad when people wrote descriptive names > for their programs instead of "f" or "f(x)". This is something totally different. Call the function by what it does, but -- again -- not by how. > since my first major programs were written in Assembler > Pascal and C whatever extensions needed for those were > used, i didn't see it as any fault. It is your prerogative, of course. I'm happy that ls is ls and git, git (not ls.i-was-implemented-in-c or something). Cheers -- t signature.asc Description: PGP signature
Re: IMPORTANT: do NOT upgrade to new stable point release
On 2023-12-10, Gary Dale wrote: > > On 2023-12-10 12:24, Greg Wooledge wrote: >> On Sun, Dec 10, 2023 at 05:09:15PM -, Curt wrote: >>> On 2023-12-10, Andrew M.A. Cater wrote: "Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023 >>> You mean in the Zulu Time Zone (as I am all at sea)? >> Use "date -u" to see current UTC time. That should be sufficient to >> let you know how long it has been since Andrew's "now". >> > You're getting too complicated. The date stamp on his e-mail will > display the correct local time (as you have set it) so I can see that he > wrote it 30 minutes ago. That relative time is universal across time zones. > > It is the notion of simultaneity itself (the now of now) that is relative rather than universal.
Re: Image handling in mutt
wrote: ... > That's why I cringe when people name executables "foo.sh". What do you > do when you decide to rewrite the thing in C (or Rust, or whatever)? > > Do you go over all calling sites and change the caller's code? no, i would just consider it a transition or a change in versions. :) i was always glad when people wrote descriptive names for their programs instead of "f" or "f(x)". since my first major programs were written in Assembler Pascal and C whatever extensions needed for those were used, i didn't see it as any fault. songbird
Re: IMPORTANT: do NOT upgrade to new stable point release
On 2023-12-10 11:56, Andrew M.A. Cater wrote: On Sun, Dec 10, 2023 at 11:50:18AM -0500, Gary Dale wrote: On 2023-12-09 14:18, Michael Kjörling wrote: On 9 Dec 2023 20:54 +0200, from ale...@nanoid.net (Alexis Grigoriou): I just upgraded to Bookworm this morning. I did reboot a couple of times but there seems to be no problem (yet). Is there anything I should look for or do other than rebooting? If you upgraded this morning, then I would expect that you are okay for now. Per #5 in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843 the bug is present in kernel Debian package version 6.1.64-1. If you are on 6.1.55-1 (current Bookworm stable per last night) you _likely_ aren't affected. If you are on 6.1.55-1 (or earlier), just hold off on upgrades for now; and if you need to upgrade something else, take great care for now to ensure that no Linux kernel packages get upgraded to any version < 6.1.66, and preferably not < 6.1.66-1. For versions, check: * uname -v * dpkg -l linux-image-\* In that bug report thread, #21 lists 6.1.66 as fixed upstream, and #28 indicates that 6.1.66-1 includes the fix from upstream, and that it is being published. Any idea when the fixed version will hit stable? With headless servers, it's a pain to downgrade to a previous kernel version. Give them a little while: release team are working on it right now as I type I'm fairly sure they're pushing it out more or less immediately once they're sure that it's built correctly and synced to all the appropriate places to be further synced to mirrors "Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023 Andy (amaca...@debian.org) Thanks. I logged into each of my headless servers and removed the problematic kernel then rebooted them so they are all at 6.1.0-13 now.
Re: Synaptic Problem
On 12/10/23 10:47, Stephen P. Molnar wrote: I have just reinstalled Bookworm. Unfortunately, when I tru tto use synaptic I get the following error: E: The package brscan4 needs to be reinstalled, but I can't find an archive for it. E: Internal error opening cache (1). Please report. Unfortunately, Google has not been of any help. A solution to the problem would be appreciated. Tanks in advance. A solution may already exist on your machine if it knows about brscan. Brother has a deb containing their smartinstaller as a bash script, named in my case "linux-brprinter-installer-2.2.1-1" or your can get the latest version from brothers sites, visit with firefox. Unpack it, run it from a cli, it asks for the model number string of the printer or scanner, goes to brother'sown linux repo and downloads the latest version available for that device and installs and configures it to Just Work with cups IF you have removed cups-browsed thereby disallowing cups from setting up the default printer driver which cannot drive the printer in anything but waste paper mode. Brothers own drivers support every feature the printer has, accessible from the web interface cups serves at localhost:631. Despite the poor publicity I've seen about factory drivers, brothers drivers for linux work 100% here. Linux support is excellent for their products. 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: Unattended Upgrades Ran Anyway.
On Sun, 10 Dec 2023 23:59:04 +0700 Max Nikulin wrote: > On 10/12/2023 22:49, Charles Curley wrote: > [...] > > systemctl status apt-daily-upgrade.timer > root@issola:~# systemctl status apt-daily-upgrade.timer ● apt-daily-upgrade.timer - Daily apt upgrade and clean activities Loaded: loaded (/etc/systemd/system/apt-daily-upgrade.timer; enabled; preset: enabled) Active: active (waiting) since Tue 2023-12-05 15:02:47 MST; 4 days ago Trigger: Mon 2023-12-11 04:52:42 MST; 17h left Triggers: ● apt-daily-upgrade.service Dec 05 15:02:47 issola systemd[1]: Started apt-daily-upgrade.timer - Daily apt upgrade and clean activities. root@issola:~# Thank you. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
On Sun, Dec 10, 2023 at 10:08:21AM -0500, Greg Wooledge wrote: > On Sun, Dec 10, 2023 at 01:41:14PM +, Andrew M.A. Cater wrote: > > That will work: you might also want to apt-get purge > > linux-image-6.1.0-14-amd64 > > but you've done the main thing. > > Note that purging 6.1.0-14 will also remove the linux-image-amd64 > metapackage, which has a hard dependency on it (at the moment). > > > That works: when the new kernel (presumably 6.1.0-15) comes out, that > > will be installed appropriately. > > Only if you reinstall the kernel metapackage as soon as you notice that > there's been another point release. > > This is not a criticism of Andrew's post. I'm just reminding everyone, > including myself, that we're going to have to remember to do this extra > step. In order to avoid having to remember to re-install the metapackage at a future date, I've installed the prior version from snapshot: http://snapshot.debian.org/archive/debian/20231002T025920Z/pool/main/l/linux-signed-amd64/linux-image-amd64_6.1.55-1_amd64.deb
Re: Unattended Upgrades Ran Anyway.
On Sun, 10 Dec 2023 16:11:44 + Michael Kjörling <2695bd53d...@ewoof.net> wrote: > On 10 Dec 2023 08:49 -0700, from charlescur...@charlescurley.com > (Charles Curley): [...] > > Exactly how did you "shut down" unattended-upgrades? > root@chaffee:/etc/dhcp# systemctl stop unattended-upgrades.service root@chaffee:/etc/dhcp# systemctl status unattended-upgrades.service ● unattended-upgrades.service - Unattended Upgrades Shutdown Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sat 2023-12-09 19:06:51 MST; 6s ago Docs: man:unattended-upgrade(8) Process: 540 ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal (code=exited, status=0/SUCCESS) Main PID: 540 (code=exited, status=0/SUCCESS) CPU: 1.661s Oct 09 02:02:20 chaffee systemd[1]: Started Unattended Upgrades Shutdown. Dec 09 19:06:42 chaffee systemd[1]: Stopping Unattended Upgrades Shutdown... Dec 09 19:06:51 chaffee systemd[1]: unattended-upgrades.service: Succeeded. Dec 09 19:06:51 chaffee systemd[1]: Stopped Unattended Upgrades Shutdown. Dec 09 19:06:51 chaffee systemd[1]: unattended-upgrades.service: Consumed 1.661s CPU time. root@chaffee:/etc/dhcp# -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: IMPORTANT: do NOT upgrade to new stable point release
On 2023-12-10 12:24, Greg Wooledge wrote: On Sun, Dec 10, 2023 at 05:09:15PM -, Curt wrote: On 2023-12-10, Andrew M.A. Cater wrote: "Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023 You mean in the Zulu Time Zone (as I am all at sea)? Use "date -u" to see current UTC time. That should be sufficient to let you know how long it has been since Andrew's "now". You're getting too complicated. The date stamp on his e-mail will display the correct local time (as you have set it) so I can see that he wrote it 30 minutes ago. That relative time is universal across time zones.
Re: Synaptic Problem
Hello, Am 10.12.2023 um 17:58 schrieb Stephen P. Molnar: I appreciated the suggestion, but it didn't solve the problem with Synaptic. On 12/10/2023 11:03 AM, Arno Lehmann wrote: Hi all, Am 10.12.2023 um 16:53 schrieb to...@tuxteam.de: On Sun, Dec 10, 2023 at 10:47:09AM -0500, Stephen P. Molnar wrote: I have just reinstalled Bookworm. Unfortunately, when I tru tto use synaptic I get the following error: E: The package brscan4 needs to be reinstalled, but I can't find an archive for it. Does synaptic still insist on the brscan4 package after it is uninstalled? In that case, there must be some dependency involved. I have not used synaptic a lot, but doesn't it give an explanation *why* it needs the package? Cheers, Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Re: [accessibility@ Orca cause trop
Bonsoir Jean-Philippe,
Ca répond en partie puisque si "N'afficher que le texte affiché" est
coché, effectivement on n'entend plus prononcer "auto completion".
Du coup on n'entend non plus le type des widgets, et ça ça ne le fait
plus du tout car on ne sait pas où on se situe précisément.
Je comprends qu'il y a une "balance" à trouver avec les autres critères
(onglet "Synthèse vocale").
Tu cites le raccourci INSERT+MAJ+ESPACE si j'ai compris.
Il n'a pas l'air de fonctionner chez moi.
Merci à toi :)
pierre estrem
Le 10/12/2023 à 06:38, Jean-Philippe MENGUAL a écrit :
Bonjour Pierre,
Ce genre de question n'est jamais très somple, parce que c'est souvent
un compromis à trouver entre trop ou pas assez bavard. Dans les
préférences, onglet Synthèse vocale, tu peux demander à Orca de ne
lire que le texte affiché, si vraiment tu n'as jamais besoin
d'entendre la description des éléments à l'écran. L'expression "auto
complétion" est en eeffet la description que fait le lecteur d'écran
de la zone où se trouve ton curseur. Tout comme Bouton, case à cocher,
liste déroulante, etc
Dans ce même onglet et alternativement à ce qui précède, tu peux aussi
décocher Lire la description, u bien Annoncer les champs de formulaire.
Si toutefois tu veux restreindre ce comportement (s'il fonctionne) à
Thunderbird, il te faudra utiliser orca+maj+espace pour le faire dans
les préférences d'Orca spécifiques à Thunderbird, tandis que
orca+espace est global.
Espérant que cela aidera,
Cordialement,
Jean-Philippe MENGUAL
Debian Developer non uploading
Community team member
Accessibility team member
debian-l10n-french team member
President of Debian France non-profit organization
Le 10/12/2023 à 04:43, Pierre ESTREm a écrit :
Bonsoir la liste,
J'utilise Orca et avec Thunderbird je ne voudrais ne plus entendre
"auto completion" une fois arrivé dans la zone de saisie du sujet
(lors de la création d'un message).
Je crois l'entendre aussi dans bien d'autres occasions.
Je pense qu'il s'agit d'un message du système car la chaîne
n'apparaît pas suite à "Sujet" .
Ca expliquerait que modifier la prononciation dans les Préférences
de Orca ne donne rien ("auto-completion" => "").
Auriez-vous une méthode pour éviter ces lectures (que je juge
inutiles) ?
Remarque: cette chaîne devrait être cependant prononcée si elle
apparaissait à l'écran !
pierre estrem
Re: IMPORTANT: do NOT upgrade to new stable point release
Andy writes: > This fails with leap seconds, potentially, and also TAI astronomical > time seems to be its own animal. TAI isn't good enough for the astronomers. https://en.wikipedia.org/wiki/Terrestrial_Time -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: IMPORTANT: do NOT upgrade to new stable point release
On Sun, Dec 10, 2023 at 05:20:40PM +, Andrew M.A. Cater wrote:
> On Sun, Dec 10, 2023 at 05:09:15PM -, Curt wrote:
> > On 2023-12-10, Andrew M.A. Cater wrote:
> > >
> > > "Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023
> >
> > You mean in the Zulu Time Zone (as I am all at sea)?
> >
> > > Andy
> > > (amaca...@debian.org)
> > >
> > >
> >
>
> Not this again :) GMT (was) the world standard reference point from 1884
> and the Washington Conference (or thereabouts).
>
> For most purposes GMT + == UTC (or UCT if you're Francophone) ==
Actually this would be TUC ("Temps universel coordonné), while English
would be CUT, but for once, they compromised on UTC [1] :-)
Cheers
[1] https://fr.wikipedia.org/wiki/UTC
--
t
signature.asc
Description: PGP signature
Re: IMPORTANT: do NOT upgrade to new stable point release
On Sun, Dec 10, 2023 at 05:09:15PM -, Curt wrote: > On 2023-12-10, Andrew M.A. Cater wrote: > > > > "Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023 > > You mean in the Zulu Time Zone (as I am all at sea)? Use "date -u" to see current UTC time. That should be sufficient to let you know how long it has been since Andrew's "now".
Re: Unattended Upgrades Ran Anyway.
> I double checked this morning. All machines had unattended upgrades > shut off as of yesterday evening, well before the > unattended-uogrades ran. On my trusty Thinkpad X30, upgrades are sufficiently taxing that having them run unexpectedly can be a real problem, so I tried to prevent unattended upgrades a few months ago. IIRC my first step was to remove the `unattended-upgrades` (which I had manually installed many years ago, when I *did* want upgrades to be automatic), but that did very little. FWIW, it felt like "whack-a-mole", where there seemed to always be another way unattended upgrades could be started :-( Stefan
Re: IMPORTANT: do NOT upgrade to new stable point release
On Sun, Dec 10, 2023 at 05:09:15PM -, Curt wrote: > On 2023-12-10, Andrew M.A. Cater wrote: > > > > "Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023 > > You mean in the Zulu Time Zone (as I am all at sea)? > > > Andy > > (amaca...@debian.org) > > > > > Not this again :) GMT (was) the world standard reference point from 1884 and the Washington Conference (or thereabouts). For most purposes GMT + == UTC (or UCT if you're Francophone) == Zulu time (26 time zones to cope with half hour offsets - ?? go from A-Z??) == "military time" (if you're US military) and quite possibly NATO time. This fails with leap seconds, potentially, and also TAI astronomical time seems to be its own animal. Does this help? Andy (amaca...@debian.org) > >
Re: File systems mounted under `/media/root/` ?
to...@tuxteam.de [2023-12-10 17:47:41] wrote: > You ssh in as root (or serial port)? I do over the serial port, but over SSH, I always login as myself first and then `su -` to root. > Perhaps it's a "user session" thingy playing games on you? Could be, Stefan
Re: IMPORTANT: do NOT upgrade to new stable point release
On 2023-12-10, Andrew M.A. Cater wrote: > > "Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023 You mean in the Zulu Time Zone (as I am all at sea)? > Andy > (amaca...@debian.org) > >
Re: Unattended Upgrades Ran Anyway.
On 10/12/2023 22:49, Charles Curley wrote: root@issola:/var# systemctl status unattended-upgrades.service systemctl status apt-daily-upgrade.timer
Re: Synaptic Problem
I appreciated the suggestion, but it didn't solve the problem with Synaptic. On 12/10/2023 11:03 AM, Arno Lehmann wrote: Hi all, Am 10.12.2023 um 16:53 schrieb to...@tuxteam.de: On Sun, Dec 10, 2023 at 10:47:09AM -0500, Stephen P. Molnar wrote: I have just reinstalled Bookworm. Unfortunately, when I tru tto use synaptic I get the following error: E: The package brscan4 needs to be reinstalled, but I can't find an archive for it. brscan4 is not in the official Debian repos. Perhaps you have installed it from another source which has disappeared. Superficial Internet search suggests that it is a Brother thing. Indeed it is. Brother have some installation helper script, but that is not really playing nicely with the idea of using remote repos for installation. It may be simplest to use dpkg to uninstall the brscan4 package, do the necessary upgrades etc., and then install the brother stuff again. That way, you'll also have relatively up to date Brother drivers. If you want to avoid the odyssey through Brother's web site, have a look at https://pieterhollander.nl/post/brother-printer-debian/ and consider just believing them. Cheers, Arno -- Stephen P. Molnar, Ph.D. https://insilicochemistry.net (614)312-7528 (c) Skype: smolnar1
Re: Urgent Latexhelp needed
On 2023-12-10, wrote:
>
>
> On Sun, Dec 10, 2023 at 06:04:05PM +0200, y...@vienna.at wrote:
>>
>> ! Missing number, treated as zero.
>>
>> \protect
>> l.59 ...reMathSymbol\mho {\mathord}{lasy}{"30}
>> "
>> uppsi
>> what does thar mean?
>
> That TeX was expecting a number at some place and found something
> else (probably this \protect control sequence).
>
I think it's some package loaded in the preamble making " active.
Re: IMPORTANT: do NOT upgrade to new stable point release
On Sun, Dec 10, 2023 at 11:50:18AM -0500, Gary Dale wrote: > On 2023-12-09 14:18, Michael Kjörling wrote: > > On 9 Dec 2023 20:54 +0200, from ale...@nanoid.net (Alexis Grigoriou): > > > I just upgraded to Bookworm this morning. I did reboot a couple of > > > times but there seems to be no problem (yet). Is there anything I > > > should look for or do other than rebooting? > > If you upgraded this morning, then I would expect that you are okay > > for now. > > > > Per #5 in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843 > > the bug is present in kernel Debian package version 6.1.64-1. If you > > are on 6.1.55-1 (current Bookworm stable per last night) you _likely_ > > aren't affected. If you are on 6.1.55-1 (or earlier), just hold off on > > upgrades for now; and if you need to upgrade something else, take > > great care for now to ensure that no Linux kernel packages get > > upgraded to any version < 6.1.66, and preferably not < 6.1.66-1. > > > > For versions, check: > > > > * uname -v > > * dpkg -l linux-image-\* > > > > In that bug report thread, #21 lists 6.1.66 as fixed upstream, and #28 > > indicates that 6.1.66-1 includes the fix from upstream, and that it is > > being published. > > > Any idea when the fixed version will hit stable? With headless servers, it's > a pain to downgrade to a previous kernel version. > Give them a little while: release team are working on it right now as I type I'm fairly sure they're pushing it out more or less immediately once they're sure that it's built correctly and synced to all the appropriate places to be further synced to mirrors "Now" is almost exactly Sun 10 Dec 16:55:43 UTC 2023 Andy (amaca...@debian.org)
Re: IMPORTANT: do NOT upgrade to new stable point release
On 2023-12-09 14:18, Michael Kjörling wrote: On 9 Dec 2023 20:54 +0200, from ale...@nanoid.net (Alexis Grigoriou): I just upgraded to Bookworm this morning. I did reboot a couple of times but there seems to be no problem (yet). Is there anything I should look for or do other than rebooting? If you upgraded this morning, then I would expect that you are okay for now. Per #5 in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843 the bug is present in kernel Debian package version 6.1.64-1. If you are on 6.1.55-1 (current Bookworm stable per last night) you _likely_ aren't affected. If you are on 6.1.55-1 (or earlier), just hold off on upgrades for now; and if you need to upgrade something else, take great care for now to ensure that no Linux kernel packages get upgraded to any version < 6.1.66, and preferably not < 6.1.66-1. For versions, check: * uname -v * dpkg -l linux-image-\* In that bug report thread, #21 lists 6.1.66 as fixed upstream, and #28 indicates that 6.1.66-1 includes the fix from upstream, and that it is being published. Any idea when the fixed version will hit stable? With headless servers, it's a pain to downgrade to a previous kernel version.
Re: Urgent Latexhelp needed
On Sun, Dec 10, 2023 at 04:40:20PM +, Eric S Fraga wrote:
> On Sunday, 10 Dec 2023 at 18:22, y...@vienna.at wrote:
> > There is nothing like \mho 0r /mho or {\mho} anywhere in the text
>
> That may be but it was in the snippet of the error message you posted.
> Maybe post more context
Yes, please!
I already asked twice for it. I'm not asking a third time ;-P
Cheers
--
t
signature.asc
Description: PGP signature
Re: File systems mounted under `/media/root/` ?
On Sun, Dec 10, 2023 at 11:42:42AM -0500, Stefan Monnier wrote: > Stanislav Vlasov [2023-12-10 21:16:54] wrote: > > In /media/ disks mounts by GUI. Stefan use root in gui login. > > Except: > - I never do a "GUI login" as root. > - "This is on a headless ARM board running Debian stable". > I access it via SSH (and occasionally serial port). You ssh in as root (or serial port)? Perhaps it's a "user session" thingy playing games on you? Cheers -- t signature.asc Description: PGP signature
Re: File systems mounted under `/media/root/` ?
Stanislav Vlasov [2023-12-10 21:16:54] wrote: > In /media/ disks mounts by GUI. Stefan use root in gui login. Except: - I never do a "GUI login" as root. - "This is on a headless ARM board running Debian stable". I access it via SSH (and occasionally serial port). Stefan
Re: Urgent Latexhelp needed
On Sunday, 10 Dec 2023 at 18:22, y...@vienna.at wrote:
> There is nothing like \mho 0r /mho or {\mho} anywhere in the text
That may be but it was in the snippet of the error message you posted.
Maybe post more context (e.g. line in your actual LaTeX where error
occurs) and/or ask on a LaTeX list/group?
--
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2
Re: File systems mounted under `/media/root/` ?
Max Nikulin [2023-12-10 21:49:46] wrote: > On 10/12/2023 02:49, Stefan Monnier wrote: >> "magically" mounted as >> `/media/root/`. > [...] >> Any idea who/what does that, and how/where I can control it? > > This path is used by udisks, however I am unsure what may cause > automounting for root. > > I would check > > udisksctl dump > udevadm info --query=all --name=sda > > for various hints related to udisks. Perhaps a better variant of udevadm > options exists. Thanks. Now I have some thread on which to pull :-) Nicholas Geovanis [2023-12-10 08:04:08] wrote: > Were there any reboots in between? Yes, I've seen the problem appear a few times over the last few days where I've been rebooting a few times (while replacing/moving some drives, and making various adjustments along the way). Stefan
Re: Image handling in mutt
On Sun, Dec 10, 2023 at 04:15:22PM -, Curt wrote: > On 2023-12-09, Eric S Fraga wrote: > > On Friday, 8 Dec 2023 at 17:06, Pocket wrote: > >> In Unix and Linux there isn't a file extension, that is a microsoft > >> invention. > > > > Predates MS by years. Systems like RSTS/E on PDP-11s, just to name one. > > They certainly are convenient. When they aren't a lie. Remember those "foo.jpg.exe"? I always consider putting metadata in a file name a "design smell" [1]. That's why I cringe when people name executables "foo.sh". What do you do when you decide to rewrite the thing in C (or Rust, or whatever)? Do you go over all calling sites and change the caller's code? Cheers [1] https://en.wikipedia.org/wiki/Code_smell -- t signature.asc Description: PGP signature
Re: Urgent Latexhelp needed
On Sun, 10 Dec 2023 16:11:22 +
Eric S Fraga wrote:
Untested but shouldn't the \mho be within braces, {\mho}?
--
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2
There is nothing like \mho 0r /mho or {\mho} anywhere in the text
Re: File systems mounted under `/media/root/` ?
2023-12-10 19:49 GMT+05:00, Max Nikulin : > On 10/12/2023 02:49, Stefan Monnier wrote: >> "magically" mounted as >> `/media/root/`. > [...] >> Any idea who/what does that, and how/where I can control it? > > This path is used by udisks, however I am unsure what may cause > automounting for root. > In /media/ disks mounts by GUI. Stefan use root in gui login. -- Stanislav
Re: Image handling in mutt
On 2023-12-09, Eric S Fraga wrote: > On Friday, 8 Dec 2023 at 17:06, Pocket wrote: >> In Unix and Linux there isn't a file extension, that is a microsoft >> invention. > > Predates MS by years. Systems like RSTS/E on PDP-11s, just to name one. They certainly are convenient. I must be stupid or something.
Re: Unattended Upgrades Ran Anyway.
On 10 Dec 2023 08:49 -0700, from charlescur...@charlescurley.com (Charles Curley): > Due to the recent traffic about the defective kernel in Bookworm > (12.3), I shut down unattended-upgrades on all my machines (Bookworm > and Bullseye). To my surprise, three of them ran unattended-upgrades > anyway. Exactly how did you "shut down" unattended-upgrades? -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Urgent Latexhelp needed
Untested but shouldn't the \mho be within braces, {\mho}?
--
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2
Re: Urgent Latexhelp needed
On Sun, Dec 10, 2023 at 06:04:05PM +0200, y...@vienna.at wrote:
> "
>
> ! Missing number, treated as zero.
>
> \protect
> l.59 ...reMathSymbol\mho {\mathord}{lasy}{"30}
> "
> uppsi
> what does thar mean?
That TeX was expecting a number at some place and found something
else (probably this \protect control sequence).
If you don't show us more context (around line 59 of your LaTeX
document, it seems) we can only guess.
You can just type "q" there and hope that zero was a good number,
perhaps the document gets typeset nicely anyway.
Cheers
--
t
signature.asc
Description: PGP signature
Urgent Latexhelp needed
"
! Missing number, treated as zero.
\protect
l.59 ...reMathSymbol\mho {\mathord}{lasy}{"30}
"
uppsi
what does thar mean?
Re: Synaptic Problem
Hi all, Am 10.12.2023 um 16:53 schrieb to...@tuxteam.de: On Sun, Dec 10, 2023 at 10:47:09AM -0500, Stephen P. Molnar wrote: I have just reinstalled Bookworm. Unfortunately, when I tru tto use synaptic I get the following error: E: The package brscan4 needs to be reinstalled, but I can't find an archive for it. brscan4 is not in the official Debian repos. Perhaps you have installed it from another source which has disappeared. Superficial Internet search suggests that it is a Brother thing. Indeed it is. Brother have some installation helper script, but that is not really playing nicely with the idea of using remote repos for installation. It may be simplest to use dpkg to uninstall the brscan4 package, do the necessary upgrades etc., and then install the brother stuff again. That way, you'll also have relatively up to date Brother drivers. If you want to avoid the odyssey through Brother's web site, have a look at https://pieterhollander.nl/post/brother-printer-debian/ and consider just believing them. Cheers, Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Re: Synaptic Problem
On Sun, Dec 10, 2023 at 10:47:09AM -0500, Stephen P. Molnar wrote: > I have just reinstalled Bookworm. > > Unfortunately, when I tru tto use synaptic I get the following error: > > E: The package brscan4 needs to be reinstalled, but I can't find an archive > for it. brscan4 is not in the official Debian repos. Perhaps you have installed it from another source which has disappeared. Superficial Internet search suggests that it is a Brother thing. > E: Internal error opening cache (1). Please report. > > Unfortunately, Google has not been of any help. > > A solution to the problem would be appreciated. That will depend on whether you need that brscan4 package. Do you have a Brother scanner? Cheers -- t signature.asc Description: PGP signature
Re: IMPORTANT: do NOT upgrade to new stable point release
On 9 Dec 2023, at 19:18, Michael Kjörling wrote: > If you are on 6.1.55-1 (or earlier), just hold off on > upgrades for now; and if you need to upgrade something else, take > great care for now to ensure that no Linux kernel packages get > upgraded to any version < 6.1.66, and preferably not < 6.1.66-1. TSM for this advice. As I'm not used to having to "take great care" like this, I would appreciate confirmation that what I've done is likely to be useful. I've dropped a file into /etc/apt/preferences.d/ containing the following text. Package: linux-image-amd64 Pin: version 6.1.55-1 Pin-Priority: 1100 As I noticed that an upgrade to 6.1.64-1 was also in line for linux-libc-dev, I did the same for this package too. As a result, apt-cache policy is telling me linux-image-amd64: Installed: 6.1.55-1 Candidate: 6.1.55-1 Version table: 6.1.64-1 500 500 https://ftp.debian.org/debian bookworm/main amd64 Packages *** 6.1.55-1 1100 100 /var/lib/dpkg/status 6.1.52-1 500 500 https://security.debian.org/debian-security bookworm-security/main amd64 Packages linux-libc-dev: Installed: 6.1.55-1 Candidate: 6.1.55-1 Version table: 6.1.64-1 500 500 https://ftp.debian.org/debian bookworm/main amd64 Packages *** 6.1.55-1 1100 100 /var/lib/dpkg/status 6.1.52-1 500 500 https://security.debian.org/debian-security bookworm-security/main amd64 Packages Thanks in anticipation of a simple yes or no. Niall O'Reilly
Unattended Upgrades Ran Anyway.
Due to the recent traffic about the defective kernel in Bookworm (12.3), I shut down unattended-upgrades on all my machines (Bookworm and Bullseye). To my surprise, three of them ran unattended-upgrades anyway. One of them is Bullseye, so it was a harmless error. But still…. The two Bookworm machines are recent installations, to 12.2 as upgraded. Fortunately, in both cases the upgrade failed because someone was smart enough to pull the plug on the defective kernel. My thanks to that someone. I double checked this morning. All machines had unattended upgrades shut off as of yesterday evening, well before the unattended-uogrades ran. -- Date: Sun, 10 Dec 2023 04:43:10 -0700 (MST) From: root@issola.localdomain To: charles@issola.localdomain Subject: unattended-upgrades result for issola.localdomain: FAILURE Unattended upgrade result: The URI http://deb.debian.org/debian/pool/m ain/l/linux-signed-amd64/linux-image-6.1.0-14-amd64_6.1.64-1_amd64.de b failed to download, aborting Unattended-upgrades log: Starting unattended upgrades script Allowed origins are: origin=Debian,codename=bookworm-updates, origin=Debian,codename=bookworm,label=Debian, +origin=Debian,codename=bookworm,label=Debian-Security, origin=Debian,codename=bookworm-security,label=Debian-Security Initial blacklist: Initial whitelist (not strict): An error occurred: 403 Access denied - broken package [IP: 192.168.100.12 3142] The URI http://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-14-amd64_6.1.64-1_amd64.deb failed to download, +aborting -- root@issola:/var# systemctl status unattended-upgrades.service ○ unattended-upgrades.service - Unattended Upgrades Shutdown Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; preset: enabled) Active: inactive (dead) since Sat 2023-12-09 19:06:51 MST; 13h ago Duration: 4d 4h 4min 2.799s Docs: man:unattended-upgrade(8) Process: 786 ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal (code=exited, status=0/SUCCESS) Main PID: 786 (code=exited, status=0/SUCCESS) CPU: 87ms Dec 05 15:02:48 issola systemd[1]: Started unattended-upgrades.service - Unattended Upgrades Shutdown. Dec 09 19:06:51 issola systemd[1]: Stopping unattended-upgrades.service - Unattended Upgrades Shutdown... Dec 09 19:06:51 issola systemd[1]: unattended-upgrades.service: Deactivated successfully. Dec 09 19:06:51 issola systemd[1]: Stopped unattended-upgrades.service - Unattended Upgrades Shutdown. [1]+ Donefirewall-config root@issola:/var# -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Synaptic Problem
I have just reinstalled Bookworm. Unfortunately, when I tru tto use synaptic I get the following error: E: The package brscan4 needs to be reinstalled, but I can't find an archive for it. E: Internal error opening cache (1). Please report. Unfortunately, Google has not been of any help. A solution to the problem would be appreciated. Tanks in advance. -- Stephen P. Molnar, Ph.D. https://insilicochemistry.net (614)312-7528 (c) Skype: smolnar1
Re: ⚠ No actualicéis a Debian 12.3 ⚠
Gracias x la información On Sun, Dec 10, 2023 at 9:01 AM Camaleón wrote: > Hola, > > Pues eso, acabo de leer que se retrasa por problemas con un bug de ext4 > (corrupción de archivos) y en Debian recomiendan PAUSAR las > actualizaciones, > sobre todo en sistemas que tienen configuradas las actualizaciones > desatendidas. > > Debian 12.3 image release delayed > https://www.debian.org/News/2023/2023120902 > > P.S. El asunto se inicia y finaliza con dos símbolos unicode con la > señal de peligro (⚠) a ver cómo se renderiza :-) > > Saludos, > > -- > Camaleón > >
Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
On Sun, Dec 10, 2023 at 01:41:14PM +, Andrew M.A. Cater wrote: > That will work: you might also want to apt-get purge > linux-image-6.1.0-14-amd64 > but you've done the main thing. Note that purging 6.1.0-14 will also remove the linux-image-amd64 metapackage, which has a hard dependency on it (at the moment). > That works: when the new kernel (presumably 6.1.0-15) comes out, that > will be installed appropriately. Only if you reinstall the kernel metapackage as soon as you notice that there's been another point release. This is not a criticism of Andrew's post. I'm just reminding everyone, including myself, that we're going to have to remember to do this extra step.
Re: File systems mounted under `/media/root/` ?
On 10/12/2023 02:49, Stefan Monnier wrote: "magically" mounted as `/media/root/`. [...] Any idea who/what does that, and how/where I can control it? This path is used by udisks, however I am unsure what may cause automounting for root. I would check udisksctl dump udevadm info --query=all --name=sda for various hints related to udisks. Perhaps a better variant of udevadm options exists.
Re: File systems mounted under `/media/root/` ?
On Sat, Dec 9, 2023, 1:50 PM Stefan Monnier wrote: > Recently I noticed some unused ext4 filesystems (i.e. filesystems that > aren't in /etc/fstab, that I normally don't mount, typically because > they're snapshots or backups) "magically" mounted as > `/media/root/`. > > This is on a headless ARM board running Debian stable. > > Not sure when this happen, but I noticed t least once happening in > response to `vgchange -ay`. > Were there any reboots in between? Any idea who/what does that, and how/where I can control it? > > Stefan >
Re: Fastly error: unknown domain: 199.232.150.132 : Fastly is cdn for Debian.
On Sun, Dec 10, 2023 at 02:38:34PM +0100, Mario Marietto wrote: > Hello to everyone. > > I'm using Devuan 5 for arm32 on my ARM chromebook and I've just tried to > update the system,but I failed. > Hi Mario, You're on your own for two reasons: one is that relatively few of us will be running on an ARM chromebook, the second is that you're asking a Devuan question. With the best will in the world, the best that we can give you on this list is "best endeavours" answers: other Debian-based distributions may do things very differently and the good people here may not have the answers to give. > This is the sources.list file that I'm using : > > deb http://pkg.bunsenlabs.org/debian beryllium main > Bunsenlabs is at best Debian-based (as a continuation of Crunchbang). I've no idea how good their ARM port is here. > deb http://deb.devuan.org/merged daedalus main > deb http://deb.devuan.org/merged daedalus-updates main > deb http://deb.devuan.org/merged daedalus-security main > deb http://deb.devuan.org/merged daedalus-backports main > > deb-src http://deb.devuan.org/merged daedalus main > deb-src http://deb.devuan.org/merged daedalus-updates main > deb-src http://deb.devuan.org/merged daedalus-security main > deb-src http://deb.devuan.org/merged daedalus-backports main > Ask Devuan: is there any particular reason you're using Devuan here rather than Debian? > # apt update > > Hit:1 http://pkg.bunsenlabs.org/debian beryllium InRelease > Get:2 http://deb.devuan.org/merged daedalus InRelease [42.4 kB] > Get:3 http://deb.devuan.org/merged daedalus-updates InRelease [32.5 kB] > Get:4 http://deb.devuan.org/merged daedalus-security InRelease [32.5 kB] > Get:5 http://deb.devuan.org/merged daedalus-backports InRelease [32.6 kB] > > Reading package lists... Done > > E: Release file for > http://pkg.bunsenlabs.org/debian/dists/beryllium/InRelease is not valid yet > (invalid for another 8674d 3h 45min 8s). Updates for this repository will > not be applied. > E: Release file for http://deb.devuan.org/merged/dists/daedalus/InRelease > is not valid yet (invalid for another 8744d 2h 14min 0s). Updates for this > repository will not be applied. > E: Release file for > http://deb.devuan.org/merged/dists/daedalus-updates/InRelease is not valid > yet (invalid for another 8744d 7h 58min 21s). Updates for this repository > will not be applied. > E: Release file for > http://deb.devuan.org/merged/dists/daedalus-security/InRelease is not valid > yet (invalid for another 8744d 4h 58min 7s). Updates for this repository > will not be applied. > E: Release file for > http://deb.devuan.org/merged/dists/daedalus-backports/InRelease is not > valid yet (invalid for another 8744d 7h 58min 11s). Updates for this > repository will not be applied. > Your real time clock isn't :( Set the date correctly using GNU date command or similar and work forward from there. > After a little experimenting it looks like to me that it is a Fastly error: > > Fastly error: unknown domain: 199.232.150.132. Please check that this > domain has been added to a service. > > Fastly is cdn for Debian. > -- This is irrelevant given your sources lists - you're not referencing Debian sources, potentially. > Mario. With every good wish, as ever, Andy (amaca...@debian.org)
Re: Fastly error: unknown domain: 199.232.150.132 : Fastly is cdn for Debian.
Am 10.12.2023 um 14:38:34 Uhr schrieb Mario Marietto: > http://deb.devuan.org/merged/dists/daedalus-updates/InRelease is not > valid yet (invalid for another 8744d 7h 58min 21s). Updates for this > repository will not be applied. Is your date correct on your machine?
Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
On Sun, Dec 10, 2023 at 01:48:52PM +0100, Stella Ashburne wrote: > Hi, > > I am using Debian Bookworm, the current stable release with the whole SSD > being encrypted with LUKS2. After decryption, the file system of the logical > volume is ext4. > > This is what happened to my computer many hours ago. > > My device upgraded to the latest kernel, linux-image-6.1.0-14-amd64 and > rebooted. > Yes, this was a problem that surfaced properly half way through the release process. The release team had already put out the main updates: I was involved with testing the images with the images team. The issue itself is only occasional and is hard to track down. It only affects ext4 - but that's the default file system used if you "just install" Debian so the release team effectively stopped the release process part way through. We halted the release of installer images: so there are no installer images out there for Debian 12.3 which would be problematic. The release team is currently working on 12.4, images for which will probably be out within the next couple of days. (This will be the first time in a _long_ time that we've not put out a release of images - breakage doesn't happen very often and the publicity folks also got onto this to warn people.) > A few hours later, Debian put out an advisory warning its users against > upgrading to linux-image-6.1.0-14-amd64, by which time it was too late for me. > Bad luck - but it looks as if you've done the right thing ... > According to some people on social media, I should boot using the previous > kernel, linux-image-6.1.0-13-amd64, which is problem-free. > > Question #1 > > I power up my device and upon seeing the GRUB menu, I highlight "Advance > options for Debian GNU/Linux" and press Enter. > > I highlight linux-image-6.1.0-13-amd64 and press Enter. > > After supply the decryption password and entering my desktop environment, I > did the following: > > cat /etc/debian_user > *Result* is 12.3, even though I boot using the previous kernel, > linux-image-6.1.0-13-amd64 > This is because base-files and everything else have been updated to reference 12.3 - so that probably comes from somewhere like /etc/debian_version > uname -a > *Result* is linux-image-6.1.0-13-amd64 > Correct: you've booted using 6.1.0-13 > I remove the corrupt linux-image-6.1.0-14-amd64 by typing the following > commands in a terminal. They are: > > dpkg --search /boot/vmlinuz-* > > sudo apt-get remove linux-image-6.1.0-14-amd64 > > sudo update-grub > > sudo shutdown -r now > > Is the above the correct way to remove the most recent/latest kernel? > That will work: you might also want to apt-get purge linux-image-6.1.0-14-amd64 but you've done the main thing. > Question #2a > > Some users opine that after removing linux-image-6.1.0-14-amd64, I should > re-install linux-image-6.1.0-13-amd64. Why should I re-install > linux-image-6.1.0-1-amd64? > If you'd removed 6.1.0-13 so that the later kernel was the only one - that would be right - Otherwise you're fine. > Am I right to state that Debian keeps the three recent kernels, including > linux-image-6.1.0-14-amd64, for situations such as this one? (The situation > in which a corrupt linux-image-6.1.0-14-amd64 was pushed to the repos for > users to upgrade) > Routinely, I think it keeps only the latest and the previous - so in this case, you would have had 6.1.0-14 and 6.1.0-13 > Question #2b > > Suppose I need to re-install linux-image-6.1.0-13-amd64 but some users told > me that it is no longer in the repos. > > I can just download it manually by using the following link: > > https://packages.debian.org/bookworm/amd64/linux-image-6.1.0-13-amd64/download > > And then in a terminal, I type the commands: > > sudo dpkg -i linux-image-6.1.0-13-amd64 > > sudo update-grub > > sudo shutdown -r now > That works: when the new kernel (presumably 6.1.0-15) comes out, that will be installed appropriately. > Is the above the correct way to install kernels that are not in the official > repos? > That will work while previous kernels still exist in the repositories yes. When I installed, I still had 6.0.1.12 available too because I'd had that previously. > Thanks for taking the time and effort to clarify my doubts. > > Best regards. > > Stella > > No problem: debian-release team are working away quite hard at the moment on sorting out the problems, providing a new kernel and, presumably, removing the problematic kernel from the archive. It's been a long weekend for them :( All the very best, as ever, Andy
Fastly error: unknown domain: 199.232.150.132 : Fastly is cdn for Debian.
Hello to everyone. I'm using Devuan 5 for arm32 on my ARM chromebook and I've just tried to update the system,but I failed. This is the sources.list file that I'm using : deb http://pkg.bunsenlabs.org/debian beryllium main deb http://deb.devuan.org/merged daedalus main deb http://deb.devuan.org/merged daedalus-updates main deb http://deb.devuan.org/merged daedalus-security main deb http://deb.devuan.org/merged daedalus-backports main deb-src http://deb.devuan.org/merged daedalus main deb-src http://deb.devuan.org/merged daedalus-updates main deb-src http://deb.devuan.org/merged daedalus-security main deb-src http://deb.devuan.org/merged daedalus-backports main # apt update Hit:1 http://pkg.bunsenlabs.org/debian beryllium InRelease Get:2 http://deb.devuan.org/merged daedalus InRelease [42.4 kB] Get:3 http://deb.devuan.org/merged daedalus-updates InRelease [32.5 kB] Get:4 http://deb.devuan.org/merged daedalus-security InRelease [32.5 kB] Get:5 http://deb.devuan.org/merged daedalus-backports InRelease [32.6 kB] Reading package lists... Done E: Release file for http://pkg.bunsenlabs.org/debian/dists/beryllium/InRelease is not valid yet (invalid for another 8674d 3h 45min 8s). Updates for this repository will not be applied. E: Release file for http://deb.devuan.org/merged/dists/daedalus/InRelease is not valid yet (invalid for another 8744d 2h 14min 0s). Updates for this repository will not be applied. E: Release file for http://deb.devuan.org/merged/dists/daedalus-updates/InRelease is not valid yet (invalid for another 8744d 7h 58min 21s). Updates for this repository will not be applied. E: Release file for http://deb.devuan.org/merged/dists/daedalus-security/InRelease is not valid yet (invalid for another 8744d 4h 58min 7s). Updates for this repository will not be applied. E: Release file for http://deb.devuan.org/merged/dists/daedalus-backports/InRelease is not valid yet (invalid for another 8744d 7h 58min 11s). Updates for this repository will not be applied. After a little experimenting it looks like to me that it is a Fastly error: Fastly error: unknown domain: 199.232.150.132. Please check that this domain has been added to a service. Fastly is cdn for Debian. -- Mario.
Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
On 10 Dec 2023 13:48 +0100, from rewe...@gmx.com (Stella Ashburne): > I highlight linux-image-6.1.0-13-amd64 and press Enter. > > After supply the decryption password and entering my desktop > environment, I did the following: > > cat /etc/debian_user > *Result* is 12.3, even though I boot using the previous kernel, > linux-image-6.1.0-13-amd64 > > uname -a > *Result* is linux-image-6.1.0-13-amd64 This combination is expected under the circumstances, assuming that you mean /etc/debian_version. Booting into a different kernel does not change the files installed by the base-files package, which is where /etc/debian_version comes from; if you want to, you can verify this with dpkg -S /etc/debian_version. > I remove the corrupt linux-image-6.1.0-14-amd64 by typing the > following commands in a terminal. They are: > > dpkg --search /boot/vmlinuz-* > > sudo apt-get remove linux-image-6.1.0-14-amd64 > > sudo update-grub > > sudo shutdown -r now > > Is the above the correct way to remove the most recent/latest kernel? Seems reasonable, _because_ the problematic kernel is a new package. If it had been an upgraded version of the same package, a similar fix would have been somewhat more involved. > Question #2a > > Some users opine that after removing linux-image-6.1.0-14-amd64, I > should re-install linux-image-6.1.0-13-amd64. Why should I > re-install linux-image-6.1.0-1-amd64? Probably because it's an easy way to ensure that your bootloader configuration is accurate. If what you showed above completed without any warnings or other troublesome output, I would expect everything to be fine. > Question #2b > > Suppose I need to re-install linux-image-6.1.0-13-amd64 but some users told > me that it is no longer in the repos. > > I can just download it manually by using the following link: > > https://packages.debian.org/bookworm/amd64/linux-image-6.1.0-13-amd64/download > > And then in a terminal, I type the commands: > > sudo dpkg -i linux-image-6.1.0-13-amd64 > > sudo update-grub > > sudo shutdown -r now > > Is the above the correct way to install kernels that are not in the official > repos? Not quite, because dpkg -i wants a file path, not a package name (that's for apt/apt-get). Also dpkg won't automatically pull in any dependencies that may have been uninstalled after the upgrade, or necessarily handle any DKMS modules that would need to be recompiled for the older kernel version, so you'd need to take care with those. Someone on the Fediverse posted an apt preferences recipe to block the broken kernel package from installation. I haven't tested it, but it looks reasonable: > create a file: > > /etc/apt/preferences.d/buggy-kernel > > with the contents: > # avoid kernel with ext4 bug > # 1057843 > Package: linux-image-* > Pin: version 6.1.64-1 > Pin-Priority: -1 Copied from https://octodon.social/@alienghic/111552556796482609 -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
Hi, I am using Debian Bookworm, the current stable release with the whole SSD being encrypted with LUKS2. After decryption, the file system of the logical volume is ext4. This is what happened to my computer many hours ago. My device upgraded to the latest kernel, linux-image-6.1.0-14-amd64 and rebooted. A few hours later, Debian put out an advisory warning its users against upgrading to linux-image-6.1.0-14-amd64, by which time it was too late for me. According to some people on social media, I should boot using the previous kernel, linux-image-6.1.0-13-amd64, which is problem-free. Question #1 I power up my device and upon seeing the GRUB menu, I highlight "Advance options for Debian GNU/Linux" and press Enter. I highlight linux-image-6.1.0-13-amd64 and press Enter. After supply the decryption password and entering my desktop environment, I did the following: cat /etc/debian_user *Result* is 12.3, even though I boot using the previous kernel, linux-image-6.1.0-13-amd64 uname -a *Result* is linux-image-6.1.0-13-amd64 I remove the corrupt linux-image-6.1.0-14-amd64 by typing the following commands in a terminal. They are: dpkg --search /boot/vmlinuz-* sudo apt-get remove linux-image-6.1.0-14-amd64 sudo update-grub sudo shutdown -r now Is the above the correct way to remove the most recent/latest kernel? Question #2a Some users opine that after removing linux-image-6.1.0-14-amd64, I should re-install linux-image-6.1.0-13-amd64. Why should I re-install linux-image-6.1.0-1-amd64? Am I right to state that Debian keeps the three recent kernels, including linux-image-6.1.0-14-amd64, for situations such as this one? (The situation in which a corrupt linux-image-6.1.0-14-amd64 was pushed to the repos for users to upgrade) Question #2b Suppose I need to re-install linux-image-6.1.0-13-amd64 but some users told me that it is no longer in the repos. I can just download it manually by using the following link: https://packages.debian.org/bookworm/amd64/linux-image-6.1.0-13-amd64/download And then in a terminal, I type the commands: sudo dpkg -i linux-image-6.1.0-13-amd64 sudo update-grub sudo shutdown -r now Is the above the correct way to install kernels that are not in the official repos? Thanks for taking the time and effort to clarify my doubts. Best regards. Stella
Thinkpad x13 AMD Ryzen microphone not working in Debian Bookworm
I have installed Debian Bookworm on X13 with AMD Ryzen 7840U and microphone is not working. It shows inactive. I use KDE and installed pipewire. The mic did not work since base install. Any advise? $ inxi -A Audio: Device-1: AMD Rembrandt Radeon High Definition Audio driver: snd_hda_intel Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor driver: N/A Device-3: AMD Family 17h/19h HD Audio driver: snd_hda_intel API: ALSA v: k6.5.0-0.deb12.1-amd64 status: kernel-api Server-1: PipeWire v: 0.3.65 status: active $ inxi CPU: 8-core AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics (-MT MCP-) speed/min/max: 1337/400/5132:6076:5605:5289:5447:5760:5918 MHz Kernel: 6.5.0-0.deb12.1-amd64 x86_64 Up: 6m Mem: 4206.1/30781.0 MiB (13.7%) Storage: 476.94 GiB (3.3% used) Procs: 370 Shell: Bash inxi: 3.3.26 $ pactl list cards Card #44 Name: alsa_card.pci-_c3_00.1 Driver: alsa Owner Module: n/a Properties: api.acp.auto-port = "false" api.acp.auto-profile = "false" api.alsa.card = "0" api.alsa.card.longname = "HD-Audio Generic at 0x905c8000 irq 106" api.alsa.card.name = "HD-Audio Generic" api.alsa.path = "hw:0" api.alsa.use-acp = "true" api.dbus.ReserveDevice1 = "Audio0" device.api = "alsa" device.bus = "pci" device.bus_path = "pci-:c3:00.1" device.description = "Rembrandt Radeon High Definition Audio Controller" device.enum.api = "udev" device.icon_name = "audio-card-analog-pci" device.name = "alsa_card.pci-_c3_00.1" device.nick = "HD-Audio Generic" device.plugged.usec = "5163628" device.product.id = "0x1640" device.product.name = "Rembrandt Radeon High Definition Audio Controller" device.subsystem = "sound" sysfs.path = "/devices/pci:00/:00:08.1/:c3:00.1/sound/card0" device.vendor.id = "0x1002" device.vendor.name = "Advanced Micro Devices, Inc. [AMD/ATI]" media.class = "Audio/Device" factory.id = "14" client.id = "34" object.id = "44" object.serial = "44" object.path = "alsa:pcm:0" alsa.card = "0" alsa.card_name = "HD-Audio Generic" alsa.long_card_name = "HD-Audio Generic at 0x905c8000 irq 106" alsa.driver_name = "snd_hda_intel" device.string = "0" Profiles: off: Off (sinks: 0, sources: 0, priority: 0, available: yes) output:hdmi-stereo: Digital Stereo (HDMI) Output (sinks: 1, sources: 0, priority: 5900, available: no) output:hdmi-stereo-extra1: Digital Stereo (HDMI 2) Output (sinks: 1, sources: 0, priority: 5700, available: no) output:hdmi-stereo-extra2: Digital Stereo (HDMI 3) Output (sinks: 1, sources: 0, priority: 5700, available: no) output:hdmi-stereo-extra3: Digital Stereo (HDMI 4) Output (sinks: 1, sources: 0, priority: 5700, available: no) output:hdmi-surround: Digital Surround 5.1 (HDMI) Output (sinks: 1, sources: 0, priority: 800, available: no) output:hdmi-surround71: Digital Surround 7.1 (HDMI) Output (sinks: 1, sources: 0, priority: 800, available: no) output:hdmi-surround-extra1: Digital Surround 5.1 (HDMI 2) Output (sinks: 1, sources: 0, priority: 600, available: no) output:hdmi-surround71-extra1: Digital Surround 7.1 (HDMI 2) Output (sinks: 1, sources: 0, priority: 600, available: no) output:hdmi-surround-extra2: Digital Surround 5.1 (HDMI 3) Output (sinks: 1, sources: 0, priority: 600, available: no) output:hdmi-surround71-extra2: Digital Surround 7.1 (HDMI 3) Output (sinks: 1, sources: 0, priority: 600, available: no) output:hdmi-surround-extra3: Digital Surround 5.1 (HDMI 4) Output (sinks: 1, sources: 0, priority: 600, available: no) output:hdmi-surround71-extra3: Digital Surround 7.1 (HDMI 4) Output (sinks: 1, sources: 0, priority: 600, available: no) pro-audio: Pro Audio (sinks: 4, sources: 0, priority: 1, available: yes) Active Profile: off Ports: hdmi-output-0: HDMI / DisplayPort (type: HDMI, priority: 5900, latency offset: 0 usec, availability group: Legacy 1, not available) Properties: port.type = "hdmi" port.availability-group = "Legacy 1" device.icon_name = "video-display" card.profile.port = "0" Part of profile(s): output:hdmi-stereo,
⚠ No actualicéis a Debian 12.3 ⚠
Hola, Pues eso, acabo de leer que se retrasa por problemas con un bug de ext4 (corrupción de archivos) y en Debian recomiendan PAUSAR las actualizaciones, sobre todo en sistemas que tienen configuradas las actualizaciones desatendidas. Debian 12.3 image release delayed https://www.debian.org/News/2023/2023120902 P.S. El asunto se inicia y finaliza con dos símbolos unicode con la señal de peligro (⚠) a ver cómo se renderiza :-) Saludos, -- Camaleón
