Hello,
On Thu 18 Apr 2024 at 09:44pm +02, Jonas Smedegaard wrote:
> I am unaware if I am alone in maintaining Haskell packages outside of
> the team giant-git-repo thingy.
I wouldn't maintain libraries outside of the monorepo but typically
programs are maintained outside of it.
I maintain
ma 11. maalisk. 2024 klo 7.02 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti:
> > On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> > > I hereby propose bin:dhcpcd-base:
> > >
> > > 1) already
On Sun, Apr 28, 2024 at 02:28:30PM +0200, Paul Gevers wrote:
> > Can you please look at libproxy<->glib-networking? libproxy excuses show
> > glib-networking tests failing, but they are working in sid.
>
> And that's not missing a versioned Depends and/or Breaks? I.e. this is a
> test only
Hi,
On 27-04-2024 7:52 p.m., Andrey Rakhmatullin wrote:
Can you please look at libproxy<->glib-networking? libproxy excuses show
glib-networking tests failing, but they are working in sid.
And that's not missing a versioned Depends and/or Breaks? I.e. this is a
test only failure?
Paul
Hi,
Quoting Adam D. Barratt (2024-04-28 01:09:28)
> > Seeing mirror functionality being uncertain, I have started to track
> > archive.debian.org as a Git-LFS repository on gitlab.com.
> Please don't. If there's a problem with debian.org services then we should
> fix that, not start adding more
On Sun, 2024-04-28 at 00:09 +0100, Adam D. Barratt wrote:
> [As a general note, the primary contact point for possible mirror
> issues is mirrors@d.o, not debian-devel]
>
> On Sat, 2024-04-27 at 12:16 +0200, Simon Josefsson wrote:
>
>
[...]
> > Further it seems mirrors are out of sync. I
[As a general note, the primary contact point for possible mirror
issues is mirrors@d.o, not debian-devel]
On Sat, 2024-04-27 at 12:16 +0200, Simon Josefsson wrote:
> it should be possible to reach archive.debian.org via rsync, however
> this fails for me. Is this intentional, or can this be
On Wed, Apr 24, 2024 at 07:38:42PM +0200, Paul Gevers wrote:
> Hi,
>
> On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
> > What to do with autopkgtests that fail in testing because of problems with
> > packages in testing that are fixed in unstable, e.g. the autopkgtest for
> >
On Sat, Apr 27, 2024 at 12:16:04PM +0200, Simon Josefsson wrote:
> Hi
>
> According to the mirror list
>
> https://www.debian.org/distrib/archive
>
> it should be possible to reach archive.debian.org via rsync, however
> this fails for me. Is this intentional, or can this be fixed?
>
Chris Hofstaedtler writes:
> you are probably aware of the time_t-64bit migration :-)
> However, this does not magically transition all data formats to 64bit
> times. One such instance is the set of utmp/wtmp and lastlog files.
>
> Thorsten Kukuk and others have been working on replacements for
On Fri, 26 Apr 2024 at 12:30, Chris Hofstaedtler wrote:
>
> Fellow Developers,
>
> you are probably aware of the time_t-64bit migration :-)
> However, this does not magically transition all data formats to 64bit
> times. One such instance is the set of utmp/wtmp and lastlog files.
>
> Thorsten
> "Chris" == Chris Hofstaedtler writes:
Chris> Fellow Developers,
Chris> you are probably aware of the time_t-64bit migration :-)
Chris> However, this does not magically transition all data formats to 64bit
Chris> times. One such instance is the set of utmp/wtmp and lastlog
Hi,
On 24-04-2024 7:42 p.m., Jérémy Lal wrote:
Inform the Release Team and we can either schedule the combination
manually, add a hint or both.
Isn't it processed automatically ? What needs manual intervention and
what doesn't ?
Well, the migration software *tries* to figure out
Hi,
On 24-04-2024 7:38 p.m., Paul Gevers wrote:
On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
What to do with autopkgtests that fail in testing because of problems
with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
Inform the
Le mer. 24 avr. 2024 à 19:39, Paul Gevers a écrit :
> Hi,
>
> On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
> > What to do with autopkgtests that fail in testing because of problems
> with
> > packages in testing that are fixed in unstable, e.g. the autopkgtest for
> >
Hi,
On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
What to do with autopkgtests that fail in testing because of problems with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
Inform the Release Team and we can either schedule the
On Wed, Apr 24, 2024 at 08:51:48AM +0200, Sebastian Ramacher wrote:
> If you wonder how you are able to help with the migration, here are
> some things to do:
> * Fix FTBFS bugs
> * Check the status of autopkgtests [1] and report or fix any issues
> related to failing tests.
> * Check if
On Wed, Apr 24, 2024 at 9:42 AM Andreas Tille wrote:
> Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands:
> > >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
> >
> > Might I suggest that the link goes the other way, so that the symlink
> > lives in /usr/bin? That way the
Hi,
Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands:
> >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
>
> Might I suggest that the link goes the other way, so that the symlink
> lives in /usr/bin? That way the existence of the lib directory is
> somewhat self-documenting.
Hi,
dpkg and gcc with t64 enabled migrated to trixie last night. The other
packages will slowly migrate as we fix the remaining blockers
(autopkgtest regressions, FTBFS bugs, etc). Be aware that temporary
removals from trixie may occur to get packages (especially key packages)
unstuck as we work
On Fri, Apr 19, 2024 at 07:59:19AM +0100, Sean Whitton wrote:
> 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
On 22/4/24 21:29, Steve Langasek wrote:
On Mon, Apr 22, 2024 at 05:11:39PM +0200, José Luis González González wrote:
I sent 5 minutes ago an email to "Plaza de Castilla *courts*" setting
^^^
BS. It just doesn't work like this. A regular citizen can't communicate
On Mon, Apr 22, 2024 at 05:11:39PM +0200, José Luis González González wrote:
> I sent 5 minutes ago an email to "Plaza de Castilla *courts*" setting
> it crystal clear that it was a long time ago the lawsuit to Universitat
> Oberta de Catalunya and British Council had to be solved.
>
> "Kinda or
Am 21.04.2024 um 18:31 schrieb Mathias Gibbens:
Currently, Midnight Commander is packaged for Debian as `mc`. I am
looking at packaging the MinIO Client (needed for a future release of
Incus), which also unfortunately names its binary `mc`. MinIO upstream
has been pretty clear that they don't
* Simon McVittie [240422 05:02]:
> On Mon, 22 Apr 2024 at 09:44:12 +0200, Simon Josefsson wrote:
> > Philip Hands writes:
> > > Might I suggest that the link goes the other way, so that the symlink
> > > lives in /usr/bin? That way the existence of the lib directory is
> > > somewhat
On Sun Apr 21, 2024 at 5:37 PM BST, Marco d'Itri wrote:
> Go for it, I think that there is no good solution for this case.
> Everybody who cares then will manually create a mc -> mcli symlink.
Indeed, they will: so I would suggest that the chosen binary name for
minio-client should *not* be mcli,
On Mon, 22 Apr 2024 at 09:44:12 +0200, Simon Josefsson wrote:
> Philip Hands writes:
> > Might I suggest that the link goes the other way, so that the symlink
> > lives in /usr/bin? That way the existence of the lib directory is
> > somewhat self-documenting.
Having the real executable in
Philip Hands writes:
> Mathias Gibbens writes:
>
>> On Sun, 2024-04-21 at 18:47 +0200, Simon Josefsson wrote:
> ...
>>> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
>
> Might I suggest that the link goes the other way, so that the symlink
> lives in /usr/bin? That way the existence of the
Mathias Gibbens writes:
> On Sun, 2024-04-21 at 18:47 +0200, Simon Josefsson wrote:
...
>> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
Might I suggest that the link goes the other way, so that the symlink
lives in /usr/bin? That way the existence of the lib directory is
somewhat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 22 Apr 2024 05:42:43 +
Source: python-re-assert
Built-For-Profiles: noudeb
Architecture: source
Version: 1.1.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team
Changed-By: Jeroen Ploemen
Changes
I don't want to exacerbate the off-topic-message problem, but I'm hoping
that by saying the following I may perhaps be able to prevent further
messages to the list about this.
First, can we please be very careful, when we're throwing around talk
about banning people from lists, to make it
Could this guy be blacklisted from Debian lists, please?
Am 21. April 2024 22:23:10 MESZ schrieb Jose Luis Alarcon Sanchez
:
>On abr. 21 2024, at 10:02 pm, José Luis González González
> wrote:
>
>> En mi teléfono móvil Samsung Galaxy A13 no puedo borrar ahora el
>> idioma Alemán del telclado y
On abr. 21 2024, at 10:02 pm, José Luis González González
wrote:
> En mi teléfono móvil Samsung Galaxy A13 no puedo borrar ahora el
> idioma Alemán del telclado y la corrección ortográfica.
>
Y que puede tener esto que ver con Debian o con Linux???. Llévalo a un
punto de Servicio Técnico de
And by the way, I was also unable to subscribe to debian-users-spanish either.
I know the emails reach, in any case.
On Sun, 2024-04-21 at 18:47 +0200, Simon Josefsson wrote:
> Marco d'Itri writes:
>
> > On Apr 21, Mathias Gibbens wrote:
> >
> > > While that might work for them, it obviously doesn't at a higher
> > > packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
> > > for any
Marco d'Itri writes:
> On Apr 21, Mathias Gibbens wrote:
>
>> While that might work for them, it obviously doesn't at a higher
>> packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
>> for any comments or suggestions on my plan for packaging the MinIO
>> Client. Following
On Apr 21, Mathias Gibbens wrote:
> While that might work for them, it obviously doesn't at a higher
> packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
> for any comments or suggestions on my plan for packaging the MinIO
> Client. Following what several other
Hi Andreas,
please stop reopening the time_t bugs where transitions are staged in
experimental. When we eventually start those transitions, they do not
need to change the package name again as they will enter unstable with a
new SONAME and built with the 64 bit time_t ABI.
Cheers
--
Sebastian
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 14 Apr 2024 18:45:38 +
Source: python-re-assert
Binary: python3-re-assert
Architecture: source all
Version: 1.1.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team
Changed-By: Dale Richards
Lists updated to omit packages not in testing:
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
On 18.04.24 21:22, Sebastian Ramacher wrote:
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.
All missing bugs about wrong deps are now filed.
--
WBR, wRAR
signature.asc
Description: PGP signature
Hi
thanks for checking all the packages and filing bugs!
On 2024-04-20 00:43:30 +0500, Andrey Rakhmatullin wrote:
> 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
Hi Andreas
On 2024-04-19 10:49:15 +0200, Andreas Tille wrote:
> I've spotted these Debian Med packages.
>
> > gentle
gentle required a rebuild for wxwidgets3.2 on mips64el. Done
> > jellyfish
The t64 changes were reverted. crac needs to rebuilt for this change so
that libjellyfish-2.0-2t64
On 2024-04-19 10:34:45 +0200, Simon Josefsson wrote:
> 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
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
1 - 100 of 172519 matches
Mail list logo
