Re: Debian Sid/Unstable is not a rolling user distro [WAS:Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size]

2024-07-19 Thread tomas
On Fri, Jul 19, 2024 at 09:25:22AM +0200, didier gaumet wrote:
> Le 19/07/2024 à 05:12, songbird a écrit :

[...]

> You are perfectly right: there is no contract and one i free to use which
> Debian distro one wants to...

Actually, there /is/ a contract:

  https://www.debian.org/social_contract

It's just another kind of contract than the usual "I pay you,
so you do what I say". In my eyes a kinder, deeper, more humane
kind of contract.

One of the things I love Debian for.

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: Debian Sid/Unstable is not a rolling user distro [WAS:Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size]

2024-07-19 Thread didier gaumet

Le 19/07/2024 à 09:43, to...@tuxteam.de a écrit :

On Fri, Jul 19, 2024 at 09:25:22AM +0200, didier gaumet wrote:

Le 19/07/2024 à 05:12, songbird a écrit :


[...]


You are perfectly right: there is no contract and one i free to use which
Debian distro one wants to...


Actually, there /is/ a contract:

   https://www.debian.org/social_contract

It's just another kind of contract than the usual "I pay you,
so you do what I say". In my eyes a kinder, deeper, more humane
kind of contract.

One of the things I love Debian for.

Cheers


My bad, I do know the existence of the Debian social contract but have 
not worded accurately enough what I wanted to say. I should have written 
something like:


"You are perfectly right: there is no such Debian contract that forbids 
one to use whatever (Testing, Unstable, Experimental...) Debian distro 
one wants to..."


Thank you Tomas :-)



Re: Debian Sid/Unstable is not a rolling user distro [WAS:Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size]

2024-07-19 Thread tomas
On Fri, Jul 19, 2024 at 10:07:14AM +0200, didier gaumet wrote:

[...]

> > One of the things I love Debian for.
> > 
> > Cheers
> 
> My bad, I do know the existence of the Debian social contract but have not
> worded accurately enough what I wanted to say. I should have written
> something like:

No bad. I perfectly understood what you meant. My notice was rather aimed
to some visitor from a distant galaxy (or to some confused future self :)

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: VirtualBox (VB) and Windows on Debian

2024-07-19 Thread Jeffrey Walton
On Thu, Jul 18, 2024 at 8:33 PM  wrote:
>
> On Wednesday, 17 July 2024 21:31:00 BST Jeffrey Walton wrote:
> > On Tue, Jul 16, 2024 at 1:35 PM jeremy ardley 
> wrote:
> > > On 16/7/24 19:31, Tom Browder wrote:
> > > > [...]
> > > There are alternatives that include:
> > >
> > > - KVM/QEMU
> > >
> > > - VMWare Workstation Pro (which is now free for private use)
> > >
> > > In my experience KVM/QEMU is fairly stable. The VMWare product not so
> > > much.
> > >
> > > Given everything is virtual you can easily try all options in an hour or
> > > two.
> >
> > Add a "mee too" for KVM/QEMU/libvirt. The components are managed by
> > the kernel, so there are usually no technical problems, like unsigned
> > modules. Virt Manager takes a little getting used to, but everything
> > you need is there.
> >
> > The only downside to KVM/QEMU/libvirt is networking in some cases.
> > Configuring a VM to use your local DHCP server is a pain because you
> > have to setup and configure the bridging yourself. And the
> > documentation to do it does not exist.
>
> Out of interest, how is one supposed to do it now? I set mine up ages ago via
> /etc/network/interfaces - eg..
>
> auto br0
> iface br0 inet dhcp
> bridge_portsenp4s0
> bridge_stp  off
> bridge_fd   0
> bridge_maxwait  0
>
> ..but I have no idea how to do it now. Manpage says 'brctl' is obsolete and
> points to 'bridge' which I've never used.

Yeah, I have an old server that was setup using the old commands, like
brctl. It has been so long I don't recall the steps I used to
configure it.

For a modern install on Debian with Systemd and Network Manager (and
not systemd-network), here are the rough steps I follow.

1. Ignore anything from `sudo -E virsh net-edit default`. You don't
use the default NAT. You use virbr0 instead.

2. Install nmtui.

3. `sudo nmtui`, then 'Edit a connection." Select bridge virbr0.

* Under slaves, add Ethernet Connection 1. Check Automatically
Connect and Available to All Users.

* Under IPv4, select Automatic. Remove addresses and friends.

* Under IPv6, select Disabled. I don't run IPv6 internally.

4. Reboot the machine.

5. After reboot and login, you should see ethernet UP, vbridge UP, and
the host has a DHCP address via the bridge.

$ ip link show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s20f0u3c2:  mtu 1500 qdisc fq_codel mast
er virbr0 state UP mode DEFAULT group default qlen 1000
   link/ether 20:7b:d2:8c:55:d4 brd ff:ff:ff:ff:ff:ff
3: wlo1:  mtu 1500 qdisc noqueue state DOWN m
ode DORMANT group default qlen 1000
   link/ether 9a:28:0e:bd:f4:ee brd ff:ff:ff:ff:ff:ff permaddr 00:41:0e:67:0e:7
b
   altname wlp87s0
4: virbr0:  mtu 1500 qdisc noqueue state UP mod
e DEFAULT group default qlen 1000
   link/ether 20:7b:d2:8c:55:d4 brd ff:ff:ff:ff:ff:ff

And:

$ ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group defaul
t qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
  valid_lft forever preferred_lft forever
2: enp0s20f0u3c2:  mtu 1500 qdisc fq_codel mast
er virbr0 state UP group default qlen 1000
   link/ether 20:7b:d2:8c:55:d4 brd ff:ff:ff:ff:ff:ff
3: wlo1:  mtu 1500 qdisc noqueue state DOWN g
roup default qlen 1000
   link/ether 9e:8e:8a:6f:35:5e brd ff:ff:ff:ff:ff:ff permaddr 00:41:0e:67:0e:7
b
   altname wlp87s0
4: virbr0:  mtu 1500 qdisc noqueue state UP gro
up default qlen 1000
   link/ether 20:7b:d2:8c:55:d4 brd ff:ff:ff:ff:ff:ff
   inet 172.16.2.15/12 brd 172.31.255.255 scope global dynamic noprefixroute vi
rbr0
  valid_lft 6293sec preferred_lft 6293sec

6. In Virtual Machine Manager, select a VM, select NIC, choose Bridge
device... and select virbr0.

7. Start the VM. The VM will get an IP address from your local DHCP server.

You might find these commands useful if you don't (yet) have a bridge:
 and maybe this
