Re: [gentoo-dev] [GLEP] Manifest2 format

[Francesco Riosa]

Marius Mauch wrote:
> Hi,
> 
> As promised here the GLEP for Manifest2 support:
> http://www.gentoo.org/proj/en/glep/glep-0044.html
> 
> This will NOT be voted upon the next council meeting on thursday ;)
> 
> Marius
> 

Really great that this has reached us, digest-* files are really
annoying from my pov.

Greetings to everyone who make this happen.

-- F.R.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Francesco Riosa]

Luca Barbato wrote:
> Ciaran McCreesh wrote:
>>
>> * Anything involving XML.
>>
> 
> What about incidentally make the format yaml compatible?
> 
> yaml.org

Only if we (you?) are able to extract a considerably simpler subset of
the specification, as is it's really overkill.

> 
> /me runs

where ? gentoo devs are everywhere ... mwhuaahahahah

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Francesco Riosa]

Ciaran McCreesh wrote:

> GLEP: 42
> Title: Critical News Reporting

+1 .
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Francesco Riosa]

Jason Stubbs wrote:
[...]
> As I said already, there will immediately be a bug asking for overlay 
> support. 
> Portage already supports multiple in a form whether anybody likes it or not.
[...]
BTW I love that feature ;-)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Francesco Riosa]

Olivier Crete wrote:
> On Tue, 2005-13-12 at 21:09 +, Ciaran McCreesh wrote:
>> On Tue, 13 Dec 2005 15:53:45 -0500 Olivier Crete <[EMAIL PROTECTED]>
>> wrote:
>> | Why not just modify GlEP 1 ?
>>
>> Going back and retroactively modifying standards is icky, and it
>> *still* doesn't address the issue of documenting why the change was
>> made.
> 
> And why not just adding a changelog to the glep explaining the changes?
> I really don't like to idea of having to read 8 gleps to find out how to
> write a glep ... and calling it glep 1.a is a good idea.. or 1.1
> 

agree, have to dig multiple places to get the history of a document is
annoying.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Optimizing performance

[Francesco Riosa]

Patrick Lauer wrote:
> Hi all,
> 
> I was wondering if there are any sane ways to optimize the performance
> of a Gentoo system.
> Overoptimization (the well known "-O9 -fomgomg" CFLAGS etc.) tends to
> make things unstable, which is of course not what we want. The "easy"
> way out would be buying faster hardware, but that is usually not an
> option ;-)

Some upstreams, mostly media related but also unsuspectable like MySQL,
use and test their apps with high optimizations.
As an effect some of these apps tend to be _more_ stable with those high
optimizations.
If I recall correctly Ned Ludd (solar) did some work on having per
package defined CFLAGS, don't know what was the intent of that work but
integrate in portage a /etc/portage/package.env support, and let the
packages mantainer _suggest_ optimal C*FLAGS may increase both stability
and performance.
However this require _a lot_ of manpower, add maybe unmanageable
complexity, in every stage of a package life, from writing the ebuild to
the final stabilization.

> 
> So ... what can be done to get the stable maximum out of your hardware?
> 
> In my experience (x86 centric - do other arches have different
> "problems"?) the following is stable, but not necessarily the optimum:
> - don't overtweak CFLAGS. "-O2 -march=$your_cpu_family" seems to be on
> average the best, -O3 is often slower and can cause bugs

see ^^^

> - don't do anything with ASFLAGS, LDFLAGS. This causes weird random
> breakage (e.g. LDFLAGS="-O1" causes prelink to fail with "absurd"
> errors) and doesn't give a noticeable performance boost

see ^^^

> - check that all IDE disks use DMA mode, otherwise they are limited to
> ~16M/s with a huge CPU usage penalty. Sometimes (application-specific)
> increasing the readahead with hdparm gives a huge throughput boost.

having more than one disk or a lot of memory add very interesting
addition, read raid 0 (stripe) or tmpfs for working data that does'nt
need a backup fex: $PORTIR, /var/tmp ...

> - kernel tweaks like preempt may increase the responsiveness of the
> system, but often reduce throughput and may have unexpected sideeffects
> like random audio stutter as well as random kernel crashes ;-)

I've found that preemption with the new standard 250Hz of the kernel is
suitable for mostly needs, however no server here has preemption enabled ;-)

> - kernel tweaks like setting swappiness or using a different I/O
> scheduler (CFQ, deadline) should help, but I'm not aware of any "real"
> benchmarks except microbenchmarks (can create 1M files 10% faster! -
> yes, but how does it behave with a normal workload?)

what is a normal workload ? Define it and creating tests should not be
so difficult, then there are apps that can help to profiling, thinking
at bootchart, sysproof, memproof, valgrind ... strace

> - using a "smarter" filesystem can dramatically improve performance at
> the potential cost of reliability. As data on FS reliability is hard to
> find from unbiased sources this becomes a religious issue ... migrating
> from ext3 to reiserfs makes "emerge sync" extremely much faster, but is
> reiserfs sustainable?

reiserfs is sustainable, at least for 99.999% of uses, last reiserfs bug
on very high load (and with degraded raid5) is dated 4 years ago here.
However upstream is going to the route of reiser4, much more complex,
and much more unstable, latest problems where in 2.6.14, additionally no
devs in gentoo are (will?) support it the patch for grub it's still not
in place I think.

> 
> Are there any application-specific tweaks (e.g. "use the prefork MPM
> with apache2")? What is known to break things, what has usually
> beneficial behaviour? Are there any useful benchmarks that show the
> performance difference between different settings?

is'n there "ab" [1] for apache testing ?

Cheers,
Francesco Riosa

[1] http://httpd.apache.org/docs/2.0/programs/ab.html
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Optimizing performance

[Francesco Riosa]

Patrick Lauer wrote:
> -user has the risk of many "use teh -fomglol flag, it si teh fast0r" ;-)
> hardened doesn't have much to do with performance (although I'd be
> interested what impact - if any - the different security features have!)

fresh of typing (but worked on for few months)
http://www.pjvenda.org/linux/doc/pax-performance/
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] ChangeLogs and rsync time

[Francesco Riosa]

We have currently 10371 ChangeLog files, > 25 MB totally .
1365 == 13% with size >= 4096 B, 12 MB totally

rsync from "emerge --sync" has "--whole-file" between its options, that
mean transfer the whole file if changed.

To make things worse the bigger ChangeLogs are (oh, surprise) those that
change frequently (also the age count), following there is the list of
first 25:

110062  ./x11-base/xorg-x11/ChangeLog
96906   ./sys-devel/gcc/ChangeLog
86916   ./sys-libs/glibc/ChangeLog
72429   ./net-www/apache/ChangeLog
65331   ./sys-apps/baselayout/ChangeLog
61801   ./media-video/mplayer/ChangeLog
57688   ./dev-db/mysql/ChangeLog
53938   ./sys-kernel/gentoo-sources/ChangeLog
53810   ./net-im/gaim/ChangeLog
53173   ./www-client/mozilla/ChangeLog
51891   ./dev-php/mod_php/ChangeLog
48127   ./dev-db/postgresql/ChangeLog
47014   ./sys-devel/binutils/ChangeLog
46742   ./kde-base/kdelibs/ChangeLog
45370   ./dev-lang/perl/ChangeLog
44998   ./sys-kernel/mm-sources/ChangeLog
41010   ./kde-base/kdebase/ChangeLog
37644   ./www-client/mozilla-firefox/ChangeLog
37524   ./net-fs/samba/ChangeLog
36411   ./mail-mta/postfix/ChangeLog
35269   ./app-office/openoffice-ximian/ChangeLog
34890   ./app-office/openoffice/ChangeLog
34773   ./sys-kernel/mips-sources/ChangeLog
33245   ./media-sound/xmms/ChangeLog
32769   ./dev-util/subversion/ChangeLog


