Re: [gentoo-dev] Deprecating repoman

Il giorno mer 9 mar 2022 alle ore 22:01 Matt Turner ha scritto: > I'd like to deprecate and ultimately remove repoman. I believe that > dev-util/pkgcheck and pkgcommit (from app-portage/mgorny-dev-scripts) > Hi using `repoman manifest` in scripts here, what would be the correct replacement for

Re: [gentoo-dev] Looking for a solution to the distutils/setuptools .egg-info mess

Il giorno lun 10 gen 2022 alle ore 06:39 Michał Górny ha scritto: [...] > > The big problem is that switching implies changing the format, so if you > install foo-X, then switch, then reinstall the same version of foo, > you're going to have the file replaced by a directory. This is not >

Re: [gentoo-portage-dev] [RFC] LTS branch of Portage

Il giorno mar 5 ott 2021 alle ore 10:31 Michał Górny ha scritto: > Hi, everyone. > > I've been thinking about this for some time already, and the recent > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > branch of Portage. > > Roughly, the idea is that: > > - master

Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

Il giorno lun 27 set 2021 alle ore 18:11 Mike Gilbert ha scritto: > I'm looking to solicit opinions on when it is appropriate for an > ebuild to check for kernel config options using linux-info.eclass. I > don't think we have any guidelines documented, instead leaving it up > to the "common

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

Il giorno mer 29 set 2021 alle ore 23:52 A Schenck ha scritto: > On 9/28/21 8:36 AM, Michał Górny wrote: > > Hi, everyone. > > > > I know I'm going to regret asking this... but I've prepared a change to > > the Portage output format and I think it asks for a wider discussion > > than internally

Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

Il giorno dom 11 lug 2021 alle ore 22:55 Michał Górny ha scritto: [snip] > > This decision will also affect another posted agenda item, namely > banning EAPI 5. Switching to the new workflow will eliminate that step, > and therefore EAPI 5 won't be "banned" until all EAPI 5 ebuilds are >

Re: [gentoo-dev] New project: binhost

Il giorno mer 10 feb 2021 alle ore 19:51 Lars Wendler < polynomia...@gentoo.org> ha scritto: > On Wed, 10 Feb 2021 19:57:48 +0200 Andreas K. Hüttel wrote: > > >Hi all, > > > >I'm announcing a new project here - "binhost" > > > >"The Gentoo Binhost project aims to provide readily installable, >

Re: [gentoo-dev] New project: binhost

Il giorno mer 10 feb 2021 alle ore 20:15 Andreas K. Hüttel < dilfri...@gentoo.org> ha scritto: > > Some ideas for portage enhancements: > > > > 1. Ability to fetch binary packages from some kind of repo. > > 2. Ability to have multiple binary packages co-exist in a repo (local > > or remote)

Re: [gentoo-portage-dev] [PATCH 1/3] Add caching to catpkgsplit function

Il 06/07/20 17:50, Michael 'veremitz' Everitt ha scritto: On 06/07/20 16:26, Francesco Riosa wrote: Il 29/06/20 03:58, Sid Spry ha scritto: There are libraries that provide decorators, etc, for caching and memoization. Have you evaluated any of those? One is available in the standard library

Re: [gentoo-portage-dev] [PATCH 1/3] Add caching to catpkgsplit function

Il 29/06/20 03:58, Sid Spry ha scritto: There are libraries that provide decorators, etc, for caching and memoization. Have you evaluated any of those? One is available in the standard library: https://docs.python.org/dev/library/functools.html#functools.lru_cache I comment as this would

Re: [gentoo-portage-dev] [PATCH] Default BINPKG_COMPRESSION to zstd (bug 715108)

Il 11/05/20 22:21, Brian Dolbec ha scritto: On Sun, 10 May 2020 19:29:34 -0700 Zac Medico wrote: This includes a _compat_upgrade.binpkg_compression script that the ebuild can call in pkg_preinst in order to maintain a backward-compatible bzip2 default when appropriate, ensuring that binary

Re: [gentoo-dev] [PATCH] dev-python/metadata.xml: Clarify description

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:

