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
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
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
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
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
obile 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/ a tmpfs and cleanup /var/tmp/ on a timer by default
[was: Re: systemd: tmpfiles.d no
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
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.
To: 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
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
>> 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
> * 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
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日周六 11:27写道：
&
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
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
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
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
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 -
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
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
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
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:
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
23 matches
Mail list logo