The information contained in the ChangeLogs is essential, and it must be
kept, but, force the users to download all that data it's not optimal.

That said I can see only two ways to reduce the ChangeLog files (a
centralized one is obviously not viable)

1) bzip2 them in some way.

   Pros:
   - whole story is avaiable
   - much lower file transfer size
   Cons:
   - grepping them need dedicated tools
   - never ending cvs issues, may be needed an alternate non cvs tree
   - vim already has a wrapper to read bz2 files, other editors does not
   - also 247 bytes file will need to be zipped ?

2) "rotate" Changelogs, keeping only the last changes, until a size
   of 4000 or [choose a preferred size here] bytes.
   This would save only about 7Mb of data (max size < 4096).

   Pros:
   - still easily readable and parseable
   - save download of data in the right points
   - affect only 13% of the actual tree
   Cons:
   - need changes in repoman/echangelog to cut the ChangeLog in the
 right position
   - grepping of ChangeLog impossible (for cutted data)
   - ChangeLog cutted at _no_ definite point in time (maybe yesterday)
   - whole history only on viewcvs or with acks like a
 sys-apps/ChangeLogs package

Thoughts ? It's doable in some way ?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ChangeLogs and rsync time

[Francesco Riosa]

Andrej Kacian wrote:
> On Sun, 01 Jan 2006 21:35:34 +0100
> Francesco Riosa <[EMAIL PROTECTED]> wrote:
> 
>> Thoughts ? It's doable in some way ?
> 
> Whatever way will get chosen, a full copy of every ChangeLog should be made
> available somewhere (somewhere other than CVS Attic), for future reference.
> 
> Kind regards,

I was thinking in a package that install in /usr/share/changelogs and/or
a web access, infra would be happy to add changelogs.gentoo.org domain .

/me runs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ChangeLogs and rsync time

[Francesco Riosa]

Grobian wrote:
> On 01-01-2006 21:35:34 +0100, Francesco Riosa wrote with possible deletions:
>> The information contained in the ChangeLogs is essential, and it must be
>> kept, but, force the users to download all that data it's not optimal.
>>
>> That said I can see only two ways to reduce the ChangeLog files (a
>> centralized one is obviously not viable)
>>
>> 1) bzip2 them in some way.
>> 2) "rotate" Changelogs, keeping only the last changes, until a size
> 
> or
> 3) remove entries for non-existing ebuilds
> 4) compress Changelog entries where possible

A combination of 2) and 3) looks good.
Maybe with some tool to automate it but that left to developer the final
decision on what cut or not.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ChangeLogs and rsync time

[Francesco Riosa]

Ciaran McCreesh wrote:
> On Sun, 01 Jan 2006 21:35:34 +0100 Francesco Riosa <[EMAIL PROTECTED]>
> wrote:
> | That said I can see only two ways to reduce the ChangeLog files (a
> | centralized one is obviously not viable)
> 
> 5) Anyone who really cares can use the excludes list, and check the
> ChangeLogs on the web when they need them.
> 
yes but this excludes totally the ChangeLogs. Having the latest changes
handy may be useful.

Simply trying to equilibrate benefits and disadvantages,
for desktop user that care on changelogs only when emerge fail
and the network administrator that has a local rsync mirror and could
not care less of some additional MB transferred.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ChangeLogs and rsync time

[Francesco Riosa]

Matti Bickel wrote:
> Pawe?? Madej <[EMAIL PROTECTED]> wrote:
>> As a common user with ADSL 256kbps all additional data downloaded via
>> rsync causes longer wait for syncing. If I want to see a changelog i
>> go to packages.gentoo.org and read it. As i got Gentoo for about 10
>> months I don't remember if I read Changelog via bash.
> 
> I strongly disagree. Reading changelogs on the web means browsing for
> them. This is much slower for me than a 'less
> /usr/portage/foo/bar/Changelog'.
> 
> I rather go with ciaranm and tell users to use rsync_exclude if they
> don't want changelogs. Taking away choice without an option is a bad
> thing (tm).
> 
> Regards and a happy new year,
> Matti

A (rethoric) question:
Do you read every time the whole ChangeLog ?

If not, generally, how much of it ?

Regards,
Francesco R.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ChangeLogs and rsync time

[Francesco Riosa]

Ok, last shoot, then let put this stuff to sleep.
Description of the attachment at the end:

Chris Gianelloni wrote:
> On Mon, 2006-01-02 at 11:25 -0600, Lance Albertson wrote: 
>>> I'm also for telling the users to rsync exclude the ChangeLogs if they
>>> don't want them instead of getting rid of them or crippling them.
>> I don't think that's really a solution. That's just a way to minimize
>> what they get. If you really want to look at a solution, you should
>> reduce whats actually in the changelog. All the changelogs are in CVS,
>> and if someone wanted to go look back at any changes, they can either
>> look at viewcvs or (hopefully soon), grab it via anoncvs. I bet you >80%
>> of things in the changelogs are for things that are in the attic. I say
>> we need a way to either have echangelog (or another script) to clean out
>> changelog entries for things that are in the attic (and make sense to
>> take out). Maybe another option would be to remove any 'version bump'
>> type entries that are old as well.
> 
> OK.  I keep seeing this argument about ChangeLog stuff for ebuilds in
> the Attic and I just think people might not be thinking it totally
> trough.  For example, I made changes to the vmware-workstation ebuilds
> to force group membership a while back because of a security bug.
> However, there's been another security bug since, so those changes were
> made on ebuilds now in Attic, but the change is still valid in the
> current ebuilds.

Could ignore the revision (-r*) address this issue ?

> 
> I don't see a problem with removing version bump and stabilization
> messages, but everything else should stay in the ChangeLog for as long
> as the package is still around.
> 
>> I just don't see the point of keeping changelog entries for stuff that
>> isn't even viewable in the tree anymore. We have CVS, the record will be
>> there, lets use it. We can't cater to every user out there, but come up
>> with a solid solution that makes sense and still gives them some form of
>> ability to look back.
> 
> Because as I stated before, there are many times where the ChangeLog
> entry for an older ebuild applies to the newer ones.  This is especially
> true when ebuilds are simply copied for version bumps.  Removing this
> information removes a lot of data.  Forcing users/developers to use CVS
> makes it more of a hassle than the gains will give us.

same as before

> 
> Again, I think this is another case of us doing things that aren't
> necessary rather than educating users.
> 
> I wouldn't have a problem with seeing ChangeLog in a default
> RSYNC_EXCLUDES with a nice comment explaining how to get the ChangeLog
> files.  This way we are removing the problem by default, educating
> users, and still not removing any data or options for our users and
> developers.
> 

