Bug#1026359: ITP: hunspell-ie -- Interlingue dictionary for hunspell

2022-12-18 Thread Алекса -скрыто-
Package: wnpp
Severity: wishlist
Owner: mistresssilv...@hotmail.com
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name    : hunspell-ie
  Version         : 1.1
  Upstream Author : Carmina16 
* URL             : https://github.com/Carmina16/hunspell-ie
* License         : Apache-2.0
  Programming Lang: N/A
  Description     : Interlingue dictionary for hunspell

I would like somebody to sponsor this. I intend to maintain the package myself.



Bug#1026341: ITP: python3-trove-classifiers -- A package to validate classifiers in packages for PyPI upload or download

2022-12-18 Thread Gudjon I. Gudjonsson
Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: "Gudjon I. Gudjonsson" 
Severity: wishlist

* Package name: python3-trove-classifiers
  Version : 2022.12.1
  Upstream Contact: 
* URL : https://pypi.org/project/trove-classifiers/
* License : Apache 2.0
  Programming Lang: Python
  Description : A package to validate classifiers in packages for PyPI 
upload or download

Long description
 The package provides a canonical source for classifiers on PyPI.
 .
 TheClassifiers categorize projects per PEP 301. Use this package to validate   
 
 classifiers in packages for PyPI upload or download.

Reasons for packaging
 - The eric ide depends on the package. There is no other package
   providing the functionality.
 - I would prefer to make the 
   Debian Python Team 
   as the maintainer and I do have a few candidates as sponsors.



Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

2022-12-18 Thread Ian Jackson
Thanks to everyone for the comments and review.  I have written things
up on the wiki:
  https://wiki.debian.org/BuildProfile/upstream-cargo
and added the entry here:
  https://wiki.debian.org/BuildProfileSpec

Please comment here, if you think any of this doesn't make sense.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Re: Please, minimize your build chroots

2022-12-18 Thread Johannes Schauer Marin Rodrigues
Hi,

Quoting David Kalnischkies (2022-12-18 17:18:28)
> On Fri, Dec 16, 2022 at 03:38:17PM +0100, Santiago Vila wrote:
> > Then there is "e2fsprogs", which apt seems to treat as if it were
> > an essential package:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826587
> 
> As Julian explained, it is considered "essential" because the maintainer
> said so. If you don't think e2fsprogs should be considered "essential"
> for a system it is installed on please talk to the maintainer.
> 
> Sure, the package is not (anymore) really "Essential:yes", but 'apt'
> isn't either and will print the same message anyhow. I don't think it
> would be a net-benefit for a user to invent words for different types of
> essentialness in apt because in the end you either know what you are
> doing while removing a somewhat essential package and continue or you don't
> know what you are doing and (hopefully) get the hell out.

would it be so difficult to cater to both kind of users? For those who do not
know the terminology, using the word "essential" is probably fine. But for
those who do it's confusing. Why can apt not say something like:

WARNING: The following packages will be removed. Apt considers them essential
because they are marked as Priority:required. This should NOT be done unless
you know exactly what you are doing!

> > This sort-of breaks sbuild when using an ordinary chroot (not overlayfs),
> > because after building a package needing e2fsprogs, it may not be removed
> > and it's kept in the chroot.
> 
> "It may". Well, certainly apt won't autoremove it. Like a lot of other
> packages it wont even through they aren't essential or protected or
> whatever… ("just" prio:required is enough for example). They are not not
> irremovable through. It might just be a little harder to remove them
> than to install them. Heck, some people believe its far easier to start
> vim than to exit it.

Note also, that you really shouldn't be using sbuild with an ordinary chroot,
that is without overlayfs or without the chroot being a tarball unpacked to a
tmpfs. The system will not only be different from before after removal of
packages at the end, if you add --allow-remove-essential to the removal
commandline in sbuild, the chroot might even be completely unusable. What is
the use-case of using sbuild with non-emphimeral chroots?

So personally, I'll not invest my own time in making sbuild better at package
removal at the end of the build process.

> > build packages. Here we would need some interface like
> > SUDO_FORCE_REMOVE=yes, or maybe just stop doing anything at all with the
> > Important:yes flag.
> 
> Ironically, one of the selling points for Protected:yes (that is how the
> field ended up named which dpkg is supporting by now) was that it allows
> to shrink the essential set (e2fsprogs even being an example) as there
> is a non-empty set of people who believe users do incredibly dumb things
> if you give them the option to.
> 
> I mean, we got practically bullied into replacing the "Do as I say!"
> prompt with a semi-hidden cmndline flag (--allow-remove-essential)
> because some wannabe YT star yolo'ed the prompt ending in misery and
> somehow that was framed as our fault by everyone as we didn't show the
> appropriate meme-gif (rendered with caca) to make them understand
> without reading [sorry, not sorry. I am not even exaggerating that much].