discussion: .

Jeff



Re: Debian Sid/Unstable is not a rolling user distro [WAS:Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size]

2024-07-19 Thread didier gaumet

Le 19/07/2024 à 09:25, didier gaumet a écrit :
[...]
You are perfectly right: there is no contract and one i free to use 
which Debian distro one wants to...

[...]

typo error, sorry:

You are perfectly right: there is no contract and one is free to use
 which Debian distro one wants to...




Debian Sid/Unstable is not a rolling user distro [WAS:Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size]

2024-07-19 Thread didier gaumet

Le 19/07/2024 à 05:12, songbird a écrit :

The Wanderer wrote:
...

By taking on yourself the risk and burden of running sid, you are
volunteering to be one of those who helps notice issues before they
reach testing, and report those issues so that the machinery of the
archive can stop the package versions which those issues from migrating
to testing. Ideally, you are also volunteering to be one of those who
helps the package maintainers track down and fix the issues.


   there is no such contract.  just like Debian Developers and
other volunteers are not forced to do work they would not wish
to do.  however, Debian Developers and others do have a social
agreement and other rules they do pledge to abide by.


You are perfectly right: there is no contract and one i free to use 
which Debian distro one wants to...



   a simple user?  anyone using any version, there's no contract
we agree to for such use.

[...]
... but to me that seems ignoring what appears (to me, again) the main 
goal of Debian: to provide a *stable* *user* (i.e.: to be used) distro.
A mean to this goal is to provide *testers* a way to test preparation of 
the next stable release with, first, an *unstable* distro, and then a 
*testing* distro.


The names of Debian distros are a down-to-earth declaration of intent:
- Stable is meant to be usable and stable
- Testing is meant to be tested
- Unstable is not meant to be stable
- Sid is the guy in the movie who *breaks* his toys

So if one chooses to *use* anything other than Stable, basically, one is 
not considered a user but a tester:

https://www.debian.org/doc/manuals/debian-faq/choosing.en.html

To me a common misconception is to compare Debian 
Unstable(+Experimental) to, say, the main distro of Archlinux or 
Opensuse Tumbleweed, because they are rolling release distros.
For example, Archlinux has Stable repositories, and also have Testing 
and Staging repositories.
The warning in Archlinux is as clear (to me) as in Debian: Stable is 
meant to be used, Testing and Staging are meant to be tested, "users" of 
these repositories are de facto, from Arch POV, considered testers.

https://wiki.archlinux.org/title/Official_repositories#

All that does *not* prevent nor forbid someone to *use* anything else 
than the Stable channel of Debian or Arch, obviously :-)




Re: stty permanently undef "start"

2024-07-19 Thread Max Nikulin

On 12/07/2024 10:56, Max Nikulin wrote:


I have a question opposite to the original one. Is it possible to 
disable xon&xoff for bash prompt, but enable it while foreground

commands are running?
I do not mind to use forward search in readline history.


As to the original question, Emacs and Vim disable flow control while 
they are active, so it is possible to use Control-s there without any 
wrapper. Now I think that it is failure of rtorrent if it does not 
manage ixon state.


Managing separate ixon state for prompt and for commands in BASH is more 
tricky than I expected. Perhaps I should try to patch C code instead. 
BASH saves and restores terminal state at some steps. As a result, PS1 
is more suitable for calling "stty -ixon" than PROMPT_COMMAND. If the 
same command is called through a key sequence ("bind -x") then state 
before prompt is restored before PS0 expansion and command execution. 
Frankly speaking, I infrequently regretted that C-s did not stat search. 
The feature does not cost time spent in the state "it is almost working 
already". Perhaps there are still cases when ixon state is switched 
incorrectly.


For the case that somebody else is brave enough to try it, see

Maybe mailing list filter correctly assessed that it does not deserve to 
be posted here.




the usage of env

2024-07-19 Thread pyh

Hello list,

I am not sure how 'env' command works.

for example, what's the difference between '/usr/bin/perl' and 'env
perl' ?

I know env may set a environment variable in system, so my question also
includes:

1. where to see a shell environment variable? I tried 'echo $ENV'
showing nothing.

2. then I tried the following one-line perl to search for 'perl'
environment variable.

$ perl -le 'for( keys %ENV ){print "$_ --> $ENV{$_}"}' |grep perl
_ --> /usr/bin/perl

the key for perl is "_" in environment variable? under this key, why
'env perl' just works?

Thanks for your help.

regards.
timothy




Re: the usage of env

2024-07-19 Thread Greg Wooledge
On Fri, Jul 19, 2024 at 20:12:14 +0800, p...@gmx.it wrote:
> for example, what's the difference between '/usr/bin/perl' and 'env
> perl' ?

"env perl" searches your $PATH.

> I know env may set a environment variable in system, so my question also
> includes:

env is used to *display* the current shell environment, or to set a new
environment for *one* specific process.

E.g.

env FOO=bar ./myprogram

This launches ./myprogram with the additional environment variable FOO
set to the value bar.

> 1. where to see a shell environment variable? I tried 'echo $ENV'
> showing nothing.

Just run env with no arguments.

> the key for perl is "_" in environment variable? under this key, why
> 'env perl' just works?

The _ environment variable is weird.  Please ignore it for now.  You
can live a full and happy life without ever worrying about it.



Re: Remote desktop Debian -> ChromeBook

2024-07-19 Thread Anssi Saari
Nicolas George  writes:

> Would perchance somebody here have already investigated a similar need
> and be able to tell which solutions are the most promising in terms of
> reliability and user experience.

I've mostly used VNC and x2go for Windows-to-Linux and Linux-to-Linux.

VNC was and is:
- Solid and we actually use it at work too.
- Limited in the number of mouse buttons at some point to five, minor
  but annoying. At the time I was used to 7.
- In VNC you run a desktop in the remote end so that needs to be
  configured and maintained. I'm not a fan of this since it's usually
  just a small handful of apps I want to run.

x2go was:
- Slow to connect.
- Reconnects from another machine were a hit or miss, mostly miss.
  So it really wasn't "screen for GUI apps" although that would've
  been useful.
- Keyboard mappings via xmodmap were sometimes ignored.
- It didn't have the mouse button limitation of VNC.
- It has a mode where it presents a list of apps on the remote machine
  so don't need to setup a desktop, can just start the app you want.

I don't know if my little gripes about x2go are valid today, I now use
it occasionally from Windows to Linux. Certainly the connection is slow
to form even in a LAN.

xpra I've tried some years ago but the documentation wasn't very clear
to me. Especially how to resume a session. Haven't looked in a while.



