On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
> * are BD-Uninstallabe,
> * FTBFS
On Fri, 19 Apr 2024 10:09:26 +0200
José Luis González González wrote:
> On Fri, 19 Apr 2024 09:59:57 +0200
> José Luis González González wrote:
>
> > On Fri, 19 Apr 2024 09:39:02 +0200
> > José Luis González González wrote:
> >
> > > Good day,
> > >
> > > There's an issue with the dash
Hi Sebastian,
Andreas Tille, on 2024-04-19:
> I've spotted these Debian Med packages.
[…]
> Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher:
[…]
> > jellyfish
> > quorum
[…]
> No idea how we can help here. Please let us know if we can do
> something.
About these two
You've written a lot of text here in a few mails, replying to yourself
several times. This is not a positive pattern.
On Fri, Apr 19, 2024 at 11:58:18AM +0200, José Luis González González wrote:
>> There are similar issues with boa and dhttpd, and it seems Apache is going
>> that way.
>
>nvi
On Fri, 19 Apr 2024 10:09:26 +0200
José Luis González González wrote:
> On Fri, 19 Apr 2024 09:59:57 +0200
> José Luis González González wrote:
>
> > On Fri, 19 Apr 2024 09:39:02 +0200
> > José Luis González González wrote:
> >
> > > Good day,
> > >
> > > There's an issue with the dash
Hi Sebastian,
thank you for your work on t64 transition.
Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher:
I've spotted these Debian Med packages.
> gentle
> jellyfish
> quorum
> sbmltoolbox
No idea how we can help here. Please let us know if we can do
something.
> anfo
Hello,
On Thu, 2024-04-18 at 21:22 +0200, Sebastian Ramacher wrote:
> Finally, packages that need rebuilds but currently have open FTBFS (RC +
> ftbfs tag) bugs:
> (...)
> virtualjaguar
I already have a tentative patch and will fix the package within the next
days. I am also preparing to fix two
Jonas Smedegaard writes:
> Quoting Simon Josefsson (2024-04-18 09:34:26)
>> Jonas Smedegaard writes:
>>
>> > That said, you are welcome to try nudge me if some concrete task
>> > emerges where you image I might be of help.
>>
>> Thanks -- I'm moving this out of 921954@bugs and cc'ing
Sebastian Ramacher writes:
> Hi,
>
> as the progress on the t64 transition is slowing down, I want to give an
> overview of some of the remaining blockers that we need to tackle to get
> it unstuck. I tried to identify some clusters of issues, but there might
> be other classes of issues.
Hi,
Em sex., 19 de abr. de 2024, 04:46, Marco d'Itri escreveu:
> On Apr 19, José Luis González González wrote:
>
> > I even tried to reach dash maintainer privately and he is not even on
> > the package's field (queried by dpkg), there's someone who is obviosly
> > fake instead: Andrej Shadura
On Fri, 19 Apr 2024 09:59:57 +0200
José Luis González González wrote:
> On Fri, 19 Apr 2024 09:39:02 +0200
> José Luis González González wrote:
>
> > Good day,
> >
> > There's an issue with the dash package and maintainer, and mutt as well.
> >
> > I even tried to reach dash maintainer
On Apr 19, José Luis González González wrote:
> I even tried to reach dash maintainer privately and he is not even on
> the package's field (queried by dpkg), there's someone who is obviosly
> fake instead: Andrej Shadura
I have met Andrej a few times and I am quite sure that he is real.
Or
On 2024-04-19 06:02:03 +0200, Andreas Metzler wrote:
> On 2024-04-18 Sebastian Ramacher wrote:
> [...]
> > Let's start with the first category. Those are packages that could be
> > binNMUed, but there are issues that make those rebuilds not have the
> > desired effect. This list include packages
Hello Go and Rust packagers,
On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote:
> With the increasing amount of programs in Debian that Build-Depend and
> statically link with Golang and Rust libraries, it's important that
> the Debian Policy clearly sets out the requirements for
On 2024-04-18 Sebastian Ramacher wrote:
[...]
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
> * are BD-Uninstallabe,
> * FTBFS but with out
Quoting Simon Josefsson (2024-04-18 09:34:26)
> Jonas Smedegaard writes:
>
> > That said, you are welcome to try nudge me if some concrete task
> > emerges where you image I might be of help.
>
> Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to
> allow others to help and
Quoting Jonathan Dowland (2024-04-18 09:35:41)
> On Wed Apr 17, 2024 at 7:26 PM BST, Jonas Smedegaard wrote:
> > To be fair, I _was_ upset (not with Jonathan, but) earlier in this
> > thread, which makes it harder to err on the side of a mistake when I
> > write something that can be read as being
On 4/9/24 03:25, James McCoy wrote:
When I first started looking into Rust packaging it was initially going
to be for a workspace of crates. I didn't receive any pushback when I
asked about taking over the one crate that had already been packaged and
handling it from a single source package for
Hi,
* Jonathan Dowland [2024-04-18 08:35]:
Sorry, Jonathan, for being difficult to read here.
No problem: Sorry for lapsing in assuming good faith on my part.
The way both of you handled this misunderstanding was... exemplary.
SCNR
Timo
--
⢀⣴⠾⠻⢶⣦⠀
On Wed Apr 17, 2024 at 7:26 PM BST, Jonas Smedegaard wrote:
> To be fair, I _was_ upset (not with Jonathan, but) earlier in this
> thread, which makes it harder to err on the side of a mistake when I
> write something that can be read as being sarcastic.
I would be upset too if my packages were
Jonas Smedegaard writes:
> That said, you are welcome to try nudge me if some concrete task
> emerges where you image I might be of help.
Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to
allow others to help and to allow you from not having to feel a need to
reply at all
Quoting Russ Allbery (2024-04-17 19:53:06)
> Jonas Smedegaard writes:
> > Quoting Jonathan Dowland (2024-04-17 17:29:11)
> >> On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote:
>
> >>> Interesting: Can you elaborate on those examplary contributions of
> >>> yours which highlighted a
Jonas Smedegaard writes:
> Quoting Jonathan Dowland (2024-04-17 17:29:11)
>> On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote:
>>> Interesting: Can you elaborate on those examplary contributions of
>>> yours which highlighted a need for maintaining all Haskell packages in
>>> same git
[replying list-only - unable to identify who is subscribed]
Quoting Jonathan Dowland (2024-04-17 17:29:11)
> On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote:
> > (or did I misunderstand your point?)
>
> You misunderstood my point: I was actually supporting your position.
Oh!
>
On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote:
> (or did I misunderstand your point?)
You misunderstood my point: I was actually supporting your position.
You've read it entirely backwards.
> Interesting: Can you elaborate on those examplary contributions of yours
> which
Hi Alan,
I granted you with the maintainer access to this repo:
https://salsa.debian.org/debian/hyprlang
This package has cleared the NEW queue a while ago:
https://tracker.debian.org/pkg/hyprlang
Could you please push your changes from personal repo
to the above repo? I can also do it for you
Quoting Jonathan Dowland (2024-04-17 11:14:20)
> On Mon Apr 8, 2024 at 9:21 PM BST, Jonas Smedegaard wrote:
> > What I am not open to is abandon the one-git-repo-per-source-package
> > packaging style that is commonly practiced in Debian. As I understand
> > it, only Haskell and Rust teams use
On Mon Apr 8, 2024 at 9:21 PM BST, Jonas Smedegaard wrote:
> What I am not open to is abandon the one-git-repo-per-source-package
> packaging style that is commonly practiced in Debian. As I understand
> it, only Haskell and Rust teams use giant-git-for-all-team-packages
> style
I've never
On 12.04.24 00:52, Bill Allombert wrote:
These contributions always need to be carefull reviewed before being
accepted. As likely as not, they are either slightly incorrect or
introducing subtle breakages in some case the submitter did not
envision. This is where an expert maintainer is most
Package: wnpp
Severity: wishlist
Owner: Dale Richards
X-Debbugs-Cc: debian-devel@lists.debian.org, d...@dalerichards.net
* Package name: python-re-assert
Version : 1.1.0
Upstream Contact: Anthony Sottile <https://github.com/asottile>
* URL : https://gith
Am Fri, Apr 12, 2024 at 09:36:25PM +0200 schrieb Bastian Blank:
> > - I also think disallowing single-person maintainership would be very
> > unwise,
> > though I agree team maintenance in general is probably better than
> > single-person maintainership. Still disallowing single-person
> >
On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel wrote:
> Debian is about freedom, so let's apply that to free choice of the tooling
> to be usable.
I disagree. "Freedom" is about Free Software, so-called freedom in
packaging has high costs as people (who look at more than their
"own" favourite
Processing control commands:
> reassign -1 src:apt
Bug #1068823 [general] Stepwise Debian upgrade to enable systems with little
free storage space to upgrade without breaks due to "No space left on device"
Bug reassigned from package 'general' to 'src:apt'.
Ignoring request to alter found
On Sat, 13 Apr 2024 at 10:11, Salvo Tomaselli wrote:
>
> > New contributors won't start in a vacuum, most will start contributing
> > first to existing projects on Salsa
>
> Or maybe they start with an ITP+RFS… was that an informed statement or a
> supposition?
It is my experience in receiving
On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote:
> Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter:
> >
> > For example, any repository that does not list debian/files and
> > debian/*.substvars in the gitignore will fail to build twice in a row,
> > because these
On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote:
> > For example, any repository that does not list debian/files and
> > debian/*.substvars in the gitignore will fail to build twice in a row,
> > because these files are created and are subsequently untracked.
>
> Sorry, no. We
Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter:
>
> For example, any repository that does not list debian/files and
> debian/*.substvars in the gitignore will fail to build twice in a row,
> because these files are created and are subsequently untracked.
Sorry, no. We should
On 12.04.24 19:28, Luca Boccassi wrote:
New contributors won't start in a vacuum, most will start contributing
first to existing projects on Salsa, which are already set up and
configured to do what is needed, if it is needed.
+1 here
Git is the bare
minimum these days, and has been for
t just
re-use upstreams CI tests. And which conflict outside of git with the
next upstream version.
I just stopped that and use git alone.
> - I also think disallowing single-person maintainership would be very unwise,
> though I agree team maintenance in general is probably better tha
On Fri, 12 Apr 2024 at 17:17, Simon Richter wrote:
>
> Hi,
>
> On 13.04.24 00:19, Marc Haber wrote:
>
> >> 'Require' is probably the wrong word. I simply have heard from several
> >> potential young contributors that they feel blocked by the tooling and
> >> specifically not everything in Git.
>
Hi,
On 13.04.24 00:19, Marc Haber wrote:
'Require' is probably the wrong word. I simply have heard from several
potential young contributors that they feel blocked by the tooling and
specifically not everything in Git.
That does not only apply to young contributors. I am an old fart and I
On Wed, 10 Apr 2024 22:44:25 +0200, Andreas Tille
wrote:
>'Require' is probably the wrong word. I simply have heard from several
>potential young contributors that they feel blocked by the tooling and
>specifically not everything in Git.
That does not only apply to young contributors. I am an
Please do it yourself by following the instructions here:
https://lists.debian.org/debian-devel/
Maycon Antônio wrote on 08/04/2024 at 17:44:20+0200:
> Please cancel my name from this list, thank you.
>
> On Sun, 7 Apr 2024 at 12:32, Sean Whitton wrote:
>>
>> Hello everyone,
>>
>> I just
On 12/04/24 15:00, Marc Haber wrote:
On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel
wrote:
Also regarding gbp, my packaging workflow does not require it
(debian/-folder-only in Git). Being enforced to use some other pkg'ing
style would reduce my fun and end up with less productivity, I fear.
On Tue, 9 Apr 2024 20:51:45 +0200, Gioele Barabucci
wrote:
>Asking maintainers "to use git" means: please push your changes, even
>those unreleased to a public git repository (salsa, github, codeberg,
>your own domain...), so other people can contribute 1) knowing that they
>are working
On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel
wrote:
>Also regarding gbp, my packaging workflow does not require it
>(debian/-folder-only in Git). Being enforced to use some other pkg'ing
>style would reduce my fun and end up with less productivity, I fear.
>The gbp workflow has its
On Tue, 9 Apr 2024 18:37:23 +, Holger Levsen
wrote:
>- I also think disallowing single-person maintainership would be very unwise,
> though I agree team maintenance in general is probably better than
> single-person maintainership.
Agreed.
> Still disallowing single-person maintainership
On Fri, Apr 12, 2024 at 09:53:29AM +0100, Jonathan Dowland wrote:
> On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote:
[...]
> I agree with everything you say here!
:)
> Wrt git-buildpackage, I'd like to add that personally, I respect the gbp
> authors and maintainers and it's a very useful
Hi all, hi Holger,
On Di 09 Apr 2024 18:37:23 UTC, Holger Levsen wrote:
hi,
just adding some random data points to this thread:
- I love git.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
where I can.
- I like salsa. (though I think for many new contributors
On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote:
> - I love git.
> - I very much dislike git-buildpackage, too much magic. I try to avoid it
> where I can.
> - I like salsa. (though I think for many new contributors this is rather
> a barrier "why not use github" directly. Also salsa is
On Thu, Apr 11, 2024 at 01:27:54PM -0500, G. Branden Robinson wrote:
> At 2024-04-11T15:37:46+0100, Colin Watson wrote:
> > On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote:
> > > Or, because some upstream maintainers have learned through, long,
> > > bitter experience that newer
Le Tue, Apr 09, 2024 at 12:18:02AM +0200, Johannes Schauer Marin Rodrigues a
écrit :
> we need both. Domain specific knowledge is clearly very important and I'm not
> trying to argue against it. But doing packaging in a way such that it becomes
> easy for others to contribute is *also* every
At 2024-04-11T15:37:46+0100, Colin Watson wrote:
> On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote:
> > Or, because some upstream maintainers have learned through, long,
> > bitter experience that newer versions of autoconf tools may result
> > in the generated configure script to be
On Thu, Apr 11, 2024 at 03:37:46PM +0100, Colin Watson wrote:
>
> When was the last time this actually happened to you? I certainly
> remember it being a problem in the early 2.5x days, but it's been well
> over a decade since this actually bit me.
I'd have to go through git archives, but I
On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote:
> On Sat, Apr 06, 2024 at 04:30:44PM +0100, Simon McVittie wrote:
> > But, it is conventional for Autotools projects to ship the generated
> > ./configure script *as well* (for example this is what `make dist`
> > outputs), to allow
On Sat, Apr 06, 2024 at 04:30:44PM +0100, Simon McVittie wrote:
>
> But, it is conventional for Autotools projects to ship the generated
> ./configure script *as well* (for example this is what `make dist`
> outputs), to allow the project to be compiled on systems that do not
> have the complete
Quoting Andreas Tille (2024-04-10 22:44:25)
> > I do understand the argument that lots of different workflows adds
> > friction. But I'm just still using what used to be _the_ standard one
> > (insofar as we ever had such a thing). Putting everything in salsa/git
> > doesn't standardise workflows
On Tue, 09 Apr 2024 17:52:43 +0100, Wookey wrote:
> On 2024-04-08 21:44 +0900, Simon Richter wrote:
> > Testing a package requires me to
> > commit everything into git first, so I have to remember to squash all these
> > commits later.
> Right - this was (one of the) main thing(s) that annoyed me
blame you about
some fat commits.
> Sometimes git is useful - I do use it quite intensively for things
> where it actually helps (complicated cave survey datasets with
> hundreds of entangled commits that need re-ordering). For the vast
> majority of my debian packaging it's just make
On Tue, 09 Apr 2024 16:07:20 +0200, Andreas Tille wrote:
> Am Mon, Apr 08, 2024 at 03:45:48PM +0200 schrieb Julien Puydt:
> > I only use salsa's git. That begs two questions:
> > - What do I miss by not using the web interface?
> If you are owner of a team repository you need to manage members.
On April 9, 2024 6:37:23 PM UTC, Holger Levsen wrote:
>hi,
>
>just adding some random data points to this thread:
>
>- I love git.
>- I very much dislike git-buildpackage, too much magic. I try to avoid it
> where I can.
>- I like salsa. (though I think for many new contributors this is
On 09/04/24 18:52, Wookey wrote:
So why mandate salsa rather than make dgit more official?
Independently from whether salsa should be mandated, "git", "salsa" and
"dgit" are three different things and should not be used as replacement
of one another.
Asking maintainers "to use git" means:
On Mon, Apr 08, 2024 at 11:00:52PM +0100, Luca Boccassi wrote:
> ...right up until the point where that "bus factor of 1" moves
> on/changes priorities/changes job/etc and the package is abandoned.
> Fortunately that never happens, though!
Having a repository on salsa or even "packaging team"
hi,
just adding some random data points to this thread:
- I love git.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
where I can.
- I like salsa. (though I think for many new contributors this is rather
a barrier "why not use github" directly. Also salsa is Debian
h simple y and
n. You can also split blocks.
If you prefer to just make a bunch of small commits and then combine
them all into one big-fat commit, just use git rebase -i HEAD~N with N
being how many commits you want to rebase.
This will give you a file text where you decide which commits are
squa
On Tue, Apr 09, 2024 at 07:43:04PM +0200, Johannes Schauer Marin Rodrigues
wrote:
> > And I do just prefer having two directories rather than multiple
> > version on top of each other. My simple brain finds it a lot easier to
> > keep track of a version directory to diff between, rather than
On Tue, Apr 09, 2024 at 05:52:43PM +0100, Wookey wrote:
> Right - this was (one of the) main thing(s) that annoyed me enough to
> just go back to the non-git based workflow. I want to make changes and
> try them. I don't want to have to commit every damn time - it's not
> done yet - I'll commit it
Hi Wookey and all,
Quoting Wookey (2024-04-09 18:52:43)
> On 2024-04-08 21:44 +0900, Simon Richter wrote:
> > Testing a package requires me to commit everything into git first, so I
> > have to remember to squash all these commits later.
> Right - this was (one of the) main thing(s) that annoyed
Am Tue, Apr 09, 2024 at 01:03:10PM + schrieb Stefano Rivera:
> > I have also noticed that the young people we manage to recruit are
> > usually not interested too much in the boring gruntwork of maintaining
> > important core packages (like adduser and sudo) but instead want to do
> > "new"
it quite intensively for things
where it actually helps (complicated cave survey datasets with
hundreds of entangled commits that need re-ordering). For the vast
majority of my debian packaging it's just makework.
I realise this (like my previous message) will result in a load of
people telling me git _i
Hi Julien,
Am Mon, Apr 08, 2024 at 03:45:48PM +0200 schrieb Julien Puydt:
>
> I only use salsa's git. That begs two questions:
> - What do I miss by not using the web interface?
If you are owner of a team repository you need to manage members. As
far as I know this is only possible via web
Hi Marc (2024.04.08_16:48:13_+)
> I have also noticed that the young people we manage to recruit are
> usually not interested too much in the boring gruntwork of maintaining
> important core packages (like adduser and sudo) but instead want to do
> "new" things. But, otoh, what would Debian be
[I'm skipping most of this email because I haven't generally been
keeping up with the thread, but thought it might be worth pointing out
one thing.]
On Mon, Apr 08, 2024 at 06:48:13PM +0200, Marc Haber wrote:
> On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas Tille wrote:
> > Before uploading I
On 09/04/24 08:52, Simon Richter wrote:
Otoh, I am fully aware of the "you can't force a volunteer to do
things", knowing that I myself would be the first one to violently
oppose a decision that I don't like while - at the same time - being
mad at some core package maintainers who have forced
On Mon, Apr 8, 2024 at 9:15 PM Attila Szalay wrote:
>
> Ok. I re-checked the patch and realized that I checked the only wrong
> module (the only one which is arch all and not any).
>
> So my apologies for the fuzz and will apply the patch with the
> appropriate changes.
>
&
t cargo crate.
¹ "Package naming" in https://wiki.debian.org/Teams/RustPackaging/Policy
> > > > I'd still prefer if we could consolidate our efforts into the rust
> > > > team (and re-integrate your forks of our package helpers), rather
> > > > than ha
Hi,
On 4/9/24 01:48, Marc Haber wrote:
Otoh, I am fully aware of the "you can't force a volunteer to do
things", knowing that I myself would be the first one to violently
oppose a decision that I don't like while - at the same time - being
mad at some core package maintainers who have forced
pping on your work.
>
> Yes, please improve your tooling to better align with Debian packaging
> rules, not assume your team rules apply also outside of your team.
Having policy for a language ecosystem is pretty common, since that
makes it easier to interoperate.
> > > I'd still
On Mon, 8 Apr 2024 at 23:23, Joerg Jaspert wrote:
>
> On 17194 March 1977, Luca Boccassi wrote:
> >> Simple packages need someone who is responsible and responsive for
> >> them
> >> in the long run and know there history much more than needing
> >> sporadic
> >> contributions.
> > ...right up
On 17194 March 1977, Luca Boccassi wrote:
Simple packages need someone who is responsible and responsive for
them
in the long run and know there history much more than needing
sporadic
contributions.
...right up until the point where that "bus factor of 1" moves
on/changes priorities/changes
Quoting Bill Allombert (2024-04-08 23:49:05)
> Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
> > On 07/04/24 23:11, Bill Allombert wrote:
> > > > What is your opinion about pushing logtool to Salsa?
> > >
> > > Not speaking for logtool obviously, but maintaining simple
On Mon, 8 Apr 2024 at 22:49, Bill Allombert wrote:
>
> Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
> > On 07/04/24 23:11, Bill Allombert wrote:
> > > > What is your opinion about pushing logtool to Salsa?
> > >
> > > Not speaking for logtool obviously, but maintaining
Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
> On 07/04/24 23:11, Bill Allombert wrote:
> > > What is your opinion about pushing logtool to Salsa?
> >
> > Not speaking for logtool obviously, but maintaining simple packages on
> > salsa is
> > just useless bureaucracy.
>
ur tooling to better detect this so we get accurate information
> > presented to us and avoid stepping on your work.
Yes, please improve your tooling to better align with Debian packaging
rules, not assume your team rules apply also outside of your team.
> > I'd still prefer if we
On Monday, April 8, 2024 12:48:13 PM EDT Marc Haber wrote:
> > > "we replace exim with postfix as the default MTA",
> >
> > A, this question always makes me wonder: If our default MTA is exim
> > why do I have such a hard time to find documents about exim in wiki.d.o
> > while there is
Please cancel my name from this list, thank you.
On Sun, 7 Apr 2024 at 12:32, Sean Whitton wrote:
>
> Hello everyone,
>
> I just pushed version 4.7.0.0 of the Debian Policy Manual and related
> documents to sid. Below you will find the significant normative changes
> from the
te information presented to us and avoid
> stepping on your work.
>
> I'd still prefer if we could consolidate our efforts into the rust
> team (and re-integrate your forks of our package helpers), rather than
> have two divergent sources of rust packaging.
>
> Cheers,
> --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Hi Julien,
On 4/8/24 22:45, Julien Puydt wrote:
I only use salsa's git. That begs two questions:
- What do I miss by not using the web interface?
> - What does that web interface have that people don't like?
It's a normal GitLab install. For anything that is a normal software
project (like
Il 08/04/2024 15:45, Julien Puydt ha scritto:
Hi
Le lun. 8 avr. 2024, 14:45, Simon Richter a écrit :
The web interface presented by salsa also does not have the necessary
data<->metadata filters to provide an actual insight into what is
really
happening in the repository.
Hi
Le lun. 8 avr. 2024, 14:45, Simon Richter a écrit :
> The web interface presented by salsa also does not have the necessary
> data<->metadata filters to provide an actual insight into what is really
> happening in the repository.
>
It's been several times already some people complain about
Ok. I re-checked the patch and realized that I checked the only wrong
module (the only one which is arch all and not any).
So my apologies for the fuzz and will apply the patch with the
appropriate changes.
But here my original reply too:
I admit that I joined late to this conversation. But my
On Mon, Apr 08, 2024 at 09:44:55PM +0900, Simon Richter wrote:
> > I don't mind what other people do, but I worry that conversations like
> > this seem to take the new thing as so self-evidently better that
> > no-one can reasonably complain about them being made a
> > requirement. Well, we don't
Hi,
On 4/8/24 05:42, Wookey wrote:
I don't mind what other people do, but I worry that conversations like
this seem to take the new thing as so self-evidently better that
no-one can reasonably complain about them being made a
requirement. Well, we don't all think it's better, and I wouldn't
* José Luis González [240407 15:00]:
> reopen 1068479
> thanks
>
> Hi all,
>
> Rene Engelhard seems to be a worse case even than Ricardo Mones. Take a
> look at my recent bug reports to libreoffice-writer and his replies.
>
> In this one:
>
> > Am 06.04.24 um 11:03 schrieb Rene Engelhard:
> >
source package where as you've been packaging an entire
workspace as a source package. We need to adapt our tooling to better
detect this so we get accurate information presented to us and avoid
stepping on your work.
I'd still prefer if we could consolidate our efforts into the rust
team (and re-int
Bill Alombert wrote:
>On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote:
>> Hi Wouter,
>>
>> Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
>> > [Feel free to quote any part of this email which I wrote outside of this
>> > mailinglist]
>>
>> OK, moving the
> Then there is salsa... I have mixed feelings about it. On the one hand, it's
> this big beast with tons of javascript and apparently we are not even
> dog-fooding gitlab as packaged in Debian to overseves. I'd like our
> infrastructure to be based on the things we offer in our distro. And it's
Hi,
Quoting Wookey (2024-04-07 22:42:34)
> On 2024-04-07 16:04 +0200, Andreas Tille wrote:
> > Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> > > [Feel free to quote any part of this email which I wrote outside of this
> > > mailinglist]
> > OK, moving the discussion to
Good evening,
José Luis González wrote on 07/04/2024 at 20:59:53+0200:
> Hi all,
>
> Rene Engelhard seems to be a worse case even than Ricardo Mones. Take a
> look at my recent bug reports to libreoffice-writer and his replies.
Your attitude is not okay, be it in this mail or in the sylpheed
On 07/04/24 23:11, Bill Allombert wrote:
What is your opinion about pushing logtool to Salsa?
Not speaking for logtool obviously, but maintaining simple packages on salsa is
just useless bureaucracy.
As a contributor, having a package on salsa is extremely useful, far
from "useless".
By
201 - 300 of 172674 matches
Mail list logo
