On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> > My concern about Gitlab is not its *additions* to existing services, but
> > its *duplications* of core services already in Debian.
>
> I agree, that's the key problem.
>
> The Debian archive itself is a VCS, so git-maintained pac
On Tue, May 21, 2024 at 12:32:52AM +0200, Bernd Zeimetz wrote:
> > > All these things should make it much more easy for other people or
> > > automated tools to send merge requests or keep maintaining a
> > > package in
> > > case the original maintainer becomes MIA.
> >
> >
> > Mandating a speci
On Mon, May 20, 2024 at 07:16:54PM -0300, Leandro Cunha wrote:
> > > > which is good news. The end of support for 32 bits will not
> > > > affect the lives of almost anyone who has machines purchased after
> > > > 2011 and who bought them after that
> > >
> > > Does this also mean he support for ar
Simon Richter writes:
> A better approach would not treat Debian metadata as git data. Even the
> most vocal advocate of switching everything to Salsa writes in his MR
> that the changelog should not be touched in a commit, because it creates
> conflicts, and instead a manual step will need to be
Hi,
On 5/21/24 10:43, Luca Boccassi wrote:
The ecosystem, however, does not support our workflows, and adapting it
to do that is even more effort than maintaining our own tools. [...]
That's a problem of our workflows, which are horrible. The solution is
not to double down on them.
Our wor
Hi Simon!
> > A better approach would not treat Debian metadata as git data. Even the
> > most vocal advocate of switching everything to Salsa writes in his MR
> > that the changelog should not be touched in a commit, because it creates
> > conflicts, and instead a manual step will need to be perf
Em 20/05/2024 22:53, xiao sheng wen(肖盛文) escreveu:
Hi,
I had report bug #1070830[1], hardinfo package change upstream repo
to hardinfo2
also is a better way.
IMHO, hardinfo2 only is the new version of hardinfo, it's not
necessary to ITP a new
hardinfo2 src package in Debian. The new versi
Hi,
I had report bug #1070830[1], hardinfo package change upstream repo
to hardinfo2
also is a better way.
IMHO, hardinfo2 only is the new version of hardinfo, it's not necessary
to ITP a new
hardinfo2 src package in Debian. The new version has a new binary
package named hardinfo2
is no p
On Tue, 21 May 2024 at 02:08, Simon Richter wrote:
>
> Hi,
>
> On 5/21/24 07:43, Bernd Zeimetz wrote:
>
> > Also its a gitlab instance. There are all kinds of documentation,
> > tutorials, videos and software for/about gitlab, including lots of
> > beginner friendly options. There is a whole ecosy
Hi,
On 5/21/24 07:43, Bernd Zeimetz wrote:
Also its a gitlab instance. There are all kinds of documentation,
tutorials, videos and software for/about gitlab, including lots of
beginner friendly options. There is a whole ecosystem around gitlab, it
does not depend on a few (two?) developers.
T
On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
>
> When a change leads to a RC bug a month or three after having be
> part of a package, fixing the problem falls on the maintainer and not
> on the change author. Even correct changes can trigger latent bugs
> in software.
Yet another re
On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues
wrote:
> 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
On Tue, 2024-04-09 at 20:51 +0200, Gioele Barabucci wrote:
>
> Salsa is a forge, i.e. a combination of a Web interface, a git
> server,
> and a set of integrated features. In comparison to dgit, salsa has,
> like
> most forges:
>
> []
Also its a gitlab instance. There are all kinds of docu
On Mon, 2024-05-20 at 20:47 +, Scott Kitterman wrote:
> >
> > All these things should make it much more easy for other people or
> > automated tools to send merge requests or keep maintaining a
> > package in
> > case the original maintainer becomes MIA.
>
>
> Mandating a specific git layout
On Mon, May 20, 2024 at 6:11 PM Andrey Rakhmatullin wrote:
>
> On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote:
> > > which is good news. The end of support for 32 bits will not
> > > affect the lives of almost anyone who has machines purchased after
> > > 2011 and who bought them a
On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote:
> > which is good news. The end of support for 32 bits will not
> > affect the lives of almost anyone who has machines purchased after
> > 2011 and who bought them after that
>
> Does this also mean he support for armhf will be droppe
Hi all
On 20/05/2024 22:27, Leandro Cunha wrote:
which is good news. The end of support for 32 bits will not
affect the lives of almost anyone who has machines purchased after
2011 and who bought them after that
Does this also mean he support for armhf will be dropped ?
Cheers
William
Ope
On May 20, 2024 7:54:46 PM UTC, Bernd Zeimetz wrote:
>Hi,
>
>On Sun, 2024-04-07 at 16:44 +0200, Andreas Tille wrote:
>>
>> Do you think that mandating Salsa is a sensible step in this
>> direction?
>
>
>Absolutely.
>
>Also I think requiring a common git layout and the usage of recent
>versions
Hello,
On Mon, May 20, 2024 at 5:15 PM Paul Gevers wrote:
>
> Hi,
>
> On 20-05-2024 4:50 p.m., Ben Hutchings wrote:
> > There is a tension here between the interests of (a) users that want to
> > run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to
> > keep using 32-bit CPUs.
Package: wnpp
Severity: wishlist
Owner: Jérémy Lal
X-Debbugs-Cc: debian-devel@lists.debian.org, The Debian Lua Team
* Package name: lua-vips
Version : 1.1.11
Upstream Contact: John Cupitt
* URL : https://github.com/libvips/lua-vips
* License : Expat
Progra
Hi,
On 20-05-2024 4:50 p.m., Ben Hutchings wrote:
There is a tension here between the interests of (a) users that want to
run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to
keep using 32-bit CPUs. If i386 is meant for group (a) then the
baseline should be raised to include
Hi!
> > If I am successful, then lintian can specialize its efforts into issues only
> > visible in packaged artifacts and thereby reduce it scope a bit.
>
> Perfect. I'd love to have some policy checking at "the right point in
> time". I'd love to support this but as far as I understand even yo
Hi,
On Sun, 2024-04-07 at 16:44 +0200, Andreas Tille wrote:
>
> Do you think that mandating Salsa is a sensible step in this
> direction?
Absolutely.
Also I think requiring a common git layout and the usage of recent
versions of dh should be required. Using merge requests instead of
sending pa
Package: wnpp
Severity: wishlist
Owner: Matthias Geiger
X-Debbugs-Cc: debian-devel@lists.debian.org, team+...@tracker.debian.org,
werdah...@riseup.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: vim-link-vim
Version : 1.0.3+git20240514
Upstream Contact: qadze
On Mon, 20 May 2024 00:30:13 +0200, Thomas Goirand wrote:
> For example, *I* don't care at all about 32 bits arch, and would prefer if
> these were to be sent to ports.debian.org. I really mean *all* 32 bits arch,
> including armhf for example.
I agree with you.
No one really needs armel(armv5
Package: wnpp
Severity: wishlist
Owner: Lucas Castro
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: hardinfo2
Version : 2.1.2
Upstream Contact: Name
* URL : https://hardinfo2.org/
* License : GPL-2
Programming Lang: C
Description : Hardinf
On Mon, 2024-05-20 at 13:39 +0200, Ansgar 🙀 wrote:
> Hi,
>
> On Sun, 2024-05-19 at 10:30 -0500, r...@neoquasar.org wrote:
> > I have an N270 system I can use to contribute, if someone is willing
> > to explain what I need to do to make it useful.
> >
> > From: Victor Gamper
> > Sent: Sunday, Ma
Package: wnpp
Severity: wishlist
Owner: Rony Joao de Sousa
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: paping
Version : 1.6.0
Upstream Contact: Mike Lovell
* URL : https://github.com/ronyjdesousa/paping
* License : MIT
Programming Lang: C++
Hi,
On Sun, 2024-05-19 at 10:30 -0500, r...@neoquasar.org wrote:
> I have an N270 system I can use to contribute, if someone is willing
> to explain what I need to do to make it useful.
>
> From: Victor Gamper
> Sent: Sunday, May 19, 2024 08:03
> To: debian-devel@lists.debian.org
> Subject: Re:
On Sun, May 19, 2024 at 08:38:58PM -0700, Don Armstrong wrote:
> On Sun, 19 May 2024, Bill Allombert wrote:
> > Also debbugs is a special case:
> > The debbugs Debian package (as opposed to the debbugs software) have never
> > been
> > really maintained. I am actually one of the very few users of
Package: wnpp
Severity: wishlist
Owner: Edward Betts
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: sensor-state-data
Version : 2.18.0
Upstream Author : J. Nick Koston
* URL : https://github.com/bluetooth-devices/sensor-sta
Package: wnpp
Severity: wishlist
Owner: Edward Betts
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: python-srptools
Version : 1.0.1
Upstream Author : Igor `idle sign` Starikov
* URL : https://github.com/idlesign/srptools
*
Package: wnpp
Severity: wishlist
Owner: Edward Betts
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: unicode-rbnf
Version : 1.1.0
Upstream Author : Michael Hansen
* URL : https://github.com/rhasspy/unicode-rbnf
* License
"Theodore Ts'o" writes:
> On Sun, May 12, 2024 at 04:27:06PM +0200, Simon Josefsson wrote:
>> Going into detail, you use 'gzip -9n' but I use git-archive defaults
>> which is the same as -n aka --no-name. I agree adding -9 aka --best is
>> an improvement. Gnulib's maint.mk also add --rsyncable,
> > Ideally debbugs should be made non-native so that some else could
> > maintain the Debian package.
>
> I'm happy to review patches that get the 2.6 branch of debbugs in shape
> where it can be released into Debian again if someone wants to take that
> effort. I've just assumed that anyone using
On Sun, 19 May 2024 20:19:12 +0200, Ben Hutchings
wrote:
>The plan is to keep i386 as a partial architecture that can be used as
>a "foreign architecture" on systems where amd64 is the main
>architecture.
Many people using ancient hardware such as a T60 thinkpad say that's
not enough for them. I
36 matches
Mail list logo