Re: the usage of env

2024-07-19 Thread Thomas Schmitt
Hi,

p...@gmx.it wrote:
> I am not sure how 'env' command works.

Read the output of

  man env


> for example, what's the difference between '/usr/bin/perl' and 'env perl' ?

Reading the man page i'd say it's the same difference as between
"/usr/bin/perl" and "perl". I.e. the former runs explicitely a particular
program file, whereas the latter runs a program file which the shell
picks for you, depending on the setting of the PATH variable.

  echo "$PATH"


> I know env may set a environment variable in system,

Not "in system", but for the particular program run which gets started by
"env". "man env" says:

  SYNOPSIS
   env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]

  DESCRIPTION
 Set each NAME to VALUE in the environment and run COMMAND.

The NAME=VALUE pairs will be in effect only as long as "env" and the
started program run.


(In a bash shell, the main advantages over plain
  [NAME=VALUE]... [COMMAND [ARG]...]
are probably the env option -i, which disables all inherited exported
variables, and -u which disables a particular inherited variable.)


> so my question also includes:
> 1. where to see a shell environment variable? I tried 'echo $ENV'
> showing nothing.

If you want to see all exported variables:

  env

because the statement in "man env":

  If no COMMAND, print the resulting environment.

Example shell session (with prompt "$"):

  $ export x=X
  $ y=Y
  $ echo "$x"
  X
  $ echo "$y"
  Y
  $ env | grep '^[xy]='
  x=X
  $

The not exported variale "y" does not show up in env's output.


> why 'env perl' just works?

Program "env" (or its helpers) finds a program file with name "perl"
in one of the directories which are listed in $PATH.


Have a nice day :)

Thomas



Re: the usage of env

2024-07-19 Thread Michel Verdier
On 2024-07-19, p...@gmx.it wrote:

> $ perl -le 'for( keys %ENV ){print "$_ --> $ENV{$_}"}' |grep perl
> _ --> /usr/bin/perl
>
> the key for perl is "_" in environment variable? under this key, why
> 'env perl' just works?

Perl $_ is the current (unnamed) value of your loop "for". You could
write it like this:
foreach my $key (keys %ENV) { print "$key=$ENV{$key}" }

https://perldoc.perl.org/variables



Re: Remote desktop Debian -> ChromeBook

2024-07-19 Thread Greg Wooledge
On Fri, Jul 19, 2024 at 15:33:40 +0300, Anssi Saari wrote:
> I've mostly used VNC and x2go for Windows-to-Linux and Linux-to-Linux.
> 
> VNC was and is:
> - Solid and we actually use it at work too.
> - Limited in the number of mouse buttons at some point to five, minor
>   but annoying. At the time I was used to 7.
> - In VNC you run a desktop in the remote end so that needs to be
>   configured and maintained. I'm not a fan of this since it's usually
>   just a small handful of apps I want to run.

You don't *have* to run a full desktop on the remote end.  You can run
a smaller, lighter set of applications if that suits your needs.

At work, I maintain a set of VNC sessions on Linux workstations for remote
Windows users to use.  The workstations themselves have KDE installed,
and if someone's sitting locally in front of the machine, they can login
and use KDE, with all of its bells and whistles.  But for the VNC sessions,
I use fvwm, with a customized menu, and a set of programs that get launched
at session start.

In my experience, the Windows users have been able to adjust to this
quite easily.  After they were told how to open the menu from the
"background", everything else was intuitive.

The only difficult thing was getting copy/paste to work.  I did this by
installing the "autocutsel" package on the workstations, and adding

autocutsel -fork

to the ~/.vnc/xstartup scripts.  Then I added crontabs to launch the VNC
sessions at boot time.  Each user is "assigned" to a specific VNC session,
which is launched with a resolution customized for their monitor(s).  If
they change their monitors and need the VNC session to run at a different
resolution, they contact me, and I work with them to get it changed.  (In
theory they could ssh into the workstation and do it all themselves, if
they knew how.)

It's been working well for us.



Re: the usage of env

2024-07-19 Thread The Wanderer
On 2024-07-19 at 09:02, Michel Verdier wrote:

> On 2024-07-19, p...@gmx.it wrote:
> 
>> $ perl -le 'for( keys %ENV ){print "$_ --> $ENV{$_}"}' |grep perl
>> _ --> /usr/bin/perl
>>
>> the key for perl is "_" in environment variable? under this key, why
>> 'env perl' just works?
> 
> Perl $_ is the current (unnamed) value of your loop "for". You could
> write it like this:
> foreach my $key (keys %ENV) { print "$key=$ENV{$key}" }
> 
> https://perldoc.perl.org/variables

I think the question was not about the '$_' variable in the perl
expression, but about the '_' variable in the output, which in this case
contains the full path to the 'perl' binary.

$ env | grep ^_
_=/usr/bin/env

That appears to be a (shell?) environment variable. Greg commented on
it, as being a weird thing that you will probably never need to worry
about. I have done some experimenting with it, and it appears to hold
the equivalent of argv[0] for the command line which invoked the current
process - but the logic for determining what that is may well not be
intuitive for many people.

'echo $_' produces the full path to 'echo'.

'sh /tmp/testme' (where that file is a '#!/bin/sh' script which runs
'echo $_') produces the full path to 'sh'.

'bash /tmp/testme' (with the script shebang line still pointing to
/bin/sh) produces the full path to 'bash'.

'chmod +x /tmp/testme' followed by '/tmp/testme' produces '/tmp/testme'.


All in all, I think I agree with Greg's description.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Re: Debian 12.6: Screen won't come back on if monitor is power cycled

2024-07-19 Thread Johan Sjölin

On 7/17/24 23:30, Kent West wrote:


Try pressing a shift key a couple of times, and then blindly typing your user 
password. > My guess is that the screensaver/lock is wonky.


Doesn't work. I don't use any screensaver or automatic screen lock.

Whenever I power cycle the monitor, I get the error message below (found 
in journalctl):


jul 19 00:59:43 galaktikos gnome-shell[1748]: Failed to create colord 
device for 'xrandr-Samsung Electric Company-S27E650-H4ZH102483': failed 
to obtain org.freedesktop.color-manager.create-device auth


--

Johan Sjölin



Re: Why is Firefox crashing so much lately?

2024-07-19 Thread Gary Dale

On 2024-07-18 09:52, Gary Dale wrote:

On 2024-07-17 21:25, Gary Dale wrote:
I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over 
X desktop. Firefox 115.12.0esr is crashing multiple times per day. It 
frequently happens when page I'm transfers to another page that 
creates a PDF or just has a complicated link. It's annoying.


