[gentoo-dev] [PATCH] multilib.eclass: populate AR and NM in multilib_toolchain_setup(), bug #724558

[Sergei Trofimovich]

For both multilib and non-multilib profiles binutils provides
tools with native ABI prefix only. For example on amd64 there
is only 'x86_64-pc-linux-gnu-nm' and 'nm'.

On abi_x86_32 tools are usually configured with --host=i686-pc-linux-gnu.
Configure tries i686-pc-linux-gnu-nm, then falls back to 'nm'.

The change overrides NM to 'x86_64-pc-linux-gnu-nm' for
multilib setup similar to other environment variables.

Reported-by: Kent Fredric
Closes: https://bugs.gentoo.org/724558
Signed-off-by: Sergei Trofimovich 
---
 eclass/multilib.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index bbaab709b4f..25e90dea44c 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -484,11 +484,13 @@ multilib_toolchain_setup() {
# Set the CHOST native first so that we pick up the native
# toolchain and not a cross-compiler by accident #202811.
export CHOST=$(get_abi_CHOST ${DEFAULT_ABI})
+   export AR="$(tc-getAR)" # Avoid 'ar', use '${CHOST}-ar'
export CC="$(tc-getCC) $(get_abi_CFLAGS)"
export CXX="$(tc-getCXX) $(get_abi_CFLAGS)"
export F77="$(tc-getF77) $(get_abi_CFLAGS)"
export FC="$(tc-getFC) $(get_abi_CFLAGS)"
export LD="$(tc-getLD) $(get_abi_LDFLAGS)"
+   export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
-- 
2.26.2

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Peter Stuge]

Stop motivated attackers or keep low barrier to entry; pick any one. :)

Michał Górny wrote:
> CAPTCHA
> ==
> A traditional way of dealing with spam -- require every new system
> identifier to be confirmed by solving a CAPTCHA (or a few identifiers
> for one CAPTCHA).
> 
> The advantage of this method is that it requires a real human work to be
> performed, effectively limiting the ability to submit spam.
> The disadvantage is that it is cumbersome to users, so many of them will
> just resign from participating.

While services such as reCAPTCHA are (as said) massively intrusive, there
are other, much less intrusive and even terminal-compatible ways to construct
a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle
for a human above the response input line - that's not so bad.

Attacking something like a server-generated maths challenge rendered in a
randomly chosen and maybe distorted font would require OCR and/or ML, which
is fairly annoying. The only real problem then would be with OCR packages. ;)

Combine with a rate limit that is increased manually as the service grows
more popular. It can be a soft limit which doesn't report failure but results
in queueing+maybe vetting of reports, to allow some elasticity for peaks.


//Peter

[gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

[Sergei Trofimovich]

'tc-directly' tracker https://bugs.gentoo.org/243502 tracks
packages that don't respect users' CC/AR/LD flags.

I added new USE=-native-symlinks mode for gcc-config and
binutils-config to ease detection of such packages.

Native symlinks are still installed by default. Nothing should
break for users who use default USE flags.

USE=-native-symlinks removes a bunch of links that most packages
use by default until are overridden explicitly. Incomplete list is:
- /lib/cpp
- /usr/bin/{gcc,cc,g++,c++,...}
- /usr/bin/{as,ld,ranlib,dwp,...}

The rule of thumb is: if a tool does not have ${CTARGET}- prefix
it will probably disappear with USE=-native-symlinks.

(At least eventually) 'emerge' should still be able to build most
of packages in such environment. I expect initial breakage will be
huge though.

Using './configure && make && make install' style workflow will be more
tedious. One workaround at least for gcc is to use something like:
$ PATH="$(gcc-config -B):$PATH"
It's not perfect. We'll see if toolchain can provide nicer environment.

Typical fixes for autoconf style build systems is to use macros like:
- AC_PROG_CC
- AM_PROG_AR
- AC_CHECK_TOOL(DWP, dwp)
and so on to detect tool that corresponds to --host=/--target= flags
and allows user's override via environment variable.

-- 

  Sergei

[gentoo-dev] [RFC] Bootloader use in eclean-kernel

[Michał Górny]

Hi, everyone.

I've finally found some time to revive eclean-kernel, and I'm having
some doubts about the way bootloaders are used (in ek1).  I'd like to
hear your opinion on whether the old behavior should be kept or removed
in favor of more-like-ek2 behavior.

Originally, ek1 assumed that we shouldn't normally remove kernels that
are listed in the bootloader.  It made sense back in the day when I was
using LILO, and it just took whatever was linked to /boot/vmlinuz{,.old}
and ek removed the rest.  Today, it makes less sense with bootloaders
like GRUB2 or systemd-boot that normally just use all installed kernels.

Alternatively, ek1 had destructive mode (a misnomer probably) that just
kept N newest kernels and removed older.  This is also the behavior
exhibited by ek2 (since I've never gotten to implement bootloaders).

The truth is, the bootloader support code in ek1 is ugly and needs
a major refactoring.  However, I'm wondering whether it's worth
the effort or if I should just remove it altogether.

Hence my question: do you find 'do not remove kernels listed
in bootloader config' feature useful?  Do you think it should remain
the default?  Do you think it is worthwhile to continue supporting it?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Anti-spam for goose

[John Helmert III]

On Fri, May 22, 2020 at 12:53:03PM -0700, Brian Dolbec wrote:
> We cannot exclude overlays which will have cat/pkg not in the main
> gentoo repo.  So, we should not excludea submission that includes a few
> of these.

To avoid this problem, even if imperfectly, it should be possible to
track what repository a given package is installed from and then check
its validity based on a list of valid packages for a given overlay.


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Michał Górny]

On Sat, 2020-05-23 at 07:20 +1200, Kent Fredric wrote:
> On Thu, 21 May 2020 10:47:07 +0200
> Michał Górny  wrote:
> 
> > Other ideas
> > ===
> > Do you have any other ideas on how we could resolve this?
> 
> And a question I'd like to revisit, because nobody responded to it:
> 
> - What are the incentives a would-be spammer has to spam this service.
> 
> Services that see spam *typically* have a definable objective.
> 
> *Typically* it revolves around the ability to submit /arbitrary text/,
> which allows them to hawk something, and this becomes a profit motive.
> 
> If we implement data validation so that there's no way for them to
> profit off what they spam, seems likely they'll be less motivated to
> develop the necessary circumvention tools. ( as in, we shouldn't accept
> arbitrary CAT/PN pairs as being valid until something can confirm those
> pairs exist in reality )
> 
> There may be people trying to jack the data up, but ... it seems a less
> worthy target.
> 
> So it seems the largest risk isn't so much "spam", but "denial of
> service", or "data pollution".

I've meant 'spam' as 'undesired submissions'.  You seem to have used
a very narrow definition of 'spam' to argue into reaching the same
problem under different name.

Let's put it like this.  This thing starts working.  Package X is
broken, and we see that almost nobody is using it.  We remove that
package.  Now somebody is angry.  He submits a lot of fake data to
render the service useless so that we don't make any future decisions
based on it.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Brian Dolbec]

On Sat, 23 May 2020 07:20:22 +1200
Kent Fredric  wrote:

> On Thu, 21 May 2020 10:47:07 +0200
> Michał Górny  wrote:
> 
> > Other ideas
> > ===
> > Do you have any other ideas on how we could resolve this?  
> 
> And a question I'd like to revisit, because nobody responded to it:
> 
> - What are the incentives a would-be spammer has to spam this service.
> 
> Services that see spam *typically* have a definable objective.
> 
> *Typically* it revolves around the ability to submit /arbitrary text/,
> which allows them to hawk something, and this becomes a profit motive.
> 
> If we implement data validation so that there's no way for them to
> profit off what they spam, seems likely they'll be less motivated to
> develop the necessary circumvention tools. ( as in, we shouldn't
> accept arbitrary CAT/PN pairs as being valid until something can
> confirm those pairs exist in reality )
> 
> There may be people trying to jack the data up, but ... it seems a
> less worthy target.
> 
> So it seems the largest risk isn't so much "spam", but "denial of
> service", or "data pollution".
> 
> Of course, we should still mitigate, but /how/ we mitigate seems to
> pivot around this somewhat.

We cannot exclude overlays which will have cat/pkg not in the main
gentoo repo.  So, we should not excludea submission that includes a few
of these.  They would just become irrelevant outliers to our
processesing of the data.  In fact some of these outlier pkgs could be
relevant to our including that pkg into the main repo.

But, like you I agree that purely spam submissions would be few, if any.

[gentoo-dev] nginx: slot mainline

[Samuel Bernardo]

Hi,

I realize today that nginx ebuild have a new slot mainline. The current
ebuild stable version 1.17 came from mainline. Anyone knows if this
means that is not the stable version of nginx?

After reading the following blog post I couldn't understand what they
are doing now:

https://www.nginx.com/blog/nginx-1-6-1-7-released/

