Yes, this is a known issue. This is because Bookworm only supports 32-bit CPUs
that are fully Intel compatible. You will find that there are other binaries
such as ffmpeg that fail with the same problem. (This is from memory. I have
a similar system that is "almost" Intel compatible, but can
> On Jun 9, 2024, at 03:02, Marc Haber wrote:
>
> On Sat, 08 Jun 2024 07:25:49 +, Laszlo Merenyi
> wrote:
>> I was able to make sudo (and visudo) executable working on this CPU, by
>> recompiling the sudo-1.9.15p5 source code package on the target with
>> manually removed "-fcf_protecti
Characterizing it as "ancient" intentionally misses the point.
What it is is functional, and paid for. And likely, already installed and in
use somewhere (like all of my 32-bit systems).
It's not just a matter of "buy something better." That's easy.
What's not easy is that a) that adds anoth
> Or is Debian going to continue to support this processor, since it is still
> apparently a viable product, enough that new systems are using it?
Considering the plans for i386 I don't think it makes sense to even ask
this question?
Of course it makes sense to ask. The plans are based on a fau
>> It's not just a matter of "buy something better." That's easy.
>Indeed, that is easier and cheaper.
Of course, continuing to use a system I already have is cheaper still.
> What's not easy is that a) that adds another machine to the waste
> stream, instead of continuing to get use from it
> On Jun 10, 2024, at 01:44, Andrey Rakhmatullin wrote:
>
> On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote:
It's not just a matter of "buy something better." That's easy.
>>
>>> Indeed, that is easier and cheaper.
>>
>> Of course, continuing to use a system I alread
Then it's not a problem in the first place. If you can't reproduce a bug with a
reasonable effort, then it is unconfirmed and you can stop worrying about it. A
bug that can't be reproduced, effectively doesn't exist.
That's not a reason to stop supporting an entire architecture. That's a
troub
> On Jun 14, 2024, at 11:46, Russ Allbery wrote:
>
> r...@neoquasar.org writes:
>
>> Then it's not a problem in the first place. If you can't reproduce a bug
>> with a reasonable effort, then it is unconfirmed and you can stop
>> worrying about it.
>
> I think you're confusing two different t
Interesting. I have an FTDI device. I will try it on my bullseye and bookworm
systems and see what they do. If they have trouble, I can gather lsusb, dmesg,
and other data from it.
--J
Sent from my mobile device.
From: Debian Bug Tracking System
Sent: Wednesda
I tested an FTDI device (ID 0403:6001, Serial UART) in three separate systems.
None of the experienced any unusual issues, except that the USB port in one of
the test systems is apparently a little touchy.
In all three cases, the device was recognized correctly. In all three cases,
the rest of
I agree. Speaking just for myself, I have at least one other 32-bit system that
currently runs Debian 11, and I'd prefer to not just upgrade it and hope it
works as a means of testing whether or not it's supported. If the distinction
between "supported" and "not supported" is going to come down
If both are installed, does one work and one fail? Do they both work and
basically do extra work?
Or can the installation package run a script that disables itself if the other
is installed and enabled?
--J
Sent from my mobile device.
From: Michael Biebl
Sent
Based on this: https://news.ycombinator.com/item?id=38664729
I would say that others have come to the same conclusion. Even the post title
literally says it's not really "SSHv3" but rather SSHv2 using a different
transport mechanism.
A package name that reflects THAT might be appropriate - li
I think the idea that HFS+ is not used on removable device is a bit of a
fallacy. I, myself, use this frequently on removable hard drives when moving
large data sets back and forth from my Mac. The Mac doesn't easily read ext
filesystems, but Linux can read HFS, and the various Microsoft files
Keeping in mind that I am new to this arena...
I have some Intel systems - both 64-bit and 32-bit - that I might be able to
use as build platforms.
What does the Debian team need from me to be able to use these systems?
I can't guarantee they'll be FAST, but I'll do what I can to make them
EF
Sent from my mobile device.
From: YunQiang Su
Sent: Friday, January 12, 2024 10:11
To: r...@neoquasar.org
Cc: noloa...@gmail.com; debian-ker...@lists.debian.org;
debian-...@lists.debian.org; debian-devel@lists.debian.org;
debian-rele...@lists.debian.org
Subjec
Let me try again, following up on the previous thread, but removing most of the
irrelevant history.
If I have a 32-bit Intel system that is currently supported on bookworm
(currently running bullseye, but I can upgrade it), is that of use to anyone as
a native build platform for 32-bit binary p
No.
You are AGAIN assuming what I am talking about.
I know the difference between a 32-bit processor and a 64-bit processor.
If you're not going to answer my question, kindly don't answer at all.
--J
> On Jan 12, 2024, at 21:40, YunQiang Su wrote:
>
> rhys 于2024年1月13日周六
> * Thank you for your offering, but Debian is never in lack of
> x86/x86_64/amd64/intel/amd/whatever_you_name_it hardware for package building.
> In fact, we now have some of the very powerful machines.
If you're sure. Working 32-bit systems are not as common as they once were,
and sometimes
>> I know the difference between a 32-bit processor and a 64-bit processor.
>
> Obviously you don't. Or at least are not aware about consequences.
>
>
> Since you still offer 32bit machines of which Debian has enough of. (64 bit
> kernel probably but it doesn't matter) where it does not matt
A few thigns I have seen in this thread:
Fedora/Arch/Whomever: I don't think it matters who thought of what first.
Sometimes, it's okay to be different. I have moved all of my systems away from
Slackware and Fedora/RedHat/etc. TO Debian because I think Debian does it
better. Please do not t
: debian-devel@lists.debian.org
Subject: Re: On merging bin and sbin
On 28/02/24 14:12, rhys wrote:
> Last thing: The idea of detecting cases where multiple binaries have the
> same name is a verey good one. It should also be possible to automate this
> effort in a number of ways. I would
You're now at the stage where you're not just MISSING the point of what people
are trying to tell you, you're actively IGNORING it.
Automatically deleting files is a bad idea. Those files aren't yours. You don't
know why they are there. Leave them alone.
--J
Sent from my mobile device.
This, in my opinion, is the correct view.
If the users/admins of a system are putting files somewhere, those are their
files and therefore their responsibility. It is not up to anyone else to claim
they know better and clean up after them.
If the files are abandoned by applications that don't
echnical issue, this would be a much shorter
conversation. ;)
--J
Sent from my mobile device.
From: "Barak A. Pearlmutter"
Sent: Tuesday, May 7, 2024 07:18
To: r...@neoquasar.org
Cc: Luca Boccassi; debian-devel@lists.debian.org
Subject: Re: Re: Make /tmp/
I'm always in favor of logging system changes.
Notification at run time is really tricky. No one ever logs into several of my
Debian servers. Other systems have interactive GUI or CLI users, some of whom
are admins and others not.
I don't know if login notices are terribly reliable as no one
The /tmp/ as tmpfs discussion is funny to me because while we've been kicking
around the idea of whether or not to clean /tmp/, having /tmp/ as a tmpfs makes
that whole argument moot. It all goes away at boot time! Problem solved! :D
Honestly, I see this one as a much easier topic, assuming that
It is not "abuse of /tmp" to put files there, even if they need to be there for
a long time. That is an unnecessary characterization.
Yes, /tmp gets backed up along with the rest of the system on every VM in my
environment.
Sometimes "temporary" CAN mean "weeks or even months." That's not som
That depends. What would be required of such a person? I also have several
i386-class machines that run Debian (though only one that can run Debian 12).
--J
Sent from my mobile device.
From: Johannes Schauer Marin Rodrigues
Sent: Friday, May 17, 2024 15:48
To:
I have an N270 system I can use to contribute, if someone is willing to explain
what I need to do to make it useful.
Sent from my mobile device.
From: Victor Gamper
Sent: Sunday, May 19, 2024 08:03
To: debian-devel@lists.debian.org
Subject: Re: About i386 suppor
On Mon, Dec 02, 2024 at 12:30:52PM +0300, Hakan Bayındır wrote:
1. First, root and ordinary users will not be able to use commands in each
other's directories, which will greatly increase their security
>>>
>>> (typical level of argumentation)
>>>
>> The ability to isolate users from co
>
> On Mon, Dec 02, 2024 at 06:46:52AM -0600, rhys wrote:
>>>>>> 1. First, root and ordinary users will not be able to use commands in
>>>>>> each
>>>>>> other's directories, which will greatly increase their security
>>
>>>
>>> When I was regularly monitoring ITPs, I noticed that newcomers often
>>> struggle to "find friends" (i.e., sponsors). In my opinion, what we need
>>> is someone to guide sponsees to the appropriate team, Salsa group, or
>>> similar space. This role doesn't require a delegation since it
Please read all the way to the bottom before replying. It will save time.
> a) single power-user system (notebook/desktop) which has a local MTA
> to send their own mail out to a proper mail server somewhere on the
> internet
> b) running a proper mail server on the internet
>
> I do b
>
> this is what can be called "old style" overrides.
Things get to be "old" because they actually work well.
> The modern way of doing it is the "stateless" style, most commonly associated
> with systemd but used by plenty of other projects, plus "drop-in" .d
> directories.
>
> The basic
>>>
>>> $ cp /usr/lib/$proj/foo.conf /etc/$proj/
>>
>> Which is not trivial, really.
Well, it IS, but in the same way that "rm -rf /" is trivial. It's easy to do,
but some non-trivial thought should occur before doing it.
> Put another way: would it really be /usr/lib/$proj, or
>
>> What group of idiots came up with a system where instead of having all of
>> the configs in maximum of two places (/etc | ~/.config) have now spread them
>> out across five completely separate directory trees?
>
> The group is called "The Linux Userspace API (UAPI) Group", and according
>
>> Suppose that packages ship sample configuration files *that exactly
>> match their defaults* (which should in general mean that everything is
>> commented out) in some standardized path under /usr/share/doc/$package/
>> (e.g. examples/etc), that makes it easy to see what path the example
>
> Right now, the model we have is "some packages use the empty /etc model,
> some packages install commented-out defaults, and there's no
> consistency". I'd love to move to the model of "all packages use
> whichever model the sysadmin prefers".
As a long-time sysadmin - and following on my pre
e priority line for aleph-dev from
optionnal to optional. The same applied to aleph-doc.
There is currently no package or pseudopackage associated with these lists.
I suggest that a pseudopackage be created if only for organizing bug reports
of this nature.
Thank you.
Rhys Dyfrgi
40 matches
Mail list logo