To visit some pages, I have to use Chromium instead.  Earlier today I 
had to rename a sessionstore-backups json file because Firefox got 
caught in loop where it recognized it had a new tab open but the tab 
caused it to crash.


I also have found that at least one site refuses to work with 115. 
That's been going on for a while. Again, I have to use Chromium for 
that site.


Thanks for the tips guys, but I'm not going to switch to XFCE, I'm 
using an old AMD graphics card, it's a desktop machine, and the 
problem isn't specific to PDFs - although that seems to be one of the 
major triggers.


My system has been upgrading from earlier versions of Debian since 
Potato. I've been on Trixie since it became the new testing. This 
crashing of Firefox is a new issue - had few problems with Trixie 
before that.


I'm beginning to suspect it may be related to my recent introduction 
of a Pi-Hole into my network. Could it be a problem for Firefox when 
it gets a 0.0.0.0 address returned on a DNS lookup?


Well, I can confirm it's not the Pi-Hole. Took it out of the DNS chain 
and Firefox is still crashing frequently. In fact, it's worse today. Now 
it crashes when I'm on Facebook and scrolling down using the mouse wheel.




Re: Why is Firefox crashing so much lately?

2024-07-19 Thread The Wanderer
On 2024-07-19 at 10:34, Gary Dale wrote:

> On 2024-07-18 09:52, Gary Dale wrote:

>> Thanks for the tips guys, but I'm not going to switch to XFCE, I'm
>> using an old AMD graphics card, it's a desktop machine, and the 
>> problem isn't specific to PDFs - although that seems to be one of
>> the major triggers.
>> 
>> My system has been upgrading from earlier versions of Debian since
>> Potato. I've been on Trixie since it became the new testing. This
>> crashing of Firefox is a new issue - had few problems with Trixie
>> before that.
>> 
>> I'm beginning to suspect it may be related to my recent
>> introduction of a Pi-Hole into my network. Could it be a problem
>> for Firefox when it gets a 0.0.0.0 address returned on a DNS
>> lookup?
> 
> Well, I can confirm it's not the Pi-Hole. Took it out of the DNS
> chain and Firefox is still crashing frequently. In fact, it's worse
> today. Now it crashes when I'm on Facebook and scrolling down using
> the mouse wheel.

What kind of crashes are we talking about? I think there may be an
'about:crashes' or similar type of page built in to Firefox, which could
give information about what it's seen happen.

If it's memory-access-related, there might be benefit to trying to e.g.
run under valgrind, intentionally reproduce a crash, and see what that
tool reports. Then again, Firefox is a sufficiently complex app that
that might not be fruitful.

Have you tried running any hardware-error checking tools, e.g. one of
the memtest suites? Crashes that frequent (with software, versions, and
data which other people do not reproduce the problem with) suggest a
possible hardware issue to my mind, although if nothing else is
exhibiting visible issues that makes the hardware a less likely culprit.

Is there any possibility that something in the library/etc. stack which
Firefox sits on top of may be unreliable, or at least be of different
versions from those which the people not observing the problem are
using? One obvious candidate would probably be the graphics stack
(driver, firmware, etc.), but that's not necessarily the only possibility.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Re: Why is Firefox crashing so much lately?

2024-07-19 Thread Gary Dale

On 2024-07-19 10:42, The Wanderer wrote:

On 2024-07-19 at 10:34, Gary Dale wrote:


On 2024-07-18 09:52, Gary Dale wrote:

Thanks for the tips guys, but I'm not going to switch to XFCE, I'm
using an old AMD graphics card, it's a desktop machine, and the
problem isn't specific to PDFs - although that seems to be one of
the major triggers.

My system has been upgrading from earlier versions of Debian since
Potato. I've been on Trixie since it became the new testing. This
crashing of Firefox is a new issue - had few problems with Trixie
before that.

I'm beginning to suspect it may be related to my recent
introduction of a Pi-Hole into my network. Could it be a problem
for Firefox when it gets a 0.0.0.0 address returned on a DNS
lookup?

Well, I can confirm it's not the Pi-Hole. Took it out of the DNS
chain and Firefox is still crashing frequently. In fact, it's worse
today. Now it crashes when I'm on Facebook and scrolling down using
the mouse wheel.

What kind of crashes are we talking about? I think there may be an
'about:crashes' or similar type of page built in to Firefox, which could
give information about what it's seen happen.

If it's memory-access-related, there might be benefit to trying to e.g.
run under valgrind, intentionally reproduce a crash, and see what that
tool reports. Then again, Firefox is a sufficiently complex app that
that might not be fruitful.

Have you tried running any hardware-error checking tools, e.g. one of
the memtest suites? Crashes that frequent (with software, versions, and
data which other people do not reproduce the problem with) suggest a
possible hardware issue to my mind, although if nothing else is
exhibiting visible issues that makes the hardware a less likely culprit.

Is there any possibility that something in the library/etc. stack which
Firefox sits on top of may be unreliable, or at least be of different
versions from those which the people not observing the problem are
using? One obvious candidate would probably be the graphics stack
(driver, firmware, etc.), but that's not necessarily the only possibility.

Looking at the submitted and unsubmitted reports, it seems the crashing 
started on July 10. It always seems to be "CanvasRenderer" as the 
culprit with libxul.so as the guilty module. Firefox was reportedly 
installed 32 days ago.


Anyway, the Firefox developers have received dozens of automated crash 
reports from me over the past10 days.


I do have a rather old graphics card, but it's an AMD one so the drivers 
should be OK. I doubt it's anything else hardware related as I'm not 
having problems with other programs.


The only other things of note:
1) my screen does briefly go blank sometimes while doing something 
involving windows.

2) Plasma 5 isn't saving my desktop when I reboot.



Re: Why is Firefox crashing so much lately?

2024-07-19 Thread Gary Dale

On 2024-07-19 11:09, Gary Dale wrote:

On 2024-07-19 10:42, The Wanderer wrote:

On 2024-07-19 at 10:34, Gary Dale wrote:


On 2024-07-18 09:52, Gary Dale wrote:

Thanks for the tips guys, but I'm not going to switch to XFCE, I'm
using an old AMD graphics card, it's a desktop machine, and the
problem isn't specific to PDFs - although that seems to be one of
the major triggers.

My system has been upgrading from earlier versions of Debian since
Potato. I've been on Trixie since it became the new testing. This
crashing of Firefox is a new issue - had few problems with Trixie
before that.

I'm beginning to suspect it may be related to my recent
introduction of a Pi-Hole into my network. Could it be a problem
for Firefox when it gets a 0.0.0.0 address returned on a DNS
lookup?

