Re: lintian.debian.org off ?

[Nilesh Patra]

On Mon, Sep 25, 2023 at 10:28:06PM -0700, Otto Kekäläinen wrote:
> > > > > Host lintian.debian.org not found: 3(NXDOMAIN)
> > > > >
> > > > > is this expected ?
> > > >
> > > > Yes, it is replaced by the UDD interface:
> > > >
> > > > https://wiki.debian.org/Services/lintian.debian.org
> 
> The page above links to two bug reports but I can't find any actual
> information about *why* the site https://lintian.debian.org/ was shut
> down?

You can find a better explanation and context here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858039#22

Best,
Nilesh


signature.asc
Description: PGP signature

Re: lintian.debian.org off ?

[Otto Kekäläinen]

> > > > Host lintian.debian.org not found: 3(NXDOMAIN)
> > > >
> > > > is this expected ?
> > >
> > > Yes, it is replaced by the UDD interface:
> > >
> > > https://wiki.debian.org/Services/lintian.debian.org

The page above links to two bug reports but I can't find any actual
information about *why* the site https://lintian.debian.org/ was shut
down?

The site 
https://udd.debian.org/lintian-tag.cgi?tag=wrong-name-for-upstream-changelog
only lists packages with the issue, while the old site had full
explanations of the issue and felt quite friendly and easy to consume
(non-CSS styled version still visible in Google cache, eg.
https://webcache.googleusercontent.com/search?q=cache:AKmDGNJEIaAJ:https://lintian.debian.org/tags/wrong-name-for-upstream-changelog).

Bug#1052673: ITP: golang-github-bazelbuild-bazelisk -- A user-friendly launcher for Bazel.

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: golang-github-bazelbuild-bazelisk
  Version : 1.18.0-1
  Upstream Author : Bazel
* URL : https://github.com/bazelbuild/bazelisk
* License : Apache-2.0
  Programming Lang: Go
  Description : A user-friendly launcher for Bazel.

 Bazelisk is a user-friendly wrapper/launcher for Bazel written in Go.
 It automatically picks a good version of Bazel given your current working
 directory, downloads it from the official server (if required) and then
 transparently passes through all command-line arguments to the real Bazel 
binary.
 .
 You can call it just like you would call Bazel.
 .
 Before Bazelisk was rewritten in Go, it was a Python script. This still works
 and has the advantage that you can run it on any platform that has a Python
 interpreter, but is currently unmaintained and it doesn't support as many 
features.

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Andrey Rakhmatullin  [230925 15:13]:
> On Mon, Sep 25, 2023 at 01:55:22PM -0400, Jonathan Kamens wrote:
> > The documentation you inked to does not specify a tag that can be used
> > specifically to mark something as not actually a bug.
> Yes, we just close those. The Debian BTS is not as rich as e.g. a typical
> bugzilla installation in this regard. Though I guess not having a fixed
> version and not having the wontfix tag usually suggests the report was
> invalid.

How hard is it to add a 'notabug' tag?

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 01:55:22PM -0400, Jonathan Kamens wrote:
> The documentation you inked to does not specify a tag that can be used
> specifically to mark something as not actually a bug.
Yes, we just close those. The Debian BTS is not as rich as e.g. a typical
bugzilla installation in this regard. Though I guess not having a fixed
version and not having the wontfix tag usually suggests the report was
invalid.

>This bug won't be fixed. Possibly because this is a choice
>between two arbitrary ways of doing things and the maintainer
>and submitter prefer different ways of doing things, possibly
>because changing the behaviour will cause other, worse, problems
>for others, or */possibly for other reasons./*
> 
> "I don't consider this a bug" seems, to me, to fit under "other reasons."
Other reasons why *this bug won't be fixed*, which doesn't apply if this
is not a bug.

> Is there some harm that is done by marking a bug that falls into this
> category with "wontfix"?
I think there is some: it having wontfix suggests the bug is valid but
won't be fixed.
The harm is minimal though, because likely nobody will read this report if
it doesn't correspond to anything affecting other people.

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Jonathan Kamens  [230925 12:56]:
> Closed bugs are available for direct search for 30 days after they're
> closed.
> 
> After that you can still search them by selecting either "Archived" or
> "Archived and Unarchived" under "Misc Options" on the search page.

Except that in the general case, this is not very useful for avoiding
the duplicated filing of a bug that has already been discussed and
rejected.

> All that aside, in this particular case I closed the bug because it wasn't
> actually a bug, but rather a PEBKAC issue (user complaining that a program
> wasn't respecting his locale when he had LC_ALL set to "C" so he was
> essentially telling the program to ignore his locale).

That is a very good reason to close the bug.  Your original message did
not refer to the bug or even the package, so I had no knowledge of the
details.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Russ Allbery  [230925 12:43]:
> Marvin Renich  writes:
> 
> > I've seen differing opinions about closing "wontfix" bugs, but as a
> 
> I think it's a trade-off.

Which is why I said there are differing opinions.  This has come up on
this list before.

> There are some bugs that seem unlikely to ever
> come up again or that aren't helpfully worded, and I'm more willing to
> close those.

Agreed.

> Also, in the abstract, I don't like using the BTS as a documentation
> system, which is sort of what collecting wontfix amounts to.  If it's

Except that if it looks like a bug to me, I am going to fire up
reportbug without looking at README.Debian, and I think many users do
the same.  But, I do go through existing bugs to try to avoid
duplication.  I know not everyone does, but they should.

I feel that even though this was not the original intent of the BTS, it
is the most useful and pragmatic place to document this sort of thing.
Documenting it in a bug script may be more in line with its intended
use, but is probably a poorer use of Debian resources, as it uses Debian
and mirror archive space and download resources (both Debian and user)
for something that is only going to come up every 10,000 package
downloads.

> something that I think is going to come up a lot, it feels better to put
> it into the actual documentation (README.Debian, a bug script if it's
> reported really often, etc.).  You're also expecting everyone filing a bug
> to read through all the existing wontfix bugs (at least their titles),
> which in some cases is fine but in some cases can become overwhelming.

I wasn't trying to start a lengthy discussion or get Debian to make an
official policy, just stating a preference.  I expect that most
maintainers use good judgement, and adding the reasoning for my
preference might help them decide which wontfix bugs to close and which
to leave open.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

The documentation you inked to does not specify a tag that can be used 
specifically to mark something as not actually a bug.


That documentation does say the following about the "wontfix" tag 
(*/emphasis/* added by me):


   |wontfix|
   This bug won't be fixed. Possibly because this is a choice
   between two arbitrary ways of doing things and the maintainer
   and submitter prefer different ways of doing things, possibly
   because changing the behaviour will cause other, worse, problems
   for others, or */possibly for other reasons./*

"I don't consider this a bug" seems, to me, to fit under "other reasons."

Is there some harm that is done by marking a bug that falls into this 
category with "wontfix"?


  jik

On 9/25/23 13:40, Andrey Rakhmatullin wrote:

On Mon, Sep 25, 2023 at 12:55:16PM -0400, Jonathan Kamens wrote:

All that aside, in this particular case I closed the bug because it wasn't
actually a bug, but rather a PEBKAC issue (user complaining that a program
wasn't respecting his locale when he had LC_ALL set to "C" so he was
essentially telling the program to ignore his locale).

wontfix is a wrong tag for such bugs according to
https://www.debian.org/Bugs/Developer#tags  though.

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 12:55:16PM -0400, Jonathan Kamens wrote:
> All that aside, in this particular case I closed the bug because it wasn't
> actually a bug, but rather a PEBKAC issue (user complaining that a program
> wasn't respecting his locale when he had LC_ALL set to "C" so he was
> essentially telling the program to ignore his locale).
wontfix is a wrong tag for such bugs according to
https://www.debian.org/Bugs/Developer#tags though.

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

Closed bugs are available for direct search for 30 days after they're 
closed.


After that you can still search them by selecting either "Archived" or 
"Archived and Unarchived" under "Misc Options" on the search page.


All that aside, in this particular case I closed the bug because it 
wasn't actually a bug, but rather a PEBKAC issue (user complaining that 
a program wasn't respecting his locale when he had LC_ALL set to "C" so 
he was essentially telling the program to ignore his locale).


  jik

On 9/25/23 12:13, Marvin Renich wrote:

* Jonathan Kamens  [230925 07:17]:

Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag all at
once by sending my explanation to ###-d...@bugs.debian.org with "Control:
tags ### wontfix" as the first line of my message body. The bug was closed
but the tags command wasn't processed.

I've seen differing opinions about closing "wontfix" bugs, but as a
user, I appreciate when they are left open.  Whether it is a simple
wishlist feature request or a crash when the user abuses the software,
if I go to file the same or similar bug at a later time, if the bug is
closed I will not see it and file a duplicate.  If it is left open, I
can see the maintainer has already thought about it and intentionally
decided not to fix it, so I can save the trouble of refiling.  Also, I
might gain some insight about the circumstances.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Russ Allbery]

Marvin Renich  writes:

> I've seen differing opinions about closing "wontfix" bugs, but as a
> user, I appreciate when they are left open.  Whether it is a simple
> wishlist feature request or a crash when the user abuses the software,
> if I go to file the same or similar bug at a later time, if the bug is
> closed I will not see it and file a duplicate.  If it is left open, I
> can see the maintainer has already thought about it and intentionally
> decided not to fix it, so I can save the trouble of refiling.  Also, I
> might gain some insight about the circumstances.

I think it's a trade-off.  There are some bugs that seem unlikely to ever
come up again or that aren't helpfully worded, and I'm more willing to
close those.

Also, in the abstract, I don't like using the BTS as a documentation
system, which is sort of what collecting wontfix amounts to.  If it's
something that I think is going to come up a lot, it feels better to put
it into the actual documentation (README.Debian, a bug script if it's
reported really often, etc.).  You're also expecting everyone filing a bug
to read through all the existing wontfix bugs (at least their titles),
which in some cases is fine but in some cases can become overwhelming.

-- 
Russ Allbery (r...@debian.org)  

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Jonathan Kamens  [230925 07:17]:
> Hi all,
> 
> I recently tried to close a bug, explain why, and set a "wontfix" tag all at
> once by sending my explanation to ###-d...@bugs.debian.org with "Control:
> tags ### wontfix" as the first line of my message body. The bug was closed
> but the tags command wasn't processed.

I've seen differing opinions about closing "wontfix" bugs, but as a
user, I appreciate when they are left open.  Whether it is a simple
wishlist feature request or a crash when the user abuses the software,
if I go to file the same or similar bug at a later time, if the bug is
closed I will not see it and file a duplicate.  If it is left open, I
can see the maintainer has already thought about it and intentionally
decided not to fix it, so I can save the trouble of refiling.  Also, I
might gain some insight about the circumstances.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

Thank you! A canonical answer at last.

On 9/25/23 10:53, Andrey Rakhmatullin wrote:

On Mon, Sep 25, 2023 at 07:16:56AM -0400, Jonathan Kamens wrote:

I recently tried to close a bug, explain why, and set a "wontfix" tag all at
once by sending my explanation to ###-d...@bugs.debian.org with "Control:
tags ### wontfix" as the first line of my message body. The bug was closed
but the tags command wasn't processed.

It doesn't work for NNN-done@ according to
https://www.donarmstrong.com/posts/control_at_submit/

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 07:16:56AM -0400, Jonathan Kamens wrote:
> I recently tried to close a bug, explain why, and set a "wontfix" tag all at
> once by sending my explanation to ###-d...@bugs.debian.org with "Control:
> tags ### wontfix" as the first line of my message body. The bug was closed
> but the tags command wasn't processed.
It doesn't work for NNN-done@ according to
https://www.donarmstrong.com/posts/control_at_submit/

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 10:04:17AM -0400, Jonathan Kamens wrote:
> I did find this here  after I emailed
> the list:
> 
>QUESTION: Can you do all the control-server actions by using fields
>in a pseudo header in an email to bugnumber@b.d.o
> or do you need to use control@b.d.o
>?
> 
>ANSWER: You need to use the explicit control@ mail copy, automatic
>parsing isn't done. From what I understood it's worked on but it
>might take a bit to make it reliable and not catch something it
>shouldn't.
This is about plain commands, not about the Control: pseudo-header.
This QA transcript is from 2010, the feature was added in 2012.

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

...and I just successfully used a Control: header in an email to 
###@bugs.debian.org, so the only question remaining in my mind is 
whether the one that didn't work failed because it was sent to ###-done, 
or failed because of the base64 encoding. I can't think of any other 
reasons why the Control: header would have been ignored.

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 02:44:19PM +0100, Peter B wrote:
> On 25/09/2023 14:25, Jonathan Kamens wrote:
> > 
> > So putting a Control: line in the pseudo-header of a message sent to 
> > ###-d...@bugs.debian.org doesn't work at all?
> > 
> 
> It should work if the syntax is correct. The + character was missing.
Please read https://www.debian.org/Bugs/server-control#tag

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

According to https://www.debian.org/Bugs/server-control#tag the plus is 
optional.


Once again, my question was, should a valid Control: header on the first 
line of an email message sent to ###-d...@bug.debian.org work, and if 
so, is the reason why it didn't work in my case because the MIME part it 
was included in was base64-encoded, and if not, what other reason could 
explain why it didn't work?


I did find this here  after I 
emailed the list:


   QUESTION: Can you do all the control-server actions by using fields
   in a pseudo header in an email to bugnumber@b.d.o
    or do you need to use control@b.d.o
   ?

   ANSWER: You need to use the explicit control@ mail copy, automatic
   parsing isn't done. From what I understood it's worked on but it
   might take a bit to make it reliable and not catch something it
   shouldn't.

So, if this is correct, then I apparently what I tried to do just 
doesn't work. :shrug:


On 9/25/23 09:44, Peter B wrote:

On 25/09/2023 14:25, Jonathan Kamens wrote:


So putting a Control: line in the pseudo-header of a message sent to 
###-d...@bugs.debian.org doesn't work at all?




It should work if the syntax is correct. The + character was missing.

Re: Control header sent with done email didn't do what I expected, should it have?

[Peter B]

On 25/09/2023 14:25, Jonathan Kamens wrote:


So putting a Control: line in the pseudo-header of a message sent to 
###-d...@bugs.debian.org doesn't work at all?



It should work if the syntax is correct. The + character was missing.

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 02:06:44PM +0100, Peter B wrote:
> > I recently tried to close a bug, explain why, and set a "wontfix" tag
> > all at once by sending my explanation to ###-d...@bugs.debian.org with
> > "Control: tags ### wontfix" as the first line of my message body. The
> > bug was closed but the tags command wasn't processed.
> > 
> > Looking at the raw message file that I sent, I see that my mailer
> > encoded the text/plain MIME body part with base64 because I had pasted
> > into the body a quote from a web site that used non-ASCII quotation
> > marks (d'oh). Is that why BTS failed to process the "Control:" command?
> > 
> > If yes, then is this a known thing that's not going to change that I
> > should just live with ;-), or should I file a bug about it?
> > 
> > If no, then can anyone tell me what else I did wrong to cause the 
> > "Control:" command not to be processed?
> > 
> > Thanks,
> > 
> > jik
> > 
> 
> see
> https://www.debian.org/Bugs/server-refcard
> 
> It should be
> tags bugnumber + wontfix
> 
> sent to cont...@bugs.debian.org
Please check https://www.debian.org/Bugs/Reporting#control

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

So putting a Control: line in the pseudo-header of a message sent to 
###-d...@bugs.debian.org doesn't work at all?


On 9/25/23 09:06, Peter B wrote:

On 25/09/2023 12:16, Jonathan Kamens wrote:


Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag 
all at once by sending my explanation to ###-d...@bugs.debian.org 
with "Control: tags ### wontfix" as the first line of my message 
body. The bug was closed but the tags command wasn't processed.


Looking at the raw message file that I sent, I see that my mailer 
encoded the text/plain MIME body part with base64 because I had 
pasted into the body a quote from a web site that used non-ASCII 
quotation marks (d'oh). Is that why BTS failed to process the 
"Control:" command?


If yes, then is this a known thing that's not going to change that I 
should just live with ;-), or should I file a bug about it?


If no, then can anyone tell me what else I did wrong to cause the 
"Control:" command not to be processed?


Thanks,

jik



see
https://www.debian.org/Bugs/server-refcard

It should be
tags bugnumber + wontfix

sent to cont...@bugs.debian.org

best to have
package foo

on the first line in case of typos in the bug number!

Re: Abandonware in testing (Re: lpr/lpd)

[Gioele Barabucci]

On 25/09/23 14:29, Wookey wrote:

It's actually quite well-maintained, just not by the maintainer:
someone else has uploaded the last 3 upstream versions via
debian-mentors.


I think this example shows the need for a level of maintainership that 
sits between "fully maintained" and "orphaned". (Or a rethinking of the 
concept of "orphan packages".)


Right now in Debian there is a distinction between:

1) maintained packages (Maintainer: "foo")

and

2) orphaned packages (Maintainer: "Debian QA Group").

State 1 is the desired state of a package: somebody (a single person or 
a team) looks after this package, packages and tests new releases, and 
is expected to respond to inquiries (bug reports, MRs, NMUs) within a 
reasonable time.


State 2 is an undesired state that should be addressed. Somebody from 
the QA team (= theoretically the whole of Debian) may have a look at it 
in case of transitions or RC bugs. But what Debian really desires is 
that somebody will adopt this package and put their name in the 
Maintainer: field.


What I think is needed is a state 3 (or 1.5) that formalizes what Wookey 
described: there is an informal group of people that may take care of a 
package, but they don't feel like having their names attached to it nor 
want the responsibility of being the ones in charge for timely fixes or 
quick replies.


The way I picture it, "state 3" packages would have something like 
"Debian Caretaking Team" in the Maintainer: field (not the usual "QA 
Group", and have autotests in lieu of a specific person/team that takes 
care of manually testing the package.


Has such a third category already been discussed or explored?

--
Gioele Barabucci

Re: Control header sent with done email didn't do what I expected, should it have?

[Peter B]

On 25/09/2023 12:16, Jonathan Kamens wrote:


Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag all at once by sending my explanation to 
###-d...@bugs.debian.org with "Control: tags ### wontfix" as the first line of my message body. The bug was closed but 
the tags command wasn't processed.


Looking at the raw message file that I sent, I see that my mailer encoded the text/plain MIME body part with base64 
because I had pasted into the body a quote from a web site that used non-ASCII quotation marks (d'oh). Is that why BTS 
failed to process the "Control:" command?


If yes, then is this a known thing that's not going to change that I should just live with ;-), or should I file a bug 
about it?


If no, then can anyone tell me what else I did wrong to cause the "Control:" 
command not to be processed?

Thanks,

jik



see
https://www.debian.org/Bugs/server-refcard

It should be
tags bugnumber + wontfix

sent to cont...@bugs.debian.org

best to have
package foo

on the first line in case of typos in the bug number!

Re: debian/copyright format and SPDX

[Stephan Lachnit]

On Mon, Sep 25, 2023 at 7:15 AM Steve Langasek  wrote:
>
> So can you tell me where in that specification this "flat text file" format
> is actually described?  The specification is not on the page that includes
> this quote.  The text does not link to the place in the spec where this
> format is described.  The site's search page (because it's reasonable for a
> spec to require a server-side search engine in order for users to be able to
> find information in it...) doesn't return any results for the string
> 'tag:value', and a search for 'tag value' points first to
> https://spdx.github.io/spdx-spec/v2.3/file-tags/ which
> describes embedding tags in a source file, not constructing a tag:value
> file.
>
> Frankly, the fact that the SPDX spec itself is as bad as it is should be
> disqualifying for using any file format specified within.  But I would still
> be willing to give it a fair shake, if I could actually find it.

E.g. here under examples?
https://spdx.github.io/spdx-spec/v2.3/document-creation-information/

Cheers,
Stephan

Re: Abandonware in testing (Re: lpr/lpd)

[Wookey]

On 2023-09-23 08:35 +0200, Gioele Barabucci wrote:
> On 22/09/23 09:41, Christoph Biedl wrote:
> > I doubt simple rules will really work out, rules like that
> > one I had in mind "Packages are removed from testing once they have been
> > orphaned/last maintainer-uploaded more than five years ago".
> 
> Maybe something more nuanced may work.
> 
> For example: packages are removed from testing if:
> 
> - have been orphaned/last maintainer-uploaded more than 2 releases ago,
> - have no autopkgtests OR autopkgtests fail OR are not
> lintian/piuparts-clean.

I don't think that 'maintainer-uploaded' rules is a good one for capturing 'is 
looked after' whichis what I think you intended. 

For example, the very useful package ncdu (which I just sponsored an
NMU upload of - 1.19 is currently in DELAYED) would fail this test.
https://tracker.debian.org/pkg/ncdu

It's actually quite well-maintained, just not by the maintainer:
someone else has uploaded the last 3 upstream versions via
debian-mentors. Upstream even took debian patches in the last release
so there are now no patches, which is about as good as things get for
mature software.

Only-NMU uploads for some years is quite a common pattern and whilst
sometimes it indicates the package is only getting emergency
drive-by maintainance, sometimes (like here) the thing is actually being
maintained just as it should be (just by someone who is not officially
the maintainer).

In this case looking for NMUs of new upstream versions would give the
clue that this is not just life-support. I don't know if that is a
sufficient rule?  Repeated NMUs by one person is also a clue. As you
say something 'more nuanced' still is needed and a useful test may
actually be quite complicated.

To get back to the wider issue: In general I like the fact that Debian
doesn't remove packages so long as they still work (so fas as we
know). It's one thing that gives users stability. (I'm still grumpy
about ipmasq being removed circa 2011, and I still use a local build
of 'bins' which was removed in 2015).

But we do end up carrying a lot of old stuff, possibly some of
which is genuinely superceded/no longer used.

And as a user I _would_ like better mechanisms to explain when
$something has been replaced by $something-else and users are expected
to move over at some point. Sometimes on upqrade a package has just
gone and it's not something you know anything about so you have no
idea if there is a replacement of some sort or what it might be
called. apt-listchanges can fill this gap, but only if you install it
(and it's kind of annoying because it interrupts the install/upgrade
process). And this only works for well-maintained packages that
actually update Debian.NEWS, not barely-maintained/unmaintained
packages. I guess you might get the info from the replacing, as
opposed to replaced package, but as with printing it's often a whole
set of stuff and it's not clear where any 'moving on' info should live. 

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1052619: ITP: pydantic-core -- Rust implementation of pydantic core functionality

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: pydantic-core
  Version : 2.9.0
  Upstream Author : Samuel Colvin
* URL : https://github.com/pydantic/pydantic-core
* License : Expat
  Programming Lang: Python, Rust
  Description : Rust implementation of pydantic core functionality

pydantic uses type hinting (PEP 484) and variable annotation (PEP 526) to
validate that untrusted data takes the desired form. There is also support for
an extension to dataclasses where the input data is validated.

The core library is implemented in Rust and up to seventeen times faster than
the original pure Python implementation.

This is a new dependency for pydantic 2. The package will probably be
team-maintained under the umbrella of the Debian Python Team
.



-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmURdfQACgkQ+C8H+466
LVkUawwAjCO9wWXpdir5lVlaQa0b5niJ/JGEWC2qg6bZxBELJHyniYlyUtAl+qeb
AsySa6hSQ+4nCgQEinCo9JHwwhERlY9MlceVeez4EuP1Xt4udbvx8l9RUUAlUP7b
BYxgw8GAWMQsrn+ZCPdv0jjvzjI9u1LOzJqwV8w6E0XpuQTi7ZsqNegKsEg0jfVk
NKUGaCyWKvEmhh1rfn7iPO0QGiufbsjp568JCA1LGX/OKL8oXD3LEu+ji9P9gCRq
ym6iqrmrRtNH3vIBi29chaQUkEZRQvkzAocWXF5F8Ba6j2B9dMiuNsPT7ylBFGF/
tEbg+9ELAHlV7Ab9yAH2VPM1gpmblOs9rpp0+F+fCfW+raTH3OByXYGgMbyryOeD
P+YtP2awBSpQSrS6YGjK83MTPRxrv0UflK6+XL3eDHN7GsMMQuAv4TkA9HX7BDUf
7+JP2urP0gjL4sdkRtZncHQWhEIc2HWHGUW3OAlJEClMyu/HVslomsEcS8zxKIUk
UCc5c91X
=J7bx
-END PGP SIGNATURE-

Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag 
all at once by sending my explanation to ###-d...@bugs.debian.org with 
"Control: tags ### wontfix" as the first line of my message body. The 
bug was closed but the tags command wasn't processed.


Looking at the raw message file that I sent, I see that my mailer 
encoded the text/plain MIME body part with base64 because I had pasted 
into the body a quote from a web site that used non-ASCII quotation 
marks (d'oh). Is that why BTS failed to process the "Control:" command?


If yes, then is this a known thing that's not going to change that I 
should just live with ;-), or should I file a bug about it?


If no, then can anyone tell me what else I did wrong to cause the 
"Control:" command not to be processed?


Thanks,

jik

how-can-i-help by default [Re: lpr/lpd]

[Simon Richter]

Hi,

On 9/25/23 14:08, Paul Wise wrote:


The problem with that approach is that the help needed information
changes independently to packages, so the information will get very out
of date in between point releases, which is why how-can-i-help does
online checks. If desired, it would be easy to have an apt update hook
that would download the data from UDD so that how-can-i-help can work
offline when the network is available.


Yes, that's why I thought of using indices/ -- there are already 
Maintainers and Uploaders files in there that I'd expect are also meant 
to change independently from Packages. The indices/ directory seems to 
be available on most if not all mirrors as well, so putting it there 
would not put unnecessary strain on UDD.


My proposal is to display the list of RFA/O packages installed on the 
system by default as part of the after-installation summary, because we 
currently have no way of reaching users of at-risk packages before the 
package is removed, and I would like to change that.


   Simon

Re: Questionable Package Present in Debian: fortune-mod

[Filippo Rusconi]

On Mon, Sep 25, 2023 at 08:32:29AM +0200, Sven Bartscher wrote:

Hi

Am 24.09.23 um 18:41 schrieb Salvo Tomaselli:

Without an ftpteam hat on, but my point of view -- I believe the team
would absolutely reject a package only based on its name (see:
#914179).


Not very consistently though:

$ apt search penis | grep penis | wc -l
2


Can you please clarify what problem you see with these package names? 
The results I get for this search are:


apt search penis | grep --color penis


Isn't penis the thing males hold in their hand when they urinate? Are we going
to exclude any term relating to fundamental biological functions in Debian? I
cannot believe I see this happening here.

As a (maybe already too old, for nowadays standards) biologist, I find this
upsetting that were are looking for this kind of silly things instead of doing
computer-related work.

Cheers,
Filippo

A Debian developer who is not sexist, rather, more inclined to altruism and
inclusiveness than not... but... not looking for things that do not deserve our
attention...

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Researcher at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Re: Questionable Package Present in Debian: fortune-mod

[Salvo Tomaselli]

> Can you please clarify what problem you see with these package names?
> The results I get for this search are:
> 
>   apt search penis | grep --color penis

I see no problem whatsoever, that was the point I was making. Sorry that it 
wasn't more clear.

The bug linked in the email I replied to, referred to "web outside of browser" 
(aka weboob) that was rejected because of the name,

The project had to go through a renaming process (it is now woob) to hope to 
be included.

Best

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

signature.asc
Description: This is a digitally signed message part.