ards with a different architecture.
There still are some options left. As of now, armel is still in the
Debian archive and still building packages. Packages will degrade (e.g.
stop building). This will be particularly noticeable when it comes to
atomic operations as armel tends to require -latomic in
(sorry for the late reply)
On Sun, Aug 17, 2025 at 01:35:08PM +0100, Simon McVittie wrote:
> If the 32-bit ports are going to survive, then the affected packages either
> need to be cross-compiled from a 64-bit architecture (which is not something
> that Debian has traditionally don
nee-dedicated for using <
If you are just asking about the required syntax, I think what you are looking
for is << (just < is not a valid syntax for this field).
https://www.debian.org/doc/debian-policy/ch-relationships.html
> > What's the proper way to ensure that nwnxee version
changes on git submodule
Maybe consult man debian-watch and note that afaik the newline after
Version: 5 is mandatory.
By chance I forgot this hint and it works even without the newline.
Thanks a lot for your hints
Cheers,
Yadd
> Maybe consult man debian-watch and note that afaik the newline after
> Version: 5 is mandatory.
By chance I forgot this hint and it works even without the newline.
Thanks a lot for your hints
Andreas.
--
https://fam-tille.de
Pattern: HEAD
Mode: git
Git-Pretty: 0.0~git%cd
Maybe consult man debian-watch and note that afaik the newline after
Version: 5 is mandatory.
Best,
--
Carl
signature.asc
Description: PGP signature
uickly and retrieves nothing. A dedicated
Template for this would be a great help.
Kind regards
Andreas.
[1]
https://salsa.debian.org/go-team/packages/golang-github-jacobsa-timeutil/-/blob/master/debian/watch?ref_type=heads
--
https://fam-tille.de
tch with 8193.37.16 but
> >>> not 8193.37.15.
> >>>
> >>> If I write nwnxee depends as `nwnee-dedicated (>= 8193.37.15),
> >>> nwnee-dedicated (<8193.37.16)`, then I get a deprecated warning for
> >>> nwnee-dedicated for
ust < is not a valid syntax for this field).
I guess the << works. Thanks!
https://www.debian.org/doc/debian-policy/ch-relationships.html
What's the proper way to ensure that nwnxee version is always the same
major.minor.patch nwnee-dedicated ?
Are the produced from the
Hello
I'm trying to create a package nwnxee that depends on package
nwnee-dedicated.
But both versions must be the same. If nwnxee is installed as version
8193.37.15+deb12u2~git18cffdba, then nwnee-dedicated must be
8193.37.15-xyz, where xyz can be any number. It can not be
8193.37.14-xyz n
On Tuesday, September 9, 2025 1:15:20 PM Mountain Standard Time Julien Lecomte
wrote:
> Hello
>
> I'm trying to create a package nwnxee that depends on package
> nwnee-dedicated.
>
> But both versions must be the same. If nwnxee is installed as version
> 8193.37.15+deb12u2~git18cffdba, then nwne
Debian chose systemd, Devuan chose InitV. so you as user can choose
whatever you want,
I wouldn't say Devuan chose SysV but Devuan does let me choose runit during
the netiso install and thankfully Debian has the init freedom project. I
wouldn't call mentioning observations a rant.
On 07/09/2025 15:20, Marc Haber wrote:
On Sun, Sep 07, 2025 at 12:37:10PM -, Kevin Chadwick wrote:
Is systemd-networkd the default on Debian?
Sadly, no. It is the best network management tool for configuration
managed servers I have seen in 25
People said that about systemd which
from
any of the above issues). A debian package that actually built from
source would be a massive boon (assuming that OWS will actually let it
connect - do they?).
So yes please, don't abandon the ITP.
This issue of software that requires a very high update frequency is
probably only goin
On Sun, Sep 07, 2025 at 12:37:10PM -, Kevin Chadwick wrote:
Is systemd-networkd the default on Debian?
Sadly, no. It is the best network management tool for configuration
managed servers I have seen in 25 years of Linux experiences. It is
totally useable since bookworm and has the best
Haddad, Serge wrote...
> Could you please clarify whether armel will be supported during future
> upgrades from Trixie to Forky (and even Duke)?
Short answer: There will not be such a support.
So, as of today, Debian 14 ("trixie") will be the last release to
support armel, with
> | systemd [64]| New upstream stable release |
I am very disappointed that Debian has made a stable point release with
a critical system package being this broken. Even being KNOWN broken.
This is not the Debian I have been used to.
Some network configurations res
on Debian? If so, why? I switched a Ubuntu
server to Devuan because of another issue of systemd-networkd repeatedly
bringing the interface up and down. Switching to network manager fixed it
but I decided on Devuan anyway. Why is buggy poorly designed code being
installed because it has systemd in i
On Fri Sep 5, 2025 at 3:50 PM CEST, Christoph Biedl wrote:
[...]
So, as of today, Debian 14 ("trixie") will be the last release to
support armel
[...]
Just for clarity: Debian "trixie" is number 13, not 14.
port for Trixie runs out (presumably around 2028), your best
hope would presumably be to see if some group of enthusiasts decided to
try and preserve a Debian-derived distribution specifically for armel,
and if there's no such thing I'd see if maybe OpenWRT still supports it.
Stefan
On Fri, 2025-09-05 at 15:50 +0200, Christoph Biedl wrote:
> Haddad, Serge wrote...
>
> > Could you please clarify whether armel will be supported during future
> > upgrades from Trixie to Forky (and even Duke)?
>
> Short answer: There will not be such a support.
>
&
reason to not upload to unstable. Its a downstreams
problem to block it somehow if they dont want it in their
release/longterm support, but its not on Debian. Put it in unstable and
block it from testing, thats all fine. (One could think of, maybe, a
flag in the package control files somehow
Andrea Pappacoda wrote...
> On Fri Sep 5, 2025 at 3:50 PM CEST, Christoph Biedl wrote:
> > [...]
> > So, as of today, Debian 14 ("trixie") will be the last release to
> > support armel
> > [...]
>
> Just for clarity: Debian "trixie" is
On Fri, Sep 05, 2025 at 12:14:47PM +, Haddad, Serge wrote:
Our systems in the field run on an armv5 chip (armel architecture) which we
can't replace with newer boards with a different architecture.
Could you please clarify whether armel will be supported during future upgrades
from Trixie
Dear Debian Team,
I hope you're doing well.
We came across this
note<https://www.debian.org/releases/trixie/release-notes/issues.html#last-release-for-armel:~:text=trixie%20will%20be%20the%20last%20release%20for%20the%20armel%20architecture.%20Debian%20recommends%2C%20where%20pos
On Thu, 04 Sep 2025 at 08:45:58 -0700, Russ Allbery wrote:
Do we have a documented way of marking an RC bug as being a persistent
blocking bug to prevent a package from entering testing, as opposed to
some other transient problem that is expected to be fixed, so that Ubuntu
could trigger off of t
>
> I would encourage you to
> start packaging signal-desktop and than we can find answers along the way.
> A lot of discussion will get easier if signal-desktop is packaged, as than
> everyone can look at the package; sneak into the code etc.
>
On one side you're completely right, on the other ha
hings into universe that have RC bugs, or
at least that class of RC bugs. It feels weird to make Debian upload
decisions based on an Ubuntu practice with obvious flaws, and it's easier
to find and use packages in unstable. Maybe we can instead help Ubuntu do
something more sensible.
Do we
file
https://salsa.debian.org/science-team/minlog/-/blob/master/debian/watch?ref_type=heads
which results in
$ LC_ALL=C uscan --verbose --report
...
uscan info: Last orig.tar.* tarball version (dversionmangled): 4.0.99.20100221
Cloning into bare repository '../minlog-temporary.533865.git'..
Since I have not checked recently, I did not know about that project.
Thank you for the tip.
Regards
signature.asc
Description: This is a digitally signed message part
On Thu, 04 Sep 2025 at 11:19:49 +0200, Hefee wrote:
If upstream is that aggressive
with old version, than yes the normal Debian stable is not working for signal-
desktop.
But it can be used in unstable/testing and -backports. If forky release is
taking place you can use a release-critical bug
Hey,
I would love to see signal-desktop in Debian. If upstream is that aggressive
with old version, than yes the normal Debian stable is not working for signal-
desktop.
But it can be used in unstable/testing and -backports. If forky release is
taking place you can use a release-critical bug
Hi,
On Tue, Sep 02, 2025 at 11:49:59AM +, Stephan Verbücheln wrote:
> To my knowledge, no one has ever successfully packaged signal-desktop.
> Even the Flatpak build script just downloads the binaries from
> signal.org and unpacks the DEB file.
>
> https://github.com/flathub/org.signal.Signal
Hi,
> Il giorno 1 set 2025, alle ore 22:59, Peter B ha
> scritto:
>
> Had a quick look at some of these.
> Is a blank line needed after the first line with "Version: 5" in it?
>
Yes, the version has to live in its own paragraph. See the manpage
debian-watc
Le mar. 2 sept. 2025 à 23:07, Josh Triplett a
écrit :
> Jonathan Dowland wrote:
> > On Tue Sep 2, 2025 at 3:23 AM BST, Sergio Durigan Junior wrote:
> > > This package will be maintained by the Debian Javascript team. It's a
> > > requirement for signal-desktop
On Tue Sep 2, 2025 at 3:23 AM BST, Sergio Durigan Junior wrote:
This package will be maintained by the Debian Javascript team. It's a
requirement for signal-desktop.
I use and value Signal, but what's the point of packaging signal-desktop
in Debian? Surely the packaged c
On 01/09/2025 21:09, Lucas Nussbaum wrote:
..snip..
And according to UDD there are a few other that are failing:
..snip
Had a quick look at some of these.
Is a blank line needed after the first line with "Version: 5" in it?
Cheers,
Peter
On 02/09/2025 13:32, Jonathan Dowland wrote:
On Tue Sep 2, 2025 at 3:23 AM BST, Sergio Durigan Junior wrote:
This package will be maintained by the Debian Javascript team. It's a
requirement for signal-desktop.
I use and value Signal, but what's the point of packaging signal-d
On Tue Sep 2, 2025 at 9:14 AM CEST, Marc Haber wrote:
It would be nice if uscan would recognize both version= and Version:.
It currently gets confused and falls back to more ancient versions,
giving misleading error messages, when one accidentally starts a v5
file with "version=5", which is an
Jonathan Dowland wrote:
> On Tue Sep 2, 2025 at 3:23 AM BST, Sergio Durigan Junior wrote:
> > This package will be maintained by the Debian Javascript team. It's a
> > requirement for signal-desktop.
>
> I use and value Signal, but what's the point of packaging
>
t; On Tue, Sep 2, 2025, 7:33 AM Jonathan Dowland wrote:
>
>> On Tue Sep 2, 2025 at 3:23 AM BST, Sergio Durigan Junior wrote:
>> > This package will be maintained by the Debian Javascript team. It's a
>> > requirement for signal-desktop.
>>
>> I use and va
maintained by the Debian Javascript team. It's a
> > requirement for signal-desktop.
>
> I use and value Signal, but what's the point of packaging signal-desktop
> in Debian? Surely the packaged client will perennially be too
> out-of-date to connect to the servers
To my knowledge, no one has ever successfully packaged signal-desktop.
Even the Flatpak build script just downloads the binaries from
signal.org and unpacks the DEB file.
https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.yaml#L73
Same for the ebuild in Gentoo Linux.
http
> > This package will be maintained by the Debian Javascript team. It's a
> > requirement for signal-desktop.
>
> I use and value Signal, but what's the point of packaging signal-desktop
> in Debian? Surely the packaged client will perennially be too
> out-of-date t
h. See the manpage
debian-watch, “Format of the Watch file, version 5”.
It would be nice if uscan would recognize both version= and Version:. It
currently gets confused and falls back to more ancient versions, giving
misleading error messages, when one accidentally starts a v5 file with
"ve
Andrea Pappacoda:
Hi,
Il giorno 1 set 2025, alle ore 22:59, Peter B ha
scritto:
Had a quick look at some of these.
Is a blank line needed after the first line with "Version: 5" in it?
Yes, the version has to live in its own paragraph. See the manpage
debian-watch, “Format of
On 01/09/25 at 10:24 -0400, Jeremy BÍcha wrote:
> On Mon, Aug 18, 2025 at 4:25 PM Lucas Nussbaum wrote:
> > I updated the vendorized copy of devscripts in UDD to version 2.25.18,
> > and then forced a refresh of version:5 packages.
> > Everything works fine.
> >
> > udd=> select source, version, e
On Mon, Aug 18, 2025 at 4:25 PM Lucas Nussbaum wrote:
> I updated the vendorized copy of devscripts in UDD to version 2.25.18,
> and then forced a refresh of version:5 packages.
> Everything works fine.
>
> udd=> select source, version, errors, warnings, status from upstream where
> watch_file ~*
Hi,
A new optional job is now available in Salsa CI: licenserecon.
It checks for mismatches between debian/copyright and the licenses
actually detected in the source.
This hopefully benefits both new packages to decrease chances of getting
rejected in the NEW queue, and existing packages to keep
Russ Allbery writes ("Gerrit and different merge UIs (was: debian/watch version
5)"):
> One feature I do still miss from Gerrit that I don't think GitHub has is
> the ability to merge a single commit from a merge request composed of
> multiple commits. With GitHub, so
On 22/08/25 at 13:15 -0700, Otto Kekäläinen wrote:
> Maybe we can have more of this, but note that we already have at least
> 7 avenues for the information about an open MR can reach the
> maintainer: https://wiki2025.debian.org/wiki/Salsa. I think this
> ultimately boils down to people who dislike
hosting. For e2fsprogs it is
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
The Vcs-Git field is relevant in the context of discussing reviewing
MRs, as contributors would submit MRs on Salsa only if the package
Vcs-Git field advertises Salsa.
> It's rather deliberlately not under the d
lly, I do have a repo on Salsa:
https://salsa.debian.org/tytso/e2fsprogs
It's rather deliberlately not under the debian hierarchy because I do
*not* believe in letting random people submit changes to the repo, and
unlike those who were apparently taken by surprise, I had taken a very
car
Hi!
On Sun, 17 Aug 2025 at 05:57, Theodore Ts'o wrote:
> On Sun, Aug 17, 2025 at 12:54:14AM -0700, Otto Kekäläinen wrote:
> > I am in fact mentoring two out of the nine GSoC students we have, plus
> > a dozen other new contributors as part of regular mentoring under the
Hi Andreas,
On 21/08/25 at 14:37 +0200, Andreas Tille wrote:
> My (possibly wrong, but to be
> discussed) interpretation is that for a package in the Debian/ group I
> should be able to do
>
>dch --team
I think that's our core disagreement: I see the Salsa 'debian
On Wednesday, August 20, 2025 10:00:08 PM Mountain Standard Time Marc Haber
wrote:
> On Thu, 21 Aug 2025 01:01:28 +0200, Jonas Smedegaard
>
> wrote:
> >LowThreshold NMUs recommend coordination ahead of non-maintainer uploads
> >and are limited to non-important changes.
> >
> >What I object to is
On Thu, 21 Aug 2025 16:08:50 +0200, Andreas Tille
wrote:
>Am Thu, Aug 21, 2025 at 03:21:04PM +0200 schrieb Marc Haber:
>> > If the data
>> > shows activity in the last release cycle, I would contact them before
>> > uploading. If not, I would consider the package de facto orphaned and
>> > proceed
On 21/08/25 15:25, Holger Levsen wrote:
and I'm in favor of sometimes giving random newbees git commit access, this
has worked very well in the past for Debian Edu and also Reproducible Builds.
Obviously this doesnt work for all repos or all groups, but it*is* totally
fine for some.
H
Hi Marc
Am Thu, Aug 21, 2025 at 03:21:04PM +0200 schrieb Marc Haber:
> > If the data
> > shows activity in the last release cycle, I would contact them before
> > uploading. If not, I would consider the package de facto orphaned and
> > proceed.
>
> Dont we have the salvaging process for that? I
people to review them. Non-DDs
> (e.g. DMs, or regular contributors) can be given access on a case-by-case
> basis.
and I'm in favor of sometimes giving random newbees git commit access, this
has worked very well in the past for Debian Edu and also Reproducible Builds.
Obviously this doe
On Thu, Aug 21, 2025 at 02:37:22PM +0200, Andreas Tille wrote:
If the data
shows activity in the last release cycle, I would contact them before
uploading. If not, I would consider the package de facto orphaned and
proceed.
Dont we have the salvaging process for that? I just went through that,
upload rights to fewer people.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
We’ve known SARS-CoV-2 reactivates latent viruses and damages immune systems
since 2020. We still infected
don't understand how far.
What I would like to differentiate more clearly is the distinction
between an NMU and a team upload. My (possibly wrong, but to be
discussed) interpretation is that for a package in the Debian/ group I
should be able to do
dch --team
and then upload as part of a
On 21/08/25 12:13, Lucas Nussbaum wrote:
This requires forking the project to their own namespace before they can
submit a MR, which is a bit inconvenient.
The possibility I am suggesting is to grant "Developer" access to fairly
trusted non-DDs (and "Maintainer" access to DDs) at the group level
Quoting Paul Gevers (2025-08-21 10:59:30)
> On 21-08-2025 10:51, Marc Haber wrote:
> > I really think that upload should be done by those persons in
> > Uploaders
>
> Can we have an agreed content for the "debian team" in
> Maintainer/Uploader? What I'm
On 8/21/25 11:26 AM, Lucas Nussbaum wrote:
On 21/08/25 at 10:59 +0200, Paul Gevers wrote:
Hi,
On 21-08-2025 10:51, Marc Haber wrote:
I really think that upload should be done by those persons in
Uploaders
Can we have an agreed content for the "debian team" in Maintainer/Uploader
On 21/08/25 at 11:45 +0200, NoisyCoil wrote:
> On 21/08/25 11:26, Lucas Nussbaum wrote:
> > but if they can't get commit access before they are
> > DDs, it makes it inconvienent for them to contribute. A dedicated team
> > would allow to give access to non-DDs with limited privileges (for
> > examp
On 21/08/25 11:26, Lucas Nussbaum wrote:
but if they can't get commit access before they are
DDs, it makes it inconvienent for them to contribute. A dedicated team
would allow to give access to non-DDs with limited privileges (for
example using protected branches).
I oppose this. Unless I misun
On 21/08/25 10:59, Paul Gevers wrote:
On 21-08-2025 10:51, Marc Haber wrote:
I really think that upload should be done by those persons in
Uploaders
Can we have an agreed content for the "debian team" in
Maintainer/Uploader? What I'm currently missing is the ability to say
On 21/08/25 10:59, Paul Gevers wrote:
Can we have an agreed content for the "debian team" in Maintainer/
Uploader? What I'm currently missing is the ability to say: this package
isn't QA maintained, but everybody is free to upload.
Maintainer: Debian
Uploader: me and som
On 21/08/25 at 10:59 +0200, Paul Gevers wrote:
> Hi,
>
> On 21-08-2025 10:51, Marc Haber wrote:
> > I really think that upload should be done by those persons in
> > Uploaders
>
>
> Can we have an agreed content for the "debian team" in Maintainer/Uploa
Paul Gevers writes:
> Hi,
>
> On 21-08-2025 10:51, Marc Haber wrote:
>> I really think that upload should be done by those persons in
>> Uploaders
>
>
> Can we have an agreed content for the "debian team" in
> Maintainer/Uploader? What I'm current
On Thu, 21 Aug 2025 07:46:31 +0200, tho...@goirand.fr wrote:
>On Aug 20, 2025 11:55, Lucas Nussbaum wrote:
>
>> What I oppose is the retrofitting of a new, not well defined policy on
>
>> the Debian group, to turn it into a "Debian Collaborative Maintenance
>
&g
Hi,
On 21-08-2025 10:51, Marc Haber wrote:
I really think that upload should be done by those persons in
Uploaders
Can we have an agreed content for the "debian team" in
Maintainer/Uploader? What I'm currently missing is the ability to say:
this package isn't QA maint
tho...@goirand.fr:
On Aug 20, 2025 11:55, Lucas Nussbaum wrote:
What I oppose is the retrofitting of a new, not well defined policy on
the Debian group, to turn it into a "Debian Collaborative Maintenance
Team".
Lucas
Well, the "debian" namespace comes f
On Aug 20, 2025 11:55, Lucas Nussbaum wrote:
> What I oppose is the retrofitting of a new, not well defined policy on
> the Debian group, to turn it into a "Debian Collaborative Maintenance
> Team".
>
> Lucas
Well, the "debian" namespace comes from
On Thu, 21 Aug 2025 01:01:28 +0200, Jonas Smedegaard
wrote:
>LowThreshold NMUs recommend coordination ahead of non-maintainer uploads
>and are limited to non-important changes.
>
>What I object to is uncoordinated uploads.
>
>Hope that makes sense.
It absolutely does. I feel the same.
Greetings
On Wed, 20 Aug 2025 23:06:02 +0200, Carsten Leonhardt
wrote:
>Lucas Nussbaum writes:
>
>> Maybe, instead than retrofitting a policy on the debian salsa group, a
>> good way to both clarify the situation and allow an opt-in mechanism
>> would be to create another gr
On Wed, Aug 20, 2025 at 10:05 AM Jonas Smedegaard wrote:
> I was not describing sloppy drive-by, just drive-by. Me not releasing
> the newest and most shiny upstream has to offer might be due to some
> knowledge that I have as maintainer and that even a careful and 100%
> well-intended driver-by c
Quoting Jeremy Bicha (2025-08-21 00:14:12)
> On Wed, Aug 20, 2025 at 10:05 AM Jonas Smedegaard wrote:
> > I was not describing sloppy drive-by, just drive-by. Me not releasing
> > the newest and most shiny upstream has to offer might be due to some
> > knowledge that I have as maintainer and that
Lucas Nussbaum writes:
> Maybe, instead than retrofitting a policy on the debian salsa group, a
> good way to both clarify the situation and allow an opt-in mechanism
> would be to create another group on salsa, with rules clearly defined
> from the start, and let maintainers d
On 2025-08-19 Andreas Tille wrote:
> Am Sun, Aug 17, 2025 at 11:37:42PM +0200 schrieb Lucas Nussbaum:
>>> One point raised during the BoF was the need to better document the role
>>> of the Debian/ group on Salsa. Not all developers are aware that being
>>> part
e.
>
> My concern is that "rarely" or perhaps even "sometimes" progress sped
> up by skipping human interaction is a net negative.
>
> I question if running fast and breaking things is what we want to aim
> at in Debian.
I think a better way to mitigate the neg
multiple packages, or I am aware of some details with newer upstream
> >> > that makes me decide to hold back on pulling that into Debian just yet.
> >> > Often I do so without formally tracking such details as bugreports - and
> >> > even if I did (or if othe
s time with my previous posts in this thread. If above
is what you've meant all along then I think I might have indeed, but...
Quoting Andreas Tille (2025-08-01 08:51:06)
> One point raised during the BoF was the need to better document the role
> of the Debian/ group on Salsa. Not a
ncerns.
>
> (reading it as the plural "you"...)
>
> I share Lucas' concern of you redefining the rules of the "debian"
> namespace at Salsa.
I understand that with “you redefining” you (=Jonas) are addressing me
personally. At the same time, I see this discu
Jonas Smedegaard writes:
> Quoting Simon Josefsson (2025-08-20 13:02:28)
>> > Sometimes I am in the middle of some larger transition that involves
>> > multiple packages, or I am aware of some details with newer upstream
>> > that makes me decide to hold back on pul
Quoting Simon Josefsson (2025-08-20 13:02:28)
> > Sometimes I am in the middle of some larger transition that involves
> > multiple packages, or I am aware of some details with newer upstream
> > that makes me decide to hold back on pulling that into Debian just yet.
> &g
other upstream
releases that will use a more modern Debian gnulib git commit from the
bundle, but none of this are excuses to prevent you to do an upload.
> Sometimes I am in the middle of some larger transition that involves
> multiple packages, or I am aware of some details with newer upst
d "Uploaders" still have a meaning.
> >
> > By using the "debian" namespace, I did not mean to invite anyone in
> > Debian to do *uncoordinated* uploads (it has happened once, about a week
> > ago, and that took me by surprise).
>
> Me too! I h
On 20/08/25 at 10:35 +0200, Andreas Tille wrote:
> Hi Jörg,
>
> Am Tue, Aug 19, 2025 at 11:15:36PM +0200 schrieb Joerg Jaspert:
> > On 17691 March 1977, Lucas Nussbaum wrote:
> >
> > > Maybe, instead than retrofitting a policy on the debian salsa group, a
>
On Wed, Aug 20, 2025 at 11:03:38AM +0200, Jonas Smedegaard wrote:
For me, the concern is not tied to specific packages. I have used this
namespace for 100s of packages to encourage collaboration but with the
assumption that "Maintainer" and "Uploaders" still have a meaning.
Jonas Smedegaard writes:
> For me, the concern is not tied to specific packages. I have used this
> namespace for 100s of packages to encourage collaboration but with the
> assumption that "Maintainer" and "Uploaders" still have a meaning.
>
> By using the &q
you redefining the rules of the "debian"
namespace at Salsa.
For me, the concern is not tied to specific packages. I have used this
namespace for 100s of packages to encourage collaboration but with the
assumption that "Maintainer" and "Uploaders" still have a meanin
On 2025-08-20 10:35, Andreas Tille wrote:
@Lucas, one practical drawback is that moving a repository out of
Debian/ requires opening an issue for the Salsa admins, since only they
can remove repositories there. I would prefer to minimize the number of
such tickets.
Surely there could be a
Hi Jörg,
Am Tue, Aug 19, 2025 at 11:15:36PM +0200 schrieb Joerg Jaspert:
> On 17691 March 1977, Lucas Nussbaum wrote:
>
> > Maybe, instead than retrofitting a policy on the debian salsa group, a
> > good way to both clarify the situation and allow an opt-in mechanism
>
Am Wed, Aug 20, 2025 at 08:35:32AM +0200 schrieb Xavier:
> BTW, I found a way to build a template for Gitlab
I love to repeat: You rock!
Thanks a lot
Andreas.
--
https://fam-tille.de
efault configuration
>>>> from d/upstream/metadata which would probably allow many packages to not
>>>> need a d/watch anymore.
>>>
>>> Good idea, we can have the following behavior:
>>> - if no debian/watch, look at debian/upstream/metadata
>>>
rt. If I pay 1000€ for an ice cream or for a car, the cost in both
cases is the same but only the ice cream was 'expensive', meaning the
cost was high compared to value. I think that in the vast majority of
MRs in Debian, the benefits far outweigh the cost, and in particular
for package &#
On 17691 March 1977, Lucas Nussbaum wrote:
Maybe, instead than retrofitting a policy on the debian salsa group, a
good way to both clarify the situation and allow an opt-in mechanism
would be to create another group on salsa, with rules clearly defined
from the start, and let maintainers decide
1 - 100 of 1813 matches
Mail list logo
