Re: [gentoo-dev] Deprecating repoman

[Francesco Riosa]

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 that?

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

[Francesco Riosa]

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
> supported by the PMS, and Portage handles it somewhat suboptimally
> (renaming the old file and leaving it orphaned).
>
> Is it possible to force the package to own the file may be touching it in
src_install() ?

This way we have a dirty installation but no orphaned file and it would be
back to normal at next install

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

[Francesco Riosa]

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 becomes 3.1.x, and primary development happens there
>
> - 3.0.x becomes the LTS branch and only major bugfixes are backported
> there
>
> As things settle down in the future, master would become 3.2.x, 3.1.x
> would become LTS, 3.0.x will be discontinued and so on.
>
> WDYT?
>

Sorry but portage is too strictly related to the ebuilds in tree, recent
removal of EAPI=5 from most eclasses underlined that.
Or to put id differently if you want a LTS portage you also need a certain
number of "protected" eclasses and ebuilds
It seems a lot of (very appreciated but don't count on me) work



>
> --
> Best regards,
> Michał Górny
>
>
>
>

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

[Francesco Riosa]

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 sense" of package maintainers.
>
> 

After so many tentatives to fix the kernel checks in these years (almost
all of which had drawbacks or missed some extreme corner case) it's
probably better to give to the user instruments to do ihs own checks rather
than trying to be smart.

An example of how this could work follow:
A file (or directory) is created in /etc/ that contains a list of
,,
Then the user is responsible to check that list against the wanna be
running kernel

This save probably both computational and human time

state_required - should be well thought out since it can be required
present, absent or maybe even suggested

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

[Francesco Riosa]

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 in Portage team.
> >
> > The primary problem with the current output format is that different
> > kinds of messages differ only in color.  This makes them
> > indistinguishable without colors and hard to grep.  ago's been asking
> > for a better way to grep for QA warnings and this is pretty much what
> > motivated me to do this.
> >
> > The proposed new format distinguished message types both using colors
> > and strings.  This is roughly inspired by Xorg logs.  For example,
> > instead of:
> >
> >  * some message
> >  * other message
> >  * hell if i know what this is
> >
> > You get:
> >
> > [WW] some message
> > [EE] other message
> > [QA] hell if i know what this is
> >
> > I've also added more colors to explicitly distinguish einfo from elog,
> > and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> > used by Portage with four-character versions to keep messages aligned.
> > The 'zings' used for merging files remain three-character, so now it's
> > easily possible to distinguish messages from installed file list.
>
> Didn't expect to be the only dissenting opinion on something like this
> but. . . Some applications parse portage output looking for these
> 'zings'. At very least app-portage/kuroo does it this way; there must be
> others, right? This is obviously not the ideal way to get information
> out of portage, but it's been stable for the 15 years Kuroo has existed.
> 10-ish years ago dol-sen started some work on building and API for
> portage, but then got sucked into core portage development to the point
> of abandoning their GTK+ portage GUI porthole, which was the original
> impetus for an API, and as far as we know, the API never made it to the
> point it could replace parsing the output.
>
> It wouldn't be worth blocking progress for one application that not many
> people use, but assuming there are others that will also break with this
> change. Are we sure there's no way to support ago's (very valuable) work
> without breaking other things?
>
> -A
>

Kuroo is already a quite complex application that parse portage output. A
quick grep seems to show that changes needed are quite manageable.
Also the parsing should be more accurate with proposed changes.
Rather it should be easy for the application to know in advance which
format the output will be.
There is also the opportunity to have a flag that enable (or disable) the
augmented output, but IMHO this should be done only if the added complexity
is NIL

$ grep -c  -Ers 'QRegExp |QregularExpression ' -i kuroo-1.2.1  | grep -v
:0$
kuroo-1.2.1/TODO:1
kuroo-1.2.1/src/history/history.cpp:3
kuroo-1.2.1/src/config/configdialog.h:2
kuroo-1.2.1/src/queue/queuelistview.cpp:1
kuroo-1.2.1/src/core/scanupdatesjob.cpp:1
kuroo-1.2.1/src/core/global.h:2
kuroo-1.2.1/src/core/packageinspector.cpp:4
kuroo-1.2.1/src/core/packageversion.h:2
kuroo-1.2.1/src/core/etcupdate.h:1
kuroo-1.2.1/src/core/portagedb.cpp:2
kuroo-1.2.1/src/core/scanhistoryjob.cpp:3
kuroo-1.2.1/src/core/global.cpp:1
kuroo-1.2.1/src/core/dependatom.h:2
kuroo-1.2.1/src/core/emerge.cpp:8




>
> >
> > The PR doing this is: https://github.com/gentoo/portage/pull/759
> >
> > Example screenshot:
> >
> https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png
> >
>
>

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

[Francesco Riosa]

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
> removed.
>
> If this means that stable EAPI 5 only packages will continue to work - at
least until someone will replace them with a better EAPI stable version
then you have my complete moral support.
This obviously also affect all eclasses used by EAPI 5 only stable packages.

Re: [gentoo-dev] New project: binhost

[Francesco Riosa]

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,
> >precompiled packages for a subset of configurations, via central
> >binary package hosting. Currently we are still in the conceptual
> >planning stage. "
> >
> >https://wiki.gentoo.org/wiki/Project:Binhost
> >
> >If you're interested in helping out, feel free to add yourself on the
> >wiki page.
> >
> >Note that I see actually *building* the packages not as the central
> >point of the project (that could be e.g. a side effect of a
> >tinderbox). I'm more concerned about
> >* what configurations should we use
> >* what portage features are still needed or need improvements (e.g.
> >binpkg signing and verification)
> >* how should hosting look like
> >* and how we can test this on a limited scale before it goes "into
> >production"
> >* ...
> >
> >Comments, ideas, flamebaits? :D
> >
> >Cheers,
> >Andreas
> >
>
> It would be great to improve portage speed with handling binpkgs. I
> already have my own binhost for a couple of Gentoo systems and even
> though these systems don't have to compile anything themselves,
> installing ~100 to ~200 binpkgs takes way more than an hour of
> installation time. Arch Linux' pacman only takes a fraction of this
> time for the very same task.
> I know that I compare apples with pears here but even reducing the
> current portage time by 50% would be a huge improvement.
>
> Agreed, nowadays I do use Gentoo in two ways:
- From binpkgs usually for baremetal, server or desktop
- condensing part of the system in a squashfs image, usually for containers

Binpkg performance is acceptable albeit not blazing fast for machines with
500-800 packages (usually server) while for desktops which easily have 2000
packages the time to update can be hours.

While we are here the squashfs images way to distribute is wonderful and
handy, except that it's read-only and managing /etc is more challenging
without the commodity of etc-update/dispatch-conf, would be nicer to have a
comparable tool to be used for this.
Suggestions about the implementation well accepted

Cheers,
Francesco (vivo) Riosa

Re: [gentoo-dev] New project: binhost

[Francesco Riosa]

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) with different build attributes (arch, USE, CFLAGS,
> > DEPENDS, whatever).
> > 3.  Ability to pick the most appropriate binary packages to use based
> > on user preferences (with a mix of hard and soft preferences).
>
> The more definite answer should come from Zac, but I think a good part of
> this
> is already implemented. :)
>
> kind of, from make.conf manpage:

binpkg-multi-instance

  Enable support for  multiple  binary  package  in‐
  stances  per ebuild.  Having multiple instances is
  useful for a number of purposes, such as retaining
  builds that were built with different USE flags or
  linked against different  versions  of  libraries.
  The  location  of  any  particular  package within
  PKGDIR can be expressed as follows:

   ${PKGDIR}/${CATEGORY}/${PN}/${PF}-${BUILD_ID}.xpak

  The  build-id starts at 1 for the first build of a
  particular ebuild, and is  incremented  by  1  for
  each new build. It is possible to share a writable
  PKGDIR over NFS, and  locking  ensures  that  each
  package   added  to  PKGDIR  will  have  a  unique
  build-id. It is not necessary to migrate an exist‐
  ing PKGDIR to the new layout, since portage is ca‐
  pable of working with a mixed PKGDIR layout, where
  packages  using  the old layout are allowed to re‐
  main in place.

  The new PKGDIR layout is backward-compatible  with
  binhost  clients  running older portage, since the
  file format is identical, the per-package PATH at‐
  tribute  in  the  'Packages' index directs them to
  download the file from the correct URI,  and  they
  automatically  use  BUILD_TIME  metadata to select
  the latest builds.

  There is currently no automated way to  prune  old
  builds from PKGDIR, although it is possible to re‐
  move packages manually, and then run 'emaint --fix
  binhost' to update the ${PKGDIR}/Packages index.

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

[Francesco Riosa]

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:
https://docs.python.org/dev/library/functools.html#functools.lru_cache

I comment as this would increase code clarity.


I think portage developers try hard to avoid external dependancies
I hope hard they do



I think the key word here is 'external' - anything which is part of the
python standard library is game for inclusion in portage, and has/does
provide much needed optimisation. Many of the issues in portage are
so-called "solved problems" in computing terms, and as such, we should take
advantage of these to improve performance at every available opportunity.
Of course, there are presently only one, two or three key developers able
to make/test these changes (indeed at scale) so progress is often slower
than desirable in current circumstances...

[sent direct due to posting restrictions...]
yes I've replied too fast and didn't notice Sid was referring to 
_standard_ libraries (not even recent additions)


sorry for the noise

- Francesco

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

[Francesco Riosa]

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 increase code clarity.


I think portage developers try hard to avoid external dependancies
I hope hard they do

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

[Francesco Riosa]

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 package consumers are not caught off guard.


[snip]

For your interest, the binpkg archive for a small LAMP container goes 
from 659 to 540 MB, the "--rm" flag isn't really needed for binpkgs but 
it help reminder that zstd is the only one that does _not_ remove the 
original file after compression


BINPKG_COMPRESS="zstd"
BINPKG_COMPRESS_FLAGS="--rm --long --threads=1 --adapt=min=7,max=19"

tails of the binpkgdir list:

Before 659M total
  3411658 Feb 13 16:03 media-fonts/corefonts-1-r7.tbz2
  3421845 May  5 19:09 dev-python/virtualenv-16.7.9-r1.tbz2
  3450323 May  3 08:54 dev-libs/nss-3.52.tbz2
  3475698 May  5 19:09 app-portage/gentoolkit-0.4.8.tbz2
  3545935 May  8 07:48 app-text/poppler-data-0.4.9.tbz2
  3582965 May 10 23:08 dev-python/cython-0.29.15.tbz2
  3870491 May  5 18:59 dev-libs/glib-2.62.6.tbz2
  3889030 May  9 07:49 sys-apps/groff-1.22.3.tbz2
  4225576 Apr 22 17:07 dev-libs/openssl-1.1.1g.tbz2
  4374231 May  5 20:21 sys-libs/db-5.3.28-r2.tbz2
  4889813 May  5 19:13 sys-devel/gdb-9.1.tbz2
  6418288 Apr  3 11:13 app-editors/vim-core-8.2.0360.tbz2
  7971823 May  5 18:49 dev-scheme/guile-2.2.4.tbz2
  8841520 Apr 30 10:08 sys-devel/binutils-2.33.1-r1.tbz2
  9076674 May  5 19:10 media-gfx/imagemagick-7.0.10.7-r1.tbz2
  9201769 May 11 13:25 net-print/cups-2.3.3-r1.tbz2
  9297311 May  1 08:13 dev-db/mysql-connector-c-8.0.20.tbz2
 12229701 Apr 30 17:10 dev-util/cmake-3.16.5.tbz2
 12977553 Apr  8 01:44 dev-libs/boost-1.72.0-r1.tbz2
 13479702 May  5 18:55 dev-libs/icu-65.1-r1.tbz2
 13788355 May 11 13:27 app-text/ghostscript-gpl-9.50.tbz2
 14028322 Feb 27 01:55 dev-lang/perl-5.30.1.tbz2
 14131663 May  5 19:11 net-dns/bind-tools-9.14.8.tbz2
 14664302 May  5 19:05 sys-libs/glibc-2.30-r8.tbz2
 15235721 Apr 22 17:09 dev-vcs/git-2.26.2.tbz2
 25024737 May  5 18:52 dev-lang/python-3.7.7-r2.tbz2
 26011846 May 10 23:09 app-admin/ansible-2.9.7.tbz2
 26213157 May  5 18:53 dev-lang/python-3.8.2-r2.tbz2
 34949529 May  5 19:15 dev-lang/php-7.3.17.tbz2
 35364894 May  5 18:59 dev-lang/php-7.4.5.tbz2
 48130470 May  5 19:09 dev-db/mariadb-10.4.12.tbz2
123472207 Apr 18 19:32 sys-devel/gcc-9.3.0.tbz2

After 540M total
  3000375 May 12 00:44 media-fonts/corefonts-1-r7.tbz2
  3010790 May 12 00:53 net-analyzer/net-snmp-5.8-r5.tbz2
  3130214 May 12 00:38 dev-libs/nss-3.52.tbz2
  3221436 May 12 00:23 media-fonts/urw-fonts-2.4.9.tbz2
  3386623 May 12 01:04 app-portage/gentoolkit-0.4.8.tbz2
  3541169 May 12 00:33 sys-apps/groff-1.22.3.tbz2
  3675561 May 12 01:06 dev-libs/glib-2.62.6.tbz2
  4305825 May 12 00:49 dev-libs/openssl-1.1.1g.tbz2
  4828074 May 12 00:49 sys-devel/gdb-9.1.tbz2
  6392717 May 12 01:04 app-editors/vim-core-8.2.0360.tbz2
  6883802 May 12 00:54 net-dns/bind-tools-9.14.8.tbz2
  7704310 May 12 00:16 sys-devel/binutils-2.33.1-r1.tbz2
  8044941 May 12 00:43 dev-scheme/guile-2.2.4.tbz2
  8442280 May 12 00:57 dev-vcs/git-2.26.2.tbz2
  8945372 May 12 02:22 media-gfx/imagemagick-7.0.10.7-r1.tbz2
  8989043 May 12 02:05 net-print/cups-2.3.3-r1.tbz2
 10140244 May 12 02:08 dev-util/cmake-3.16.5.tbz2
 12680888 May 12 02:03 sys-libs/glibc-2.30-r8.tbz2
 12991659 May 12 00:56 dev-libs/icu-65.1-r1.tbz2
 13634394 May 12 02:10 dev-libs/boost-1.72.0-r1.tbz2
 13861694 May 12 00:27 dev-lang/perl-5.30.1.tbz2
 13905742 May 12 02:12 app-text/ghostscript-gpl-9.50.tbz2
 16061883 May 12 01:03 app-admin/ansible-2.9.7.tbz2
 18244923 May 12 00:50 dev-lang/python-3.7.7-r2.tbz2
 19061497 May 12 02:15 dev-db/mariadb-10.4.12.tbz2
 19284388 May 12 00:52 dev-lang/python-3.8.2-r2.tbz2
 30342169 May 12 02:22 dev-lang/php-7.3.17.tbz2
 30767719 May 12 02:21 dev-lang/php-7.4.5.tbz2