Re: [gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee

Il giorno lun 10 feb 2020 alle ore 08:20 Michał Górny ha scritto: > On Sun, 2020-02-09 at 22:51 -0800, Zac Medico wrote: > > In that case, I suppose we'll have to apply consistency manually? Can we > > all agree on a global order of preference for the relevant packages? > > That would be my

Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

Il giorno mer 18 dic 2019 alle ore 22:03 Sebastian Pipping ha scritto: > > CMake bundles a (previously outdated and vulnerable) copy of expat so > I'm not sure if re-activating that bundle — say with a new use flag > "system-expat" — would be a good thing to resort to for breaking the > cycle,

Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction

Il giorno lun 16 dic 2019 alle ore 13:39 Michał Górny ha scritto: > > > Comments > > WDYT? > > what about getting rid of RESTRICT="fetch" and manage everything inside SRC_URI? Would that be technically feasible? Ideally marking only the not re-distributable download and leaving

Re: [gentoo-dev] [RFC] Perspectives on improving (dis-hacking) python-single-r1

Since we are here ... I'd still like to see some way to adopt latest python version if user wants to. One way it could work is that we add a "LATEST" to PYTHON_TARGETS that would always build against best version of python. To avoid complications if a new version of python is emerged together with

Re: [gentoo-dev] Migrate away from python-2 or not

Il giorno dom 24 nov 2019 alle ore 13:20 Benda Xu ha scritto: > > > > Given the python-2 countdown deadline being 2020-01-01, a month away, > shall we get rid of python-2? > > yes please as much as possible. In my experience most server instances can live without py2 at all (after clang 9). In

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

Il giorno sab 26 ott 2019 alle ore 06:24 Michael Everitt ha scritto: > On 26/10/19 04:59, Kent Fredric wrote: > > On Fri, 25 Oct 2019 15:03:39 -0700 > > Georgy Yakovlev wrote: > > > >> not used anymore > >> > >> Closes: https://bugs.gentoo.org/695698 > >> Signed-off-by: Georgy Yakovlev > > > >

Re: [RFC] gpkg format proposal v2 (was: Re: [gentoo-portage-dev] [RFC] Improving Gentoo package format)

Il giorno dom 11 nov 2018 alle ore 22:17 Michał Górny ha scritto: > On Sun, 2018-11-11 at 21:53 +0100, Michał Górny wrote: > [...-] > Of course, one option would be to use ZIP ;-). > Zip archives have another big advantage; there is an index of files, so listing the archive contents and

Re: [gentoo-portage-dev] [RFC] Improving Gentoo package format

Il giorno dom 11 nov 2018 alle ore 09:29 Michał Górny ha scritto: > On Sat, 2018-11-10 at 09:37 -0500, Alec Warner wrote: > > On Sat, Nov 10, 2018 at 8:09 AM Michał Górny wrote: > [...] > > > My proposal > > > === > > > > > > Basic format > > > > > > The base of the format

Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

Il 13/09/18 20:55, Andreas Sturmlechner ha scritto: > On Donnerstag, 13. September 2018 16:25:13 CEST Mike Gilbert wrote: >> This may effect your plans to enable ninja by default, since it will >> break any fortran package. > Not much concerned about that; backend default can be overridden by

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

please ignore my previous email >

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

Il giorno dom 26 ago 2018 alle ore 20:15 Mart Raudsepp ha scritto: > Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny: > > One thing where this would fail would be e.g.: > > > > LICENSE="GPL-2+ > > bar? ( GPL-2 ) > > foo? ( GPL-3+ )" ^ you can't put a comment on the

Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test

Il giorno sab 25 ago 2018 alle ore 01:45 Zac Medico ha scritto: > On 08/24/2018 04:14 PM, Francesco Riosa wrote: > > > > Il 24/08/18 19:08, Mike Gilbert ha scritto: > >> On Fri, Aug 24, 2018 at 10:45 AM Kent Fredric > wrote: > >>> On Fri, 24 Aug 2018 1

Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test

Il 24/08/18 19:08, Mike Gilbert ha scritto: > On Fri, Aug 24, 2018 at 10:45 AM Kent Fredric wrote: >> On Fri, 24 Aug 2018 10:27:01 -0400 >> Mike Gilbert wrote: >> >>> If you want to define behavior that can be relied upon in ebuilds, it >>> should be specified in PMS. PMS does not define any

