On Mon, Sep 27, 2021 at 1:20 PM Michał Górny wrote:
> + eqawarn
> + eqawarn "It is impossible to reliably guarantee that the
> extended attributes"
> + eqawarn "will be reliably preserved while merging. Please
> ensure that any"
> +
On Mon, Sep 27, 2021 at 1:20 PM Michał Górny wrote:
>
> Warn the developers if ebuilds install files with xattrs to ${ED}.
> The xattrs may or may not be preserved when installing the package,
> making them unreliable on one hand, and somewhat suprising in other
> cases (e.g. when they
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
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
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
(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
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
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
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
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
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
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
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
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
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
> 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.
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,
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
> 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
Warn the developers if ebuilds install files with xattrs to ${ED}.
The xattrs may or may not be preserved when installing the package,
making them unreliable on one hand, and somewhat suprising in other
cases (e.g. when they unintentionally leak from developer's system).
This is the first step
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
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
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.
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
> On Sat, 04 Sep 2021, Ulrich Müller wrote:
> PMS says about eend: "Takes one fixed argument, which is a numeric
> return code, and an optional message in all subsequent arguments."
Pushed.
signature.asc
Description: PGP signature
On Mon, 2021-09-27 at 12:49 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 26 Sep 2021, Michał Górny wrote:
>
> > Symlinking FILESDIR into the work tree has the unintended
> > consequence
> > of preserving all original file metadata, including system-specific
> > ACLs
> > and so on. When these
> On Sun, 26 Sep 2021, Michał Górny wrote:
> Symlinking FILESDIR into the work tree has the unintended consequence
> of preserving all original file metadata, including system-specific ACLs
> and so on. When these files are installed, this could lead to
> unintentionally copying this
33 matches
Mail list logo