IMHO RSYNC_EXCLUDES it's a bad option, in it's extended version, exclude
foo/bar could bring to every sort of problems, difficult to address (but
I've never tryed that ;-).

The attached bash script attempt to purge the ChangeLog (it broke a bit
but could be solved)

It clean out all entries without corresponding files (*.ebuild files/*)
It left in place date of addition of euilds and developer that changed
something

The test is moved in two new files Changelog.{new,old}

be careful, it leave a ".tmp__revisions" in place

The size of the resulting ChangeLog may be less han 50% than the original.

#! /bin/bash

function exit_no_changelog() {
echo "No ChangeLog found"
exit 1
}


function main() {

local ChangeLog="ChangeLog"
local ChangeLogNew="ChangeLog.new"
local ChangeLogOld="ChangeLog.old"
local inside=0
local buffer

CWD="."
pushd "${CVD}" &> /dev/null

[[ -f "${ChangeLog}" ]] || exit_no_changelog

# create a list of each version, remove gentoo specific revisions
#grep ^\* ChangeLog \
#| sed -e 's/^*//;s/ .*//;s/-r[[:digit:]][[:digit:]]*//' \
#| sort \
#| uniq \
#> .tmp__versions

# create a list of each version
grep ^\* "${ChangeLog}" \
| sed -e 's/^*//;s/ .*//' \
| sort \
| uniq \
> .tmp__revisions

# keep track of each modify and author
# FIXME this is a sed job
local entry_pattern='[[:digit:]][[:digit:]]\ 
[[:alnum:]][[:alnum:]][[:alnum:]]\ 20[[:digit:]][[:digit:]]; '
echo -n "" > .tmp__revisions
while read line ; do
case "${line}" in
${entry_pattern}*:*)
echo "${line}" >> .tmp__revisions
;;
${entry_pattern}*)
echo -n ${line} >> .tmp__revisions
inside=1
;;
*:*)
if [[ inside -eq 1 ]] ; then
echo ${line} >> .tmp__revisions
inside=0
fi
;;
*)
[[ inside -eq 1 ]] && echo -n ${line} >> .tmp__revisions
;;
esac
done < "${ChangeLog}"
sed -i -e 's/:.*$/:/' .tmp__revisions

# mark revisions to keep

Re: [gentoo-dev] ChangeLogs and rsync time

[Francesco Riosa]

Chris Gianelloni wrote:
> On Tue, 2006-01-03 at 00:35 +0300, Peter Volkov (pva) wrote:
>> On Вск, 2006-01-01 at 21:35 +0100, Francesco Riosa wrote:
>>> We have currently 10371 ChangeLog files, > 25 MB totally .
>>> 1365 == 13% with size >= 4096 B, 12 MB totally
[...]
> be benificial.  The only question left to be answered is how much space
> would actually be saved to make this extra load on CVS worth it.
> 

At the extreme of all ChangeLog moved in old there are 10371 more files
in the tree, 25 MB less to check and to transfer (in case all the
Changelogs are modified at the same time).

In a more general scenario, only about 1300 Changelogs need to be
transferred in ChangeLog.old, Leaving The total size of the Changelogs
to about 18 MB instead of 25, with about 6 MB in ChangeLog.old (assuming
no duplicated data).
The Total number of ChangeLog* raise to 10371[norm] + 1365[.old] = 11736

There is a overhead for user that not use rsync exclude and a noticeable
gain for user that instead exclude ChangeLog.old .


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] mysql commercial

[Francesco Riosa]

Steve Rodgers wrote:

It isn't very clear to what it needed here but I'll try to answer anyway

> Hi does anyone have any experience of deploying mysql commercial build into a 
> gentoo platform?

not me, but I use the gpl version for commercial scopes

> 
> Several mysql dependencies such as php will need to have the ebuild slot 
> there so I guess it's
> up to me to maintain an overlay equivalent that provides the same as the 
> portage ebuild?

If both "app-db/mysql-commercial" and "app-db/mysql" are in portage the
packages may depend over a "virtual/mysql" . Virtuals are used in gentoo
tree for packages that both provide the same functionality.

> 
> Does this exist and if not - would it be of use for me to contribute back to 
> portage?
> 
> e.g. app-db/mysql-commercial

Users to get a package in the tree need to open a bug and attach the an
ebuild, then a developer could take care of the bug and insert it into
the tree. However that developer will probably need a copy of a
commercial MySQL to test and work on.

As an alternative you could try to become a developer and take care
yourself of the package.

> 
> Thanks
> 
> Steve

Regards,
Francesco
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] mysql commercial

[Francesco Riosa]

Jakub Moc wrote:
[...]
> Dunno what exactly "commercial" means here, it you mean official -bin,
> there's some overlay and ebuilds in Bug 83424, there's also some weird
[...]

Please forget that one, it's broken, and the quantity and the size of
the binary packages to download make an hell to maintain it, i.e.
(unless you want to maintain just x86 and amd64 ARCHs)

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] [dRFC] slotted mysql ready

[Francesco Riosa]

Background, to make life easyer for people that use more versions of
mysql (and just for fun) MySQL is going to be slotted.

Currently the slot enabled versions are mysql-4.1.16-r30
mysql-5.0.18-r30 mysql-5.1.4_alpha-r30, in short those with "-r30".

The few patches needed are already included in current ~ mysql-4.1.16
and mysql-5.0.18 but hidden due to SLOT=0, starting from 2005-11

An eselect-mysql module has been prepared to create simlinks for the
desired version of mysql making easy to switch between them (hopefully)

The libraries (libmysqlclient & co) don't follow this logic and the
higher version is always the default (similarly to sys-libs/db).

The rc-scripts have been modified to use the logic of
sys-apps/baselayout net.ethx => net.lo symlink to be able to start more
servers at once (this is working from 2005-11 but reworked today)

Additionally the ebuilds code has been moved to two new eclasses,
mysql_fx.eclass and mysql.eclass, the first own support functions, the
last own the src_* pkg_* functions.
The initial idea is that when a specific ebuild need to marked stable
the code is moved from the mysql.eclass to the ebuild itself, to froze it.

Documentation on:
o switch to slotted
o upgrade with no downtime using this new capabilities
need to be written from scratch (this is going to be the more difficult
part for me).

there is a bash construct the eclass use to retrieve the latest two
chars of a string, in the form: MYVAR="${MYARRAY[3]:(-2)}" , is this
acceptable?

The intention is to made mysql-5.0.18-r30 stable on 2005-02-15 at
maximum on the first archs.

AFAIK I'm the only one who have seen this stuff until now, any comment,
any suggestion is highly apreciated.


Francesco Riosa
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [dRFC] slotted mysql ready

[Francesco Riosa]

Kalin KOZHUHAROV wrote:
[...]
>>
>> An eselect-mysql module has been prepared to create simlinks for the
>> desired version of mysql making easy to switch between them (hopefully)
>>
>> The libraries (libmysqlclient & co) don't follow this logic and the
>> higher version is always the default (similarly to sys-libs/db).
> 
> So how does this affect packages that use say dev-perl/DBD-mysql ?
> 
> If they can only use mysql-5, then the will be broken if they connect to a 
> mysql-4 server using non
> UTF-8 encoding. (bad wording, but generally speaking, there is an 
> inconsistence in character
> encoding betweet mysql-4 and mysql-5 that DOES break things on non ISO-8859-1 
> encoded databases)
> 
[...]

At the moment 4.0 is not slotted, only >= 4.1 are.

The fact that is effectively possible to use a non slotted 4.0 together
 with 4.1 and 5.0 does not mean that it should be used that way.

Does this answer your question ?

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [dRFC] slotted mysql ready

[Francesco Riosa]

Kalin KOZHUHAROV wrote:
> Francesco Riosa wrote:
>> Kalin KOZHUHAROV wrote:
[...]
>
> Now this is in my mind, a mind that looks for bugs and troubles before
they come out.

That's exactly what I'm looking for ;-)

>
> If mysql is slotted (and you said it it will be soon), what will
happen to software that use mysql
> bindings, for example dev-perl/DBD-mysql?

will happen that the bindings need to be fixed at first,
fex see bug #114925 "dev-perl/DBD-mysql-3.0002_p4 fails to compile"
where Malcolm Lashley give a patch to add backward compatibility.

