* Andreas Metzler [241231 06:59]:
> On 2024-12-29 Helmut Grohne wrote:
> > On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> [...]
> >> I would also like to do something similar to unstable; maybe start with
> >> packages uploaded before some arbitrary date that are also not included
>
On 2024-12-29 Helmut Grohne wrote:
> On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
[...]
>> I would also like to do something similar to unstable; maybe start with
>> packages uploaded before some arbitrary date that are also not included
>> in any of oldstable/stable/testing. These ca
Package: release-notes
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org, gib...@debian.org
TL;DR -- It is expected that trixie will be the last release of
Debian to include LXD, and users are encouraged to migrate to Incus
after upgrading.
(CC'ing debian-devel for broader awarenes
Niels Thykier:
Hi,
This is an update on the MBF for `Rules-Requires-Root: no` as the new
default.
Two weeks further down the line with another update. :)
# Qualitative updates:
* I have asked the release team to look into whether we should go ahead
with this for Trixie or wait until a
Le Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 a écrit :
> Hi,
>
> I'm wondering how we can clean up suites like experimental and
> unstable. They tend to slowly accumulate cruft that nobody cleans up,
> including no longer installable packages.
>
> As a very simple start, I would like to rem
Hi,
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.
The issue here is that without the fsync there is a risk that such
corruption occurs even
Simon Richter writes:
The order of operation needs to be
>
> 1. create .dpkg-new file
> 2. write data to .dpkg-new file
> 3. link existing file to .dpkg-old
> 4. rename .dpkg-new file over final file name
> 5. clean up .dpkg-old file
>
> When we reach step 4, the data needs to be written to disk
Hi Ansgar,
On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> I'm wondering how we can clean up suites like experimental and
> unstable. They tend to slowly accumulate cruft that nobody cleans up,
> including no longer installable packages.
>
> As a very simple start, I would like to rem
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-odmantic
Version : 1.0.2
Upstream Contact: Arthur Pastel
* URL : https://github.com/art049/odmantic
* License : ISC
Programming Lang:
On Sunday, December 29, 2024 12:39:59 PM MST Richard Lewis wrote:
> Otto Kekäläinen writes:
> >> >> i think the barrier is likely to be "i didnt know you could do that?"
> >> >> rather than "how do i use that?"
> >> >
> >> > Salsa CI is and has always been opt-in.
> >>
> >> oops - i meant the op
Am 30. Dezember 2024 11:40:31 MEZ schrieb Thomas Goirand :
>On 12/28/24 22:52, Simon Josefsson wrote:
>> Is it possible to configure Salsa so instead of using the GitLab default
>> of .gitlab-ci.yml it uses debian/salsa-ci.yml if that file exists but
>> otherwise falls back to recipes/debian.yml@sa
Package: wnpp
Severity: wishlist
Owner: Karsten Schoeke
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: redfish
Version : 3.7.5
Upstream Contact: DMTF, https://www.dmtf.org/standards/feedback
* URL : https://github.com/DMTF/python-redfish-library
* License
Sorry, seems that the previous message was corrupted by the client.
On 30/12/24 11:59, Matteo Croce wrote:
> Part of the trick here is that the fsync()s are skipped, but I think
> even if none of the above were problems, then we'd still need to
> fsync() stuff to get the actual filesystem entries
> Part of the trick here is that the fsync()s are skipped, but I think
> even if none of the above were problems, then we'd still need to >
fsync() stuff to get the actual filesystem entries to make sense, so >
the currently missing directory fsync()s might be a worse problem for >
such reflink
On 12/28/24 22:52, Simon Josefsson wrote:
Is it possible to configure Salsa so instead of using the GitLab default
of .gitlab-ci.yml it uses debian/salsa-ci.yml if that file exists but
otherwise falls back to recipes/debian.yml@salsa-ci-team/pipeline? That
seems like a sensible global configurat
15 matches
Mail list logo