100930187 May 12 02:01 sys-devel/gcc-9.3.0.tbz2

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

[Francesco Riosa]

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] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee

[Francesco Riosa]

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 idea, yes.  I'd suggest going for the 'lightest'
> package first.  Would you be able to figure out some kind of measure
> on how heavy each of those packages is?  I suppose we need to account
> for build time and dependencies.
>
> All of these packages are pretty old and not receiving commits in years,
may I suggest that the order should be from the less prone to break to the
most prone to break?
I'll leave to maintainers decide on how to assign a vote on resilience, but
monitoring upstream, active forks and other distro should be taken in
account.

Best,
Francesco

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

[Francesco Riosa]

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, with regard to security in particular.
>
> Pushing gently upstream to upgrade bundled expat copy would (at least
temporarily) fix the issue and also benefit other use cases. Maybe they are
Gentoo friendly
they also release quite often, which would fix the problem soon

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

[Francesco Riosa]

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
untouched the others

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

[Francesco Riosa]

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
other packages it must always include also a numeric version like 3_8

Regarding your proposal getting rid of PYTHON_SINGLE_TARGET would be nice
but being able to have multiple version of python installed is nicer and
differentiate gentoo from most other distro

Alternative 2 is also nice, the only thing that make me dubious is that it
looks like it will be a gigantic work, but you have a better sense of the
situation and will be one of those doing the actual work, so go for it!

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

[Francesco Riosa]

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 desktop world thare are very few, but important packages that still
require it.
The Gimp being one prominent example



