Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel
> On Fri, 22 May 2020, Michał Górny wrote: > 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? For GRUB, wouldn't the typical workflow remove old kernels first, and only then update grub.cfg? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel
On Friday, May 22, 2020, Michał Górny wrote: > 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 > > Hello, My flow is like: - install gentoo-sources - build kernel and install to /boot - eclean-kernel -d -n 2 - grub-config Tomas
Re: [gentoo-dev] nginx: slot mainline
On Friday, May 22, 2020, Samuel Bernardo wrote: > 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 > > > Features are added to the mainline branch, it can be broken from time to time. After it's tested it's merged into the stable branch. Mainline is like the dev branch and stable is like the master branch. If you need higher stability pick the stable releases, if you need new features pick the mainline releases. Tomas
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Fri, 2020-05-22 at 22:36 +0100, Sergei Trofimovich wrote: > '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. Does this list include 'ar' or not? Asking because there's been a number of false positives reported for 'ar' being used as an archiver (e.g. to work on .deb packages). -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] multilib.eclass: populate AR and NM in multilib_toolchain_setup(), bug #724558
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
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
'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
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
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
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
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
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
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
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
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
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
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.