Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote: > On 19-02-19 22:05:02, Brian Dolbec wrote: > > On Tue, 19 Feb 2019 23:03:51 -0600 > > Matthew Thode wrote: > > > > > On 19-02-20 00:00:04, Michael Orlitzky wrote: > > > > On 2/19/19 11:21 PM, Matthew Thode wrote: > > > > > > > > > > > > What problem would this solve? (Is adding gentoo-keys to @system > > > > > > the least bad way to solve it?) > > > > > > > > > > > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > > > > portage tarballs. This is useful for the initial sync (as called > > > > > out in our manual). Otherwise using emerge-webrsync could be > > > > > mitm'd or otherwise messed with. > > > > > > > > Ok, then I agree with the goal if not the solution. This is a > > > > portage-specific thing, namely > > > > > > > > FEATURES=webrsync-gpg > > > > > > > > that should be enabled by default on a stage3. (Making new users go > > > > out of their way to add basic security is daft.) Portage already has > > > > USE=rsync-verify, and I think we could either > > > > > > > > a) expand the meaning of that flag to include enabling > > > > webrsync-gpg by default, and to pull in gentoo-keys; or > > > > > > > > b) add another (default-on) flag like USE=webrsync-verify to do it > > > > > > > > That flag would be enabled by default, so gentoo-keys would be > > > > pulled in as part of @system without actually being *in* the > > > > @system. Something along those lines would achieve the same goal in > > > > a cleaner way. > > > > > > > > > > > > > > This worksforme (optional, default enabled dep of portage with a > > > default feature flag change). > > > > > > > > As far how we treat deps of @system packages, since this does not > > > > > have any deps that should help check that box for anyone > > > > > worried. > > > > > > > > I meant the other way around. Once gentoo-keys is in @system, > > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. > > > > There's no real policy or consensus on the matter, and it makes it > > > > a real PITA if we ever want to remove things from @system, because > > > > lots of packages will break in unpredictable ways. > > > > > > > > > > Ah, ya, that makes sense. > > > > > > > One of the things that releng has bantered about the last few years is > > making a stage4 with these extra non @system pkgs. The stage4 would > > allow all the extra pkgs needed for new installs without adding to > > @system. The system set could possibly be trimmed a little more then > > too. Then knowledgeable users could work with minimal stage3's when it > > suits their purpose while new users doing installs get the advantage of > > the additional pre-installed pkgs. > > > > Ok, after setting that up portage wants to update pgp keys, which fail > because keyservers suck. It doesn't look like we can change the > keyservers or disable the update entirely but we can set the retries to > 0 (which better disable it...). Robbat2 had a patch to allow disabling > the update but it doesn't look like it was applied. > Disabling that means entirely killing the verification as it'd happily use a revoked key. Keyservers were supposed not to suck anymore. Are you sure it's not misconfigured network? Maybe it's got broken-but-pretended IPv6? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On 02/20/19 02:36, Michał Górny wrote:
> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>>
>>
>>> # Don't install libtool archives (even for modules)
>>> - prune_libtool_files --all
>>> + find "${D}" -name '*.la' -delete || die
>>
>> Maybe restrict removal to regular files, i.e. add "-type f"?
>
> I suppose you should have spoken up when people started adopting that
> 'find' line all over the place. Though I honestly doubt we're going to
> see many packages installing '*.la' non-files.
>
Just so we are all clear here: your argument is that more fully correct
approaches should not be considered in the present and future because
less fully correct approaches were implemented in the past? And,
further, that since nothing matching a specific pattern happens to come
to your mind at he moment, such things do not exist? Perhaps dialing
back the rhetoric from 11 and considering feedback as an opportunity to
improve existing code is called for in this case, among others.
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-22 22:19:54, Rich Freeman wrote: > On Fri, Feb 22, 2019 at 9:58 PM Matthew Thode > wrote: > > > > Ok, after setting that up portage wants to update pgp keys, which fail > > because keyservers suck. It doesn't look like we can change the > > keyservers or disable the update entirely but we can set the retries to > > 0 (which better disable it...). Robbat2 had a patch to allow disabling > > the update but it doesn't look like it was applied. > > I assume that it proceeds after some timeout? Or does it completely > bail? IMO failing successful makes more sense though it is less > secure. > > It definitely makes sense to attempt a keyserver update since that is > going to be the mechanism to catch key revocations. It also will make > life easier on users using an older stage3 that happens to have > expired keys. Well, assuming the keyserver works... > Na, times out the build (1.5 hour gate time...). It retried nine times... I agree that updating is best, but nine times? http://logs.openstack.org/02/608102/12/check/openstack-ansible-functional-gentoo-17-0-systemd/f866472/logs/host/lxc-cache-prep-commands.log.txt.gz -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On Fri, Feb 22, 2019 at 9:58 PM Matthew Thode wrote: > > Ok, after setting that up portage wants to update pgp keys, which fail > because keyservers suck. It doesn't look like we can change the > keyservers or disable the update entirely but we can set the retries to > 0 (which better disable it...). Robbat2 had a patch to allow disabling > the update but it doesn't look like it was applied. I assume that it proceeds after some timeout? Or does it completely bail? IMO failing successful makes more sense though it is less secure. It definitely makes sense to attempt a keyserver update since that is going to be the mechanism to catch key revocations. It also will make life easier on users using an older stage3 that happens to have expired keys. Well, assuming the keyserver works... -- Rich
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-19 22:05:02, Brian Dolbec wrote: > On Tue, 19 Feb 2019 23:03:51 -0600 > Matthew Thode wrote: > > > On 19-02-20 00:00:04, Michael Orlitzky wrote: > > > On 2/19/19 11:21 PM, Matthew Thode wrote: > > > >> > > > >> What problem would this solve? (Is adding gentoo-keys to @system > > > >> the least bad way to solve it?) > > > >> > > > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > > > portage tarballs. This is useful for the initial sync (as called > > > > out in our manual). Otherwise using emerge-webrsync could be > > > > mitm'd or otherwise messed with. > > > > > > Ok, then I agree with the goal if not the solution. This is a > > > portage-specific thing, namely > > > > > > FEATURES=webrsync-gpg > > > > > > that should be enabled by default on a stage3. (Making new users go > > > out of their way to add basic security is daft.) Portage already has > > > USE=rsync-verify, and I think we could either > > > > > > a) expand the meaning of that flag to include enabling > > > webrsync-gpg by default, and to pull in gentoo-keys; or > > > > > > b) add another (default-on) flag like USE=webrsync-verify to do it > > > > > > That flag would be enabled by default, so gentoo-keys would be > > > pulled in as part of @system without actually being *in* the > > > @system. Something along those lines would achieve the same goal in > > > a cleaner way. > > > > > > > > > > This worksforme (optional, default enabled dep of portage with a > > default feature flag change). > > > > > > As far how we treat deps of @system packages, since this does not > > > > have any deps that should help check that box for anyone > > > > worried. > > > > > > I meant the other way around. Once gentoo-keys is in @system, > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. > > > There's no real policy or consensus on the matter, and it makes it > > > a real PITA if we ever want to remove things from @system, because > > > lots of packages will break in unpredictable ways. > > > > > > > Ah, ya, that makes sense. > > > > One of the things that releng has bantered about the last few years is > making a stage4 with these extra non @system pkgs. The stage4 would > allow all the extra pkgs needed for new installs without adding to > @system. The system set could possibly be trimmed a little more then > too. Then knowledgeable users could work with minimal stage3's when it > suits their purpose while new users doing installs get the advantage of > the additional pre-installed pkgs. > Ok, after setting that up portage wants to update pgp keys, which fail because keyservers suck. It doesn't look like we can change the keyservers or disable the update entirely but we can set the retries to 0 (which better disable it...). Robbat2 had a patch to allow disabling the update but it doesn't look like it was applied. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] eclass/java-utils-2: switch to eapi7-ver
On Thu, Feb 21, 2019 at 03:30:32PM +0100, Andreas Sturmlechner wrote:
> On Montag, 17. Dezember 2018 09:09:13 CET Marty E. Plummer wrote:
> > @@ -15,7 +15,7 @@
> > # you should inherit java-pkg-2 for Java packages or java-pkg-opt-2 for
> > packages # that have optional Java support. In addition you can inherit
> > java-ant-2 for # Ant-based packages.
> > -inherit eutils versionator multilib
> > +inherit eutils multilib
>
> I would recommend to keep inheriting all those eclasses (including
> versionator) for EAPI 0-6, in order not to break revdeps with implicit use.
> Who knows in what shape they are, and no one is going to fix them for a long
> time. But we don't want to inherit any of them with EAPI-7, hence merge it
> with below hunk.
>
Yeah, I came to the same conclusion when I suggested a move from
versionator to eapi7-ver for gnome.org.eclass and it had implicit deps
on versionator in its consumers.
> > @@ -25,6 +25,9 @@ export WANT_JAVA_CONFIG="2"
> > # Prefix variables are only available for EAPI>=3
> > has "${EAPI:-0}" 0 1 2 && ED="${D}" EPREFIX= EROOT="${ROOT}"
> >
> > +# EAPI 7 has version functions built-in. Use eapi7-ver for all earlier
> > eclasses.
> > +[[ ${EAPI} == [0123456] ]] && inherit eapi7-ver
> > +
> > # @VARIABLE: JAVA_PKG_E_DEPEND
> > # @INTERNAL
> > # @DESCRIPTION:
>
>
> Regards,
> Andreas
>
>
>
Re: [gentoo-dev] wayland category
Ühel kenal päeval, R, 22.02.2019 kell 13:55, kirjutas Matthew Thode: > On 19-02-16 18:12:26, Aaron Bauman wrote: > > On Sat, Feb 16, 2019 at 06:04:54PM -0500, Aaron Bauman wrote: > > > On Sun, Feb 17, 2019 at 12:56:52AM +0200, Mart Raudsepp wrote: > > > > Wildcards aren't allowed in category names. Do you mean gui- > > > > misc, gui- > > > > apps, gui-wm, gui-libs, or what? > > > > > > > > > > > > Mart > > > > > > Correct, examples would be: > > > > > > gui-libs/wlroots > > > gui-wm/sway > > > gui-apps/swaylock > > > gui-apps/sway > > > > > > > The last example should read gui-apps/swayidle > > > > These all seem good to me, I'll commit it sometime over the weekend > if > no one objects (and pkg move it in updates/1Q-2019) I believe Aaron mentioned one of these isn't really an "app"; I think swayidle and/or swaylock. Otherwise thumbs up for adding gui-libs, gui-wm and gui-apps categories. I'm not sure if we can find a better place than a gui-misc/ for these non-apps (gui-plugins or something?) Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] wayland category
On 19-02-16 18:12:26, Aaron Bauman wrote: > On Sat, Feb 16, 2019 at 06:04:54PM -0500, Aaron Bauman wrote: > > On Sun, Feb 17, 2019 at 12:56:52AM +0200, Mart Raudsepp wrote: > > > Wildcards aren't allowed in category names. Do you mean gui-misc, gui- > > > apps, gui-wm, gui-libs, or what? > > > > > > > > > Mart > > > > Correct, examples would be: > > > > gui-libs/wlroots > > gui-wm/sway > > gui-apps/swaylock > > gui-apps/sway > > > > The last example should read gui-apps/swayidle > These all seem good to me, I'll commit it sometime over the weekend if no one objects (and pkg move it in updates/1Q-2019) -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-19 21:23:33, Matthew Thode wrote: > As the title says, I think this should be done. > > First sync is impossible to verify without keys (webrsync) > app-crypt/gentoo-keys has no dependencies, which help avoid some bloat > in the base install. > > Let the bikeshedding begin. > Looks like it's a docs problem. https://bugs.gentoo.org/671816 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support
On Tue, 19 Feb 2019 22:46:23 -0800 Matt Turner wrote: > On Tue, Feb 19, 2019 at 10:24 PM Ulrich Mueller wrote: > > > > > On Wed, 20 Feb 2019, Matt Turner wrote: > > > > > Nearly all the work is just removing uses of autotools-multilib and > > > autotools-utils. The new code should work in EAPI 4 and 5. Don't add > > > support for EAPI 6; that ship has already sailed. > > > > AFAICS, adding EAPI 6 support wouldn't require any additional code? > > I think that is true. (I have no strong preference on whether to add > EAPI 6 support. I just figured that anything that gets an EAPI bump > now should go to the latest available) This is not always possible. E.g. I have a package with optional java support. Since java is still EAPI 6 I can't use EAPI 7. Best regards, Andrew Savchenko pgpKvbXTHcFp8.pgp Description: PGP signature