Thanks,

Samuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Kent Fredric]

On Thu, 21 May 2020 10:47:07 +0200
Michał Górny  wrote:

> Other ideas
> ===
> Do you have any other ideas on how we could resolve this?

And a question I'd like to revisit, because nobody responded to it:

- What are the incentives a would-be spammer has to spam this service.

Services that see spam *typically* have a definable objective.

*Typically* it revolves around the ability to submit /arbitrary text/,
which allows them to hawk something, and this becomes a profit motive.

If we implement data validation so that there's no way for them to
profit off what they spam, seems likely they'll be less motivated to
develop the necessary circumvention tools. ( as in, we shouldn't accept
arbitrary CAT/PN pairs as being valid until something can confirm those
pairs exist in reality )

There may be people trying to jack the data up, but ... it seems a less
worthy target.

So it seems the largest risk isn't so much "spam", but "denial of
service", or "data pollution".

Of course, we should still mitigate, but /how/ we mitigate seems to
pivot around this somewhat.


pgpsx5km9Qpj3.pgp
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] kernel-2.eclass: avoid lexicographical compare on versions, bug #705246

[Sergei Trofimovich]

Originally found in bug #705240 as:

```
if [[ ... || ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.28 ]]; then
```

'>' are string comparisons. They are benign so far, but
will start failing on linux-10 :)

Let's be consistent and use version comparison.

CC: ker...@gentoo.org
Closes: https://bugs.gentoo.org/705246
Signed-off-by: Sergei Trofimovich 
---
 eclass/kernel-2.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 07af8d8ab2c..d69182045c5 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1015,7 +1015,7 @@ postinst_sources() {
#   K_SECURITY_UNSUPPORTED=deblob
 
# if we are to forcably symlink, delete it if it already exists first.
-   if [[ ${K_SYMLINK} > 0 ]]; then
+   if [[ ${K_SYMLINK} -gt 0 ]]; then
[[ -h ${EROOT}usr/src/linux ]] && { rm "${EROOT}"usr/src/linux 
|| die; }
MAKELINK=1
fi
@@ -1078,7 +1078,7 @@ postinst_sources() {
KV_PATCH=$(ver_cut 3 ${OKV})
if [[ "$(tc-arch)" = "sparc" ]]; then
if [[ $(gcc-major-version) -lt 4 && $(gcc-minor-version) -lt 4 
]]; then
-   if [[ ${KV_MAJOR} -ge 3 || 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.24 ]] ; then
+   if [[ ${KV_MAJOR} -ge 3 || ver_test 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} -gt 2.6.24 ]] ; then
echo
elog "NOTE: Since 2.6.25 the kernel Makefile 
has changed in a way that"
elog "you now need to do"
@@ -1272,7 +1272,7 @@ unipatch() {
# do not apply fbcondecor patch to sparc/sparc64 as it breaks boot
# bug #272676
if [[ "$(tc-arch)" = "sparc" || "$(tc-arch)" = "sparc64" ]]; then
-   if [[ ${KV_MAJOR} -ge 3 || ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} 
> 2.6.28 ]]; then
+   if [[ ${KV_MAJOR} -ge 3 || ver_test 
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} -gt 2.6.28 ]]; then
if [[ ! -z ${K_WANT_GENPATCHES} ]] ; then
UNIPATCH_DROP="${UNIPATCH_DROP} 
*_fbcondecor*.patch"
echo
@@ -1521,7 +1521,7 @@ kernel-2_src_unpack() {
# fix a problem on ppc where TOUT writes to /usr/src/linux breaking 
sandbox
# only do this for kernel < 2.6.27 since this file does not exist in 
later
# kernels
-   if [[ -n ${KV_MINOR} &&  ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} < 2.6.27 
]] ; then
+   if [[ -n ${KV_MINOR} && ver_test ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} 
-lt 2.6.27 ]] ; then
sed -i \
-e 's|TOUT  := .tmp_gas_check|TOUT  := 
$(T).tmp_gas_check|' \
"${S}"/arch/ppc/Makefile
-- 
2.26.2

[gentoo-dev] [PATCH] linux-info.eclass: avoid lexicographical compare on numbers, bug #705248

[Sergei Trofimovich]

Originally found in bug #705240 as:

```
  error=0
  ...
  if [[ ${error} > 0 ]]; then
  ...
```

'>' are string comparisons. They are benign in this case, but let's
be consistent and use integer comparison.

