Hi.
This turned out to be a non-issue. vzlogger creates a system user. So
this only affects the projects backport to buster.
Thanks for the answers, they helped me understanding this.
Joachim
Hi Joachim,
Le 2024-10-05 17:21, Joachim Zobel a écrit :
> Hi.
>
> Debian policy 9.2.1 says: "When maintainers choose a new hardcoded or
> dynamically generated username for packages to use, they should start
> this username with an underscore." By now this requires an
On Sat, Oct 05, 2024 at 05:21:10PM +0200, Joachim Zobel wrote:
> Debian policy 9.2.1 says: "When maintainers choose a new hardcoded or
> dynamically generated username for packages to use, they should start
> this username with an underscore." By now this requires an
>
On 2024-10-05 Joachim Zobel wrote:
> Debian policy 9.2.1 says: "When maintainers choose a new hardcoded or
> dynamically generated username for packages to use, they should start
> this username with an underscore." By now this requires an
> adduser --allow-bad-names
&g
Hi.
Debian policy 9.2.1 says: "When maintainers choose a new hardcoded or
dynamically generated username for packages to use, they should start
this username with an underscore." By now this requires an
adduser --allow-bad-names
in the script creating the user. Since I followed t
ll DDs,
It has been suggested that I need to supply a list of the current "confirmed"
packages requiring a sponsor that need a DD to review and possibly upload to
Debian when ready. Below is that list.
#1072910 RFS: lsp-treemacs/0.5-1 -- treemacs integration for Emacs LSP
RFS: https://bugs
Dear all DDs,
Below is the link to the page of currently "confirmed" as being in good order
packages that are awaiting a DD review and possible upload to Debian. If DDs
could spare the time to pick up a package or two and finish off the package
mentor process it would be greatly a
[Dropping CC to the upstream mailing list.]
On Fri, Sep 27, 2024 at 04:56:21PM +0700, Arnaud Rebillout wrote:
> On 30/08/2024 17:11, Colin Watson wrote:
> > This is now implemented in Debian unstable. I called the packages
> > openssh-client-gssapi and openssh-server-gssapi, wit
On 30/08/2024 17:11, Colin Watson wrote:
This is now implemented in Debian unstable. I called the packages
openssh-client-gssapi and openssh-server-gssapi, with the intention of
splitting out both GSS-API authentication and key exchange support
later: that is, in trixie+1 I intend to build
On Sun Sep 1, 2024 at 6:14 PM BST, Otto Kekäläinen wrote:
> The discussion was summarized in a separate "Summay" email by me on this
> list, and a comment in the MR (which merges the two discussions) and it
> just happened that the next day it was also covered in
> https://lwn.net/Articles/986480/
Hi Ricardo,
Am Tue, Sep 03, 2024 at 10:37:27PM +0200 schrieb Ricardo Ribalda Delgado:
> ...
> As a newer DD, I don't feel comfortable speaking on behalf of the
> project just yet. I'm hoping someone from debian-dev or
> debian-multimedia might be interested in participating,
ly
> > works and is quite common, sometimes necessary.
>
> It would be great if we could run the salsa-ci pipeline localy easily, in
> chroot via sbuild or whatever.
> Do not get me wrong I like the fact that we have these pipelines in salsa, it
> is a great plus for D
etimes necessary.
>
> It would be great if we could run the salsa-ci pipeline localy easily, in
> chroot via sbuild or whatever.
> Do not get me wrong I like the fact that we have these pipelines in salsa, it
> is a great plus for Debian.
>
> I Just see that the salsa-ci pipeli
e localy easily, in
chroot via sbuild or whatever.
Do not get me wrong I like the fact that we have these pipelines in salsa, it
is a great plus for Debian.
I Just see that the salsa-ci pipelines does not gives somethimes exacly the
same result than my current sbuild + autopkgtest run locally.
So I n
tem it is another story.
>> >> So we rely on the central salsa instance.
(...)
>> >> I do not know if I am clear but I have the fear that this
>> >> centralisation will make us forget that de-centralisation is sort of
>> >> "central" t
On Tuesday, 3 September 2024 23.42.33 CDT Jonas Smedegaard wrote:
> I don't say that Debian must work for jungle developers, nor that we
> must all use email and not different forms of collaboration requiring
> better connectivity. My point is that Debian *allows* collaboration
of
> > that. eg, it could be written to be only about what goes into the
> > archive and not say anything about using schroot locally, or whether
> > salsa is gitlab or something else. but maybe i misunderstand
>
> >> I do not know if I am clear but I have the fear th
schroot locally, or whether
> salsa is gitlab or something else. but maybe i misunderstand
>> I do not know if I am clear but I have the fear that this
>> centralisation will make us forget that de-centralisation is sort of
>> "central" to the Debian way.
>
>
Hi everyone,
[A continuation of my previous email, hoping that a new subject get
more attention :)
https://lists.debian.org/debian-devel/2024/06/msg00191.html]
In two weeks, I'll be hosting a micro-conference about Complex Cameras
in Linux at LPC in Vienna:
https://lpc.events/eve
On 03/09/2024 15:36, Otto Kekäläinen wrote:
My information was based on what Salsa admin posted at
https://salsa.debian.org/salsa/support/-/issues/395
Hi Otto,
Thanks for that link,
which took me nearly a minute to open!
Quoting from there.
Could we keep the issue open for now and only clo
Hi!
> Hi Otto,
> Until recently I generally found Salsa response to be adequate,
> but for the last couple of days it has been so
> excruciatingly slow as to be almost unusable.
>
> > In response, Otto Kekäläinen noted that the Salsa admins
> > had posted about upcoming hardware upgrades and other
On 28/08/2024 03:13, Otto Kekäläinen wrote:
## Performance and Reliability
Multiple participants, including Salvo Tomaselli, Johannes Schauer
Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained
about Salsa/GitLab being slow or unreliable at times, which deterred
contribution. Imp
Hi Debian Developers,
Our package marked as "confirmed" that has languished on mentors for quite
some time is our package of the day.
Please could a DD with a little free time, graciously give it your time and
show this package some love?
Package: graphite-carbon
Links...
* Mento
know if I am clear but I have the fear that this
> centralisation will make us forget that de-centralisation is sort of
> "central" to the Debian way.
I suspect that if the DEP was clearer in scope and aims, these concerns
would not actually arise
What about dog fooding ?
for now we can setup a schroot and sbuild very easily and start to build a
local repository in minutes.
But when it comes to install gitlab and the CI system it is another story. So
we rely on the central salsa instance.
It seems to me that a great strength of Debian
a follow-up DEP?
If you want editing advice debian-l10n-engl...@lists.debian.org is a great
resource
I would suggest:
- make the "intro" less general. Set out a clear, short, list of
objectives/goals/what you want to improve. This will also help with
setting a clearer scope
- m
Hi Jonathan!
The discussion was summarized in a separate "Summay" email by me on this
list, and a comment in the MR (which merges the two discussions) and it
just happened that the next day it was also covered in
https://lwn.net/Articles/986480/
I am currently writing revision 2 of the proposal.
Thanks for working on this. I finally had a read over it today.
I've found the split in discussion between this list and the Merge Request
comments
hard to manage. It would help a lot, I think, if some of the MR threads were
marked
resolved, assuming the issues they describe are resolved. Tha
Excellent - this substantially reduces the amount of pre-authentication
attack surface exposed on your users' sshd by default.
On Fri, 30 Aug 2024, Colin Watson wrote:
> On Tue, Apr 02, 2024 at 01:30:11AM +0100, Colin Watson wrote:
> > * for Debian trixie (current testing):
>
Hi!
> NOTE: The following idea might be out-of-scope in DEP-18, but specific
> use-case to improve
> collaboration in Debian, IMHO.
>
> Here is just an idea: put collaboration policy metadata in debian/control.
> (The following idea assumes that non-maintainer DD tend to he
On Tue, Apr 02, 2024 at 01:30:11AM +0100, Colin Watson wrote:
> * for Debian trixie (current testing):
>
>* add dependency-only packages called something like
> openssh-client-gsskex and openssh-server-gsskex, depending on their
> non-gsskex alternatives
>
Hi,
On Mon, May 27, 2024 at 8:07 PM Leandro Cunha wrote:
>
> Hi,
>
> On Fri, May 24, 2024 at 10:28 PM Otto Kekäläinen wrote:
> >
> > Hi!
> >
> > So just to clarify, are you saying that a copy of
> > https://security.debian.org/debian-security/dists/b
On 8/23/24 00:24, lina wrote:
Hi,
During the Debian (stable) installation on Macbook pro from 2019,
my internal keyboard is not recognizable even I exhausted all possible
keyboard options listed during
dpkg-reconfiguration keyboard-configuration
# more /etc/default/keyboard
# KEYBOARD
trying to improve
contribution and collaboration in Debian.
## Maintainer Workflows
There were concerns that requiring specific Git and Gitlab practices
could create burdens for existing maintainers, especially
single-person maintainers. Sean Whitton described his own preferences
as a maintainer
list discussion in
https://lists.debian.org/debian-devel/2024/07/msg00429.html
## Overall Sentiment
There was a broad consensus that Debian workflows are too fractured
and would benefit from more standardization and unification. However,
there were differing opinions on the right approach to achieve
Dear all DDs,
Below is the link to the page of currently "confirmed" being in good order
packages that are awaiting a DD review and possible upload. If DDs could
spare the time to pick up a package or two and finish off the package mentor
process it would be greatly appreciated.
https://bugs.debi
Hello Ansgar,
Am Sat, Mar 23, 2024 at 09:30:49AM +0100 schrieb Ansgar 🙀:
> Debian 10 "buster" has moved to archive.debian.org in order to free
> space on the main mirror network. We plan to start removing files for
> non-LTS architectures in about two weeks; the existing R
Hi,
Quoting Otto Kekäläinen (2024-08-27 08:42:53)
> > Before pushing for new ways of representing Debian stuff in git, I think it
> > would be a good idea to learn from all the other distros and distro-like
> > systems successfully using git [1]. Debian is not the only distro
Hi!
Considering what other Linux distros are doing and what is popular
among software developers today, Debian will probably gain more
contributors and be more approachable if we don't reinvent too many
custom things, and hence...
..
> In the current DEP14/DEP18 discussions a lot of di
On Fri, 2024-08-23 at 09:24 +0200, lina wrote:
> Hi,
>
> During the Debian (stable) installation on Macbook pro from 2019,
Installation problems should generally be reported to the debian-boot
list.
> my internal keyboard is not recognizable even I exhausted all possible
> k
give for (3.) is such a small
> proportion: I find this workflow really useful as a way to reconcile
> devref 6.8.8.1's assertion that pristine upstream tarballs are important
> with the desire to have upstream git history readily available to make
> maintenance easier.
In the Debi
On Sat, Aug 24, 2024 at 2:06 AM Ahmed Siam wrote:
> On Sat, Aug 24, 2024 at 2:00 AM Ahmed Siam wrote:
> > On Sat, Aug 24, 2024 at 1:45 AM Ahmed Siam wrote:
> > > Perl pipeline run:
> > > - https://salsa.debian.org/ahmedsiam/perl/-/pipelines/719321
> This pipeline run from Nodejs shows a similar
On Sat, Aug 24, 2024 at 2:00 AM Ahmed Siam wrote:
>
> On Sat, Aug 24, 2024 at 1:45 AM Ahmed Siam wrote:
> >
> > On Sat, Aug 24, 2024 at 1:25 AM Jérémy Lal wrote:
> > > A bunch of packages I know (nodejs, receptor to name a few) have salsa CI
> > > failures, but no sbuild failures.
> > > It woul
On Sat, Aug 24, 2024 at 1:45 AM Ahmed Siam wrote:
>
> On Sat, Aug 24, 2024 at 1:25 AM Jérémy Lal wrote:
> > A bunch of packages I know (nodejs, receptor to name a few) have salsa CI
> > failures, but no sbuild failures.
> > It would be perfect if the build process was exactly the same.
>
> There
On Sat, Aug 24, 2024 at 1:25 AM Jérémy Lal wrote:
> A bunch of packages I know (nodejs, receptor to name a few) have salsa CI
> failures, but no sbuild failures.
> It would be perfect if the build process was exactly the same.
There is a work-in-progress MRs about using sbuild for building packa
observation that it would be
> helpful if there was better documentation to make life easier for
> package maintainers.
Yes, it is the authoritative page.
I will update the page based on discussions on debian-devel. Draft
pending at https://salsa.debian.org/salsa-ci-team/pipeline/-
On Friday, 23 August 2024 02:24:44 CDT lina wrote:
> Hi,
>
> During the Debian (stable) installation on Macbook pro from 2019,
>
> my internal keyboard is not recognizable even I exhausted all possible
> keyboard options listed during
Hi,
I think this question would fit bett
Thanks, originally I posted on debian user, the only one who replied is
rather arrogant, I do not see the point to continue that thread,
I probably to start a new thread next time on debian-user, thanks again,
lina
On Fri, Aug 23, 2024 at 10:05 AM Piper McCorkle wrote:
> On Friday, 23 Aug
Hi,
During the Debian (stable) installation on Macbook pro from 2019,
my internal keyboard is not recognizable even I exhausted all possible
keyboard options listed during
dpkg-reconfiguration keyboard-configuration
# more /etc/default/keyboard
# KEYBOARD CONFIGURATION FILE
# Consult the
Hello,
I think that more than you realise of this already exists :)
On Tue 20 Aug 2024 at 04:10pm +09, Simon Richter wrote:
> From a requirements perspective, I'd like to be able to
>
> - express patches as commits:
>- allow cherry-picking upstream commits as Debian pat
scussions on the topic tend to
> reinforce that feeling.
Oh well. FWIW I think it's crazy and not a good use of my time to NOT
have the complete upstream history in the same repository that I use for
Debian packaging. :-)
> (For some value of $fun, try cloning the mesa or
> F
ire multiple changes to be applied in the same commit.
>
> The imported archive is represented either directly as a tree (which may
> be imported from the upstream project if no files are undistributable
> for Debian), or via a mechanism that can reproduce a compressed archive
> that
Hi !
Le mercredi 21 août 2024, 23:37:38 CEST Chris Hofstaedtler a écrit :
> Hi Simon,
>
> * Simon Richter [240820 09:11]:
> > One of the long-standing issues is that there are multiple ways Debian
> > packaging can be represented in a git tree, and none of them are o
On 2024-08-21 19:11:40 -0400 (-0400), rsbec...@nexbridge.com wrote:
[...]
> On the other side (perhaps), git is increasingly being used in the
> Ops setting for DevOps and DevSecOps. Production configurations
> for high-value applications are moving to storing those
> configurations into git for tr
* rsbec...@nexbridge.com [240822 01:21]:
> >> Any feelings/objections/missed requirements?
> >
> >In the current DEP14/DEP18 discussions a lot of discussion was had about how
> >we
> >should represent Debian things in git; your mail also goes into this
> &
On Wednesday, August 21, 2024 5:38 PM, Chris Hofstaedtler wrote:
>* Simon Richter [240820 09:11]:
>> One of the long-standing issues is that there are multiple ways Debian
>> packaging can be represented in a git tree, and none of them are optimal.
>[..]
>> A possible i
Chris Hofstaedtler writes:
> My *feeling* is we should do the opposite - that is, represent less
> Debian stuff in git, and especially do it in less Debian-specific
> ways. IOW, no git extensions, no setup with multiple branches that
> contain more or less unrelated things, etc.
Hi Simon,
* Simon Richter [240820 09:11]:
> One of the long-standing issues is that there are multiple ways Debian
> packaging can be represented in a git tree, and none of them are optimal.
[..]
> A possible implementation would be a type of Git "user extension" obj
Re: Simon Richter
> That is not a 32 bit bug, but an indication of something else being broken.
It is the same problem in the sense that 64-bit architectures are
fine, and something (probably in some autoconf script) is broken on
32-bit. The point here is that these are always weird bugs in weird
Hi,
On 8/21/24 18:32, Christoph Berg wrote:
10:39:04 snprintf.c:409:1: error: conflicting types for ‘strchrnul’; have
‘const char *(const char *, int)’
10:39:04 409 | strchrnul(const char *s, int c)
10:39:04 | ^
10:39:04 In file included from snprintf.c:43:
10:39:04 /usr/includ
Re: To debian-devel
> it has probably been a decade since I've last seen a PostgreSQL
> installation in the wild on a 32-bit machine. PostgreSQL itself works
> fine there, but more and more extensions are not compatible anymore,
> either deliberately, or (more common) because
n's
decision: it's upstream's decision what they will name their tags.
The only decision we can make here as Debian packagers is whether to use:
1. a workflow where upstream/latest contains the same commits as
upstream git (like src:mesa);
2. a workflow where upstream/latest co
Hi,
there's a bit of a discussion within Debian on collaborating using Git.
One of the long-standing issues is that there are multiple ways Debian
packaging can be represented in a git tree, and none of them are optimal.
The problem at hand is that the packaging workflow consists
Hi!
## How many source packages are in Debian unstable as of today?
± zgrep "^Package: " Sources.gz | wc -l
38199
## How many source packages have a gbp.conf?
± ls -1 *_gbp.conf | wc -l
13570
(24629 do not have it)
## What is the most popular 'debian-branch'?
Note! Th
For those playing along at home...
On 19/08/2024 14:53, Stuart Prescott wrote:
url=$(curl -s
https://sources.debian.org/api/src/zzuf/0.15-4/debian/gbp.conf/ | jq -r
.raw_url)
The API URL should obviously be
https://sources.debian.org/api/src/$pkg/latest/debian/gbp.conf/
and
ld get upset at 1655 files being downloaded in the following
fashion.
apt-file search --index-names dsc --package-only debian/gbp.conf |
while read pkg; do
echo -n $pkg
url=$(curl -s
https://sources.debian.org/api/src/zzuf/0.15-4/debian/gbp.conf/ | jq -r
.raw_url)
Quoting Otto Kekäläinen (2024-08-19 03:45:37)
> I tried to use codesearch.debian.net to find out how many packages have a
> debian/gbp.conf but it seems it can't be used to simply list packages that
> have a specific file, it always also needs a search terms to look up inside
> th
Hi!
I am happily using debian/gbp.conf and debian-branch=debian/latest in
all of my packages but based on the DEP14 discussion seems some people
prefer debian/sid or debian/unstable (and some of them upload to
experimental from the branch despite the name, and some maintain a
separate debian
Hi debian-devel,
it has probably been a decade since I've last seen a PostgreSQL
installation in the wild on a 32-bit machine. PostgreSQL itself works
fine there, but more and more extensions are not compatible anymore,
either deliberately, or (more common) because of subtle bugs in p
Dear all DDs,
Below is the link to the page of currently "confirmed" being in good order
packages that are awaiting a DD review and possible upload. If DDs could
spare the time to pick up a package or two and finish off the package mentor
process it would be greatly appreciated.
https://bugs.debi
On 08/08/2024 07.02, nick black wrote:
Michael R. Crusoe left as an exercise for the reader:
Please create a new group on salsa and then we can move the repo[0] from the
debian-med namespace.
done: https://salsa.debian.org/deflate-team
Thank you Nick, I've moved the libdeflate Salsa
Michael R. Crusoe left as an exercise for the reader:
> Please create a new group on salsa and then we can move the repo[0] from the
> debian-med namespace.
done: https://salsa.debian.org/deflate-team
I've sent invites to you and Andrea. Feel free to ignore them.
> Then you can
[resending to your correct address]
Hello,
On Mon 05 Aug 2024 at 06:14am +05, Andrey Rakhmatullin wrote:
> It's similar but different: I'm talking about workflows to build a package
> from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs").
> And yeah it could be a metadata field.
Hello,
On Mon 05 Aug 2024 at 06:14am +05, Andrey Rakhmatullin wrote:
> It's similar but different: I'm talking about workflows to build a package
> from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs").
> And yeah it could be a metadata field.
Just to note that once people are u
Hello,
On Sat 03 Aug 2024 at 11:29am -07, Soren Stoutner wrote:
> 1. Debian workflows are too fractured. The project would be better if we
> asked people
> to standardize around a single (or a small number) of workflows. To do so,
> the workflow
> would need to be flexible e
On 06/08/2024 20.36, Andrea Pappacoda wrote:
Il giorno mar 6 ago 2024 alle 11:32:15 -04:00:00, nick black
ha scritto:
I maintain it for Fedora, and would be happy to handle it in
Debian; it's a dependency for one of my other packages (notcurses).
Happy to enter into a team maintainersh
Hello,
On Sat 03 Aug 2024 at 09:19am +02, PICCA Frederic-Emmanuel wrote:
> Hello, I like the dgit idea, produce a git repository for people who want to
> use git and let other use whatever they want.
>
> Maybe uploading a paquage to Debian could push automatically into dgit. (may
Hello,
On Sat 03 Aug 2024 at 08:26am +02, Jonas Smedegaard wrote:
> My problem with DEP-18 is that people who have zero problem with using
> git and are also not fundamentally against using salsa, but have
> reservations surrounding *which parts* of salsa to use and the
> consequences for related
Il giorno mar 6 ago 2024 alle 11:32:15 -04:00:00, nick black
ha scritto:
I maintain it for Fedora, and would be happy to handle it in
Debian; it's a dependency for one of my other packages (notcurses).
Happy to enter into a team maintainership as well.
Hi Nick and Michael, I'd b
Michael R. Crusoe left as an exercise for the reader:
> libdeflate-dev has 3304 reverse-dependencies in "unstable"[0].
> I would like to move it from Debian-Med to a more appropriate team.
> Are there any volunteers?
I maintain it for Fedora, and would be happy to handle i
libdeflate-dev has 3304 reverse-dependencies in "unstable"[0].
I would like to move it from Debian-Med to a more appropriate team.
Are there any volunteers?
Some history: libzstd-dev (3020 reverse build-depends) was also first packaged
by Debian-Med but is now under the RPM pack
, the possible contact of the maintainer, attempts (and then
eventually feel that it would be better to "improve" your
contributions using other methods).
This information should be in debian/README.source.
Simon
debian/README.source can be used for that, this according to t
, attempts (and then eventually feel
that it would be better to "improve" your contributions using other
methods).
This information should be in debian/README.source.
Simon
parallel to the human
policy. Shenanigans like parsing special statements from formats aimed
at humans do not really cut it in my book.
[1]: https://salsa.debian.org/debian/debputy/-/merge_requests/37
here can help for you?
https://lists.debian.org/debian-devel/2024/08/msg00058.html
https://lists.debian.org/debian-devel/2024/08/msg00062.html
I think something like this could be useful, even in a possible future where
all packages would use git and salsa; but from the answers received so f
t).
> >
> something like wrote here can help for you?
>
> https://lists.debian.org/debian-devel/2024/08/msg00058.html
>
> https://lists.debian.org/debian-devel/2024/08/msg00062.html
>
> I think something like this could be useful, even in a possible future where
> all p
the default branch?
Only if DEP-18 also includes an easy way to find the workflow used by the
repo, which I'm not seeing there (which may be my fault).
something like wrote here can help for you?
https://lists.debian.org/debian-devel/2024/08/msg00058.html
https://lists.debian.org/debian-
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
> one problem I have with NMUs in team-maintained package is that they
> often bypass Salsa… Would it make sense to add to the DEP a request
> that NMUs are started from and pushed to the default branch?
Only if DEP-18 also includes
orrect solution is
> > adopted*. Unity is more important than minority opinions on this
> > particular issue.
>
> Keep in mind that unhappy people quit.
Yes, people will resign, but (other) people resign because they got tired
of Debian not having standartized workflows, and th
ame time I don't *want* to be the single
maintainer. Actually, I don't want to maintain packages at all, my joy
is elsewhere in Debian.
I'm on LowThresholdNMU and LowThresholdAdoption lists. I guess I should
have created a wnpp RFH" bug for all my packages? Not that thos
Hi!
> I have three feelings.
>
>
> 1. Debian workflows are too fractured. The project would be better if we
> asked people to standardize around a single (or a small number) of workflows.
> To do so, the workflow would need to be flexible enough to handle the wide
> ran
ed on my work helping new contributors start working on Debian, I
think the number of people the project would gain would far exceed those who
would leave.
> What exact issue are we trying to fix?
The core of the issue is that it is far too hard for a new contributor to
figure out how to co
; purpose of simplifying the conversation. I don't think that
> simplification is helpfull, however.
I am one of the silent crowd who has followed this discussion.
I have three feelings.
1. Debian workflows are too fractured. The project would be better if we
asked people to
standardize around
18 basically, I think that it might be better
> >>> to add an option
> >>> to formalize package owner's (single person maintainer) collaboration
> >>> policy
> >>> especially about non-team maintained packages under
> >>> https://s
ainer) collaboration policy
especially about non-team maintained packages under
https://salsa.debian.org/debian/.
If such a package repository enables merge request feature, then I
will send merge request and
send E-mail to bugs.d.o about url of the MR to notify it.
But it is not true that such MR is m
r) collaboration policy
> > especially about non-team maintained packages under
> > https://salsa.debian.org/debian/.
> >
> > If such a package repository enables merge request feature, then I
> > will send merge request and
> > send E-mail to bugs.d.o about ur
-team maintained packages under
https://salsa.debian.org/debian/.
If such a package repository enables merge request feature, then I
will send merge request and
send E-mail to bugs.d.o about url of the MR to notify it.
But it is not true that such MR is merged in timely manner.
(Surely collaboration
n.org/debian/.
If such a package repository enables merge request feature, then I
will send merge request and
send E-mail to bugs.d.o about url of the MR to notify it.
But it is not true that such MR is merged in timely manner.
(Surely collaboration takes longer time, I know.)
If the package
packages under
> https://salsa.debian.org/debian/.
>
> If such a package repository enables merge request feature, then I
> will send merge request and
> send E-mail to bugs.d.o about url of the MR to notify it.
> But it is not true that such MR is merged in timely manner.
> (Surely colla
intained packages under
> https://salsa.debian.org/debian/.
>
(...)
> If such a package repository enables merge request feature, then I
> will send merge request and
> send E-mail to bugs.d.o about url of the MR to notify it.
> But it is not true that such MR is merged in tim
1 - 100 of 1010 matches
Mail list logo
