ges were either too
young (so they were too late regarding the hard freeze anyway) or almost
ready (so they insta-migrated as soon as I lifted the “udeb freeze”) —
cryptsetup, libpng1.6, lvm2, during the 16:00Z britney run this Friday.
> That being said, the release team has agreed (should it be need
that made sense to have in trixie, some of them
looked like “unimportant” updates that could wait, and I've ignored
them. I haven't been consistent, but you can check debian-boot@ and/or
debian-release@ from the last few hours for some public queries sent to
maintainers/uploaders, as I trie
ucing
packages to wait for your pre-approval before uploading anything
non-urgent to unstable during this period; or is it OK to upload to
unstable, and rely on the block-udeb hints to prevent our packages from
reaching testing at an inconvenient time?
(subject to the usual release team app
Hi Paul,
I used the release notes to upgrade a bookworm system to a trixie system. I
like the new layout of the release notes, thanks for the layout upgrade :-)
Overall it went very well, for the only real issue I run into, I filed a bug
report:
https://bugs.debian.org/cgi-bin/bugreport.cgi
On Sun, Apr 13, 2025 at 10:45:56PM +0200, Rainer Dorsch wrote:
> I am not a Debian developer, therefore I cannot create a pull request for
> fixes
> in the release notes myself,
You absolutely can. One does *not* need to be a Debian Developer to send
patches to the Debian BTS, or
On Wed, Mar 26, 2025 at 12:26:42PM +0530, 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
gt; * TBA- Milestone 4 - Full Freeze
>all packages need a manual unblock for migration
>
> === RC bugs ===
>
> The current list of Release Critical bugs for trixie [3] is
> progressively looking better. Thanks to everybody who is helping
> out. That said,
t; * 2025-04-15 - Milestone 2 - Soft Freeze
>>no new packages, delayed migration
>> * 2025-05-15 - Milestone 3 - Hard Freeze - key packages and packages
>>without autopkgtests need a manual unblock for migration
>> * TBA- Milestone 4 - Full F
/Preseed
> [1]: https://fai-project.org/
> >
> > On Wed, 5 Mar, 2025, 1:45 pm Gard Spreemann, > <mailto:g...@nonempty.org>> wrote:
> >
> >
> > Sarbjit Singh Sandhu > <mailto:sarbjitsinghsandhu...@gmail.com>> writes:
> >
> >
ing to propose the creation of a new Debian branch that
> offers a stable release every year, as opposed to the current 5-year
> cycle.
It's really great to see young people interested in Debian. I do need to
point out that the current cycle has been approximately 2
, 1:45 pm Gard Spreemann, wrote:
>
> Sarbjit Singh Sandhu writes:
>
> > I am writing to propose the creation of a new Debian branch that
> > offers a stable release every year, as opposed to the current 5-year
> > cycle.
>
> It's really great to see young peo
Am Mittwoch, dem 05.03.2025 um 14:38 + schrieb Jeremy Stanley:
> There's also a several-month freeze after taking a snapshot of
> packages from sid before the release occurs, so when an Ubuntu LTS
> release happens the contemporary age of packages in the prior LTS is
> we
On 2025-03-05 10:40:38 + (+), Stephan Verbücheln wrote:
[...]
Ubuntu schedules its LTS release always for April (normal releases
October), because Gnome is always releasing in March and September. So
for Ubuntu LTS users, the age of desktop apps is up to two years.
[...]
Not really
cantly older.
For example, the Bookworm freeze started in January 2023, so the
desktop apps are based on the Gnome release of September 2022. When
Trixie will be released, the apps in Bookworm will be almost three
years old. This is where average users feel the age.
Ubuntu schedules its LTS release
Sarbjit Singh Sandhu writes:
> I am writing to propose the creation of a new Debian branch that
> offers a stable release every year, as opposed to the current 5-year
> cycle.
It's really great to see young people interested in Debian. I do need to
point out that the current
> In my opinion, the better solution would be to have more backports in
> the stable release because people are mostly unhappy with outdated apps
> and not with outdated essential core components.
What about the project to automatically build backports around janitor ?
What is the statu
In my opinion, the better solution would be to have more backports in
the stable release because people are mostly unhappy with outdated apps
and not with outdated essential core components.
This would probably not even require a policy change in Debian. But it
requires a lot of people with a lot
Andrey Rakhmatullin writes:
Unfortunately, while proposing is cheap, actually *doing* this
is somewhat harder. So unless you, and a suitable number of
other people, are ready to work on this, this won't happen.
A more realistic goal might be to increase the number of packages
in the backpo
On Tue, Mar 04, 2025 at 02:12:05PM +0530, Sarbjit Singh Sandhu wrote:
Dear Debian Developers,
I am writing to propose the creation of a new Debian branch that offers a
stable release every year, as opposed to the current 5-year cycle. This
would be particularly beneficial for educational
Dear Debian Developers,
I am writing to propose the creation of a new Debian branch that offers a
stable release every year, as opposed to the current 5-year cycle. This
would be particularly beneficial for educational institutions, where a
balance between stability and up-to-date software is
On 28/01/2025 12:37, Frank Guthausen wrote:
On Tue, 28 Jan 2025 09:34:37 +0100
Emilio Pozuelo Monfort wrote:
On 27/01/2025 23:15, Andrea Bolognani wrote:
https://release.debian.org/trixie/freeze_policy.html
Updated
Almost - there are still the first three TBAs in the 2nd table row.
On Tue, 28 Jan 2025 09:34:37 +0100
Emilio Pozuelo Monfort wrote:
> On 27/01/2025 23:15, Andrea Bolognani wrote:
> >
> >https://release.debian.org/trixie/freeze_policy.html
>
> Updated
Almost - there are still the first three TBAs in the 2nd table row.
--
kind regards
Frank
pgpFVLmM08Tzp.
On 27/01/2025 23:15, Andrea Bolognani wrote:
On Wed, Jan 22, 2025 at 11:00:00PM +0100, Emilio Pozuelo Monfort wrote:
Trying to follow our release cadence, we are going to start freezing
trixie in March. As usual, it is our intention to have a short freeze,
though with the short notice that may
On Wed, Jan 22, 2025 at 11:00:00PM +0100, Emilio Pozuelo Monfort wrote:
> Trying to follow our release cadence, we are going to start freezing
> trixie in March. As usual, it is our intention to have a short freeze,
> though with the short notice that may be hard. We apologiz
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 br
On Sun, Mar 03, 2024 at 09:25:41PM +0100, hwspeedy wrote:
> Hi Simon Quiqley, (CC: debian-devel)
>
> I'm trying to figure out how to get the hardinfo2 - release 2.0.12 into
> debian repository.
> hardinfo2 is a community fork of hardinfo and should continue as hardinfo
Hi Simon Quiqley, (CC: debian-devel)
I'm trying to figure out how to get the hardinfo2 - release 2.0.12 into
debian repository.
hardinfo2 is a community fork of hardinfo and should continue as
hardinfo package, currently maintained in debian by Simon Quiqley.
Salvo Tomaselli suggested
Hi Simon Quigley, Debian Maintainer, (CC: debian-devel list)
We are proud to suggest new hardinfo2 release 2.0.12 to be included in
debian repositories - test on debian 7 - SID(13).
https://github.com/hardinfo2/hardinfo2/releases/tag/release-2.0.12
PS: My first release, so please guide me
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-k8s-sigs-release-utils
Version : 0.7.7-1
Upstream Author : Kubernetes SIGs
* URL : https://github.com/kubernetes-sigs/release-utils
* License : Apache-2.0
Programming Lang: Go
Hi
On 18-12-2023 11:29, Santiago Vila wrote:
El 17/12/23 a las 22:40, Steven Robbins escribió:
Does that mean ceasing the "ITP" messages in debian-devel?
I'd certainly welcome that!
I think he really meant debian-release, as this was "Bits from
the Release Team"
Hi,
On 18-12-2023 13:18, Antonio Terceiro wrote:
Will reproducibility regressions block migration to testing?
Not for the near future for 2 reasons:
1) contrary to autopkgtest where removal of the test "fixes" regression,
it feels that currently blocking on regression would give maintainers
On Sat, Dec 16, 2023 at 06:23:46PM +, Paul Gevers wrote:
> Reproducibility migration policy
>
>
> The folks from the Reproducibility Project have come a long way since they
> started working on it 10 years ago, and we believe it's time for the next step
> in De
On Sat, Dec 16, 2023 at 06:23:46PM +, Paul Gevers wrote:
> During the wonderful mini-DebConf at Cambridge, the Release Team had a sprint
> and other discussions. Some of the discussed topics are worth sharing, so here
> we go.
[...]
> Reproducibility migr
already archives all information, and there are
multiple ways anyone can subscribe to the Release Team bugs, so this
mirroring seems unnecessary. More importantly it inhibits the list from
being a more useful discussion channel that we like it to be. Hence, we'll
try to work with the BTS maintaine
there are
> multiple ways anyone can subscribe to the Release Team bugs, so this
> mirroring seems unnecessary. More importantly it inhibits the list from
> being a more useful discussion channel that we like it to be. Hence, we'll
> try to work with the BTS maintainers to direct the tra
Matthew Garrett writes:
> On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
>
>> qemu is basically an interpreter for foreign machine code. If your
>> threat model allows access to qemu-user-static for an attacker, they
>> can run pretty much any binary is if it were native, and the w
Hi,
* Colin Watson [2023-07-14 11:50]:
On Fri, Jul 14, 2023 at 08:08:39AM +0100, Matthew Garrett wrote:
On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
> qemu is basically an interpreter for foreign machine code. If your
> threat model allows access to qemu-user-static for an att
On Fri, Jul 14, 2023 at 08:08:39AM +0100, Matthew Garrett wrote:
> On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
> > qemu is basically an interpreter for foreign machine code. If your
> > threat model allows access to qemu-user-static for an attacker, they
> > can run pretty much an
On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
> qemu is basically an interpreter for foreign machine code. If your
> threat model allows access to qemu-user-static for an attacker, they
> can run pretty much any binary is if it were native, and the whole
> SystemCallArchitectures h
* Guillem Jover [2023-07-13 19:36]:
The same would apply to any other interpreted program, as long as the
interpreter matches the systemd native architecture.
This, by the way, includes the following scenario:
* Trent W. Buck [2023-07-06 10:41]:
dpkg --add-architecture arm64
apt updat
Hi!
On Thu, 2023-07-06 at 18:41:38 +1000, Trent W. Buck wrote:
> "Trent W. Buck" writes:
> > e.g. I expect "SystemCallArchitectures=native" to break for a lot of
> > people (anyone doing dpkg --add-architecture)
Yes, see #982456.
> Short version:
>
> • SystemCallArchitectures=native + debian
On Sun, 2023-07-09 at 18:02 +0100, Luca Boccassi wrote:
> Note that we already have such a package in the archive: dbus-broker.
> It has been the default in Fedora for a long time, and it will be the
> default in Ubuntu in the future. It has been available in Debian since
> Bullseye - please help
On Thu, 6 Jul 2023 at 09:42, Trent W. Buck wrote:
>
> "Trent W. Buck" writes:
> > e.g. I expect "SystemCallArchitectures=native" to break for a lot of
> > people (anyone doing dpkg --add-architecture)
>
> Short version:
>
> • SystemCallArchitectures=native + debianutils:i386 doesn't break
> dp
s
> package build a variant that doesn't support traditional activation (for
> use on systemd-only systems), and a variant that does (for use on other
> systems). Then, we could work towards ensuring every D-Bus service
> supports service-based activation rather than only tradition
"Trent W. Buck" writes:
> e.g. I expect "SystemCallArchitectures=native" to break for a lot of
> people (anyone doing dpkg --add-architecture)
Short version:
• SystemCallArchitectures=native + debianutils:i386 doesn't break
dpkg-db-backup.service.
• Probably savelog simply never calls an AR
Russ Allbery writes:
> "Trent W. Buck" writes:
>
>> As someone who does that kind of thing a lot, I'd rather have
>> the increased annoyance of opt-out hardening than
>> the reduced security of opt-in hardening.
>> Even if it means I occasionally need to patch site-local rules into
>> /etc/appar
"Trent W. Buck" writes:
> As someone who does that kind of thing a lot, I'd rather have
> the increased annoyance of opt-out hardening than
> the reduced security of opt-in hardening.
> Even if it means I occasionally need to patch site-local rules into
> /etc/apparmor.d/local/usr.bin.msmtp or
>
Russ Allbery writes:
> [⋯]
> We know which PAM modules are installed and
> can analyze the PAM configuration files to know which ones are configured.
> We know which daemons use PAM.
> We similarly know which NSS modules are enabled.
> We can figure out what facilities they require, and could
> a
Philipp Kern writes:
> On 2023-07-05 09:36, Russell Coker wrote:
>> On Monday, 3 July 2023 22:37:35 AEST Russell Coker wrote:
>>> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
> My fear here would be that you are not in control of what your
> dependencies are doing. This is especia
||
|We would also like to reveal the codename of Debian 15, which will be
"Buttercup". This name follows the tradition of naming Debian releases
after characters from the Toy Story movies. We hope you like it and
look forward to your contributions to make Debian 15 another grea
On Wed, Jul 05, 2023 at 11:05:05PM +0200, Joaquín Rufo Gutierrez wrote:
> No, Debian 13 will be released on 2024 occasionally.
Who are you, sorry?
The person who sent this "announcement" doesn't seem to be part of the
Debian Project, they're also not listed as a member of the release
team at https://www.debian.org/intro/organization
Someone from the release team might confirm my assumption, but for now
please assume
Il 05/07/2023 22:50, Joaquín Rufo Gutierrez ha scritto:
|Hello Debian users, We are happy to announce that Debian 13,
codenamed "Trixie", is expected to be released sometime in 2024,
following the usual 2-year release cycle.|
|
|
|Hi, sorry but if it were |||2-year release cycle |
rixie", is
> > expected to be released sometime in 2024, following the usual 2-year
> > release cycle.
>
> Bookworm was released in 2023. The usual 2-year release cycle would put
> the next Debian to be released some time in 20*25*?
>
> Mike
>
On Wed, Jul 05, 2023 at 10:50:34PM +0200, Joaquín Rufo Gutierrez wrote:
> Hello Debian users,
>
> We are happy to announce that Debian 13, codenamed "Trixie", is
> expected to be released sometime in 2024, following the usual 2-year
> release cycle.
Bookworm was rele
Hello Debian users,
We are happy to announce that Debian 13, codenamed "Trixie", is
expected to be released sometime in 2024, following the usual 2-year
release cycle. The exact release date will depend on the progress of
testing and bug fixing, but we will keep you updated on the
d
Philipp Kern writes:
> My fear here would be that you are not in control of what your
> dependencies are doing. This is especially true if you think of NIS and
> PAM, where libraries are dlopen()ed and can spawn arbitrary helper
> binaries. I remember openssh installing a syscall filter for its a
On 2023-07-05 09:36, Russell Coker wrote:
On Monday, 3 July 2023 22:37:35 AEST Russell Coker wrote:
https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
People have asked how hard it is to create policy for daemons. For an
individual to create them it's a moderate amount of work, 1-2 h
On Monday, 3 July 2023 22:37:35 AEST Russell Coker wrote:
> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
People have asked how hard it is to create policy for daemons. For an
individual to create them it's a moderate amount of work, 1-2 hours per daemon
which is a lot considering
Marco d'Itri writes:
> This is a good example of what an almost fully sandboxed service looks like:
> https://salsa.debian.org/md/rpki-client/-/blob/master/debian/rpki-client.service
My best score is a little better :-)
On Debian 11 (systemd v247):
→ Overall exposure level for collection4.servic
Marco d'Itri writes:
> On Jul 04, Andrey Rakhmatullin wrote:
>
>> Cool but looks like a lot of work.
[...]
>> start with applying all of them and then looking what needs to be
>> disabled?
> This is what I do.
FYI below is my basic workflow.
Once you've done 2-5 daemons, you get a "feel" for
Marco d'Itri writes:
> On Jul 04, "Trent W. Buck" wrote:
>
>> * If it runs its own process manager (e.g. postfix's "master"),
>> don't bother trying to harden it.
> I disagree. It may not be possible to use NoNewPrivileges, but at least
> file system hardening is usually trivial to enable
On Jul 04, Andrey Rakhmatullin wrote:
> Cool but looks like a lot of work.
I do not think that this is really a lot of work.
> Is it possible to do this without
> applying the flags one by one and testing the result? Is it easier to
You may intimately know what the daemon needs to do and how the
On Mon, Jul 03, 2023 at 11:40:18PM +0200, Marco d'Itri wrote:
> This is a good example of what an almost fully sandboxed service looks
> like:
>
> https://salsa.debian.org/md/rpki-client/-/blob/master/debian/rpki-client.service
Cool but looks like a lot of work. Is it possible to do this without
On Jul 04, "Trent W. Buck" wrote:
> * If it runs its own process manager (e.g. postfix's "master"),
> don't bother trying to harden it.
I disagree. It may not be possible to use NoNewPrivileges, but at least
file system hardening is usually trivial to enable for most daemons.
> * If it
a variant that does (for use on other
systems). Then, we could work towards ensuring every D-Bus service
supports service-based activation rather than only traditional
activation. Over the course of a release cycle or so, we *could* get to
the point of being able to lock down D-Bus on systemd systems.
RL writes:
> Russell Coker writes:
>
>> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
>>
>> I think we should make it a release goal to have as many daemons as
>> possible running with systemd security features to aim for a low score
>> from &
Hi,
Jonathan Carter (2023-07-03):
> One shouldn't trust everything that is read on Matrix. I suggest asking
> the release team for clarification, because my last understanding is
> that release goals still exist, it's just that the release team doesn't
> want to be t
boxing,
considering that it is so easy with systemd.
I am not sure if it can be a release goal, but it definitely should be
a best practice.
This is a good example of what an almost fully sandboxed service looks
like:
https://salsa.debian.org/md/rpki-client/-/blob/master/debian/rpki-client.s
On Mon, 03 Jul 2023 at 20:21:20 +0100, RL wrote:
> (One of the issues for services that send email is that it is very
> easy to break exim)
It's also very easy to break anything else that relies on running a
setuid/setgid/setcap executable (including many mail delivery agents,
not just Exim), as t
On 2023-07-03 14:21, RL wrote:
Russell Coker writes:
https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
I think we should make it a release goal to have as many daemons as
possible running with systemd security features to aim for a low score
from "systmd- analyze security&q
Russell Coker writes:
> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
>
> I think we should make it a release goal to have as many daemons as
> possible running with systemd security features to aim for a low score
> from "systmd- analyze security".
This
Hi Russell
On 2023/07/03 14:37, Russell Coker wrote:
Someone said on Matrix that we aren't going to have official release goals in
future.
One shouldn't trust everything that is read on Matrix. I suggest asking
the release team for clarification, because my last understandin
Someone said on Matrix that we aren't going to have official release goals in
future. If so that doesn't stop people from doing the work just makes it less
of an issue to release with some of the bugs unsolved.
https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
I think we s
Hi,
Stéphane Blondon wrote (Sun, 28 May 2023 13:16:24
+0200):
> > > Richard Lewis wrote (Fri, 19 May
> > 2023 00:58:26 +0100):
> >
> > > - are the red hyphens in eg the 'deb...' line near the top of
> > > >
> > https://people.de
> > Richard Lewis wrote (Fri, 19 May
> 2023 00:58:26 +0100):
>
> > - are the red hyphens in eg the 'deb...' line near the top of
> > >
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html
> > > meant to be red? (maybe it i
r simpler, or even
> use a canned one like (this was simply my first web search result):
>
> https://pypi.org/project/Sphinx-Substitution-Extensions/
>
> The examples in its readme look to be along the lines of the Debian
> Release Notes use case anyway. There's also basic substitu
substitution you could get away with something far simpler, or even
use a canned one like (this was simply my first web search result):
https://pypi.org/project/Sphinx-Substitution-Extensions/
The examples in its readme look to be along the lines of the Debian
Release Notes use case any
is still lacking some
> > > functionality,
> > > which is heavily used in the release-notes.
> > > That is the use of substitutions within URLs.
> > > In docbook speach these were entities, and you could use them in URLs
> > > like this:
> >
tities (or now called substitutions) in
quoted lines like
deb https://deb.debian.org/debian RELEASENAME main contrib
or
# script -t 2>~/upgrade-RELEASENAMEstep.time -a
~/upgrade-RELEASENAMEstep.script
These also do not work.
That's the biggest blocker in the upgrading c
Hi,
RL wrote (Sat, 20 May 2023 12:52:25
+0100):
> Holger Wansing writes:
>
> > However, I may have some objections against the migration at all:
> > as far as I know, sphinx/reStructuredText is still lacking some
> > functionality,
> > which is heavily used in
Holger Wansing writes:
> However, I may have some objections against the migration at all:
> as far as I know, sphinx/reStructuredText is still lacking some functionality,
> which is heavily used in the release-notes.
> That is the use of substitutions within URLs.
> In docbook sp
Am 19.05.23 um 17:35 schrieb Ansgar:
I suggest to already document this in the release notes for bookworm,
possibly in Section 2.1 (Supported architectures) or a subsection in
Section 5 (Issues to be aware of for bookworm).
Maybe something along these lines:
+---
| Debian 12 is expected to be
Package: release-notes
X-Debbugs-Cc: Steve McIntyre , debian-devel@lists.debian.org
On Fri, 2023-05-19 at 15:03 +0100, Steve McIntyre wrote:
> I had been thinking about doing similar for installer images too, but
> with other work going on too I think it got too late in the cycle to
>
[[ debian-devel in CC, to get a wider audience regarding reStructuredText ]]
Hi,
I worked on this recently, and I have something like a prototype ready.
It can be found (as html) at
https://people.debian.org/~holgerw/release-notes_sphinx/
while the git repo containing the migration is at
https
Charles Curley (2023-04-03):
> Hmm. On https://www.debian.org/devel/debian-installer, there are two
> news items at the top. Both are dated 19 Feb 2023. Is that correct?
>
> The RC1 release
> (https://www.debian.org/devel/debian-installer/News/2023/20230403) is
> also dated F
On Mon, 3 Apr 2023 23:31:42 +0200
Cyril Brulebois wrote:
> The Debian Installer team[1] is pleased to announce the first release
> candidate of the installer for Debian 12 "Bookworm".
Hmm. On https://www.debian.org/devel/debian-installer, there are two
news items at the top. B
t;> you're ready to sign up to maintaining in stable.
>> I think that's the kind of sing-up-to-do-the-work that the security and
>> release team are waiting for.
>
>I'd be happy if singularity would be in stable. I'm not sure how far
>I can help out since
x27;s the kind of sing-up-to-do-the-work that the security and
> release team are waiting for.
I'd be happy if singularity would be in stable. I'm not sure how far
I can help out since I'm lacking competence in Go but if needed I might
contribute to my limited skills.
Kind regards
Andreas.
--
http://fam-tille.de
>>>>> "Nilesh" == Nilesh Patra writes:
Nilesh> Since I had done quite a bit of work on this, I'm a sad to
Nilesh> see this happen, as fasttrack still has much less visibility
Nilesh> / availability than an official stable release, or even
in stable to fix security issues if those new versions are not
bugfix-only releases. We have to accept that for browsers, because
shipping without them seems like a disservice to nearly all of our
users, but still it's something we really don't like.
fasttrack still has much less visibi
ainer,
> > > which lead for buster to https://bugs.debian.org/917867 and keeping it
> > > out of
> > > the stable release, did not really change in the aspect of beeing able to
> > > patch
> > > vulnerabilities to the stable branch once upstream version
release, did not really change in the aspect of beeing able to patch
vulnerabilities to the stable branch once upstream versions moved on, is this
correct interpretation? In context from #917867, it was even in stretch at
first, but needed to be removed after stretch was released in a point release.
If
On Sat, Jan 21, 2023 at 08:34:40PM +0100, Salvatore Bonaccorso wrote:
> So in my understanding of the above the situation around
> singularity-container,
> which lead for buster to https://bugs.debian.org/917867 and keeping it out of
> the stable release, did not really change in t
M +0530, Nilesh Patra wrote:
> > > src:singularity-container was lying around in a bad shape for several
> > > years
> > > and had missed 2 debian releases until me and Andreas picked it up again.
> > > It is currently in a reasonably good condition. I was excited
y-container was lying around in a bad shape for several years
> > and had missed 2 debian releases until me and Andreas picked it up again.
> > It is currently in a reasonably good condition. I was excited to have it in
> > stable release again, but I have a couple of doubts over it
ith respect to the lifecycle
of SingularityCE versions.
TLDR...
* We only do patch releases for a minor x.y version of the open-source
SingularityCE for ~6 months.
* For versions of SingularityCE that we turn into a commercial
SingularityPRO release our security policy means we will provide
t; or not.
>
> I'd appreciate if someone on the list could chime in and give an opinion on
> if they
> consider it do-able or not for upcoming bookworm release.
>
Could you list the concerns that you have?
+ Security support?
I see upstream comments that they will disclose th
ave it in
> stable release again, but I have a couple of doubts over it.
>
> 1. A little background:
> singularity-container sync the code from the upstream codebase for sylabs[1]
> and there also exists a community-maintained fork called apptainer.
> Sylabs singularity CE see
> > it may be better to support such an API in uscan internals.
>
> I believe redirectors are more appropriate for that. Internals of uscan
> are relatively uncomplicated and do not know any site-specific APIs.
I didn't know redirector well, after that, yes, fakeupstream.cgi can
supp
1 - 100 of 5787 matches
Mail list logo
