Hi,
since feedback was requested the normally unwanted +1 ...
Am Sun, Dec 15, 2024 at 09:29:26AM + schrieb Holger Levsen:
> On Sun, Dec 15, 2024 at 09:50:17AM +0100, Daniel Baumann wrote:
> > both sound good (dropping mandatory priority is nice and consistent,
> > fixing unknown section behav
Hi Sean,
Am Sat, Dec 21, 2024 at 10:11:55AM +0800 schrieb Sean Whitton:
>
> We don't need new vocabulary and a new mailing list for this.
> Let's use:
>
> Maintainer: Debian developers
>
> Maintainer: Debian contributors
>
> (lowercase 'd' deliberate)
I really like this suggestion i
On 21/12/24 03:11, Sean Whitton wrote:
an alternative that I was thinking of, is making this "everybody is onboard"
policy more explicit by having a special email to use for the Maintainer
field. For example:
Maintainer: Debian community
The stewards of the package could be listed as Uplo
On 2024-12-19 Andrey Rakhmatullin wrote:
> On Thu, Dec 19, 2024 at 04:58:06PM +0100, Samuel Thibault wrote:
>>> And it is actively harmful as if one edits the example configuration to
>>> have a useful configuration as dpkg will start annoying admins with
>>> "the example configuration has changed
Hello,
On Thu 12 Dec 2024 at 08:05pm -08, Don Armstrong wrote:
> That said, the critique is received, and I've been very, very slowly
> working on rewriting the entire system to address some of these issues.
> [Being a parent has made my Debian time very precious, however, so
> keeping things run
Hello,
On Thu 12 Dec 2024 at 08:57am +01, Matthias Urlichs wrote:
> On 04.12.24 18:08, Andreas Tille wrote:
>> in the
>> absence of a debian/dont_touch_my_package file, any Debian Developer is
>> permitted to upload the package.
>
> I like this idea.
>
> The next step: agree on a "standard" Debia
Hello,
On Thu 12 Dec 2024 at 10:43am +01, Gioele Barabucci wrote:
> an alternative that I was thinking of, is making this "everybody is onboard"
> policy more explicit by having a special email to use for the Maintainer
> field. For example:
>
> Maintainer: Debian community
>
> The stewards
Hello,
On Thu 12 Dec 2024 at 10:30pm +09, Charles Plessy wrote:
> - at work, not using LLMs to write code is like refusing to wear shoes
>at the Olympics because Greeks did not and saying that shoes pollute
>and the run is no less fun when everybody agreed to be bare feet.
>True, but
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: python-rfc8785
Version : 0.1.4
Upstream Author : William Woodruff, Anders Rundgren, et al
* URL : https://github.com/trai
Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias
X-Debbugs-Cc: debian-devel@lists.debian.org, eam...@debian.org
* Package name: audioop-lts
Version : 0.2.1
Upstream Contact: Alex Nørgaard
* URL : https://github.com/AbstractUmbra/audioop
* License : PSF-2
Russ Allbery wrote:
> And this is the root of the problem: you want one thing for understandable
> reasons, and other people, like myself, would prefer the opposite behavior
> of having /etc empty by default for different understandable reasons. We
> both understand the other's point of view and si
Package: wnpp
Severity: wishlist
Owner: Märt Põder
X-Debbugs-Cc: debian-devel@lists.debian.org, tr...@infoaed.ee
* Package name: nautilus-compare
Version : 1.0.2
Upstream Contact: Märt Põder
* URL : https://launchpad.net/nautilus-compare
* License : GPL-3+
P
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: python-sigstore-rekor-types
Version : 0.0.18
Upstream Author : William Woodruff, et al
* URL : https://github.com/trailof
On Fri, 20 Dec 2024 11:50:57 +0100, Samuel Thibault
wrote:
>Josh Triplett, le ven. 20 déc. 2024 02:05:30 -0800, a ecrit:
>> I'm talking about the "empty /etc" model here, which is why I'm trying
>> to find a solution so that people who *want* the file-full-of-comments
>> have it, without installin
Samuel Thibault writes:
> It seems way more often to me that I want to easily inspect/modify/amend
> the configuration in /etc (without having to look whatever other place
> to find out about the default configuration) than checking what changes
> I have made to /etc which I may not want any more
Hi Enrico,
* Enrico Zini [2024-12-20 19:29]:
* Is there a way to tell cmake to build the two things together, or to
point at the build dir of the first one to build the second one,
without installing it first?
I had a similar problem with the ros- packages and solved it with a top
level
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: python-grpclib
Version : 2.0.0b7
Upstream Author : Vladimir Magamedov, et al
* URL : https://github.com/vmagamedov/grpcli
Hello,
I'm trying to make a Debian package out of
https://gitlab.eumetsat.int/open-source/data-tailor-plugins/fcidecomp
I managed to build it this way:
$ cd src/fcidecomp
$ # Build and install fcicomp-jpegls first
$ rm -r build/fcicomp-jpegls/
$ gen/build.sh fcicomp-jpegls/ release
$ # fcicom
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: python-betterproto
Version : 2.0.0b7
Upstream Author : Daniel G. Taylor
* URL : https://github.com/danielgtaylor/python-b
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: python-sigstore-protobuf-specs
Version : 0.3.3
Upstream Author : The Sigstore Authors
* URL : https://github.com/sigstore
> Right now, the model we have is "some packages use the empty /etc model,
> some packages install commented-out defaults, and there's no
> consistency". I'd love to move to the model of "all packages use
> whichever model the sysadmin prefers".
As a long-time sysadmin - and following on my pre
>
>> Suppose that packages ship sample configuration files *that exactly
>> match their defaults* (which should in general mean that everything is
>> commented out) in some standardized path under /usr/share/doc/$package/
>> (e.g. examples/etc), that makes it easy to see what path the example
>
Ansgar 🙀, le ven. 20 déc. 2024 13:07:36 +0100, a ecrit:
> On Fri, 2024-12-20 at 13:00 +0100, Samuel Thibault wrote:
> > Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
> > > On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> > > > What I completely fail to understand is why people
Henrik Ahlgren, le ven. 20 déc. 2024 13:47:24 +0200, a ecrit:
> On Fri, 2024-12-20 at 12:01 +0100, Ansgar 🙀 wrote:
> > With empty-/etc, you would (ideally) only have explicit local
> > configuration in /etc which makes it much, much easier to see what the
> > local admin changed to diagnose problem
On Fri, 20 Dec 2024 02:05:30 -0800
Josh Triplett wrote:
>
> I'm talking about the "empty /etc" model here, which is why I'm trying
> to find a solution so that people who *want* the file-full-of-comments
> have it, without installing it for people who *don't* want it.
This sounds to be a reasona
Hi,
On Fri, 2024-12-20 at 13:00 +0100, Samuel Thibault wrote:
> Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
> > On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> > > What I completely fail to understand is why people would want to not
> > > see any file in /etc. What harm doe
Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
> On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> > What I completely fail to understand is why people would want to not
> > see any file in /etc. What harm does it *actually* cause?
>
> It makes it hard to see what was actually c
Hello,
Julian Andres Klode, le ven. 20 déc. 2024 12:21:37 +0100, a ecrit:
> # setting the profile
>
> I then propose we inject the
>
> DEB_BUILD_PROFILES=norust
>
> in the buildds for the ports architectures that do not have
> a rustc.
wanna-build would also need to be told to drop build-
On Fri, 2024-12-20 at 12:01 +0100, Ansgar 🙀 wrote:
> With empty-/etc, you would (ideally) only have explicit local
> configuration in /etc which makes it much, much easier to see what the
> local admin changed to diagnose problems, prepare upgrades and so on.
> This is practically impossible now.
On Thu, Dec 19, 2024 at 08:36:25AM -0600, rhys wrote:
>
>
> >
> >> What group of idiots came up with a system where instead of having all of
> >> the configs in maximum of two places (/etc | ~/.config) have now spread
> >> them out across five completely separate directory trees?
> >
> > The
Hi,
On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> What I completely fail to understand is why people would want to not
> see any file in /etc. What harm does it *actually* cause?
It makes it hard to see what was actually configured: there is random
configuration bits, possibly from
(CC me, I'm not subscribed to debian-devel or maintain ports :D)
Hi,
# norust build profile
I propose we add a `norust` build profile such that packages
building Rust parts or integrating with Rust parts can
disable those parts.
For example, if apt gains sqv support, we can define a
pkg.apt.nos
Josh Triplett, le ven. 20 déc. 2024 02:05:30 -0800, a ecrit:
> On Fri, Dec 20, 2024 at 09:55:17AM +0100, Samuel Thibault wrote:
> > Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
> > > Samuel Thibault wrote:
> > > > Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > > > > And
On Fri, Dec 20, 2024 at 09:55:17AM +0100, Samuel Thibault wrote:
> Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
> > Samuel Thibault wrote:
> > > Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > > > And it is actively harmful as if one edits the example configuration to
>
Richard Lewis, le ven. 20 déc. 2024 09:42:11 +, a ecrit:
> but perhaps what is missing is a way to see what changed on upgrade
> (you'd want to save the clean version from the _previous_ version of a
> package to be able to do that after the upgrade)?
You mean ucf?
Samuel
Henrik Ahlgren, le ven. 20 déc. 2024 11:32:37 +0200, a ecrit:
> On Fri, 2024-12-20 at 09:55 +0100, Samuel Thibault wrote:
> > But isn't it what we already have? If I don't modify the example in /etc
> > and only add files to .d/, I'm getting upgrades without questions.
> > And if I modify the examp
On Fri, Dec 20, 2024 at 03:22:57AM +, Colin Watson wrote:
> On Tue, Dec 17, 2024 at 12:53:42PM +, Julian Gilbey wrote:
> > On Mon, Dec 16, 2024 at 01:58:14AM +, Colin Watson wrote:
> > > [...]
> > > * spyder: #1088068/#1089054.
> >
> > I'm struggling with this one; I've asked at
> > h
Josh Triplett writes:
> Suppose that packages ship sample configuration files *that exactly
> match their defaults* (which should in general mean that everything is
> commented out) in some standardized path under /usr/share/doc/$package/
> (e.g. examples/etc), that makes it easy to see what pat
On Fri, 2024-12-20 at 09:55 +0100, Samuel Thibault wrote:
> But isn't it what we already have? If I don't modify the example in /etc
> and only add files to .d/, I'm getting upgrades without questions.
> And if I modify the example in /etc, I'm getting the question. That way
> I can decide per-pack
Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
> Samuel Thibault wrote:
> > Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > > And it is actively harmful as if one edits the example configuration to
> > > have a useful configuration as dpkg will start annoying admins with
>
40 matches
Mail list logo
