Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On 5/24/20 5:41 AM, Mike Gilbert wrote: > Also, people are likely to disable this accidentally via USE="-*". Counts as > if they want to break their system intentionally. > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Fri, May 22, 2020 at 5:36 PM 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.
>
> (At least eventually) 'emerge' should still be able to build most
> of packages in such environment. I expect initial breakage will be
> huge though.
Could you please add this flag to package.use.force? I don't think we
want to give people the impression that this is a well-supported
configuration. I would only expect people to disable this if they want
to break their system intentionally.
Also, people are likely to disable this accidentally via USE="-*".
RE: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
> 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.
>
Do we currently have (or is there a plan for) a mechanism to manage the
symbolic links and/or create them after merging the package when necessary?
It's quite tiresome to type in $CHOST-gcc for simple everyday tasks.
Regards,
--
Pengcheng Xu
https://jsteward.moe
openpgp-digital-signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] linux-info.eclass: avoid lexicographical compare on numbers, bug #705248
On Sat, 23 May 2020 14:56:06 -0400
Mike wrote:
> On 5/22/20 2:57 PM, Sergei Trofimovich wrote:
> > 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
> >
>
> Thanks. LGTM
Pushed as:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa1d259decdfd73a49e0c49e88a8ec5675453266
--
Sergei
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Am 23.05.2020 um 23:46 schrieb Daniel Pielmeier: Hm correct me if I am wrong, but from looking at the patch Zac provided I think he meant that the time portage consumes is only one second while the "rest" is 3.2 seconds. So there is probably a potential in improving the "rest" somehow. Yes and no. The difference between the python and bash version is roughly 2 seconds. One second for importing portage (which Zac patched away) and another second for the rest of the portage stuff. So using the portage API adds two additional seconds. The python version needs 3.2 seconds on my system. As said the portage API (or better calling the portage API) consumes ~2 seconds. As this is the most time intense part the question is if there is a way to optimize this. Hope this is more clearly. I had fun anyway :) regards Daniel
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Am May 23, 2020 9:17:46 PM UTC schrieb Daniel Buschke : >Am 23.05.2020 um 22:55 schrieb Zac Medico: >> Since the portage API only added about 1 second to the python script >> time, I guess it's on par with your bash implementation. ;-P > >Yeah, if you substract the second for loading and the second for doing >queries, then yes, it's pretty par with the bash implementation :D Hm correct me if I am wrong, but from looking at the patch Zac provided I think he meant that the time portage consumes is only one second while the "rest" is 3.2 seconds. So there is probably a potential in improving the "rest" somehow. You see he exits after line 35 and until that not a lot happens besides all other imports, the argument parsing and the querying of the data. -- Best regards Daniel
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Am 23.05.2020 um 22:55 schrieb Zac Medico: Since the portage API only added about 1 second to the python script time, I guess it's on par with your bash implementation. ;-P Yeah, if you substract the second for loading and the second for doing queries, then yes, it's pretty par with the bash implementation :D Let me answer this with a meme ;) https://damage.devloop.de/zac_makes_runtime_equal.jpg Thanks Daniel
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
On 5/23/20 1:41 PM, magic-gen...@damage.devloop.de wrote: > Am 23.05.2020 um 22:20 schrieb Zac Medico: >> On 5/23/20 1:02 PM, magic-gen...@damage.devloop.de wrote: >>> I rewrote e-file in python by using the portage API [1]. But loading the >>> API slows down the whole script. Is there any way to speed up my >>> implementation? Have I done something fundamentally wrong? >> >> When I patched the portage API out of your script, I saw the run time >> drop from 4.2 seconds to 3.2 seconds with this patch: >> ... >> >> Are your results worse than mine? > > Nope, but maybe the phrase "loading the API" was misleading. I'd like to > replace it with: "But using the API slows down the whole script.". This > means it is much slower to get the additional informations by portage > API than just grep'ing throught the ebuild files. If I run the python > e-file on my machine it takes 3.2 seconds for a single file. The bash > e-file show the same result within a second or so. > > regards > Daniel > > Since the portage API only added about 1 second to the python script time, I guess it's on par with your bash implementation. ;-P -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Am 23.05.2020 um 22:20 schrieb Zac Medico: On 5/23/20 1:02 PM, magic-gen...@damage.devloop.de wrote: I rewrote e-file in python by using the portage API [1]. But loading the API slows down the whole script. Is there any way to speed up my implementation? Have I done something fundamentally wrong? When I patched the portage API out of your script, I saw the run time drop from 4.2 seconds to 3.2 seconds with this patch: ... Are your results worse than mine? Nope, but maybe the phrase "loading the API" was misleading. I'd like to replace it with: "But using the API slows down the whole script.". This means it is much slower to get the additional informations by portage API than just grep'ing throught the ebuild files. If I run the python e-file on my machine it takes 3.2 seconds for a single file. The bash e-file show the same result within a second or so. regards Daniel
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Hi, Am 23.05.2020 um 22:08 schrieb Michał Górny: On Sat, 2020-05-23 at 22:02 +0200, magic-gen...@damage.devloop.de wrote: I rewrote e-file in python by using the portage API [1]. But loading the API slows down the whole script. Is there any way to speed up my implementation? Have I done something fundamentally wrong? My only suggestion would be to use pkgcore instead of portage. It is compatible at configuration/data format level, so your script should work out of the box for Portage users. Which makes me feel I did something fundamentally wrong :) I used "portage.db['/']['vartree'].dbapi" and "portage.db['/']['porttree'].dbapi" to get the API for installed (vartree) and available (porttree) packages. This is not available ing pkgcore. I haven't found a quick guide on how to use pkgcore but I will have a further look. Thanks Daniel
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
On 5/23/20 1:02 PM, magic-gen...@damage.devloop.de wrote: > Hi, > the current e-file tool of app-portage/pfl is written in bash. e-file is > a CLI tool which searches portagefilelist.de for a given file and list > additional informations based on the local portage. Latter is done by > grep'ing through the ebuild files which is fast but IMHO not very smart. > > I rewrote e-file in python by using the portage API [1]. But loading the > API slows down the whole script. Is there any way to speed up my > implementation? Have I done something fundamentally wrong? > > Thanks in advance > Daniel > > [1] https://github.com/portagefilelist/client/blob/e-file-python/bin/e-file > When I patched the portage API out of your script, I saw the run time drop from 4.2 seconds to 3.2 seconds with this patch: $ diff -U1 e-file.py.orig e-file.py --- e-file.py.orig 2020-05-23 13:16:26.873861849 -0700 +++ e-file.py 2020-05-23 13:16:42.076861548 -0700 @@ -6,3 +6,3 @@ import json -import portage +#import portage @@ -35,2 +35,3 @@ files = json.loads(r.text) +sys.exit(0) if len(files['result']) > 0: Are your results worse than mine? -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
On Sat, 2020-05-23 at 22:02 +0200, magic-gen...@damage.devloop.de wrote: > Hi, > the current e-file tool of app-portage/pfl is written in bash. e-file is > a CLI tool which searches portagefilelist.de for a given file and list > additional informations based on the local portage. Latter is done by > grep'ing through the ebuild files which is fast but IMHO not very smart. > > I rewrote e-file in python by using the portage API [1]. But loading the > API slows down the whole script. Is there any way to speed up my > implementation? Have I done something fundamentally wrong? My only suggestion would be to use pkgcore instead of portage. It is compatible at configuration/data format level, so your script should work out of the box for Portage users. I'm not sure how much faster it will be. However, it will surely be more readable considering how horrible Portage API is. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] speeding up usage of portage in e-file / portage file list
Hi, the current e-file tool of app-portage/pfl is written in bash. e-file is a CLI tool which searches portagefilelist.de for a given file and list additional informations based on the local portage. Latter is done by grep'ing through the ebuild files which is fast but IMHO not very smart. I rewrote e-file in python by using the portage API [1]. But loading the API slows down the whole script. Is there any way to speed up my implementation? Have I done something fundamentally wrong? Thanks in advance Daniel [1] https://github.com/portagefilelist/client/blob/e-file-python/bin/e-file
[gentoo-dev] Last-rites: gnome-python-common-r1.eclass
gnome-python-common-r1.eclass: Mark as DEAD - No consumers left in Gentoo ebuild repository - Removal in 30 days, bug #640022 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] linux-info.eclass: avoid lexicographical compare on numbers, bug #705248
On 5/22/20 2:57 PM, Sergei Trofimovich wrote:
> 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
>
Thanks. LGTM
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last-rites: dev-python/gconf-python, dev-python/gnome-python-base, dev-python/pygtksourceview
# Andreas Sturmlechner (2020-05-23) # Obsolete GNOME 2 era packages, stuck on Python 2 and pygtk, # bugs #640022, #708094. Masked for removal in 30 days. dev-python/gconf-python dev-python/gnome-python-base dev-python/pygtksourceview signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Anti-spam for goose
On Fri, 22 May 2020 21:58:54 +0200 Michał Górny wrote: > 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. Sure, and I agree that's a risk. But its not the "random users from the internet fill your inbox with shallow promises of free money" sort of risk, that's typically implied by "spam" ;). The set of potential attackers seems much smaller in our case, and are expressly likely to be actual consumers of Gentoo. This attacker type seems to be the sort that mitigates well with: - Make it so that end users can't forge custom IDs and can only be handed out by the server (but the ID doesn't actually add any tracking, its just a chunk of randomness with a signature that verifies its legitimacy) - Make ID generation expensive. - Limit submissions per ID the same way we do now. That way it doesn't harm typical users beyond their --setup, but hurts would be attackers. If we get under attack, we can just suspend ID generation services, or rate limit ID generation. (And we can encode data in the ID about when it was generated, and the strength of the challenge of the generation, and then block submissions based on criteria when problems occur) This means we don't need to keep track of what ID's are "valid", server side, crypto bits do all the leg work. Even if our private key doing the signing gets compromised, we can change it, which triggers all users to need to re-id, and flush old data. pgp2bPAtbKLWn.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
On Fri, 22 May 2020 22:13:11 + Peter Stuge wrote: > 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. Well, they kinda have to be, the state of AI is increasing so much that current captcha systems undoubtedly also develop their own adversarial AI to try beat their own captcha. I don't think we have the sort of power to develop this. And the inherently low entropy of only having 80x23 with so few (compared to full RGB) bits per pixel, this gives any would-be AI a substantial leg up. Using text distortion is amateur hour these days. (and there's always mechanical-turk anyway) pgpAEpbsuoP1P.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
On Fri, 22 May 2020 12:53:03 -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. 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. We *can* still validate them against entries in known overlays. And even if we *cant* validate everything, we can de-weight and hide from *default* reports items that can't be found in known overlays. This would move the difficulty goal from "submit a spam record" to: - write an overlay - get it published somewhere - get it included in the database of known overlays - then publish a spam record relating to it Which sounds like a slow and painful process if the risk of being blacklisted burns down that whole stack. pgp3S6X2G8lWc.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH] multilib.eclass: populate AR and NM in multilib_toolchain_setup(), bug #724558
On Fri, 22 May 2020 23:42:48 +0100
Sergei Trofimovich wrote:
> 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
Also added OBJDUMP, RANLIB and STRIP as they are used in most
libraries used by autotools. Pushed as:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dd35b529194fdcadf324fd4f0a466a61aa1dfadb
--
Sergei
Re: [gentoo-dev] [RFC] Anti-spam for goose
On Sat, 2020-05-23 at 09:54 +0200, Fabian Groffen wrote: > On 22-05-2020 21:58:54 +0200, Michał Górny wrote: > > 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. > > I'm affraid that has a heroic flair to me. The service should never be > used for decisions like that, because it's a biased sample at most. > Doing stuff like this simply destroys the soul of the distribution. > > I hope this isn't one of your genuine objectives with the service. If > it is, I can see why you fear spam so much. > What it is is one thing, what an angry user perceives it to be is another. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Anti-spam for goose
On 22-05-2020 21:58:54 +0200, Michał Górny wrote: > 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. I'm affraid that has a heroic flair to me. The service should never be used for decisions like that, because it's a biased sample at most. Doing stuff like this simply destroys the soul of the distribution. I hope this isn't one of your genuine objectives with the service. If it is, I can see why you fear spam so much. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel
On Sat, 2020-05-23 at 08:48 +0200, Ulrich Mueller wrote: > > > > > > 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? > I don't know, I haven't used GRUB since I've started using Gentoo. Right now ek1 behavior is to do this with GRUB2 if config says it was autogenerated, and otherwise respect the config. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sat, 23 May 2020 08:05:46 +0200
Michał Górny wrote:
> 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).
USE=-native-symlinks does remove /usr/bin/ar. Full(er) list for binutils is:
addr2line
ar
as
c++filt
coffdump
dlltool
dllwrap
dwp
elfedit
gprof
ld
ld.bfd
ld.gold
nm
objcopy
objdump
ranlib
readelf
size
srconv
strings
strip
sysdump
windmc
windres
--
Sergei
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