>
> If the answer is yes, we will need to decide on the following
> python-2-only packages.
>
> ,
> | $ comm -23 <(equery -qC h python_targets_python2_7 | sort ) <(equery -qC
> h python_targets_python3_6 | sort)
> | dev-lang/yasm-1.3.0
> | dev-libs/libxslt-1.1.33-r1
> | dev-python/backports-functools-lru-cache-1.5
> | dev-python/enum34-1.1.6-r1
> | dev-python/functools32-3.2.3
> | dev-python/futures-3.2.0
> | dev-python/pygobject-2.28.6-r55
> | dev-python/pygtk-2.24.0-r4
> | dev-python/subprocess32-3.2.7
> | dev-util/boost-build-1.70.0
> | dev-vcs/subversion-1.12.2
> | gnome-base/libglade-2.6.4-r2
> | net-analyzer/nmap-7.70
> | sys-devel/clang-8.0.1
> | x11-wm/xpra-2.4.3
> `
>
"As much as possible" IMHO exclude at least yasm, libxslt and nmap



>
> If the answer is no, to avoid holding back new versions having only
> python3, such as bug 671796 for dev-python/matplotlib bump, old versions
> with python_targets_python2_7 and new versions without should be
> co-installable into different SLOTs.
>

whatever your (gentoo dev) choice  I wish you good luck

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

[Francesco Riosa]

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 
> >
> > Its likely this removal will cause the same kinds of problems faced by
> > the recent virtual/pam removal, just its more insidious, as the
> > dependency on the virtual is hidden away inside an eclass.
> >
> > But this still means that anything users have already installed will
> > still depend on this, and without --changed-deps=y, it will break
> > portage's resolution of anything currently installed using this crate.
> >
> > You can work-around this by -r1 bumping everything that used this
> > eclass  but this just goes to show why there's policy against
> > eclasses changing the dependencies of their consumers without any
> > consumer involvement.
> tl;dr - play with fire .. you're gonna get burned .. :]
>
> Good luck with the core aim .. there is probably a slow-and-steady approach
> that will win through ..
>
> So basically the eclass should be bumped, with the old one deprecated?

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

[Francesco Riosa]

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 extracting a single file is very fast and
does not depend from it's position in the archive.
The big disadvantage is that only "desktop" profile has unzip by default

Best regards,
-Francesco

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

[Francesco Riosa]

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 is a regular compressed tarball.  There's no
> junk
> > > appended to it but the metadata is stored inside it as
> > > /var/db/pkg/${PF}.  The contents are as compatible with the actual vdb
> > > format as possible.
> > >
> >
> > Just to clarify, you are suggesting we store the metadata inside the
> > contents of the binary package itself (e.g. where the other files that
> get
> > merged to the liveFS are?) What about collisions?
> >
> > E.g. I install 'machine-images/gentoo-disk-image-1.2.3' on a machine that
> > already has 'machine-images/gentoo-disk-image-1.2.3' installed, won't it
> > overwrite files in the VDB at qmerge time?
>
> Portage will obviously move the files out, and process them as metadata.
>  The idea is to precisely use a directory that can't be normally part
> of binary packages, so can't cause collisions with real files (even if
> they're very unlikely to ever happen).
>
> > > This has the following advantages:
> > >
> > > + Binary package is still stored as a single file.
> > >
> > > + It uses a standard compressed .tar format, with minimal
> customization.
> > >
> > > + The user can easily inspect and modify the packages with standard
> > > tools (tar and the compressor).
> > >
> > > + If we can maintain reasonable level of vdb compatibility, the user
> can
> > > even emergency-install a package without causing too much hassle (as it
> > > will be recorded in vdb); ideally Portage would detect this vdb entry
> > > and support fixing the install afterwards.
> > >
> >
> > I'm not certain this is really desired.
>
> Are you saying it's better that user emergency-installs a package
> without recording it in vdb, and ends up with mess of collisions
> and untracked files?
>
> Just because you don't like some use case doesn't mean it's not gonna
> happen.  Either you prepare for it and make the best of it, or you
> pretend it's not gonna happen and cause extra pain to users.
>
>
Another option would be to install in a near but not overlapping directory,
example:
/var/db/pkg/${PF}-binpkg

this way the user that know what to do with that data can play with it,
also portage could be instructed to stat() that directory and take action
(halt maybe?) if present.

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

[Francesco Riosa]

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 package, 
> should its maintainer find out it breaks by EAPI-7 bump.
>
>
FYI there was a similar discussion some time ago, since than ninja has
been the default backend for cmake (desktop system 2k packages), in this
time the following packages had (or still have) problems:

# cmake cannot use ninja if it's not installed...
dev-cpp/gtest cmake-make
dev-util/ninja cmake-make

net-analyzer/icinga2 cmake-make
media-gfx/gmic cmake-make

# ninja: error:
'vendor/scrypt/src/scrypt_original-build/libscrypt_sse2.a', needed by
'src/cryfs-cli/cryfs', missing and no known rule to make it
sys-fs/cryfs cmake-make

# Fortran not supported
sci-libs/blas-reference cmake-make
sci-libs/exodusii cmake-make
sci-libs/lapack-reference cmake-make

# error
dev-libs/appstream cmake-make
kde-plasma/kinfocenter cmake-make
app-doc/doxygen cmake-make
net-irc/quassel cmake-make
kde-apps/libksieve cmake-make

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

[Francesco Riosa]

please ignore my previous email

>

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

[Francesco Riosa]

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 right line
>
> LICENSE="GPL-2+ "
> LICENSE+="bar? ( GPL-2 ) " # GPL-2 only
> LICENSE+="foo? ( GPL-3+ )"
>

Wouldn't this break metadata cache?

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

[Francesco Riosa]

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 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 meaning for the
> >>>> "test" USE flag.
> >>> We should eschew idealism about how the world *should* behave, and
> avoid
> >>> making portage a steaming garbage heap in order to comply with a
> >>> terrible PMS specification of a heavily used feature.
> >> Portage still works just fine for most people who would enable
> >> FEATURES=test. Stop exaggerating.
> >>
> > People enabling FEATURES=test on most but not all packages had some
> > troubles and they need to disable them in both package.{env,use}
> > I'd like to have a flag to reinstate the previous portage behaviour, but
> > that's probably too late
>
> Would a FEATURES setting that implies RESTRICT="!test? ( test )" for all
> ebuilds do what you want?
>

"want" is too much,
but it would have been pleasant to have something to keep portage
dependancies working as before.
"testrespectuse" or "usetestrespectfeatures" come to mind or another
command line option.




> --
> Thanks,
> Zac
>

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

[Francesco Riosa]

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 meaning for the
>>> "test" USE flag.
>> We should eschew idealism about how the world *should* behave, and avoid
>> making portage a steaming garbage heap in order to comply with a
>> terrible PMS specification of a heavily used feature.
> Portage still works just fine for most people who would enable
> FEATURES=test. Stop exaggerating.
>
People enabling FEATURES=test on most but not all packages had some
troubles and they need to disable them in both package.{env,use}
I'd like to have a flag to reinstate the previous portage behaviour, but
that's probably too late

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

[Francesco Riosa]

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 revert request and
instead ask for review of this patch:

From de7bec54c51361ae2aecbfa06a9cf3300a338dca Mon Sep 17 00:00:00 2001
From: Francesco Riosa 
Date: Mon, 6 Aug 2018 19:18:05 +0200
Subject: [PATCH] linux-info.eclass: CONFIG_LOCALVERSION for out of source
 builds

Closes: https://bugs.gentoo.org/662772
---
 eclass/linux-info.eclass | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index b158e345d16..98ec0ac8dab 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -548,13 +548,22 @@ get_version() {
     return 1
 fi
 
+    [ -d "${OUTPUT_DIR}" ] && KV_OUT_DIR="${OUTPUT_DIR}"
+    if [ -n "${KV_OUT_DIR}" ];
+    then
+        qeinfo "Found kernel object directory:"
+        qeinfo "    ${KV_OUT_DIR}"
+    fi
+    # and if we STILL have not got it, then we better just set it to KV_DIR
+    KV_OUT_DIR="${KV_OUT_DIR:-${KV_DIR}}"
+
 # Grab the kernel release from the output directory.
 # TODO: we MUST detect kernel.release being out of date, and
'return 1' from
 # this function.
-    if [ -s "${KV_DIR}"/include/config/kernel.release ]; then
-        KV_LOCAL=$(<"${KV_DIR}"/include/config/kernel.release)
-    elif [ -s "${KV_DIR}"/.kernelrelease ]; then
-        KV_LOCAL=$(<"${KV_DIR}"/.kernelrelease)
+    if [ -s "${KV_OUT_DIR}"/include/config/kernel.release ]; then
+        KV_LOCAL=$(<"${KV_OUT_DIR}"/include/config/kernel.release)
+    elif [ -s "${KV_OUT_DIR}"/.kernelrelease ]; then
+        KV_LOCAL=$(<"${KV_OUT_DIR}"/.kernelrelease)
 else
     KV_LOCAL=
 fi
@@ -586,15 +595,6 @@ get_version() {
     done
 fi
 
-    [ -d "${OUTPUT_DIR}" ] && KV_OUT_DIR="${OUTPUT_DIR}"
-    if [ -n "${KV_OUT_DIR}" ];
-    then
-        qeinfo "Found kernel object directory:"
-        qeinfo "    ${KV_OUT_DIR}"
-    fi
-    # and if we STILL have not got it, then we better just set it to KV_DIR
-    KV_OUT_DIR="${KV_OUT_DIR:-${KV_DIR}}"
-
 # And we should set KV_FULL to the full expanded version
 KV_FULL="${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}${KV_LOCAL}"
 
-- 
2.18.0


From de7bec54c51361ae2aecbfa06a9cf3300a338dca Mon Sep 17 00:00:00 2001
From: Francesco Riosa 
Date: Mon, 6 Aug 2018 19:18:05 +0200
Subject: [PATCH] linux-info.eclass: CONFIG_LOCALVERSION for out of source
 builds

Closes: https://bugs.gentoo.org/662772
---
 eclass/linux-info.eclass | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index b158e345d16..98ec0ac8dab 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -548,13 +548,22 @@ get_version() {
 		return 1
 	fi
 
+	[ -d "${OUTPUT_DIR}" ] && KV_OUT_DIR="${OUTPUT_DIR}"
+	if [ -n "${KV_OUT_DIR}" ];
+	then
+		qeinfo "Found kernel object directory:"
+		qeinfo "${KV_OUT_DIR}"
+	fi
+	# and if we STILL have not got it, then we better just set it to KV_DIR
+	KV_OUT_DIR="${KV_OUT_DIR:-${KV_DIR}}"
+
 	# Grab the kernel release from the output directory.
 	# TODO: we MUST detect kernel.release being out of date, and 'return 1' from
 	# this function.
-	if [ -s "${KV_DIR}"/include/config/kernel.release ]; then
-		KV_LOCAL=$(<"${KV_DIR}"/include/config/kernel.release)
-	elif [ -s "${KV_DIR}"/.kernelrelease ]; then
-		KV_LOCAL=$(<"${KV_DIR}"/.kernelrelease)
+	if [ -s "${KV_OUT_DIR}"/include/config/kernel.release ]; then
+		KV_LOCAL=$(<"${KV_OUT_DIR}"/include/config/kernel.release)
+	elif [ -s "${KV_OUT_DIR}"/.kernelrelease ]; then
+		KV_LOCAL=$(<"${KV_OUT_DIR}"/.kernelrelease)
 	else
 		KV_LOCAL=
 	fi
@@ -586,15 +595,6 @@ get_version() {
 		done
 	fi
 
-	[ -d "${OUTPUT_DIR}" ] && KV_OUT_DIR="${OUTPUT_DIR}"
-	if [ -n "${KV_OUT_DIR}" ];
-	then
-		qeinfo "Found kernel object directory:"
-		qeinfo "${KV_OUT_DIR}"
-	fi
-	# and if we STILL have not got it, then we better just set it to KV_DIR
-	KV_OUT_DIR="${KV_OUT_DIR:-${KV_DIR}}"
-
 	# And we should set KV_FULL to the full expanded version
 	KV_FULL="${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}${KV_LOCAL}"
 
-- 
2.18.0

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

[Francesco Riosa]

hi all,

   like someone else I do build out of sources kernels, since commit
50078fbbb3966773401c1fc59838c1e5952c1318 it has been impossible to build
some modules from gentoo repo.

See bug https://bugs.gentoo.org/662772 reported by another user with the
same problem.

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.

thank you,
Francesco Riosa

Re: [gentoo-dev] Trustless Infrastructure

[Francesco Riosa]

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 possible to embed the signature _inside_ ebuilds and other
common files to spare at least 80k from those 260k?

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

[Francesco Riosa]

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 grsec/pax
>>   (more or less obsolete).
>> * things that are now in default profiles anyway (aslr, stack
>>   protector).
>> * things that probably should be in default profiles (relro, now linker
>>   flags)
>> * -fstack-check, which should eventually be replaced with
>>   -fstack-clash-protection (only available in future gcc's) and that
>>   should probably also go into default profiles.
>> * Furthermore hardened disables some useful features due to their
>>   incompatibility with pax (e.g. sanitizers).
>>
>> So it's stuff that either is obsolete or probably should be a candidate
>> for main profiles. Maybe we should strive for "hardened-by-default".
>>
> You're forgetting selinux.  Most of Zorry's work has made it into gcc
> and is now being enabled by our default toolchain.  Some kernel features
> have also been improved upstream.  With upstream carrying a lot of the
> work we did, I think 'hardened-by-default' minus selinux should be the
> goal of Gentoo.
>
Hardened had strong impact in some workflows, surpassing 10%.
Overhead could be acceptable in some situation but unwanted in others,
main profiles are obscure and difficult to change for most.
For this reason I'd like to ask to carefully evaluate if a security
feature can be enabled without suddently change the behaviour (worse
performances) of a machine running Gentoo.
Instead it would be good to have a guide on how to further harden any
profile.
If the hardening at any cost argument wins however we MUST have a guide
on ho to disable at least the most impactful options.

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

[Francesco Riosa]

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 doesn't permit
>> this but have this feature could be help users to define our
>> profiles under overlays.
>> Something like this:
>> sys-devel/gcc::gentoo
> Conceptually that makes no sense. sys-devel/gcc is the name of an
> upstream package, so what does it even mean to mask it in one
> repository but not in another? If it's the same package, then it
> should behave in the same way, regardless of the repository its ebuild
> it hosted in (or the package being installed, in which case it is no
> longer in an ebuild repository).
>
> If it is a different package however, then it should have a different
> name.
Sorry to say it bluntly but this make no sense at all, even changing a
USE flag make the package behave wildly differently.
Once we agree that an upstream (complex enough) package may have
different incarnations two ebuilds from different maintainers may please
differently the user.
I'm not sure this choice belong to profiles but not because same
upstream correspond to same files on filesystem.

>
> Ulrich




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Functional portage with namespace

[Francesco Riosa]

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 two binaries.
> If a hard-timestamp is to be used, assuming you have portage via git,
> then it might be desirable to hard-timestamp based on either:
>
> a) the timestamp of the specific ebuilds last change
> b) the timestamp of the most-recent-of specific ebuild+eclass's last change
> c) the timestamp of the specific ebuilds initial commit
d) for rsync users the timestamp of the repository, kept in metadata/,
the timestamp of last commit otherwise
>
> I'm not sure which one is more practical though.
>
> Sounds like it would be an "experts" tool which would become far more 
> practical
> for people who are using custom overlays to maintain their production systems,
> and those people can naturally make guarantees about their repos being in git,
> and they can decide which of those 3 options ( well, the ones we
> provide at least ) are most suited to what they're doing.
>

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

[Francesco Riosa]

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 you that static linking is almost always a bad
> idea. It has serious security implications, it is poorly supported on
> *nix systems (example: library dependencies are provided via hacks, we
> don't have proper rebuild capabilities) and should be basically
> considered  a great evil. Partially relevant doc: [1].
>
> This is why Gentoo does not generally support statically linking stuff,
> and we force dynamic linking whenever possible (sometimes even going too
> far with that but that's another story). We only allow static linking
> for special cases where shared linking can't be used for one reason
> or another.
>
> As part of that we also shouldn't deliver static libraries unless
> absolutely necessary to satisfy the dependencies of applications which
> we support built statically. Back in the day, Gentoo developers were
> pushing against packages that built static libraries unconditionally.
> However, it seems that at some point this front changed from 'fighting
> unconditionally built static libraries' to 'proliferating USE=static-
> libs everywhere'. Which is bad.
>
> So, developers, please *stop adding USE=static-libs* to random libraries
> that have no reason whatever to be statically linked to. And by that I
> mean a good reason, not creeping featurism, not 'user asked for it', not
> 'this broken package hardcodes libfoo.a'.
>

this would make impossible to use qemu static with binfmt alas
https://wiki.debian.org/QemuUserEmulation
Also looking for which packages are eligible for static libraries or not is
more work, not less, because it's a whole different layer of dependancies
(when doing the qemu stuff I just decided to build static for everything
rather than manage use flags per package)

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

[Francesco Riosa]

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 python-any-r1_pkg_setup()
call python_setup() itself and automake ebuild does NOT define it's own
pkg_setup() (thus python-any-r1 pkg setup is used).

Result is that with no python:2.7 installed ebuild will fail, always
both with test enabled or disabled.

I've realized all this after bug https://bugs.gentoo.org/648940 was
closed, that discussion didn't go very well, so I'd like to ask before
opening a different bug

It's correct to ask the maintainer to define pkg_setup() in automake ebuild?

if so should it be empty like:
pkg_setup() { : }
or it should contain default like
pkg_setup() { default }

or another solution is preferred?

Thanks in advance,
Francesco (vivo)

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

[Francesco Riosa]

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
includes the GNU assembler gas.

   - Supported assembler names: as, gas, may have toolchain specific prefix
   - Supported source files extensions: .s, .asm
   - .S files, i.e. assembler files which require preprocessing, are not
   supported
   - Involved files: CMakeASM-ATTInformation.cmake,
   CMakeDetermineASM-ATTCompiler.cmake, CMakeTestASM-ATTCompiler.cmake




>
> Bug: https://bugs.gentoo.org/625844
> ---
>  eclass/cmake-utils.eclass | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index b9f69a824b14..ef3f3c2607f8 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -516,6 +516,7 @@ cmake-utils_src_configure() {
> fi
> cat > "${build_rules}" <<- _EOF_ || die
> SET (CMAKE_ASM_COMPILE_OBJECT "
>  ${includes} ${CPPFLAGS}  -o  -c " CACHE
> STRING "ASM compile command" FORCE)
> +   SET (CMAKE_ASM-ATT_COMPILE_OBJECT "
>  ${includes} ${CPPFLAGS}  -o  -c " CACHE
> STRING "ASM compile command" FORCE)
> SET (CMAKE_C_COMPILE_OBJECT " 
> ${includes} ${CPPFLAGS}  -o  -c " CACHE STRING "C
> compile command" FORCE)
> SET (CMAKE_CXX_COMPILE_OBJECT "
>  ${includes} ${CPPFLAGS}  -o  -c " CACHE
> STRING "C++ compile command" FORCE)
> SET (CMAKE_Fortran_COMPILE_OBJECT
> "  ${includes} ${FCFLAGS}  -o
>  -c " CACHE STRING "Fortran compile command" FORCE)
> @@ -531,6 +532,7 @@ cmake-utils_src_configure() {
> local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> cat > ${toolchain_file} <<- _EOF_ || die
> SET (CMAKE_ASM_COMPILER "${myCC/ /;}")
> +   SET (CMAKE_ASM-ATT_COMPILER "${myCC/ /;}")
> SET (CMAKE_C_COMPILER "${myCC/ /;}")
> SET (CMAKE_CXX_COMPILER "${myCXX/ /;}")
> SET (CMAKE_Fortran_COMPILER "${myFC/ /;}")
> @@ -609,6 +611,7 @@ cmake-utils_src_configure() {
> if [[ ${CMAKE_BUILD_TYPE} != Gentoo && ${EAPI} != 5 ]]; then
> cat >> ${common_config} <<- _EOF_ || die
> SET (CMAKE_ASM_FLAGS_${CMAKE_BUILD_TYPE^^} ""
> CACHE STRING "")
> +   SET (CMAKE_ASM-ATT_FLAGS_${CMAKE_BUILD_TYPE^^} ""
> CACHE STRING "")
> SET (CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE
> STRING "")
> SET (CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE^^} ""
> CACHE STRING "")
> SET (CMAKE_Fortran_FLAGS_${CMAKE_BUILD_TYPE^^} ""
> CACHE STRING "")
> --
> 2.16.2
>
>
>

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

[Francesco Riosa]

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 slight concerns I have.
>
>> To accomplish this, force dev-db/mysql-connector-c to be the only souce
>> of libmysqlclient.so.
>>
>> Packages that choose to support  libmariadb.so instead can include a
>> libmariadb USE to hook up to dev-db/mariadb-connector-c that will be
>> introduced (and they can live side-by-side).  The motivation for this
>> could be licensing with libmariadb being LGPL instead of GPL.  This is
>> similar to ffmpeg/libav, except the libraries can co-exist.
> Have all the concerns about using slightly different libmysqlclient.so
> builds been resolved? Esp for pre-built binaries (I don't know if there
> are any left in the tree).
>
>> The current providers of virtual/mysql would get a new USE flag that is
>> MASKED for all users for the transition period and pull in the lib
>> package(s) when that USE is disabled.
>>
>> virtual/mysql would become a server reference for USERS only.  It would
>> be a QA warning violation to depend directly on virtual/mysql as it can
>> live anywhere.
> This part worries me slightly. I do understand that mysql-embedded is
> retired entirely, but apps that spun up their own local mysqld instance
> would still be affected this this change.

Checked a random desktop install and found these packages depending on
virtual/mysql:

vivo@Monfi ~ $ equery d virtual/mysql
 * These packages depend on virtual/mysql:
dev-db/mariadb-10.2.12 (server ? ~virtual/mysql-5.6[embedded=,static=])
dev-libs/apr-util-1.6.1 (mysql ? =virtual/mysql-5*)
dev-libs/cyrus-sasl-2.1.26-r11 (mysql ? virtual/mysql)
dev-libs/redland-1.0.17-r1 (mysql ? virtual/mysql)
kde-apps/akonadi-17.12.2 (mysql ? virtual/mysql)
net-analyzer/net-snmp-5.7.3_p3 (mysql ? virtual/mysql)
net-mail/mailutils-3.4 (mysql ? virtual/mysql)
sci-mathematics/glpk-4.63 (mysql ? virtual/mysql)

It would be interesting to know how their ${*DEPEND} should look after
the change.

Honestly I'd also like to understand the rationale better, why this
change is needed?
Are the implementations of Oracle mysql and Mariadb so different that
it's not possible anymore to consider those equivalent (for what
packages see)?

Thanks in advance,
Francesco



signature.asc
Description: OpenPGP digital signature

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

[Francesco Riosa]

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 one of the
first to pop up, indeed.


>
> I'd like to bring openQA to Gentoo, and start using it for both testing,
> and maybe, if promising at it seems, using it to automatize even more
> our testing workflow and help stabilization processes.
>

simply Great.


>
> I'm creating a new project for this, the aim is first to provide ebuilds
> for openQA, and meanwhile writing test cases that can be used to test
> Gentoo inside it. As i see it, it would be really helpful exp. regarding
> testing DEs  and track back regressions as well [2], it offers also
> integrations with bugzilla.
>

One of the first things noticed when trying to achieve full testing is that
it's a gigantic work. Suse seem to have a really good framework that
surely costed a lot to build.
How much can be reused of that work?
What are the differences, in features and building blocks expected for a
gentoo implementation?


>
> Development plan and goals will be updated to the Project page soon [3]
>
>
> What do you think?
>
>
That's a difficult objective worth the effort to achieve it


>
> Best,
>
> Ettore
>
>
> 1: http://open.qa/
>
> 2: https://openqa.opensuse.org/tests/600283
>
> 3: https://wiki.gentoo.org/wiki/Project:OpenQA
>
>
>

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

[Francesco Riosa]

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 Riosa
> <viv...@gmail.com <mailto: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
> >> 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 2.7 and 3.6 (latest) installed
> >>   no python 3.5
> >> - don't want to mess dependencies (the warnings in the eclass
> are scary)
> >>
> >> So, what can be done to let the user choose it's preferred python
> >> version(s) without having to build it's own overlay?
> >>
> >> One solution is to change ebuilds in tree to include a user
> variable in
> >> the PYTHON* arrays, example:
> >>
> >> -PYTHON_COMPAT=( python3_{4,5} )
> >> +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )
> >>
> >> if someone want to bet that packages are ok with 3.6/latest
> (even before
> >> a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
> >> /etc/portage/make.conf and run egencache.
> > I like the idea to inject values into PYTHON_COMPAT instead of
> > overriding it completely. I'm pretty sure this can/should be
> > implemented in the eclass without touching ebuilds.
> In my mind that was to leave ebuilds developers the ability to opt
> out,
> but well that could also be done in the eclasses.
> Opt out could be beneficial for packages that only support python 2.7,
> or where there are known and documented problems with different python
> versions.
> >
> > I'm not sure I really like the idea of affecting the other metadata
> > variables. I can see your point about wanting to remove python
> > versions that would otherwise satisfy dependencies. If metadata is
> > modified this way, it would definitely be "unsupported".
> I've not tought about remove python versions, only add them
> (beneficial
> for users that like to use experimental python versions)
> However the supported python version are translated and build
> important
> cached variables IUSE, DEPEND, etc. so there is no way to cleanly
> modify
> those variable after the cache has been generated.
> The only viable option is to regenerate, update or delete it.
>
> >
> > As far as implementation, you would probably need to write the
> patches for this.
> If there is consensus that's not a problem, cannot guarantee to be
> fast
> however
> >
> > Also, I expect the QA team might have some objections, so you
> may want
> > to discuss it with them (especially mgorny) before spending too much
> > time on it.
> I'd like to hear mgorny opinions but that should be a more extended
> decision than only QA and the python eclasses developer(s).
> If nothing else because deciding that sometimes may be good to let the
> user break the cache is a global decision and documentation need to be
> added.
>
>
> I'm seeing less value in this being a 'cache-breaking' exercise and
> more value in it simply being a custom eclass.
>
> If you hoist the eclass into an overlay and modify it (e.g. to set the
> var and get the deps you want) the caching
> all works out fine.
>
> 1. The source of the data is the hoisted eclass.
> 2. The eclass mtime changed.
> 3. package managers can see that and update cache metadata for
> inheriting ebuilds.
> 4. Bonus, once the cache is generated we have a valid means to see if
> the cache remains valid.
> 5. Double bonus, any ebuilds not inheriting the eclass are unaffected.
>
> I'm not sure why this is so onerous.
>
> -A
That's a good idea, in the past I've failed to completely understand how
portage inherit eclasses in overlays, but if I can figure that out
probably this could be a solution.
Also depending from the magnitude of changes the four python eclasses
need and the correlated maintenance burden.

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

[Francesco Riosa]

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
>> 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 2.7 and 3.6 (latest) installed
>>   no python 3.5
>> - don't want to mess dependencies (the warnings in the eclass are scary)
> Because it is not meant to be used for that purpose, and it is not meant
> to be used by users at all! It's just a quick hack for developer who
> wants to UNLIKELY(check if package works with implementation X) before
> he starts the effort on modifying PYTHON_COMPAT in ebuilds.
supposed that, but at this point I fail to see the benefit versus the
added complexity in the eclasses, however that's not my business.
>
>> So, what can be done to let the user choose it's preferred python
>> version(s) without having to build it's own overlay?
>>
>> One solution is to change ebuilds in tree to include a user variable in
>> the PYTHON* arrays, example:
>>
>> -PYTHON_COMPAT=( python3_{4,5} )
>> +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )
>>
>> if someone want to bet that packages are ok with 3.6/latest (even before
>> a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
>> /etc/portage/make.conf and run egencache.
>>
>> Indeed biggest problem in changing $PYTHON* variables is that metadata
>> also change and cache is invalidated.
>>
>> However if the problem is known (*), and if the change to metadata is
>> stable per "system"/"gentoo repo clone", then the solution to the
>> problem is easy; just run $(egencache --update -j$(nproc) --repo gentoo)
>> after each sync.
> This won't work. You are wrongly presuming that egencache regenerates
> cache unconditionally. It does so only if either ebuild or eclass
> content changed. So it worked for you once because you modified ebuilds
> and/or eclasses. It won't work when you change PYTHON_COMPAT_ADD.
>
> I haven't checked the Portage details but it may see the metadata change
> when installing the package. Which means it would install package with
> unsatisfied dependencies (because it satisfied dependencies from cache),
> then store the final dependencies and TADAAM, you've got broken
> depgraph.
ouch, that basically kill the proposal, unless portage is modified to
check known cache modifying variables, which isn't something I'd like to
create.
>
>> The most important thing is that this solution is scriptable and need no
>> human intervention.
> So is gpy-upgrade-impl.
It seem to do the job, one piece missing is something that monitor
gentoo repository to see if it has better version (still w/o wanted
python), an inotify for ebuilds. Suggestions?
>
>> Notice also that it's easy to have an array with duplicate values
>> PYTHON_COMPAT=( python3_6 python3_6 ) but at a first glance
>> _python_set_impls() is resilient to this.
>>
>> (*) In a perfect world, where global variables that can change metadata
>> are known {egencache,emerge} can be made conscious and warn if the cache
>> is invalid, but that's out of scope at the moment.
> This isn't perfect world. This is the exact opposite of it, it would be
> a mess. Also, conscious tools would probably start plotting against you
> if you'd give them such horrible tasks.
>

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

[Francesco Riosa]

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
>> 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 2.7 and 3.6 (latest) installed
>>   no python 3.5
>> - don't want to mess dependencies (the warnings in the eclass are scary)
>>
>> So, what can be done to let the user choose it's preferred python
>> version(s) without having to build it's own overlay?
>>
>> One solution is to change ebuilds in tree to include a user variable in
>> the PYTHON* arrays, example:
>>
>> -PYTHON_COMPAT=( python3_{4,5} )
>> +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )
>>
>> if someone want to bet that packages are ok with 3.6/latest (even before
>> a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
>> /etc/portage/make.conf and run egencache.
> I like the idea to inject values into PYTHON_COMPAT instead of
> overriding it completely. I'm pretty sure this can/should be
> implemented in the eclass without touching ebuilds.
In my mind that was to leave ebuilds developers the ability to opt out,
but well that could also be done in the eclasses.
Opt out could be beneficial for packages that only support python 2.7,
or where there are known and documented problems with different python
versions.
>
> I'm not sure I really like the idea of affecting the other metadata
> variables. I can see your point about wanting to remove python
> versions that would otherwise satisfy dependencies. If metadata is
> modified this way, it would definitely be "unsupported".
I've not tought about remove python versions, only add them (beneficial
for users that like to use experimental python versions)
However the supported python version are translated and build important
cached variables IUSE, DEPEND, etc. so there is no way to cleanly modify
those variable after the cache has been generated.
The only viable option is to regenerate, update or delete it.

>
> As far as implementation, you would probably need to write the patches for 
> this.
If there is consensus that's not a problem, cannot guarantee to be fast
however
>
> Also, I expect the QA team might have some objections, so you may want
> to discuss it with them (especially mgorny) before spending too much
> time on it.
I'd like to hear mgorny opinions but that should be a more extended
decision than only QA and the python eclasses developer(s).
If nothing else because deciding that sometimes may be good to let the
user break the cache is a global decision and documentation need to be
added.

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

[Francesco Riosa]

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 2.7 and 3.6 (latest) installed
  no python 3.5
- don't want to mess dependencies (the warnings in the eclass are scary)

So, what can be done to let the user choose it's preferred python
version(s) without having to build it's own overlay?

One solution is to change ebuilds in tree to include a user variable in
the PYTHON* arrays, example:

-PYTHON_COMPAT=( python3_{4,5} )
+PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )

if someone want to bet that packages are ok with 3.6/latest (even before
a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
/etc/portage/make.conf and run egencache.

Indeed biggest problem in changing $PYTHON* variables is that metadata
also change and cache is invalidated.

However if the problem is known (*), and if the change to metadata is
stable per "system"/"gentoo repo clone", then the solution to the
problem is easy; just run $(egencache --update -j$(nproc) --repo gentoo)
after each sync.
The most important thing is that this solution is scriptable and need no
human intervention.

Notice also that it's easy to have an array with duplicate values
PYTHON_COMPAT=( python3_6 python3_6 ) but at a first glance
_python_set_impls() is resilient to this.

(*) In a perfect world, where global variables that can change metadata
are known {egencache,emerge} can be made conscious and warn if the cache
is invalid, but that's out of scope at the moment.

The procedure to find out which packages are enabled for python 3.5 but
not for python 3.6 is not totally straightforward but this should be the
list of ~amd64 packages interested:


app-admin/glance    [15.0.0]
app-admin/setools   [4.1.1]
app-arch/bloscpack  [0.11.0]
app-arch/patool [1.12]
app-arch/vimball    [0.5.1]
app-backup/attic    [0.16]
app-backup/untangle-https-backup    [0.0.7]
app-benchmarks/bootchart2   [0.14.7-r1]
app-emulation/libguestfs    [1.36.5]
app-emulation/sen   [0.5.1]
app-i18n/transifex-client   [0.12.4]
app-misc/asciinema  [1.4.0]
app-misc/gramps [4.2.5]
app-misc/icdiff [1.9.1]
app-misc/jira-cli   [2.1.5]
app-misc/lirc   [0.10.0_rc2]
app-misc/solaar [0.9.2-r3]
app-misc/terminal-colors    [2.2]
app-mobilephone/obexftp [0.24-r1]
app-office/libreoffice-bin  [5.4.2.2-r1]
app-pda/libimobiledevice    [1.2.0]
app-portage/elogviewer  [2.7]
app-portage/gentoolkit-dev  [0.3.1]
app-portage/gs-elpa [0.1.3-r1]
app-portage/g-sorcery   [0.2.1-r1]
app-portage/gs-pypi [0.2.1-r1]
app-portage/pqlop   [0.02-r1]
app-text/grip   [4.2.0]
app-text/gtranslator    [2.91.7-r1]
app-text/landslide  [1.1.3]
app-text/pelican    [3.7.1]
app-text/pytextile  [2.3.3]
app-text/sigil  [0.9.8]
app-text/wiki2beamer    [0.9.5-r1]
app-vim/jedi    [0.8_p20171015]
app-vim/pyclewn [2.1-r1]
dev-games/vamos [0.8.2]
dev-lang/hy [0.13.1]
dev-libs/gom    [0.3.2]
dev-libs/Ice    [3.6.3-r1]
dev-libs/libcec [4.0.2-r1]
dev-libs/libsolv    [0.6.22]
dev-libs/link-grammar   [5.3.11]
dev-perl/Inline-Python  [0.560.0]
dev-python/abstract_rendering   [0.5.1]
dev-python/algopy   [0.5.3]
dev-python/amqplib  [1.0.2-r1]
dev-python/ansi2html    [1.3.0]
dev-python/aodhclient   [0.8.0]
dev-python/argcomplete  [1.9.2]
dev-python/asdf [1.2.1]
dev-python/astlib   [0.8.0]
dev-python/astrodendro  [0.2.0]
dev-python/astroml  [0.3]
dev-python/astroml-addons   [0.2.2]
dev-python/astroscrappy [1.0.5]
dev-python/awscli   [1.14.16]
dev-python/backports-abc    [0.5]
dev-python/beaker   [1.8.1]
dev-python/behave   [1.2.5-r1]
dev-python/bibtexparser [0.6.2]
dev-python/breathe  [4.6.0]
dev-python/castellan    [0.12.2]
dev-python/ccdproc  [1.2.0]
dev-python/cgkit    [2.0.0-r1]
dev-python/cgroup-utils [0.6]
dev-python/chump    [1.5.2]
dev-python/cliff    [2.8.0]
dev-python/cliff-tablib [1.1]

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

[Francesco Riosa]

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
> News-Item-Format: 2.0
> Display-If-Installed: 
> Along with changes to use modern libraries, GnuCash 2.7+ has changed the
> schema [1] it uses for both databases and files. GnuCash will
> automatically modify the file or database in place upon open.
>
> Therefore, it is imperative that you back up any files or databases
> before using GnuCash 2.7 in case you run into an issue and want or need
> to revert back to 2.6.
>
> Instructions for backing up are as follows:
>
> For XML (plain files):
> $ cp /path/to/file.gnucash /path/to/file.gnucash.bak
>
> For MySQL:
> $ mysqldump gnucash_db | mysql gnucash_db_bak
>
> For PostgreSQL:
> $ createdb -U dbadmin -T gnucash_db -O gnucash_user gnucash_db_bak
>
> For SQLite:
> $ cp /path/to/gnucash/sqlite.file.gnucash /path/to/gnucash/sqlite.file.
> gnucash.bak
>
> [1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a
>

It could be wise to close GnuCash before backup, also the choice of
creating a copy of the database is a bit unusual, an offline backup may be
more appropriated, example for mysql:
mysqldump gnucash_db | xz > gnucash-2.6.sql.xz

It's ok to leave restore instruction out, since those are usually easy to
find and spending more time with it does not hurt

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

[Francesco Riosa]

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.a.
vivo)?
I'd like to be able to seldom post here.

 [...]

> [1] https://projects.gentoo.org/council/meeting-logs/20171210-summary.txt
> [2] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct
> [3] https://bugs.gentoo.org/644070  (alias g-dev-whitelist)
>
> --
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer
> (council, toolchain, perl, libreoffice, comrel)

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

[Francesco Riosa]

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 fine to do
>>> these days, despite the warning.
>> If you're using netifrc's systemd support, this would break your
>> networking ;-).
> I guess the winky face means you are not serious, but I'll respond anyway. :-)
>
> I suspect the number of people using systemd with netifrc is in the
> single digits. I would rather not clutter the news item to account for
> this scenario.
Just for the record,
 I'm using it if using systemd (desktop systems), it's the only network
manager that use iproute2 syntax, shortening it if context is available
(no need to specify interface if it's mentioned in variable name f.ex.).
Beside I don't like NetworkManager

worse than that I'm actually using the same gentoo image with openrc and
systemd in different scenarios.
Basically my build box is using openrc inside a lxc container (no use of
netifrc, since net is managed by lxc).
The clients of the build box instead boot with systemd _and_ netifrc.

Gentoo is used by people who like to change defaults and (ab)use the
(autodocumented) flexibility offered by portage and ebuilds. Don't be
light in assuming how strange people is using strange configuration, and
population of strange people, that could be surprising.

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

[Francesco Riosa]

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 bug count because it is
> kind of hard to test the latest chromium beta when X11 isn't working.
>
Don't wonder anymore, this already happened, however it has to be noted
that different part of the tree are different.
Most famous server packages (apache, nginx, postfix, mysql posgrees) are
in good shape, stable here is pretty usable and working well.

When the target is a desktop system however things change and you are
pushed to a partially ~arch system and soon thereafter to a full
unstable install.

This is only partially imputable to the (lack of) manpower, increased
number of installed packages, infinitely bigger use flag permutation and
functionality,  in short complexity make very difficult to have a stable
system that stay stable.

Stable has to be stable in different point in times, and it's not enough
to wait a month of user test, that's a good start, but it should be
constantly  monitored in a changing environment. This is very difficult
when thare are 2000pkgs installed instead of 500.

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

[Francesco Riosa]

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 could go a step further and not distribute even the
> ebuilds except on demand.  Just have an index of what packages exist
> and enough dependency info to avoid having to churn with ebuild
> fetches in order to resolve them.
interesting point of view but this would require major refactoring of
portage and providing a resilient and capable infrastructure to serve
the ebuilds on demand.
Removing just files/ dirs  would require no modification to portage and
a load on infra that is probably much lighter (dependant on
implementation chosen)

> You could view ebuilds as source code - certainly important, but not
> necessarily the best thing to just have sitting around on your hard
> drive when not needed.
Personally, most of the time I do see  them exactly this way, but not a
big fuss either
>
> Whether we remove all files/ or the entire package dir from the repo,
> I'd suggest that this become more standardized if we wanted to go down
> one of these roads.  Instead of sticking something in SRC_URI and so
> on, it might be best if files (or packages) be kept in a standard
> mirrored location, and the package manager would just automatically
> find/fetch them if they exist and extract them to a standard location.
> Then any package that uses files/ can do so in a more standardized
> way.
Provided exact source of upstream files is kept near the ebuild the idea
is tantalizing.
A per repository base SRC_URI and "automatic" downloads of packages files

>
> This also would fix some existing issues with non-upstream distfiles,
> where they get stored in various random locations and aren't
> necessarily available long-term.  This has been a topic that comes up
> from time to time, especially if somebody is trying to build from an
> old version of the repo.  Something like genkernel patches or whatever
> would just go in files/ since the size limit is now gone and they'd
> presumably be archived forever.
>
another good point, it would be probably a good time to split $DISTDIR
in per package directory, big number of inodes in that dir has also been
a source of problems in the past, especially for mirror owners.

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

[Francesco Riosa]

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 many files that they will never use -- either because they
> don't need the package in question, or because the file belongs
> to an old version.
>
> For example, 'du -h app-shells/bash/files' states 232K while only three
> of those files are used by the newest version, and everything else are
> patches for old versions. And in case of bash, we're keeping those
> versions pretty much 'forever'.
>
> The new policy mostly targets large patchsets and files relevant to old
> package versions. By removing them from the repository, we're hoping to
> reduce the growth of its size a bit and reduce the amount of data
> transferred via rsync.

Evaluating transfer size, since on-disk size is different and the latter
will vary

The numbers are interesting:
- Total size of the tree: 224509 KiB #1
- Total size of files in files/: 27809 KiB #2
- Cumulative files/ >= 32KiB : 3289 KiB #2

Some simple math later and we discover that removing _all_ files from
the offending packages would give only a 1,5% reduction in transfer size.
Removing _all_ files/ directory would spare 12,4% or 1/8

I don't have numbers for the past, but if I recall correctly currently
the situation is greener than 10 years ago.
This to point that _some_ policy is _beneficial_ to avoid an explosion
of the repo size.
However restricting it further IMO would give very little benefit and
(looking at the packages involved) make life harder for no good reason.

It would be interesting instead to evaluate ways to remove _all_ files/
dirs from the tree, keeping ebuilds separated from data.
a different tree for files/ can seen a cleaner approach, give all
ebuilds the same mechanism to personalize patches & co, remove limits in
size (well not all limits)
Obviously the cost of such an operation is order of magnitude higher
than putting some policies in place.

#1 obtained with: find * -type f -exec cat {} + | wc -c

#2 list obtained with:
cd $PORTDIR
for files in $(find * -type d -name files) ; do
    echo -n $(find ${files} -type f -exec cat {} + | wc -c)
    echo ",${files%/files}"
done

Best Regards,
Francesco

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

[Francesco Riosa]

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. New stabilization requests are usually
>> handled much faster by x86, sparc and hppa teams!
>>
>> If you have a stable AMD64 system and would like to help arch testing,
>> please do! I don't know what exact rules for that are but I think [1]
>> could be helpful. If someone knows better, then please share.
>>
> As far as I'm aware the standing policy already exists that
> maintainers can stabilize their own packages on amd64.

It would be interesting to discuss if proxy maintainers should be able
to stabilize too.


>
> That said, if somebody wants to organize an AT program for amd64 they
> should feel free to do so.  I could explain how things used to work at
> least if that is helpful.
>
> The old way it used to work is that ATs had to pass the ebuild quiz
> and they would get editbugs privs to tag bugs as tested.  I won't
> elaborate here unless there is interest...
>

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

[Francesco Riosa]

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 shell is
>  # /bin/false, default homedir is /dev/null, and there are no default groups.
>  enewuser() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
maybe ewarn() is more appropriate than einfo()?
Just in case it's executed outside the scope of prefix

[...]

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

[Francesco Riosa]

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}
>> + : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
>>
>> For those with cmake ebuilds you can test this out now via 
>>
>> CMAKE_MAKEFILE_GENERATOR="ninja"
>> inherit cmake-utils
> If testing this, please use : ${CMAKE_MAKEFILE_GENERATOR:=ninja} in
> ebuilds unless the emake generator is explicitly known not to work. This
> will preserve user choice if they want to avoid ninja for some reason.
>
In my user opinion this has no place in a ebuild unless upstream clearly
say to use (or evidently use) ninja as it main generator.
In cases where ninja is considered (by upstream) the best option,
Michael suggestion to make it overridable is a very wise one.
In that case, please also remember to depend on ninja

Since other emails (by Christoph and Brian) in this thread make evident
that it's not a drop in replacement,  fixing it in the eclass seem a bad
idea, but that probably should be reconsidered when ninja become more
capable.

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

[Francesco Riosa]

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 current algorithms, so either is a good candidate. The choice of
> > Keccak is purely arbitrary (because it's the winner?).
> >
>
> Actually, a small correction here: we support more implementations
> of SHA3 than BLAKE2, so the first one is less problematic for us.
>

Not researched in depth but:
B2sum provided by coreutils is quite satisfacting*, it's pretty fast, while
sha-3 is deemed to be slower than sha-2, maybe this could be weighted while
choosing the algorithm wanted.

Both seem to take advantage of modern multicore CPUs but sha-3 does 11.7
[cpb]#0 (see #1) while an email seen on the internet say blake2 can reach 1
[cpb] (see #2)

#0 cpb = cpu cycles per byte
#1 https://en.wikipedia.org/wiki/SHA-3#Speed
#2 http://www.metzdowd.com/pipermail/cryptography/2016-May/029297.html
* (in my limited experience)

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

[Francesco Riosa]

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 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 from a package
> > (rpm) that weight less than 3MB when the functionality we need is
> > already all upstreamed. But if there is someone willing to keep it up to
> > date, that's totally fine.
> >
> > Provided we^W you keep dev-util/debugedit indefinitely  it's possible to
> > provide more useful choices to the users with at least two courses of
> > action:
> >
> > 1) instruct ${package_manager} to search for `debugedit` first in
> > ${PATH} _and_ then in /usr/libexec/rpm/debugedit.
> > This way dev-util/debugedit take precedence, if it's not installed and
> > app-arch/rpm is, then the latter will be used.
> >
> > 2) optionally (via useflag) create a symlink in /usr/bin to the libexec
> > debugedit when installing rpm. Obviously the two package must block each
> > other.
> > the rpm package implementing this solution (revbumped to latest) is
> > available here:
> > https://github.com/vivo75/vivovl/blob/master/app-arch/
> rpm/rpm-4.14.0.ebuild
> >
> > thanks for reading and please share your thoughts
> >
> > -- Francesco (vivo) Riosa
> >
> Sounds to me like a potential case of a 'virtual/debugedit' package,
> depending on one of rpm or debugedit to be installed, perhaps?
>
> MJE
>

It would be, but debugedit has no dependency in tree, so it's all
manageable from the messages portage send to the user.

[gentoo-dev] FEATURES=splitdebug and debugedit

[Francesco Riosa]

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 from a package
(rpm) that weight less than 3MB when the functionality we need is
already all upstreamed. But if there is someone willing to keep it up to
date, that's totally fine.

Provided we^W you keep dev-util/debugedit indefinitely  it's possible to
provide more useful choices to the users with at least two courses of
action:

1) instruct ${package_manager} to search for `debugedit` first in
${PATH} _and_ then in /usr/libexec/rpm/debugedit.
This way dev-util/debugedit take precedence, if it's not installed and
app-arch/rpm is, then the latter will be used.

2) optionally (via useflag) create a symlink in /usr/bin to the libexec
debugedit when installing rpm. Obviously the two package must block each
other.
the rpm package implementing this solution (revbumped to latest) is
available here:
https://github.com/vivo75/vivovl/blob/master/app-arch/rpm/rpm-4.14.0.ebuild

thanks for reading and please share your thoughts

-- Francesco (vivo) Riosa



0xB39B85C4.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

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

[Francesco Riosa]

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 from a package
(rpm) that weight less than 3MB when the functionality we need is
already all upstreamed. But if there is someone willing to keep it up to
date, that's totally fine.

Provided we^W you keep dev-util/debugedit indefinitely  it's possible to
provide more useful choices to the users with at least two courses of
action:

1) instruct ${package_manager} to search for `debugedit` first in
${PATH} _and_ then in /usr/libexec/rpm/debugedit.
This way dev-util/debugedit take precedence, if it's not installed and
app-arch/rpm is, then the latter will be used.

2) optionally (via useflag) create a symlink in /usr/bin to the libexec
debugedit when installing rpm. Obviously the two package must block each
other.
the rpm package implementing this solution (revbumped to latest) is
available here:
https://github.com/vivo75/vivovl/blob/master/app-arch/rpm/rpm-4.14.0.ebuild

thanks for reading and please share your thoughts

-- Francesco (vivo) Riosa



0xB39B85C4.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

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

[Francesco Riosa]

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
> > > package in binary format which may not be legally allowed.
> >
> > The difference is that how the package manager/ebuild installs the
> > package may be better suited to the environment than what upstream
> > expects (such as upstreams that install through a .run file)
>
> I fail to see how basically skipping src_install and maybe some prepare
> stuff that makes it better suited to an environment.
> Can you explain that further?
>
> These packages are just exploded tarballs. I fail to see the benefit
> to repacking those into another tarball to be exploded. At best
> skipping src_install and/or prepare, seems to be the only difference.
>

one such benefit is that the binhost is known and managed by someone you
trust, SRC_URI point to the wider and dangerous internet.
So please leave this as a configurable choice.


>
> I see no difference in installing kernel sources via source ebuild or a
> binpkg, pre-built ebuild binary. Other than the time it takes to
> re-package the kernel sources into another tarball.
>
>
> --
> William L. Thomson Jr.
>

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

[Francesco Riosa]

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 (maybe in a few months) I'd even suggest
> masking all of gcc-4. After all, unmasking them if you really need them is
> rather easy.
>

well if the intent is cleaning adding a package mask is just more burden,
not less.
If they compile fine with the latest stable gcc better leave them unmasked,
right?



>
> About removing them (what William proposed), I'd keep what we have now. We
> had
> this discussion already in lots of detail in the past, and convincing
> points
> were made to keep one of each 4.x ...
>

do you have any pointers or keyword to search?
Because once upon a time there were incompatible changes frequently (2.95
=> 3.x with x < 4 was bloody) but nowadays everything "C" seem more stable.
And the switch to c++11 still ongoing started with 4.8 and far less
problematic.
Maybe different arches than amd64? Binary packages? Embedded platforms?


>
> --
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer (council, perl, libreoffice)

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

[Francesco Riosa]

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 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.

last time I've checked (year 2010?) gcc-2.95 was impossible to emerge 
with a newer version of gcc.

gcc-3.4.6 (I'm a bit surprised) _can_ be compiled by gcc-6.3
USE="-* nptl" emerge -1 -a --buildpkgonly =gcc-3.4.6-r2
but it was released March 06, 2006.

IMHO who need these old versions of gcc for good reasons is able to use 
$preferred_search_engine to find them, if toolchain overlay can be 
resumed to host those.
Of the fairly extensive (but far from complete) subset of gentoo tree 
installed on my machines only Nvidia/cuda stuff require gcc older than 5 
and nothing require something older than 4.9


my vote would be keep:
gcc-4.{8.5,9.4}
gcc-5.4
gcc-6.3

and call it northern emisphere spring cleaning (NESC)

regards,
Francesco

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

[Francesco Riosa]

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 hear.  Like I said, on a fresh install I'd go with the current
> > version (5.4).  But for now, I'll wait for other people to experience
> > problems.  If nothing major, I might switch at a convenient time.
> >
>
>
> You just have to be careful with
>
>  emerge -c
>
> This will remove the old "unused" gcc silently :-/
>

no fear about that issue a:
emerge --select --noreplace sys-devel/gcc:4.9.4
to keep your wanted version of gcc in the world file
(--select is usually already the default)


> Cheers,
> Jörg
>
>
>

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

[Francesco Riosa]

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 my
ebuild-batcher[1], though same functionality is easily replicated.



How do you plan to test a thousand packages against the new version of 
python, and then revision/stabilize all of the broken ones 
immediately? Or is the plan to just break everyone's systems, and ask 
them to report bugs for the things that stopped working?
python 3.5.0 was released on 2015-09-13 and is still marked unstable and 
until recently was unusable because there were too many missing packages 
marked ready for it, stabilization isn't that faster right now.
Most of the breakage would be caught when recompiling (bytecode) of a 
package stable or not and even when not caught it would trigger only 
eselecting an unstable dev-lang/python if testing all python packages is 
required to stabilize dev-lang/python (which is kinda the current 
situation).


Python is slotted, that would also help a lot at keeping the breakage 
unobtrusive *
* Provided portage is never broken by a dev-lang/python update, but 
that's easy to test.





I think what you will actually get as a result is that nobody will 
ever add a new version of python to the tree, because you've just made 
it a huge ordeal to do so.



I do respectfully disagree with this sentence.

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

[Francesco Riosa]

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 reversed. Rather than
adding all the versions that the ebuild supports. What if it only
included versions it did not support?

Rational
When new versions are added. Ebuilds must be updated to support the
new version. This can require editing a decent amount of ebuilds.
Many may work fine with the new version. Making this extra needless
work. From a user point of view, You cannot move to the newer
version without keeping older around till all are updated to the
newer version.

Now one could say its the same work to mark versions not supported.
But I think there is less of that. Also if something supports and
older version and not newer, it may stand out more failing.
Requiring someone to reduce to the older version, and maybe filing
bugs to get it updated to the newer version.

Python 2.7 stuff aside. I am not sure how many Python and Ruby
packages break with a newer release. In pythons case I think once
they support Python 3.x, there is little chance if it breaking with
further 3.x releases. Not sure about Ruby.

I could be very wrong and the present way of doing things being the
only way. However if this is feasible it may lead to less work. It
would allow all packages to move to a newer version. Also allowing
punting of older sooner. This leaves the versions solely up to the
eclasses. Then ebuilds simply mark the unsupported versions. Just
like we do now with adding versions it does support.

Which if something was say only Python 2.7. It would have a >= to
excluded any newer version of Python. That said, we could do the
same with the current way. Saying this supports Python/Ruby >=SLOT.

Either way I do not think the current way is the best way. You have
to add every version/slot to ebuilds that work fine with any
version. When new ones are added, the ebuild has to be touched
again. When it may work fine with a new version without requiring
the ebuild to be modified.

This came up with some stuff requiring ruby23 as I moved to 24.
Looking around some stuff has Python 3.5 some 3.6, but all 3.4. So
I will stick to 3.4 till everything is at 3.6. Otherwise no point
and still have other versions.

The approach mentioned above, if the packages do not have issue. I
could go ahead and switch to ruby24 and pyton 3.6 across the board.
Which I cannot do now till a bunch of ebulids have their targets
increased.
  

+1 to the python part, cannot speak about ruby.
or totally automate the addition of python versions to ebuilds at the
exact time of bumping dev-lang/python.




This could be partially automated using buildbot.  The easiest would be
for pkgs containing working test suites.  Those that pass could be
auto-enabled with that python with ~arch keywords.  I think if a stable
pkg is to be added the new python, it should be via a revision bump and
~arch'ing the keywords.  But we could enforce the bot to rev-bump all
ebuilds just as easily.

Pkgs without tests, those would be harder and
we could do some basic tests on those, like syntax, test imports, but
would require additional means of testing in order to qualify for an
auto-python addition.

It should also be possible for the bot to scrape setup.py for
comppatible python versions.  Many of the pkgs I have been working with
recently have them listed.  Also there is travis.yml files in many
upstream pkg repos which can also be scraped for tested pythons.

It could certainly reduce the manpower needed to keep things up to date.

All good ideas, if William proposal is rejected, I'd like to request a 
mandatory step like this when a new minor 3.x python version is added to 
the tree.

No idea if that's feasible for ruby too.

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

[Francesco Riosa]

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 only
included versions it did not support?


Even if this would work better, it would require retraining all 
developers, completely rewriting several eclasses, tons of 
documentation, and a few thousand ebuilds.
Let's assume the retraining will be 2 or 3 orders of magnitude easier 
than switching from cvs to git, than that's doable.
Eclasses, ebuilds and documentation will be the real burden, but at this 
point it's better to discuss if the feature is wanted or not, then later 
wait for the volunteer(s) to actually do the work.




No one's going to jump on that bandwagon without a proof-of-concept 
that works much better than what we have now.


yep, that could be done, but since it's not trivial maybe better decide 
if it will be wasted or possibly accepted.



by the way eclasses from gentoo repo with PYTHON string inside are the 
following:


$ grep -c PYTHON *.eclass | grep -v :0$
distutils-r1.eclass:28
enlightenment.eclass:6
gnome-python-common-r1.eclass:2
kernel-2.eclass:2
mate.eclass:1
mozcoreconf-v4.eclass:3
python-any-r1.eclass:75
python-r1.eclass:107
python-single-r1.eclass:112
python-utils-r1.eclass:203
ros-catkin.eclass:40
twisted-r1.eclass:2
waf-utils.eclass:7

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

[Francesco Riosa]

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 it only
included versions it did not support?

It would only work if upstream provide a strong assurance for forward
compatibility. Explicit testing and marking working seems the only
practical way to ensure stability.
Surely enough forward compatibility may be a problem and  python 
upstream does deprecate and remove features #1 and things that fiddle 
with python bytecode will easily break.
However we keep $KEYWORDS between version of the same package and that 
it's subject to the same exact kind of problems.


Honestly just trying out python 3.6 is a pain at the moment and the 
situation is the same at every python bump.


#1 https://docs.python.org/3/whatsnew/index.html

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

[Francesco Riosa]

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
When new versions are added. Ebuilds must be updated to support the new
version. This can require editing a decent amount of ebuilds. Many may
work fine with the new version. Making this extra needless work. From a
user point of view, You cannot move to the newer version without
keeping older around till all are updated to the newer version.

Now one could say its the same work to mark versions not supported. But
I think there is less of that. Also if something supports and older
version and not newer, it may stand out more failing. Requiring someone
to reduce to the older version, and maybe filing bugs to get it updated
to the newer version.

Python 2.7 stuff aside. I am not sure how many Python and Ruby packages
break with a newer release. In pythons case I think once they support
Python 3.x, there is little chance if it breaking with further 3.x
releases. Not sure about Ruby.

I could be very wrong and the present way of doing things being the
only way. However if this is feasible it may lead to less work. It
would allow all packages to move to a newer version. Also allowing
punting of older sooner. This leaves the versions solely up to the
eclasses. Then ebuilds simply mark the unsupported versions. Just like
we do now with adding versions it does support.

Which if something was say only Python 2.7. It would have a >= to
excluded any newer version of Python. That said, we could do the same
with the current way. Saying this supports Python/Ruby >=SLOT.

Either way I do not think the current way is the best way. You have to
add every version/slot to ebuilds that work fine with any version. When
new ones are added, the ebuild has to be touched again. When it may
work fine with a new version without requiring the ebuild to be
modified.

This came up with some stuff requiring ruby23 as I moved to 24. Looking
around some stuff has Python 3.5 some 3.6, but all 3.4. So I will stick
to 3.4 till everything is at 3.6. Otherwise no point and still have
other versions.

The approach mentioned above, if the packages do not have issue. I
could go ahead and switch to ruby24 and pyton 3.6 across the board.
Which I cannot do now till a bunch of ebulids have their targets
increased.


+1 to the python part, cannot speak about ruby.
or totally automate the addition of python versions to ebuilds at the 
exact time of bumping dev-lang/python.

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

[Francesco Riosa]

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 - pretty well in order to
> follow upstream and use it as a template when bumping the next version,
> so standards and assumptions of quality are actually higher there :)
>
> yes, or to look from a different angle, speaking for - packages _in_
tree:
It can be expected that it does not build because the ebuild has not caught
up with upstream, hopefully for the shortest time possible.
_but_ it should have the same level of (bash/EAPI/deps) code cleanliness of
any other ebuild.

BTW that help a lot we, users, that want to test that package in the limbo
time upstream has done some changes and the ebuild as not caught up.
Othrewise just avoid the - in tree, a lot of developer have said they
are evil in the past (right?)

cheers,
Francesco

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

[Francesco Riosa]

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 like
> >>> what I see.
> >>>
> >>> I have opened an issue on OpenRC's github wrt migrating OpenRC to
> >>> the meson build system [3].
> >>>
> >>> As I said on the bug, the downside is the addition of py3 and ninja
> >>> as build time dependencies, but I think the upside (a build system
> >>> where we don't have to worry about parallel make issues or
> >>> portability) outweighs that.
> >>>
> >>> What do folks think here?
> >>
> >> I would discourage it.  Making OpenRC build-depend on python
> >> introduces unnecessary complexity that will undermine the
> >> portability of OpenRC sooner or later.
> >>
> >> After all OpenRC is a small program easy to build with a hand-written
> >> Makefile.
> >>
> >> Parallel make issues?  No problem let's just solve it.
> >>
> >>
> >> Please, keep it simple.
> >
> >I'm adding my support to this sentiment
> >
> >
>
> +1
>
> --
> Lars Wendler
> Gentoo package maintainer
> GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39
>
> Attention! New gpg key! See
> https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html
>

Replay @ random using gmail webmail interface;

May be worth mentioning that also other distro like Alpine Linux uses
openrc, they can be interested

Re: [gentoo-dev] New Project: Gentoostats

[Francesco Riosa]

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:00 Gokturk Yuksek <gokt...@gentoo.org>:
>
>> Hi everyone,
>>
>> I'm happy to announce the launch of the Gentoostats project.
>>
>> Gentoostats is a client-server software that collects various statistics
>> from Gentoo machines. It's been written as part of the Google Summer of
>> Code 2011 but unfortunately wasn't deployed. The main intention of this
>> project is to take over the development of gentoostats, have it deployed
>> on Gentoo infra and maintain it.
>>
>> Despite the 5 years of inactivity, the software remains surprisingly
>> functional. The source code is located here[0]. The ebuilds are located
>> in my overlay[1] currently but I'm hoping to make a release and move the
>> package to the tree in the coming days.
>>
>> I invite anyone who is interested to add themselves to the project.
>>
>> Best Regards,
>>
>> --
>> gokturk
>>
>> [0] https://gitweb.gentoo.org/proj/gentoostats.git/
>> [1] https://github.com/gktrk/kpanicd-overlay
>>
>>
> I thought this was an English list .. with respect :] ...
>

oops, that's an answer for a total different email in a different timeline
in a far far away universe.

apologies

Re: [gentoo-dev] New Project: Gentoostats

[Francesco Riosa]

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 client-server software that collects various statistics
> from Gentoo machines. It's been written as part of the Google Summer of
> Code 2011 but unfortunately wasn't deployed. The main intention of this
> project is to take over the development of gentoostats, have it deployed
> on Gentoo infra and maintain it.
>
> Despite the 5 years of inactivity, the software remains surprisingly
> functional. The source code is located here[0]. The ebuilds are located
> in my overlay[1] currently but I'm hoping to make a release and move the
> package to the tree in the coming days.
>
> I invite anyone who is interested to add themselves to the project.
>
> Best Regards,
>
> --
> gokturk
>
> [0] https://gitweb.gentoo.org/proj/gentoostats.git/
> [1] https://github.com/gktrk/kpanicd-overlay
>
>

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

[Francesco Riosa]

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 wrote:
> > I somehow doubt that would give me the expected number only, and I
> lack
> > a BSD install handy to test it.
>  $(sysctl -n hw.ncpu)
> 
> >>> I don't know that the sysctl command works universally:
> >>>
> >>> # sysctl -n hw.ncpu
> >>> sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory
> >>>
> >> It's BSD-specific (Darwin may have it too, but I'm not in OS X at the
> >> moment, so I can't check), which pretty much describes this branch in
> >> the codepath as well.  Linux users will have the nproc command from
> >> coreutils.
> > Yes, Darwin has it too, but the tool lives in /usr/sbin instead:
> >
> > https://gitweb.gentoo.org/repo/proj/prefix.git/tree/
> scripts/bootstrap-prefix.sh#n1987
> >
> > Fabian
> >
> >
> Ah, yes, I missed the part about it being BSD-specific.
>
> This one-liner certainly isn't as graceful or elegant, but it works:
>
> # cat /proc/cpuinfo | grep 'processor' | wc -l
>

# grep -c processor /proc/cpuinfo

however Documentation/filesystems/proc.txt is very vague on it's content,
just stating it has info on the cpu, better leave this as a backup value
IMHO

Re: [gentoo-dev] Gentoo on Android stage3

[Francesco Riosa]

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-
> stage3-armv7a_hardfp-20161026.tar.xz
>
> snapshot from the latest main Gentoo repository, featuring gcc-5.4,
> glibc-2.23, and the latest prefix-standalone (aka. RAP) profiles[1].
>
> The tarball runs Gentoo natively[2] under /data/gentoo (:=EPREFIX[3,4])
> on a rooted[5] android device newer than 2011 or armv7a[6], alongside
> the Android stack.
>
> The installation guide is at
>
>   https://wiki.gentoo.org/wiki/Project:Android/tarball
>
> with a list of tested devices at
>
>   https://wiki.gentoo.org/wiki/Android/Devices
>
>
> Next we are going to build a normal-user version, and to manage Android
> kernels with portage[7].
>
> Time to unleash the mobile power with Gentoo.
>
> Enjoy,
> Benda
>
> 1. https://archives.gentoo.org/gentoo-dev-announce/message/
> 772326d735c8c7c469beffc0a9bb0b97
> 2. No chroot or PRoot
> 3. https://wiki.gentoo.org/wiki/Project:Prefix/Technical_
> Documentation#EPREFIX_variable
> 4. https://projects.gentoo.org/pms/6/pms.html#x1-12100011.1.3
> 5. https://en.wikipedia.org/wiki/Rooting_%28Android_OS%29
> 6. https://en.wikipedia.org/wiki/Comparison_of_ARMv7-A_cores
> 7. https://wiki.gentoo.org/wiki/Project:Android
> 8. Previous announcement:
>https://archives.gentoo.org/gentoo-dev-announce/message/
> 890e3e40977a37bb499fb02d35efe74a
>
>

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

[Francesco Riosa]

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 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 LABEL= thereafter,
> why should
> > > it be "deprecated"?
> >
> > I don't think anyone said that the LABEL= syntax is bad; quite the
> > opposite -- WilliamH wants everyone using /dev/disk/by-label/
> > paths in fstab to instead use LABEL= , to avoid issues if udev
> > doesn't create the symlinks before localmount tries to use them.
> >
> >
> > Indeed nobody ever said "deprecated" some people (/me too) don't like
> > to use labels and prefer UUIDs instead.
> > - in some situations -
> > To complete the statement labels are very good with fleets of servers
> > with predefined and consistent disk layouts, or for some people desktop.
> > When it come to a small number of server with different layouts they
> > are equivalent in functionality but need managing and memory, when you
> > substitute disk for example, simply not worth it.
> >
> > Best,
> > Francesco
>
>
> UUID is the same situation in this case -- in fstab you can do it by
> UUID= or you can do it by /dev/disk/by-uuid/.  The latter
> form depends on udev finishing up and would have the same issue.
>
> The identifier itself that you use for the partition doesn't need to
> change at all, its just the means with which you use this identifier
> that WilliamH is recommending you change.
>
>
> I did already understood the difference, but thanks for clarifying

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

[Francesco Riosa]

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 LABEL= thereafter, why
> should
> > it be "deprecated"?
>
> I don't think anyone said that the LABEL= syntax is bad; quite the
> opposite -- WilliamH wants everyone using /dev/disk/by-label/
> paths in fstab to instead use LABEL= , to avoid issues if udev
> doesn't create the symlinks before localmount tries to use them.
>
>
> Indeed nobody ever said "deprecated" some people (/me too) don't like to
use labels and prefer UUIDs instead.
- in some situations -
To complete the statement labels are very good with fleets of servers with
predefined and consistent disk layouts, or for some people desktop.
When it come to a small number of server with different layouts they are
equivalent in functionality but need managing and memory, when you
substitute disk for example, simply not worth it.

Best,
Francesco

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

[Francesco Riosa]

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 PM, William Hubbs 
> >wrote:
>  If you are not using /dev/disk/by-* paths in fstab, you do not need
> >to
> >>> take any action for this news item.
> 
>  If you are, it is very critical that you update fstab AS SOON AS
> >>> POSSIBLE. Your system will become unbootable in the future if you do
> >>> not  do so.
> >>>
> >>> Err, what is changing that will make systems unbootable?
> >>>
> >>> I am fairly certain systems running systemd will continue to work
> >>> properly with either syntax.
> >>
> >>  They probably will.
> >>
> >>> If this is about the udev-settle issue for OpenRC, I would urge you
> >to
> >>> reconsider that.
> >>
> >>  There isn't anything to reconsider afaik. The problem is that
> >>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
> >>  works regardless of which device manager  you use, so this is the
> >safer
> >>  route.
> >>
> >>  William
> >>
> >
> >I take it us museum relics still using jurassic-era device names like
> >/dev/sd* or /dev/md* aren't affected by this?  Cthulhu-forbid Linux
> >device
> >naming gets any more complicated than using UUID's.  What's next,
> >saving the
> >serial numbers of discovered disks in an overly-complicated
> >key/value-based
> >non-SQL database format?
>
> Wait full you-know-who notices that disk device names are not predictable
> and fixes that.
>

that's easy just make fstab parser able to read the content of
HWPATH=/sys/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1/dev
;-)


>
>
> --
> Best regards,
> Michał Górny (by phone)
>
>

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

[Francesco Riosa]

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 any action for this news item.
> > >
> > > If you are, it is very critical that you update fstab AS SOON AS
> > POSSIBLE. Your system will become unbootable in the future if you do
> > not  do so.
> >
> > Err, what is changing that will make systems unbootable?
> >
> > I am fairly certain systems running systemd will continue to work
> > properly with either syntax.
>
>  They probably will.
>
> > If this is about the udev-settle issue for OpenRC, I would urge you to
> > reconsider that.
>
>  There isn't anything to reconsider afaik. The problem is that
>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
>  works regardless of which device manager  you use, so this is the safer
>  route.
>

please make also clear that UUID=... syntax will still work, one for all I
don't like labels and will gladly continu to use this format:
UUID=debd07a3-fbbc-4433-89db-29e6f91d25e4 /boot ext2 noauto,noatime  1 2



>
>  William
>
>

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

[Francesco Riosa]

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:
--autounmask [ y | n | only | write | continue]

especially if these options make no sense used together


2016-07-01 12:29 GMT+02:00 Alexander Berntsen :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> The patch itself looks OK, but I think that this option is a bad idea
> and design, and that the extra complexity isn't warranted. I know
> users have asked for something similar several times, but thankfully
> the users aren't the developers.
>
> But if you genuinely think this is a good idea, and someone else on
> the team does too, I won't oppose it. We should make sure that we
> strongly discourage its usage for regular users. Perhaps your
> suggested manpage addition already does -- I don't know.
> - --
> Alexander
> berna...@gentoo.org
> https://secure.plaimi.net/~alexander
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJXdkX1AAoJENQqWdRUGk8BYbUQAM6EcIv7/2PpOM/ETY6zlZM3
> hHH6X4ZofiMJCaXN+xoppFhJ6+d9851VlMS98r7lTPe4BiMlcjXELkb9ukgHJG2S
> PJtRRo79MlTIH3WB3q7Se+ZIkvtTjikVLKRQgxir5i6UxXgOZgp0ucYguvtnU2U5
> 79bAxXaUwbqt7o51FfR42J+xWjlfKl36cKsbkMCthNzTyGD/eX8L6wHjkphPhZ9I
> hxMdmRKs9eKV6EOIDc5ZP55B3+NBeLo5VXZSylZurrwlkGyFhFFUUnIXRkX/Xod5
> 3Tgk980KrqDwuhZ1tT7Jug8x+uOHYrugZzL9AW/T91ACp9kut2gXYhXATufHXHT4
> 6vCm9BCNwqMQh3GkQCVQEhY1P3okFdR1SXZuzjiSpfbzkZjyIJ1o/Vj/X5/gq+SC
> CWQBgIyoW9hVvIQqHbfnoEewfXhwFpvknl7R8DeWiCZbX462Gjn5dQ4KKZHlQrLk
> nDtvHKmX6aXC7ElQsRMagZ5HevfcU2h4uYbYorkaipNskMFMeGBT5j85jK3Nu9C9
> 0XX6GD+djYDd0L4hk0h6Kb30PZu5p5Y9HIQdia0tspwUDsbSsOdJe/vNYQMNy50z
> Oke0arfNJEY5KfILV5QS1ShkX/2Ot+tZtDsPsEZKMidK5hYZcyeAHQ0MmVLLikkj
> CtWAcVXmHmOz3HH6tVTY
> =buhT
> -END PGP SIGNATURE-
>
>

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

[Francesco Riosa]

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 answer:
I do use my kde sessions with en_US language, my daughter prefer to use
it_IT, same PC.

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

[Francesco Riosa]

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.
>
> So, now servers and other systems that do not require repo Q/A ability
> will no longer get repoman installed anyway.
>
> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now
> modular, and using the portage plugin system. The system is not yet
> fully plug and play. Those changes will take place in the stage3
> re-writes.
>
> The two packages will remain in the same portage git repo, although the
> repoman code has been moved into it's own pkg directory.  It is too
> tied into portage api's to be on it's own just yet.  An that
> is not likely to happen until we get a stable portage API.  This new
> system does allow for semi-independant releases for both repoman and
> portage.  When important API's change, it will require both to be
> release at the same time.  So you can look forward to seeing the minor
> version number to get more frequent bumps than it has this last decade.
>
> Currently, the portage ebuild does not RDEPEND on the repoman ebuild.
> You will have to explicitly emerge it for it to be installed. It has
> been suggested to add a use flag enabled RDEPEND (default on) for the
> dev profile.  I will also be adding that to the portage- release
> for all profiles in the coming days.
>
> NOTES:  Repoman now depends on lxml for it's xml parsing and error
> checking along with now using metadata.xsd.  It now will report a lot
> more errors than the previous buggy code everyone has been using.
>
> I want to thank the following people for their help and contributions
> to make these releases:
>
> Zac Medico 
> Alexander Bernsten 
> Dirkjan Ochtman  for the base xml re-write code
> Michal Gorny  for the metadata.xsd changes
> Göktürk Yüksek  for the metadata.xml test ebuilds
> patches.
> Mike Gilbert  for all the testing on the rewite code,
> and a number of gen-b0rk repo test ebuilds.
>
> Coacher for the recent testing, bug reports and patches.
> And anyone else I missed ;)
>
> So, please report any issues with either the ebuilds or installs, bugs,
> etc... you know the drill ;)
>
> Don't forget, please contribute more test case ebuilds to the gen-b0rk
> repo.  The better the test ebuild coverage we have, the better our Q/A
> tools (like repoman) will be and the less often things will be released
> broken.
>
> Thank you
> --
> Brian Dolbec 
>
>
> Thank you Brian and all the persons involved

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

[Francesco Riosa]

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 change
> > > > the virtual back. One-line change.
> > >
> > > Which is precisely the corresponding argument for not switching the
> > > default to eudev in the first place.
> >
> > OH, my, this is looking more like you are being paid by systemd peeps...
>
> honestly ?  cut the crap man.
>
> > You are just refusing to acknowledge these simple facts.
> >
> > systemd.:  irrelevant to this decision
> >
> > standalone systemd-udev.:  Vehemently unsupported, support for its
> >capability to exist is planned to be punted
> >in the future.
> >
> > eudev...:  fully functional, actively developed,
> >and fully supported, mature project, been
> >around for years.
>
> udev: it's the default in every major distro that everyone tests and
> develops against.
>

This is NOT true, major distro use systemd, NOT udev as we use it.


>
> eudev: no one of any relevance outside of Gentoo runs it.
>

Neither this is totally true, or put another way, everybody which is NOT
using systemd is using eudev (or some form of static /dev).
So obviously this is totally relevant for people that don't use systemd.

Also, why, why people using systemd ARE interested in this thread?
You should not be interested at all.


>
> > Oh and here is one final piece that should blow your reason away
> >
> > https://github.com/gentoo/eudev   <== NOTICE that it's upstream is
> > within our gentoo domain.
>
> irrelevant.  any Gentoo dev can create any repo in that namespace even
> when they shouldn't.  the fact that eudev is in there does *not* mean
> the whole Gentoo project has signed on to it, or that it's some sort
> of "banner" project.  it means at least one Gentoo dev decided to do X
> and our project system doesn't require project consensus before X can
> proceed.  do not conflate these.
> -mike
>

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

[Francesco Riosa]

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
> across device nodes, mountpoints, services, and cron jobs.  In the
> alternate model you have completely different implementations of all
> of those, each with their own configurations and behaviors.
>
> >
> > And that's much of the beauty of OpenRC. Its simple, it achieves the
> > same goals as Systemd and Upstart, etc, but does so with a lot less
> > mechanics under the hood, and doesn't clutter up systems with features
> > you don't need prematurely.
>
> OpenRC doesn't achieve MANY of the goals of systemd.  Maybe you don't
> personally care about some of them, but you really can't compare the
> feature sets at this point.
>
> > And there are great benefits from simplicity over complexity.
>
> Absolutely.  It is great to create a text file and symlink it in a
> directory named after a service to make that service auto-restart, or
> have a memory limit, or set an IO priority for that service.  It is
> great to not have to think about anything to have just about all your
> processes organized into a sensible cgroup hierarchy.  It is great to
> be able to tweak one config file to ensure that users who log out of a
> system can't leave any processes behind.
>
> It is great to be able to tweak something in policykit and change
> things like who can shut down the system, or who can restart a
> service.
>
> The simplicity of systemd comes from the fact that it has brought what
> used to be a collection of many independent tools under one roof, and
> created a converging set of interfaces for all of them.
>
> > And a lot of Gentoo is surprisingly simple: Like our use of bash
> > scripts for recipies to build things, like using rsync to deploy/relay
> > not just those recipies, but security notices and  news items, which
> > are themselves reasonably simple formats.
>
> Well, one thing about Gentoo that certainly isn't simple is our init.d
> scripts.
>
> Compare this:
> http://pastebin.com/sSDtpF4t
>
> With this:
> http://pastebin.com/Lfn8r7qP
>
> Systemd does the job in 10% of the code (and half of it is a comment),
>

Actually that's incorrect, it does not implement "configdump" and
"fullstatus" is it possible for systemd to implement those?
Anyway we are hijaking another discussion to OpenRC versus Systemd or it's
only my impression?


> and doesn't implement its own service polling and killer script during
> shutdown independently for every service (not that every init.d script
> even does this - most of them will just leave orphans behind, and
> systemd will catch orphans that even the lengthy init.d script for
> apache misses).
>
> >
> > The only preference I see here is the preference to not have and
> > install things your system has no use for, which I find an odd
> > preference to be complaining about, and depending on your system
> > requirements, that may also be not so much "preference".
> >
>
> And hence my suggestion that we simply get this stuff out of the
> stage3s in the first place.  Then everybody can just pick the
> implementation that best suits their requirements.
>
> If you want to talk about default providers, the most straightforward
> one to use is systemd.  It is what people are going to be used to
> coming from other distros, it is what every upstream package expects
> to be running anyway, and it is the simpler tool that does everything
> that most people want.
>
> For people who want a more exotic configuration, there are
> alternatives, and Gentoo should certainly support using them as long
> as people care to maintain them.
>
> --
> Rich
>
>

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

[Francesco Riosa]

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 :

> Hi Helmut,
>
> Helmut Jarausch wrote:
> >   escons prefix="${D}/usr" install
> ..
> > prefix=/var/tmp/portage/media-libs/libmypaint-/image//usr
> ..
> > How can I fix this?
>
> Set prefix to /usr and use another method to install into ${D}.
>
>
> //Peter
>
>

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

[Francesco Riosa]

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 important for anyone who does

photo on

linux.

So why don't you take them?


any mentor?

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

[Francesco Riosa]

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-gmic


nobody for these? they are rather important for anyone who does
photo on linux.



What does gimp-gmic do? I maintain a set of brushes and presets for
GIMP for pixel art; is it related to that at all?

quoting: A plug-in 'gmic_gimp', to bring G'MIC capabilities to the GIMP 
image retouching software.


gmic is not gimp dependant more a library/executable with an extended 
set of operations.

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

[Francesco Riosa]

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

[Francesco Riosa]

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 start point to clone and improve
upon. Before it was CVS.

Actually an `emerge -uDN @world` fail constantly, because of broken deps
and other stuff (given a desktop profile with a good number of packages)
this fact render gentoo very unpleasant to keep up to date, it has never
been a breeze but it was better.

combining these two things  I really could not care less, and nobody
should care less for the usage of proprietary tools to improve things,
knowing that thing can fail and could need a replacement.
In the meantime Gentoo can improve itself in other areas, manpower don't
seem too high at the moment.

also you can strive for HURD and not linux, but don't impose it on us
(at least not for now)

- Francesco R.

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

[Francesco Riosa]

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 requiring static libs in
  cryptsetup and lvm2?

 This isn't the specific answer you're likely looking for, but the
 obvious answers would be:
 1.  Booting without /usr mounted if any of cryptsetup/lvm2's libs are
 located in /usr (not the case for lvm2 on my system at least).
 2.  Any initramfs creation tool that isn't smart enough to realize
 what cryptsetup/lvm2 are linked to and copy those into the initramfs
 (shouldn't be an issue in anything modern).

 Rich

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

[Francesco Riosa]

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 ~ from:
CONFIG_CHECK=~DEVTMPFS
  
   to ensure people really changes it in their kernel and prevent
 breakage?
  
 
  That won't work because the host you run the package isn't necessarily
  same as the one you are building it on
  The build host doesn't need DEVTMPFS
 
 

 And couldn't that be done at install time? I mean, you can build and
 package new udev but installation will die if udev is going to be
 installed on a system without DEVTMPFS


Pacho, see the message from robbat2 titled RFC: CONFIG_CHECK_FATAL, making
CONFIG_CHECKS fatal by default

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

[Francesco Riosa]

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 delay of some seconds, exactly like `emerge -C portage` or
something very similar?
Trying to cover the corner cases but without pretend to be omniscent?

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

[Francesco Riosa]

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

[Francesco Riosa]

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 the number of packages to grow much
  more. We, the Gentoo Qt team, are of the opinion that the time has
  come to split all these out into their own category. This category is
  to be used for the various modules and applications that belong to the
  upstream Qt Framework only (these include e.g. assistant and
  linguist). Third-party applications should remain in the current
  categories.
 
  After some initial bikeshedding we came to the conclusion that naming
  the category simply qt is the most elegant solution. We will then
  also be dropping the qt- prefix in package names. This means
  x11-libs/qt-core will be moved to qt/core, and so on.
 
  Please let us know your thought on this.

 Just a completely different idea -- how about putting those libraries
 into different categories appropriate to the topic? We have a bunch of
 categories like dev-libs, media-libs, etc. -- and I wonder how many of
 the Qt libs would fit into each of them.

 This would be the right thing to do, or the correct way.
Most would really hate it (me too)

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

[Francesco Riosa]

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 SIGNED MESSAGE- Hash: SHA256
  
   On 18/01/13 07:24 AM, viv...@gmail.com wrote:
   Since for servers predictable names are useful and for desktop
   (which usually have only one ethernet that never change) Is it
   possible to set desktop profiles to still use ethX, and base
   profile to use new naming scheme?
  
   For wireless situation may be different, many of them are
   external, could wireless be managed differently?
  
  
   In short, no.  At least, not unless the functionality that is
   currently a configure-time thing is changed into a
   build-time/install-time thing controlled via a use flag.
  
   Actually,this is how I set you up by dropping the file in
   /etc/udev/rules.d/80-net-name-slot.rules.
  
   Nothing changes on your system unless you remove this file and do
   not have 70-persistent-net.rules.
  
   William
  
 
  ..right, but default behaviour can't be changed automatically
  depending on what profile you're on, as vivo requested, since profiles
  don't control configuration (just use flags)

 Right, and we have a policy against using use flags to control the
 installation of configuration files.

 vivo, what is your concern here exactly?

 William

 My concern was to make simple desktop users happy while leaving the
servers safe.
The answers given in the previous emails are satisfying, since they cover
exhaustively what is in place and what could be (or not) done.

Thanks,
Francesco

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

[Francesco Riosa]

+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 bug https://bugs.gentoo.org/show_bug.cgi?id=384193 and
 https://bugs.gentoo.org/show_bug.cgi?id=379497

 I opened a tracker https://bugs.gentoo.org/show_bug.cgi?id=429308

 Some devs seem unsure about that or want to have a council vote on that
 https://bugs.gentoo.org/show_bug.cgi?id=429332


 When I sum that up again...
 - we are on gentoo and need as much information as possible for
 backtracing, resolving bugs, checking whether CFLAGS and such have been
 respected
 - no need to tell the user to recompile with
 EXTRA_ECONF=--disable-silent-rules or similar just to be able to help
him
 - some QA checks might depend on verbose build log and are not yet
 implemented therefor
 - if people want nice build _output_ (not log), they can use --quiet-build

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

[Francesco Riosa]

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
buildtools/wafsamba/samba_conftests.py
def CHECK_LIBRARY_SUPPORT(conf, rpath=False, version_script=False, msg=None):
bld.compile()
except with a file not found


Portage 2.2.0_alpha111 (default/linux/amd64/10.0, gcc-4.6.3,
glibc-2.15-r2, 3.4.1-vs2.3.3.4 x86_64)
=
System uname: 
Linux-3.4.1-vs2.3.3.4-x86_64-Intel-R-_Core-TM-_i7-2600_CPU_@_3.40GHz-with-gentoo-2.1
Timestamp of tree: Sun, 24 Jun 2012 19:30:01 +
distcc 3.1 x86_64-pc-linux-gnu [enabled]
ccache version 3.1.7 [disabled]
app-shells/bash:  4.2_p20
dev-java/java-config: 2.1.11-r3
dev-lang/python:  2.7.3-r2
dev-util/ccache:  3.1.7
dev-util/cmake:   2.8.7-r5
dev-util/pkgconfig:   0.26
sys-apps/baselayout:  2.1-r1
sys-apps/openrc:  0.10.3
sys-apps/sandbox: 2.5
sys-devel/autoconf:   2.13, 2.68
sys-devel/automake:   1.10.3, 1.11.1
sys-devel/binutils:   2.22-r1
sys-devel/gcc:4.5.3-r2, 4.6.3, 4.7.1
sys-devel/gcc-config: 1.7.3
sys-devel/libtool:2.4-r1
sys-devel/make:   3.82-r1
sys-kernel/linux-headers: 3.4 (virtual/os-headers)
sys-libs/glibc:   2.15-r2
Repositories: gentoo vivovl mysql
ACCEPT_KEYWORDS=amd64
ACCEPT_LICENSE=*
CBUILD=x86_64-pc-linux-gnu
CFLAGS=-O2 -march=corei7-avx -pipe -frecord-gcc-switches -mno-movbe
-mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm
--param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=8192 -mtune=corei7-avx -fgcse-after-reload
-fpredictive-commoning -ftree-vectorize -funswitch-loops
-fgraphite-identity -floop-block -floop-interchange -floop-strip-mine
-ggdb -gdwarf-4 -fvar-tracking-assignments
CHOST=x86_64-pc-linux-gnu
CONFIG_PROTECT=/etc /usr/share/config /usr/share/gnupg/qualified.txt
/usr/share/openvpn/easy-rsa /usr/share/themes/oxygen-gtk/gtk-2.0
CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d
/etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release
/etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/
/etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d
/etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d
/etc/texmf/updmap.d /etc/texmf/web2c
CXXFLAGS=-O2 -march=corei7-avx -pipe -frecord-gcc-switches -mno-movbe
-mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm
--param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=8192 -mtune=corei7-avx -fgcse-after-reload
-fpredictive-commoning -ftree-vectorize -funswitch-loops
-fgraphite-identity -floop-block -floop-interchange -floop-strip-mine
-ggdb -gdwarf-4 -fvar-tracking-assignments
-fvisibility-inlines-hidden
DISTDIR=/g/distfiles
EMERGE_DEFAULT_OPTS=--ask-enter-invalid --quiet-build=y
FCFLAGS=-O2 -pipe
FEATURES=assume-digests binpkg-logs buildpkg compress-build-logs
compressdebug config-protect-if-modified distcc distlocks ebuild-locks
fail-clean fixlafiles installsources metadata-transfer news noinfo
notitles parallel-fetch parallel-install parse-eapi-ebuild-head
sandbox sfperms splitdebug strict test-fail-continue
unknown-features-warn unmerge-logs unmerge-orphans xattr
FFLAGS=-O2 -pipe
GENTOO_MIRRORS=http://mirror.netcologne.de/gentoo/
http://mirror.ovh.net/gentoo-distfiles/
http://mirror.switch.ch/ftp/mirror/gentoo/ http://gentoo.lagis.at/
http://mirror.qubenet.net/mirror/gentoo/;
INSTALL_MASK=/usr/lib64/libogrove.la /usr/lib64/libospgrove.la
/usr/lib64/libostyle.la
/usr/lib64/vlc/plugins/codec/libdirac_plugin.la
/usr/lib64/vlc/plugins/demux/libdirac_plugin.la /bin/systemd
/bin/systemctl /usr/lib64/elektra/libelektra-filesys.la
/usr/lib64/elektra/libelektra-hosts.la
/usr/lib64/elektra/libelektra-ini.la
/usr/lib64/elektra/libelektra-passwd.la /usr/lib64/libelektra-cpp.la
/usr/lib64/libelektra.la /usr/lib64/libelektratools.la 
LDFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed -Wl,--sort-common -Wl,--no-copy-dt-needed-entries
-Wl,--build-id 
LINGUAS=it
MAKEOPTS=-j36
PKGDIR=/g/packages
PORTAGE_COMPRESS=lzma
PORTAGE_CONFIGROOT=/
PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times
--compress --force --whole-file --delete --stats --human-readable
--timeout=180 --exclude=/distfiles --exclude=/local
--exclude=/packages
PORTAGE_TMPDIR=/var/tmp
PORTDIR=/g/portage
PORTDIR_OVERLAY=/g/ovl/tmp /g/ovl/mysql
SYNC=rsync://rsync.gentoo.org/gentoo-portage
USE=acl amd64 avx berkdb bzip2 caps cli cracklib crypt cups cxx dbus
dri fortran gdbm gpm iconv ipv6 modules mudflap multilib ncurses nls
nptl opencl opengl openmp pam pcre pppd qt3support readline
semantic-desktop session sse sse2 sse3 sse4_1 ssl ssse3 static-libs
svg tcpd unicode xattr xorg zlib ALSA_CARDS=ali5451 

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

[Francesco Riosa]

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 broken out
 of nowhere. I don't believe this issue was that urgent in order to
 justify the significant breakage of portage tree.

 you're assuming the breakage was intentional.  i also wouldn't really describe
 it as significant, but that's just quibbling over an insignificant aspect.

It's intentional not to revert the change, it's significant because it
involve a number of significant packages like icu, vim and boost, some
of them already marked stable (from a fast grep from the one mentioned
in the previous posts).

 but what's done is done.  fix the ebuilds and move on.
 -mike

revert - fix the ebuilds - re-apply could work too, or since you're an
old and respected developer fix them yourself, the change is easy and
probably mantainers will understand.

Francesco R.

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

[Francesco Riosa]

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 to inherit eutils and then
  remove eutils from autotools. Now, a bunch of ebuilds are broken out
  of nowhere. I don't believe this issue was that urgent in order to
  justify the significant breakage of portage tree.
 
  you're assuming the breakage was intentional.  i also wouldn't really
  describe it as significant, but that's just quibbling over an
  insignificant aspect.

 It's intentional not to revert the change, it's significant because it
 involve a number of significant packages like icu, vim and boost, some
 of them already marked stable (from a fast grep from the one mentioned
 in the previous posts).

 you've identified the broke things.  so fix them.
 -mike

wanna give me commit access for few hours?
I've already done mass changes to the tree when introducing
virtual/mysql seem something doable the same way.

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

[Francesco Riosa]

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 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 broken out
   of nowhere. I don't believe this issue was that urgent in order to
   justify the significant breakage of portage tree.
  
   you're assuming the breakage was intentional.  i also wouldn't really
   describe it as significant, but that's just quibbling over an
   insignificant aspect.
 
  It's intentional not to revert the change, it's significant because it
  involve a number of significant packages like icu, vim and boost, some
  of them already marked stable (from a fast grep from the one mentioned
  in the previous posts).
 
  you've identified the broke things.  so fix them.

 wanna give me commit access for few hours?

 just join as a dev and get it over with ;P

maybe gentoo will live better w/o my fat typeing hands :-P

 I've already done mass changes to the tree when introducing
 virtual/mysql seem something doable the same way.

 seems people have already fixed most (if not all) errors related to
 autotools.eclass

Seem to be the better outcome.  If someone could fix the remaining
unfixed after x days that would be perfect, it's always unpleasant to
touch other devs ebuilds but sometimes is just the only thing to do
(replace with some philosophy mumble at pleasure;-)

good night and thanks for answering

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

[Francesco Riosa]

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 much just coming out of the blue.

 We should make emerge -v (display USE flags) non-optional.
 Users should be trained to recognize the green/red use flag changes.

currently portage _does_ show use changed w/o -v, and show _all_ use
w/ -v, please leave it as is -v is way too verbose to see the changes
in a multi-package merge

 Do whatever you what, I've set make.conf:USE=ldap on machines relying
 on it.
 Michael

Mee too, that sum to zero machines tough

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

[Francesco Riosa]

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 wrote:
   * Get a versionator replacement into the PM
 
  Why are we trying to make PM a brick instead of keeping stuff modular?
  What does the eclass lack which could be provided by PM?

 Because trying to parse version formats correctly in bash is a huge
 pain, and versionator doesn't get it right (never mind that the rules
 were different when versionator was written).

 --
 Ciaran McCreesh
What's changed from 2006 in version handling?

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

[Francesco Riosa]

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 stage. You mean pkg_pretend, I suppose?

  Therefore I ask, what is the proper behaviour here ? Is there
  documentation on what special env variables are supposed to be
  defined in each stage ?

 It's specified here:
 http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-11900012.1

 | Variable   Legal in   Consistent?    Description
 | -
 | T          All        Partially⁴     The full path to a temporary
 |                                      directory for use by the ebuild.
 |
 | ⁴Consistent and preserved across a single connected sequence of
 | install or uninstall phases, but not between install and uninstall.
 | When reinstalling a package, this variable must have different
 | values for the install and the replacement.

  Can this be considered as a bug in paludis ?

 The spec seems to be clear that T is legal in all phases, including
 pkg_pretend.

 Well, I'd say: there is no sane value you can assign to $T since you are
 not allowed to write anything anyway:

indeed it's not writing, check-reqs.eclass is reading space available
via 'df -Pm' there is something else it could use assuming
$PORTAGE_TMPDIR is worse for portability?


 pkg_pretend must not write to the
 filesystem. (http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-9700010.1.2)

 and since pkg_pretend is run separately from the main phase function
 sequence, and does not participate in any kind of environment saving it
 is not guaranteed to be set to the same $T later.

 Cheers,
 Tiziano

Re: [gentoo-dev] Deprecate EAPI1?

[Francesco Riosa]

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 managers planned on supporting all the EAPIs for
 quite a while longer.

 We have to support them indefinitely. It's not possible to uninstall a
 package whose EAPI is unknown.

probably not needed in practice, some random toughts follow.

upgrade a gentoo system older than three years is nearly impossible,
even update small part of it can be a major problem. Solution being
install from scratch in a new partition or overwrite with a stage 3
and abuse qfile -o.

Hopefully situation will change in the future, and we will able to
eix-sync and upgrade all of gentoo or only part of it.

At the moment tough the ability to ununstall a package from year
2008/2009 is moot, the system is screwed anyway.

except for the possible existance of packages which have not been
updated in 3/4 years (do they exist?) it's possible for all package
mangler (tm) to consider pre 2009 stuff as forgotten.

regards,
Francesco

Re: [gentoo-dev] Deprecate EAPI1?

[Francesco Riosa]

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.
Tell everyone that it's not possible to upgrade a 2009 system id more
honest and free everybody from forever compatibility slavery.

To be able to upgrade a gentoo installation as old as five years is
interesting and valuable but require an effort that has yet to be
made.

P.S. I'm neutral about EAPI 1 deprecation, just stating that forever
support is a chimera right now

2012/3/11 Richard Yao r...@cs.stonybrook.edu:
 These must be maintained indefinitely to provide an upgrade path for
 older Gentoo Linux installations. It is rare, but people do upgrade
 old installs from time to time. Without some EAPI=1 packages, there is
 no path for people to use to upgrade.

 On Sun, Mar 11, 2012 at 8:01 AM, Pacho Ramos pa...@gentoo.org wrote:
 After reading previous discussion:
 http://help.lockergnome.com/linux/gentoo-dev-Deprecate-EAPIs--ftopict530567.html

 Looks like preventing NEW commits from using eapi1 (via repoman) could
 be done without major issues. This could even being done also for eapi2
 as it's close enough to eapi3, but I don't have a strong opinion about
 eapi2 deprecation (personally, I try to always use latest eapi if eclass
 allows me to do so).

 Any thoughts on this?

 Thanks

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

[Francesco Riosa]

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 apply to return as a developer in
gentoo, will respond to emails this week end (25/26 Feb)

I'm _not_ offering support for digikam, for which I develop, because I
would like to mantain a two step verification process
(developer/packager)

Regards,
Francesco

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

[Francesco Riosa]

2012/2/23 Andreas K. Huettel dilfri...@gentoo.org:
 Hi Francesco,

 certainly help is always welcome! ( thanks for all your upstream work with
 digikam and its database!)

it's a pleasure, also that work has ben temporarily halted, will
re-start very soon (this we)


 I'd love to offer my help on the Gentoo side, but unfortunately I'm just about
 to leave in a couple of days for a long (4weeks) business+vacation trip. While
 I'll take my laptop and occasionally do Gentoo stuff, I wont be able to
 dedicate much time...

 Best thing is probably to talk to the guys on #gentoo-kde, and if you 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 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 apply to return as a developer in
 gentoo, will respond to emails this week end (25/26 Feb)

 I'm _not_ offering support for digikam, for which I develop, because I
 would like to mantain a two step verification process
 (developer/packager)

 Regards,
 Francesco
 --
 Andreas K. Huettel
 Gentoo Linux developer
 kde, sci, arm, tex, printing