On Sat, Apr 19, 2025 at 10:55:20PM +0800, Sean Whitton wrote:
This just hasn't been my experience. You don't need perfect
compatibility (or certification). By restricting myself to the POSIX
specifications of sh, awk, find, grep and sed, I've profitably written
several non-trivial programs that
On Sat, Apr 19, 2025 at 04:09:53PM +0200, Chris Hofstaedtler wrote:
* Michael Stone [250419 15:47]:
If the goal is a minimal container image, why use debian at all vs a
distribution optimized for that purpose? Running alpine without perl
is already a solved problem...
This is true for a lot
On Fri, Apr 18, 2025 at 10:17:12PM +0100, Jonathan Dowland wrote:
They likely lack perl, as well. Most/all awk usage in maintainer
scripts could probably be replaced with perl. But, if you are in the
minimizing game, perhaps you'd rather remove perl from the essential
set? A substantially harde
On Sat, Apr 19, 2025 at 08:05:54PM +0800, Sean Whitton wrote:
I have interpreted scripts that I want to run on any FreeBSD and Debian
machine, because they are part of my OS bootstrapping. What else is
there than POSIX sh for this? Therefore, it's still relevant.
With that requirement, what y
On Fri, Apr 18, 2025 at 02:52:17PM +0800, Sean Whitton wrote:
On Thu 17 Apr 2025 at 08:02pm -05, Richard Laager wrote:
So, personally, I think getting mktemp(1) added to POSIX would be
better for portability in the long run anyway.
Eventually. POSIX.1-2017 is going to be the thing to target f
On Tue, Apr 15, 2025 at 03:38:38PM +0200, Simon Josefsson wrote:
I believe that is a fairly new (~5 years?) approach within Debian.
Debian used to treat OpenSSL incompatible with GPLv2 and that all code
that link to OpenSSL has to have a GPL+OpenSSL exception. Does anyone
recall how and when thi
On Tue, Apr 08, 2025 at 12:08:05PM -0500, Richard Laager wrote:
I got bit (not in pytz) by US/Pacific disappearing, so I understand
the annoyance from the user perspective. However, as that is what has
happening in tzdata, I don't think we should have individual packages
trying to fight that in
On Tue, Apr 08, 2025 at 06:42:43AM +0100, Alastair McKinstry wrote:
But ./gen_tzinfo.py in python-tz adds extra timezones it believes
should be present, including some backwards-compatible entries such as
"US/Pacific". Adding these timezones is possible, but I am loath to
diverge from tzdata..
On Tue, Apr 08, 2025 at 04:50:58PM -0500, Richard Laager wrote:
Option C would also keep the whole system consistent. But in that
scenario, installing python-tz indirectly adds system-wide timezone
values. I'm hesitant about that idea; it feels like "spooky action at
a distance".
FWIW, that'
On Tue, Apr 08, 2025 at 05:19:38PM +0200, Dirk Lehmann wrote:
in relation to the discussion of 'utmp in trixie'
* https://lists.debian.org/debian-devel/2025/04/msg00011.html
It looks like, that wtmp is an well alternative to who(1). For that
the command
$> last -p now
No. utmp and wtmp ar
On Wed, Apr 02, 2025 at 05:52:13PM +1100, Craig Small wrote:
Yes, there is definitely a Y2038 issue
*for trixie*?
there are also issues with utmp not
being
handled consistently and some security issues around who can do what to the
file.
Stuff that has been true literally decades. If someon
On Fri, Apr 04, 2025 at 09:10:42PM +0200, Dirk Lehmann wrote:
On 4/3/25 2:58 PM, Antonio Terceiro wrote:
I never cared about /run/utmp in itself, but I got used to last(1).
FWIW, a new implementation of last is now provided by wtmpdb.
+1
great, it looks like that
* wtmpdb(8)
could be a wel
On Thu, Apr 03, 2025 at 12:47:07AM +0200, Marco d'Itri wrote:
On Apr 02, Bill Allombert wrote:
Does that breaks the usual unix commands like 'who' ? If yes this is
who(1) specifically, yes.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079575 .
Maybe the coreutils maintainer is alrea
On Fri, Apr 04, 2025 at 03:43:03PM +0200, Marc Haber wrote:
Can your package handle the classic on-disk format when it is compiled
with 64 bit time_t? I remember there was some discussion about that
back then.
If you touch /run/utmp you'll see it is still working fine with any
packages that ha
On Fri, Apr 04, 2025 at 12:46:03AM +0200, Chris Hofstaedtler wrote:
But the thing that needs looking at is why who in Debian behaves like
it does, and if it doesn't work right, fix that in who or wherever
else it needs fixing in the stack.
Because I haven't turned it on, because I'm really unh
On Thu, Apr 03, 2025 at 07:52:12PM +0200, Marco d'Itri wrote:
On Apr 03, Michael Stone wrote:
The issue isn't making a change, the issue is what change is the
right thing to do. IMO, dropping utmp without any kind of a
transition or deprecation period is the wrong thing to do. H
/run/utmp is no longer provided in trixie, which means that the
mechanisms used to show active sessions in unix for several decades no
longer work. There's a replacement mechanism provided by systemd, but
it's not 1:1. I propose that for trixie *both* mechanisms are active, so
a person can choo
On Mon, Mar 10, 2025 at 08:36:45PM +0900, Simon Richter wrote:
We're not obligated to validate their questionable choices in buying
hardware that ships with non-free firmware
There are a lot of competing priorities here, and it's the height of
arrogance to be so certain that one's own opinion
On Sun, Mar 09, 2025 at 01:32:47PM +0100, Matthias Urlichs wrote:
Another way to look at this outcome, and the one I personally prefer
by a wide margin, is that it'd be very cool to have them, but at this
time their utility is … questionable, given that I personally own zero
(out of umpteen) co
On Fri, Jan 03, 2025 at 11:49:05AM +0100, Bernhard Schmidt wrote:
Shared infrastructure of course. Note that this includes an update of
the initramfs, which is CPU bound and takes a bit on this system. You
can take around 45s off the clock for the initramfs regeneration in
each run. I did a cou
On Wed, Jan 01, 2025 at 03:15:25PM +, Nikolaus Rath wrote:
Julien Plissonneau Duquène writes:
Le 2024-12-30 21:38, Nikolaus Rath a écrit :
If a system crashed while dpkg was installing a package, then my
assumption has always been that it's possible that at least this package
is corrupted.
On Tue, Dec 31, 2024 at 06:44:58PM +0100, Marc Haber wrote:
On Tue, Dec 31, 2024 at 10:32:09AM -0700, Soren Stoutner wrote:
On my system, which has a Western Digital Black SN850X NVMe (PCIe 4) formatted
ext4, dpkg runs really fast (and feels like it runs faster than it did a few
years ago on sim
On Tue, Dec 31, 2024 at 05:31:36PM +0100, Sven Mueller wrote:
It feels wrong to me to justify such a heavy performance penalty this way if
Well, I guess we'd have to agree on the definition of "heavy performance
penalty". I have not one debian system where dpkg install time is a
bottleneck.
On Mon, Dec 30, 2024 at 08:38:17PM +, Nikolaus Rath wrote:
If a system crashed while dpkg was installing a package, then my
assumption has always been that it's possible that at least this package
is corrupted.
You seem to be saying that dpkg needs to make sure that the package is
installed
On Sat, Dec 28, 2024 at 08:22:17PM -0500, Theodore Ts'o wrote:
Note that it's not a sync, but rather, under certain circumstances, we
initiate writeback --- but we don't wait for it to complete before
allowing the close(2) or rename(2) to complete. For close(2), we will
initiate a writeback on a
On Thu, Dec 26, 2024 at 09:01:30AM +0100, Helmut Grohne wrote:
What other place would be suitable for including this functionality?
As I suggested: you need two tools or one new tool because what you're
looking for is the min of ncpus and (available_mem / process_size). The
result of that cal
On Thu, Dec 26, 2024 at 09:23:36PM +0900, Simon Richter wrote:
My feeling is that this is becoming less and less relevant though,
because it does not matter with SSDs.
To summarize: this thread was started with a mistaken belief that the
current behavior is only important on ext2. In reality t
On Fri, Dec 13, 2024 at 07:00:36PM +0200, Peter Pentchev wrote:
On Fri, Dec 13, 2024 at 10:08:19AM -0500, Michael Stone wrote:
On Fri, Dec 13, 2024 at 12:22:38PM +0100, Marc Haber wrote:
> They are planning to remove the --badname option from useradd, making
> it impossible to even try
On Fri, Dec 13, 2024 at 12:22:38PM +0100, Marc Haber wrote:
They are planning to remove the --badname option from useradd, making
it impossible to even try UTF-8 user names, without patching useradd.
Or edit the passwd file (vipw), or use any non-passwd-file
authentication mechanism, or use a
On Thu, Nov 14, 2024 at 04:39:28PM +0100, Iustin Pop wrote:
Indeed. But even the comment, by itself, I think raises a question - why
do we (still) do this?
Because there's very little incentive to change it.
On Tue, Nov 12, 2024 at 11:10:54PM +0100, Iustin Pop wrote:
On Tue, Nov 12, 2024 at 02:14:34PM +0800, kindusmith wrote:
> In early Unix, boot and vmunix were both stored in the root directory as
> programs, and boot was used to start vmunix. Debian inherited this for
> compatibility, but the situ
On Tue, Nov 12, 2024 at 02:14:34PM +0800, kindusmith wrote:
In early Unix, boot and vmunix were both stored in the root directory
as programs, and boot was used to start vmunix. Debian inherited this
for compatibility, but the situation has changed a lot. Today, boot is
stored in the root direc
On Mon, Sep 16, 2024 at 09:49:24AM +0200, Ansgar 🙀 wrote:
Hi,
On Sun, 2024-09-15 at 23:07 -0400, Michael Stone wrote:
On Tue, Jul 09, 2024 at 02:13:26PM +0200, Daniel Gröber wrote:
> If ifupdown's paradigm were working for people we wouldn't be having this
> conversation.
>
On Tue, Jul 09, 2024 at 02:13:26PM +0200, Daniel Gröber wrote:
If ifupdown's paradigm were working for people we wouldn't be having this
conversation.
Well, the problem is that there's a selection bias in people having this
conversation--the people who are using ifupdown without issues aren't
On Tue, Jul 09, 2024 at 10:57:39AM +0200, Matthias Urlichs wrote:
Agreed: either it's drop-in compatible or we may as well switch the
default to NM and/or systemd-networkd.
Well, here's a heretical thought: why don't we do that anyway, at least for new
installations?
Frankly the default
On Fri, Aug 16, 2024 at 04:54:02PM +0100, Colin Watson wrote:
Quite. If nothing else, I think the code actually in the Debian archive
that relies on the old path ought to be changed _first_, e.g. via an
MBF. I see a bunch of cases that are relatively subtle and might suck a
lot of other people'
The first time I rebooted after iproute2 removed the /sbin/ip link, my system
failed to boot. I eventually discovered this was because /sbin/vconfig (from
the "vlan" package) calls /sbin/ip and when that failed the network was not
configured. This meant having to boot into single user mode for dia
On Tue, Apr 02, 2024 at 01:30:10AM +0100, Colin Watson wrote:
* add dependency-only packages called something like
openssh-client-gsskex and openssh-server-gsskex, depending on their
non-gsskex alternatives
* add NEWS.Debian entry saying that people need to install these
packages
On Sat, Nov 11, 2023 at 11:50:31AM +0100, Andreas Metzler wrote:
you seem to have missed/deleted the paragraph where Ansgar suggested how
to do this *without* tradeoff. ("explicitly disable/enable build options
per arch")
No, I didn't. That was in my original email and is one of the
possibilit
On Fri, Nov 10, 2023 at 03:10:42PM +0100, Ansgar wrote:
Please avoid producing different results depending on the build
environment. That just results in non-reproducible issues in unclean
environments (suddenly different dependencies, different features,
...).
I think that is an acceptable tra
On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote:
Per-architecture dependencies are possible though, so maybe starting
to add the libssl dependency only on amd64 is a good starting point,
and then users of other architectures can request to be added too if
it is beneficial for them.
On Mon, Aug 14, 2023 at 09:40:52PM +0100, Wookey wrote:
On 2023-08-14 10:19 -0400, Michael Stone wrote:
On Thu, Aug 10, 2023 at 02:38:17PM +0200, Lucas Nussbaum wrote:
> On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
> > Are we ready to call for consensus on dropping the require
On Thu, Aug 10, 2023 at 02:38:17PM +0200, Lucas Nussbaum wrote:
On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
Are we ready to call for consensus on dropping the requirement that
`debian/rules clean; dpkg-source -b` shall work or is anyone interested
in sending lots of patches for this?
My r
On Sat, Jul 01, 2023 at 09:44:27AM -0400, Michael Stone wrote:
On Thu, Jun 29, 2023 at 08:55:11PM +0100, Matthew Vernon wrote:
Bookworm is now out; I will shortly be increasing the severity of
the outstanding bugs to RC, with the intention being to remove
src:pcre3 from Debian before the
On Thu, Jun 29, 2023 at 08:55:11PM +0100, Matthew Vernon wrote:
Bookworm is now out; I will shortly be increasing the severity of the
outstanding bugs to RC, with the intention being to remove src:pcre3
from Debian before the trixie release.
You don't think that marking packages for removal tw
On Wed, Feb 15, 2023 at 11:29:25AM +, Alastair McKinstry wrote:
The counterpoint is if someone does a high-core-count 32-bit arch for
HPC; x32 could (have been) such an architecture, but its development
looks stalled.
That may have been a possibility 15-20 years ago, but today anything
ca
On Fri, Oct 14, 2022 at 10:52:01AM +0200, Santiago Ruano Rincón wrote:
5. transitional packages along with a helper package (that fails or
success during install) to prompt the user so they add non-free-firmware
section when needed.
Is there any reason why you are not considering 5.?
The dange
On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
Plus, as Shengjing Zhu points out: we already expect people to manage
the sources.list anyway on upgrades.
We also try to avoid silent install problems that might or might not
result in a system that doesn't boot properly.
On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
What's the plan for upgraded systems with an existing /etc/apt/sources.list.
Will the new n-f-f section added on upgrades automatically(if non-free was
enabled before)?
On Thu, Sep 29, 2022 at 04:26:45PM +0200, Vincent Bernat wrote:
On 2022-09-29 15:01, Michael Stone wrote:
On Wed, Sep 28, 2022 at 09:02:15PM -0600, Sam Hartman wrote:
* Finally, I can use bluetooth on linux with reasonably good audio
quality!
Aren't they both using the same backend?
On Wed, Sep 28, 2022 at 09:02:15PM -0600, Sam Hartman wrote:
* Finally, I can use bluetooth on linux with reasonably good audio
quality!
Aren't they both using the same backend? ldac/aptx weren't in pulseaudio
for a long time, but they are now. Or is there something else?
On Thu, Sep 15, 2022 at 06:13:35PM +0530, Nilesh Patra wrote:
As far as I can see, the latest "new upstream" upload to unstable was
in "2021-08-25" which is more than an year from now, post which there
have been few bug fix uploads.
More notable upload has been the one that enables gstreamer sup
On Tue, Sep 13, 2022 at 07:25:12PM +0200, Michael Biebl wrote:
Am 13.09.22 um 18:17 schrieb Antoine Beaupré:
I also have the feeling that pipewire has already gone beyond what
pulseaudio is capable of in terms of Bluetooth support, but I might be
mistaken on that.
Interesting. What do you have
On Wed, Jul 20, 2022 at 05:15:07PM +0200, Adam Borowski wrote:
Available in the archive yes, installed by default no way.
That makes this current thread mostly moot, as when not installed by
default (or a metapackage) you don't need any particular implementation
to be blessed.
I think the origi
On Sun, Jul 17, 2022 at 01:49:53AM -0400, Timothy M Butterworth wrote:
Telnet is old, insecure and should not be used any more. What is the point of
packaging a Telnet daemon when everyone should be using SSH. Telnet Client I
can see because a person may need to connect to a router or switch that
[apologies to package aliases getting this twice due to autocomplete fail]
I've been trying to make sense of the NEWS item in isc-dhcp-client
(that alternatives are needed) in combination with the functionality
of ifupdown and what the implications are for debian upgrades
generally.
isc-dhcp
On Sun, Mar 13, 2022 at 11:09:24AM +0100, Marc Haber wrote:
On Sat, 12 Mar 2022 14:41:35 -0500, Michael Stone
wrote:
And remember, there are existing real-world debian systems that have
users with dots (regardless of local adduser policy; think ldap/ad for
example) so these are already issues
On Sat, Mar 12, 2022 at 03:19:52PM +0800, Paul Wise wrote:
Hideki Yamane wrote:
Is there any suggestion or guideline for pacakges that contain
both systemd-timer unit setting and cronjob? Don't they conflict
or not
Do what apt does; make the cron job exit successfully without doing
anything w
On Fri, Mar 11, 2022 at 10:16:24PM +0100, Marc Haber wrote:
[^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]] is found 829
times in Debian, mostly in docs and comments, but also in a few live
scripts. I think that we still have some way to go until we get rid of
the dot notation in chown ca
On Thu, Mar 10, 2022 at 09:33:00PM +0100, Marc Haber wrote:
On Wed, 9 Mar 2022 17:29:01 -0500, Michael Stone
wrote:
On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote:
I don't think it makes sense to move toward 0700 home directories and to
loosen the umask for usergroups.
On Thu, Mar 10, 2022 at 06:28:57PM +0100, Vincent Bernat wrote:
❦ 10 March 2022 11:34 -05, Michael Stone:
It was always configurable, but was enabled out of the box in hamm...
My system was installed on Potato if I remember correctly (or maybe
Woody, but definitely not older than Potato). But
On Thu, Mar 10, 2022 at 05:06:32PM +0100, Vincent Bernat wrote:
❦ 10 March 2022 11:21 +01, Philip Hands:
On systems that don't use usergroups for all/some users, doesn't this
change make all files writable by other users by default? That would
seem like a very unsecure change on upgrades (or a
On Thu, Mar 10, 2022 at 12:04:38AM +0100, Ansgar wrote:
On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote:
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared
On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote:
I don't think it makes sense to move toward 0700 home directories and to
loosen the umask for usergroups.
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other peo
On Wed, Feb 02, 2022 at 10:16:36PM +0500, Andrey Rahmatullin wrote:
On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote:
On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:
> Doesn't that, then, lead to the suggestion that any package entering
> unstable wit
On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:
Doesn't that, then, lead to the suggestion that any package entering
unstable without having undergone NEW review (which, in the revised
model, might be every new package) should automatically have a bug filed
against it requesting sui
On Wed, Feb 02, 2022 at 09:39:02AM -0600, John Goerzen wrote:
On Tue, Feb 01 2022, Russ Allbery wrote:
I would hate to entirely lose the quality review that we get via NEW, but
I wonder if we could regain many those benefits by setting up some sort of
peer review system for new packages that i
On Tue, Sep 21, 2021 at 09:00:52AM +0100, Jonathan Dowland wrote:
On Mon, Sep 20, 2021 at 11:02:49AM -0400, Michael Stone wrote:
It seems to install to /usr/bin/which.gnu, implying that you could
upload /usr/bin/which.bsd if you so desire; what's the issue?
I think we should have jus
On Mon, Sep 20, 2021 at 02:38:06PM +0100, Jonathan Dowland wrote:
On Fri, Aug 20, 2021 at 11:03:50AM +0800, YunQiang Su wrote:
For such a simple tool, do we really need such many versions?
At least you've asked the question. I'd love to think that there was a
proper evaluation of BSD which ver
On Fri, Sep 10, 2021 at 10:04:08PM +0530, Anuradha Weeraman wrote:
> 2) If you do go ahead with switching to the community distribution, then
> "93u+m" is part of the name, not the version number, so I'd suggest:
[...]
Correction: rushed the last email, I meant to say that I agree that 93u+m
is
On Fri, Sep 10, 2021 at 08:02:42PM +0200, David Kalnischkies wrote:
On Fri, Sep 10, 2021 at 11:08:38AM -0400, Michael Stone wrote:
On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote:
> On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote:
> > The only thing I
On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote:
On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote:
The only thing I could see that would be a net gain would be to generalizes
sources.list more. Instead of having a user select a specific protocol and
path, allow
On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote:
Laptops of end-user systems are the target, but also developers. When
people gather at a place (conference, hackspace, private meetup, etc.)
downloading of .debs should just work quickly by default. Many such
sites could easily provid
On Fri, Sep 10, 2021 at 12:00:57PM +0200, Timo Röhling wrote:
* Michael Stone [2021-09-08 19:25]:
I think the issue isn't certificate validation, it's that https
proxy requests are made via CONNECT rather than GET. You could
theoretically rewrite the proxy mechanism to MITM the CO
On Thu, Sep 09, 2021 at 02:54:21PM +0200, Timo Röhling wrote:
* Michael Stone [2021-09-09 08:32]:
I'm honestly not sure who the target audience for auto-apt-proxy
is--apparently someone who has an infrastructure including a
proxy, possibly the ability to set dns records, etc., but
On Thu, Sep 09, 2021 at 11:54:44AM +0530, Pirate Praveen wrote:
Why can't auto-apt-proxy ask this as a debconf question? I also like
auto-apt-proxy but I agree with this, someone needing auto-apt-proxy should be
able to change the default as well.
I don't really see why adding another debcon
On Thu, Sep 09, 2021 at 08:36:28AM +0200, Timo Röhling wrote:
* Michael Stone [2021-09-08 19:12]:
Why not simply automate setting it at install time using preseed?
I'm honestly not sure who the target audience for auto-apt-proxy
is--apparently someone who has an infrastructure includ
On Wed, Sep 08, 2021 at 03:56:14PM +0200, Ansgar wrote:
On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote:
On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote:
> So what do you suggest then? Tech-ctte as with merged-/usr? Or a
> GR? Or
> something else?
I propose that the proponents pay
On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote:
Enabling https by default quite simply breaks the simple recipe of
installing auto-apt-proxy. Would you agree with auto-apt-proxy's
postinst automatically editing your sources.list to drop the s out of
https? The answer repeatedly giv
On Sat, Apr 03, 2021 at 08:03:23PM +0500, Andrey Rahmatullin wrote:
On Sat, Apr 03, 2021 at 10:37:37AM -0400, Michael Stone wrote:
> > > Not sure what hardware you are talking about but the majority of WiFI
> > > hardware is supported by the mainline kernels, at least after yo
On Thu, Apr 01, 2021 at 11:52:46AM +0500, Andrey Rahmatullin wrote:
On Wed, Mar 31, 2021 at 10:38:11PM -0400, Michael Stone wrote:
On Tue, Mar 30, 2021 at 10:20:03PM +0500, Andrey Rahmatullin wrote:
> Not sure what hardware you are talking about but the majority of WiFI
> hardware is sup
On Tue, Mar 30, 2021 at 10:20:03PM +0500, Andrey Rahmatullin wrote:
Not sure what hardware you are talking about but the majority of WiFI
hardware is supported by the mainline kernels, at least after you load
their firmware.
I assume you haven't tried very much wifi hardware. Realistically, the
On Fri, Dec 18, 2020 at 09:11:42AM +0100, Raphael Hertzog wrote:
And at least anyone that is not installing the latest version can have
an idea of whether it's important/urgent for them to upgrade or not.
I think the software in question is a good example where there's
basically no value in ha
On Wed, Dec 16, 2020 at 02:47:22PM -0500, Devops PK Carlisle LLC wrote:
I understand your point about 32 bit being updated forever, and perhaps
it does not need to be. Perhaps the happy medium would be to freeze it
at some point, but leave it available as-is so that legacy software with
32 bit d
On Sun, Dec 13, 2020 at 11:40:29AM -0500, Devops PK Carlisle LLC wrote:
Being philosophically opposed to throwing a good machine into a
landfill, I tend to hang on to equipment for a long time. My
play/experimentation and last-ditch backup box is a 10 year old laptop.
I hear that, but at least
On Wed, Apr 08, 2020 at 10:36:17PM +0200, Thomas Goirand wrote:
I don't agree with this *at all*. It is not in the interest of our users
to be forced to update the software they use for their infrastructure
every few months.
Isn't that the user's decision, when they decided to adopt a tool that
On Sun, Mar 01, 2020 at 01:06:13PM +0800, SZ Lin (林上智) wrote:
Hi all,
I'm working on fixing bugs (including RC) on google-authenticator[1] which
name should be "google-authenticator-libpam" instead.
[1] https://packages.debian.org/source/sid/google-authenticator
[2] https://github.com/google/go
On Fri, Mar 06, 2020 at 07:46:26AM +0100, Eduard Bloch wrote:
So, wouldn't a restart of the i386 architecture under a different name
give an excelent opportunity to get rid of many of such workarounds?
In theory, sure...but I don't see that there's any actual demand for a
new/clean i386 archit
On Thu, Feb 13, 2020 at 04:08:22PM +0100, Andrej Shadura wrote:
On Thu, 13 Feb 2020, 10:40 YunQiang Su, wrote:
just redefine time_t to 64bit may also cause a problem:
a bad designed and old network protocol which aims only target 32bit
system,
a binary data packet, may contain
On Thu, Feb 13, 2020 at 10:29:35AM +0100, Ansgar wrote:
For arm* and mips*, we mostly seem to be talking about special-purpose
systems where just switching to a new architecture/port doesn't seem to
be that much as a problem as for i386. I think rebuilding the world and
breaking ABI might thus b
On Mon, Feb 10, 2020 at 06:27:55PM +0100, Svante Signell wrote:
Not much space for other init systems than systemd within Debian. I was hoping
for too much. Let's move on with our lives.
I think we'd all appreciate if you would do that and stop sending
messages about systemd!
On Fri, Feb 07, 2020 at 02:46:19PM +0200, Wouter Verhelst wrote:
On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> Why not? This seems like the type of problem that SONAMEs are made for.
> What am I missing?
SONAMEs a
On Thu, Feb 06, 2020 at 08:09:13PM +0100, Svante Signell wrote:
On Thu, 2020-02-06 at 13:41 -0500, Michael Stone wrote:
On Thu, Feb 06, 2020 at 07:22:07PM +0100, Svante Signell wrote:
> On a Debian sytem _not_ running systemd:
>
> du -sh /var/log
> 74M/var/log
>
> A
On Thu, Feb 06, 2020 at 07:22:07PM +0100, Svante Signell wrote:
On a Debian sytem _not_ running systemd:
du -sh /var/log
74M /var/log
And the binary logs from systemd would of course be much smaller since
they are binary. Any numbers?
It looks like you just proved that this discussion doe
On Thu, Feb 06, 2020 at 04:49:31PM +0100, Simon Richter wrote:
I'd expect servers and embedded systems to be vastly underrepresented in
both of these statistics, but that doesn't mean these use cases are in any
way uninteresting to the project.
Please stop beating the dead horse of whether debi
On Thu, Feb 06, 2020 at 09:50:36AM +1100, Dmitry Smirnov wrote:
On Thursday, 6 February 2020 9:04:33 AM AEDT Michael Stone wrote:
Nobody said "exclusively" except you!
It was suggested that default will change and I'm concerned about that.
And yet you said "exclusively&q
On Thu, Feb 06, 2020 at 08:40:29AM +1100, Dmitry Smirnov wrote:
On Thursday, 6 February 2020 6:59:38 AM AEDT Nikolaus Rath wrote:
I would venture that for every user who is grateful that
/var/log/mail.log collects all the various mail-related logs, there is
another user that curses about non bei
On Wed, Feb 05, 2020 at 01:32:41PM +, Scott Kitterman wrote:
My impression so far is that the journalctl interface is a regression from what
we have now in every way I care about.
Great! Good thing you can just keep using rsyslogd.
On Tue, Feb 04, 2020 at 03:17:50PM +0100, Ansgar wrote:
At least for i386, I expect it to be used mostly for legacy
applications (and legacy installations). So breaking ABI by switching
to a "new" architecture or by just changing major libraries like libc6
probably diminishes its value so much t
On Sun, Feb 02, 2020 at 02:35:19PM +, Anthony DeRobertis wrote:
On February 2, 2020 12:02:33 PM UTC, Simon khng
wrote:
Why was rsyslog used as the persistent storage instead of journald for
previous Debian distribution?
rsyslog has been the default Debian log storage since before switchi
1 - 100 of 379 matches
Mail list logo