After this operation, 195 MS disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'

https://youtu.be/0506yDSgU7M?t=637

"I have to type 'Yes, do as I say!' in order to install it."

Sigh...

> Due to that, you are now presented with:
> | E: Removing essential system-critical packages is not permitted. This might 
> break the system.
> 
> See? "essential" again and even "system-critical" at that.
> It is all a lie of course. Nobody really needs an init system, much less
> some silly metapackage for it, as long as there is /bin/sh and a keyboard.
> I should make a video about it to – essentially – become famous & rich…

Dammit, and now you wrote that one can use in a public forum that it's possible
to add --allow-remove-essential! Think of the children!

> Btw, apt also has behaviour specifically for sbuild: 'apt-cache show
> mail-transport-agent' has a zero exitcode even through that makes no
> sense at all apart from not making (some?) sbuild versions explode.
> You are welcome. I hate it.

E... lets change that. What's the problem in sbuild?

Thanks!

cheers, josch



Re: Please, minimize your build chroots

2022-12-18 Thread David Kalnischkies
On Fri, Dec 16, 2022 at 03:38:17PM +0100, Santiago Vila wrote:
> Then there is "e2fsprogs", which apt seems to treat as if it were
> an essential package:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826587

As Julian explained, it is considered "essential" because the maintainer
said so. If you don't think e2fsprogs should be considered "essential"
for a system it is installed on please talk to the maintainer.

Sure, the package is not (anymore) really "Essential:yes", but 'apt'
isn't either and will print the same message anyhow. I don't think it
would be a net-benefit for a user to invent words for different types of
essentialness in apt because in the end you either know what you are
doing while removing a somewhat essential package and continue or
you don't know what you are doing and (hopefully) get the hell out.


> This sort-of breaks sbuild when using an ordinary chroot (not overlayfs),
> because after building a package needing e2fsprogs, it may not be removed
> and it's kept in the chroot.

"It may". Well, certainly apt won't autoremove it. Like a lot of other
packages it wont even through they aren't essential or protected or
whatever… ("just" prio:required is enough for example). They are not not
irremovable through. It might just be a little harder to remove them
than to install them. Heck, some people believe its far easier to start
vim than to exit it.


> I think apt authors did not think that apt is used by sbuild to

I think (the few) apt authors deal with way too many users with way too
many (sometimes mutually exclusive) ideas of how it should behave:


> build packages. Here we would need some interface like SUDO_FORCE_REMOVE=yes,
> or maybe just stop doing anything at all with the Important:yes flag.

Ironically, one of the selling points for Protected:yes (that is how the
field ended up named which dpkg is supporting by now) was that it allows
to shrink the essential set (e2fsprogs even being an example) as there
is a non-empty set of people who believe users do incredibly dumb things
if you give them the option to.

I mean, we got practically bullied into replacing the "Do as I say!"
prompt with a semi-hidden cmndline flag (--allow-remove-essential)
because some wannabe YT star yolo'ed the prompt ending in misery and
somehow that was framed as our fault by everyone as we didn't show the
appropriate meme-gif (rendered with caca) to make them understand
without reading [sorry, not sorry. I am not even exaggerating that much].

Due to that, you are now presented with:
| E: Removing essential system-critical packages is not permitted. This might 
break the system.

See? "essential" again and even "system-critical" at that.
It is all a lie of course. Nobody really needs an init system, much less
some silly metapackage for it, as long as there is /bin/sh and a keyboard.
I should make a video about it to – essentially – become famous & rich…


Btw, apt also has behaviour specifically for sbuild: 'apt-cache show
mail-transport-agent' has a zero exitcode even through that makes no
sense at all apart from not making (some?) sbuild versions explode.
You are welcome. I hate it.


So, long story short, apt features and behaviour are very seldom done
because we are bored and had nothing better to do. It is far more common
that it was heavily requested to be that way for $REASONS. Sometimes its
even the same $REASONS you have for disliking it. Users are the worst,
I said it here first. But no problem, there usually is an option to
change anything in apt. If not, we can usually add it.

Just don't assume that the behaviour you prefer will be the default.
We have a strong tendency to make everyone unhappy.
(I should know, I never get what I want.)


Best regards

David Kalnischkies

P.S.: You thought we are surprised by sbuild using apt? Sorry, but you
are up against ISO building needing 'apt-cache depends' output previously
unknown even to the CD team itself (https://bugs.debian.org/218995#54)
(yes, it is a decade old. It's still my favorite). Try harder.


signature.asc
Description: PGP signature