Hi Otto,
On Tue, Aug 20, 2024 at 06:35:52PM -0700, Otto Kekäläinen wrote:
> In short:
> I would very much like to see all top-150 packages run Salsa CI at
> least once before being uploaded to unstable. What people think is a
> reasonable way to proceed to reach this goal?
>
>
> Background:
> We
Hi Johannes and Bastian,
On Tue, Aug 20, 2024 at 10:35:47AM +0200, Bastian Venthur wrote:
> On 20.08.24 07:55, Johannes Schauer Marin Rodrigues wrote:
> > Hi,
> [...]
> > if I remember correctly, a package can also become a key package by having a
> > high-enough popcon value. If that is correct,
On Fri, 2024-08-16 at 16:54 +0100, Colin Watson wrote:
> On Fri, Aug 16, 2024 at 05:21:38PM +0200, Philip Hands wrote:
> > I think it probably was just a coincidence, since it looks like the
> > change was made in order to fix #1064795 which was reported on
> > 25 Feb 2024.
>
> Ah, good to know, t
On 2024-08-21 19:11:40 -0400 (-0400), rsbec...@nexbridge.com wrote:
[...]
> On the other side (perhaps), git is increasingly being used in the
> Ops setting for DevOps and DevSecOps. Production configurations
> for high-value applications are moving to storing those
> configurations into git for tr
* rsbec...@nexbridge.com [240822 01:21]:
> >> Any feelings/objections/missed requirements?
> >
> >In the current DEP14/DEP18 discussions a lot of discussion was had about how
> >we
> >should represent Debian things in git; your mail also goes into this
> >direction.
> >
> >My *feeling* is we sho
On Wednesday, August 21, 2024 5:38 PM, Chris Hofstaedtler wrote:
>* Simon Richter [240820 09:11]:
>> One of the long-standing issues is that there are multiple ways Debian
>> packaging can be represented in a git tree, and none of them are optimal.
>[..]
>> A possible implementation would be a typ
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: ocaml-intrinsics-kernel
Version : 0.17.1
Upstream Contact: Jane Street developers
* URL : https://github.com/janestr
Chris Hofstaedtler writes:
> My *feeling* is we should do the opposite - that is, represent less
> Debian stuff in git, and especially do it in less Debian-specific
> ways. IOW, no git extensions, no setup with multiple branches that
> contain more or less unrelated things, etc.
+1
I think this
Hello Andrey,
On Wed, 21 Aug 2024 at 16:08, Andrey Rakhmatullin wrote:
> > I have also been wondering if we could take a different approach for
> > packaging libraries for language ecosystems that already have
> > packaging managers to play nicer with Debian packaging
> > maintainability. I find
Hi Salvo,
On Wed, 21 Aug 2024 at 16:19, Salvo Tomaselli wrote:
>
> > maintainability. I find myself when I need to use such libraries I
> > need to build my own bundle to support specific applications since
> > Debian packaged versions don't tend to work well with the application
> > (the same is
Hi Simon,
* Simon Richter [240820 09:11]:
> One of the long-standing issues is that there are multiple ways Debian
> packaging can be represented in a git tree, and none of them are optimal.
[..]
> A possible implementation would be a type of Git "user extension" object
> that contains
>
> - an
Stephen,
and everyone else who pointed out that coinstallability is a
non-issue - thanks!
About the additional work in fuse/fuse3, #918984 and #927291, I
wonder if they are relevant to the libfuse consumers. Anyway, if we
believe fuse3 works just fine with libfuse2-* consumers, then it
seems like
* Scott Kitterman [240820 14:35]:
> On August 20, 2024 12:16:47 PM UTC, Andrey Rakhmatullin
> wrote:
> >On Tue, Aug 20, 2024 at 12:12:33PM +, Scott Kitterman wrote:
> >> There are people doing this, we could use more, but it does
> >> happen. I've processed lots of these and it's virtually
On 21 August 2024 3:22:16 pm UTC, Nilesh Patra wrote:
>My last installation of Debian on a laptop was approximately 1.5 years ago and
>it was off by default. It asked me if I want to enable it or not.
>
>Did that change recently in D-I?
>
I don't think it did. I have had a bunch of reinstallation
Hi,
I believe at least some of these packages were probably packaged as
dependencies for packaging lazygit. I am not sure which all, but I remember
atleast gocui, pty and termbox-go to be needed by lazygit in one way or
another. There has been further work on packaging lazygit towards the end o
Noah wrote:
>On Tue, Aug 20, 2024 at 11:09:51AM +0200, Bastian Venthur wrote:
>> I think popcon does give a good approximation of how much percent of people
>> installed a certain package even if not everyone uses it, don't you agree?
>
>No, definitely not. There are hundreds of thousands of Debia
On Tue, Aug 20, 2024 at 11:09:51AM +0200, Bastian Venthur wrote:
> I think popcon does give a good approximation of how much percent of people
> installed a certain package even if not everyone uses it, don't you agree?
>
> Last time I installed Debian it was still enabled by default.
When was it
On Tue, Aug 20, 2024 at 11:09:51AM +0200, Bastian Venthur wrote:
> I think popcon does give a good approximation of how much percent of people
> installed a certain package even if not everyone uses it, don't you agree?
No, definitely not. There are hundreds of thousands of Debian systems
running
On Wed, Aug 21, 2024 at 03:39:11PM +0200, Héctor Orón Martínez wrote:
> I am surprised to not see more of those packages in the list, there
> are many packages in those ecosystems with popcon between 1-10 users.
popcon wasn't used when building this list though (even via the key
packages condition
Hello Helmut,
Thanks for starting this topic.
On Tue, 20 Aug 2024 at 07:29, Helmut Grohne wrote:
> golang-github-bsm-pool
> golang-github-coreos-go-tspi
> golang-github-crewjam-saml
> golang-github-form3tech-oss-jwt-go
> golang-github-go-redis-redis
> golang-github-jesseduffield-asciigraph
> go
Re: Simon Richter
> That is not a 32 bit bug, but an indication of something else being broken.
It is the same problem in the sense that 64-bit architectures are
fine, and something (probably in some autoconf script) is broken on
32-bit. The point here is that these are always weird bugs in weird
Hi Lukas,
On Wed, Aug 21, 2024 at 10:30:46AM +0200, Lukas Märdian wrote:
> This email was intended to first gauge opinions from networking maintainers,
> before pushing it out to debian-devel@l.d.o.. All the points still hold and
> are fine to be public. But let me at least add the preamble and re
On Wed, Aug 21, 2024 at 10:06:38AM +, Holger Levsen wrote:
> Hi,
>
> I also like us to remove more broken and unused packages from unstable.
>
> On Tue, Aug 20, 2024 at 11:20:10AM +0200, Lucas Nussbaum wrote:
> > Maybe we could also reduce the cost of removals for users and potential
> > new
Hi,
On 8/21/24 18:32, Christoph Berg wrote:
10:39:04 snprintf.c:409:1: error: conflicting types for ‘strchrnul’; have
‘const char *(const char *, int)’
10:39:04 409 | strchrnul(const char *s, int c)
10:39:04 | ^
10:39:04 In file included from snprintf.c:43:
10:39:04 /usr/includ
Hi,
I also like us to remove more broken and unused packages from unstable.
On Tue, Aug 20, 2024 at 11:20:10AM +0200, Lucas Nussbaum wrote:
> Maybe we could also reduce the cost of removals for users and potential
> new maintainers, by improving the information provided in various places
> on how
Helmut Grohne left as an exercise for the reader:
> notcurses
i need decide whether i'm putting out a new upstream release
with ffmpeg 7 support, or whether i ought patch it in debian
(thanks to sebastian ramacher for originally bringing the issue
to my attention). i suppose i can do the latter no
Re: To debian-devel
> it has probably been a decade since I've last seen a PostgreSQL
> installation in the wild on a 32-bit machine. PostgreSQL itself works
> fine there, but more and more extensions are not compatible anymore,
> either deliberately, or (more common) because of subtle bugs in prin
On Tue, Aug 20, 2024 at 10:44:30PM -0700, Otto Kekäläinen wrote:
> > Something that many developers are probably not aware of is that they
> > can enable CI for a repository with no code changes at all and with
> > a single command:
> >
> > salsa update_projects $NAMESPACE/$PROJECT \
> > --jobs
On Tue, Aug 20, 2024 at 06:35:52PM -0700, Otto Kekäläinen wrote:
> Hi!
>
> In short:
> I would very much like to see all top-150 packages run Salsa CI at
> least once before being uploaded to unstable. What people think is a
> reasonable way to proceed to reach this goal?
>
>
> Background:
> We
Hi Daniel,
On 20.08.24 16:25, Daniel Gröber wrote:
Hi Lukas,
CCing d-devel,
This email was intended to first gauge opinions from networking maintainers,
before pushing it out to debian-devel@l.d.o.. All the points still hold and
are fine to be public. But let me at least add the preamble and r
On Tue, Aug 20, 2024 at 10:44:30PM -0700, Otto Kekäläinen wrote:
> > Advertise widely and frequently that there is a pool of people which is
> > happy to help investigating the failed CI jobs.
> > Then start personally advocating the benefits of CI to the maintainers
> > of these packages: I expect
31 matches
Mail list logo
