[gentoo-dev] Last rites: net-libs/xrootd-ceph
# Guilherme Amadio (2023-10-30) # net-libs/xrootd-ceph was split from net-libs/xrootd as a git # submodule, but has been merged back to the main repository in # net-libs/xrootd-5.6.0. Please switch to net-libs/xrootd[ceph] # instead of net-libs/xrootd-ceph. Removal on 2023-11-30. net-libs/xrootd-ceph Best regards, -Guilherme Amadio
Re: [gentoo-dev] [PATCH 4/4] cmake.eclass: Default CMAKE_BUILD_TYPE=RelWithDebInfo in EAPI 8
Hi,
On Thu, Aug 19, 2021 at 07:45:16PM +0200, Andreas Sturmlechner wrote:
> Signed-off-by: Michał Górny
> Signed-off-by: Andreas Sturmlechner
> ---
> eclass/cmake.eclass | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
> index 8befd9e5a9f..3021a3a2b1e 100644
> --- a/eclass/cmake.eclass
> +++ b/eclass/cmake.eclass
> @@ -42,14 +42,19 @@ _CMAKE_ECLASS=1
> # Eclass can use different cmake binary than the one provided in by system.
> : ${CMAKE_BINARY:=cmake}
>
> +[[ ${EAPI} == 7 ]] && : ${CMAKE_BUILD_TYPE:=Gentoo}
> # @ECLASS-VARIABLE: CMAKE_BUILD_TYPE
> # @DESCRIPTION:
> # Set to override default CMAKE_BUILD_TYPE. Only useful for packages
> # known to make use of "if (CMAKE_BUILD_TYPE MATCHES xxx)".
> # If about to be set - needs to be set before invoking cmake_src_configure.
> -# You usually do *NOT* want nor need to set it as it pulls CMake default
> -# build-type specific compiler flags overriding make.conf.
> -: ${CMAKE_BUILD_TYPE:=Gentoo}
> +#
> +# The default is RelWithDebInfo as that is least likely to append undesirable
> +# flags. However, you may still need to sed CMake files or choose a different
> +# build type to achieve desirable results.
> +#
> +# In EAPI 7, the default was non-standard build type of Gentoo.
> +: ${CMAKE_BUILD_TYPE:=RelWithDebInfo}
Although I think this is better than the "Gentoo" build type we had, I
think that even better is to just leave this blank and set a default on
a per-ebuild basis, as I commented on bug 802786[1]. Repeating my
comment from there, build type flags always come after CMAKE__FLAGS,
which then override make.conf settings. Moreover, setting a build type
can also have funny behavior with multi-config generators (possible with
ninja on Linux too now) because it has no meaning in that context. For
instance, this may override make.conf flags with "-O2 -g" in most cases,
preventing people from changing the optimization level of any CMake-based
package, or disabling compilation of debug info (which is then stripped
anyway). This is probably why we had the "Gentoo" build in the first place.
For ebuilds that must have a CMAKE_BUILD_TYPE set, we should probably
use Release and override CMAKE__FLAGS_RELEASE with settings from
make.conf, or make CMAKE__FLAGS contain settings from make.conf
and enforce CMAKE__FLAGS_ is empty for all build types.
Cheers,
-Guilherme
1. https://bugs.gentoo.org/802786
>
> # @ECLASS-VARIABLE: CMAKE_IN_SOURCE_BUILD
> # @DEFAULT_UNSET
> --
> 2.33.0
>
Re: [gentoo-dev] [PATCH] qmail.eclass: simplify is_prime()
Hi,
On Thu, Jun 17, 2021 at 05:42:12PM +, Peter Stuge wrote:
> Rolf Eike Beer wrote:
> > The previous algorithm would scan for all primes for a given number,
> > which takes needlessly long.
>
> Please also mention how this caused a problem for you in the commit
> message, to help us understand why you're proposing to change this.
>
>
> > +++ b/eclass/qmail.eclass
> > -# @FUNCTION: is_prima
> > +# @FUNCTION: is_prime
> > # @USAGE:
> > # @DESCRIPTION:
> > # Checks wether a number is a prime number
>
> Maybe name the algorithm? Looks like an optimization of the sieve of
> Eratosthenes?
>
>
> > is_prime() {
> > local number=${1} i
> > - for i in $(primes ${number} ${number})
> > +
> > + if [[ $[number % 2] == 0 ]]; then
> > + return 1
> > + fi
>
> While 2 itself is prime the above returns 1 for any even number.
There's actually a much simpler solution to this:
$ is_prime() { test $(factor $1 | cut -d: -f2 | wc -w) == 1; }
$ for n in $(seq 0 10); do is_prime $n && echo $n is prime; done
2 is prime
3 is prime
5 is prime
7 is prime
$ time factor 20187319083467888113
20187319083467888113: 20187319083467888113
0.00
Cheers,
-Guilherme
Re: [gentoo-dev] */*: Mask Py2 only packages
On Sat, Jun 20, 2020 at 12:58:20AM -0400, Aaron Bauman wrote: > > # Aaron Bauman (2020-06-20) > > # Py2 only > > # Removal in 14 days > > dev-util/uftrace This is a function tracer written in C. I don't know why it's on this list. If a package has only optional support for python like this, just drop python support rather than the whole package, please. In this case it's just a matter of adding --without-libpython to the call to econf. In any case, the release notes for the latest version says that it now does support python3, even though the configuration for python3 seems a bit broken after I've had a look at it. I will take it and fix nevertheless. Cheers, -Guilherme
Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
Hi, On Wed, May 27, 2020 at 02:45:29PM +0200, Toralf Förster wrote: > On 5/27/20 2:16 PM, Thomas Deutschmann wrote: > > The problem when doing review on Github > > for me is, that we usually create new revisions. Therefore we don't see > > what's changed in new revision versus previous revision. > That's my main concern with the current behaviour: a "git diff" often doesn't > show a diff against the previous (ebuild) file, it shows a diff against > /dev/null :-/ Indeed, on GitHub it is hard to review, but locally you can add [diff] algorithm = patience to your .gitconfig, and that should help with the diffs even when the revision changes by moving the file. When copying, it probably won't help. We could also try as a policy to split the revision bump from the changes, i.e. bump the revision in the first commit, then apply the changes in a second one. That way, one can click on the right commit to see the differences only, even on GitHub. Then we can squash when merging locally, since we don't click merge on GitHub anyway. Cheers, -Guilherme
Re: [gentoo-dev] [PATCH] dev-python/metadata.xml: Clarify description
Hi Michał, longdescription lang="pt" A categoria dev-python contém pacotes cujo propósito principal é fornecer módulos, extensões e bindings para Python, bem como ferramentas e outros utilitários para desenvolvimento de software em Python. Cheers, -Guilherme On Sun, Mar 08, 2020 at 10:24:17AM +0100, Francesco Riosa wrote: > longdescription lang="it" > > La categoria dev-python contiene pacchetti il cui scopo principale > è fornire moduli, estensioni e bindings per Python, > nonché strumenti e utilità per lo sviluppo nel linguaggio > di programmazione Python. > > Il giorno dom 8 mar 2020 alle ore 09:52 Michał Górny ha > scritto: > > > Rewrite the description for dev-python category in order to clarify > > its purpose. It has been pointed out that the previous description may > > have suggested that it is the category for *all* things written > > in Python. > > > > Signed-off-by: Michał Górny > > --- > > dev-python/metadata.xml | 44 +++-- > > 1 file changed, 12 insertions(+), 32 deletions(-) > > > > // If you can supply translations for the remaining languages, please > > // send them my way and I'll update the patch. > > > > diff --git a/dev-python/metadata.xml b/dev-python/metadata.xml > > index ed6a813dd009..b90b8f66f45a 100644 > > --- a/dev-python/metadata.xml > > +++ b/dev-python/metadata.xml > > @@ -2,41 +2,21 @@ > > http://www.gentoo.org/dtd/metadata.dtd;> > > > > > > - The dev-python category contains libraries, utilities or > > - bindings written in or for the Python programming > > language. > > + The dev-python category contains packages whose primary > > purpose > > + is to provide Python modules, extensions and bindings, as > > well > > + as tools and utilities useful for development in the Python > > + programming language. > > > > > > - Die Kategorie dev-python enthält Bibliotheken und > > Werkzeuge für die > > - Programmiersprache Python. > > - > > - > > - La categoría dev-python contiene librerias y utilidades > > referentes al > > - lenguaje de programación Python. > > - > > - > > - dev-pythonカテゴリーにはPythonプログラミング言語で記述された/のために > > - 記述されたライブラリーと>ユーティリティとバインディングが含まれます。 > > - > > - > > - De dev-python categorie bevat bibliotheken en hulpmiddelen > > voor het > > - gebruik van de programmeertaal Python. > > - > > - > > - Nhóm dev-python chứa các thư viện và tiện ích liên quan > > - đến ngôn ngữ lập trình Python. > > - > > - > > - La categoria dev-python contiene librerie ed utilità per > > il linguaggio > > - di programmazione Python. > > - > > - > > - A categoria dev-python contém bibliotecas, utilitários e > > - bindings escritos em ou para a linguagem de programação > > Python. > > + Die Kategorie dev-python enthält Pakete, die hauptsächlich > > + Module, Erweiterungen und Sprachbindungen für Python zur > > + Verfügung stellen, sowie Werkzeuge und Dienstprogramme für > > die > > + Entwicklung in der Programmiersprache Python > > > > > > - Kategoria dev-python zawiera biblioteki, narzędzia i > > powiązania > > - (bindings) napisane w lub stworzone do pisania w języku > > programowania > > - Python. > > + Kategoria dev-python zawiera paczki dostarczające przede > > + wszystkim moduły, rozszerzenia i powiązania (bindings) > > Pythona, > > + jak również przydatne narzędzia dla wiary programującej > > + w Pythonie. > > > > > > - > > -- > > 2.25.1 > > > > > >
Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags
Hi Michał, On Tue, Sep 10, 2019 at 10:44:54PM +0200, Michał Górny wrote: > Hi, everyone. > > I've recently (finally!) started adding tests to cpuid2cpuflags. Tests > are based on mocked syscalls that return arch-specific data read from > text files. So far I've got x86 and ppc covered, and now I'd like to > add tests for various arm hardware. Since ARM covers a pretty broad > range of hardware, I'd use as much data as possible, especially from > different ARM generations. > > If you have an ARM board and would like to help, please: > > wget https://dev.gentoo.org/~mgorny/dist/cpuid2cpuflags-7-dev.tar.bz2 > tar -xf cpuid2cpuflags-7-dev.tar.bz2 > cd cpuid2cpuflags-7-dev > ./configure > make hwcap-dump > ./hwcap-dump > > and send me the output along with 'uname -m'. TIA! Sorry for the late reply, I was on vacations in the last couple of weeks. Here is some data on hardware not yet submitted: ## Raspberry Pi Zero W: More info at: https://www.raspberrypi.org/products/raspberry-pi-zero-w $ uname -m armv6l $ ./hwcap-dump hwcap:81d6 hwcap2: $ lscpu Architecture:armv6l Byte Order: Little Endian CPU(s): 1 On-line CPU(s) list: 0 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 Vendor ID: ARM Model: 7 Model name: ARM1176 Stepping:r0p7 CPU max MHz: 1000. CPU min MHz: 700. BogoMIPS:697.95 Flags: half thumb fastmult vfp edsp java tls /proc/cpuinfo: processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) BogoMIPS: 997.08 Features: half thumb fastmult vfp edsp java tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xb76 CPU revision: 7 Hardware: BCM2835 Revision: 9000c1 Serial : 81342439 ## Raspberry Pi 4 Model B: More info at: https://www.raspberrypi.org/products/raspberry-pi-4-model-b $ uname -m armv7l $ ./hwcap-dump hwcap:003fb0d6 hwcap2:0010 $ lscpu Architecture:armv7l Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Vendor ID: ARM Model: 3 Model name: Cortex-A72 Stepping:r0p3 CPU max MHz: 1500. CPU min MHz: 600. BogoMIPS:270.00 Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 /proc/cpuinfo processor : 0-3 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS: 270.00 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xd08 CPU revision: 3 Hardware: BCM2835 Revision: c03111 Serial : 299a8a34 ## HP Moonshot XGene 1: More info at: https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04500662 $ uname -m aarch64 $ ./hwcap-dump hwcap:0007 hwcap2: $ lscpu Architecture: aarch64 Byte Order:Little Endian CPU(s):8 On-line CPU(s) list: 0-7 Thread(s) per core:1 Core(s) per socket:8 Socket(s): 1 NUMA node(s): 1 Model: 1 BogoMIPS: 100.00 NUMA node0 CPU(s): 0-7 Flags: fp asimd evtstrm /proc/cpuinfo: processor : 0-7 BogoMIPS: 100.00 Features: fp asimd evtstrm CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part: 0x000 CPU revision: 1 ## Cavium ThunderX: More info at: https://en.wikichip.org/wiki/cavium/thunderx $ uname -m aarch64 $ ./hwcap-dump hwcap:01ff hwcap2: $ lscpu Architecture: aarch64 Byte Order:Little Endian CPU(s):96 On-line CPU(s) list: 0-95 Thread(s) per core:1 Core(s) per socket:48 Socket(s): 2 NUMA node(s): 2 Model: 0 BogoMIPS: 200.00 L1d cache: 32K L1i cache: 78K L2 cache: 16384K NUMA node0 CPU(s): 0-47 NUMA node1 CPU(s): 48-95 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics /proc/cpuinfo: processor : 0-95 BogoMIPS: 200.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics CPU implementer : 0x43 CPU architecture: 8 CPU variant : 0x1 CPU part: 0x0a1 CPU revision: 0 ## Cavium ThunderX2: More info at: https://en.wikichip.org/wiki/cavium/thunderx2 $ uname -m aarch64 $ ./hwcap-dump hwcap:19ff hwcap2: $ lscpu Architecture: aarch64 Byte Order:Little Endian CPU(s):256 On-line CPU(s) list: 0-255 Thread(s) per core:4 Core(s) per socket:32
Re: [gentoo-dev] util-linux build time increase?
On Thu, Feb 21, 2019 at 04:36:24AM -0500, Joshua Kinard wrote: > Does anyone have an idea why util-linux's build time would go up > significantly from 2.32.x to 2.33.x? It may be a MIPS thing, as my x86_64 > box shows no discernible change in build times between the same versions. > Can any other archs check w/ genlop to see if they see a large jump in build > time? > > 'genlop -t util-linux' output on my SGI system (some entries removed for > brevity): > > Thu Feb 1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1 >merge time: 27 minutes and 48 seconds. > > Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32 >merge time: 28 minutes and 44 seconds. > > Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1 >merge time: 32 minutes and 58 seconds. > > Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33 >merge time: 1 hour, 19 minutes and 49 seconds. > > Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1 >merge time: 1 hour, 23 minutes and 37 seconds. > > Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1 >merge time: 1 hour, 25 minutes and 15 seconds. Indeed. Here's what I see in one of my machines at work (Core i7-7820X): Fri Jul 20 16:31:38 2018 >>> sys-apps/util-linux-2.32.1 merge time: 1 minute and 40 seconds. Fri Aug 3 14:38:40 2018 >>> sys-apps/util-linux-2.32.1 merge time: 1 minute and 40 seconds. Wed Nov 14 16:49:40 2018 >>> sys-apps/util-linux-2.33 merge time: 4 minutes and 24 seconds. Tue Feb 5 14:21:40 2019 >>> sys-apps/util-linux-2.33.1 merge time: 4 minutes and 24 seconds. Not sure what causes it. Cheers, -Guilherme
Re: [gentoo-dev] [RFC] C++ standard in ebuilds
On Mon, Sep 17, 2018 at 10:24:48AM -0700, Matt Turner wrote:
> I don't understand what a potential solution would be.
>
> The various projects use -std=c++XXX because that's what their code
> requires. -std=c++XXX can't generally be changed. If a dependent
> project is incompatible that's no different than any other case of
> incompatible dependencies in Gentoo.
>
> I think -std=c++XXX discussions before happened because gcc changed
> the C++ ABI with -std=c++11. I don't think that's particularly
> relevant here, since as far as I know different -std=c++XXX values
> don't change the ABI with current gcc.
>
> So I guess my understanding is that there isn't a problem different
> than existing incompatible dependencies, but maybe I have
> misunderstood you.
My concern is with, say, package foo that depends on both bar and baz,
and bar and baz support from C++11 to C++17, but must be compiled with
the same version of the standard so that foo can link against both of
them without having a broken ABI. I think that depending on bar[c++14],
or having a similar mechanism to Python to handle "same version of the
standard" with ${CXXSTD_REQUIRED_USE} or similar in an eclass would be
nice.
Cheers,
-Guilherme
Re: [gentoo-dev] [RFC] C++ standard in ebuilds
On Tue, Sep 18, 2018 at 08:46:46AM -0400, Richard Yao wrote: > > > On Sep 17, 2018, at 12:40 PM, Vadim A. Misbakh-Soloviov > > wrote: > > > > I'd prefer to wait another replies on the list for the main theme of this e- > > mail, but this problem also affects C (so, as **c**flags and C standards), > > so > > solution shoudn't be c++ specific, imho. > You would think that, but the C standard version does not effect ABI > compatibility. We had a very long discussion about this in OpenZFS because > the other platforms were using C99 while we had backported everything to C89 > on Linux because of the Linux kernel. No one could find a single example of > ABI breakage caused by mixing and matching C89 and C99 (C99 LKM and C89 > kernel). After a few years of not a single example being raised, the Linux > team lead opted to adopt C99. > > Now, there are flags affecting the ABI, but those are separate from the C > standard version. As for C++, mixing standard versions does go badly because > new language features require ABI changes. > > Yes, since mixing standard versions is not so good, and many ebuilds hard-code it with append-cxxflags, I think it's worth discussing a better solution that will avoid unnecessary breakage. The big problem is going from C++14 to C++17 as mentioned before. The 'noexcept' became part of the mangled name. C++17 also removes features, so there will be code that will need to be changed to compile as well. If we have a system-wide setting, we can start warning upstreams about it at least when things break. Cheers, -Guilherme
[gentoo-dev] [RFC] C++ standard in ebuilds
Hi everyone, I would like to discuss a system-wide way to handle C++ standard setting in Gentoo. We currently have many packages appending -std=c++XX to their flags, and it's hard to keep track of which packages use which version of the standard. This is a problem when packages force dependencies to use the same version of the standard, or if certain combinations cause ABI or other breakage (i.e., due to backports conflicting with standard classes). We currently have the page below with some documentation, but I have not found much else on the topic: https://wiki.gentoo.org/wiki/Project:C%2B%2B/Maintaining_ABI One problem is that depending on the compiler version, the right option may change (e.g. -std=c++1y vs -std=c++14 and -std=c++1z vs -std=c++17). This isn't a big problem when using recent compilers, but may be it will if you want to test some package you develop with an older compiler you still need to support (out of Gentoo), or if you use ICC, which lags a bit behind in standards support. For CMake projects, we could set CMAKE_CXX_STANDARD in cmake-utils.eclass. For other projects we could use other means. In any case, it might make sense to have global USE flags like c++11 (already a local USE flag), c++14, etc, along with a small eclass that C++ projects can inherit to get the right setting instead of using append-cxxflags with a hard-coded standard version. Hard-coding the standard flag may create problems because we will have a mix of the default and the hard-coded ones. The USE flags would also allow depending on a package with the same standard configuration or setting the standard globally to something different than the compiler default (i.e. either stay with C++11 because that's what you need to work with, or use C++17 since you are on ~arch and your system compiler supports it, etc). What are your thoughts on the matter? This has been discussed in the past¹, but it doesn't seem we have a global solution yet. I think another discussion happened more recently, but I didn't find the thread. Cheers, —Guilherme 1. https://archives.gentoo.org/gentoo-dev/message/eab0dc92cb8adb1457ff368c5a033eaf
[gentoo-dev] [RFC] Make 'cuda' a global USE flag
Hi everyone, We have several packages (~35) with local USE=cuda. Should we make that a global USE flag? It's a quite generic flag for GPU support, so I was surprised to learn it was still local when I added support for it to a package recently. Another thing we might want to discuss is a global setting for the CUDA architecture to be used¹. We compile from source, so it would be a shame not to compile with the right features for newer GPUs². Maybe just advertising the NVCCFLAGS one should put in make.conf is enough? Cheers, —Guilherme 1. https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#options-for-steering-gpu-code-generation 2. https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#gpu-feature-list
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
Hello, I like the idea of enforcing quality rules in the tree, but I have a few reservations regarding the current plan. On Sun, Jul 29, 2018 at 04:47:47PM +0900, Alice Ferrazzi wrote: > Sent from my phone. Please excuse my brevity. > > On Sun, 29 Jul 2018, 16:39 Fabian Groffen, wrote: > > > Completely agreeing with Sergei, with some additional suggestions: > > > > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > > > On Sun, 29 Jul 2018 00:40:18 +0300 > > > Mikle Kolyada wrote: > > > > > > > Hello, > > > > > > > > The Gentoo QA team would like to introduce the following policy that > > > > would be applied to individuals breaking the state and quality of the > > > > main gentoo.git tree If you introduce penalties for breaking prefix as well, I'm afraid many people will be unnecessarily penalized. I think that such penalties are counter productive in most cases. If someone is really being careless it might make sense to get some warning and lose commit access temporarily. If someone made a simple mistake that can be easily fixed, like version bumping a package that starts to fail in some corner case, then punishment doesn't make much sense. I'd rather prefer to see improvements to our automated checks as the mean to improve the quality of the tree, and penalties for people that do not use repoman. Rather than a temporary ban, it would also make more sense to just require someone to go through the ebuild quiz again as penalty for breaking the tree many times. > > > > ( as we do not have this strictly documented yet): > > > > > > > > > > > > > > > > If recommended > > > > > > It's not called "recommended" but "enforced". > > > > I agree. If you put penalties on these, they become hard rules. I > > think that change should be discussed by the council perhaps? > > > > > > Gentoo workflow policies are not followed by an > > > > individual developer > > > > (e.g make major changes to the widely used eclasses without prior > > > > discussion on the mailing list or > > > > commit changes that lead to multiple CI checks failure) > > > > > > Here should go exhaustive list of links to the policies to be enforced. > > > > At least. And they should be clear and concise. No "common sense" or > > anything involved for exceptions and the like. In addition, new checks > > should be introduced to the community and possibly approved by council > > as to whether being enforced or not. > > > > Fabian > > > > > > > > > the standard QA > > > > procedure is: > > > > > > > > 1.) Two warnings granted by QA team, after two independent breakages > > > > 2.) Revoking the commit access for 14 days > > > > > > > > These violations will be evaluated individually by all QA team members. > > > > Warnings can be revoked, if during 6 months period a developer makes at > > > > least 20 non trivial changes not producing more breakages. > > > > > > > > > > > > > > -- > > > > > > if you want to enforce rules, would be productive to also have extensive > documentation on how to avoid to make such problems. > Better would be to invest more time in something like the breckage checker > script, similar at what mgorny is doing, than adding more ways to block > developers contributions. I agree with Alice here. We already have the devmanual and repoman, as well as the CI system, which are all very good. Extending them is the best way to keep Gentoo in good shape. Also, if we have enough resources, we can try to reject broken pushes, rather than punishing devs after broken changes reach the main tree. Cheers, -Guilherme
[gentoo-dev] [PATCH] udev.eclass: return unprefixed udevdir
Hi,
This is a simple fix, but I'd like it to be reviewed.
Without this get_udevdir returns the prefixed directory, leading
to double prefix on udev related packages (e.g. fuse-common).
Even if not used in prefix, udev related packages are usually pulled
in as dependencies of other packages (xrootd for fuse).
Cheers,
-Guilherme
---
diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 5e5df073880..148581b8bd5 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -46,7 +46,8 @@ DEPEND="virtual/pkgconfig"
# Get unprefixed udevdir.
_udev_get_udevdir() {
if $($(tc-getPKG_CONFIG) --exists udev); then
- echo "$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
+ local udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
+ echo ${udevdir#${EPREFIX%/}}
else
echo /lib/udev
fi
Re: [gentoo-dev] rfc: Remove inherit eutils from font.eclass for EAPI=6
On Thu, Feb 15, 2018 at 03:16:22AM +0200, Mart Raudsepp wrote:
> On Wed, 2018-02-14 at 23:43 +0100, Jonas Stein wrote:
> > Did I miss something?
> > Who can help to check with (an automatic) testenvironment, if these
> > packages will survive?
>
> Don't check with test environments, read the ebuilds.
I agree with this. Font ebuilds are usually quite trivial, so it might
even be faster to just read them. The font.eclass has not been touched
since the move to git, but I suspected few fonts would actually use
eutils, so here is another grep that shows it may be easier than we
think to get rid of inherit eutils, even if for all EAPIs:
https://devmanual.gentoo.org/eclass-reference/eutils.eclass/index.html
gentoo $ export eutils_funcs=(eqawarn ecvs_clean esvn_clean \
egit_clean emktemp edos2unix strip-linguas built_with_use make_wrapper \
path_exists use_if_iuse optfeature epause ebeep usex einstalldocs \
in_iuse)
gentoo $ for func in ${eutils_funcs[@]}; do grep -rI 'inherit.*font'
--include='*.ebuild' -l | \
xargs grep $func; done | cut -d: -f1 | sort | uniq
app-office/lyx/lyx-2.2.3-r1.ebuild
app-office/lyx/lyx-2.2.3-r2.ebuild
media-fonts/terminus-font/terminus-font-4.39-r1.ebuild
media-fonts/terminus-font/terminus-font-4.40.ebuild
media-fonts/terminus-font/terminus-font-4.46.ebuild
media-fonts/unifont/unifont-10.0.04.ebuild
media-fonts/unifont/unifont-10.0.05.ebuild
media-fonts/unifont/unifont-10.0.06.ebuild
media-fonts/unifont/unifont-9.0.06.ebuild
net-misc/suite3270/suite3270-3.4_p10.ebuild
net-misc/suite3270/suite3270-3.5_p10.ebuild
net-misc/suite3270/suite3270-3.5_p12.ebuild
net-misc/suite3270/suite3270-3.6_p4.ebuild
Most of the above only use usex, and terminus-font uses einstalldocs as well.
I think these should be pretty easy to fix to not use eutils, or simply
add 'inherit eutils' for these ebuilds, then remove from the eclass.
I can help with testing by reading ebuilds more carefully and emerging
them after the change in font.eclass.
Cheers,
-Guilherme
Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc
On Tue, Apr 25, 2017 at 11:26:16AM -0500, William Hubbs wrote:
> On Mon, Apr 24, 2017 at 07:59:53PM +0200, Guilherme Amadio wrote:
> >
> > I would rather prefer to keep essential development tools in tree.
> > GCC is not only used as system compiler, but also for development.
> > I already had problems before with CMake being aggressively removed,
> > so I couldn't just install CMake 3.5.2 to test something that got
> > broken with the latest CMake (3.7.2 at the time).
> >
> > For things like autotools, CMake, compilers, etc, I would like to
> > see at least the latest release of the previous major version (e.g.
> > CMake 2.8), and the last few latest releases from the current major
> > version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries,
> > as in prefix you may be somewhat limited by the host (think macOS),
> > so removing old ebuilds aggressively breaks stuff. I think this was
> > the case with clang before, where we needed 3.5 and that got removed,
> > so bootstrapping on macOS was broken for sometime.
>
> That's completely reasonable. My concern is that we have the following
> versions of gcc in the tree:
>
> gcc-2.95.3-r10
> gcc-3.3.6-r1
> gcc-3.4.6-r2
> gcc-4.0.4
> gcc-4.1.2
> gcc-4.2.4-r1
> gcc-4.3.6-r1
> gcc-4.4.7
> gcc-4.5.4
> gcc-4.6.4
> gcc-4.7.4
> gcc-4.8.5
> gcc-4.9.3
> gcc-4.9.4
> gcc-5.4.0
> gcc-5.4.0-r3
> gcc-6.3.0
>
> Under your proposal, I guess we would just have gcc-5.4.0-r3, gcc-4.9.4
> and maybe gcc-3.4.6-r2 and *definitely maybe* gcc-2.95.3-r10. Is this
> correct?
I'm not saying we should cut down to the set of versions I mentioned.
I think it's totally fine to have all the gcc versions above in the tree.
What I want to avoid is having less than what I said due to aggressive
removal of older versions, at least for critical packages like the toolchain
and related tools. So, I'd be happy with the set below for gcc, for example:
> gcc-4.4.7
> gcc-4.7.4
> gcc-4.8.5
> gcc-4.9.4
> gcc-5.3.0
> gcc-5.4.0-r3
> gcc-6.3.0
However, it doesn't hurt to have the older 3.x and 2.95 versions in case
someone needs to compile, say, software that was developed a long time
ago and doesn't compile anymore with the latest compilers.
Cheers,
—Guilherme
Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc
On Mon, Apr 24, 2017 at 11:01:32AM -0500, William Hubbs wrote:
> On Sun, Apr 23, 2017 at 02:35:48PM +0200, Michał Górny wrote:
> > Hi,
> >
> > I'm thinking of masking old versions of sys-devel/gcc, in particular
> > older than the 4.9 branch.
> [...]
> > My solution
> > ===
> >
> > I think there is no point in having explicit support for ancient gcc
> > versions these days. However, I admit that some specific developers
> > and users may have a need for them. Therefore, I think the best way
> > forward would be to keep them in ::gentoo but p.mask with
> > an explanatory message.
> >
> > The most important goal of having the packages masked is that it would
> > cause Portage to verbosely complain whenever the users have it
> > installed. With appropriate comment (displayed by Portage), we could
> > clearly inform users that they need to upgrade gcc and switch to a new
> > version to ensure that majority of packages work.
> >
> > We would also clearly indicate that we no longer support the old
> > versions and do not have to explicitly indicate this non-support via
> > explicit version checks in ebuilds.
> >
> > At the same time, users who really need those versions could unmask them
> > on their own responsibility and knowing the implications of setting them
> > as system-wide compilers.
> >
> >
> > What do you think?
+1
> Honestly,
>
> if we aren't going to officially support those older versions of gcc, I
> would rather see them moved to an overlay and removed from the main
> tree.
I would rather prefer to keep essential development tools in tree.
GCC is not only used as system compiler, but also for development.
I already had problems before with CMake being aggressively removed,
so I couldn't just install CMake 3.5.2 to test something that got
broken with the latest CMake (3.7.2 at the time).
For things like autotools, CMake, compilers, etc, I would like to
see at least the latest release of the previous major version (e.g.
CMake 2.8), and the last few latest releases from the current major
version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries,
as in prefix you may be somewhat limited by the host (think macOS),
so removing old ebuilds aggressively breaks stuff. I think this was
the case with clang before, where we needed 3.5 and that got removed,
so bootstrapping on macOS was broken for sometime.
Cheers,
—Guilherme
Re: [gentoo-dev] Package up for grab
On Wed, Aug 03, 2016 at 11:15:30AM +0800, Jason Zaman wrote: > On Tue, Aug 02, 2016 at 04:08:34PM -0700, Jigme Datse Rasku wrote: > > I'd have to say, there is likely a reason we are looking for a new > > maintainer. I don't know what is involved, but I might be interested. > > Might be wanting to start that direction... > > There is a new alpha skype for linux too now that should be looked into. > I have no idea how stable it is but it's probably not much worse than > what we currently have :P. > > https://community.skype.com/t5/Linux/Skype-for-Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/td-p/4434299 There is also a web version at https://web.skype.com for those that feel that installing the desktop client is too much of a hassle. I've moved to Google Hangouts long ago, though, and never looked back. Cheers, —Guilherme
Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM
On Mon, Aug 01, 2016 at 11:08:47PM +0200, David Seifert wrote: > Dear friends, > while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86 > list could be expanded a bit: I like the idea of expanding the list of CPU_FLAGS_X86, and having flags for other arches too, but I would be in favor of dropping the _X86 suffix and using CPU_FLAGS for all arches. Your machine most likely will only have one kind anyway. Not sure what others think about it, though. > avx512 - introduced with Skylake and Knights Landing Only Skylake Xeons (yet to be launched) will support AVX512, and as mentioned in another email, the subsets supported by Skylake and KNL are a bit different. So, adding each subset should be better (e.g. avx512f, avx512cd, avx512er, etc). > I also propose creating a CPU_FLAGS_PPC variable containing (at least): > > altivec - PowerPC's SSE > vsx - PowerPC's AVX > > Finally, I also propose creating CPU_FLAGS_ARM variable containing: > > neon > > Any ideas? Currently cpu-feature flags for non-x86 are package local, > whereas making them globally available makes masking easier for non- > applicable archs etc. and makes enabling them easier for users. Masking flags is not needed if they are determined from /proc/cpuinfo. Cheers, —Guilherme
Re: [gentoo-dev] Need design help/input for eclean-kernel
On Thu, Jun 30, 2016 at 02:38:26PM +0200, Michał Górny wrote:
> So if you have some time, please reply to this thread with
> a specific /boot layout that you think needs to be handled, with
> as much helpful information as possible -- including possible
> distinctive features and pitfalls.
Looks like not too many people are booting kernels like me, so
I'm going to add my crude setup to the pile :)
I compile most stuff into the kernel (at least enough so I don't
need to use an initrd/initramfs to mount / or /usr). I do not use a boot
loader either, I use CONFIG_EFI_STUB=y and compile in the command
line arguments to avoid trouble. Then, I use efibootmgr to boot the
kernel at /boot/EFI/Gentoo/bootx64.efi
I usually keep several kernels in the same directory with a version
suffix (e.g. bootx64-4.6.2.efi, etc) and overwrite the bootx64.efi
file with whatever kernel I want to boot with cp bootx64{-4.x.x,}.efi
I keep a few older kernels around in case I screw up the configuration
of a new one (usually video drivers), but for the most part, that's it.
My compiled kernel command line is also pretty simple:
quiet console=tty1 root=/dev/sda4 init=/usr/lib/systemd/systemd
I never really though about writing scripts to manage this, since it's
quite a simple setup, but having tools to manage it would be nice.
Just think about supporting a simple EFI/UEFI setup, I would say, in
addition to the more common setups using a boot loader.
Cheers,
—Guilherme
Re: [gentoo-dev] Migrate to Phabricator
Hello, On Mon, Apr 18, 2016 at 01:44:00PM +0200, Jonas Jelten wrote: > Ohai! > > Phabricator is a fun adventure game: http://phabricator.org/ > It provides a tightly coupled set of project management tools. > > Many bigger projects (e.g. blender, mediawiki, ...) started using > phabricator, it could also be very beneficial for gentoo. The website lists "Companies probably using Phabricator", which not a very good for transmitting trust. We've just been through major migrations: moving to git, website migration, etc. We should not forget all the work that has been put into making the current system work for Gentoo, and I have to say, I think that our new website looks really nice, gitweb looks great too, and we have a really large history of bugs on bugzilla, that also has a Gentoo theme. Migrating to something else would be a huge undertaking. That's why, even though I use and like Atlassian tools, I never proposed a migration to JIRA, bitbucket and other tools. If others would like moving to something else, I believe that Atlassian tools are more attractive. Yes, they are a proprietary company, but they do offer free licenses for open source projects that could be hosted on Gentoo Infra. https://www.atlassian.com/software/views/open-source-license-request That said, I'm not saying we should move to Atlassian tools, just that it's probably a better option than Phabricator, if such a big migration happens. I think that what we have now is already pretty good. > Migrating would contradict the apparent goal of integrating github more > tightly, but still we could consider to use Phabricator instead, > especially to dump bugzilla. While I'm not particularly against integrating more tightly with GitHub, there is no such goal in Gentoo as far as I can tell. As much as I like GitHub, I do understand the concerns of others about making GitHub essential. It has been blocked before in certain regions of the world, and that's not good for us, regardless of the free vs proprietary debate. I don't think that GitHub is evil or anything, but GitHub is a nice place for extras, to interact with the user community, receive patches, etc. It should not replace our own infra. Cheers, —Guilherme
Re: [gentoo-dev] packages to grab
Hi, On Fri, Jan 08, 2016 at 11:04:03AM -0500, Göktürk Yüksek wrote: > Hi, > > > > > I will move all packages I maintain [1] to the associated projects if > > possible. All devs are free to take what ever you are interested in. I > > am also happy to proxy contributors if they like to maintain a package. > > > I would like to proxy-maintain dev-vcs/gitstats if possible. Sure, I can be your proxy-maintainer. Cheers, —Guilherme > > > > > Cheers, > > Justin > > > > 1) > > http://euscan.gentooexperimental.org/maintainers/jlec%40gentoo.org/ > > Thanks, > > -- > gokturk >
Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)
On Tue, Dec 01, 2015 at 10:58:55PM +, James Le Cuirot wrote:
> Sorry for the length of this but you really need to consider the bigger
> picture with this stuff and not all devs are familiar with it.
>
> For EAPI 7, mgorny and I are seeking to address some cross-compiling
> issues. This is a subject I've long had an interest in and before I
> became a developer, I created a project called cross-boss that, to be
> blunt, hacks its way through the shortcomings in Portage and the tree.
> It does (or at least did when I last worked on it) achieve a higher
> success rate than you would get from crossdev alone and allows you to
> install a brand new standalone system from scratch as opposed to one
> under /usr/${CHOST}.
>
> I have heard some developers say that cross-compiling is simply not
> worth the effort but I have succeeded in building some big ticket items
> including MariaDB, GTK+, Qt4, and LibreOffice. This is one area where
> Gentoo can really shine so I would like to exploit that potential.
Thanks for the nice write up.
I've been using a prefix installation (no root privileges to use Gentoo)
and Intel compilers with Portage to cross compile stuff for the Xeon Phi[1].
For the most part I've just hacked my way into making things work, but
it would be cool to get a project going to do this properly.
Cheers,
—Guilherme
[1] https://software.intel.com/en-us/mic-developer
Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user
On Sat, Sep 05, 2015 at 02:42:15PM +0200, Ulrich Mueller wrote: > > On Sat, 5 Sep 2015, Rich Freeman wrote: > > > I certainly support the principle, but for the sake of transparency > > can we try to coordinate this so that the setting name doesn't > > change when this moves into the package manager for EAPI6? > > So far, the EAPI 6 draft says [1]: > >eapply_user >Takes no arguments. Package managers supporting it apply >user-provided patches to the source tree in the current working >directory. Exact behaviour is implementation defined and beyond >the scope of this specification. Package managers not supporting >it must implement the function as a no-op. Only available in >EAPIs listed in table [...] as supporting eapply_user. Is there a reason to pick eapply_user rather than epatch_user? I think the second one would fit better with what we already have. Alternatively, if we would like to avoid adding a new function, it could be something like epatch --user or epatch -d $DIRECTORY_WITH_PATCHES, where $DIRECTORY_WITH_PATCHES either defaults to something like $EPATCH_SOURCE_USER, or can be specified via package.env. This takes the burden away from the package manager for where to put patches, and lets the user make that choice. Cheers, —Guilherme
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On Wed, Aug 19, 2015 at 11:00:49AM -0700, Zac Medico wrote: On 08/19/2015 10:49 AM, hasufell wrote: On 08/19/2015 07:37 PM, Zac Medico wrote: On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. Why is it called Package-Manager: then? Because repoman in bundled with portage, I guess. I suppose we could change it to something else. How about the line below? Signed-off-by: dev name (repoman version) Cheers, —Guilherme
Re: [gentoo-dev] Re: Fonts project meeting and elections
On Sun, Mar 01, 2015 at 08:59:38PM +0800, Ben de Groot wrote: On 28 February 2015 at 19:52, Michael Orlitzky m...@gentoo.org wrote: On 02/28/2015 01:47 AM, Ben de Groot wrote: Since this is mostly used for web developers, I recommend to leave it off for desktop users, but possibly on for servers, for example. If we do the use expand, we should leave it up for users to set. I suggest we default to only otf, if there is a choice. Other formats should not be installed by default, unless it's the only option for that package. This is going to get confusing fast -- please consider just installing everything by default. If you default to only OTF, what happens when you install a foo-ttf package? Is it a no-op? What if there's a package that only ships WOFF files? A combination of TTF and WOFF? Most of the fonts are tiny and it's not worth the hassle to avoid a few kilobytes. It will also keep the eclass nice and clean. If you default to installing everything, then when a user goes out of his way to remove (say) WOFF, you can go ahead and just ignore WOFF files even if the result is something stupid like an empty package. (The webfonts might be useful for clients, by the way. If they're not installed locally, your browser downloads them on-demand and caches them for later use.) Actually, after thinking about it some more, and doing some more research, I think this approach is unnecessary. Unless someone can tell me otherwise, I don't think we have any software that can handle truetype fonts but not opentype fonts. Most if not all of these packages use media-libs/freetype, which displays both formats just fine. So when we have font packages that offer both ttf and otf, then we should just install the superior format, which is OpenType. For packages that only offer one format, we install that format. Webfonts are also not an issue, as they are simply repackaged OpenType fonts aimed at web delivery. But most web developers use third party CDNs for that, such as Google Fonts. For the very few people who want to serve WOFF fonts from their own websites, I'm sure they can locate them as necessary. And webfonts are not useful for clients. Users should simply install the otf (or ttf) format of those fonts locally, and they will be picked up instead of the webfonts. Summarized, I propose the following policy: 1. If there is a choice of formats between otf and ttf, install only otf. 2. Do not install webfonts. I agree with your policy, but I think it's still a good idea to offer a mechanism to install the other formats for those who need it, maybe via truetype and woff or webfont USE flags. LaTeX, for example, may not be able to use OpenType fonts, unless you use XeTeX, or other newer variant, and sometimes a package you may want to use is only available for plain LaTeX or PDFTeX (pst-solides3d and pstricks come to mind). We could have global USE flags for each popular font format, turn on the flag for OpenType by default, and let users choose extra formats they want. Another thing we might want to work on is on a way to convert fonts for use with legacy LaTeX software that can't use OpenType files. Best, —Guilherme
Re: [gentoo-dev] Re: Fonts project meeting and elections
Hello! On Fri, Feb 27, 2015 at 03:45:23PM +0800, Ben de Groot wrote: On 22 February 2015 at 03:43, Ben de Groot yng...@gentoo.org wrote: To anyone within Gentoo who is interested in fonts I would like to announce a meeting to be held in #gentoo-meetings on Freenode, on Friday February 27 at 06:00 UTC, unless another date and/or time will be suggested by people who want to attend. Since nobody actually showed up, here is what I've decided and am proposing: Oops, got caught up by the timezone difference... Sorry about that. It was late at night here, but yesterday. 1. lu_zero, matsuu, pva: do you still want to be members of the Fonts project? Then add yourselves to the new project page: https://wiki.gentoo.org/wiki/Project:Fonts I'm listed, but why can I not edit the page? I'd like to be able to. 2. Since aballier voted for me, and there were no other nominations, we default to me becoming the lead. 3. Handling of fonts with both truetype and opentype variants, as brought up in https://bugs.gentoo.org/406301#c8 Since OpenType is an extension of TrueType, and superior for desktop and printing use, I propose that we prefer installing just OpenType. But this should be user configurable, so in those cases I propose we do: IUSE=+opentype if use opentype; then FONT_SUFFIX=otf else FONT_SUFFIX=ttf fi Both this and the use expand suggested by Luca seem good methods. I also suggest we prefer OpenType over TrueType whenever possible. 4. Project member should have a look at font bugs. https://bugs.gentoo.org/buglist.cgi?quicksearch=media-fonts has a lot of low hanging fruit: version bumps, dead homepages, etc. Also some good new packages. I've seen a few of those and suggested webpages for a couple of them. I can go fix some of these if nobody else does. 5. Some fonts have webfont variants (WOFF is the important one here). This may be useful for users doing web development. What are your thoughts on installing those (conditionally, toggled by useflag)? Since this is mostly used for web developers, I recommend to leave it off for desktop users, but possibly on for servers, for example. Anything else you want to discuss? I'd like to suggest that we do not name new font packages font-*, but simply by the name of the typeface, such as open-sans, source-pro, etc. There is Source Serif, Source Sans, and Source Han Sans that are not packaged yet (see https://github.com/adobe-fonts for more info), as well as many other nice and well-known typefaces and icon fonts such as Aller, Amble, Casper, Clear Sans, Entypo, Font Awesome, Signika, Comic Neue, Fira, Nexa, Exo, Nobile, Open Sans, etc. There is also the really nice Input (http://input.fontbureau.com), but its license is only free for personal use, so we may need to talk to its designer to see if we can package it at all. I'm using it on my laptop, and it's a pleasure to read and very customizable. Well, maybe opening a #gentoo-fonts on IRC will be a nice way to coordinate our efforts. Also, this is definitely a minor thing, but all designers prefer the term typeface to font when referring to typefaces, so they'd probably be happy if media-fonts became media-type, or something similar. The distinction is that the set of fonts (regular, light, bold, condensed, etc) is what makes a typeface, which is the general style of all fonts in the set. Anyway, just food for thought. Best, —Guilherme
Re: [gentoo-dev] Fonts project meeting and elections
Hello, On Sun, Feb 22, 2015 at 03:43:33AM +0800, Ben de Groot wrote: To anyone within Gentoo who is interested in fonts I would like to announce a meeting to be held in #gentoo-meetings on Freenode, on Friday February 27 at 06:00 UTC, unless another date and/or time will be suggested by people who want to attend. There hasn't been much activity in the fonts area of Gentoo, and our lead seems to be MIA. The main points on the agenda: 1. Who wants to be member of the Fonts project, and help out? 2. Members to elect a new lead. I'm nominating myself. 3. Make a plan for dealing with open bugs 4. Open floor Yes, I would like to be part of the team. I was thinking about creating a Typography project, but if there is already a Fonts project, it will work just as well. I won't nominate myself as a lead, since I just became a Gentoo dev, but I do want to help. I will show up to the meeting. Best, —Guilherme
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
On Mon, Oct 13, 2014 at 07:37:19AM -0400, Alex Xu wrote: On 13/10/14 05:35 AM, Michał Górny wrote: Please review the following news item. - Title: bash-completion-2.1-r90 Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: -MM-DD Revision: 1 News-Item-Format: 1.0 Display-If-Installed: app-shells/bash-completion-2.1-r90 Starting with app-shells/bash-completion-2.1-r90, we are enabling the completion autoloading support. Along with it, we are replacing the eselect-bashcomp module with a new one suited better for the new framework. Users will notice that the new framework is opt-out rather than opt-in. Since completions are loaded on-demand, all of them are enabled by default. If some of them are undesired, eselect-bashcomp can be used to explicitly disable (mask) them. The current eselect-bashcomp setup will *not* be migrated. It may be necessary to rebuild packages installing completions after the upgrade, and remove old configuration symlinks afterwards. For details, please consult the app-shells/bash-completion post-install messages. seems too oriented towards developer audiences, whereas news items are intended to target users; iow, I don't care what's going on behind the scenes, just tell me what I need to do to fix it. I disagree. I'm a user, and I'm interested in what is going on behind the scenes. I think that it's safe to assume that many Gentoo users care about the internals of the distribution too. I've actually been waiting for this to hit the tree since mgorny announced it. The news announcement is pretty good; I'd only incorporate pacho's suggestion to include the two commands needed to fix old stuff, and then I think it's good to go. —Guilherme
[gentoo-dev] Re: Resolving HAL vs. pciutils/usbutils
Hi guys, I totally agree with the patch sent by Daniel in the previous message. I think it clarifies to the user (me, for example), why it's not possible to build pciutils with the zlib USE flag. This is just my humble opinion, though, as a user. And sorry to a bit off this thread, but I also would like to help with some translations of official docs and development. I've been using Gentoo since 1.4, but never really had time to help. Now I feel I'll have more time and, if you can point me to some Brazilian dev, if there are any, I can take some stuff to do. Cheers, Guilherme -- [EMAIL PROTECTED] mailing list