[gentoo-dev] Re: commit 50078fbbb39667734 for linux-info.eclass

Il 06/08/2018 17:13, Francesco Riosa ha scritto: ... > Please revert the commit, after that we should discuss here an > appropriate fix, with this statement I'm offering to test it for vanilla > kernel, out of source builds. tried to fix it and it seem to work, so I retract the rever

[gentoo-dev] commit 50078fbbb39667734 for linux-info.eclass

, after that we should discuss here an appropriate fix, with this statement I'm offering to test it for vanilla kernel, out of source builds. thank you, Francesco Riosa

Re: [gentoo-dev] Trustless Infrastructure

Il 02/07/2018 17:36, Jason A. Donenfeld ha scritto: > Proposal: > - Sign every file in the portage tree so that it has a corresponding > .asc. Repoman will need support for this. > implementation detail: Adding an .asc file for every file would bring the total files from 130k to 260k. Would be

Re: [gentoo-dev] Regarding the State of PaX in the tree

Il 16/04/2018 14:31, Anthony G. Basile ha scritto: > On 4/16/18 5:14 AM, Hanno Böck wrote: [snip] > >> >> There's also another question related to this: What's the future for >> Gentoo hardened? >> From what I can tell hardened consists of: >> * the things that try to make it compatible with

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

Il 23/03/2018 10:48, Ulrich Mueller ha scritto: >> On Thu, 22 Mar 2018, Geaaru wrote: >> for both portage and your fork I think that could be interesting add >> an extension to PMS for define inside profiles or targets masking of >> packages of a particular repslository. Currently PMS

Re: [gentoo-dev] Functional portage with namespace

Il 17/03/2018 00:40, Kent Fredric ha scritto: > On Mon, 12 Mar 2018 07:55:46 +0900 > Benda Xu wrote: > >> Ha, indeed many packages hardwrites "date of build" alike. That is a >> hard question to define reproducibility. I would rather ignore the >> timestamps when comparing

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

2018-03-08 16:40 GMT+01:00 Michał Górny : > Hello, developers. > > I would like to bring to your attention an alarming trend in Gentoo > ebuilds -- the proliferation of IUSE=static-libs, that is a flag > allowing our users to build static libraries. > > I should like to remind

[gentoo-dev] python-any-r1 deps used only for testing

hi, sys-devel/automake would to depend on python:2.7 if and only if "test" are enabled. For the tast it inherit python-any-r1 eclass than depend conditionally with test? ( ${PYTHON_DEPS} )" Additionally the ebuild call python_setup() in src_test() However this does not work, because eclass

Re: [gentoo-dev] [PATCH] cmake-utils.eclass: Extend ASM rules to ASM-ATT

2018-02-25 10:06 GMT+01:00 Michał Górny : > Some CMake projects use ASM-ATT rather than ASM, so extend our rule > overrides to that. > for the curious: https://cmake.org/Wiki/CMake/Assembler#ASM-ATT ASM-ATT This can be used for assembler files in AT assembler syntax. This