Well, I can confirm it's not the Pi-Hole. Took it out of the DNS
chain and Firefox is still crashing frequently. In fact, it's worse
today. Now it crashes when I'm on Facebook and scrolling down using
the mouse wheel.

What kind of crashes are we talking about? I think there may be an
'about:crashes' or similar type of page built in to Firefox, which could
give information about what it's seen happen.

If it's memory-access-related, there might be benefit to trying to e.g.
run under valgrind, intentionally reproduce a crash, and see what that
tool reports. Then again, Firefox is a sufficiently complex app that
that might not be fruitful.

Have you tried running any hardware-error checking tools, e.g. one of
the memtest suites? Crashes that frequent (with software, versions, and
data which other people do not reproduce the problem with) suggest a
possible hardware issue to my mind, although if nothing else is
exhibiting visible issues that makes the hardware a less likely culprit.

Is there any possibility that something in the library/etc. stack which
Firefox sits on top of may be unreliable, or at least be of different
versions from those which the people not observing the problem are
using? One obvious candidate would probably be the graphics stack
(driver, firmware, etc.), but that's not necessarily the only 
possibility.


Looking at the submitted and unsubmitted reports, it seems the 
crashing started on July 10. It always seems to be "CanvasRenderer" as 
the culprit with libxul.so as the guilty module. Firefox was 
reportedly installed 32 days ago.


Anyway, the Firefox developers have received dozens of automated crash 
reports from me over the past10 days.


I do have a rather old graphics card, but it's an AMD one so the 
drivers should be OK. I doubt it's anything else hardware related as 
I'm not having problems with other programs.


The only other things of note:
1) my screen does briefly go blank sometimes while doing something 
involving windows.

2) Plasma 5 isn't saving my desktop when I reboot.


It's not X11 either. It's happening when I use Plasma 5 on Wayland.




Re: Debian 12.6: Screen won't come back on if monitor is power cycled

2024-07-19 Thread debian-user
Johan Sjölin  wrote:
> On 7/17/24 23:30, Kent West wrote:
> 
> > Try pressing a shift key a couple of times, and then blindly typing
> > your user password. > My guess is that the screensaver/lock is
> > wonky.  
> 
> Doesn't work. I don't use any screensaver or automatic screen lock.
> 
> Whenever I power cycle the monitor, I get the error message below
> (found in journalctl):
> 
> jul 19 00:59:43 galaktikos gnome-shell[1748]: Failed to create colord 
> device for 'xrandr-Samsung Electric Company-S27E650-H4ZH102483':
> failed to obtain org.freedesktop.color-manager.create-device auth

There's a thread at https://bbs.archlinux.org/viewtopic.php?id=228663
that might be relevant?



Re: Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

2024-07-19 Thread Celejar
Ash Joubert wrote:

> On 2024-07-19 02:32, Celejar wrote:
> 
> I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
> running out of space on /boot:
> update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
> zstd: error 70 : Write error : cannot write block : No space left on 
> device
> E: mkinitramfs failure zstd -q -9 -T0 70
> update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
> It turns out that the initrd for 6.9.9 is more than 7x the size of the
> one for 6.9.8!
> 
> 
> I had the same problem. The cause is not the kernel upgrade but the 
> refactoring of non-free firmware packages. firmware-misc-nonfree now 
> recommends firmware-nvidia-graphics, causing it to be installed:
> 
> 
> $ apt-cache show firmware-misc-nonfree
> [...]
> 
> Recommends: firmware-nvidia-graphics, firmware-intel-graphics, 
> firmware-intel-misc, firmware-mediatek
> 
> 
> 
> I am not using an nvidia gpu so the fix for me was:
> 
> apt-get purge firmware-nvidia-graphics
> 
> 
> There was NEWS when I dist-upgraded:
> 
> $ zcat /usr/share/doc/firmware-misc-nonfree/NEWS.Debian.gz
> firmware-nonfree (20230625-3~exp1) experimental; urgency=medium
> 
>   Several firmware files were moved from firmware-misc-nonfree into
>   their own package:
>   - firmware-nvidia-graphics: This package now holds the firmware files for
> Nvidia GPU hardware.
>   - firmware-intel-graphics: This package now holds the firmware files
> for Intel Graphics Media Driver chips (mostly i915) as found in
> 'modern' Intel CPUs with integrated graphics in the Broadwell and
> the various 'Lake' CPU series.
> 
> - firmware-intel-misc: This package now holds the firmware files for Intel 
> devices and chips which do not belong in one of the other Intel firmware
> 
> packages. These devices/chips include for example Omni-Path devices,
> Ethernet/Network chips/devices and QuickAssist Technology crypto
> accelerators.
>   - firmware-mediatek: This package now holds the firmware files for
> devices and chips made by MediaTek and Ralink, which is part of
> MediaTek.
> 
> -- Diederik de Haas  Thu, 18 Jan 2024 14:00:00 +0100

Thanks much! *This* type of answer is why I posted here instead of
going straight to the BTS - none of the messages prior to this one
provided any insight as to why I was hitting the problem now, while
other distros had hit it months ago, or where the problem really lay.
As per another message in this thread, I've already filed a bug against
linux-image-6.9.9-amd64, but I suppose I should update the report with
this information, indicating that it's not really a problem with that
package.

-- 
Celejar



Re: umask - default user settings?

2024-07-19 Thread Max Nikulin

On 16/07/2024 20:46, Greg Wooledge wrote:

On Mon, Jul 15, 2024 at 23:39:54 -0400, Greg Wooledge wrote:

Now we just need for GNOME users to discover a way to configure the
programs that are started as children of dbus, and then we can move
forward.  Documentation would be my top priority.  If other people want
to try to drum up interest in environment configuration, then there'll
be documentation available for end users to follow.


I've added a bit of content to .


Isn't the following a more suitable article for umask?

I think, it is better to drop UMask note from EnvironmentVariables.



Re: the usage of env

2024-07-19 Thread Mike Castle
In addition to what everyone else has said about env(1), there is the
fact that Korn derived shells also supports some of the same features.

env VAR1=foo VAR2=bar random-command
VAR1=foo VAR2=bar random-command

If running a Korn-like shell (ksh, bash, zsh), both would set the
envvars VAR1 and VAR2 to those values.  (Note: I don't *think* earlier
Bourne shells support that, but I may be misremembering when the
feature was introduced.  It was likely before even my time.)

However, C-shell derived do not, you must use the env(1) command.

