[gentoo-dev] Last rites: dev-ruby/rack-mount

2020-05-23 Thread Hans de Graaff
# Hans de Graaff (2020-05-24) # No releases since 2011, upstream is gone, fails tests, # no reverse dependencies. # Masked for removal in 30 days. dev-ruby/rack-mount signature.asc Description: This is a digitally signed message part

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

2020-05-23 Thread Matt Turner
On Sat, May 23, 2020 at 10:21 PM Joonas Niilola wrote: > > > 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. Yes, but unfortunately catalyst's stage1 build does exa

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

2020-05-23 Thread Joonas Niilola
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

2020-05-23 Thread Mike Gilbert
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. > > Nati

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

2020-05-23 Thread Pengcheng Xu
> 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 wil

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

2020-05-23 Thread Sergei Trofimovich
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

Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-23 Thread Daniel Buschke
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 an

Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-23 Thread Daniel Pielmeier
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 secon

Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-23 Thread 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 i

Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-23 Thread Zac Medico
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 s

Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-23 Thread magic-gentoo
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

Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-23 Thread magic-gentoo
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 somethi

Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-23 Thread Zac Medico
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 thro

Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-23 Thread Michał Górny
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 b

[gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-23 Thread magic-gentoo
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

[gentoo-dev] Last-rites: gnome-python-common-r1.eclass

2020-05-23 Thread Andreas Sturmlechner
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

2020-05-23 Thread Mike
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...@gento

[gentoo-dev] Last-rites: dev-python/gconf-python, dev-python/gnome-python-base, dev-python/pygtksourceview

2020-05-23 Thread Andreas Sturmlechner
# 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 p

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

2020-05-23 Thread Kent Fredric
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

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

2020-05-23 Thread Kent Fredric
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

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

2020-05-23 Thread Kent Fredric
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

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

2020-05-23 Thread Sergei Trofimovich
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=i68

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

2020-05-23 Thread Michał Górny
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

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

2020-05-23 Thread Fabian Groffen
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

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

2020-05-23 Thread Michał Górny
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 co

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

2020-05-23 Thread Sergei Trofimovich
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-confi