Re: [gentoo-dev] verifying profiles/package.mask comment format
> On 21 Feb 2021, at 04:30, Tim Harder wrote: > > Hi all, > > Is there interest in enforcing some basic QA for the semi-formatted > comments in profiles/package.mask (and possibly other profiles file > types)? I have code implementing the basic functionality done for > pkgcheck, but wondered if the format should be standardized and > documented more than it may be already before support is merged. > I definitely have interest in this. Every so often, I find a class of mistakes like incorrectly-ordered masks, wrong email format, and so on, and fix them in the area I’m touching as it’s cheap to fix whatever file I’m on - not necessarily so to fix every single one in profiles/. This also gives us scope to make requirements like e.g. a bug reference, clear date for removal if last-rites, and generally be a bit more verbose by making clear what the expectations are for message content. (There is a clear benefit for last-rites having at least one bug — it gives users a chance to object or mention alternatives.) Anyway, not trying to bikeshed re last-rites process, I just mean there’s definitely a collection of uses here. Thanks for working on it. Note that this was brought up last month too by jstein, so there is definitely other interest: https://archives.gentoo.org/gentoo-dev/message/0600146362529770aa88225b29de46ae. > Also, I'm unsure it's been noticed but `pkgcheck scan --commits` now > verifies any profile changes done in git commits so this support would > automatically get run for package.mask changes (and other enabled files) > when using pkgcheck locally in that fashion. > > Thanks, > Tim > signature.asc Description: Message signed with OpenPGP
[gentoo-dev] verifying profiles/package.mask comment format
Hi all, Is there interest in enforcing some basic QA for the semi-formatted comments in profiles/package.mask (and possibly other profiles file types)? I have code implementing the basic functionality done for pkgcheck, but wondered if the format should be standardized and documented more than it may be already before support is merged. Also, I'm unsure it's been noticed but `pkgcheck scan --commits` now verifies any profile changes done in git commits so this support would automatically get run for package.mask changes (and other enabled files) when using pkgcheck locally in that fashion. Thanks, Tim
Re: [gentoo-dev] New project: binhost
On 2/13/21 4:53 PM, Zac Medico wrote: > On 2/13/21 4:37 PM, Zac Medico wrote: >> On 2/11/21 1:17 AM, Michał Górny wrote: >>> On Wed, 2021-02-10 at 19:51 +0100, Lars Wendler wrote: On Wed, 10 Feb 2021 19:57:48 +0200 Andreas K. Hüttel wrote: > Hi all, > > I'm announcing a new project here - "binhost" > > "The Gentoo Binhost project aims to provide readily installable, > precompiled packages for a subset of configurations, via central > binary package hosting. Currently we are still in the conceptual > planning stage. " > > https://wiki.gentoo.org/wiki/Project:Binhost > > If you're interested in helping out, feel free to add yourself on the > wiki page. > > Note that I see actually *building* the packages not as the central > point of the project (that could be e.g. a side effect of a > tinderbox). I'm more concerned about > * what configurations should we use > * what portage features are still needed or need improvements (e.g. > binpkg signing and verification) > * how should hosting look like > * and how we can test this on a limited scale before it goes "into > production" > * ... > > Comments, ideas, flamebaits? :D > > Cheers, > Andreas > It would be great to improve portage speed with handling binpkgs. I already have my own binhost for a couple of Gentoo systems and even though these systems don't have to compile anything themselves, installing ~100 to ~200 binpkgs takes way more than an hour of installation time. Arch Linux' pacman only takes a fraction of this time for the very same task. I know that I compare apples with pears here but even reducing the current portage time by 50% would be a huge improvement. >>> >>> Is that really a problem? For me, Portage takes about an hour just to >>> do the dependency processing these days. In fact, building from sources >>> is now faster than dependency calculations. >> >> The ratio of these times is dependent on the complexity of the >> dependencies involved, and so is the answer to your question. > > Also, in the context of binary packages, dependencies calculations are > generally simpler for binary packages because their USE conditionals and > slot-operator := dependencies are frozen in a particular state. This > dramatically reduces the search space involved in dependency calculation. IUSE_RUNTIME will obviously introduce conditionals in binary package dependencies, but we should welcome these conditionals because they will provide useful flexibility. I think IUSE_RUNTIME will be a very nice feature to have for project binhost, since it will allow binary package dependencies to behave with flexibility that more closely resembles the flexibility of ebuild dependencies. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: x11-misc/xbindkeys
Dear all the following packages are up for grabs after dropping desktop-misc: x11-misc/xbindkeys https://packages.gentoo.org/packages/x11-misc/xbindkeys There is an open PR https://github.com/gentoo/gentoo/pull/14706 -- Best, Jonas
[gentoo-dev] Packages up for grabs: x11-misc/xearth
Dear all the following packages are up for grabs after dropping desktop-misc: x11-misc/xearth https://packages.gentoo.org/packages/x11-misc/xearth Still uses EAPI 5 There are open bugs. Please take care of this package. -- Best, Jonas
[gentoo-dev] Packages up for grabs: x11-misc/wdm
Dear all the following packages are up for grabs after dropping desktop-misc: x11-misc/wdm https://packages.gentoo.org/packages/x11-misc/wdm There are open bugs. Upstream moved the repository to https://github.com/voins/wdm but the ebuild still relies on a dead SRC_URI The last commit upstream was 12 years ago. I do not know if wdm is still usable at all in a productive environment. This package can likely become a candidate for last rites soon. Please take care of this package. -- Best, Jonas
