Re: [gentoo-dev] [PATCH] waf-utils.eclass: enable parallel install
> On 28 Jan 2023, at 19:25, Mike Gilbert wrote: > > This gives a nice speedup to net-fs/samba, which (re)links several > hundred files in its install phase. > > Bug: https://bugs.gentoo.org/715542 > Signed-off-by: Mike Gilbert > --- OK, let's try it. Bit reluctant because of some of the issues we've had before but should be less of an issue in install. signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] dev-python/ package naming policy?
On Mon, 2023-01-30 at 16:11 +0500, Anna (cybertailor) Vyalkova wrote: > On 2023-01-30 12:00, Michał Górny wrote: > > However, there's a can of worms around the corner -- should we also > > allow normalizing "-" and "_" across different packages (see dev- > > python/sphinx*)? > > PyPI treats "-" and "_" separators as the same, so I'd not use > underscores for in-repo consistency. I suppose that's PEP 503. It speaks of name normalization: | The name should be lowercased with all runs of the characters ., -, | or _ replaced with a single - character. [1] Technically, a policy that would require only "normalized" name match would let us improve consistency when upstreams fail to do so. Unfortunately, while common tools search case-insensitively, they are sensitive to these characters (and I'm not convinced of changing that). [1] https://peps.python.org/pep-0503/#normalized-names -- Best regards, Michał Górny
Re: [gentoo-dev] dev-python/ package naming policy?
Andrew Ammerlaan writes: > On 28/01/2023 19:02, Ulrich Mueller wrote: >>> On Sat, 28 Jan 2023, Michał Górny wrote: However, it's been pointed out that this makes it hard for people to find packages they're looking for. >> I don't understand this argument. Why would all-lowercase make finding a >> package harder? > > Here's an example, on pypi we have packages: > - git-python > - python-git > - GitPython > - git-py > > Each of these is a different package. The package you usually want is > GitPython, but if we would name it gitpython or git-python, things would get > very confusing very quickly. In fact, this package was renamed precisely to > avoid this confusion in [1]. This is not the only case where there are very > similarly named packages on pypi. By having a 1 to 1 mapping between names in > pypi and names in ::gentoo we avoid this confusion. AFAIK, but I cannot find a source confirming this, PyPI project names are case-insensitive, so it should be okay to map to all lowercase. > Best regards, > Andrew > > [1] > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dec450a90c7490f11df7e69cd9c6709c099285c -- Arsen Arsenović signature.asc Description: PGP signature
Re: [gentoo-dev] dev-python/ package naming policy?
On 2023-01-30 12:00, Michał Górny wrote: > However, there's a can of worms around the corner -- should we also > allow normalizing "-" and "_" across different packages (see dev- > python/sphinx*)? PyPI treats "-" and "_" separators as the same, so I'd not use underscores for in-repo consistency.
Re: [gentoo-dev] dev-python/ package naming policy?
On Sat, 2023-01-28 at 17:38 +0100, Michał Górny wrote:
> To improve consistency and make packages easier to find, I'd like to
> propose going forward that when packages are published on PyPI, we use
> their official PyPI names. This also means preserving the case for
> the few packages that use CamelCase names and similar.
>
> Some modifications will be necessary. For example, it is legal for PyPI
> package names to include dot (".") — we normally translate that to a
> hyphen ("-"). We may also have use cases for creating multiple Gentoo
> packages from the same PyPI package (see e.g. dev-python/ensurepip-*).
> Then, there are of course Python packages that aren't published on PyPI.
>
> Still, I think as a general rule of thumb this would make sense. WDYT?
>
To add a data point, the "Flask-Babel" package has been renamed to
"flask-babel" upstream today. Unfortunately, minor changes to names are
not that uncommon (pkgcheck regularly catches them via "mismatched"
remote-ids). This also means that now this one package is inconsistent
with the rest of capitalized "Flask" packages.
In the end, I'm still not sure whether this policy really makes sense.
Perhaps it should be relaxed to allow case mismatches, if only to allow
us to retain in-tree consistency when upstreams fail to be consistent.
However, there's a can of worms around the corner -- should we also
allow normalizing "-" and "_" across different packages (see dev-
python/sphinx*)?
Now you see why we didn't have a policy for this before.
--
Best regards,
Michał Górny
[gentoo-dev] Re: Last rites: app-admin/gkrellm & plugins
Philip Webb posted on Fri, 27 Jan 2023 12:58:43 -0500 as excerpted: > 230127 Michał Górny wrote: >> # GKrellM and a variety of plugins. >> # Removal on 2023-02-26. Bug #892251. >> app-admin/gkrellm [and plugins, etc.] > Is there a recommended alternative ? app-admin/conky It's currently gtk3, but at least with lua-cairo enabled, X-only. However, upstream is alive and wayland-native support is apparently in the works (tho it has been some months since I last checked status), so doesn't appear to be death-bed either. I use it here, altho I wasn't satisfied with built-in only so learned lua (designed for embedding, exactly what conky uses it for) and wrote my own conky lua themes. Seems extensibility is mandatory for flexibility (handling decent detail at readable size without going fullscreen) for this sort of app, and I've learned the extensibility language of more than one such app (RIP superkaramba!) as they've gone dead over the years, but with conky alive and working on wayland-native support, hopefully it'll stick around for awhile. Meanwhile, email me privately if you're interested in a lua-based conky theme that can handle for example per-thread user/nice/system/freq (extensible to steal... if you're doing VMs) at "readble but not entire screen" sizes with AMD's 64-core/128-thread threadripper in mind (tho I'm still on an old 6-thread ATM so expanding that big likely has bugs to work out), or just for general conky discussion/questions, if you want. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
