On Mon, Sep 27, 2021 at 11:47:38PM +0200, Michał Górny wrote:
> > Can we consider moving the checks for set A somewhere else, such that we
> > don't check the kernel config during package compile & install time, but
> > only check it later? This also meaningfully resolves that cases where
> > the s
Deadline for responses: 2021/10/14!
The Foundation would like to propose that RedHat/Fedora "hobble" patch
presently applied when USE=bindist is true shall be removed from
dev-libs/openssl.
RedHat's stated reasons for the patch were originally to avoid any patent
concerns, but they have also morp
On Mon, 2021-09-27 at 19:14 +, Robin H. Johnson wrote:
> I wanted to break the prior thread to discuss the root issue.
>
> We have some set of packages (A) which collectively depend on one or
> more kernel options being set in specific ways, and the options need to
> REMAIN set if you want the
(This is all tangential to the main issue of this thread and just
discussing internet history - skip as you wish...)
On Mon, Sep 27, 2021 at 2:14 PM Marek Szuba wrote:
>
> I am no expert on US law but from what I have read (in many different
> sources, with me having begun using PGP in either lat
Mike Gilbert wrote:
> > > It's a waste of time and effort to pepper random ebuilds with checks
> > > for options that everyone should have enabled in the first place.
> >
> > It's not for you to say what everyone should have enabled in their kernel.
>
> Do you not agree that there are some options
On Mon, Sep 27, 2021 at 4:28 PM Jason A. Donenfeld wrote:
>
> On Mon, Sep 27, 2021 at 11:44 AM Robin H. Johnson wrote:
> > I think we need to strip out a lot of the crap about trying to detect
> > things in the stuff being built, and reduce the check to the simplest
> > possible form:
> > $ time
On Mon, Sep 27, 2021 at 11:44 AM Robin H. Johnson wrote:
> I think we need to strip out a lot of the crap about trying to detect
> things in the stuff being built, and reduce the check to the simplest
> possible form:
> $ time zgrep -w CONFIG_PACKET /proc/config.gz
> CONFIG_PACKET=y
The results f
On Mon, Sep 27, 2021 at 3:11 PM Peter Stuge wrote:
>
> Mike Gilbert wrote:
> > It's a waste of time and effort to pepper random ebuilds with checks
> > for options that everyone should have enabled in the first place.
>
> It's not for you to say what everyone should have enabled in their kernel.
Robin H. Johnson wrote:
> We have some set of packages (A) which collectively depend on one or
> more kernel options being set in specific ways, and the options need to
> REMAIN set if you want the packages to continue work.
..
> Can we consider moving the checks for set A somewhere else, such that
I wanted to break the prior thread to discuss the root issue.
We have some set of packages (A) which collectively depend on one or
more kernel options being set in specific ways, and the options need to
REMAIN set if you want the packages to continue work.
There are also a subset of packages (B),
Mike Gilbert wrote:
> It's a waste of time and effort to pepper random ebuilds with checks
> for options that everyone should have enabled in the first place.
It's not for you to say what everyone should have enabled in their kernel.
There's significant value in ebuilds documenting required kerne
On Mon, Sep 27, 2021 at 1:56 PM Rich Freeman wrote:
>
> On Mon, Sep 27, 2021 at 1:44 PM Robin H. Johnson wrote:
> >
> > I think we need to strip out a lot of the crap about trying to detect
> > things in the stuff being built, and reduce the check to the simplest
> > possible form:
> > $ time zgr
On Mon, Sep 27, 2021 at 12:23 PM Mike Pagano wrote:
>
> On 9/27/21 12:10 PM, Mike Gilbert wrote:
> > I'm looking to solicit opinions on when it is appropriate for an
> > ebuild to check for kernel config options using linux-info.eclass. I
> > don't think we have any guidelines documented, instead
On 9/27/21 2:15 PM, Mike Gilbert wrote:
On Mon, Sep 27, 2021 at 1:44 PM Robin H. Johnson wrote:
On Mon, Sep 27, 2021 at 01:15:10PM -0400, Mike Gilbert wrote:
On Mon, Sep 27, 2021 at 12:23 PM Mike Pagano wrote:
Adding linux-info calls to pkg_pretend or pkg_setup causes slowdowns
when running
On Mon, Sep 27, 2021 at 1:44 PM Robin H. Johnson wrote:
>
> On Mon, Sep 27, 2021 at 01:15:10PM -0400, Mike Gilbert wrote:
> > On Mon, Sep 27, 2021 at 12:23 PM Mike Pagano wrote:
> > > > Adding linux-info calls to pkg_pretend or pkg_setup causes slowdowns
> > > > when running emerge, so we should
On 2021-09-26 21:20, Rich Freeman wrote:
Back in the PGP ITAR days I believe somebody went through some
loopholes to publish the software outside the US,
Yes, PGP 2.6 source code got published as an OCR-friendly book
(https://dl.acm.org/doi/book/10./207390) which was then legally
taken f
On Mon, 2021-09-27 at 20:01 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 27 Sep 2021, Michał Górny wrote:
>
> > You seem to be missing the fact that all of them hardcode "bzr".
>
> Yes, and it is updated to "brz" in a followup commit. Would you prefer
> leaving them as "bzr"? I guess that bac
> On Mon, 27 Sep 2021, Michał Górny wrote:
> You seem to be missing the fact that all of them hardcode "bzr".
Yes, and it is updated to "brz" in a followup commit. Would you prefer
leaving them as "bzr"? I guess that backwards compatibility link will
stay there for a long time.
signature.as
On Mon, Sep 27, 2021 at 1:44 PM Robin H. Johnson wrote:
>
> I think we need to strip out a lot of the crap about trying to detect
> things in the stuff being built, and reduce the check to the simplest
> possible form:
> $ time zgrep -w CONFIG_PACKET /proc/config.gz
> CONFIG_PACKET=y
>
Sure, just
On Mon, 2021-09-27 at 19:25 +0200, Ulrich Mueller wrote:
> > > > > > On Sat, 25 Sep 2021, Michał Górny wrote:
>
> > > +EBZR="bzr.eclass"
>
> > Why do we need this? It seems as if someone is reinventing
> > ${ECLASS}.
>
> Replaced by ${ECLASS}.
>
> > > +# @ECLASS-VARIABLE: EBZR_STORE_DIR
>
> >
On Mon, Sep 27, 2021 at 01:15:10PM -0400, Mike Gilbert wrote:
> On Mon, Sep 27, 2021 at 12:23 PM Mike Pagano wrote:
> > > Adding linux-info calls to pkg_pretend or pkg_setup causes slowdowns
> > > when running emerge, so we should do so only when there is a
> > > compensating benefit.
> >
> > Is t
> On Sat, 25 Sep 2021, Michał Górny wrote:
>> +EBZR="bzr.eclass"
> Why do we need this? It seems as if someone is reinventing ${ECLASS}.
Replaced by ${ECLASS}.
>> +# @ECLASS-VARIABLE: EBZR_STORE_DIR
> @USER_VARIABLE?
Added.
>> +# @DESCRIPTION:
>> +# The directory to store all fetched Ba
On Mon, Sep 27, 2021 at 12:23 PM Mike Pagano wrote:
> > Adding linux-info calls to pkg_pretend or pkg_setup causes slowdowns
> > when running emerge, so we should do so only when there is a
> > compensating benefit.
>
> Is this a significant slowdown? Do you have any numbers?
Adding a check for C
On 27/09/21 18:10, Mike Gilbert wrote:
> I'm looking to solicit opinions on when it is appropriate for an
> ebuild to check for kernel config options using linux-info.eclass. I
> don't think we have any guidelines documented, instead leaving it up
> to the "common sense" of package maintainers.
>
On 9/25/21 9:28 PM, Arthur Zamarin wrote:
> - mark _distutils-r1_check_all_phase_mismatch as @INTERNAL
> - fix list appearance for distutils_enable_tests options
>
> Signed-off-by: Arthur Zamarin
> ---
> eclass/distutils-r1.eclass | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/ecl
On 9/27/21 12:10 PM, Mike Gilbert wrote:
I'm looking to solicit opinions on when it is appropriate for an
ebuild to check for kernel config options using linux-info.eclass. I
don't think we have any guidelines documented, instead leaving it up
to the "common sense" of package maintainers.
Adding
I'm looking to solicit opinions on when it is appropriate for an
ebuild to check for kernel config options using linux-info.eclass. I
don't think we have any guidelines documented, instead leaving it up
to the "common sense" of package maintainers.
Adding linux-info calls to pkg_pretend or pkg_set
27 matches
Mail list logo
