Package: wnpp
Severity: wishlist
Owner: Shengqi Chen
X-Debbugs-Cc: debian-devel@lists.debian.org, ha...@debian.org,
debian-scie...@lists.debian.org
* Package name: highs
Version : 1.9.0
* URL : https://www.highs.dev/
* License : MIT
Programming Lang: C++
Des
Hi,
> > > This change basically adds the recommendation to use "upstreamvcs" as the
> > > name of the "git remote" to access the upstream repository and it also
> > > documents the possibility to merge the upstream commits in the
> > > "upstream/latest" branch (as proposed by gbp import-orig
> > >
Hi,
> > > While I'd love to see all packages on Salsa
> >
> > I think that being able to host the primary git repository of packages
> > elsewhere is a freedom worth maintaining for many reasons.
>
> No, I don't think this is a good idea, and at my first thought, I
> personally don't see any pract
> That's fair. I maintain a package of a project where I eventually
> moved the upstream codebase into revision control but have been too
> lazy/distracted to do the same for the debian directory (which I
> realistically only update once every year or two). I'm committed to
> importing that into Sa
Hi Andreas
Lets think about some better fine tuning. "NOT LIKE '%salsa%'" might
catch also Vcs URLs that are intentionally somewhere else. While I'd
love to see all packages on Salsa, it might be sensible to start with
packages that are unintentionally not in Salsa so
udd=> SELECT COUNT(DISTI
Wouter, thank you so much for this response. your message has motivated me to
change adequate to target gccgo (rather than golang-go, which is a couple of
years ahead), to extend the availability of adequate to more ports
On Wed Dec 18, 2024 at 9:34 PM CET, Wouter Verhelst wrote:
> Hi,
>
> On Wed,
On Tue, Jan 07, 2025 at 11:21:36PM +0100, tho...@goirand.fr wrote:
> > I think that being able to host the primary git repository of packages
> > elsewhere is a freedom worth maintaining for many reasons.
same here.
> I don't think we should continue to allow the "freedom" to be annoying for
On 2025-01-07 23:21:36 +0100 (+0100), tho...@goirand.fr wrote:
[...]
> I don't think we should continue to allow the "freedom" to be
> annoying for every other contributors. Even if there may be some
> "technical excuses" to do so.
That's fair. I maintain a package of a project where I eventually
On Fri Dec 27, 2024 at 10:49 PM CET, Serafeim (Serafi) Zanikolas wrote:
> hi Jonathan,
>
> On Thu Dec 12, 2024 at 3:36 PM CET, Jonathan Dowland wrote:
[..]
> > "likely in many ports too" is dancing around the fact that it *doesn't*
> > run on at least one port, hence Holger's complaint.
>
> which
On Jan 7, 2025 21:25, Julien Plissonneau Duquène wrote:
> I think that being able to host the primary git repository of packages
> elsewhere is a freedom worth maintaining for many reasons.
I don't think we should continue to allow the "freedom" to be annoying for
every other contributors
On 2025-01-07 21:24:54, Julien Plissonneau Duquène wrote:
> Le 2025-01-07 20:03, Andreas Tille a écrit :
> > While I'd love to see all packages on Salsa
>
> I think that being able to host the primary git repository of packages
> elsewhere is a freedom worth maintaining for many reasons.
No, I do
On Tue, Jan 07, 2025 at 09:24:54PM +0100, Julien Plissonneau Duquène wrote:
> Le 2025-01-07 20:03, Andreas Tille a écrit :
> > While I'd love to see all packages on Salsa
>
> I think that being able to host the primary git repository of packages
> elsewhere is a freedom worth maintaining for many
nick black writes:
> later that year, zig changed the way it bootstraps [3]. there was
> already a "zig-bootstrap" repository and "zig" repository, both of which
> are released together. the relevant elements: "zig-bootstrap" now ships
> with a binary WASM file (zig1.wasm), which is converted to
Le 2025-01-07 20:03, Andreas Tille a écrit :
While I'd love to see all packages on Salsa
I think that being able to host the primary git repository of packages
elsewhere is a freedom worth maintaining for many reasons.
What the Debian Project could (and probably should) do in these cases is
Andreas Metzler writes:
> On 2025-01-07 Simon Josefsson wrote:
> [...]
>
>> I believe this would be good, I frequently run into GnuPG bugs in the
>> 2.2.x branch that was fixed years ago in 2.4 and today I mostly these on
>> Debian because others moved on to 2.4.x. Andreas, can you give a
>> cu
Package: wnpp
Severity: wishlist
Owner: Edward Betts
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: gdown
Version : 5.2.0
Upstream Author : Kentaro Wada
* URL : https://github.com/wkentaro/gdown
* License : MIT
Pro
Am Tue, Jan 07, 2025 at 10:46:25AM +1100 schrieb Stuart Prescott:
> Without seeking to rain on the parade, that query is only the packages that
> list a non-salsa VCS. That's not counting the packages that don't list a VCS
> at all and therefore are also maintained outside salsa:
>
> udd=> SELECT
nick black left as an exercise for the reader:
> this wasm file is, again, distributed with the zig-bootstrap and zig sources.
> it is a binary and knocks us out of main. this file can be recreated, using
> sources from within the zig repository, with a working zig. but even the
> "zig-bootstrap" s
Current Ubuntu 24.04 LTS also uses GnuPG 2.4 and probably has a similar
set of patches.
Regards
signature.asc
Description: This is a digitally signed message part
previous efforts have been made to package the zig programming language [0].
the most recent release of the zig programming language was 0.13.0 [1]
on 2024-06-07. bug #1012286 declares an ITP for zig 0.9.1 [2], but the work
there seems to have trailed off in the 0.10 era. jonathan carter started
wo
Julien Plissonneau Duquène writes:
>
> [..snip..]
>
> Could you please give us a few examples of projects where that already
> works out-of-the-box, ie the package is built and uploaded to the
> archive exactly as provided by upstream, debian/changelog and all?
>
I'm not Marco, but I happen to
On 2025-01-07 Simon Josefsson wrote:
[...]
> I believe this would be good, I frequently run into GnuPG bugs in the
> 2.2.x branch that was fixed years ago in 2.4 and today I mostly these on
> Debian because others moved on to 2.4.x. Andreas, can you give a
> current status of pending issues for
Package: wnpp
Severity: wishlist
Owner: Thomas Ward
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name : repolib
Version : 2.0.0
Upstream Contact: Ian Santopietro
* URL : https://github.com/pop-os/repolib
* License : GPL 3.0 and LGPL 3.0
Programming
Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris
X-Debbugs-Cc: debian-devel@lists.debian.org, aferra...@debian.org,
debian-on-mobile-maintain...@alioth-lists.debian.net
* Package name: libmegapixels
Version : 0.2.0
Upstream Contact: Martijn Braam
* URL : https
Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris
X-Debbugs-Cc: debian-devel@lists.debian.org, aferra...@debian.org,
debian-on-mobile-maintain...@alioth-lists.debian.net
* Package name: libdng
Version : 0.2.1
Upstream Contact: Martijn Braam
* URL : https://gitl
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org
* Package name: scifem
Version : 0.3.0
Upstream Contact: Henrik Finsberg
* URL : https://scientificcomputing.github.io/scifem
* License
Frank Guthausen writes:
> On Sat, 04 Jan 2025 08:42:10 +
> Stephan Verbücheln wrote:
>
>> Please note that GnuPG 2.2 is also end of life now.
>>
>> https://gnupg.org/download/index.html
>
> GnuPG 2.4.7 is in experimental[1] but neither yet in sid[2] or trixie[3]
> (where it is version 2.2.4
On Sat, 04 Jan 2025 08:42:10 +
Stephan Verbücheln wrote:
> Please note that GnuPG 2.2 is also end of life now.
>
> https://gnupg.org/download/index.html
GnuPG 2.4.7 is in experimental[1] but neither yet in sid[2] or trixie[3]
(where it is version 2.2.45-2 in both repositories). The trixie f
On Jan 07, Julien Plissonneau Duquène wrote:
> You are free to join or discuss it here. That DEP has been online for some
> years now, it's not exactly happening in the hiding.
Nobody mentioned hiding anything, but it's still just a few people
chatting in a gitlab issue.
> > WTF? I say instead
Le 2025-01-07 12:59, Andrey Rakhmatullin a écrit :
Tags in git are not prefixed with the remote name or anything else. A
tag
named upstream/1.2.3 is never from the upstream. A tag named 1.2.3
should
always be from the upstream.
Branches, on the other hand, indeed clash between "upstream/foo br
On Tue, Jan 07, 2025 at 12:46:46PM +0100, Julien Plissonneau Duquène wrote:
> > > This change basically adds the recommendation to use "upstreamvcs"
> > > as the
> > > name of the "git remote" to access the upstream repository and it also
> > Like many others, this looks like a gratuitous change fo
Le 2025-01-07 11:29, Marco d'Itri a écrit :
On Jan 07, Raphael Hertzog wrote:
This change basically adds the recommendation to use "upstreamvcs" as
the
name of the "git remote" to access the upstream repository and it also
Like many others, this looks like a gratuitous change for change's
sa
On 07/01/25 at 11:53 +0100, Chris Hofstaedtler wrote:
> * Raphael Hertzog [250107 08:39]:
> > 1/ https://salsa.debian.org/dep-team/deps/-/merge_requests/9
> > (see mr9.patch attached if you don't want to look up on the web)
> >
> > We had a couple of revisions already and it seems fine to me to m
* Raphael Hertzog [250107 08:39]:
> 1/ https://salsa.debian.org/dep-team/deps/-/merge_requests/9
> (see mr9.patch attached if you don't want to look up on the web)
>
> We had a couple of revisions already and it seems fine to me to merge
> this, if anyone has valid objections (i.e. with good rati
On Jan 07, Raphael Hertzog wrote:
> This change basically adds the recommendation to use "upstreamvcs" as the
> name of the "git remote" to access the upstream repository and it also
Like many others, this looks like a gratuitous change for change's sake.
Countless packages have been using "upstr
On 1/6/25 10:11 PM, Andreas Tille wrote:
Personally, my main challenge is having to focus on the same issue
twice, with a minimum delay of 21 days in between. For example, I
encountered an ITS bug that had been lingering in the BTS for over a
year. The waiting period is entirely reasonable under
Le 2025-01-07 08:38, Raphael Hertzog a écrit :
2/ https://salsa.debian.org/dep-team/deps/-/merge_requests/16
To expand a bit on this, proposals so far for naming versioned branches
are:
1. // e.g. debian/6.12/trixie which (I think)
matches what the kernel team is already doing [1]
2. // e.g
37 matches
Mail list logo