TODO: threat include files like libraries, also mind about "mysql_config"

>
> "{{{ A hypothetical example:
>
> I used mysql-4.1.16-r30 and I have a locally encoded (say Shift_JIS)
database. I have DBD-mysql
> compiled against that and a package FOO using that works as expected.
>
> Some package wants >=mysql-5.0.0 and DBD-mysql, and because mysql is
SLOTed, portage says ok,
> emerges mysql-5.0.18-r30 and rebuilds DBD-mysql against it.

Oops *you* need to tell portage to rebuild DBD-mysql.
Difficult that a package will want mysql >= something, but take this is
an example, so it's ok.

>
> The probable result is that package FOO will be silently broken
because of incompatible changes
> between mysql-4.1 and mysql-5.0 ...
>
> "}}}

Not so probable, or at least at a lesser degree than what you think.
The major part of incompatibilityes are absorbed from the additional
layer offered by DBD-mysql.
The client app will still work with DBD-mysql, not directly with the server.
Ah and by the way remember that the server running will continue to be
4.1, and that default datadir will be different for 4.1 and 5.0 (it's
insane to make two different versions work with the same data)

Charset side there is additional support in MySQL 5.0 to support UTF-16,
but the big jump has been done between 4.0 and 4.1, now it should be
just more easy.

>
> Actually reading on
http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html there are
quite
> many incompatible changes.

Take a look at the changes:

Server Changes:
- The indexing order for end-space in TEXT  columns ...
  Unlikely to affect many apps.
- For BINARY columns, the pad value and how ...
  Unlikely to affect many apps.
- MyISAM and InnoDB  tables created with DECIMAL ...
  Database only change, not visible outside (well not exatly but with a
good approx.)
- Incompatible change: As of MySQL 5.0.3, the server by default no
longer loads user-defined functions...
  Unlikely to affect many apps.
- Incompatible change: The update log was removed in MySQL 5.0 ...
  Don't affect apps, learn to use "mysqlbinlog"
- Support for the ISAM storage engine has been removed ...
  Well it's real time to switch to myisam
- Support for RAID options in MyISAM tables has been removed ...
  Don't affect apps.

SQL Changes:
- Previously, a lock wait timeout caused InnoDB to roll ...
  Look like a bug fixed
- The namespace for triggers has changed in MySQL 5.0.10. ...
  Don't affect 4.1
- As of MySQL 5.0.15, the CHAR() function returns a binary string rather
than ...
  Filtered from DBD-mysql layer
- Beginning with MySQL 5.0.12, natural joins and joins with USING,
including outer join variants, are processed according to the SQL:2003
standard. The changes include elimination of redundant output columns
for NATURAL joins and joins specified with a USING clause and proper
ordering of output columns. The precedence of the comma operator also
now is lower compared to JOIN.
  LIKELY TO AFFECT MANY APPS THAT USE SQL, however the fixes are cheap
as this nonsense
  1 + 2 - 3 ==> ( 1 + 2 ) * 3
  there is an operator that changed precedence.

>
> Although this may be a problem for DBD-mysql, it will be exposed after
mysql is SLOTed...
> Or shall we SLOT dev-perl/DBD-mysql as well?
> And what about ruby, python (any other language bindings?)?

No at all, every one of these must be able to compile on whatever
version of mysql,
examples of how this could be done are at bugs 85783, 85810, 85829,
85843, 85844, 114925.

Better ?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Projects and simple guides

[Francesco Riosa]

Lance Albertson wrote:
> Aron Griffis wrote:
>> Grant Goodyear wrote:[Tue Jan 10 2006, 11:09:15AM EST]
>>
>>> As an aside, it's ciarnanm has already put work in on developing an RST to
>>> guidexml converter, so I wouldn't worry too much about RST not scaling.
>>
>> Could that be used dynamically on the server?  The last time I was
>> familiar with the gentoo.org server, it was running axkit and
>> dynamically generating HTML from the GuideXML.  Is it a relatively
>> simple matter to support .rst files in the same manner?
> 
> Actually, we're moving away from axkit because its a PITA to maintain.
> Currently, two of the three web nodes are running a home grown app
> called gorg that runs via ruby. It seems to work rather well.
> 
>> A related question: How hard would it be to enable the dynamic
>> generation for dev.gentoo.org/~users?  That would make development of
>> RST or GuideXML documents *much* simpler, since we could just work on
>> the file in our public_html and test render it by accessing through
>> a web browser.
> 
> Last I knew, its not a simple task for generating those nice looking
> html pages that ciaranm made a while back for the developer docs. When I
> asked him about (he can probably provide more detail), It took a lot of
> processing time and wasn't that scalable. Now, I'm not sure if anything
> has changed since then.
> 
> I can probably setup toucan to use gorg in some fashion if I had a few
> folks to test it with. I'm sure that would make things easier for a lot
> of people for rendering things.
> 

yes and it would be much appreciated to have this possibility on
d.g.o/~users/ .

tester += me, if that can help.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds

[Francesco Riosa]

>>> I would like to be able to limit the -jN when there is no distcc host
>>> available or when compiling c++ code, otherwise my poor laptop is dead with
>>> -j5 compiling pwlib when the network is down
>> As far as I can tell distcc isn't smart enough for dynamic load balancing.
>> One could hack portage to "test" each server in the distcc host list and
>> remove missing servers for each run - doesn't look elegant to me.
> dn
> Yes, might be a solution, even if not elegant. I am thinking also of
> automating distcc configuration (i.e. no need to run --set-hosts) and one
> idea is to use DNS with some TXT record, but that is just an idea - no
> patching is done yet.

you may be interested in the SRV DNS record, take a look at
http://www.dns-sd.org/ServiceTypes.html

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] guide/howto switching to slotted MySQL

[Francesco Riosa]

Here there is a guide on howto switch to the slotted versions of MySQL.
It's a first draft and to be totally usable some repoman commit are needed.

After the mentioned commits and the needed corrections to the guide
4.1.16 , 5.0.17 and 5.0.18 (all marked unstable) will be removed.

At the same time slotted MySQL will acquire keywording actually owned by
 the removed counterparts.

The stabling of MySQL 5.0 will be retarded from 2005-02-15 to 30 days
after the slotted packages keywording.

regards,
Francesco R.






MySQL, upgrade and switch to slotted guide


	Francesco Riosa



Here described there is an upgrade path for MySQL databases as painless as
possible.






1.6
2006-01-04


Upgrading from old versions of MySQL




This document cover how to upgrade to the latest version available.
There are currently three version of MySQL supported in portage:


	5.0 Follow upstream schedule (stable tree, active bugfixing)
	4.1 Follow upstream schedule (only changes to a large userbase)
	4.0 Security fix only


There are two additional version presently, but are currently unsupported
meaning that bug reports have very low priority any may lack functionalities.
The current document is not guaranteed to work with them.


	3.23 ancient
	5.1 active development




	The present document will use mysql-4.0.26 as start point
	and mysql-5.0.18-r30 as the target version
	Replace any of these with your own.








Install the new version




	This step require to (re)move some files from the running environment,
	so the first thing to do is a backup of the running database server,
	(still not the data).
	Done that, it's possible to remove the conflicting files with the
	slotted MySQL, and install the new version side by side with
	the current one.



# quickpkg dev-db/mysql
# rm -rf /usr/include/mysql /usr/bin/mysql_config
# for tmpfile in  /usr/lib/*mysql* ; do
  mv "${tmpfile}" "${tmpfile}.TMP"
  ln -s "${tmpfile}.TMP" "${tmpfile}"
  done