But, env(1) does also offers the -i and -u flags to initialize and
unset envvars.  I use -u a lot during dev/testing to make sure scripts
I write work correctly in various combinations.

mrc



Re: Fwd: using xorriso to create a bootable Linux ISO

2024-07-19 Thread Thomas Schmitt
Hi,

Vijay Kirpalani wrote:
> I am using xorriso to create a bootable Linux ISO and facing some issues.
> Please suggest what i might be doing wrong or missing.

I answered to your identical mail on bug-xorr...@gnu.org . See:
  https://lists.gnu.org/archive/html/bug-xorriso/2024-07/msg3.html

The problem seems not much related to Debian, except the fact that a
Debian ISO is presented by virtual box and GRUB the way we would expect
for a virtual USB stick or hard disk.


Have a nice day :)

Thomas



Re: umask - default user settings?

2024-07-19 Thread Greg Wooledge
On Fri, Jul 19, 2024 at 23:04:25 +0700, Max Nikulin wrote:
> On 16/07/2024 20:46, Greg Wooledge wrote:
> > On Mon, Jul 15, 2024 at 23:39:54 -0400, Greg Wooledge wrote:
> > > Now we just need for GNOME users to discover a way to configure the
> > > programs that are started as children of dbus, and then we can move
> > > forward.  Documentation would be my top priority.  If other people want
> > > to try to drum up interest in environment configuration, then there'll
> > > be documentation available for end users to follow.
> > 
> > I've added a bit of content to 
> > .
> 
> Isn't the following a more suitable article for umask?
> 
> I think, it is better to drop UMask note from EnvironmentVariables.

I've made some minor changes to both pages.



Re: the usage of env

2024-07-19 Thread pyh

On 2024-07-20 00:07, Mike Castle wrote:

In addition to what everyone else has said about env(1), there is the
fact that Korn derived shells also supports some of the same features.

env VAR1=foo VAR2=bar random-command
VAR1=foo VAR2=bar random-command



$ VAR1=foo && ./a.sh
$ export VAR2=foo; ./a.sh
$ ./b.sh


$VAR1 will be seen by a.sh only, but $VAR2 can be seen my current login
session (such as b.sh). Am I right? I am a bit confused about env scope.

Thanks for your kind help.



Re: the usage of env

2024-07-19 Thread Greg Wooledge
On Sat, Jul 20, 2024 at 05:46:23 +0800, p...@gmx.it wrote:
> $ VAR1=foo && ./a.sh
> $ export VAR2=foo; ./a.sh
> $ ./b.sh
> 
> 
> $VAR1 will be seen by a.sh only, but $VAR2 can be seen my current login
> session (such as b.sh). Am I right? I am a bit confused about env scope.

If we assume NO other commands have been executed in this shell so far,
then:

VAR1 is not marked for export.  It's just a regular shell variable.
It won't be seen by either call to ./a.sh which is a (non-subshell)
child process, not will it be seen by ./b.sh which is also a non-subshell
child.

VAR2 is marked for export by the interactive shell.  It's a permanent
part of the shell's environment and will be seen by all child processes
from that point forward.

VAR2 will therefore be seen by the second call to ./a.sh and the call
to ./b.sh.

Now, what you didn't ask, but what I *expected* you to ask, is:

What's the difference between these two commands?
VAR3=foo ./a.sh
VAR3=bar; ./a.sh

In the first command, VAR3 is placed in the environment of the command
being executed.  ./a.sh will see it.  VAR3 will not survive beyond
this command.  It will be discarded, and future commands will not be
aware it ever existed.

In the second command, VAR3 is created as a regular variable in the
current shell, but not exported to the environment.  It will NOT be
seen by ./a.sh, but it WILL be seen by future shell commands within
this session.



Re: the usage of env

2024-07-19 Thread pyh

On 2024-07-20 05:56, Greg Wooledge wrote:

On Sat, Jul 20, 2024 at 05:46:23 +0800, p...@gmx.it wrote:

$ VAR1=foo && ./a.sh
$ export VAR2=foo; ./a.sh
$ ./b.sh


$VAR1 will be seen by a.sh only, but $VAR2 can be seen my current
login
session (such as b.sh). Am I right? I am a bit confused about env
scope.


If we assume NO other commands have been executed in this shell so far,
then:

VAR1 is not marked for export.  It's just a regular shell variable.
It won't be seen by either call to ./a.sh which is a (non-subshell)
child process, not will it be seen by ./b.sh which is also a
non-subshell
child.

VAR2 is marked for export by the interactive shell.  It's a permanent
part of the shell's environment and will be seen by all child processes
from that point forward.

VAR2 will therefore be seen by the second call to ./a.sh and the call
to ./b.sh.


I verified that as follows.

$ VAR=foo ./a.sh
i can see VAR=foo

$ ./a.sh
i can see VAR=

$ VAR=foo; ./a.sh
i can see VAR=

$ export VAR=foo; ./a.sh
i can see VAR=foo

Thanks Greg.



Now, what you didn't ask, but what I *expected* you to ask, is:

What's the difference between these two commands?
VAR3=foo ./a.sh
VAR3=bar; ./a.sh

In the first command, VAR3 is placed in the environment of the command
being executed.  ./a.sh will see it.  VAR3 will not survive beyond
this command.  It will be discarded, and future commands will not be
aware it ever existed.

In the second command, VAR3 is created as a regular variable in the
current shell, but not exported to the environment.  It will NOT be
seen by ./a.sh, but it WILL be seen by future shell commands within
this session.


I can not clearly understand for this statement. what's "future shell
commands"? can you show an example?

regards,
timothy



Re: the usage of env

2024-07-19 Thread Greg Wooledge
On Sat, Jul 20, 2024 at 06:17:46 +0800, p...@gmx.it wrote:
> $ VAR=foo ./a.sh
> i can see VAR=foo

I don't know what "see" means here.

hobbit:~$ cat a.sh
#!/bin/sh
echo "I am a.sh, and inside me, VAR=<$VAR>."
hobbit:~$ unset -v VAR
hobbit:~$ VAR=foo ./a.sh
I am a.sh, and inside me, VAR=.
hobbit:~$ echo "VAR=<$VAR>"
VAR=<>

VAR is defined in the environment of a.sh but NOT in the calling shell.

> > What's the difference between these two commands?
> > VAR3=foo ./a.sh
> > VAR3=bar; ./a.sh
> > 
> > In the first command, VAR3 is placed in the environment of the command
> > being executed.  ./a.sh will see it.  VAR3 will not survive beyond
> > this command.  It will be discarded, and future commands will not be
> > aware it ever existed.
> > 
> > In the second command, VAR3 is created as a regular variable in the
> > current shell, but not exported to the environment.  It will NOT be
> > seen by ./a.sh, but it WILL be seen by future shell commands within
> > this session.
> 
> I can not clearly understand for this statement. what's "future shell
> commands"? can you show an example?

