Re: Need Support on Debian10 Linux Kernel Upgrade
Hi, Balasubramanian Ravuthan wrote: > 1. Debian 10 Buster is not released with Linux Kernel 5.10 ; That means We >cant upgrade Kernel 5.10 with Debian 10? - Please confirm. No. There are kernel source packages of 5.10 in backports https://packages.debian.org/buster-backports/linux-source-5.10 https://packages.debian.org/buster-backports/linux-config-5.10 In general you can compile an own kernel and use it with your existing Debian installation. I did this on Debian 10 with 5.10-rc3 from git (branch "linux-next") when i explored how to fix various old bugs in cdrom, sr, and iso9660. It works fine for me, although being much newer than the 4.19 kernel which was installed with Debian 10 (and still can be booted if i want). This is not recommended by Debian, of course, and you might get mockery from other Debian users if you report about problems which arise from such a individual kernel upgrade. Better first try with the source packages from backports. > 3. In order to upgrade Linux Kernel to 5.10 means we have to install Debian > 11 BullsEye. Please Confirm. See 1. > 5. What will be the impact for upgrading Debian 10 with Kernel 4.19 to > Debian 11 with Kernel 5.10. At least "bracketed-paste" and maybe other unsolicited changes. (Yesterday i had to learn how to repair vim on a SuSE system: set t_BE= I'm looking forward to my first upgrade to Debian 11 ...) > 2. > 4. Were these items supposed to contain questions ? Have a nice day :) Thomas
Re: Fwd: Returned mail: see transcript for details
Him On 2021-12-16 3:10 p.m., gene heskett wrote: > See attached, the final reject of my attempt to post to the cups list, which > I > am subscribed to. > > Where did I mess it up? > Have you tried registering again ? Also, look in the header of your message and see the complete route of your message. Maybe you email server is blocked by Apple's system for security reason. Who's you email provider? > Cheers, Gene Heskett. > -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development OpenPGP_signature Description: OpenPGP digital signature
Re: xmodmap settings lost when (usb) keyboard reattached.
Vincent Lefevre writes: > In the past, I wrote a script, put in the /etc/pm/sleep.d directory: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633849#92 > > but there were some issues with it, as I mentioned there. It's also not directly applicable when the issue isn't related to pm-utils or suspend or hibernate. I have the same annoyance as the OP, USB keyboard connected to a USB switch so that I can switch between my work and personal computers in my home office easily. I have an alias fk for fix keyboard which just runs xmodmap with some input, basically it sets Alt_R to Mode_switch and then maps a bunch of chars (20 total) behind mode_switch. What I see in my script where I switch the USB is a little weird. I can run xmodmap from the script but it doesn't apply the layout. No error either. I've tried to use a delay and that sometimes works but not consistently. I've also tried to monitor for changes in xmodmap output even up to a minute since that changes some time after the keyboard is plugged in, after a while Alt_R appears on the mod1 line of xmodmap output. What I found just now as I played with this is that if I have just one call xmodmap then things work. I had a leftover second call to xmodmap which makes caps to control but I don't need that with my current keyboard.
Re: jupyter-notebook and bullseye
Hi. On Thu, Dec 16, 2021 at 12:43:51PM -0700, D. R. Evans wrote: > FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/python' ... > Can someone suggest how I might get back to the fully-working set of kernels > that I had in buster? Try this: apt install python-is-python3 Reco
Re: xmodmap settings lost when (usb) keyboard reattached.
On Wed 15 Dec 2021 at 16:53:54 (+), Tim Woodall wrote: > I run the following command to switch my caps-lock to escape: > xmodmap -e 'clear Lock' -e 'keycode 0x42 = Escape' > > However, if I disconnect and reconnect my keyboard (I have a KVM switch > box so this happens quite a lot) the setting is lost. > > Before I start writing udev rules to auto reapply this setting when the > keyboard is (re)attached, is there some other, better, way to make this > setting stick? You could try editing /etc/console-setup/remap.inc and running # dpkg-reconfigure console-setup A change at that level might be inherited by whatever's restarting and causing you to lose the settings. Note that for whatever reason (lost in the mists), I always run dpkg-reconfigure console-setup while X is not running, ie not even in a C-A-Fn virtual console. That constraint might have changed, IDK. Cheers, David.
Re: Debian 11.1, xfce4-terminal, select entire line, middle-click, newline not pasted
On Mon 06 Dec 2021 at 09:28:33 (+0100), Thomas Schmitt wrote:
> Mike Kupfer wrote:
> > If you use bash,
> > https://utcc.utoronto.ca/~cks/space/blog/unix/BashBracketedPasteChange
> > probably explains what you're seeing.
>
> This is one of the mornings when i look into my mailbox and want to
> repeatedly scream a popular german 7-to-8 letter word.
> No wonder that many people are reluctant to upgrade their operating
> system after they got it to work as desired.
>
> Maybe it's about time to create bashvuan ?
Having just started using bullseye, I must admit I'm already missing
the inverse-video aspect of bracketed paste when I go back to buster
(where I manually configured bracketed paste after seeing this thread).
However, I was already setting XTerm*cutNewline: false, and I do
paste at point(emacs)/cursor position, and not where I pasteClick¹.
Whether you use these two options might influence how desirable
bracketed paste is in the first place. It's a matter of taste.
¹ Paste at point is obviously more beneficial when you paste as
frequently by keyboard (Shift-Insert) as by mouse ("middle"
button), the position of the mouse being indeterminate or even
invisible with the keyboard paste.
Cheers,
David.
Re: 8 -> 9 update changing things
On Thu 16 Dec 2021 at 16:56:22 (-0500), Roy J. Tellason, Sr. wrote: > On Thursday 16 December 2021 02:49:17 pm Andrew M.A. Cater wrote: > > On Thu, Dec 16, 2021 at 02:35:43PM -0500, Roy J. Tellason, Sr. wrote: > > > I'd posted about my update a while back, and while some folks were > > > encouraging me to go all the way to 11 since it's the current version, > > > my thinking has been to see how things are working, what's changed, > > > what broke, etc. and deal with all of that before I continue on in the > > > update process. > > > > > > Some of the things I'm dealing with are: > > > > > > 1. An annoying blue dot showed up in my taskbar. > > > Right-clicking on this gave me an option to "quit", which I would do, > > > and then within a few seconds it would come right back again! I finally > > > tracked this down to being "KDEaccessible", which I've done nothing to > > > invoke and don't know why the upgrade put that in there. I solved the > > > problem by using synaptic to uninstall the package, since I have no use > > > for it. > > > > > > > This one is solved for the moment, then. > > Yeah, but why the heck did this get turned on in the first place? Or even > installed? One might hypothesise that . you run KDE, and KDE makes cvhanges that aren't always popular with every user. . KDE recommends kdeaccessibility depends on kaccessible. . KDE make changes to kaccessible for people who require and use it. Seems reasonable. > > > 2. My virtual (older) Slackware virtualbox install is seeing a few issues. > Under Slackware it's a very old version of KDE, which I much prefer to the > newer stuff. Yes, that's what I meant above. I think there's a cohort who use TDE instead. > It bugs me that things get changed, for no apparent reason, and that stuff > gets added, likewise. The reasons are often made apparent in the packages' changelogs. > > > There's probably more, but I would like to get these things ironed out > > > before I go chasing any more stuff, and before I continue on the upgrade > > > path... This list, from four years ago, might be a good place to look for threads talking about these problems the first time around. But I can't help thinking of someone laying a carpet before they've painted the ceiling, or vacuuming the floor before dusting the furniture. Better to create just one big mess and then clear it all up in one go? > But upgrading involves me copying a whole pile of stuff over to my > server, including some really large files that are involved in Virtualbox > and the one snapshot I have, and then figuring out a whole mess of detailed > stuff that I need to do to make the upgrade happen. Each time you upgrade?! > Last time it was something like 3 or 4 days before I was back to anything > remotely resembling normal, and I'm not looking forward to the next time (or > two). Cheers, David.
doas 101 question
bullseye 11.1, 5.10.0-9-amd64, doas 6.8.1-2
How to configure /etc/doas.conf so a non-root user gets root's PATH?
Neither of these options work when attempting to execute a command in
/usr/sbin via doas (e.g., 'doas '):
permit nopass setenv {
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin }
dnewman as root
permit nopass keepenv root as root
permit nopass setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } dnewman as root
permit nopass keepenv root as root
The latter is from doas on OpenBSD, but I think that works because
non-root user accounts already have various sbins in their PATH.
I'm aware that linux-utils changed behavior a few years ago, and that
non-root users have a more restricted PATH. However, I'm unclear on what
steps to take so that non-root users can temporarily use root's PATH.
Thanks.
dn
Re: doas 101 question
On Fri, Dec 17, 2021 at 12:20:43PM -0800, David Newman wrote:
> How to configure /etc/doas.conf so a non-root user gets root's PATH?
This works for me:
unicorn:~$ PATH=/usr/local/bin:/usr/bin:/bin
unicorn:~$ cat /etc/doas.conf
permit setenv {
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } greg
unicorn:~$ doas env | grep PATH
doas (greg@unicorn) password:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> permit nopass setenv {
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } dnewman
> as root
> permit nopass keepenv root as root
>
> permit nopass setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } dnewman as root
> permit nopass keepenv root as root
You've got two contradictory lines for "dnewman as root", with the latter
having a setenv clause without PATH in it. I would imagine the latter
wins out (because it occurs last), and therefore your PATH variable doesn't
get set.
I don't know how repeated "dnewman as root" lines would be handled if only
one of them had a setenv clause. You could experiment and find out. It
would be easier just to get rid of the second line.
Re: doas 101 question
On 12/17/21 8:16 PM, Greg Wooledge wrote:
On Fri, Dec 17, 2021 at 12:20:43PM -0800, David Newman wrote:
How to configure /etc/doas.conf so a non-root user gets root's PATH?
This works for me:
unicorn:~$ PATH=/usr/local/bin:/usr/bin:/bin
unicorn:~$ cat /etc/doas.conf
permit setenv {
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } greg
unicorn:~$ doas env | grep PATH
doas (greg@unicorn) password:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Thanks for this. I get similar results where doas shows root's PATH --
but I cannot execute a file called '/usr/local/sbin/s', which is owned
by root:root and has 0750 permissions, unless I specify the full path:
dnewman@coppi:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
dnewman@coppi:~$ cat /etc/doas.conf
permit nopass setenv {
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } dnewman
dnewman@coppi:~$ doas env | grep PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
dnewman@coppi:~$ doas s mailman3
doas: s: command not found
dnewman@coppi:~$ doas /usr/local/sbin/s mailman3
● mailman3.service - GNU Mailing List Manager
..
permit nopass setenv {
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } dnewman
as root
permit nopass keepenv root as root
permit nopass setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } dnewman as root
permit nopass keepenv root as root
You've got two contradictory lines for "dnewman as root", with the latter
having a setenv clause without PATH in it.
Clarification: The examples in my previous email were two different
two-line configurations. It wasn't a four-line doas.conf file.
The second two-line example was taken from an OpenBSD box where invoking
doas allows execution without the full path. However, in that case I
think it's because regular users already have /usr/local/sbin in their
PATH, and so possibly unrelated to doas.
I would imagine the latter
wins out (because it occurs last), and therefore your PATH variable doesn't
get set.
I don't know how repeated "dnewman as root" lines would be handled if only
one of them had a setenv clause. You could experiment and find out. It
would be easier just to get rid of the second line.
Good idea. Per the example above it's just one line now, similar to yours.
dn
Re: doas 101 question
On Fri, 17 Dec 2021, David Newman wrote:
Thanks for this. I get similar results where doas shows root's PATH -- but I
cannot execute a file called '/usr/local/sbin/s', which is owned by root:root
and has 0750 permissions, unless I specify the full path:
dnewman@coppi:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
dnewman@coppi:~$ cat /etc/doas.conf
permit nopass setenv {
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin } dnewman
dnewman@coppi:~$ doas env | grep PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
dnewman@coppi:~$ doas s mailman3
doas: s: command not found
dnewman@coppi:~$ doas /usr/local/sbin/s mailman3
? mailman3.service - GNU Mailing List Manager
..
Do you have an alias for s?
tim@einstein(4):~$ l
/home/tim/bin/l says hello world
tim@einstein(4):~$ alias l='PATH=/bin l'
tim@einstein(4):~$ l
bash: l: command not found
tim@einstein(4):~$ /home/tim/bin/l
/home/tim/bin/l says hello world
The other thing I can think of is you need to run hash -r
(I don't know what doas is, I'm just making guesses)