CC: ker...@gentoo.org
Closes: https://bugs.gentoo.org/705248
Signed-off-by: Sergei Trofimovich 
---
 eclass/linux-info.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 44eebcf52a9..405ef5571e1 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -813,7 +813,7 @@ check_extra_config() {
linux_chkconfig_present ${config} || error=1
fi
 
-   if [[ ${error} > 0 ]]; then
+   if [[ ${error} -gt 0 ]]; then
local report_func="eerror" local_error
local_error="ERROR_${config}"
local_error="${!local_error}"
@@ -848,14 +848,14 @@ check_extra_config() {
fi
done
 
-   if [[ ${hard_errors_count} > 0 ]]; then
+   if [[ ${hard_errors_count} -gt 0 ]]; then
eerror "Please check to make sure these options are set 
correctly."
eerror "Failure to do so may cause unexpected problems."
eerror "Once you have satisfied these options, please try 
merging"
eerror "this package again."
export 
LINUX_CONFIG_EXISTS_DONE="${old_LINUX_CONFIG_EXISTS_DONE}"
die "Incorrect kernel configuration options"
-   elif [[ ${soft_errors_count} > 0 ]]; then
+   elif [[ ${soft_errors_count} -gt 0 ]]; then
ewarn "Please check to make sure these options are set 
correctly."
ewarn "Failure to do so may cause unexpected problems."
else
-- 
2.26.2

Re: [gentoo-dev] [RFC] Anti-spam for goose

[waebbl]

Am Fr., 22. Mai 2020 um 15:40 Uhr schrieb Gordon Pettey <
petteyg...@gmail.com>:

> On Fri, May 22, 2020 at 1:18 AM waebbl  wrote:
>
>> Am Do., 21. Mai 2020 um 22:14 Uhr schrieb Viktar Patotski <
>> xp.vit@gmail.com>:
>>
>>> I believe that we are all have forgotten about Donald Knuth: Premature
>>> optimisation is the root of all evill.
>>>
>> I won't consider spam protection to be a optimisation. Instead, the
>> occurence of spam is IMO a proper use-case from a developers PoV. Therefore
>> thinking about how to handle it, is a necessary task.
>>
> Abusing Knuth's words as an excuse to avoid any and all good practice is
> the root of all evil.
>

Would you consider not even thinking about it a good practice?

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Gordon Pettey]

On Fri, May 22, 2020 at 1:18 AM waebbl  wrote:

> Am Do., 21. Mai 2020 um 22:14 Uhr schrieb Viktar Patotski <
> xp.vit@gmail.com>:
>
>> I believe that we are all have forgotten about Donald Knuth: Premature
>> optimisation is the root of all evill.
>>
> I won't consider spam protection to be a optimisation. Instead, the
> occurence of spam is IMO a proper use-case from a developers PoV. Therefore
> thinking about how to handle it, is a necessary task.
>
Abusing Knuth's words as an excuse to avoid any and all good practice is
the root of all evil.

Re: [gentoo-dev] [RFC] Anti-spam for goose

[waebbl]

Am Do., 21. Mai 2020 um 22:14 Uhr schrieb Viktar Patotski <
xp.vit@gmail.com>:

I believe that we are all have forgotten about Donald Knuth: Premature
> optimisation is the root of all evill.
>

I won't consider spam protection to be a optimisation. Instead, the
occurence of spam is IMO a proper use-case from a developers PoV. Therefore
thinking about how to handle it, is a necessary task.

--
With Regards
Bernd 

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Michał Górny]

On Fri, 2020-05-22 at 06:42 +0200, Michał Górny wrote:
> On Thu, 2020-05-21 at 22:13 +0200, Viktar Patotski wrote:
> > We don't have "spam" yet, but we are already trying to protect. There might
> > be cases when some systems will be posting stats more often than we want,
> > but probably that will not harm us. Or this will be done by our main users
> > who runs 1kk of gentoo installations and this "spam"  will be actually
> > valuable. Moreover, nobody forces us to treat info from 'goose' as first
> > priority, so we are still able to select on which packages to work. In
> > short: this topic is not so important yet, I think.
> > 
> 
> Tell that to SKS keyserver admins.  Well, on the plus side if it
> happens, it probably won't affect user systems in the process.

Well, I didn't make my point very clear, so please let me explain.

Right now the project is in experimental phase.  If we do major changes
right now, the harm is minimal.

If spamming happens one year from now, two years from now... we'd have
many users submitting data.  Suddenly, we would have to invent something
new, and it will probably be impossible within the framework used right
now.  This would most likely mean we'd have to literally kick all users
from the system and start over.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part