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
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
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 gen
> 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
>>>
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
against breaking things while doing that.
Cheers,
H.
On 7.05.2024 ÖS 5:32,
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
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
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
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
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
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
> 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
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
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 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
> 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
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.
>>
>
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
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
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
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
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.
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), input
> 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
>> blobs already
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
> 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
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 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
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
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
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
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
32 matches
Mail list logo
