On Wed, Nov 13, 2024 at 10:29:06AM +0100, Matthias Klose wrote:
> python3-defaults in unstable now adds Python 3.13 as a supported Python 3.13
> version. You might see some additional build failures, until the binNMUs
> for this addition are done [1]. This might take some days for some
> architect
Marc Haber wrote:
> don't take the old version away until the new one is feature par and
> bug free.
Leaving aside the points Philipp Kern made (some features are
intentionally removed, and code is rarely if ever "bug free")...
Another way of phrasing "don't take the old version away" is "someone
Hi,
On 12/15/24 2:11 PM, Marc Haber wrote:
[ Rewriting existing tools in another language ]
> Yes, go ahead with that, but don't force people to do that, and don't
> take the old version away until the new one is feature par and bug
> free.
I find the latter a bit offensive and unrealistic. Rewri
On 12/16/24 12:54 AM, Richard Lewis wrote:
Tiago Bortoletto Vaz writes:
Btw, for triage I used to suggesthttps://fabre.debian.net to
newcomers. I had some hope that it could be a start for something
bigger, so I tried to have access to the code to improve a few things
but never had an answer f
Tiago Bortoletto Vaz writes:
> Btw, for triage I used to suggest https://fabre.debian.net to
> newcomers. I had some hope that it could be a start for something
> bigger, so I tried to have access to the code to improve a few things
> but never had an answer from the maintainer :\
This looks lik
Charles Plessy:
Le Sun, Dec 15, 2024 at 09:27:06AM +0100, Niels Thykier a écrit :
We would like [...] that `dpkg` provides defaults [...] if the fields
are omitted from `debian/control`, you get `Priority: optional` and
`Section: unknown` as default in all artifacts (`.dsc`, `.changes`,
and in t
On Sat, 14 Dec 2024 22:38:49 +0100, Matthias Urlichs
wrote:
>Marc Haber:
>
>> I disagree violently with all efforts that would waste Debian people's
>> time to rewrite existing and well-working times just for the sake of
>> having them in a more "modern" programming language.
>ITYM "well-working t
Le Sun, Dec 15, 2024 at 09:27:06AM +0100, Niels Thykier a écrit :
> We would like [...] that `dpkg` provides defaults [...] if the fields
> are omitted from `debian/control`, you get `Priority: optional` and
> `Section: unknown` as default in all artifacts (`.dsc`, `.changes`,
> and in the `.deb`).
Hi Matthias,
Quoting Matthias Urlichs (2024-12-15 06:33:35)
> On 12.12.24 12:48, Holger Levsen wrote:
> > On Thu, Dec 12, 2024 at 08:57:57AM +0100, 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 Dev
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 behaviour too), thanks!
indeed! thank you both!
> ideally these changes would be in dpkg in trixie, but maintainers would
> start dropp
Daniel Baumann:
Hi,
both sound good (dropping mandatory priority is nice and consistent,
fixing unknown section behaviour too), thanks!
Thanks for the feedback. :)
ideally these changes would be in dpkg in trixie, but maintainers would
start dropping priority fields *after* trixie so that f
Hi,
both sound good (dropping mandatory priority is nice and consistent,
fixing unknown section behaviour too), thanks!
ideally these changes would be in dpkg in trixie, but maintainers would
start dropping priority fields *after* trixie so that for backports we
woudn't need to add it back en mas
Hi,
Historically, if you omitted `Priority` and `Section` from your
package, `dpkg` would warn and use `-` or `unknown` as placeholder
when it absolutely needed a value for these fields in the `.dsc` and
the `.changes` file. The resulting `.deb` would omit the field.
We would like to change this
13 matches
Mail list logo