hobbit:~$ unset -v VAR
hobbit:~$ VAR=bar; ./a.sh
I am a.sh, and inside me, VAR=<>.
hobbit:~$ echo "VAR=<$VAR>"
VAR=



Re: the usage of env

2024-07-19 Thread pyh

On 2024-07-20 06:25, Greg Wooledge wrote:


I can not clearly understand for this statement. what's "future shell
commands"? can you show an example?


hobbit:~$ unset -v VAR
hobbit:~$ VAR=bar; ./a.sh
I am a.sh, and inside me, VAR=<>.
hobbit:~$ echo "VAR=<$VAR>"
VAR=


OK I know that. $VAR can be seen by future shell command in this
session, but cannot be seen by a sub-shell such as a.sh.

Thanks.



Re: the usage of env

2024-07-19 Thread Greg Wooledge
On Sat, Jul 20, 2024 at 06:30:42 +0800, p...@gmx.it wrote:
> On 2024-07-20 06:25, Greg Wooledge wrote:
> > > 
> > > I can not clearly understand for this statement. what's "future shell
> > > commands"? can you show an example?
> > 
> > hobbit:~$ unset -v VAR
> > hobbit:~$ VAR=bar; ./a.sh
> > I am a.sh, and inside me, VAR=<>.
> > hobbit:~$ echo "VAR=<$VAR>"
> > VAR=
> 
> OK I know that. $VAR can be seen by future shell command in this
> session, but cannot be seen by a sub-shell such as a.sh.

a.sh is NOT a subshell.  That's really super important.

a.sh is a NON-subshell child process.

In an actual subshell, you *would* see the variable, because subshells
inherit regular variables as well as environment variables.

hobbit:~$ unset -v VAR
hobbit:~$ VAR=foo; (echo "I am a subshell, and VAR=<$VAR>")
I am a subshell, and VAR=
hobbit:~$ ./a.sh
I am a.sh, and inside me, VAR=<>.

https://mywiki.wooledge.org/SubShell



Re: the usage of env

2024-07-19 Thread pyh

On 2024-07-20 06:35, Greg Wooledge wrote:

On Sat, Jul 20, 2024 at 06:30:42 +0800, p...@gmx.it wrote:

On 2024-07-20 06:25, Greg Wooledge wrote:
> >
> > I can not clearly understand for this statement. what's "future shell
> > commands"? can you show an example?
>
> hobbit:~$ unset -v VAR
> hobbit:~$ VAR=bar; ./a.sh
> I am a.sh, and inside me, VAR=<>.
> hobbit:~$ echo "VAR=<$VAR>"
> VAR=

OK I know that. $VAR can be seen by future shell command in this
session, but cannot be seen by a sub-shell such as a.sh.


a.sh is NOT a subshell.  That's really super important.

a.sh is a NON-subshell child process.

In an actual subshell, you *would* see the variable, because subshells
inherit regular variables as well as environment variables.

hobbit:~$ unset -v VAR
hobbit:~$ VAR=foo; (echo "I am a subshell, and VAR=<$VAR>")
I am a subshell, and VAR=
hobbit:~$ ./a.sh
I am a.sh, and inside me, VAR=<>.

https://mywiki.wooledge.org/SubShell


make sense now. thanks a lot!



Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

2024-07-19 Thread Ash Joubert

On 2024-07-20 03:39, Celejar wrote:

Thanks much!

[...]

As per another message in this thread, I've already filed a bug against
linux-image-6.9.9-amd64, but I suppose I should update the report with
this information, indicating that it's not really a problem with that
package.


You are welcome! Please close your kernel bug report.

Hard to pin this on the firmware package either as the recommends is 
arguably the right behaviour to prevent missing firmware at boot time, 
but the recommends has this surprising side-effect for those with a 
/boot partition with insufficient free space for such a large firmware 
package. It is not dangerous because the old initrd is not removed until 
the new one is written successfully, but it is annoying!


Kind regards,

--
Ash Joubert (they/them) 
Director / Game Developer
Transient Software Limited 
New Zealand



w4sp-lab

2024-07-19 Thread Aleix Piulachs
installing w4sp-lab and wireshark there are many errors and I can't install
it..


Re: the usage of env

2024-07-19 Thread Max Nikulin

On 20/07/2024 05:25, Greg Wooledge wrote:

#!/bin/sh
echo "I am a.sh, and inside me, VAR=<$VAR>."


A way to report a bit more information:

cat /tmp/test.sh
#!/bin/sh
printf "%s: VAR %5s %10s value=<%s>\n" \
  "$0" "${VAR+set}" "${VAR:+not empty}" "$VAR"

/tmp/test.sh
/tmp/test.sh: VAR  value=<>

VAR= /tmp/test.sh
/tmp/test.sh: VAR   setvalue=<>

VAR=a /tmp/test.sh
/tmp/test.sh: VAR   set  not empty value=

On 19/07/2024 20:31, The Wanderer wrote:

$ env | grep ^_
_=/usr/bin/env

That appears to be a (shell?) environment variable.



"Bash Variables"
Alternatively
info "(bash)Bash Variables"
man bash

Back to the original questions, "env" is handy to force path search, 
e.g. in shebang


#!/usr/bin/env perl

unlike

#!/usr/bin/perl

may run perl from /usr/local/bin/perl, ~/bin/perl, etc. depending on 
$PATH. There are some cases when commands are not interpreted by shell 
and "env" allows to set environment variables for program, e.g. Exec= 
entries in .desktop files allow


 Exec=env VAR=value some-application

but not

Exec=VAR=value some-application

(I do not remember if VAR=value needs escaping) despite both cases work 
in shell.




Re: umask - default user settings?

2024-07-19 Thread Max Nikulin

On 19/07/2024 10:45, songbird wrote:

- Does MATE use scopes and services to run applications an components?
"ps xwf" and "systemd-cgls" trees may clarify where started applications
appear.


   neither of those show all the programs that i have
included on the panels, but there are cgroups and some
of the other programs listed.


The question is what are parents of processes started from menus, 
desktop icons, launchers, etc. in both trees. The special case is 
flatpak/snap sandboxes.


Maybe you will find missed applications in output of "ps axuwf" and 
"systemd-cgls" executed as root. Sometimes it is not easy to associate 
process names and user friendly names used in desktop environment. You 
may try to grep in /usr/share/applications for names and "Exec".





Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