# emerge -av =dev-db/mysql-5.0.18-r30



Be sure to update the /etc/init.d/mysql startup script with
etc-update or dispatch-conf.







Copy the data to the newly installed server




Lets go to to dump the data, this will be imported in the new version of
mysql.
We are going to use mysqldump from the slotted MySQL.
Notice the "-500" suffix to the mysqldump program name, it's from
the 5.0.x version.



# mysqldump-500 \
  --defaults-file=/etc/mysql/my.cnf
  -uroot \
  --password='your_password' \
  -hlocalhost \
  --all-databases \
  --opt \
  --allow-keywords \
  --flush-logs \
  --hex-blob \
  --master-data \
  --max_allowed_packet=16M \
  --quote-names \
  --result-file=BACKUP_MYSQL_4.0.SQL



Now a file named BACKUP_MYSQL_4.0.SQL exist, which can be
used to recreate your data. The data is described in the MySQL dialect of SQL,
the Structured Query Language.



start the server without networking and user management
and run the SQL script:



# mv /etc/conf.d/mysql /etc/conf.d/mysql.orig
# echo '
  NOCHECK=1
  DEBUG=3
  mysql_slot_500=(
"skip-networking"
"skip-grant-tables"
  )
  ' > /etc/conf.d/mysql
# /etc/init.d/mysql-500 start
# mysql-500 --defaults-file=/etc/mysql-500/my.cnf < BACKUP_MYSQL_4.0.SQL
# mv /etc/conf.d/mysql.orig /etc/conf.d/mysql
# /etc/init.d/mysql-500 stop



	To convert the data to UTF-8 during this step you MUST remove "--hex-blob"
	from the mysqldump option, then filter the data through a converter like
	"iconv".
	In most case this is done simply "piping" it like this:
	"iconv -f ISO_8859-1 -t UTF8 BACKUP_MYSQL_4.0.SQL
	| mysql-500 --defaults-file=/etc/mysql-500/my.cnf"
	Also manual tweaking of the SQL file could be needed, depending on the
	structure and the data contained in it.



	If there are applications still writing to the previous
	database, it's possible to setup a "Replication" relationship between the
	two databases, however this will not be covered here.








Switch to the new server


If you need to be sure that applications are working with the newly
installed server, please test them against it, quite every application
has configuration settings to chose which port or socket to use to connect
to the database server.
Simply start the server on an alternate port (for example 3307) and tell your
application or a test copy of it to connect with those parameters.
Pay attention that most of them will try to use the parameters found in the
"[client]" section of /etc/mysql/my.cnf config file.



When you're satisfied with the results, remove every testing setting,
stop the old server and start the new one.
Also make it the server that will start at next reboot.



# rc-update del mysql default
# rc-update add mysql-500 default
# /etc/init.d/mysql stop
# /etc/init.d/mysql-500 start



unmerge the old version, and make the new one the default.
The unme

Re: [gentoo-dev] Ebuilds and USE flags

[Francesco Riosa]

Rene Zbinden wrote:
> I am writing an ebuild for a program written in perl. This program has
> the dependency of gnuplot but with the png flag enabled. What is the
> gentoo way to enable this USE Flag for gnuplot when I emerge my program.
> 

There is no "active" way, you could only check if the flag was enabled,
and fail if it was not, take this example from app-admin/moodss


pkg_setup() {
if ! built_with_use dev-lang/tcl threads ; then
eerror "Tcl is missing threads support."
eerror "Please add 'threads' to your USE flags, and re-emerge tcl."
die "tcl needs threads support"
fi
}

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guide/howto switching to slotted MySQL

[Francesco Riosa]

Chris White wrote:
> On Monday 23 January 2006 10:06, Francesco Riosa wrote:
>> Here there is a guide on howto switch to the slotted versions of MySQL.
>> It's a first draft and to be totally usable some repoman commit are needed.
> 
> You're probably better of putting this in bugzilla and assigning to the docs 
> team. Please cc me as when you do make one.
> 
> Chris White

bug #120210, assigned and cc-ed :-)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: emerge snapshots

[Francesco Riosa]

A. Khattri wrote:
> On Tue, 24 Jan 2006, Wernfried Haas wrote:
> 
>> - adding buildpkg to your FEATURES builds binary packages, which makes
>>   it faster to revert to older versions if the new one cause
>>   problems.
> 
> You could also use quickpkg, i.e. write a script that interates through
> world and runs quickpkg on each atom. Quickpkg will drop a binary package
> in PKGDIR (which is set in /etc/make.conf). If you make a backup of PKGDIR
> and your world file, you have a crude packages backup which can be used
> to rebuild the box if need be.
> 