Re: [gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient

On 14/02/2018 05:37, Robin H. Johnson wrote: > On Tue, Feb 13, 2018 at 09:32:32PM -0500, Brian Evans wrote: >> I have a plan I would like some eyes on... >> >> I want to gradually *BAN* the use of virtual/mysql and >> virtual/libmysqlclient as dependencies. > Overall I agree, but there's some

Re: [gentoo-dev] [RFC] Testing Gentoo with openQA

2018-02-03 13:16 GMT+01:00 mudler : > Hi everyone, > > > This is an idea that has been floating around already, as some of you > already know, openQA [1] is a project that provides the ability to fully > test O.S. > Being used to routinely build Gentoo profiles, this idea is

Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

On 16/01/2018 01:40, Alec Warner wrote: > > > On Mon, Jan 15, 2018 at 7:05 PM, Francesco Riosa <viv...@gmail.com > <mailto:viv...@gmail.com>> wrote: > > > > On 15/01/2018 18:07, Mike Gilbert wrote: > > On Mon, Jan 15, 2018 at 10:27 AM, Francesco

Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

On 16/01/2018 08:57, Michał Górny wrote: > W dniu pon, 15.01.2018 o godzinie 16∶27 +0100, użytkownik Francesco > Riosa napisał: >> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added >> to all python eclasses, it's useful for developers that want test and &

Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

On 15/01/2018 18:07, Mike Gilbert wrote: > On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa <viv...@gmail.com> wrote: >> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added >> to all python eclasses, it's useful for developers that want test and >>

[gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added to all python eclasses, it's useful for developers that want test and mark the package for newer versions of python. However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not usable if: - the user want only python

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v3)

2018-01-11 17:27 GMT+01:00 Aaron W. Swenson : > This time with a version constrain that should allow this to expire at > some point in the future. > > Title: GnuCash 2.7+ Breaking Change > Author: Aaron W. Swenson > Posted: 2018-01-11 > Revision: 1 >

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

2018-01-09 22:20 GMT+01:00 Andreas K. Huettel <dilfri...@gentoo.org>: > [...] > * Whitelisting requires that one developer vouches for you. We intend this > to be as unbureaucratic as possible. > May I ask to some random developer to vouche for me (Francesco Riosa a.k.

Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution

On 12/27/17 16:47, Mike Gilbert wrote: > On Tue, Dec 26, 2017 at 7:18 PM, Robin H. Johnson wrote: >> On Tue, Dec 26, 2017 at 11:22:50PM +0100, Jason A. Donenfeld wrote: >>> You might want to mention that alternatively, uninstalling >>> openrc on a systemd profile system is

Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

On 12/21/17 15:11, Rich Freeman wrote: > Part of me wonders if issues with stable are causing issues with > ~arch. If stable is regarded as stale that is going to push people > into ~arch who really intend to have stable systems. That said you do > want testing systems to have a reasonably low

Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

On 12/18/17 14:01, Rich Freeman wrote: > On Mon, Dec 18, 2017 at 7:45 AM, Francesco Riosa <viv...@gmail.com> wrote: >> It would be interesting instead to evaluate ways to remove _all_ files/ dirs >> from the tree, keeping ebuilds separated from data. > Arguably you

Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

On 12/17/17 14:21, Michał Górny wrote: > ... > Rationale > = > > At this moment, syncing the repository implies fetching 'files' > directories of all packages, even though the relevant files are used > only when a ebuild referencing them is being built. This means that our > users fetch

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

On 12/12/2017 19:24, Rich Freeman wrote: > On Tue, Dec 12, 2017 at 1:15 PM, Michał Górny wrote: >> It seems that we've started lacking arch testers for AMD64 architecture. >> At this moment, there are already 159 bugs in amd64 backlog, and there >> is no noticeable progress.

Re: [gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged

On 11/20/17 05:09, hero...@gentoo.org wrote: [...] > diff --git a/eclass/user.eclass b/eclass/user.eclass > index 86bcd282479..76a622df698 100644 > --- a/eclass/user.eclass > +++ b/eclass/user.eclass > @@ -103,6 +103,10 @@ egetent() { > # Default uid is (pass -1 for this) next available, default

Re: [gentoo-dev] Re: cmake + ninja vs autotools

On 18/11/2017 00:35, Michael Palimaka wrote: > On 11/16/2017 02:27 PM, William L. Thomson Jr. wrote: >> It maybe worth considering switching the default generator in the >> cmake-utils.eclass from the default of emake to ninja. >> >> - : ${CMAKE_MAKEFILE_GENERATOR:=emake} >> + :

Re: [gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-19 23:00 GMT+02:00 Michał Górny : > W dniu czw, 19.10.2017 o godzinie 21∶08 +0200, użytkownik Michał Górny > napisał: > > > > 4. The new hashes that are stronger and commonly available are > > SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from > > our

Re: [gentoo-dev] FEATURES=splitdebug and debugedit

2017-10-13 4:05 GMT+02:00 M. J. Everitt <m.j.ever...@iee.org>: > On 12/10/17 22:24, Francesco Riosa wrote: > > hi, > > > > FEATURES=splitdebug at the moment require package dev-util/debugedit > > which is a lagging behind upstream. > > However pac

[gentoo-dev] FEATURES=splitdebug and debugedit

hi,     FEATURES=splitdebug at the moment require package dev-util/debugedit which is a lagging behind upstream. However package app-arch/rpm (from which debugedit is forked) always install the same binary in ${ROOT}/usr/libexec/rpm/debugedit. In 2017 I don't see much value in maintaining a fork

[gentoo-portage-dev] FEATURES=splitdebug and debugedit

hi,     FEATURES=splitdebug at the moment require package dev-util/debugedit which is a lagging behind upstream. However package app-arch/rpm (from which debugedit is forked) always install the same binary in ${ROOT}/usr/libexec/rpm/debugedit. In 2017 I don't see much value in maintaining a fork

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-09 17:33 GMT+02:00 William L. Thomson Jr. : > On Wed, 9 Aug 2017 11:07:04 +1000 > "Sam Jorna (wraeth)" wrote: > > > > What then is the benefit? If what is installed is the same from > > > package manager or binpkg. Also your redistributing another's

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

2017-04-26 0:26 GMT+02:00 Andreas K. Huettel : > Am Sonntag, 23. April 2017, 14:35:48 CEST schrieb Michał Górny: > > Hi, > > > > I'm thinking of masking old versions of sys-devel/gcc, in particular > > older than the 4.9 branch. > > > > Masking is fine; some time later

Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

On 25/04/2017 18:44, Guilherme Amadio wrote: 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

Re: [gentoo-dev] Re: Re: stable gcc 5.4.0 ??

2017-04-21 18:21 GMT+02:00 Jörg Schaible : > Walter Dnes wrote: > > > On Thu, Apr 20, 2017 at 05:52:20PM -0500, Matthias Maier wrote > > > >> (A-C) gcc-5.4.0 and gcc-4.9.4 are slotted separately. What is going to > >> be the default is entirely up to you. > > > > Good to

Re: [gentoo-dev] Reverse use of Python/Ruby versions

On 10/04/2017 01:59, Michael Orlitzky wrote: On 04/09/2017 07:15 PM, William L. Thomson Jr. wrote: If the package failed, all that would need to be done kinda like now is a given variable modified in the ebuild. Just marking what ever it did not work with. As mentioned that could be done via

Re: [gentoo-dev] Reverse use of Python/Ruby versions

On 10/04/2017 00:20, Brian Dolbec wrote: On Sun, 9 Apr 2017 23:36:18 +0200 Francesco Riosa <viv...@gmail.com> wrote: On 09/04/2017 18:15, William L. Thomson Jr. wrote: Not sure if this is practical, it may be less work if the use of Python and Ruby versions ( maybe others ) is re

Re: [gentoo-dev] Reverse use of Python/Ruby versions

On 09/04/2017 23:52, Michael Orlitzky wrote: On 04/09/2017 12:15 PM, William L. Thomson Jr. wrote: Not sure if this is practical, it may be less work if the use of Python and Ruby versions ( maybe others ) is reversed. Rather than adding all the versions that the ebuild supports. What if it

Re: [gentoo-dev] Reverse use of Python/Ruby versions

On 09/04/2017 23:44, Kristian Fiskerstrand wrote: On 04/09/2017 06:15 PM, William L. Thomson Jr. wrote: Not sure if this is practical, it may be less work if the use of Python and Ruby versions ( maybe others ) is reversed. Rather than adding all the versions that the ebuild supports. What if

Re: [gentoo-dev] Reverse use of Python/Ruby versions

On 09/04/2017 18:15, William L. Thomson Jr. wrote: Not sure if this is practical, it may be less work if the use of Python and Ruby versions ( maybe others ) is reversed. Rather than adding all the versions that the ebuild supports. What if it only included versions it did not support? Rational

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-wireless/gr-air-modes/

2017-02-21 12:56 GMT+01:00 Alexis Ballier : > On Tue, 21 Feb 2017 13:16:59 +1300 > Kent Fredric wrote: > > > Also, given its a - package, standards and assumptions of quality > > are typically much lower. > > not at all; a lot of people do maintain

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

2017-02-03 10:52 GMT+01:00 Lars Wendler : > On Fri, 3 Feb 2017 10:32:30 +0100 Kristian Fiskerstrand wrote: > > >On 02/03/2017 10:10 AM, Benda Xu wrote: > >> William Hubbs writes: > >> > >>> I have been looking at the meson build system [1] [2], and I

Re: [gentoo-dev] New Project: Gentoostats

2017-01-02 17:36 GMT+01:00 M. J. Everitt <m.j.ever...@iee.org>: > On 02/01/17 11:40, Francesco Riosa wrote: > > l'ho fatto con un utente diverso (pnp_RSIFNC), per ora sto prendendo > quelle che avrei dovuto comunque prendere, poi forzo le altre > > 2017-01-02 10:29 GMT+01

Re: [gentoo-dev] New Project: Gentoostats

l'ho fatto con un utente diverso (pnp_RSIFNC), per ora sto prendendo quelle che avrei dovuto comunque prendere, poi forzo le altre 2017-01-02 10:29 GMT+01:00 Gokturk Yuksek : > Hi everyone, > > I'm happy to announce the launch of the Gentoostats project. > > Gentoostats is a

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

2016-12-14 19:32 GMT+01:00 Nathan Zachary : > On 14/12/16 12:29, Fabian Groffen wrote: > > On 14-12-2016 13:01:16 -0500, Doug Freed wrote: > >> On Wed, Dec 14, 2016 at 12:48 PM, Nathan Zachary > >> wrote: > >>> On 14/12/16 10:11, Doug Freed

Re: [gentoo-dev] Gentoo on Android stage3

Christmas is coming, I'll enjoy this Thank you! 2016-10-29 17:09 GMT+02:00 Benda Xu : > Hi Fellows, > > This is an announcement of the latest Gentoo on Android stage3 tarball, > > http://distfiles.gentoo.org/experimental/prefix/rap/rap- >

Re: [gentoo-dev] newsitem: important fstab update

2016-10-28 16:42 GMT+02:00 Ian Stakenvicius <a...@gentoo.org>: > On 27/10/16 09:54 PM, Francesco Riosa wrote: > > 2016-10-28 3:32 GMT+02:00 Ian Stakenvicius <a...@gentoo.org > > <mailto:a...@gentoo.org>>: > > > > On 27/10/16 09:23 PM, Gregory Woodb

Re: [gentoo-dev] newsitem: important fstab update

2016-10-28 3:32 GMT+02:00 Ian Stakenvicius : > On 27/10/16 09:23 PM, Gregory Woodbury wrote: > > Out of curiosity, why do folks say that the use of LABEL= is not > > good? I realize that s are not required when doing a mkfs, but > > if the admin does so reliably and wants to use

Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 11:04 GMT+02:00 Michał Górny : > Dnia 26 października 2016 10:49:04 CEST, Joshua Kinard > napisał(a): > >On 10/25/2016 13:15, William Hubbs wrote: > >> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote: > >>> On Tue, Oct 25, 2016 at 1:01

Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 19:15 GMT+02:00 William Hubbs : > On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote: > > On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs > wrote: > > > If you are not using /dev/disk/by-* paths in fstab, you do not need to > > take

Re: [gentoo-portage-dev] [PATCH] Add emerge --autounmask-continue option (bug 582624)

Hi, thanks for your continuous work, just an implementation detail, it may be possible to avoid a new option reusing the current autounmask one? instead of --autounmask [ y | n ] --autounmask-only [ y | n ] --autounmask-write [ y | n ] --autounmask-continue [ y | n ] something like:

Re: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

2016-06-01 0:03 GMT+02:00 Mike Gilbert : > On Tue, May 31, 2016 at 5:34 PM, Jörg Schaible > wrote: > > How can I select different linguas for individual packages with this > > approach? > > Why would you want to? > > In addition to Jörg Schaible

Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree

2016-05-16 3:39 GMT+02:00 Brian Dolbec : > > portage-2.3.0_rc1 and repoman-2.3.0_rc1 are now in the tree. > > portage-2.3.0_rc1 is essentially the portage 2.2.28 release with only a > few small patches applied. It mostly just installs less code, namely > the repoman code. > >

Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-14 21:23 GMT+01:00 Mike Frysinger : > On 14 Feb 2016 11:41, Brian Dolbec wrote: > > On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote: > > > On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote: > > > > If, for any reason, eudev should be abandoned - we can just

Re: [gentoo-dev] Changing order of default virtual/udev provider

2016-02-09 13:17 GMT+01:00 Rich Freeman : > On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric > wrote: > > > > A pure udev system is in comparison, much simpler than a systemd system. > > I don't buy that at all. In systemd you have a unified object model >

Re: [gentoo-dev] Paths in pkg-config file when using escons?

and what about $LIBDIR ? libmypaint build system is totally broken. Please tell upstream, eventually providing a better one. just for testing purposes sed -e "s:${D}::" ${D}/usr/lib/pkgconfig/*.pc || die "cannot sanitize *.pc files" should suffice. 2015-12-23 21:16 GMT+01:00 Peter Stuge

Re: [gentoo-dev] more packages up for grabs

Il 19/05/2015 23:57, Aaron Bauman ha scritto: On Tuesday, May 19, 2015 03:40:31 PM Francesco Riosa wrote: Il 18/05/2015 23:13, Tim Harder ha scritto: * media-gfx/darktable * media-gfx/dcraw * media-gfx/gmic * media-gfx/rawtherapee * media-plugins/gimp-gmic nobody for these? they are rather

Re: [gentoo-dev] more packages up for grabs

Il 20/05/2015 04:18, Daniel zlg Campbell ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/19/2015 06:40 AM, Francesco Riosa wrote: Il 18/05/2015 23:13, Tim Harder ha scritto: * media-gfx/darktable * media-gfx/dcraw * media-gfx/gmic * media-gfx/rawtherapee * media-plugins/gimp

Re: [gentoo-dev] more packages up for grabs

Il 18/05/2015 23:13, Tim Harder ha scritto: * media-gfx/darktable * media-gfx/dcraw * media-gfx/gmic * media-gfx/rawtherapee * media-plugins/gimp-gmic nobody for these? they are rather important for anyone who does photo on linux.

Re: [gentoo-dev] CI services for Gentoo Social Contract meanings of dependant notifications on depgraph breakages

Il 16/04/2015 12:41, Peter Stuge ha scritto: Rich Freeman wrote: If people want pure-FOSS tools, they need to make it happen. Selfless work lives on moral support among a few other things. listen: Git is the child of bitkeeper closing it's freeware program it gave the kernel community a good

Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2

2. should be nuked from orbit anyway, just curious do someone know any? 2013/7/29 Rich Freeman ri...@gentoo.org On Mon, Jul 29, 2013 at 4:57 PM, Pacho Ramos pa...@gentoo.org wrote: Grepping in the tree, looks like only some old genkernel versions are depending on it. Apart of that, what is

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

2013/1/23 Pacho Ramos pa...@gentoo.org El mié, 23-01-2013 a las 23:45 +0200, Samuli Suominen escribió: On 23/01/13 23:21, Pacho Ramos wrote: El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió: please review this news item, seems we need one after all Why don't you drop

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

2013/1/23 Fabio Erculiani lx...@gentoo.org I think that the problem is that it is trying to be smart when it's not really possible (unless you want to cover all the corner cases, which is a pain). Hum, but if we could not be smart enough we can at least try to be very annoying. what about a

Re: [gentoo-dev] RFC: new qt category

2013/1/19 Michael Weber x...@gentoo.org But please don't double the qt. yay for lib-cute/qt-core

Re: [gentoo-dev] RFC: new qt category

2013/1/19 Michał Górny mgo...@gentoo.org On Thu, 17 Jan 2013 21:57:16 +0800 Ben de Groot yng...@gentoo.org wrote: Presently we already have a good number of split qt-* library packages in x11-libs. With the arrival of Qt5 upstream has gone a lot further in modularization, so we expect

Re: [gentoo-dev] call for testers: udev predictable network interface names

2013/1/19 William Hubbs willi...@gentoo.org On Fri, Jan 18, 2013 at 10:07:42AM -0500, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/01/13 09:54 AM, William Hubbs wrote: On Fri, Jan 18, 2013 at 08:33:13AM -0500, Ian Stakenvicius wrote: -BEGIN PGP

Re: [gentoo-dev] force verbose build log as per PMS policy?

+1 for verbosity Il giorno 01/ago/2012 13:21, hasufell hasuf...@gentoo.org ha scritto: We already had a discussion about cmake-utils.eclass and forcing verbose build log for that which was approved: http://archives.gentoo.org/gentoo-dev/msg_ce7d33748936663e84a5463fbf7f4d39.xml Also we have

[gentoo-dev] bug XXXXXX sys-libs/tdb fail check for building library support

neither stable tdb-1.2.9 nor tdb-1.2.10 install any shared library when build with distcc, because of a failing chech @ configure time Checking for building library support: not found setting MAKEOPTS=-j1 does not suffice FEATURES=-distcc is needed FYI the check is inside

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

2012/5/22 Mike Frysinger vap...@gentoo.org: On Monday 21 May 2012 18:16:25 Markos Chandras wrote: Excuse me but the way this change was handled is a bit depressing. First, the ebuilds should have been fixed to inherit eutils and then remove eutils from autotools. Now, a bunch of ebuilds are

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

2012/5/22 Mike Frysinger vap...@gentoo.org: On Monday 21 May 2012 19:01:04 Francesco Riosa wrote: 2012/5/22 Mike Frysinger: On Monday 21 May 2012 18:16:25 Markos Chandras wrote: Excuse me but the way this change was handled is a bit depressing. First, the ebuilds should have been fixed

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

2012/5/21 Mike Frysinger vap...@gentoo.org: On Monday 21 May 2012 19:24:27 Francesco Riosa wrote: 2012/5/22 Mike Frysinger: On Monday 21 May 2012 19:01:04 Francesco Riosa wrote: 2012/5/22 Mike Frysinger: On Monday 21 May 2012 18:16:25 Markos Chandras wrote: Excuse me but the way

Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags

2012/5/5 Michael Weber x...@gentoo.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/05/2012 09:55 PM, Dale wrote: Not to mention, you add the possibility that the user may miss the change since they are not expecting it.  I would expect it when I was changing profiles but not so

Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)

What's changed from 2006 in version handling? Il giorno 28/apr/2012 11:39, Ciaran McCreesh ciaran.mccre...@googlemail.com ha scritto: On Sat, 28 Apr 2012 10:52:07 +0200 Michał Górny mgo...@gentoo.org wrote: On Fri, 27 Apr 2012 21:12:27 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com

Re: [gentoo-dev] Should ${T} be defined in pkg_prepare ?

2012/3/31 Tiziano Müller dev-z...@gentoo.org: Am Samstag, den 31.03.2012, 14:44 +0200 schrieb Ulrich Mueller: On Sat, 31 Mar 2012, Maciej Grela wrote: I've read the PMS and I haven't found information whether this variable is supposed to be set during pkg_prepare or not. There is no such

Re: [gentoo-dev] Deprecate EAPI1?

2012/3/11 Ciaran McCreesh ciaran.mccre...@googlemail.com: On Sun, 11 Mar 2012 09:52:40 -0400 Rich Freeman ri...@gentoo.org wrote: Is there really much of a benefit to this?  I guess for anybody who runs scripts to mass-manipulate ebuilds it might be helpful, but I think all the package

Re: [gentoo-dev] Deprecate EAPI1?

top-posting me too to avoid more confusion, sorry Se my other reply to this thread, upgrading in place an old gentoo install is nearly impossible, it's so bad that glibc breakage can occour, that require a knowledge of the system so high that everything else become nuances of a vague problem.

[gentoo-dev] color management in gentoo (kde expecially) proposal for help

Hi, my name is Francesco Riosa, I would be interested in a more complete support of the oyranos color managment programs in ::gentoo. Oyranos is intended to be multy platform and in some sense multy os, but in the current incarnation has good support for kde. In case there is interest I can

Re: [gentoo-dev] color management in gentoo (kde expecially) proposal for help

have questions about other software they can help you find the right people. will do that in the weekend too Cheers, Andreas Hi,    my name is Francesco Riosa, I would be interested in a more complete support of the oyranos color managment programs in ::gentoo. Oyranos is intended

  1   2   >