2024-07-19 Thread David Wright
On Sat 20 Jul 2024 at 12:13:28 (+1200), Ash Joubert wrote:
> On 2024-07-20 03:39, Celejar wrote:
> > Thanks much!
> [...]
> > As per another message in this thread, I've already filed a bug against
> > linux-image-6.9.9-amd64, but I suppose I should update the report with
> > this information, indicating that it's not really a problem with that
> > package.
> 
> You are welcome! Please close your kernel bug report.
> 
> Hard to pin this on the firmware package either as the recommends is
> arguably the right behaviour to prevent missing firmware at boot time,
> but the recommends has this surprising side-effect for those with a
> /boot partition with insufficient free space for such a large firmware
> package. It is not dangerous because the old initrd is not removed
> until the new one is written successfully, but it is annoying!

According to Debian policy: "The Recommends field should
list packages that would be found together with this one
in all but unusual installations."
   -

So if my old Broadcom ethernet card requires firmware-misc-nonfree
(the package for "firmware blobs which are not individually large
enough to warrant a standalone package"), it would be /unusual/ for
the installation not to need some Nvidia firmware as well?

That doesn't seem to make any sense. Suggests might be a better
relationship, but even that seems a stretch to me.

 "Suggests […] is used to declare that one package may be more useful
  with one or more others. Using this field tells the packaging system
  and the user that the listed packages are related to this one and
  can perhaps enhance its usefulness, but that installing this one
  without them is perfectly reasonable."

Cheers,
David.



Re: Re: Webmin

2024-07-19 Thread Evelyn Escamilla


Enviado desde mi iPhone


why reliable linux hasn't gained more market share?

2024-07-19 Thread hlyg

crowdstrike makes news headlines, many Windows become blue screens

it is evident that many people around still use Windows

i wonder if linux is more reliable than Windows

according to some statistics linux has only 4% desktop market, 73% for 
MS, 15% for MacOS


why free OS hasn't gained more share even after 30 years of development?





Re: why reliable linux hasn't gained more market share?

2024-07-19 Thread David
On Sat, 2024-07-20 at 11:54 +0800, hlyg wrote:
> crowdstrike makes news headlines, many Windows become blue screens
> 
> it is evident that many people around still use Windows
> 
> i wonder if linux is more reliable than Windows
> 
> according to some statistics linux has only 4% desktop market, 73%
> for 
> MS, 15% for MacOS

Market share is not a reliable recommendation for quality.
How much market share do Rolls Royce or Bugatti have?

> why free OS hasn't gained more share even after 30 years of
> development?

Because people don't have it hammered into them via the educational
formats, it doesn't come preinstalled on almost every computer you buy:
offered as the only option, Linux isn't advertised, and probably never
will be.
Basically, all the same reasons that Mac is the only option offered in
almost every design school.
Cheers!



Running 32-bit static exeutable on 64-bit Debian

2024-07-19 Thread Van Snyder
I'm trying to run a 32-bit static executable on 64-bit Debian 12.5
"bookworm."

When I launch it, I get

./LinuxSusser: error while loading shared libraries: libgtk-x11-
2.0.so.0: cannot open shared object file: No such file or directory

Why is a static executable wanting to load a .so file?

i386 is in my arch list in /etc/apt/sources.list. I've done "apt
update"

The 64-bit version of the file exists.

I used to be able to run this program in Debian 10.

How do I run it now? The author has retired and isn't interested in
building a 64-bit executable (static or otherwise).



Re: why reliable linux hasn't gained more market share?

2024-07-19 Thread tomas
On Sat, Jul 20, 2024 at 02:45:37PM +1000, David wrote:
> On Sat, 2024-07-20 at 11:54 +0800, hlyg wrote:

[...]

> > why free OS hasn't gained more share even after 30 years of
> > development?
> 
> Because people don't have it hammered into them via the educational
> formats, it doesn't come preinstalled on almost every computer you buy:
> offered as the only option, Linux isn't advertised, and probably never
> will be.

All of them good factors. I may add yet another: because in the current
economic ideology, investing in things seems preferrable than investing
in people -- and Windows (and MacOS) were marketed as "can be administered
by anyone". Which, of course, as often in marketing, is a lie.

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: Running 32-bit static exeutable on 64-bit Debian

2024-07-19 Thread David
On Sat, 20 Jul 2024 at 04:56, Van Snyder  wrote:

> I'm trying to run a 32-bit static executable on 64-bit Debian 12.5 "bookworm."
>
> When I launch it, I get
>
> ./LinuxSusser: error while loading shared libraries: libgtk-x11-2.0.so.0: 
> cannot open shared object file: No such file or directory

Hi, try
  apt list --installed  '*libgtk2.0*'
which you will want to show that the i386 version of the libgtk2.0-0
package is installed alongside any other versions present.

If it does not appear there then try installing it, using whatever package
manager you prefer, and specify that you want the i386 package to be
co-installed with any other versions already present.

Reference:
https://packages.debian.org/search?searchon=contents&keywords=libgtk-x11&mode=filename&suite=stable&arch=any



Re: Running 32-bit static exeutable on 64-bit Debian

2024-07-19 Thread Van Snyder
On Sat, 2024-07-20 at 05:54 +, David wrote:
> On Sat, 20 Jul 2024 at 04:56, Van Snyder 
> wrote:
> 
> > I'm trying to run a 32-bit static executable on 64-bit Debian 12.5
> > "bookworm."
> > 
> > When I launch it, I get
> > 
> > ./LinuxSusser: error while loading shared libraries: libgtk-x11-
> > 2.0.so.0: cannot open shared object file: No such file or directory
> 
> Hi, try
>   apt list --installed  '*libgtk2.0*'
> which you will want to show that the i386 version of the libgtk2.0-0
> package is installed alongside any other versions present.
> 
> If it does not appear there then try installing it, using whatever
> package
> manager you prefer, and specify that you want the i386 package to be
> co-installed with any other versions already present.

I suspected it's not installed, so I had already done 

# find /usr/lib -name '*libgtk2.0*'
/usr/lib/x86_64-linux-gnu/libgtk2.0-0

(I also used "locate" and didn't find it.)

I made sure that i386 is in the arch list in /etc/apt/sources.list.
Then I ran "apt update" but it didn't install the i386 version. Does it
exist? How do I force it to install?

And there's still the mystery why a statically-linked executable wants
to load a shared object library.

> 
> Reference:
> https://packages.debian.org/search?searchon=contents&keywords=libgtk-x11&mode=filename&suite=stable&arch=any
>