Better create the list from /var/db/pkg/* , world file only own the file
explicitly merged, leaving out any dependencies (fex libraries).

The backup of the world file is still (and more) needed
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Make logrotate a global USE flag?

[Francesco Riosa]

Doug Goldstein wrote:
> Marcelo Góes wrote:
>> It seems there are some ebuilds with a logrotate USE flag:
>>
>> use.local.desc:34:app-backup/bacula:logrotate - Install support files
>> for logrotate
>> use.local.desc:550:mail-filter/dspam:logrotate - Install support files
>> for logrotate
>> use.local.desc:899:net-ftp/vsftpd:logrotate - Use logrotate for rotating logs
>> use.local.desc:1011:net-misc/ntp:logrotate - Install support files for 
>> logrotate
>> use.local.desc:1079:net-proxy/squid:logrotate - Use logrotate for rotating 
>> logs
>> use.local.desc:1284:sys-power/acpid:logrotate - Use logrotate for rotating 
>> logs
>> use.local.desc:1290:sys-power/hibernate-script:logrotate - Use
>> logrotate for rotating logs
>> use.local.desc:1303:www-apps/dspam-web:logrotate - Build logrotate
>> support for dspam
>>
>> Perhaps it should be a global USE flag?
>>
>> Marcelo
>>
>> --
>> Marcelo Góes
>> [EMAIL PROTECTED]
>> [EMAIL PROTECTED]
>>
> How about the packages that don't even ask and just install logrotate
> stuff? Like Apache, lighttpd, and mysql?
> 

they should use it, MySQL will be updated when Marcelo make "logrotate"
uf global
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Make logrotate a global USE flag?

[Francesco Riosa]

Thomas de Grenier de Latour wrote:
> On Sat, 28 Jan 2006 18:58:52 -0800
> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> 
>> You want people to recompile the whole package to get another
>> text file installed?
>  
> When would one recompile a package just for that? Only case i can
> think of is when someone who already has setup his apache / ftp /
> database / whatever server suddenly discover what "logrotate" is
> and thus decide to start using it, whereas until then he didn't
> payed any attention to the flag each time it was listed by "emerge
> -pv".  That sounds rather unlikely, and i would say "too bad, be
> more careful next time..." to such a sysadmin. And anyway, this
> user doesn't really have to recompile anything to fix his mistake:
> he can still have a look on the ebuild to see that if the file he
> is missing is available in $FILESDIR, or use "ebuild unpack" and
> get it from the sources tree when it comes from upstream. 
> 
[snip]

indeed, rephrasing what sayd before in the same thread:

Mysql eclass will add a USE flag, local or global, "logrotate" for next
versions of MySQL, not touching the old ebuilds.

Run-time needed files will still live in $PORTDIR/dev-db/mysql/files,
because their size is small, and they change seldom. Compile time needed
files have been already moved in a separate SRC_URI fetched file.

Unless we decide to drop totally "logrotate" use flag support.

BTW hope this is not enough fuel to start another flamewar.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] slotted mysql ready for testing (~arch)

[Francesco Riosa]

As the subject say,
  In less than 24 hours slotted mysql ebuilds will be unmasked, to point
the finger they are:
=dev-db/mysql-4.1.16-r30
=dev-db/mysql-5.0.18-r30

There is a migration guide [1] that explain some of the magic, thanks to
the editors: Chris White, Jan Kundrát, Joshua Saddler to make it human
readable, beat me instead if it broke your box.

A third one, mysql-5.1.4_alpha-r30, as you can guess this will stay
masked (and yes I did noticed many days ago that 5.1.5 has been
released, just rename the ebuild if you want to give it a try).

The un-slotted counterparts will disappear from the tree at the same time:
=dev-db/mysql-4.1.16
=dev-db/mysql-5.0.17
=dev-db/mysql-5.0.18

The following will survive, without being slotted, either because too
old or because they are the last marked stable in the portage tree.
=dev-db/mysql-3.23.58-r1
=dev-db/mysql-4.0.25-r2
=dev-db/mysql-4.0.26
=dev-db/mysql-4.1.14

At the end February the mysql herd will cooperate with the arch's teams
to test and mark stable the following:
=dev-db/mysql-4.0.26
=dev-db/mysql-4.1.16-r30
=dev-db/mysql-5.0.18-r30
at that point in time older version will be removed too (3.23.58 is
another story).

Last notice:
emerge -pv =mysql-5.0.18 =mysql-5.0.18-r30
Calculating dependencies ...done!
[ebuild  NS   ] dev-db/mysql-5.0.18  USE="berkdb cluster extraengine
max-idx-128 perl ssl utf8 -big-tables -debug -minimal -static" 0 kB
[ebuild   R   ] dev-db/mysql-5.0.18-r30  USE="berkdb cluster extraengine
max-idx-128 perl ssl -big-tables -debug -minimal -srvdir -static"

As you can see the non-standard "utf8" use flag has been removed,
nothing bad, it was a easy replace in the my.cnf config file from
"latin1" to "utf8" and vice-versa.
the "srvdir" is easy too, it add support for "datadir" in
"/srv/localhost/mysql" but only for fresh install (see glep 20)

[1] http://www.gentoo.org/doc/en/mysql-upgrade-slotted.xml
[2] http://www.gentoo.org/proj/en/glep/glep-0020.html

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Default Ebuild behaviour

[Francesco Riosa]

Donnie Berkholz wrote:
> Ciaran McCreesh wrote:
>> On Tue, 31 Jan 2006 17:06:35 + "Benjamin Smee (strerror)"
>> <[EMAIL PROTECTED]> wrote:
>> | On Tuesday 31 January 2006 15:47, Ciaran McCreesh wrote:
>> | > For packages in the second group, not using a USE flag is silly. 
>> | 
>> | I take it you are agreeing we should have a USE flag for these
>> | ebuilds?
>>
>> For packages where /etc entries are "wanted by some, not wanted by
>> some", yes.
> 
> I finally came up with an idea for this that satisfies my desire to not
> recompile the package to get e.g. a logrotate file. Have the flag
> control whether it's installed to /etc or to /usr/share/doc.
> 
> Thoughts?

+1
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] [RFC] multislot mysql

[Francesco Riosa]

Ok, I've been realized that having a slotted mysql is not the dream of
every end user ... or developer.

Anyway I prefere too keep the possibility to do a similar install.

A good solution should be to add the "multislot" USE flag to the ebuild
and let it to decide whenever make it slotted or not, sorry, this is not
viable, yes it's already used by other important packages but not well
supported by portage and should be used only in particular situations.

The only thing that came in mind to me is to provide two series of
ebuilds, with different revision ranges.
The use flag "multislot" will still have a role, to make the ebuild fail
during pkg_setup() if set on the wrong ebuild.
It's possible to define the default ebuild to merge, assigning a greater
revision number will make an ebuild the default installed, I suggest the
un-slotted version to be the default.

example:

mysql-4.1.16-r[0..49] Need "+multislot"
mysql-4.1.16-r[50..99] Need "-multislot"
mysql-5.1.18-r[0..49] Need "+multislot"
mysql-5.1.18-r[50..99] Need "-multislot"

whoever want to have a slot version will need to mask revisions between
50 and 99 .

The change will happen soon, between today and tomorrow, so toughts,
flames and insults are well accepted.

- Francesco R.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] multislot mysql

[Francesco Riosa]

Carlos Silva wrote:
> On Fri, 2006-02-03 at 10:19 +0000, Francesco Riosa wrote:
>> Ok, I've been realized that having a slotted mysql is not the dream of
>> every end user ... or developer.
>>
>> Anyway I prefere too keep the possibility to do a similar install.
>>
>> A good solution should be to add the "multislot" USE flag to the ebuild
>> and let it to decide whenever make it slotted or not, sorry, this is not
>> viable, yes it's already used by other important packages but not well
>> supported by portage and should be used only in particular situations.
>>
>> The only thing that came in mind to me is to provide two series of
>> ebuilds, with different revision ranges.
>> The use flag "multislot" will still have a role, to make the ebuild fail
>> during pkg_setup() if set on the wrong ebuild.
>> It's possible to define the default ebuild to merge, assigning a greater
>> revision number will make an ebuild the default installed, I suggest the
>> un-slotted version to be the default.
>>
>> example:
>>
>> mysql-4.1.16-r[0..49] Need "+multislot"
>> mysql-4.1.16-r[50..99] Need "-multislot"
>> mysql-5.1.18-r[0..49] Need "+multislot"
>> mysql-5.1.18-r[50..99] Need "-multislot"
>>
>> whoever want to have a slot version will need to mask revisions between
>> 50 and 99 .
>>
>> The change will happen soon, between today and tomorrow, so toughts,
>> flames and insults are well accepted.
>>
>> - Francesco R.
> I really don't like this... It will give users more work to maintain
> their systems... Managing /etc/portage/ isn't easy, and forcing the
> users to use it, isn't good too. I speak for mysql:
> [EMAIL PROTECTED] ~ $ cat /etc/portage/package.keywords | wc -l
> 53
> ^^ And this was about 100 before i did a cleanup to it.
> 
> What i sugest is to create a diferent package, mysql-{slotted,}. You
> guys from the mysql herd can use the same ebuils to both packages (the
> content i mean) and just check the ${PN} for the slotted word to see if
> the package is slotted or not
> 
> Just my 0.02€
> 

I'm going to assume that user _don't_ want a slotted mysql .

Not forcing the users to mess with /etc/portage is exactly what I try to
 achieve here.

Assuming the ebuilds are already marked stable (and btw un-slotted MUST
be marked stable before or at the same time then slotted).
This case if u remove totally /etc/portage you will have a un-slotted
mysql installed, of the best version avaiable, isn't this what we want
to achieve ?

Having a different package is doable but also a un-useful tree cluttering.

Also I assume that if the user want to have a slotted MySQL version
he/she/they can cope with some entries in /etc/portage to achieve the
result.



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] multislot mysql

[Francesco Riosa]

Robin H. Johnson wrote:
> On Fri, Feb 03, 2006 at 10:19:18AM +0000, Francesco Riosa wrote:
>> A good solution should be to add the "multislot" USE flag to the ebuild
>> and let it to decide whenever make it slotted or not, sorry, this is not
>> viable, yes it's already used by other important packages but not well
>> supported by portage and should be used only in particular situations.
> [snip]
>> example:
>>
>> mysql-4.1.16-r[0..49] Need "+multislot"
>> mysql-4.1.16-r[50..99] Need "-multislot"
>> mysql-5.1.18-r[0..49] Need "+multislot"
>> mysql-5.1.18-r[50..99] Need "-multislot"
> NAK. Do not go the route of ranged revisions for specific features.
> 
> If you go with multislot, you must make it work in ALL revisions.
> 
> One of the reasons why is that portage does not support a limited
> ranged dep properly last I checked, so this is hard for everybody to
> deal with.
> 

Robin, Jakub,

I can see your points here, for the moment I will left things as is,
still open to alternatives.

Francesco
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Dev: zmedico (Zac Medico)

[Francesco Riosa]

Brian Harring wrote:
> Hola all-
> 
> Well looky here, we've got another new portage dev to report- Zac 
> Medico (zmedico).  Areas of focus thus far are general stable work, 
> and work on the rewrite (you can thank him and marienz for the test 
> framework work).
> 
> Additionally, Zac is the maintainer of two external projects-
> http://freshmeat.net/projects/linkbrowser/
> http://freshmeat.net/projects/rimanip/
>  
> Finally, he lives in Orange County, California, and is interested in 
> progressive politics related to social justice and environmental concerns.
> 
> So... say hello everyone, but kindly no leg humping (this means you 
> Battousai). :)
> 
> ~harring

Nice to have you on board Zac, take care of the tree environment :-)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [Fwd: Re: official branding ( gentoo )]

[Francesco Riosa]

Jory A. Pratt wrote:
> Well that is it, your firefox will no longer say deerpark :) I will
> commit the changes tomorrow morning.

With the package currently maintained by me I'm constrained to _not_
modularize it because of linking issues between source files, still
questionable but it's a question of stability.

To be asked by upstream to fixate unstable and huge extensions like
"canvas" and "svg" ... doesn't look good to me (said this way to keep
language polite on this list).

just my 2 € cents

Francesco R.
-- 
gentoo-dev@gentoo.org mailing list

Re: Translation questions [was: Re: [gentoo-dev] I want to help, but I don't know where]

[Francesco Riosa]

Rafael Bugajewski wrote:
> Mark Kowarsky wrote:
> 
>> If you want to help
>> http://www.securesystem.info/tiki-view_blog_post.php?blogId=3&postId=104
>> contains a good summary of what and how you can help out :).
> 
> Thanks for the nice link. I read some stuff and now I know that the first 
> step 
> is "helping out". So I will translate some existing documentation into 
> german.
> 
> I could start writing everything in german into a plain text file, but I 
> don't 
> think it's a good idea. In my opinion it would be better if I could write the 
> XML files directly and submit it to Bugzilla for approval. But where can I 
> get a needed XML structure, example or at least description?
> 
> Greets,
> 
> Rafael Bugajewski

start with these:

http://www.gentoo.org/proj/en/gdp/doc/doc-tipsntricks.xml
http://www.gentoo.org/proj/en/gdp/doc/translators-howto.xml
http://www.gentoo.org/proj/en/gdp/doc/metadoc-guide.xml

also patches for bugs in bugzilla are generally appreciated ;-)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] SLOTed MySQL or not?

[Francesco Riosa]

Luca Longinotti wrote:
> As the title says, what would you prefer for the future of MySQL in
Gentoo?
> Please take a moment to read
> https://forums.gentoo.org/viewtopic-t-438557.html and vote (and
> eventually comment on it).
> Thanks!

I've asked to Luca to have one week poll but the results [1] show
already that MySQL will be unslotted at the end.
Thank you to spend the time to do that I should do it _before_ to try
the slotting road (and may be speak with the other MySQL maintainer
before :p).

Luca (chtekk) Longinotti, will also take care of MySQL, on my request,
in a near future, then I'll stay as a backup maintainer for the time
coming, or leave if needed for whatever reason.

Before to this to happen I'll try my best to close the greatest number
of bugs still open (many already are but not committed) and manage to
bring MySQL back to the unslotted version.

[1]
Yes.  12% [ 12 ]
No.   75% [ 72 ]
No preference. 11% [ 11 ]

Best regards,
Francesco Riosa

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Change layout of distfiles

[Francesco Riosa]

Michael Renner wrote:

> Introducing an additional directory hierarchy should fix this, and is
> the common solution for this problem for various projects, be it debian
> [1], cpan [2], slackware [3], etc.
> 
> 
> One migration scenario for a better future:
> 
> Create subdirectories named after the first letter of each file and move
> the files in their respective directories.
> 

Splitting the files using only one letter leave some directory with
still too much files in imho.

g   2879
l   2394
p   2049
s   2018

versus

l   li  1652
k   kd  888
x   xf  670
g   gn  559

li* (lib) are still a lot, but more manageable.

the total number of files in my mirror directory is 32000, but I don't
delete old files, and I've started some months ago.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New developer: Alfredo Tupone (Tupone)

[Francesco Riosa]

Kito wrote:
> 
> On Mar 6, 2006, at 1:33 PM, [EMAIL PROTECTED] wrote:
> 
>> Hi all.
>>
>> Alfredo has joined the Gentoo team to help with the games herd. I'm sure
>> he'll have a fun time "testing" all those games :)
>>
>> Alfredo writes about himself:
>> "I live in Rome, Italy.
> 
> 
> Italians, Italians, everywhere Italians!
> 
> echo "Kito" | sed "s/K/V/"
> 

lol,
welcome both, Alfredo and Emanuele, nice to be a bigger conspiracy

Francesco
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] SLOTed MySQL or not?

[Francesco Riosa]

Luca Longinotti wrote:
> As the title says, what would you prefer for the future of MySQL in Gentoo?
> Please take a moment to read
> https://forums.gentoo.org/viewtopic-t-438557.html and vote (and
> eventually comment on it).
> Thanks!


http://bugs.gentoo.org/show_bug.cgi?id=125599

deprecation of "Slotted MySQL Upgrade and Migration Guide"




-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] SLOTed MySQL or not?

[Francesco Riosa]

Ramon van Alteren wrote:

No dev but +1 from me.
I liked slotted mysql a lot and use it extensively.

It has helped us tremendously during our upgrade path and I would be 
very sad to see it go.


Public opinion is just that, public opinion, doesn't neccesarily mean 
something went wrong.


FWIW, I'd like to keep the slotted mysql ebuilds. If they are removed 
from the tree I'll re-add them to our local frozen tree for our company.


We're not a hosting company BTW, we just run lots of mysql daemons ;-)

Ramon



Thanks to Stuart hosting it's avaiable again

Browse:
$ http://svn.gnqs.org/projects/gentoo-mysql-overlay/browser/slotted
Checkout:
$ svn co http://svn.gnqs.org/svn/gentoo-mysql-overlay/slotted slotted

I did not have the time to test it, and in the near future I will also 
be rather busy.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ati driver

[Francesco Riosa]

Roberto Griso wrote:


Please use the gentoo-desktop mailing list for these kinds of questions.

-Steve
--
gentoo-dev@gentoo.org <mailto:gentoo-dev@gentoo.org> mailing list


 this is not gentoo-desktop mailing list question, vai a cacare, tu e 
tre quarti della palazzina tua.


Complimenti, ottimo atteggiamento, hai meno di 10 anni vero ?
Allora forse devi ancora imparare che:
a) offendere qualcuno di un gruppo quando si fa una richiesta 'e 
perlomeno stupido.
b) offenderlo in italiano ti fara' solo odiare dagli altri italiani che 
leggono questa lista, perche ci vergognamo di te.
c) la domanda che hai posto veramente non ha senso qui, stai chiedendo 
aiuto per un problema di installazione, non per lo sviluppo di gentoo. 
trovati un altro posto dove possano rispondere alle tue domande, sui 
forum di gentoo oppure in quei tre quarti di palazzina che hai menzionato.


English speaking ppl, sorry for the italian.

- Francesco Riosa

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Having fun with compression

[Francesco Riosa]

Robin H. Johnson wrote:
> On Sun, Apr 30, 2006 at 06:30:23PM +0200, Patrick Lauer wrote:
>> We have ~15k .tar.gz in distfiles. ~6500 .tar.bz2, ~2000 others.
>> A short run over 477 distfiles spanning 833M gave me 586M of .tar.bz2 -
>> roughly 30% more efficient!
>> A comparison run with 7zip gave me 590M files, so bzip2 seems to be
>> quite good.
> Try rzip, esp. on the larger files, and see a serious improvement, with
> the cost of one major penalty [*].
> 
> * rzip cannot handle streams, it seeks across the file multiple times
>   for what it does.
> 

/me for fun too, values are consistnt between various run

foreach of:
export CMD='rzip -9 gcc-4.2-20060429.tar'
export CMD='rzip -d gcc-4.2-20060429.tar.rz'
export CMD='bzip2 -d gcc-4.2-20060429.tar.bz2'
export CMD='bzip2 -9 gcc-4.2-20060429.tar'
export CMD='gzip gcc-4.2-20060429.tar'
export CMD='gunzip gcc-4.2-20060429.tar.gz'

$CMD &>/dev/null & \
J=$(jobs -l 1 | cut -c 6- ) ; J=${J% Running*} \
; while [[ -d /proc/${J} ]] ; do sleep 0.05 ; echo -n "$J " ; grep
VmPeak /proc/${J}/status ; done


file: gcc-4.2-20060429.tar size 268160 kB

Compression:
rzip -9
VmPeak  345368 kB
Size34437.87 kB
bzip2 -9
VmPeak  9224 kB
Size38024.95 kB
gzip
VmPeak  1940 kB
Size50368.28 kB


De-compression:
bzip2 -d
VmPeak  5448 kB
rzip -d
VmPeak  7892 kB
gunzip
VmPeak  1940 kB

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Maintainer wanted for sys-auth/pam_mysql

[Francesco Riosa]

Sune Kloppenborg Jeppesen wrote:
sys-auth/pam_mysql is without an active maintainer and has an open security bug 
#120842


https://bugs.gentoo.org/show_bug.cgi?id=120842

Anyone willing to take care of this package in the future, please update 
metadata/herd info and CC yourself on the bug.




pam-mysql 0.7RC1 added to the tree, the package now belong to the 
"mysql" herd, still need to look in depth at the patches 
"pam_mysql-0.6_md5_openssl.patch" and "pam_mysql-0.6_md5_sasl2.patch", 
these, temporary have _not_ been applyed.


rgds, Francesco Riosa
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Heritage

[Francesco Riosa]

Chris Gianelloni wrote:

On Wed, 2006-05-10 at 00:55 -0400, Curtis Napier wrote:

Grant Goodyear wrote:

Curtis Napier wrote: [Tue May 09 2006, 09:49:27PM CDT]

Larry our wonderful mascot is from a font collection that we DO NOT OWN
THE COPYRIGHT TOO. Our esteemed ex-architect STOLE Larry. Legally
speaking we have no rights to use Larry whatsoever and if the owner of
the copyright ever stumbles onto gentoo.org and sees it we are looking
at a big fat lawsuit.

Both Jon and I (separately) addressed this earlier, but I'm pretty sure
that although we don't own the copyright to Larry, the font it is from
has a license that allows us to use it freely.  If you have evidence to
the contrary, please let me know, and I'll see what I can do to obtain
any necessary rights.

-g2boojum-

I don't see a license for it anywhere. If we have a copy it would
probably be best to have it somewhere easily accessible. Putting it in
the images directory on the website makes sense.


I have a copy of the font.

It is ©2000 Ethan Dunham ‐ Fonthead Design ‐ http://www.fonthead.com



And in any case it's easy to create your own taking the idea from the 
original, but without copying it, see attachment.

Re: [gentoo-dev] Re: Re: Signing everything, for fun and for profit

[Francesco Riosa]

Chris Bainbridge wrote:
> On 20/05/06, Peter <[EMAIL PROTECTED]> wrote:
> 
> 
> Thanks for the clarification. That scheme looks fine. The master
> manifest will add about ~700k to the tree, but since it can be rsynced
> the actual bandwidth usage day to day should be reasonable.
> 
rsync option for the portage tree include "--whole-file", thus making it
a full download at quite every sync.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changes to the way Java packages are built

[Francesco Riosa]

I'm surprised from the lack of "Thanks a lot Java Team", so please let
me have the honour to be the first on this ml ;-)

The work done has been impressive, the number of package involved great,
thanks _a_lot_ for all you did.

Francesco R.

-- 
gentoo-dev@gentoo.org mailing list

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

[Francesco Riosa]

2012/2/23 Andreas K. Huettel :
> 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

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

[Francesco Riosa]

2012/2/23 Johannes Huber :
> Am Donnerstag, 23. Februar 2012, 15:47:09 schrieb 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
>
> Hi Francesco,
>
> we have already kde-misc/kolor-manager in tree.

app-admin/elektra
media-gfx/icc_examin
media-gfx/lprof (only if ported to lcms2)
media-gfx/xcm
media-libs/oyranos
x11-libs/libXcm

I'm thinking about these

and also the synnefo project mentioned before (yet TODO)


> Greetings,
> --
> Johannes Huber (johu)
> Gentoo Linux Developer / KDE Team
> GPG Key ID F3CFD2BD

Re: [gentoo-dev] Deprecate EAPI1?

[Francesco Riosa]

2012/3/11 Ciaran McCreesh :
> On Sun, 11 Mar 2012 09:52:40 -0400
> Rich Freeman  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 :
> 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  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
>

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

[Francesco Riosa]

2012/3/31 Tiziano Müller :
> 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:
>> 
>>
>> | 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: 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  wrote:
> > On Fri, 27 Apr 2012 21:12:27 +0100
> > Ciaran McCreesh  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] RFC: remove ldap from desktop profiles use flags

[Francesco Riosa]

2012/5/5 Michael Weber :
> -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: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Francesco Riosa]

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

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

[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

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

[Francesco Riosa]

+1 for verbosity

Il giorno 01/ago/2012 13:21, "hasufell"  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
>

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] 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] 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] 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 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 10/04/2017 00:20, Brian Dolbec wrote:

On Sun, 9 Apr 2017 23:36:18 +0200
Francesco Riosa  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 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] 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] 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] 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] 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.
>

[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

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

[Francesco Riosa]

2017-10-13 4:05 GMT+02:00 M. J. Everitt :

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

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] 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] [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] 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] [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] [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  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] 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] 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&sysvinit&netifrc 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] Upcoming posting restrictions on the gentoo-dev mailing list

[Francesco Riosa]

2018-01-09 22:20 GMT+01:00 Andreas K. Huettel :

> [...]



> * 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] 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

[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]
dev-python/Coffin

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

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 16/01/2018 01:40, Alec Warner wrote:
>
>
> On Mon, Jan 15, 2018 at 7:05 PM, Francesco Riosa  <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
> 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] 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] 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] [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&T 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
>
>
>

[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] 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)

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] 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] 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] 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] 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] 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] 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] 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] 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-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)
>
>