Hi,
On 6.06.2024 ÖS 1:08, Johannes Schauer Marin Rodrigues wrote:
Hi,
Quoting Simon Richter (2024-06-06 11:32:33)
Would it be possible to set in stone that packages are supposed to always
be built in an environment where LC_ALL=C.UTF-8, or, in other words, that
builders must set LC_ALL=C.UTF-8
On 25.06.2024 ÖS 1:54, Andrey Rakhmatullin wrote:
On Tue, Jun 25, 2024 at 06:14:54AM -0400, Roberto C. Sánchez wrote:
The style of writing mail - everything in one line, CCing several lists is
similar to how Luna writes it too. Freaky.
AI can already generate audio and video that convincingl
Dear Daniel, and all,
> On 2 Sep 2024, at 22:56, Daniel Gröber wrote:
>
> Hi Andrej,
>
> On Mon, Sep 02, 2024 at 09:02:43PM +0200, Andrej Shadura wrote:
>> On Mon, 2 Sep 2024, at 19:41, Daniel Gröber wrote:
>>> You're continuing to confirm my pre-existing view that netplan infantilizes
>>> it's
Dear Lukas and All,
From my perspective, Netplan is a great add-on for homogenizing network
management in the cloud, which requires simple to semi-complicated network
needs, especially with heterogenous OS fleets. However, for many ways, Netplan
is not a great default to begin with, since it’s
> On 8 Jun 2023, at 06:19, Paul Wise wrote:
>
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
>
>> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>>modern x86_64 systems
>>2a. legacy native Linux i386 binaries
>>2b. legacy Windows i386 binaries vi
Hello,
I completely agree with you and many others on that regard. A private
key is private, and shall not be stored in a server where multiple users
might access to and open to internet, which can be compromised.
Doing this makes the attack surface substantially larger, and given the
target
However, shoehorning X-is-X to apt for replacing alternatives is a very
unoptimal (and even backwards) approach, because it’s not only for simple
applications. Some of the daily alternatives I see are:
- x-www-Browser
- java (and the whole toolchain)
- editor
- vi
- pager
… The list goes on and
Metapackage approach is not the same for many reasons.
First, I have seen Debian installations which doesn’t have internet access, but
setup with many alternatives of the same application (e.g.: Java).
Moreover, apt automatically purges its cache after a successful transaction.
As I said in
I moved to Mozilla's official packages for the time being since I didn't
want to downgrade to ESR for now.
Will resume with Debian's packages when the dust settles down.
On 25.03.2024 ÖÖ 8:26, Leandro Cunha wrote:
Hi,
On Mon, Mar 25, 2024 at 2:18 AM Paul Wise wrote:
On Sun, 2024-03-24 at 2
Similarly, I’m following the thread for a couple of days now, and wondering
about its implications.
When I consider server scenarios, pushing /tmp to RAM looks highly undesirable
from my perspective. All the servers I manage use their whole RAMs and using
the unused space as a disk cache is far
Consider a long running task, which will take days or weeks (which is
the norm in simulation and science domains in general). System emitted a
warning after three days, that it'll delete my files in three days. My
job won't be finished, and I'll be losing three days of work unless I
catch that
x27;s no way to change that. I'm
just pointing out how the systems we work with behave. We don't
configure them that way. Heck, some of the applications our users use
have no configuration file whatsoever.
I'm all for progress and a better, self-healing system, but I'm very
> On 7 May 2024, at 18:57, Russ Allbery wrote:
>
> Hakan Bayındır writes:
>> Dear Russ,
>
>>> If you are running a long-running task that produces data that you
>>> care about, make a directory for it to use, whether in your home
>>> dir
Sent from my iPhone
> On 7 May 2024, at 18:39, Holger Levsen wrote:
>
> On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote:
>> Consider a long running task, which will take days or weeks (which is the
>> norm in simulation and science domains in gener
I also think that Lintian is one of the most important tools in Debian
packaging ecosystem. I'm not a Debian Developer, but have built packages
for our Debian derivative distribution (Pardus, which I tech-led it for
some time). The first step was to get the package "Lintian-clean (TM)"
before e
On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:
On 2024-05-28 Luca Boccassi
wrote:
[...]
- existing installations pre-trixie will get an orphaned tmpfiles.d in
/etc/ that keeps the existing behaviour unchanged (no cleanup of
/var/tmp)
[...]
Hello,
I think it is bad choice to deliberately ha
> On 29 May 2024, at 17:33, Marvin Renich wrote:
>
> * Hakan Bayındır [240529 07:51]:
>> On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:
>>> On 2024-05-28 Luca Boccassi
>>> wrote:
>>> [...]
>>>> - existing installations pre-trixie will g
> On 30 May 2024, at 09:15, Marc Haber wrote:
>
> On Wed, 29 May 2024 14:35:27 +0300, Hakan Bay?nd?r
> wrote:
>> I'll kindly disagree here. I'd rather not have to go back to every
>> system and make sure that they all behave the way I want after doing a
>> periodic, completely boring "apt-g
Dear Christian,
Can you please share the outputs "lspci -vvv" and "dmidecode" commands
(please run them as the root user) as text files? This will allow
anybody interested to see your hardware details, so pinpointing your
computer's details plus the hardware used for sound will be much easier.
Dear All and Steve,
I'm kinda late to the discussion, but upon reading the message, a
possible solution has been popped into my mind.
As everybody knows, Debian is also releasing the said firmware as
compressed archives and these are visible in the download page [0],
however usage and docume
Hi Andrey,
On 4/21/22 10:50, Andrey Rahmatullin wrote:
On Thu, Apr 21, 2022 at 09:57:36AM +0300, Hakan Bayındır wrote:
As everybody knows, Debian is also releasing the said firmware as compressed
archives and these are visible in the download page [0], however usage and
documentation is
Sorry for duplicate - It was from a wrong account. Re sending just to
ensure delivery.
---
Dear All and Steve,
I'm kinda late to the discussion, but upon reading the message, a
possible solution has been popped into my mind.
As everybody knows, Debian is also releasing the said firmware as
On 4/21/22 11:09, Andrey Rahmatullin wrote:
On Thu, Apr 21, 2022 at 10:57:47AM +0300, Hakan Bayındır wrote:
As everybody knows, Debian is also releasing the said firmware as compressed
archives and these are visible in the download page [0], however usage and
documentation is neither clearly
> On 21 Apr 2022, at 21:14, Gunnar Wolf wrote:
>
> Marc Haber dijo [Tue, Apr 19, 2022 at 06:56:54PM +0200]:
>> On Tue, 19 Apr 2022 08:21:10 -0600, Sam Hartman
>> wrote:
>>> One valuable suggestion was to make sure users could easily select
>>> freedom if that's what they wanted.
>>> So I think
On 4/22/22 08:18, Andreas Tille wrote:
Am Thu, Apr 21, 2022 at 10:12:19AM -0700 schrieb Russ Allbery:
I've been a Debian Developer for quite some time and can usually manage to
figure out most tasks like this, and providing separate firmware to the
installer has completely defeated me every
> On 25 Apr 2022, at 19:40, Andrey Rahmatullin wrote:
>
> On Mon, Apr 25, 2022 at 05:53:03PM +0200, Paul van der Vlis wrote:
>> I have an idea for an extra option:
>>
>> 6. Put the closed source firmware somewhere in the Debian images, but
>> never
>> install closed sourc
On 4/26/22 09:12, Ansgar wrote:
On Mon, 2022-04-25 at 23:48 +0300, Hakan Bayındır wrote:
While what you’re saying is technically true, the default selection
means much more than a default. It’s defines the stance of Debian, as
a whole.
[...]
So, if Option 5 is adopted, the default state is
> On 26 Apr 2022, at 11:30, Ansgar wrote:
>
> On Tue, 2022-04-26 at 10:47 +0300, Hakan Bayındır wrote:
>> While I understand where you're coming from, I don't think such thing
>> is necessary, because a) Most popular devices with non-free firmware
>> blo
On 4/26/22 12:08, Andrey Rahmatullin wrote:
On Tue, Apr 26, 2022 at 11:59:20AM +0300, Hakan Bayındır wrote:
No, they do not. Most popular devices won't work at all without non-
free firmware, including boring things such as mass storage (SD cards,
SSD, HDD, ..., and controllers),
On 30.05.2022 09:36, Andrey Rahmatullin wrote:
On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote:
There are definitely people who use forks because it's easier to
install non-free firmware. What's the problem with that? Let them use
forks. A distro can't be all things to all people.
This
On 1.06.2022 14:33, Marc Haber wrote:
On Wed, 1 Jun 2022 09:41:35 +0300, Hakan Bay?nd?r
wrote:
As a person who's handling a lot of servers, I can tell that most high
performance hardware is running either load-on-boot (generally ethernet
and other network cards) or persistent (generally stor
This is exactly my point of view of ITPs as well, while I'm not as
involved in Debian in most of the people here, it's a nice and proper
gateway to see what's happening and what people are working on.
Also, I have taken note of at least of couple pieces of software which I
could use developing
Hi Adam,
I’d object that, because after we rotate the logs, we use a lot of z commands,
namely zcat, zgrep, zless. Which allows us process many gigabytes of gzip files
without extracting them first.
We have a big cluster at office and a central logging system. That system
handles close to a th
Hello all,
While all looks good and feels sound from many aspects, I have some
reservations against treating changelogs as metadata.
Current changelogs as files have a well known place, can be used by
anything and everything, and they are local.
Stuffing them behind a command, possibly maki
Hi Andrey,
> On 6 Sep 2022, at 12:42, Andrey Rahmatullin wrote:
>
> On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote:
>> While all looks good and feels sound from many aspects, I have some
>> reservations against treating changelogs as metadata.
>>
>
> On 11 Sep 2022, at 14:59, Andrey Rahmatullin wrote:
>
> On Sun, Sep 11, 2022 at 02:41:24PM +0300, Hakan Bayındır wrote:
>>> On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote:
>>>> While all looks good and feels sound from many aspects, I have
> On 14 Sep 2022, at 10:37, Wouter Verhelst wrote:
>
> On Sun, Sep 11, 2022 at 03:09:07PM +0300, Hakan Bayındır wrote:
>> Yes, you’re right. However, my reservation is whether dpkg is more prone to
>> breaking in disaster recovery scenarios. Reading a gzipped file is a
We use Keycloak in both at office and in international projects as
backbones of relatively big and federated SSO systems, and it works fine.
It's not very hard to deploy and configure on bare metal. Enabling its
own HTTPS/SSL features are also relatively straightforward.
I'm sure that it can
On 1.12.2022 12:16, Paul Wise wrote:
On Sat, 2022-11-26 at 19:42 +0100, Patrice Duroux wrote:
Any (or a specific group of) users could be able to install any
package of the first class by their own without asking a sysadmin (or
explicitly acquiring privilege of) user.
The general idea of a
> On 22 Sep 2024, at 14:47, Chris Hofstaedtler wrote:
>
> As far as I understood Lukas' mail, then at least currently not, as
> NM in Debian doesn't come with patches to support two-way
> configuration with netplan.
I think this is a very serious regression for desktop systems. Debian started
Hi,
On 23.09.2024 ÖS 2:09, Lukas Märdian wrote:
But about working towards unified network configuration.
-- Lukas
So, is it "Let's include it in a dormant state for desktop systems
today, so we can go netplan-only in Trixie+1"?
I personally can't fathom why there's a great push about netpl
> On 2 Dec 2024, at 09:10, Andrey Rakhmatullin wrote:
>
> On Mon, Dec 02, 2024 at 09:38:28AM +0800, kindusmith 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 argument
Hi Julian,
How would that work for non-BTRFS systems, and if not, will that make
Debian a BTRFS-only system?
I'm personally fine with "This works faster in BTRFS, because we
implemented X", but not with "Debian only works on BTRFS".
Cheers,
Hakan
On 12/27/24 11:18 AM, Julian Andres Klode
> On 27 Dec 2024, at 20:46, Jonathan Kamens wrote:
>
> On 12/27/24 7:34 AM, Geert Stappers wrote:
>> Yeah, it feels wrong that dpkg gets file system code, gets code for one
>> particular file system.
>>
> I disagree. If there is a significant optimization that dpkg can implement
> that is on
On 12/26/24 12:33 PM, Julien Plissonneau Duquène wrote:
Hi,
Le 2024-12-24 15:10, Simon Richter a écrit :
This should not make any difference in the number of write operations
necessary, and only affect ordering. The data, metadata journal and
metadata update still have to be written.
I w
Hi Michael,
That sounds like a neat idea. Especially, with the proliferation of more
complex filesystems like BTRFS, the penalty of calling fsyc() a lot becomes
very visible. I’m not a BTRFS user myself, but I always hear comments and
discuss about it.
Removing this workaround can help to remo
> On 29 Dec 2024, at 20:20, Enrico Zini wrote:
>
> Hello,
Hi,
>
> today I decided to upgrade from bookworm to trixie/testing[1][2]. I ran
> the upgrade in a gnome-terminal, and of course all gnome terminals in
> the system crashed halfway through the upgrade[1][3].
This is strange. I’m not
On 3/6/25 4:00 PM, Lee Garrett wrote:
On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek"
wrote:
Both network "outages" could have been prevented by adding a note at
the end of the dist-upgrade output.
e.g. something like the following (monospace font required for the
"Attention" te
Hi Stephan,
In first blush, I don’t think shaders should be considered firmware. They are
not used to enable the hardware, but they’re just programs which work on pixels
to perform some functions. These functions work like “suggested/recommended”
packages which enable more functions with the ha
Sent from my iPhone
> On 12 Mar 2025, at 18:09, Marco d'Itri wrote:
>
> On Mar 12, Hakan Bayındır wrote:
>
>> If we think that a shader is a firmware, any software running on the second
>> socket on a system is also a firmware, since the program is running
> On 12 Mar 2025, at 13:02, Marco d'Itri wrote:
>
> On Mar 12, Hakan Bayındır wrote:
>
>> In first blush, I don’t think shaders should be considered firmware. They
>> are not used to enable the hardware,
> I am not taking a position about shaders at this poi
On 3/26/25 9:56 AM, Sarbjit Singh Sandhu wrote:
Thanks for your suggestion I liked that but can you please help me that
how to use and install debian on approx 20 computers of my schools with
the kde plasma desktop and how to update them every 2 years and also
making it user friendly for the pe
52 matches
Mail list logo
