Source: libasyncns
Version: 0.8-6
Severity: important
X-Debbugs-Cc: Tanguy Ortolo , Tanguy Ortolo
, debian-devel@lists.debian.org, 862...@bugs.debian.org,
862...@bugs.debian.org, Package Salvaging Team
Hi Tanguy,
Your package libasyncns was highlighted in the Bug of the Day[1]
initiative
Hi,
> Perhaps, to ease the burden of those of us maintaining many packages,
> we could instead have this more complex rule:
>
> > The default debian branch is the first available of these, in order:
> > 1. debian/latest
> > 2. debian/unstable
> > 3. debian/expe
On Wed, Jun 04, 2025 at 01:48:25PM +0300, Otto Kekäläinen wrote:
Hi!
I am not sure what is the default in Salsa for new repositories right
now, but I suggest all Debian Developers/Maintainers who use Salsa to:
- Review your global notification settings at
https://salsa.debian.org/-/profile
Hi!
I am not sure what is the default in Salsa for new repositories right
now, but I suggest all Debian Developers/Maintainers who use Salsa to:
- Review your global notification settings at
https://salsa.debian.org/-/profile/notifications
- For each Salsa project you feel responsible for, go
esql+fastapi, while keeping the flat file
> > > system only for archiving the bug log (the .log files) for at
> > > least a significant period of time, but that bug log would be
> > > write only.
> > >
> > > The code for this is about 25% there, b
g log (the .log files) for at
> > least a significant period of time, but that bug log would be
> > write only.
> >
> > The code for this is about 25% there, but I've been working on it
> > for years now in my very limited Debian development time, so I
> &g
n that
> > debbugs runs is at https://bugs.debian.org/debbugs-source/debbugs/
>
> FWIW the actual/working repository URL is
> https://bugs.debian.org/debbugs-source/debbugs.git
Sorry, I typoed. The above line should read
https://bugs.debian.org/debbugs-source/debian/, which is a chec
On Sun, Jun 01, 2025 at 09:54:09AM -0700, Don Armstrong wrote:
> On Tue, 27 May 2025, Otto Kekäläinen wrote:n
> > I would assume Debbugs might evolve without you having to personally
> > do all the improvements, if you allow improvements done by others
> > flow in. As an example, I have had
> > ht
; The code for this is about 25% there, but I've been working on it for
> years now in my very limited Debian development time, so I don't have
> a realistic timeline for completion.
Do you have some design documentation and/or a TODO list that others
could use to be able to contribute to this effort?
signature.asc
Description: PGP signature
sts/6
> open for 4 years now.
That's not an MR that I'll apply, because the actual version that
debbugs runs is at https://bugs.debian.org/debbugs-source/debbugs/
Salsa isn't the actively running code for Debian, though it is a place
that we're using as upstream.
--
Don A
ng the flat file
system only for archiving the bug log (the .log files) for at least a
significant period of time, but that bug log would be write only.
The code for this is about 25% there, but I've been working on it for
years now in my very limited Debian development time, so I don
On Thu, 29 May 2025, Colin Watson wrote:n
> On Wed, May 28, 2025 at 02:22:00PM +, Holger Levsen wrote:
> > Also, I don't really see how to keep all the e-mail features it currently
> > offers,
> > while hiding email addresses. I quite often look up email addresses in bugs
> > and contact peopl
Hi Philipp, hi all,
>>>>> On Sat, 31 May 2025 15:11:11 +0200, Philipp Kern said:
> But to me the weirdest thing is that quite a few complained and there
> was no real response rationalizing the decision.
You may have missed this email
https://lists.debian.o
Hello Philipp,
Am Sat, May 31, 2025 at 03:11:11PM +0200 schrieb Philipp Kern:
> On 5/9/25 1:45 AM, Antonio Terceiro wrote:
> > On Thu, May 08, 2025 at 10:33:55PM +0200, Holger Wansing wrote:
> >> I think about removing myself from the debian-www team.
> >> Better no long
On 5/9/25 1:45 AM, Antonio Terceiro wrote:
> On Thu, May 08, 2025 at 10:33:55PM +0200, Holger Wansing wrote:
>> I think about removing myself from the debian-www team.
>> Better no longer be part of it, otherwise people might blame me for such
>> decisions ...
>
> Pl
o view full headers, download mboxes and generate a working reply mailto:
> link. It also won't completely solve the privacy issue, as e-mail addresses
> can also be found in git repositories and mailing list archives. IMO it would
> be better to recommend using a dedicated e-mail add
ers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
If a monkey hoarded more bananas than it could eat, while most of the other
monkeys starved, scientists would study that monkey to figure ou
On 17607 March 1977, Julien Plissonneau Duquène wrote:
The delay is only a part of the issue, the other part is the lack of
feedback that would allow the user to know if her registration is
still
pending or has been rejected.
Oh, reject you get a mail. If its deleted, you don't.
I like the
On Thu, May 29, 2025 at 01:03:56PM +0200, Julien Plissonneau Duquène wrote:
Right now we have an implementation that is dated but mostly works so
I think that there is no need to rush a move. Working on it for a
while and experimenting with the real data in there will certainly
help with figuri
On Thu May 29, 2025 at 9:58 AM BST, Holger Levsen wrote:
(still, I think the answer to that should not be to hide email
addresses but something else, eg maybe asking new bts users if they
are aware that there email address will become public and block their
submissions until they agree...)
Bu
On May 29, Julien Plissonneau Duquène wrote:
Security measures should be proportional to the specific threat, and
we actually know that targeted malicious attacks to the BTS are not
happening.
We know that they didn't happen so far. I would not be so sure about
the future.
There is always a
Le 2025-05-29 10:58, Holger Levsen a écrit :
(still, I think the answer to that should not be to hide email
addresses
but something else, eg maybe asking new bts users if they are aware
that there
email address will become public and block their submissions until they
agree...)
My personal
Le 2025-05-28 18:41, Marco d'Itri a écrit :
Security measures should be proportional to the specific threat, and
we actually know that targeted malicious attacks to the BTS are not
happening.
We know that they didn't happen so far. I would not be so sure about the
future.
Anyway there are
Le 2025-05-29 02:43, Colin Watson a écrit :
While it might be possible to carry on doing without, the data
fundamentally has many relational properties and an RDBMS would make
life a lot easier. I wish I'd known what I know now about PostgreSQL
when I was in my period of working on debbugs v
These are part of the fighting spam strategy. It does not have to be a
binary solution. There can be reasonable restrictions and if people have
to target debian to get addresses that itself will avoid many email
address harvestors. It does not have to be open to all if we can't
prev
Hello,
On Thu 29 May 2025 at 11:31am +02, Marc Haber wrote:
> On Thu, May 29, 2025 at 10:27:09AM +0100, Sean Whitton wrote:
>>On Wed 28 May 2025 at 10:04pm +02, Marc Haber wrote:
>>> My personal pet peeve is the difference between the source package and the
>>> packaging git repository contents.
On Thu, May 29, 2025 at 10:27:09AM +0100, Sean Whitton wrote:
On Wed 28 May 2025 at 10:04pm +02, Marc Haber wrote:
My personal pet peeve is the difference between the source package and the
packaging git repository contents. Those two especially differ in the state of
patches: They're applied in
bably want to use git-debrebase or git-dpm or
single-debian-patch in addition to dgit.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Wed 28 May 2025 at 10:04pm +02, Marc Haber wrote:
> My personal pet peeve is the difference between the source package and the
> packaging git repository contents. Those two especially differ in the state of
> patches: They're applied in the unpacked source package, and not applied in
>
.)
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Wenn der Faschismus wiederkehrt, werden Medien ihn pflichtbewusst als
"umstritten" bezeichnen.
signature.asc
Description: PGP signature
de yourself.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
There are many ways to kill. You can stab someone in the guts, take their bread
away, not heal someone from disease, put someone in a
On Thu, May 29, 2025 at 09:54:37AM +0200, Marc Haber wrote:
> On Thu, May 29, 2025 at 09:52:38AM +0200, Joost van Baal-Ilić wrote:
> > A, indeed. Otoh the dgit-people feel a source package should be treated as
> > an
> > intermediate build artifact; not something to be consumed by humans.
>
> Bu
Hi,
On Thu, May 29, 2025 at 09:39:01AM +0200, Marc Haber wrote:
> On Thu, May 29, 2025 at 05:26:31AM +0200, Joost van Baal-Ilić wrote:
> > On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
> >
> > > My personal pet peeve is the difference between the source package and the
> > > packagi
Quoting Marc Haber (2025-05-29 09:57:07)
> On Thu, May 29, 2025 at 09:21:13AM +0200, Jonas Smedegaard wrote:
> >Perhaps, to ease the burden of those of us maintaining many packages,
> >we could instead have this more complex rule:
> >
> >> The default debian branch i
On Thu, May 29, 2025 at 09:21:13AM +0200, Jonas Smedegaard wrote:
Perhaps, to ease the burden of those of us maintaining many packages,
we could instead have this more complex rule:
The default debian branch is the first available of these, in order:
1. debian/latest
2. debian/unstable
3
, simplified documentation with full examples
6. track merge requests.
Most of these I also very much agree with, however I doubt that *we* want
to hide e-mail addresses from public (unauthenticated) web browsing. In my book
the open development model of Debian is tied to the fact that we the developers
On Thu, May 29, 2025 at 09:52:38AM +0200, Joost van Baal-Ilić wrote:
A, indeed. Otoh the dgit-people feel a source package should be treated as an
intermediate build artifact; not something to be consumed by humans.
But if you decide not to use dgit you're back to source packages. It
might be
On 29/05/2025 12:51 pm, Jonas Smedegaard wrote:
Quoting Xiyue Deng (2025-05-29 06:15:30)
Hi Holger,
Holger Levsen writes:
On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:
If you suggest that using "debian/latest" should *not* be done by
default, then it
Hi,
On Thu, May 29, 2025 at 05:26:31AM +0200, Joost van Baal-Ilić wrote:
On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
My personal pet peeve is the difference between the source package and the
packaging git repository contents. Those two especially differ in the state
of patches
Quoting Xiyue Deng (2025-05-29 06:15:30)
> Hi Holger,
>
> Holger Levsen writes:
>
> > On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:
> >> If you suggest that using "debian/latest" should *not* be done by
> >> default, then it s
Hi,
On Wed, May 28, 2025 at 11:11:47PM +, Holger Levsen wrote:
my biggest problem with dep14 is that it doesnt recommend *one* layout. my
biggest problem with how I see that interpreted is that I think debian/unstable
is much better than debian/latest *as a default recommendation*.
because
Hi Holger,
Holger Levsen writes:
> On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:
>> If you suggest that using "debian/latest" should *not* be done by
>> default, then it seems that requires reverting changes to DEP-14.
>
> yes. dep14 currently
gt; in
> > particular these two:
> >
> > - https://optimizedbyotto.com/post/debian-packaging-from-git/
>
> My personal pet peeve is the difference between the source package and the
> packaging git repository contents. Those two especially differ in the state
>
On Wed, May 28, 2025 at 01:53:21PM +0200, Julien Plissonneau Duquène wrote:
Le 2025-05-27 20:30, Ahmad Khalifa a écrit :
they all have a Database data model (faster search/query)
Having some experience with databases, I'm not convinced that a RDBMS
(SQL) is a necessity here. Better indexing a
On Wed, May 28, 2025 at 02:22:00PM +, Holger Levsen wrote:
Most of these I also very much agree with, however I doubt that *we* want
to hide e-mail addresses from public (unauthenticated) web browsing. In my book
the open development model of Debian is tied to the fact that we the developers
On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:
> If you suggest that using "debian/latest" should *not* be done by
> default, then it seems that requires reverting changes to DEP-14.
yes. dep14 currently says "that uploads to unstable and experimental shoul
On Wed, May 28, 2025 at 10:05:44PM +, Holger Levsen wrote:
> I appreciate and applaus Otto's posts too, but can we please agree on
> debian/unstable, debian/experimental, debian/trixie, ... as our *default*?
> while still "allowing" debian/latest and and also debian/3.
).
Maybe I'm exaggerating a bit,
Maybe "a bit" is a bit of an understatement :)
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `&
Quoting Holger Levsen (2025-05-29 00:05:44)
> On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
> > does it make sense to work in debian/latest and only last before pushing for
> > review create another branch next/debian/latest? I'd always intuitively work
>
On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
> does it make sense to work in debian/latest and only last before pushing for
> review create another branch next/debian/latest? I'd always intuitively work
> in next/debian/latest directly.
I appreciate and applaus Ot
Julien Plissonneau Duquène writes:
> I'm considering getting my hands into that thing later this year, so
> let me try to summarize the relevant parts of the previous threads
> (with the intent of documenting this in a wiki page).
this is awesome
> We would like debbugs to:
> 0. keep all the e-
they represent your
personal opinion and that people who want to delve into alternatives
could read the official docs here, here and here.
in
particular these two:
- https://optimizedbyotto.com/post/debian-packaging-from-git/
I would love this article (or a third one) explaining how to co
On May 28, Ahmad Khalifa wrote:
Anyone can manipulate any bug without restriction and in bulk.
Untag it as RC, email 0-9 with the -done suffix, spam it with
links, target packages that echo to a mailing list.
Security measures should be proportional to the specific threat, and
we actually
least the emails should be authenticated somehow
(@debian only maybe? one-time register-confirm emails?).
We have to be careful with changes here, as they could easily become
major annoyances for casual and even regular contributors.
Of course, and I fully acknowledge that existing users have
(@debian only maybe? one-time register-confirm emails?).
Can you expand on why you think manipulating bugs by mail is a security
flaw?
Anyone can manipulate any bug without restriction and in bulk.
Untag it as RC, email 0-9 with the -done suffix, spam it with links,
target packages that echo to
documentation with full examples
> 6. track merge requests.
Most of these I also very much agree with, however I doubt that *we* want
to hide e-mail addresses from public (unauthenticated) web browsing. In my book
the open development model of Debian is tied to the fact that we the developers
are
they landed on a "local optimum" they don't want
to go through all the complexity to re-learn another way.
To combat the general complexity, I have contributed in the past year
to the Developer's Reference, to the Git-buildpackage manual and a
bunch of man pages in Debian. H
On 28/05/25 at 13:53 +0200, Julien Plissonneau Duquène wrote:
> > they all have a Database data model (faster search/query)
>
> Having some experience with databases, I'm not convinced that a RDBMS (SQL)
> is a necessity here. Better indexing and caching would definitely help
> though.
Even if I'
On Wed, May 28, 2025 at 01:53:21PM +0200, Julien Plissonneau Duquène wrote:
1. process new requests and give feedback instantly
My opinion now is that debbugs runs pretty frequently, but emails
get rejected randomly, leading to a 30min wait for mail queue
reruns. This is probably a mail serve
On 27/05/2025 21:59, Lucas Nussbaum wrote:
- add a new field that allows pointing to a merge request (similar to
the 'forwarded' field)
My intuition is that there are cases where we would like to link several
merge requests (possibly in different repositories) to a single bug.
- have a b
On 28/05/2025 00:25, tho...@goirand.fr wrote:
Please do contribute this upstream, so we get it on our next upgrade !
Yes, that's also a possibility.
Cheers,
--
Julien Plissonneau Duquène
(@debian only maybe? one-time register-confirm emails?).
We have to be careful with changes here, as they could easily become
major annoyances for casual and even regular contributors.
We probably want to keep posting to submit@ and NNN(-*)@ (excepted
-done) open as it is, despite the spam that
On Tue May 27, 2025 at 7:30 PM BST, Ahmad Khalifa wrote:
0. keep all the e-mail features it currently offers
IMHO, this is a security flaw, not a feature. I hear that everyone loves
it, so at least the emails should be authenticated somehow (@debian only
maybe? one-time register-confirm
On Tue, May 27, 2025 at 10:37:22AM -0700, Otto Kekäläinen wrote:
I would assume Debbugs might evolve without you having to personally
do all the improvements, if you allow improvements done by others flow
in.
As an example, I have had
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests
On May 27, 2025 20:57, Julien Plissonneau Duquène wrote:
>
> Le 2025-05-27 20:08, tho...@goirand.fr a écrit :
> > THANKS. Indeed, it is annoying us a lot, Salsa users too, but anyone
> > sending us a quick email always receives a reply in due time. This
> > indeed is better than having b
On 27/05/25 at 18:46 +0200, Julien Plissonneau Duquène wrote:
> 6. track merge requests.
Maybe something similar to bts-link[0]?
- add a new field that allows pointing to a merge request (similar to
the 'forwarded' field)
- have a bot that processes bugs with merge requests and adjust BTS tags
On 5/27/25 10:16 PM, Julien Plissonneau Duquène wrote:
I took note of some existing previous work for 3. (MUMI, DebGTD) that is
worth looking at though I could not find anything about "the return of
the Amancay".
Please consider https://fabre.debian.net/ as well.
OpenPGP_0x8F53E0193B294B75.
> > Debian has certainly done many things right in the past 30 years, but
> > treatment of new contributors is currently pretty harsh, considering
> > how many cracks and false turns they need to overcome on to become
> > regular contributors.
>
> The impact success
Le 2025-05-27 20:08, tho...@goirand.fr a écrit :
THANKS. Indeed, it is annoying us a lot, Salsa users too, but anyone
sending us a quick email always receives a reply in due time. This
indeed is better than having bots spamming all of Salsa.
The delay is only a part of the issue, the other part
-mail features it currently offers
IMHO, this is a security flaw, not a feature. I hear that everyone loves
it, so at least the emails should be authenticated somehow (@debian only
maybe? one-time register-confirm emails?).
1. process new requests and give feedback instantly
My opinion n
> requests, and giving all registered Debian contributors a way to
> generate invitation links that would not require further manual approval
> (iow these registrations would be "pre-approved" by the contributor
> generating the link, and they would be accountable in case of abuse). I
On May 27, 2025 19:17, Russ Allbery wrote:
>
> Julien Plissonneau Duquène writes:
> I would be worried about dropping the manual approval due to the sheer
> volume of sophisticated automated spam account creation attacks on any
> sort of authentication process with automatic sign-up.
anual approval, as I don't know
of any automated and accurate method that could be used to prevent such
abuse.
I'm rather proposing giving all DDs the power to approve pending
requests, and giving all registered Debian contributors a way to
generate invitation links that would not require
> I endorse basically all of this. (I had really hoped to be able to put
> significant effort into modernizing debbugs over the past year or so,
I understand time is always a limitation, but if/when you have time
for debbugs, could you please prioritize reviewing/merging the open
MRs?
I would as
my tenure.
That sort of amount of time is probably more representative of the
likely workload for Debian than something like GitHub's efforts would
be; but it might still be more than we have available.
And I agree that captcha-type methods aren't anywhere near sufficient.
We frequ
On Tue, May 27, 2025 at 06:46:29PM +0200, Julien Plissonneau Duquène wrote:
Unlike some people I believe that debbugs can be improved and
modernized in a satisfying way while retaining most if not all of its
current interfaces. This would minimize breakage and inconvenience for
developers that
Julien Plissonneau Duquène writes:
> I would first try to improve the Salsa registration process. I
> understand the need to prevent recurrent abuse, but the current manual
> approval process with its delay and lack of feedback when things go
> wrong is likely to discourage casual contributors, a
Hi,
On 21/05/2025 17:48, Otto Kekäläinen wrote:
Debian has certainly done many things right in the past 30 years, but
treatment of new contributors is currently pretty harsh, considering
how many cracks and false turns they need to overcome on to become
regular contributors.
The impact
grating away from JIRA to GitHub
issues, but they also have a fairly different usage pattern than Debian.
For Debian maybe something like Redmine could work (I'm not suggesting a
change, but looking at alternatives may give some ideas).
Cheers,
--
Julien Plissonneau Duquène
t; packages probably sometime around the release of Trixie.
>
> As upstream has moved around a bit, wouldn't it make more sense for mono
> to package the dotnet repository for Forky instead?
>
> My understanding is that debian mono is sourced from the mono-project
> repo [1
on keeping Mono in Debian and have no real
motivation to start packaging dotnet in addition to it.
Of course it should not prevent anyone else from starting a packaging
effort for dotnet, we might even be able to share some tools between
mono and dotnet to lessen the load for both teams.
> My
otnet repository for Forky instead?
My understanding is that debian mono is sourced from the mono-project
repo [1], which is no longer maintained, but the wine-mono fork [2] has
v6 going. wine-mono is distributed with Wine, but not packaged in
debian. I know wine-hq will download mono and set it up (ru
Hello,
On Sun 25 May 2025 at 06:25pm +02, Marc Haber wrote:
> On Sun, 25 May 2025 17:34:58 +0500, Andrey Rakhmatullin
> wrote:
>>(note that it requires /usr/sbin/sendmail by default, though there seem to
>>be options to use SMTP)
>
> The /usr/lib/sendmail interface is dying anyway, it doesn't pl
On Sun May 25, 2025 at 4:41 PM BST, Richard Lewis wrote:
someone could, for example, make the bts support \ to continue a line,
that would benefit everyone without breaking anything?
This is a reasonable suggestion. I advise filing a wishlist bug to
request it (that is, if your mailer lets yo
Hello,
On Mon 26 May 2025 at 01:13pm +02, Julien Plissonneau Duquène wrote:
> Hi,
>
> Le 2025-05-21 14:45, Sean Whitton a écrit :
>> It's meant to be kept up-to-date. If it's a dead link, it should be
>> deleted.
>
> The way it is currently specified in thi
Hi,
Le 2025-05-21 14:45, Sean Whitton a écrit :
It's meant to be kept up-to-date. If it's a dead link, it should be
deleted.
The way it is currently specified in this appendix of Debian Policy [1]
reads:
an explanation of where the upstream source came from
Note "where
On Sun, 25 May 2025 17:34:58 +0500, Andrey Rakhmatullin
wrote:
>(note that it requires /usr/sbin/sendmail by default, though there seem to
>be options to use SMTP)
The /usr/lib/sendmail interface is dying anyway, it doesn't play well
with systemd, and it doesn't play at all with systemd units th
On Sun, May 25, 2025 at 04:41:38PM +0100, Richard Lewis wrote:
i believe i read (sorry again: i used an android phone and accessed a
website that wasnt released as free software to find this information)
that gmail breaks lines because some RFC recommends lines should be less
than some length, an
Holger Levsen writes:
> On Sun, May 25, 2025 at 10:56:14AM +0100, Richard Lewis wrote:
>> It would be really nice if there was an easy way to link a bug report to a
>> MR on salsa
>> you can try
>> forwaded NN
>> https://salsa.debian.org/debian-team/package
On Sun, May 25, 2025 at 01:02:25PM +0100, Colin Watson wrote:
It would be really nice if there was an easy way to link a bug report to a MR
on salsa
you can try
forwaded NN
https://salsa.debian.org/debian-team/package-name/-/merge_requests/MMM
but eg gmail will break the long line
On Sun, May 25, 2025 at 10:56:14AM +0100, Richard Lewis wrote:
It would be really nice if there was an easy way to link a bug report to a MR
on salsa
you can try
forwaded NN
https://salsa.debian.org/debian-team/package-name/-/merge_requests/MMM
but eg gmail will break the long line
On Sun, May 25, 2025 at 10:56:14AM +0100, Richard Lewis wrote:
It would be really nice if there was an easy way to link a bug report to a MR
on salsa
you can try
forwaded NN
https://salsa.debian.org/debian-team/package-name/-/merge_requests/MMM
but eg gmail will break the long line
On Sun, 25 May 2025 10:56:14 +0100, Richard Lewis
wrote:
>but eg gmail will break the long line before the url (we can all say how
>bad gmail is, but that doesnt solve anything)
Gmail is completely unsuitable for Debian work, and that's not
Deb
On Sun, May 25, 2025 at 10:56:14AM +0100, Richard Lewis wrote:
> It would be really nice if there was an easy way to link a bug report to a MR
> on salsa
> you can try
> forwaded NN
> https://salsa.debian.org/debian-team/package-name/-/merge_requests/MMM
> but eg gmail w
request tracker, something that Debbugs was never
> intended to be, and is available in Salsa already.
It would be really nice if there was an easy way to link a bug report to a MR
on salsa
you can try
forwaded NN
https://salsa.debian.org/debian-team/package-name/-/merge_requests/MMM
b
Quoting Christian BAYLE (2025-05-24 22:27:41)
> Hello,
>
> if I wanted to rethink the bug tracking
> i would seriously consider storing the bug in git
>
> maybe with something like this i just discovered
> https://github.com/git-bug/git-bug/tree/master
>
> The big advantage is to unlock the trac
Hello,
if I wanted to rethink the bug tracking
i would seriously consider storing the bug in git
maybe with something like this i just discovered
https://github.com/git-bug/git-bug/tree/master
The big advantage is to unlock the tracking from any forge
and there is some kind of logic to attach b
ailable in Salsa already. Also they used extra
scripts that were not properly interfaced with the BTS, which leads to
extra problem.
So I do not think this applies to Debian.
Cheers,
--
Bill.
Imagine a large red swirl here.
t could be an option. If Atlassian offered the Debian project free
(gratis) use of their platform (especially if they handle the
administration), why wouldn't we accept?
Three points:
Having used Jira - I think I'd rather stick hot needles in my eyes.
Atlassian are *EXTREMELY* unlikely
lifa wrote:
It's alive, not sure if sponsored by Red Hat/Mozilla, but both use it
(and Kernel, KDE, the list goes on).
Red Hat have transitioned almost entirely to JIRA.
Thankfully that's not an option for us (not dfsg free).
But it could be an option. If Atlassian offered the
1 - 100 of 1615 matches
Mail list logo
