[gentoo-dev] Packages up for grabs: net-misc/sobby, net-libs/obby, net-libs/libinfinity, net-libs/net6

[Tiziano Müller]

Hi everyone,

the following packages are up for grabs since I have no use for them
anymore:

net-misc/sobby
net-libs/obby
net-libs/libinfinity
net-libs/net6

They are unfortunately not up-to-date, and 3 minor bugs are open for
net-libs/libinfinity:

https://bugs.gentoo.org/527158
https://bugs.gentoo.org/537488
https://bugs.gentoo.org/670610

Upstream seems to be still around for the editor itself (gobby, not in
the tree anymore).

If nobody picks them up, they are likely to get tree-cleaned since all
except one are libraries nobody seems to be using.

Best regards,
Tiziano

[gentoo-dev] Last rites: net-nds/gosa-* packages

[Tiziano Müller]

# Tiziano Müller  (21 Nov 2018)
# Project is in maintenance-only mode with the last big release in 2012.
# Needs a dedicated maintainer with a matching LDAP setup (extra schemas
required).
# Several open issues (#370985, #356827, #399845, #544562, #651092) and
one security
# bug (bug #66912). Therefore removal in 30 days.
net-nds/gosa-core
net-nds/gosa-plugin-mail
net-nds/gosa-plugin-samba
net-nds/gosa-plugin-systems

Re: [gentoo-dev] Hardening a default profile

[Tiziano Müller]

Hi Michael

Am 11.06.2017 um 23:39 schrieb Michael Brinkman:
>  Hello, so I've been running Gentoo Hardened for a few years on my
> laptop, my desktop, and a server made from an older desktop.
> 
> Because of Grsecurity closing access to its source to non-subscribers,
> I decided that I would just try to stick with Gentoo-sources and
> harden the default profile and follow the KSSP guidelines to get as
> close as possible without losing the testing kernel.  Because of this,
> I no longer used the PaX features and decided switch to the default
> profile and enabling my own flags.

The security people probably have more insight, but I personally run by
default the hardened profile, also in combination with gentoo-sources if
there were too many compatibility issues with the software I had to run
on that specific machine.
So, from my point of view there is no reason to switch to the default
profile just because the grsec-kernel-patchset isn't open source anymore.

Best regards,
Tiziano

[gentoo-dev] Last rites: dev-python/amara

[Tiziano Müller]

# Tiziano Müller  (10 Aug 2014)
# Bundles an old (2.0.0) and vulnerable, but modified version of expat.
# Testsuite is completely broken and upstream seems to be working on the
# next rewrite instead of fixing this one. Nothing in the tree depends on it.
# Removal in a month.
dev-python/amara

Re: [gentoo-dev] Akamai secure memory allocator for OpenSSL?

[Tiziano Müller]

Am 13.04.2014 22:42, schrieb Joshua Kinard:
> So one of the side-discussions happening after Heartbleed was the fact that
> OpenSSL has its own memory allocator code that effectively mitigates any C
> library-provided exploit mitigations (as discussed on the openbsd-misc ML at
> [1] and Ted Unangst's blogs at [2] and [3]).  This is partially why there's
> so much "interesting" data to be sniffed from a server's memory via the
> heartbleed response packets -- that memory wasn't really initialized to
> random data or zero'd upon malloc(), nor garbage-collected upon free().
>
> Taking place over on the openssl-users ML, someone from Akamai posted a new
> secure memory allocator patch[4][5] that they have been using in production
> for about a decade.  That patch was cleaned up, diff'ed against
> openssl-1.0.1g, and posted to openssl-dev here:
> https://marc.info/?l=openssl-dev&m=139733477712798&q=p5
>
> It basically provides a secure memory area protected by guard pages for
> sensitive data, like RSA private keys, so that if another Heartbleed-like
> event occurs, things won't be as bad.  Hopefully...
>
> Is this something we want to look at adding to our openssl copy via an
> optional USE flag (default off)?

Not really, no. I would rather wait until other people have reviewed
and/or it has been pulled into openssl.

To cite the Akamai dev who posted the patch [1]:
"Let me restate that: *do not just take this patch and put it into
production without careful review.*"

Best,
Tiziano

[1] http://thread.gmane.org/gmane.comp.encryption.openssl.user/51243?resub=1

Re: [gentoo-dev] New license: Adaptec

[Tiziano Müller]

Am Freitag, den 30.08.2013, 07:35 +0200 schrieb Ulrich Mueller:
> >>>>> On Fri, 30 Aug 2013, Diego Elio Pettenò wrote:
> 
> > On Thu, Aug 29, 2013 at 7:20 PM, Tiziano Müller  wrote:
> > good point, will go for ADAPTEC then instead
> 
> > Please don't.
> 
> +1
> 
> Obviously they have different licenses for different products, so if
> there's no name that identifies the license itself, then it might be
> better to use e.g. the package name instead.

It seems they use this EULA for all their downloads by now.

So, how about "Adaptec-EULA" ?

Re: [gentoo-dev] New license: Adaptec

[Tiziano Müller]

Am Donnerstag, den 29.08.2013, 13:17 +0200 schrieb Ulrich Mueller:
> >>>>> On Thu, 29 Aug 2013, Tiziano Müller wrote:
> 
> > I would like to add arcconf (binary to manage aacraid-based
> > controllers) to the tree, which is protected by a mandatory
> > clickthrough witch the attached text.
> 
> > The license would be named "Adaptec" and added to the NON-FREE
> > license group.
> 
> The license contains nasty clauses like this:
> "If you are a European Consumer you must not export Software outside
> the country in which you download it without our prior written
> permission."

In my use case that clause isn't a real problem since it's being used on
a server.

> I.e., if you install the software on your computer, you're not allowed
> to travel with it. Not sure if this would be enforceable for travel
> within the EU, but nevertheless, I suggest that you add the license to
> the @EULA group. And the ebuild needs mirror restriction, at least.

right, @EULA is what I meant (instead of NON-FREE).
Since you're not allowed to redistribute I already restricted fetch,
mirror & bindist in the corresponding ebuild.

What is interesting is that they even make you agree to that EULA for
their updated aacraid drivers which are based on the in-kernel drivers.
I suspect a GPL violation here...

> "Adaptec" was previously used for a different license:
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/licenses/Adaptec?view=markup
> So better choose another name to avoid confusion.

good point, will go for ADAPTEC then instead

[gentoo-dev] New license: Adaptec

[Tiziano Müller]

I would like to add arcconf (binary to manage aacraid-based controllers)
to the tree, which is protected by a mandatory clickthrough witch the
attached text.

The license would be named "Adaptec" and added to the NON-FREE license
group.

Objections?
ADAPTEC, INC.
DOWNLOADABLE SOFTWARE LICENSE

This License is granted by Adaptec, Inc., referred to in this License as 
"ADAPTEC" or "we" or "us." ADAPTEC reserves the right to record all activities 
and to use any information obtained in accordance with the privacy policy which 
you can access below. 

Directions to Obtain Your File:

CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS AS WELL AS THE EXPORT 
COMPLIANCE REQUIREMENTS SET OUT BELOW. YOU MUST ANSWER THE REQUIRED QUESTION 
TRUTHFULLY TO LET US KNOW WHETHER YOU HAVE READ AND UNDERSTOOD THE TERMS AND 
CONDITIONS AND EXPORT COMPLIANCE REQUIREMENTS AND WHETHER YOU AGREE TO COMPLY. 
YOU MUST CLICK A FURTHER BUTTON TO CONFIRM YOUR ANSWER AND IF YOU ANSWER IN THE 
AFFIRMATIVE, A BINDING LICENSE AGREEMENT ("LICENSE") WILL BE CONCLUDED BETWEEN 
US. YOU MAY THEN PROCEED TO DOWNLOAD THE SOFTWARE.
IF YOU DO NOT AGREE TO THESE TERMS, CONDITIONS, AND EXPORT COMPLIANCE 
REQUIREMENTS THEN DO NOT DOWNLOAD THE SOFTWARE. IF YOU WISH TO CANCEL THIS 
LICENSE AT ANY TIME YOU MAY DO SO BY DESTROYING ALL COPIES AND PARTIAL COPIES 
OF THE SOFTWARE WHICH YOU HAVE DOWNLOADED.
YOU ALSO AGREE THAT YOU HAVE ALL NECESSARY INFORMATION IN ORDER TO ENTER INTO 
THIS LICENSE WHETHER UNDER AN APPLICABLE EUROPEAN E-COMMERCE DIRECTIVE OR 
OTHERWISE. IF YOU DO NOT AGREE TO THESE TERMS, CONDITIONS, AND REQUIREMENTS, DO 
NOT DOWNLOAD ANY FILES.
Please retain a copy of the License for your files or you may contact ADAPTEC's 
Legal Department at the address listed below for a further copy. This license 
may be concluded in English or the language in which it is drafted by ADAPTEC 
and appears to you online, as applicable. If you are a consumer residing in 
Europe (a "European Consumer") then this License shall not affect your 
statutory rights under the local laws in Europe.
This License grants you a non-exclusive license to use the ADAPTEC Software and 
related documentation ("Software") on the following terms, conditions, and 
export compliance requirements: 

If you are NOT an individual consumer residing in Europe then the following 
terms, conditions and export compliance requirements apply and are a part of 
your license: ALL SECTIONS EXCEPT AS SPECIFIED HEREIN. 

If you are an individual consumer residing in Europe ("European Consumer") then 
the following terms, conditions and export compliance requirements apply and 
are made part of your License: 1, 2, 3, 4, applicable parts of 6, 7, 9 and the 
first paragraph of export compliance. IF YOU ARE A EUROPEAN CONSUMER THIS 
LICENSE SHALL NOT AFFECT YOUR RIGHTS UNDER THE STATUTORY LAWS OF EUROPE.
Your right to use the Software.You may use the Software in machine readable 
form (i.e. the form you download from us) within a single working location. You 
may copy the Software in the same form solely for back-up purposes or use 
within a single working location. You must reproduce ADAPTEC's copyright notice 
and proprietary legends. These requirements apply to European Consumers.
Restrictions. This Software contains trade secrets and in order to protect them 
you may not: (1) distribute copies of the Software in any manner, including, 
but not limited to, distribution through web site posting; (2) decompile, 
reverse engineer, disassemble, or otherwise reduce the Software to a human 
perceivable form; (3) MODIFY, ADAPT OR TRANSLATE THE SOFTWARE INTO ANY OTHER 
FORM; (4) RENT, LEASE, LOAN, RESELL FOR PROFIT, OR CREATE DERIVATIVE WORKS 
BASED UPON THE SOFTWARE OR ANY PART OF IT. These requirements apply to European 
Consumers.
Ownership. The Software is copyrighted by, proprietary to and a trade secret of 
ADAPTEC. ADAPTEC retains the title, ownership and intellectual property rights 
in and to the Software and all subsequent copies regardless of the form or 
media. The Software is protected by the copyright laws of the United States, 
the European Union, and international copyright treaties. This License is not a 
sale of the Software. These terms apply to European consumers.
Termination. This License is effective until terminated. This License will 
terminate automatically without notice if you fail to comply with any of the 
provisions. Upon termination you shall destroy all copies of the Software 
including any partial copies. This provision applies to European Consumers.
Disclaimer of Warranty. IF YOU ARE A EUROPEAN CONSUMER THEN THIS SECTION 5 DOES 
NOT APPLY TO YOU AND DOES NOT FORM PART OF YOUR LICENSE WITH US. PROCEED TO 
SECTION 6.  THE SOFTWARE IS LICENSED TO YOU "AS IS." YOU ACCEPT ALL RISKS WHICH 
MAY ARISE FROM THE DOWNLOADING OF THE SOFTWARE, INCLUDING BUT NOT LIMITED TO 
ERRORS IN TRANSMISSION OR CORRUPTION OF EXISTING DATA OR SOFTWARE. ADAPTEC 
MAKES NO WARRANTIES, EXPRESS OR IMPL

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Tiziano Müller]

Am Samstag, den 25.05.2013, 15:53 -0400 schrieb Anthony G. Basile:
> On 05/25/2013 02:13 PM, Markos Chandras wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On 05/25/2013 05:14 PM, Ben de Groot wrote:
> >> But if a co-maintainer pushes through a change that I oppose, then
> >> working together becomes quite difficult. In this case I opted to
> >> give up maintainership.
> >>
> > Ben,
> >
> > We've been working together, in the same team(s), for more than 4
> > years and we never had a single problem in co-maintaining packages. I
> > would never expected you to make so much noise because I committed a
> > file (yes a file, *not* a patch) that changes absolutely *nothing* to
> > existing users but it helps all those users who want to use systemd.
> >
> > I am very disappointed and confused.
> >
> > You should have known me better by now.
> >
> > - -- 
> > Regards,
> > Markos Chandras - Gentoo Linux Developer
> > http://dev.gentoo.org/~hwoarang
> >
> 
> We are moving too quickly on bug #448882 ([Tracker] packages not 
> providing systemd units).  We should come to better consensus on systemd 
> integration and we were getting there with the idea of INSTALL_MASK. I 
> don't know that it is a working solution yet.  I have to oppose adding 
> unit files unless we have a way to opt out for reasons I gave earlier, 
> regarding embedded systems where one needs to conserve space 
> aggressively.  And we may have found a way to do so without cluttering 
> ebuilds with USE flags.

Even though I don't care about a couple of files more on my FS I would
prefer to find a solution with functions provided by PMS, not portage
alone.

> 
> Can I ask the systemd people to design a working solution for opting 
> out?  I can't support this initiative without such a solution and I 
> would be happy to work with the systemd people to reach it, ie I'll test.
> 

Maybe we have to find a more generic solution for this, because there is
bug #235944 [1] which request extra config snippets for rsyslog added to
various packages. Or is this something different? If yes, how?

Best,
Tiziano


[1] https://bugs.gentoo.org/show_bug.cgi?id=235944

[gentoo-dev] New USE_EXPANDs for uWSGI: UWSGI_LANGUAGES, UWSGI_PLUGINS and plans for uwsgi-2

[Tiziano Müller]

Hi everyone,

the new versions of uwsgi (1.9+) support even more languages/platforms
and plugins.

Currently we do everything with common USE flags and build-in many
plugins since we didn't want to expose them right from the start to the
user (the selection is based on upstreams base configuration).

For the new version, uWSGI will support the following
languages/platforms which we would like to put in UWSGI_LANGUAGES:
python (vanilla, gevent, ugreen, stackless), ruby (rack, RoR & fibers),
perl, lua, erlang (+pyerl), php, go, java (jvm & clojure), mono,
javascript (via v8).
For some of them it is even possible to enable/disable the specific
interface (for example ruby fibers or java clojure) but if they don't
pull in additional dependencies we continue with the current approach
and build all interfaces for a language.

For the UWSGI_PLUGINS we would add the following flags:
ping, cache, nagios, rrdtool, carbon, rpc, corerouter, fastrouter, http,
ugreen, signal, syslog, rsyslog, logsocket, router_uwsgi,
router_redirect, router_basicauth, zergpool, redislog, mongodblog,
router_rewrite, router_http, logfile, router_cache, rawrouter,
router_static, sslrouter, spooler, cheaper_busyness, symcall,
transformation_tofile, transformation_gzip, gridfs,
stats_pusher_mongodb, stats_pusher_statsd, spooler, xslt
(plus some more)

While the following will remain normal USE flags:
xml, yaml, json, zeromq, ssl, pcre
since they are not plugins but general capabilities of uWSGI.

The drawback of putting for example "python" behind a UWSGI_LANGUAGES
USE_EXPAND is that someone with USE=python in make.conf does not get
python-support in uWSGI automatically but has to enable it explicitly.
On the other hand, uWSGI gets installed explicitly and people most
likely check things before installing them.

Furthermore we may want to switch to an all-plugin-based installation as
available for Debian, openSUSE, etc. as recommended by upstream [1]
(currently we're only building the language plugins as real plugins). It
doesn't really matter as much as it does for binary package distros but
it also doesn't hurt (please correct me if wrong) and this way our users
can share their configs between distros.

Ok to add those two USE_EXPANDs?

Any comments on the other plans?

Best,
Tiziano

[1] http://projects.unbit.it/uwsgi/wiki/Guide4Packagers

[gentoo-dev] Last rites: dev-libs/dv{acm4,net,ssl,thread,util}

[Tiziano Müller]

# Tiziano Müller  (21 Mar 2013)
# Masked for removal in 30 days (bug #462590). Open bugs:
# #310217, #339477, #343807, #439110
# Recent test failures in dvutil show bugs in timezone handling.
# No new release since >3 years, upstream is not responding.
# Not recommended for new development. Use C++11, boost, poco, etc instead.
dev-libs/dvacm4
dev-libs/dvnet
dev-libs/dvssl
dev-libs/dvthread
dev-libs/dvutil

Re: [gentoo-dev] Moving our/portage stuff to var

[Tiziano Müller]

Am Montag, den 17.12.2012, 11:19 +0100 schrieb Tomáš Chvátal:
> Currently we put portage into /usr/portage and all related stuff is to
> be in the subfolders there (distfiles, binpkg).
> 
> I've always myself override these defaults in make.conf to point for
> /var/portage/ (not /var/lib because I never bothered enough how to
> make world and config files to be put elsewhere :P).

I always move the stuff as well:

* /var/cache/distfiles
* /var/cache/packages ... may not be the best choice since they can't
always be regenerated
* /var/db/repositories/portage
* /var/db/repositories/... (other portage repositories)
* /var/db/paludis/repositories/... (for paludis-specific repositories,
like layman)

Tiziano

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Tiziano Müller]

Am Dienstag, den 30.10.2012, 22:48 -0700 schrieb Diego Elio Pettenò:
> On 30/10/2012 22:44, Tiziano Müller wrote:
> > I agree. It really doesn't make sense to keep unbuildable stuff in the
> > tree. The point of slotting it in the first place was also to force a
> > rebuild of reverse dependencies to have them use newer boost (since at
> > that time when boost slotting was introduced we had some API breakages
> > occurring between versions).
> > Now with the sub-slots we can simply use this feature to tell the PM to
> > rebuild the stuff.
> 
> Well, as long as the soname is correct (which it is), with
> preserved-rebuild (which is now available on ~arch Portage as well),
> this is basically already possible to some extent without even using
> subslots.
> 
> Each new minor version bump (1.49 -> 1.50) will orphan the 1.49
> libraries, @preserved-rebuild will rebuild the linked packages.
> 
> Of course for those that don't link to the objects, but only use the
> headers, the sub-slots make it possible as well.
> 

Didn't have @preserved-rebuild back then and I don't really consider
this a feature (but that's just a side note).

One reason for the slotting was also to give people developing code on
Gentoo the chance to easily have multiple versions of boost in parallel
(for testing, etc.). This was also the main reason to introduce
eselect-boost (besides making the transition to slotted boost easier ..
a transition which never really happened since everyone kept relying on
eselect-boost).
But that too stems from a time when boost got a release once a year, so
by now slotting is really just a burden.

Question is: do we want to keep the versioned soname scheme (which
doesn't make much sense without the slotting) or not.
I would like to see it removed together with the slotting.

Concerning the maintenance: I'd prefer cpp and nothing
else. The reason for this is that boost is tied to the development of
C++ itself pretty closely and we want that people who take care of boost
have enough knowledge about C++ itself.. and then: why not share your
knowledge by taking care of some other C++ packages as well.

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Tiziano Müller]

Am Dienstag, den 30.10.2012, 11:30 -0700 schrieb Diego Elio Pettenò:
> Given the amount of headaches that Boost seems to give us all, now
> thanks to the recent changes even more because Gentoo's boost is
> different from all others and no upstream default check seem to work
> correctly with it, I'm questioning the usefulness of having it slotted.
> 
> Among other things, with each GCC/GLIBC update all but a handful of
> slots are kept working; in this case I think most if not all <1.50 are
> broken.
> 
> So given that it's a PITA for the maintainers, a PITA for the users,
> eselect boost has been shown to be a bad idea and so on ... can we just
> go back to just install it and that's about it?

I agree. It really doesn't make sense to keep unbuildable stuff in the
tree. The point of slotting it in the first place was also to force a
rebuild of reverse dependencies to have them use newer boost (since at
that time when boost slotting was introduced we had some API breakages
occurring between versions).
Now with the sub-slots we can simply use this feature to tell the PM to
rebuild the stuff.
I'll also put cpp as herd for it in metadata.xml.

Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.

[Tiziano Müller]

Am Dienstag, den 28.08.2012, 09:43 +0200 schrieb hasufell:
> On 08/28/2012 06:26 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> > 
> > There needs to be a way to specify maximal accepted slot of Boost.
> > Examples of some possibilities: * BOOST_MAX_SLOT="1.49" global
> > variable * '--max 1.49' arguments for boost-utils_get_* functions
> > 
> 
> Exactly. I don't see any reason for this eclass except this feature.
> The current expected behavior of boost and build systems is that
> always the latest installed will be picked.
> 
> In fact this breaks packages in 3 of 4 cases on new boost versions.
> 
> And while we are it it, we can punt the useless eselect implementation.

boost-1.50 already removes symlinks created by eselect-boost and doesn't
depend on it anymore.

Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.

[Tiziano Müller]

Am Dienstag, den 28.08.2012, 10:06 +0200 schrieb Michał Górny:
> On Tue, 28 Aug 2012 06:26:02 +0200
> Arfrever Frehtes Taifersar Arahesis  wrote:
> 
> > 2012-08-28 00:19:28 Michał Górny napisał(a):
> > > --- /dev/null
> > > +++ b/gx86/eclass/boost-utils.eclass
> > > @@ -0,0 +1,43 @@
> > > +# Copyright 1999-2012 Gentoo Foundation
> > > +# Distributed under the terms of the GNU General Public License v2
> > > +# $Header: $
> > > +
> > > +if [[ ! ${_BOOST_ECLASS} ]]; then
> > > +
> > > +# @ECLASS: boost-utils.eclass
> > > +# @MAINTAINER:
> > > +# mgo...@gentoo.org
> > 
> > It is better to copy list of maintainers from
> > gentoo-x86/dev-libs/boost/metadata.xml.
> > 
> > > +# @BLURB: helper functions for packages using Boost C++ library
> > > +# @DESCRIPTION:
> > > +# Helper functions to be used when building packages using the
> > > Boost C++ +# library collection.
> > > +
> > > +case ${EAPI:-0} in
> > > + 0|1|2|3|4) ;;
> > > + *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> > > established." +esac
> > 
> > Please accept all EAPIs.
> 
> These are EAPIs which are allowed throughout the tree, sorry. Feel free
> to ping Council about adding non-standard EAPIs to eclasses.
> 
> > > +inherit versionator
> > > +
> > > +# @FUNCTION: boost-utils_get_best_slot
> > > +# @DESCRIPTION:
> > > +# Get newest SLOT (major version) of Boost.
> > > +boost-utils_get_best_slot() {
> > > + local pkg=dev-libs/boost
> > > + local atom=$(best_version ${pkg})
> > > + get_version_component_range 1-2 ${atom#${pkg}}
> > > +}
> > > +
> > > +# @FUNCTION: boost-utils_get_includedir
> > > +# @DESCRIPTION:
> > > +# Get correct includedir for best Boost version. Outputs the sole
> > > path +# (without -I).
> > > +boost-utils_get_includedir() {
> > > + local slot=$(boost-utils_get_best_slot)
> > > + has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> > > +
> > > + echo -n "${EPREFIX}/usr/include/boost-${slot/./_}"
> > > +}
> > 
> > There needs to be a way to specify maximal accepted slot of Boost.
> > Examples of some possibilities:
> > * BOOST_MAX_SLOT="1.49" global variable
> > * '--max 1.49' arguments for boost-utils_get_* functions
> 
> I'd rather wait with that till Tiziano expresses his opinion. I think
> the policy ought to be 'always prefer newest version' but I guess
> that's hard with boost.
> 

one of the points of having a slotted boost (besides solving the rebuild
when API/ABI breakages occur) is that a package may also use an older
boost slot (currently it only would make sense if we'd backport the
glibc-2.16 patches but that's a different story). So I'd prefer if we'd
have a BOOST_MAX_SLOT variable.

[gentoo-dev] Lastrite: app-admin/eselect-boost & Boost plans

[Tiziano Müller]

Some of you may have already noticed, that boost >=1.50.0-r1 does not
pull in eselect-boost anymore and does not install a profile for it
either. This is on purpose since app-admin/eselect-boost will be
removed.

Why: the purpose of eselect-boost was to make the introduction of
slotted-boost easier (since we wouldn't have to fix all packages at
once) and to help people using Gentoo as a development platform.
It was never the intention that Ebuilds should depend permanently on the
symlinks created by eselect-boost depending on a users selection.
Especially with EAPI-5 slot-operators the PM must be able to assume that
a package depending on boost links/uses the best version of boost
according to its dependency specification.

I apologize for not having made that clear earlier.

How to make sure your package uses latest boost (if it doesn't detect it
properly)? I'm using something like this in my ebuilds which require
boost:

BOOST_PKG="$(best_version ">=dev-libs/boost-1.40.0")"
BOOST_VER="$(get_version_component_range 1-2 "${BOOST_PKG/*boost-/}")"
BOOST_VER="$(replace_all_version_separators _ "${BOOST_VER}")"
BOOST_INC="/usr/include/boost-${BOOST_VER}"

If someone has a better idea (possibly introduce pkg-config files for
boost) and/or write/extend an eclass to handle such cases (probably
similar to the db-use.eclass) I'd appreciate a helping hand.

Further plans:

When unmasking glibc-2.16, most of the old boost versions will be broken
and old unstable boost-versions must be removed.
As soon as glibc-2.16 gets stable, boost-1.50.0 has to be stabilized and
old stable versions of boost must be removed.

Boost-1.51.0: mgorny (thanks a lot, btw) and I are working on splitted
ebuilds. The wishlist also includes switching to the cmake-based
modularized boost distribution which would make the ebuilds a lot
easier. It would also reduce the required disk-space when building and
testing.
Since 1.51 got released already, we may decide to introduce this in 1.52
and release 1.51 as usual.

At this point I'd also like to thank hwoarang, floppym and Arfrever for
their help in maintaining boost... and of course everyone participating
in testing, bug-fixing and stabilizing that beast.

Ideas? Hints? Comments?

Cheers,
Tiziano

Re: [gentoo-dev] glibc-2.16 moving to ~arch

[Tiziano Müller]

Am Samstag, den 18.08.2012, 01:44 -0400 schrieb Mike Frysinger:
> On Saturday 18 August 2012 01:16:29 Diego Elio Pettenò wrote:
> >  - everything depending on boost (current 1.49 won't work, you need
> > 1.50, and quite a few things break with 1.50);
> 
> there's a trivial patch needed to make 1.49 work.  forcing people to use 1.50 
> is purely the boost's maintainers choice.

I'm already working on some of the boost-1.49/50 breakages and 1.51 is
already in the pipeline, so 1.50 has to leave p.mask in a month or so
anyway.

> 
> >  - everything depending on gnutls (current 2.x version does not build
> > with glibc 2.16, and quite a few things don't build with gnutls 3);
> 
> there's a trivial patch long been available that you've refused to merge.  so 
> any errors here are of your choosing.
> 
> > Congrats, this is just the kind of behaviour that makes Gentoo look
> > professional... no wait I meant the other way around I guess. Because
> > the automake 1.12 breakage is not enough to have in tree, hm?
> 
> *yawn*.  don't use unstable if you want stability.
> -mike

[gentoo-dev] [gentoo-dev-announce] Last rites: net-fs/mount-cifs

[Tiziano Müller]

# Tiziano Müller  (24 Jul 2012)
# Now part of net-fs/cifs-utils & unmaintained by upstream
# Security bug #308067 and bugs #427702, #232608, #247809,
# #258409, #265183, #337691, #342783, #279074
# Removal in 30 days
net-fs/mount-cifs

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

[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  AllPartially⁴ 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:

"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


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] latest boost vs. eselected boost

[Tiziano Müller]

Am Donnerstag, den 19.01.2012, 11:50 -0500 schrieb Ian Stakenvicius:
> On 19/01/12 03:27 AM, "Paweł Hajdan, Jr." wrote:
> > On 1/19/12 9:05 AM, Johannes Huber wrote:
> >> Summary of the comments: 1) Ebuilds should always pick the latest
> >> boost version. 2) Boost should be compared to gcc, python, ruby
> >> etc
> >> 
> >> [1] https://bugs.gentoo.org/show_bug.cgi?id=335108
> > 
> > Right, Tiziano Müller's (dev-zero) comments are pretty clear that 
> > ebuilds should use latest boost.
> > 
> > I'm fine with last-riting eselect-boost, and I'm also fine with 
> > eselect-boost applying to ebuilds too, like eselect-python.
> > 
> > What I mostly care about is consistency and principle of least
> > surprise.
> > 
> 
> I thought there was a push to eventually de-slot boost?  (in which
> case this issue just disappears)
No.

> 
> Anyways, if we ARE going to keep boost slotted, we should probably
> have a mechanism within ebuilds to select the boost version that will
> be used -- simiar to/same as python and ruby (or perhaps closer to
> autotools?  unsure which paradigm best fits).  Yes, I know how much of
> a potential mess this could be and how much of a PITA it's going to be
> to do.*  I'm not sure if using eselect-boost for this would be a good
> idea, though; isn't eselect mainly just for the system?  IE, when a
> user is using boost for their own stuffs?
Yes, exactly. As I wrote in the bug: the eselect-boost module was for
the transition from unslotted to slotted boost as well as for people
doing development on Gentoo using boost.

If you want compare the boost-case to something, it's probably best
compared to sys-libs/db.

Two years ago (maybe there is a better solution by now) I used something
like this to extract the boost-include directory in an ebuild:

  BOOST_PKG="$(best_version ">=dev-libs/boost-1.35.0-r5")"
  BOOST_VER="$(get_version_component_range 1-2 "${BOOST_PKG/*boost-/}")"
  BOOST_INC="/usr/include/boost-$(replace_all_version_separators _ 
"${BOOST_VER}")"

Maybe someone can come up with a wrapper to have something like this:

  WORKING_BOOST_SLOTS="1.37 1.38 1.42 1.45"
  [...]
  DEPEND="$(slot_deps dev-libs/boost ${WORKING_BOOST_SLOTS})"
  [...]
  BOOST_SLOT="$(best_slot dev-libs/boost ${WORKING_BOOST_SLOTS})"
  BOOST_INC="$(best_slot_boost_include ${WORKING_BOOST_SLOTS})"

which could be used for other slotted libs, like sys-libs/db.

(basically a generalization of the db-use.eclass)

Cheers,
Tiziano


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog

[Tiziano Müller]

Am Freitag, den 23.07.2010, 09:06 +0200 schrieb Thomas Beierlein:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Jorge,
> 
> On Thu, 22 Jul 2010 18:04:59 +
> "Jorge Manuel B. S. Vicetto"  wrote:
> > If you want to use sqlite3 as default and assuming your prefer
> > postgres over mysql, you can use the following and drop the die from
> > pkg_setup.
> > 
> > DEPEND="
> ... snip ...
> > !bacula-clientonly? (
> > sqlite3? (
> > app-backup/bacula[-mysql.-postgres]
> > dev-db/sqlite:3
> > )
> > !sqlite3? (
> > postgres? (
> > mysql? ( app-backup/bacula[-mysql] )
> > dev-db/postgresql-base[threads]
> > )
> > !postgres? (
> > mysql? ( virtual/mysql )
> > !mysql? ( app-backup/bacula[sqlite3] )
> > )
> > !bacula-nodir? ( virtual/mta )
> > )
> ... snip ...
> > "
> 
> interesting. I did not know that an ebuild can use-depend on itself.
> Good to know.
No, not good. It doesn't make any sense.
We will have a solution for such cases somewhere in the future, but at
the moment you should just display a warning that even though the user
specified more than one db only is going to be used.

Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Tiziano Müller]

Am Montag, den 05.04.2010, 08:16 +0200 schrieb Maciej Mrozowski:
> On Sunday 04 of April 2010 17:33:17 Tiziano Müller wrote:
> 
> >>  Besides I 
> >> can already imagine PMS-related discussion regarding "make the PMs check 
> for rdeps per default before unmerging things" - thx but no thx.
> > This is not related to PMS. Paludis for example does it already with the
> > current EAPIs.
> So how does Paludis handle those issues?
> (Read my comments about "emerge" atomicy below)
> 
> > It is a problem which can _only_ be solved at the PM level. You have to
> > tell the PM when API breakages happen. Either by slotting the lib or by
> > something else.
> ^^^
> This is important - as slotting is not a practical solution. What is it then?
> 
> > Using guesswork to determine whether or not a library
> > should be removed may be a temporary solution. Remember: you're
> > partially ignoring a users request since he wanted the package to be
> > removed - and we all know how things like "protect the user from
> > himself" end up.
> 
> Unconditionally removing libraries (instead of preserving them) and making 
> their reverse runtime dependencies reinstalled is unacceptable because 
> "emerge" process involving multiple packages is not atomic. Simple as that.
A side mark: preserving libs may work in a number of cases, but there
are a lot of (possible) examples where the rdeps (and/or the preserved
libs) are nevertheless broken or become useless (think of: ui-files,
plugins, dlopen'ed libs, etc.).

Please forget your atomicity. It's a really nice idea (and I'd like to
see it too) but not possible now or in the near future.


> Is this what you suggest? Correct me if I'm wrong:
> 1. Users wants to uninstall or reinstall package, we let him do it provided 
> reverse runtime dependencies are satisfied afterwards. Let's say he wants to 
> upgrade expat.
> 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime 
> reverse deps will still be satisfied when we upgrade.
> 3. Expat has been upgraded sucessfully,
> 4a. "emerge" discovers reverse runtime dependencies are broken and it starts 
> to rebuild them, then it bails out due to error ld: libexpat.so. not 
> found. Because step 3 cannot be rolled back (no atomicy) - game over.
> or
In that case you most probably have a problem in your dep-tree (either
unspecified deps or a dep-resolver bug)

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Tiziano Müller]

Am Sonntag, den 04.04.2010, 23:44 -0700 schrieb Brian Harring:
> On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote:
> > Unconditionally removing libraries (instead of preserving them) and making 
> > their reverse runtime dependencies reinstalled is unacceptable because 
> > "emerge" process involving multiple packages is not atomic. Simple as that.
> > Is this what you suggest? Correct me if I'm wrong:
> > 1. Users wants to uninstall or reinstall package, we let him do it provided 
> > reverse runtime dependencies are satisfied afterwards. Let's say he wants 
> > to 
> > upgrade expat.
> > 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and 
> > runtime 
> > reverse deps will still be satisfied when we upgrade.
> > 3. Expat has been upgraded sucessfully,
> > 4a. "emerge" discovers reverse runtime dependencies are broken and it 
> > starts 
> > to rebuild them, then it bails out due to error ld: libexpat.so. not 
> > found. Because step 3 cannot be rolled back (no atomicy) - game over.
> > or
> > 4b. "emerge does not discover those and does nothing. python is broken so 
> > emerge cannot be used anymore. Game over
> 
> This is called 'nondeterministic resolution'- known issue also w/ 
> proposals of that sort.
> 
> Pretty much everytime someone proposes it as a solution, it gets 
> smacked down by most folk since an emerge -p invocation that is a 
> single pkg upgade shouldn't be able to go rebuild your entire world.
> 
> The alternative is a slotted ABI var- basically a counter (although it 
> doesn't have to be) w/in ebuilds themselves to indicate if they're 
> carrying a new ABI from upstream for that slotting.  For example, 
> you've got EXPAT merged w/ ABI=2, version 2.0.  version 2.0.1, for 
> whatever reason, breaks ABI- thus v2.0.1 in the tree is ABI=2.0.1 (or 
> 3, as said it's an arbitrary value).
> 
> Via that, the resolver can see that a rebuild is necessary and plan a 
> rebuild of all consumers (whether NEEDED based or revdep).  Note 
> preserve-lib would be rather useful here- specifically holding onto 
> the intermediate lib while doing rebuilding.
No, it doesn't help since you may have the same problems some people try
to solve in this thread.

>   This however breaks down 
> a bit when the ABI change is in reverse of normal versioning.
How so? Such a var should just specify the ABI and the PM only has to
check whether it changed from one PVR to the other. The "how" is
completely irrelevant.


-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Tiziano Müller]

Am Samstag, den 03.04.2010, 23:05 +0200 schrieb Maciej Mrozowski:
> On Saturday 03 of April 2010 14:16:14 Fabian Groffen wrote:
> > Shouldn't we fix that buildsystem then?  Do you have an example of a
> > package/buildsystem that does that?
> "We" already do, the thing is that maybe we don't have to.
> https://bugs.gentoo.org/show_bug.cgi?id=240323
> From top of my head: python having issues with sys-libs/db as well as some 
> packages with readline.
>  
> > > It would indeed. Now when I think about it, moving stuff to preserved
> > > library dir could be just done - provided it's possible - along with
> > > fixing/setting DT_RPATH's in reverse runtime dependencies. This way no
> > > system-wide LIBRARY_PATH's would be necessary.
> > > Is it possible? Mike?
> > No, unless you somehow make sure you reserve space for this, by e.g.
> > setting a bogus rpath entry at buildtime.  If you want to go that route,
> > you probably want to look at the Prefix' binutils-config wrapper that
> > already calls the linker with added rpath arguments.  Afterwards you can
> > use chrpath to set it to the correct location.  Will get messy with the
> > vdb though, but if Portage's doing it, it can probably be dealt with.
> Sounds messy indeed, what about hardened/SELinux/AppArmor/whatever - do they 
> allow such DT_RPATH operations? It should be probably also restricted for 
> binary-only packages.
> 
> On Saturday 03 of April 2010 20:51:43 Tiziano Müller wrote:
> > Don't fix the hack. Remove the preserve libs "feature", make the PMs
> > check for rdeps per default before unmerging things.
> This will only prevent creating orphans of uninstalled libraries, what about 
> upgraded ones when SOVERSION has been bumped (the most common case)?
I addressed this in the next phrase.

>  Besides I 
> can already imagine PMS-related discussion regarding "make the PMs check for 
> rdeps per default before unmerging things" - thx but no thx.
This is not related to PMS. Paludis for example does it already with the
current EAPIs.

> 
> > Slot libraries where needed, slot dep operators (EAPI 4) will help.
> Again, you suggest to SLOT every library that happened to bump SOVERSION. 
> It's 
> unrealistic. Besides library should be slotted when it's API changes, for 
> source based distributions it's not needed for ABI changes - let's not 
> confuse 
> those two. Also excessive slotting increases probability of breaking library 
> discovery mechanisms in various build systems (not everyone uses pkg-config).
I know that slotting can cause problems. But forcing build systems to
use specific versions of libraries is much easier than "shadowing"
libraries present in library search dirs, especially when those libs are
not even tracked by the PM.

> 
> > And if that doesn't work out we need a separate var to give the PM a hint 
> when API/ABI breakages happen (such that the PM knows when to re-install the 
> rev deps).
> It needs PMS amended and thus GLEP.
Wrong, we don't have GLEPs for >90% of the PMS changes going into EAPI-3
or 4.

>  Please submit a GLEP item for this if you 
> see it fit.
> Anyway, as explained in OT, it's not a problem of package manager 
> dependencies 
> system but issue with broken/not smart build systems - no dependency tree 
> magic will solve this issue.
It is a problem which can _only_ be solved at the PM level. You have to
tell the PM when API breakages happen. Either by slotting the lib or by
something else. Using guesswork to determine whether or not a library
should be removed may be a temporary solution. Remember: you're
partially ignoring a users request since he wanted the package to be
removed - and we all know how things like "protect the user from
himself" end up.




-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?

[Tiziano Müller]

Am Samstag, den 03.04.2010, 12:50 +0300 schrieb Petteri Räty:
> I don't think later is valid resolution. If there's a valid bug it just
> means it's never looked at again. If the bug is not valid then a
> different resolution should be used. So what do you think about
> disabling later? I would like to avoid things like this:
Yes, please remove it. Keep it simple and stupid. LATER means it's not
resolved and is as such not a valid resolution.

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

[Tiziano Müller]

Am Samstag, den 03.04.2010, 12:38 +0200 schrieb Maciej Mrozowski:
> Problem
> 
> ..is known, let me summarize briefly.
> 
> Uninstalling packages providing libraries, without checking reverse runtime 
> dependencies of those packages leaves their dependencies unsatisfied 
> (packages 
> with broken executables and/or shared libs).
> Some package managers try their best not to remove said libraries, yet 
> allowing packages to be removed.
> Those orphaned libraries cause problems[1] as build systems of some other 
> packages being (re)installed afterwards pick them up and abuse those orphaned 
> libraries. (we don't like orphans abused, we prefer them... "gone").
> 
> Solution
> 
> Now, I suppose there are some ideas how to make orphaned libraries not go in 
> a 
> way. Basically then need to be available for system, but hidden for "emerge".
> 
> There is opt-out suggestion[2], unfortunately it does not provide any info 
> how 
> exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, 
> maybe - as Brian Harring suggested - sandbox could be used to somehow "hide" 
> preserved libraries or preserved library directory from ebuild environment 
> (preserved library directory a'ka "purgatory" - libs could be moved there 
> when 
> considered orphaned).
> 
> Opt-in suggestion is as follows:
> 1. Use some library path (read by ld loader from environment) and export it 
> globally to environment pointing it to preserved library directory.
> 2. During "emerge", unset environment variable corresponding to said 
> preserved 
> library directory - orphans are no longer located.
> Attached patch for glibc (2.11, but should apply to any other glibc around) 
> and uClibc (this one is not tested but should work as well) that makes ld 
> loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable.
> 
> (LD_LIBRARY_PATH would work as well, but it's being used widely so cannot be 
> safely mangled.. on the second though it can - one could filter out preserved 
> library paths from it during "emerge").
> 
> Thoughts?

Don't fix the hack. Remove the preserve libs "feature", make the PMs
check for rdeps per default before unmerging things. Slot libraries
where needed, slot dep operators (EAPI 4) will help. And if that doesn't
work out we need a separate var to give the PM a hint when API/ABI
breakages happen (such that the PM knows when to re-install the rev
deps).


-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Add NGINX_MODULES to USE_EXPAND

[Tiziano Müller]

Hi Benedikt

Did you look at the nginx ebuild in my overlay? I already created an
ebuild with USE flags for the different features and with USE_EXPANDable
flags in mind.
Even though there are only 3 mail modules I'd prefer two USE_EXPAND
vars: NGINX_HTTP_MODULES and NGINX_MAIL_MODULES, since upstream makes a
difference between http-modules and mail-modules.

Cheers,
Tiziano

Am Donnerstag, den 04.03.2010, 21:27 +0100 schrieb Benedikt Böhm:
> Hi all,
> 
> i'd like to add NGINX_MODULES to USE_EXPAND. If there are no
> objections i will commit it end of the week.
> 
> Thanks,
> Bene
> 

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] [rfc] Making repoman/metagen check for validity of herds

[Tiziano Müller]

Am Donnerstag, den 25.02.2010, 19:06 +0100 schrieb Sebastian Pipping:
> I agree that additional repoman checks can help to improve quality in
> Gentoo...
> 
> 
> It seems that currently neither metagen nor repoman check what I put in
> for herd (i.e. if such a herd exists or not).
> 
> Does anyone feel like getting his hands on that or like teaming up on it?

Since the value for  is a distinct set of values it could be
easily done using a xsd or relax-ng schema plus XIncludes.
See http://dev.gentoo.org/~dev-zero/metadata/ for my earlier
experiments.


-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Build system output verbosity, e.g. cmake

[Tiziano Müller]

Am Sonntag, den 21.02.2010, 19:36 +0100 schrieb Fabian Groffen:
> Hi all,
> 
> Inspired by the recent poppler move from autoconf to cmake for its
> build system, the following.
> 
> Given that poppler didn't compile on at least two arches, I found that
> cmake is pretty much terse in its output, especially when errors are
> encountered.  Often it is important to know how the compiler or linker
> was invoked, to be able to (quickly) resolve the issue at hand.  Cmake
> doesn't seem to report such call by default, it needs VERBOSE=1 to be
> set in the environment in order to do so.
> 
> I recently proposed to enable this by default for cmake, but got some
> negative feedback for that.  Hence, I'd like to know the opinion of more
> people on the issue.
> 
> In the past we have had verbose build systems, that printed a lot of
> messages.  Portage even analyses this output to look for common
> problems.  Newer buildsystems (like cmake), or just newer insights (like
> gnustep makefiles, linux kernel, git, ...) suppress more messages
> leading to reduced output.
> 
> - should we leave defaults of build systems as is, keeping some very
>   verbose and others very terse?
> - should we always enable verbosity such that we can analyse logs, both
>   by Portage as well as in bugs when something apparently went wrong?
> - should make the output level consistent for all build systems?
> 
> I think verbosity is useful when debugging problems.  Portage's --jobs
> feature nicely allows to hide the "ugly" output (even with --jobs=1),
> still storing the log for when something goes wrong, while eliminating
> the need to look at it all the time.
> 
> So what do you think?  Pros, cons?
> 

Please always enable verbose (as in "show the actual gcc command line
call") output unless a build system shows the complete call in case it
failed.
Being able to attach the build log without the need to first rerun the
merge process with some flag set to get the full output is easier for
the user and therefore a good thing.
Leave the output mangling to the package manager.

Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Upstream tags in metadata.xml (GLEP 46)

[Tiziano Müller]

Am Freitag, den 05.02.2010, 11:34 +0100 schrieb Alexis Ballier:
> > Other sites I'd like to add:
> > - pypi
> > - google-code
> > - ctan ... if someone can identify a key for packages
> 
> I don't know what you exactly mean by a key, but for ctan the
> catalogue [1,2] may be what you're looking for.
> If I understood correctly, a key would be $PN and the relevant
> information found in, e.g.,
> http://texcatalogue.sarovar.org/entries/${PN}.html
> 
> Note that not all packages have version information; if they don't, one
> can probably use the date instead.
Last time I checked I didn't have the impression that ${PN} is not
enough to get a unique entry for a package on ctan.

> 
> If I remember correctly, texlive has perl scripts/libs to deal with it,
> so it may be possible to reuse them for a bumpchecker.
> 
> Also, definitely +1 for adding more sites, but I think one important
> feature is missing: simple http/ftp listing. Not all projects are
> hosted on major sites, and having a (more complicated) way of tracking
> versions based on a directory listing could be useful.
Definitely, but for http/ftp listing checks SRC_URI is probably enough.
The only thing which could make it easier is when upstream uses
sub-directories for major/minor versions (like gnome for example). In
that case something like http://ftp.gnome.org/pub/GNOME/sources/GConf
might help to find a new version easier, but I really doubt it.

But for now I'd stick to the two cases:
a) hosting sites with project numbers/ids/names where we can extract
version information in a general way
b) arbitrary download sites, in which case a bump checker could try to
find new versions by checking for a http/ftp listing or by checking the
Changelog (...) which may also be a good way to
know whether something changed at upstream (and then let the developer
decide what it was)

>  I do not know
> how to exactly implement that (maybe a regexp to match only the files
> we want and a sed/awk script to do the $tarball -> $PV pass).
> If I remember correctly debian has something like that for version
> tracking, so it may be worth having a look.
> 
> Alexis.
> 
> [1] http://dante.ctan.org/tex-archive/help/Catalogue/catalogue.html
> [2] http://texcatalogue.sarovar.org/



-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Upstream tags in metadata.xml (GLEP 46)

[Tiziano Müller]

Am Freitag, den 05.02.2010, 20:16 +0300 schrieb Peter Volkov:
> В Чтв, 04/02/2010 в 22:37 +0100, Tiziano Müller пишет:
> > The upstream tags are meant as a way to track information about
> > - id of a hosting or indexing site (automated version bump checks)
> 
> Does there exist any scripts for this?
> 
Not that I know of. I once started working on one.

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Upstream tags in metadata.xml (GLEP 46)

[Tiziano Müller]

Am Donnerstag, den 04.02.2010, 22:37 +0100 schrieb Tiziano Müller:
> While some people already discovered the upstream metadata tags, there
> are only 8 ebuilds using them so far. Mostly I am to blame for that,
> since I forgot to send out a proper announcement. While all the required
> information can be found in the Developer Handbook [1], here is a short
> summary:
> 
> The upstream tags are meant as a way to track information about
> upstream, like:
> - the upstream status (can make treecleaners lives easier)
> - online documentation links (a shortcut for the user)
> - not-so-obvious contact/bug-reporting information
> - id of a hosting or indexing site (automated version bump checks)
> - their alignment (mostly chaotic-neutral ;-)
> 
> An example (copied from GLEP 46 [2] itself):
> 
> 
> Foo Bar
> f...@bar.bar
> 
> 
> Foo Gentoo
> f...@gentoo.org
> 
> http://foo.bar/changelog.txt
> http://foo.bar/doc/index.html
> http://foo.bar/doc/index.de.html
> https://bugs.foo.bar
> foobar
> foobar
> 
> 
> Please note:
> - the  tag in  is only for specifying an upstream
> maintainer name and e-mail address and does not specify the ebuild
> maintainer (although it may be the same if you decide to become
> upstream).
> - the type attribute for  is currently one of (freshmeat|
> sourceforge|cpan|vim), send a mail to gentoo-dev before adding
> additional sites
> - the data in the  tags is an id which uniquely identifies
> the project on that site:
> - for type="vim": the script_id (example: 2586)
> - for type="freshmeat": the project name (example: aria2)
> - for type="sourceforge": the project name (example: liferea)
> - for type="cpan": the module name (example: Pod-Index)

Other sites I'd like to add:
- pypi
- google-code
- ctan ... if someone can identify a key for packages

Opinions?

Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

[gentoo-dev] Upstream tags in metadata.xml (GLEP 46)

[Tiziano Müller]

While some people already discovered the upstream metadata tags, there
are only 8 ebuilds using them so far. Mostly I am to blame for that,
since I forgot to send out a proper announcement. While all the required
information can be found in the Developer Handbook [1], here is a short
summary:

The upstream tags are meant as a way to track information about
upstream, like:
- the upstream status (can make treecleaners lives easier)
- online documentation links (a shortcut for the user)
- not-so-obvious contact/bug-reporting information
- id of a hosting or indexing site (automated version bump checks)
- their alignment (mostly chaotic-neutral ;-)

An example (copied from GLEP 46 [2] itself):


Foo Bar
f...@bar.bar


Foo Gentoo
f...@gentoo.org

http://foo.bar/changelog.txt
http://foo.bar/doc/index.html
http://foo.bar/doc/index.de.html
https://bugs.foo.bar
foobar
foobar


Please note:
- the  tag in  is only for specifying an upstream
maintainer name and e-mail address and does not specify the ebuild
maintainer (although it may be the same if you decide to become
upstream).
- the type attribute for  is currently one of (freshmeat|
sourceforge|cpan|vim), send a mail to gentoo-dev before adding
additional sites
- the data in the  tags is an id which uniquely identifies
the project on that site:
- for type="vim": the script_id (example: 2586)
- for type="freshmeat": the project name (example: aria2)
- for type="sourceforge": the project name (example: liferea)
- for type="cpan": the module name (example: Pod-Index)

Regards,
Tiziano



[1]:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4
[2]: http://www.gentoo.org/proj/en/glep/glep-0046.html


-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30



smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

[Tiziano Müller]

The proper replacement for such interactive notifications when called in
pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
Thus I'd keep them around until then.

Cheers,
Tiziano

Am Sonntag, den 17.01.2010, 22:38 +0200 schrieb Petteri Räty:
> With GLEP 42 and proper logging of e* messages I think we shouldn't
> annoy users any more with ebeep or epause so attached is a patch only
> defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
> keep these around for EAPI 3? If not I will apply the attached patch.
> 
> Regards,
> Petteri

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Election for the Gentoo Council empty seat

[Tiziano Müller]

Am Freitag, den 25.12.2009, 19:09 +0100 schrieb Tobias Scherbaum:
> Am Dienstag, den 15.12.2009, 23:36 -0100 schrieb Jorge Manuel B. S.
> Vicetto:
> > nomination: December 17th to 30th
> 
> I'd like to nominate dev-zero.

And I accept, thanks.

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] client/server consistency: USE flags / split packages

[Tiziano Müller]

Am Mittwoch, den 04.11.2009, 18:44 +0300 schrieb Peter Volkov:
> Hi. How do we handle packages that provide client, server, and possibly
> extra tools/libraries? Do we split packages like binary distros do or do
> we use USE flags? What USE flags? Currently some packages are split
> other use client, server or minimal USE flag(s).
> 
> Back in 2006 similar problem was discussed many times with no final
> resolution - it was hard to ban split packages since portage had no
> support for USE deps. Also some packages started to utilize 'minimal'
> USE flag to force users read USE flag description and thus reduce its
> usage and lower number of bugs due to not-installed parts of package.
> 
> With EAPI=2 both use deps and USE defaults (if necessary) are here so
> it's possible to introduce some guidelines:
> 
> 1. do not split packages; use USE flags and USE deps.
> 2. stop using minimal USE flag to build client or sever only.
> 
> 
> So are there any good reasons to split packages?

In environments with a staging server and binary packages, yes.


-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] [rfc] layman-global.txt, repositories.xml, layman, overlays.gentoo.org

[Tiziano Müller]

Am Mittwoch, den 30.09.2009, 18:17 +0200 schrieb Sebastian Pipping:
> Ciaran McCreesh wrote:
> > Sure. Just periodically fetch the repository centrally. Have a master
> > list of sync URLs with expected repository names, and use that to
> > generate the full master list that includes metadata.
> > 
> > Added bonus: you can quickly remove any repository that no longer
> > exists.
> 
> How long do you want the time frame for add-meta-data-or-get-kicked
> to be?  If half the repos don't not make it will kicking them help
> anybody?
Yes, then they're not maintained. And unmaintained overlays tend to
contain even more broken ebuilds than others.

>   What if that metadata format changes later or is extended by
> additional required entries?
How about using the power of xml and version the schemas? As long as the
metadata-file specifies the respective dtd/xsd/relaxng you know exactly
how to validate (and parse) it and may apply a xsl-trafo if necessary to
convert it to a new format on the fly. As long as you keep using xml you
can then change the complete format in a new schema version.


-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] [rfc] layman-global.txt, repositories.xml, layman, overlays.gentoo.org

[Tiziano Müller]

Am Mittwoch, den 30.09.2009, 17:57 +0200 schrieb Sebastian Pipping:
> Fabian Groffen wrote:
> > Point remains that it looks in-consistant, for repo, name is an
> > attribute, while for owner it is a sub-element.  Why having attributes
> > in the first place anyway?
> 
> It's closer to the original layman-global.txt which also makes the
> converter scripts simpler (and faster) than the element approach.  I
> think it's just right.
Then you're doing something wrong in your converter script because that
would be a simple change.
A simple rule of thumb is: use attributes for values with predefined
contents, use elements otherwise. So, make "name" an element please.

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] [rfc] layman-global.txt, repositories.xml, layman, overlays.gentoo.org

[Tiziano Müller]

Am Montag, den 28.09.2009, 20:23 +0200 schrieb Sebastian Pipping:
> repositories.xml
> =
>  name="sping"
>   quality="experimental"
>   status="unofficial">
> Gentoo overlay of Sebastian Pipping
> http://git.goodpoint.de/?p=overlay-sping.git
> 
>   sebast...@pipping.org
>   Sebastian Pipping
> 
> git://git.goodpoint.de/overlay-sping.git
> http://git.goodpoint.de/?p=overlay-sping.git.git;a=atom
>   
> =

What is the reason that "name" is an attribute? While quality, status
and type have a distinct set of allowed values, name doesn't and I'd
therefore set it as an element instead.

How about adding an attribute "lang" to  to be able to give
descriptions in different languages?

Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

[Tiziano Müller]

Am Samstag, den 22.08.2009, 02:23 -0400 schrieb Andrew D Kirch:
> Tiziano Müller wrote:
> > As you can see currently, most time is needed to implemente the features
> > in portage. It therefore doesn't make sense to make the EAPI process
> > even faster. On the other hand, I think it would make sense to have a
> > separate group developing new EAPIs instead of the council.
> >
> > Cheers,
> > Tiziano
> 
> I agree with what's being said here.  The previous council ran into a
> huge road block with EAPI and GLEP's.  I think that EAPI's should be
> moved to the Portage herd,
Portage just happens to be one of the package managers to implement the
specs afterwards. Since you agree with me about implementation taking
too long a pretty easy conclusion is that the portage team is already
understaffed so moving even more responsibility/work there makes the
whole process even slower. (Besides the fact of not including other
package manager devs in the process, but guessing from your earlier
comments you don't care about that.)

>  and GLEPs assigned as necessary until final
> approval or dissent is given by the council.
And you moaned about bureaucracy earlier today? Interesting.


-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

[Tiziano Müller]

Am Samstag, den 22.08.2009, 01:54 +0100 schrieb AllenJB:
> From what I've seen here, at least part of the problem here stems from
> the fact that this feature won't be considered until EAPI-4, and that
> means it might be a long way off yet. This, in my mind, raises the
> question of whether the current PMS/EAPI process is too slow in certain
> circumstances and could it be modified to speed things up when deemed
> necessary?
> 
> Could there be room for "fast track" EAPI's to be considered on some
> occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with the
> "package.* as directory in profiles" feature included?
> 
> If this is a matter of what the council has decided, would a simple
> solution be to have a motion for amendment / fast-track of EAPI2.1 (or
> alternative solution) brought up and voted on by the council?

As you can see currently, most time is needed to implemente the features
in portage. It therefore doesn't make sense to make the EAPI process
even faster. On the other hand, I think it would make sense to have a
separate group developing new EAPIs instead of the council.

Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

[Tiziano Müller]

Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill:
> On Wed, 12 Aug 2009 19:46:56 +0100
> Ciaran McCreesh  wrote:
> 
> > On Wed, 12 Aug 2009 20:41:30 +0200
> > Tomáš Chvátal  wrote:
> > > Also we should allow the stuff as directory thingus (portage already
> > > handles it right).
> > 
> > That's a seperate thing that needs EAPI control. You'll need to propose
> > it for EAPI 4 if you want that.
> 
> Why is that (seriously curious, not disagreeing)?  Portage has supported this
> for quite a while now.  Does the current PMS disallow it?
> 
> What I've really wanted for a long time is different package.mask files for
> different types of masks.  eg.
> 
> package.mask/broken.mask (qa.mask?)
> package.mask/removal.mask
> package.mask/security.mask
> package.mask/testing.mask

To avoid collision with the current package.mask I'd prefer
package.mask.d/ for the directory. Also makes the transition easy since
we can generate package.mask out of the files in package.mask.d/.

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] 2009 Council Elections

[Tiziano Müller]

Am Sonntag, den 28.06.2009, 20:46 +0100 schrieb George Prowse:
> Ciaran McCreesh wrote:
> > On Sun, 28 Jun 2009 19:31:43 +0100
> > George Prowse  wrote:
> >>  > This strengthening bridge of understanding can be seen in dev-
> >>  > zero's move to appoint ciaranm as his proxy for today's council
> >>  > meeting.
> >>
> >> If a doctor loses his right to practice medicine you dont allow him
> >> to speak on the board of a hospital
> > 
> > Coming from you, George, that's rather rich... Also, I would like to
> > remind you that the Council's decision was everything to do with the
> > rules not allowing a non-developer to proxy (a claim which has yet to
> > be substantiated), and nothing to do with the attempts of a small number
> > of malcontents that anything involving me, Paludis or Exherbo is so
> > amazingly evil that it must be entirely ignored.
> > 
> I'm sure getting personal about subjects on a Gentoo mailing list will 
> endear yourself to everyone.
> 
> Thinking logically for a second, if you really cared about Gentoo you 
> would have tried your best to be good and nice in the... I dunno, 4 
> years(?) since your ejection and then worked your way up to being a 
> developer again.
> 
> Trying to get into Gentoo by proxy (heh, see what I did there?) is the 
> wrong way

Please read my mail at
http://archives.gentoo.org/gentoo-dev/msg_1c0cf45c2d4619441c964163b787a11e.xml
for that.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] 2009 Council Elections

[Tiziano Müller]

Am Sonntag, den 28.06.2009, 21:35 +0530 schrieb Nirbheek Chauhan:
> On Sun, Jun 28, 2009 at 9:10 PM, Roy Bamford wrote:
> > Oh. Don't talk about 'common sense' GLEP39 does not mention it, so it
> > doesn't count ... and its much rarer than you may think.
> >
> 
> I would like to make a stand for more usage of common sense and
> "wisdom" in interpretation of rules. It more often than not makes for
> more sensible and useful decisions.

Well, Gentoo became (or always was) a multi-cultural project and what I
see is that common sense really depends on one's cultural background.
Therefore I'd say it doesn't hurt to just write something down in case
of ambiguity.

> 
> To this end, I advocate the following TED talk:
> http://www.ted.com/index.php/talks/barry_schwartz_on_our_loss_of_wisdom.html
> 
> From Donnie's twitter status[1] from a while back, I take it he would
> agree as well.
> 
> > Lastly, as a trustee and partly legally responsible for decisions made
> > on behalf of Gentoo, I am uneasy with the concept of non developers
> > making those decisions. Now reread my 'what if' above with that
> > liability in mind.
> >
> 
> This is an interesting point that I doubt many here would have thought of.
> 
> 
> 1. http://twitter.com/dberkholz/status/2345098446

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] 2009 Council Elections

[Tiziano Müller]

Am Sonntag, den 28.06.2009, 16:40 +0100 schrieb Roy Bamford:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 2009.06.28 10:00, Tiziano Müller wrote:
> > Am Freitag, den 26.06.2009, 07:15 -0600 schrieb Denis Dupeyron:
> > > On Fri, Jun 26, 2009 at 6:46 AM, Ben de Groot
> > wrote:
> > > > To appoint as proxy for a council meeting someone who has been
> > booted
> > > > from Gentoo is a clear lapse of judgement, and would in my eyes
> > > > disqualify the involved council member from functioning in that
> > position.
> > > 
> > > As Petteri noted it's not obvious that GLEP39 disallows choosing a
> > > non-dev as proxy for a council meeting. I haven't talked to 
> > Tiziano,
> > > and I don't know what he had in mind when he chose ciaranm as his
> > > proxy, but I'd be ready to believe part of it was that he wanted to
> > > experiment.
> > Well, it was surely not an experiment to see whether someone must be 
> > a
> > dev or not to be a proxy. Based on GLEP 39 it was fairly clear to me
> > this must not be the case and I at least expected the council to
> > accept
> > him (or any other non-dev) at least for that meeting.
> > 
> [snip]
> > -- 
> > Tiziano Müller
> > Gentoo Linux Developer, Council Member
> > Areas of responsibility:
> >   Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
> > E-Mail   : dev-z...@gentoo.org
> > GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30
> > 
> 
> Its my opinion that the concept of proxies in council meetings is 
> fatally flawed.  

As I stated in at least one mail before (and in countless discussions on
IRC): I'd like to see the proxy-concept being removed since it is flawed
as you point out below and replaced with something like "a council
member may miss N meetings with M of them without prior notice"
And then remove that slacker mark as well and just say: "if you miss
more than those N meetings or miss M meetings without prior notice you
get kicked". And for those who like the slacker mark to see who has
missed a lot of meetings or missed meetings repeatedly we could have a
statistics summary on proj/en/council with the number of missed meetings
per member.

Cheers,
Tiziano

> 1. The brief (if any) that the proxy is given by the council member 
> being proxied is never made public. 
> 
> 2. Its never clear if the proxy is voting as instructed by the council 
> member or as they see fit at the time.
> 
> What if an entire meeting and therefore any votes were staffed by 
> entirely by non gentoo developer proxies?
> Unlikely, but perfectly possible under GLEP39. Would Gentoo feel bound 
> by decisions that such a meeting reached?
> 
> Oh. Don't talk about 'common sense' GLEP39 does not mention it, so it 
> doesn't count ... and its much rarer than you may think.
> 
> Lastly, as a trustee and partly legally responsible for decisions made 
> on behalf of Gentoo, I am uneasy with the concept of non developers 
> making those decisions. Now reread my 'what if' above with that 
> liability in mind.
> 
> Note: Other trustees may have a different view of the world
> 
> - -- 
> Regards,
> 
> Roy Bamford
> (NeddySeagoon) a member of
> gentoo-ops
> forum-mods
> treecleaners
> trustees
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (GNU/Linux)
> 
> iEYEARECAAYFAkpHjtYACgkQTE4/y7nJvavn9gCgt5tw0IaT8GRdh2w0nY+RskZF
> H2YAoMgphYWUOp4bVMl8TWp0Qy1nTzjI
> =aR8L
> -END PGP SIGNATURE-
> 

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] 2009 Council Elections

[Tiziano Müller]

Am Freitag, den 26.06.2009, 07:15 -0600 schrieb Denis Dupeyron:
> On Fri, Jun 26, 2009 at 6:46 AM, Ben de Groot wrote:
> > To appoint as proxy for a council meeting someone who has been booted
> > from Gentoo is a clear lapse of judgement, and would in my eyes
> > disqualify the involved council member from functioning in that position.
> 
> As Petteri noted it's not obvious that GLEP39 disallows choosing a
> non-dev as proxy for a council meeting. I haven't talked to Tiziano,
> and I don't know what he had in mind when he chose ciaranm as his
> proxy, but I'd be ready to believe part of it was that he wanted to
> experiment.
Well, it was surely not an experiment to see whether someone must be a
dev or not to be a proxy. Based on GLEP 39 it was fairly clear to me
this must not be the case and I at least expected the council to accept
him (or any other non-dev) at least for that meeting.

When I had to choose a proxy I basically went through the list of people
I worked together and from which I know their opinions and they know
mine. That would have been: dertobi123 and maekke, one a council member
already, the other one unavailable at the time I looked for a proxy.
Then there was tanderson who wasn't sure whether he has to proxy for
another council member already and ciaranm who was present in most
meetings, knows my opinion, can distinguish between his opinion and mine
and worked on EAPI-3.

I'm sorry when I offended some council members and other developers with
that decision but guessing from the last discussions on #-council
between Ciaran and other council members I really didn't expect such an
animosity.

For the claim that Exherbo-people undercut Gentoo: I don't care about
what someone is doing in their freetime. I would also accept an Ubuntu
dev, a Red Hat developer, drobbins or even Bill Gates as a council
member if they'd invest enough time in Gentoo.
I personally don't care about Exherbo, I'm neither a dev nor a user and
the same thing goes for Funtoo. If nothing bad happens I will organize
the booth again at the next Open Expo in September (hopefully together
with dertobi123 and maekke), investing my personal time and money again
to show people what Gentoo is about and I will also continue to promote
Gentoo/Prefix at the University (where I'm working on a large
installation on a big server) and I will continue to use Gentoo for an
Embedded Project with hopefully over 3000 deployed systems within the
next two years.

Furthermore I only care partially about someones past. People change all
the time and they deserve more than one chance. If I would show the same
averseness to some devs I had fights with in the past as people do to
Ciaran I couldn't work with them now.

>  And experiments sometimes succeed, or sometimes they fail,
> but they often teach you something. I wouldn't be as fast as you to
> remove Tiziano from the list of people I'd vote for.
Thanks :)


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Gentoo Council Reminder for June 25

[Tiziano Müller]

Am Montag, den 22.06.2009, 15:18 -0400 schrieb Thomas Anderson:
> (This is late because I was traveling and dev-zero is/was on devaway.)
> 
> This is your friendly reminder! Same bat time (typically the 2nd & 4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
> 
> If you have something you'd wish for us to chat about, maybe even vote
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> list to see.
> 
> For more info on the Gentoo Council, feel free to browse our homepage:
> http://www.gentoo.org/proj/en/council/
> 
> 
> Attached is the preliminary meeting agenda.

Agenda looks fine, thanks Thomas for taking it over but I simply didn't
have time to do it before I left for my holidays.

Cheers,
Tiziano


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Re: [packagekit] Inviting you to project "PackageMap"

[Tiziano Müller]

Am Freitag, den 12.06.2009, 11:54 +0200 schrieb Sebastian Pipping:
> Richard Hughes wrote:
> > I'm slightly worried about it being called a service. Is it going to
> > be a new process that just does the mapping or is this a bad choice of
> > words? If it is a new process then I'm not sure such a thing will
> > catch on.
> 
> I'm not yet sure about how a mapper will keep it's data
> fresh as the use of it is dependent on that.
> Ignore my "service" for now.
> 
> 
> > I'm also worried that a package manager has to read in and parse
> > thousands of small files.
> 
> While you mention "package manager" - with the current concept
> the data will not be precise enough for use with a package manager.
> 
> 
> > Why did you decide to write each project as
> > a single xml file?
> 
>  - The other 99% of the database stay valid XML if a single
>file is invalid
> 
>  - To better fit the version controlled environment
> 
> 
> > Parsing and reading 10,000 files (in multiple directories) might take
> > a few seconds, and would have to be copied into memory (few Mb) to
> > query quickly.
> 
> Correct.
> 
> 
> > Which has to be invalidated if any of the files or
> > directories change. Why didn't you just put them in a sqlite database
> > that can be queried in a few ms, without dragging in an xml parser?
> > Also 10,000 files take up way more space (and takes longer to install
> > and update) than a single database file.
> 
> I like your idea about sqlite.  Maybe keeping the data to edit XML
> and query and sqlite export snapshot is something to try.
Why not use a XML database like dbxml?
Maybe you could just specify the XML files as storage and then dbxml
would do the rest.


> 
> 
> > XML might be
> > useful for storing the data, but not for querying.
> 
> Good point.

Using XPath and XQuery you can do queries on XML as well.

Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Tiziano Müller]

Am Dienstag, den 09.06.2009, 21:00 -0500 schrieb Doug Goldstein:
> On Thu, Jun 4, 2009 at 5:26 PM, Tiziano Müller wrote:
> > This is your friendly reminder! Same bat time (typically the 2nd & 4th
> > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> > irc.freenode.net) !
> >
> > If you have something you'd wish for us to chat about, maybe even vote
> > on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> > list to see.
> >
> > For more info on the Gentoo Council, feel free to browse our homepage:
> > http://www.gentoo.org/proj/en/council/
> >
> >
> > Following is the preliminary meeting agenda.
> >
> >
> > EAPI 3: Short discussion of the progress
> > 
> >
> > zmedico will provide an update on the progress of the implementation. Short
> > discussion of problems and implementation decisions if needed.
> 
> I'd say let's involve all the package manager maintainer groups. Each
> packager manager can have a rep speak on their behalf and we can plow
> through this topic fairly quickly.
Sure, one prominent maintainer of an alternative package manager is
usually around during meetings. But since the more complex features are
already implemented in kdebuild and paludis supported kdebuild, we're
really waiting for support in our official package manager. I don't know
about the state of pkgcore though.

> >
> >
> > Default ACCEPT_LICENSE
> > --
> > Goal: A possible default value for ACCEPT_LICENSE has been proposed. Decide
> > whether that's ok. What happens to the X11 license files (one for each app)?
> 
> In virtually all situations MIT has been used for the X11 license,
> which should be sufficient enough for us. The previously proposed
> defaults for ACCEPT_LICENSE all looked reasonable to me.
> 
> >
> >
> > Bash-4 in EAPI-3
> > 
> > Goal: A request has been made to allow bash-4.0 features in EAPI-3. Decide
> > first whether or not to open the EAPI-3 feature list at all.
> 
> No. bash-4 has seen some regressions and some oddities. 24 patches in
> and its starting to seem remotely sane, except the problem is it does
> not have wide scale adoption yet. I expect to see a lot of patches
> coming. Additionally, EAPI-3 has been an ongoing thing long enough.
> The more we keep pushing this off the more items should be shuffled
> in. We decided what EAPI-3 was a long time back. Stick with that.
> EAPI-4 can be the bases of bash-4 support.
Well, that's my opinion as well. But since there was an official request
for this we have to decide on it.

> 
> >
> >
> > Define EAPI development/deployment cycles
> > -
> >
> > Goal: Start discussion about EAPI development/deployment. For example:
> > Collect problems of eapi introductions in the past, like reverting
> > ebuilds to former eapis to get them stable, not waiting for the pm
> > support a certain eapi before requesting stable keywords for ebuilds
> > using the new eapi,  Collect problems of EAPI development like
> > feature-freeze, late feature removals (due to implementation problems).
> > Eventually develop a lightweight EAPI development model.
> 
> This is still something being discussed on the mailing lists and
> belongs there. Not in a council meeting.
Which mailinglist? Since council people have now pretty good experience
on what needs to be done to get an eapi ready I think it is the right
place to start the discussion.

> 
> If I am AFK during the council meeting due to being in a skiff, I have
> designated tanderson/gentoofan23 as my proxy.
> 
noted.


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[gentoo-dev] Gentoo Council Reminder for June 11

[Tiziano Müller]

This is your friendly reminder! Same bat time (typically the 2nd & 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even vote
on, let us know! Simply reply to this e-mail for the whole Gentoo dev
list to see.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/


Following is the preliminary meeting agenda.


EAPI 3: Short discussion of the progress


zmedico will provide an update on the progress of the implementation. Short
discussion of problems and implementation decisions if needed.


Default ACCEPT_LICENSE
--
Goal: A possible default value for ACCEPT_LICENSE has been proposed. Decide
whether that's ok. What happens to the X11 license files (one for each app)?


Bash-4 in EAPI-3

Goal: A request has been made to allow bash-4.0 features in EAPI-3. Decide
first whether or not to open the EAPI-3 feature list at all.


Define EAPI development/deployment cycles
-

Goal: Start discussion about EAPI development/deployment. For example:
Collect problems of eapi introductions in the past, like reverting
ebuilds to former eapis to get them stable, not waiting for the pm
support a certain eapi before requesting stable keywords for ebuilds
using the new eapi,  Collect problems of EAPI development like
feature-freeze, late feature removals (due to implementation problems).
Eventually develop a lightweight EAPI development model.



Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30
-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format

[Tiziano Müller]

 
> I look forward to the current council members ack'ing this e-mail
> (whether it be in parts or in whole) and I look forward to our Gentoo
> developer body ack'ing this e-mail to show support that they want a
> "goal oriented action taking" council and not a "delay and talk"
> council. This council has only a few short weeks remaining and now is
> the time to start reviewing candidates and seeing if they will do for
> you in the coming year what you expect a council to do.
> 
> If people like this, great. If people don't, then I can feel comforted
> that I spoke my piece about what I want to see the council become and
> people don't share the same vision as me.



-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format

[Tiziano Müller]

Am Dienstag, den 02.06.2009, 01:53 -0400 schrieb Andrew D Kirch:
> Doug Goldstein wrote:
> > All,
> >
> > The current council meetings have gotten completely out of hand for
> > weeks meetings have become nothing more then a continuation of the
> > senseless bicker-fest that have become the e-mail threads on GLEP54,
> > GLEP55, and EAPI-3 without any real progress or sense coming of them.
> > It's taken me a little bit to step up and put a stop to it but I fully
> > intend on putting a stop to it. The point of the council meetings is
> > to bring up a topic and decide on its merits whether it should be
> > brought into the Gentoo Project or not. I quote from the first line of
> > the Gentoo Council website:
> I would strongly advice that EAPI-3 and GLEP's 54/55 be dropped at least
> for the time being (at a minimum 90 days).  The argument has left any
> trappings of merit or rational behind, and has replaced them with
> religion.  As this is now a dogmatic issue a resolution cannot be
> reached at this time.
> >
> > We have all collectively failed the Gentoo Project since we have not
> > been doing this for the past several weeks.
> 
> Vigorous debate fails no one.  Religious zealotry however fails us all. 
> In recognizing that this is what's happening iwth EAPI-3, and GLEP's
> 54/55 is the first step towards moving on to a new and fair debate on
> these issues down the road.

Why are you mentioning EAPI-3 here? That topic got closed two meetings
ago.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

[Tiziano Müller]

Am Montag, den 01.06.2009, 22:29 +0200 schrieb Tiziano Müller:
> The people I'd like to nominate:
> 
> - dertobi123 ... for his solid comments, experience, common sense,
> reliability
> - halcy0n ... even though he had to resign early I hope he finds time
> again to run for council, I really enjoy working together with him and I
> appreciate his common sense
> - betelgeuse ... technically skilled and experienced
> - fmccor ... not sure whether possible or not since member of the
> trustees. But his latest comments showed experience in organizational
> tasks and that's what we need.
> Probably some more later on...

and of course I missed one of the most obvious candidates: tanderson. He
did a great job while being a secretary, now he should get the chance of
doing it as a council member.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

[Tiziano Müller]

Am Montag, den 01.06.2009, 12:17 +0200 schrieb Tobias Scherbaum:
> And here we go, these are the ones I'd like to nominate:
> 
> * dev-zero, well because ... i'd like him to be on the council again!

And I accept the nomination, thank you.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Tiziano Müller]

Am Mittwoch, den 27.05.2009, 20:55 +0100 schrieb Roy Bamford:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 2009.05.27 13:46, Ferris McCormick wrote:
> > On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote:
> > > This is your friendly reminder! Same bat time (typically the 2nd &
> > 4th
> > > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-
> > council
> > @
> > > irc.freenode.net) !
> > > 
> > > If you have something you'd wish for us to chat about, maybe even
> > vote
> > > on, let us know! Simply reply to this e-mail for the whole Gentoo
> > dev
> > > list to see.
> > > 
> > > For more info on the Gentoo Council, feel free to browse our
> > homepage:
> > > http://www.gentoo.org/proj/en/council/
> > > 
> > > 
> > > Following is the preliminary meeting agenda. First we'll have to
> > fill
> > > the empty spot. After a short upgrade on EAPI-3 implementation we
> > will
> > > discuss the removal of old eclasses, followed by our old friend 
> > GLEP
> > 55.
> > > If we still have time we can dive into the topic of general EAPI
> > > development.
> > > 
> > 
> > Because Piotr recently amended GLEP55 to provide some further
> > clarification and justification as well as to present a few
> > alternatives
> > addressing some objections people have expressed, it seems to me that
> > the GLEP55 discussion should now go something like this:
> > 
> > 1.  Approve the concept in principle (I think Piotr's examples
> > sufficiently show the need for something along the lines set out in
> > the
> > revised GLEP);
> > 
> [snip]
> > > Cheers,
> > > Tiziano
> > Regards,
> > Ferris
> > -- 
> > Ferris McCormick (P44646, MI) 
> > Developer, Gentoo Linux (Sparc, Userrel, Trustees)
> > 
> GLEP 55 still confuses the problem and the solution.
> Adding metadata to the filename is not required and is bad system 
> design practice. Its also the first step on the slippery slope to 
> adding more metadata in the future.

Ok, while thinking even more about it I have to disagree.
I agree with you that users should be mostly unaware of EAPI as such.
But I don't see ebuilds or ebuild-names as kind of a user-visible
interface the average user has to handle (even though most if not all
Gentoo users will edit or even write an ebuild at least once). Instead
he should use the package manager which hides those implementation
details. As such I don't see a problem of exporting metadata information
into the ebuild-name.



-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

[Tiziano Müller]

The people I'd like to nominate:

- dertobi123 ... for his solid comments, experience, common sense,
reliability
- halcy0n ... even though he had to resign early I hope he finds time
again to run for council, I really enjoy working together with him and I
appreciate his common sense
- betelgeuse ... technically skilled and experienced
- fmccor ... not sure whether possible or not since member of the
trustees. But his latest comments showed experience in organizational
tasks and that's what we need.

Probably some more later on...



Am Montag, den 01.06.2009, 04:25 + schrieb Jorge Manuel B. S.
Vicetto:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello fellow developers and users.
> 
> Nominations for the Gentoo Council 2009/2010 are now open for the next
> two weeks (until 23:59 UTC, 14/06/2009).
> 
> All nominations must be sent to the gentoo-dev mailing list. If you
> were nominated and want to run, you have to accept your nomination on
> the same mailing list.
> 
> Here are the rules:
> 
> * Council elections generally happen once a year
> * The council is composed of seven elected members
> * Nominations are allowed from June 1st 00H00 UTC to June 14th 23H59 UTC
> * Only Gentoo developers may be nominated
> * Anyone can nominate (nominating yourself is OK)
> * Nominees must accept their nomination before voting begins
> * Voting is opened from June 16th 00H00 UTC to June 30th 23H59 UTC
>   (there is one day of break between nominations and voting so the
> infra team has time to set up everything)
> * Only Gentoo developers may vote
> * Gentoo uses the Condorcet method of voting
> 
> The page listing all nominations is here:
> http://www.gentoo.org/proj/en/elections/council-200906-nominees.xml
> 
> If you don't know what the Gentoo Council is, you can read about it here:
> http://www.gentoo.org/proj/en/council/
> 
> If you want to ask a question or share your thoughts, contact any of
> the election officials:
> 
> Jorge Manuel B. S. Vicetto (jmbsvicetto)
> Łukasz Damentko (rane)
> Roy Bamford (neddyseagoon)
> Shyam Mani (fox2mike) will be doing infra magic.
> 
> You can send us an e-mail (gentoo-elections at gentoo dot org) or find
> us on Freenode (#gentoo-elections, #gentoo-dev, so on).
> 
> For the elections team,
> 
> - --
> Regards,
> 
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
> Gentoo- forums / Userrel / Devrel / SPARC / KDE
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkojWCIACgkQcAWygvVEyAKcBQCgi7CbK2zTX8y/FqDvTUfsN2l4
> ig4AoI6cI1m8dlTXRKtfYyTUfGBMvhZC
> =72eQ
> -END PGP SIGNATURE-

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Tiziano Müller]

Am Donnerstag, den 28.05.2009, 09:23 +0200 schrieb Patrick Lauer:
> On Thursday 28 May 2009 07:46:36 Tiziano Müller wrote:
> 
> > And here is why (I'm only looking at the non-degenerated case with valid
> > metadata, ignoring overlays which some consider a corner case (I don't
> > understand that argument, but that's another thing)):
> 
> overlays tend to come without metadata. Just enabling the KDE overlay changed 
> the time for "emerge -upNDv world" from ~30 seconds cold cache to ~120 
> seconds. Running emerge --metadata gets the performance back to pretty much 
> the old levels.
> 
> > When the package manager looks at a package, it first reads the
> > package's ebuild directory and gets the mtimes. It does the same for the
> > cache entries and validates the caches (there is more stuff in here,
> > like checking eclasses and so on).
> Eclasses are negligible because you only have to look at them once for the 
> whole caclulation. You can cache the mtime for the duration of your operation.
> 
> > Then the following happens based on the "solution" we choose:
> > eapi-in-filename: the package manager starts from the highest version
> > with a supported eapi (the others are inexistant with the used glob).
> > For that ebuild it reads the cache entry and decides whether or not it
> > can be used. 
> In this case you amusingly do NOT want to cache the eapi in the cache, so you 
> can even defer sourcing the ebuild until you actually need the metadata.
by "whether or not it can be used" I meant "keyword-like", surely not
eapi-like since you already know it at that point.

> (You don't want to cache it because you need to check the file mtime anyway, 
> and then you read the filename anyway. No need to look for it in another 
> place 
> then :) )
> > If not, it proceeds to the next version, if yes, it's done.
> > eapi-in-ebuild: the package manager reads all cache entries and sorts
> > out those with an EAPI it doesn't support. The rest gets ordered and the
> > same procedure as above applies.
> >
> > So, one of the main differences is: "reading one cache file" (if running
> > unstable you can asssume you support the highest version, thus reading
> > only one cache file) vs. "reading all cache files".
> That assumes a dumb cache format. 
> Why don't we make the cache more efficient so you read one file per package / 
> category / ... ?
> 
> >
> > I did some performance measurements based on that. I have 1507 installed
> > packages with 5541 different versions/revisions.
> >
> > Reading from hot cache:
> > 1507 files: ~50ms
> > 5541 files: ~170ms
> >
> > Reading from cold cache:
> > 1507 files: ~2.8s
> > 5541 files: ~6s
> And now you need to pull metadata for dependency calculation. How big is the 
> impact of that?
The 1507 files are the complete dep-tree cache entries for the highest
version, where the 5541 files are all the cache entries for all packages
in dep-tree.
I did say that I simplified the case a lot, didn't I? :)

> 
> >
> > I made a lot of assumptions here (neglecting seek between ebuild-dir and
> > metadata-dir, other processes using the drive, 80 ebuilds from overlays
> > where the ebuild would have to be read, etc.). But estimating from the
> > numbers above I'd say that a "emerge -uD world"/"paludis -i world" will
> > be at least twice as slow, which I think is not acceptable.
> I find that quite acceptable. As long as we're using such a bad layout the 
> performance is secondary.
... and I don't :)

> 
> To fix the performance you'd "only" have to guarantee that the repo is 
> unchanged (readonly), so you can add lots of simple caches/indexes - no need 
> to source any ebuild for metadata again, one cachefile for eapi if you want 
> ... I bet you find lots of small improvements that that would yield. Much 
> more 
> impressive than managing to avoid a few open() here and there ...
> 
> 
> > And I also don't understand your point of stating it's "bad design".
> Bad design is like smelly feet. It's hard not to notice ...
> 
> > I mean: when coding you should "not optimize prematurely", but with
> > eapi-in-ebuild it is against the other principle of "not pessimize
> > prematurely" (Sutter/Alexandrescu: C++ Coding Standards).
> If you quote that try the full quote:
> 
> "We should forget about small efficiencies, say about 97% of the time: 
> premature optimization is the root of all evil."
> 
> In other words, we should not try to make that path faster when we can avoid 
> hitting it at all with a small design revision.
> 
Which you still failed (after one year or so) to provide a nice cleanly
written document for.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Tiziano Müller]

Am Dienstag, den 19.05.2009, 19:01 +0200 schrieb Ulrich Mueller:
> >>>>> On Mon, 18 May 2009, Ciaran McCreesh wrote:
> 
> > On Mon, 18 May 2009 06:59:36 +0200
> > Ulrich Mueller  wrote:
> >> AFAICS, there _is_ an ambiguity. You can have the following two
> >> ebuilds in the tree, simultaneously:
> 
> >>${PORTDIR}/app-misc/foo/foo-1a-scm.ebuild
> >>${PORTDIR}/app-misc/foo-1a/foo-1a-scm.ebuild

> [Added some context back to your quotation of my posting.]
> 
> > There's no ambiguity. It means what we define it to mean.
> 
> Maybe it's possible to do that for dependencies, but VDB entries and
> binary packages for above two examples would still collide.
> 
> So the conclusion still stands:
> 
> >> The conclusion is that GLEP 54 in its current form is not
> >> implementable.
> 
> Hyphens within PV are a Bad Thing, and we should really think about
> replacing the separator for "scm" by something else, like a period or
> an underscore. For example, the following two would be unique:
> 
> ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
> ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
you probably mean:
${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild

but how would their vdb or binpkg names be unique?

vdb for example:
app-misc/foo-1a_live for app-misc/foo
app-misc/foo-1a_live for app-misc/foo-1a

am I missing something?

> 
> With our current versioning scheme the rule is very simple: ${P} is
> split into ${PN} and ${PV} at the last hyphen. This can be done in a
> straight forward way by regexp matching, and I would really hate to
> lose this nice property.

I don't understand why this property is important. Can you please
explain?


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Tiziano Müller]

es and validates the caches (there is more stuff in here,
like checking eclasses and so on).
Then the following happens based on the "solution" we choose:
eapi-in-filename: the package manager starts from the highest version
with a supported eapi (the others are inexistant with the used glob).
For that ebuild it reads the cache entry and decides whether or not it
can be used. If not, it proceeds to the next version, if yes, it's done.
eapi-in-ebuild: the package manager reads all cache entries and sorts
out those with an EAPI it doesn't support. The rest gets ordered and the
same procedure as above applies.

So, one of the main differences is: "reading one cache file" (if running
unstable you can asssume you support the highest version, thus reading
only one cache file) vs. "reading all cache files".

I did some performance measurements based on that. I have 1507 installed
packages with 5541 different versions/revisions.

Reading from hot cache:
1507 files: ~50ms
5541 files: ~170ms

Reading from cold cache:
1507 files: ~2.8s
5541 files: ~6s

I made a lot of assumptions here (neglecting seek between ebuild-dir and
metadata-dir, other processes using the drive, 80 ebuilds from overlays
where the ebuild would have to be read, etc.). But estimating from the
numbers above I'd say that a "emerge -uD world"/"paludis -i world" will
be at least twice as slow, which I think is not acceptable.

And I also don't understand your point of stating it's "bad design". I
mean: when coding you should "not optimize prematurely", but with
eapi-in-ebuild it is against the other principle of "not pessimize
prematurely" (Sutter/Alexandrescu: C++ Coding Standards).



-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] New app-eselect category?

[Tiziano Müller]

Am Dienstag, den 26.05.2009, 17:00 -0700 schrieb Josh Saddler:
> AllenJB wrote:
> > I'd favor tags over increasing the category
> > levels, tho I'm not convinced either is necessary at the current time
> > (tho tags might make searching easier, in some ways).
> 
> Heck yes! Tags are a good idea. The idea's been raised on -dev a few
> times. I suppose they're not (yet) essential, but from a user point of
> view, if the tools supported searching for tags buried in metadata.xml,
> it would make life much, much nicer.

And with the risk to repeat myself: herds can already been seen as tags.
So, my proposal still stands: change the current herds into teams and
write them in metadata.xml as such:


  cpp


and then using  as tags.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

[Tiziano Müller]

Am Montag, den 04.05.2009, 22:01 +0100 schrieb Sérgio Almeida:
> Gentoo Dev's,
> 
> My name is Sérgio Almeida, I am Portuguese and I am a student for this
> year's Google SoC coding the Universal Select Tool project for Gentoo
> being Sébastien Fabbro (bicatali) my mentor.
> 
> Abstract:
> 
> Universal Select Tool is an utility to manage system configuration.
> This tool is similar to the unmaintained eselect utility of Gentoo or
> Exherbo's eclectic. The idea is to create a tool that  manages both
> system settings and user settings with profile creation possibilities.
> The utility will use mostly concepts from "modules", "softenv", and
> both "eselect" and "eclectic".
> 
> My initial proposal does not get in-depth with implementation details
> and I need to make some decisions as soon as possible. Implementation
> language will be python as it is easy to maintain, easy to code and
> faster and more flexible than bash. See attachment for more details.
> 
> Besides introducing myself, the purpose of this e-mail is a
> call-to-ideas to all Gentoo developers, mainly all eselect-* and
> *-config developers.
> 
> Here are the main interest ideas:
> 
> * keep eselect structure of modules - actions
> 
> * symlinking, environment and aliases actions can consist of something
> like:
> 
> # module moo comments
> description "Example Module description"
> version "Example Module Version"
> author "m...@farm.moo"
> # action system moo
> description "Moo Action Description"
> symlink "regexp" "regexp"
> env "regexp" "regexp"
> alias "regexp" "regexp"
> # end moo
> 
> These should get the job done for most of the modules and opens the door
> to automatic module creation prior to a successful emerge (if some USE
> flag set)
> 
> * Actions that consist of code blocks that support any scripting
> language (what about binaries?) to do more complex actions (full module
> example):
> 
> # module moo comments
> description "Example Module description"
> version "Example Module Version"
> author "m...@farm.moo"
> 
> # action user moo
> description "Example Module will moo for any user"
> type runnable
> runner /bin/bash
> # file moo.bash
> #!/bin/bash
> do_moo() {
>   echo "This is the Example Module mooing"
> }
> do_moo()
> # end moo.bash
> # end moo
> 
> * actions can be run system-wide and per-user:
> # action user moo
> # action system moo
> 
> * automatic module loading and profile management can be managed by some
> env.d python scripts that are user-aware and follow some database
> 
> I've been given this difficult task of unifying all of these tools
> together and as you all can understand, I won't be having the time to
> read through all eselect-* modules and *-config utilities code.
> 
> Please drop me a line here or at freenode if you have anything to add to
> these ideas or have any further ideas that can help me on this project.
> Thank you all in advance.

What I'd like to see is the possibility to
... localize messages (will be difficult since modules need translations
as well, but maybe you find a way :)
... encapsulation of methods to set/list/change such that instead of a
CLI- a NCurses- or GUI-Frontend could be developed.

Cheers,
Tiziano



-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[gentoo-dev] Gentoo Council Reminder for May 28

[Tiziano Müller]

This is your friendly reminder! Same bat time (typically the 2nd & 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even vote
on, let us know! Simply reply to this e-mail for the whole Gentoo dev
list to see.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/


Following is the preliminary meeting agenda. First we'll have to fill
the empty spot. After a short upgrade on EAPI-3 implementation we will
discuss the removal of old eclasses, followed by our old friend GLEP 55.
If we still have time we can dive into the topic of general EAPI
development.


Approval/voting of new council member replacing Donnie Berkholz
---

Unfortunately Donnie resigned as a member of the council (for
details please read his mail on the g-council ml). Next in line
are ulm and ssuominen.


EAPI 3: Short discussion of the progress


zmedico will provide an update on the progress of the implementation. Short
discussion of problems and implementation decisions if needed.


Removing old eclasses
-

Goal: Decide whether developers are allowed to remove eclasses. Problem:
Upgrading using portage with a version before 2.1.4 will fail since portage
always used eclasses from the tree instead of the ones from environment.bz2,
even though the environment fail has been generated. Portage 2.1.4 got stabled
over a year ago.


Handling EAPI versioning in a forwards-compatible way
-

Goal: Discuss whether one of the alternatives given in GLEP 55 is appropriate
to solve the problem. Decide which one should be chosen.


Define EAPI development/deployment cycles
-

Goal: Start discussion about EAPI development/deployment. For example:
Collect problems of eapi introductions in the past, like reverting
ebuilds to former eapis to get them stable, not waiting for the pm
support a certain eapi before requesting stable keywords for ebuilds
using the new eapi,  Collect problems of EAPI development like
feature-freeze, late feature removals (due to implementation problems).
Eventually develop a lightweight EAPI development model.


Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] RFC: GLSA-2, a new DTD for GLSAs

[Tiziano Müller]

Am Dienstag, den 26.05.2009, 16:19 +0200 schrieb Robert Buchholz:
> Hello,
> 
> the Security Team would like to create a new DTD for our GLSAs. GLSAs 
> are distributed via our web site and the tree. Their format is defined 
> by a DTD.
> 
> When the format was initially defined in 2004, some use cases were 
> considered that never got implemented or used. Other use cases only 
> came up later. For this reason, we want to update the GLSA for the 
> needs of 2009. Since this includes changes that make existing GLSAs 
> invalid we are going to introduce a new DTD called glsa-2.dtd.
> 
> I would like to announce the changes we want to introduce. If you have 
> any feedback, please speak up. This can include feature requests.
Maybe add a 'tag' attribute to the reference link to give them a
meaning, like:
...

or keeping a table of tags in the XSL and replace it on transformation:
Upstream Bug 1234

not sure whether uri would be the right point for such stuff though.

>  After 
> this discussion, we would like to freeze the DTD and ask all consumers 
> of GLSA XML files (such as package managers) to implement said changes. 
> The first GLSA using the new DTD will be at the earliest six weeks 
> after the DTD was frozen. Once the new GLSA format is in use, we are 
> going to convert some or all of the existing GLSAs to use the format.

I wouldn't do that since a properly written tool should be able to
handle both versions anyway.

> 
> Find the existing DTD here:
> http://dev.gentoo.org/~rbu/glsa-2/glsa.dtd
> 
> The new DTD here:
> http://dev.gentoo.org/~rbu/glsa-2/glsa-2.dtd
> 
> And a diff between them here:
> http://dev.gentoo.org/~rbu/glsa-2/glsa-2.dtd.diff
> 
> Here's a list of changes:
> 
> (-) Dropping of the product type. GLSAs will be used solely to announce
> security issues in the Portage Tree. The "infrastructure" 
> and "informational" product type are not needed and the type 
> attribute will be dropped altogether.
> (-) Dropping of service tag. Same rationale as above, if we
> drop "infrastructure", we do not need the service tag.
> (-) Drop the 'name' attribute to unaffected. This is not implemented in 
> glsa-check or Portage 2.2 and it was never part of our Policy to mix 
> GLSAs with package moves or similar.
> (+) SLOT support. An implied attribute 'slot' to the 'vulnerable' 
> and 'unaffected' tag will be introduced. This limits the scope of 
> the range specifiers to ebuilds in the specified slot. The default 
> is '*' meaning all slots.  [1]
I don't think this is really a good idea since the version may or may
not be tied to a slot (at the moment it is in most cases I know).

Looks good so far.


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] New app-eselect category?

[Tiziano Müller]

Am Dienstag, den 26.05.2009, 09:04 +0200 schrieb Ulrich Mueller:
> As of today, app-admin contains 179 packages.
> We could move the 27 eselect-* packages to a new app-eselect category
> (eselect itself would stay in app-admin).
> 
> Opinions?

Yes in general. Maybe think about what happens when the Universal Select
Tool gets released/used. Possible alternative: app-select?

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Tiziano Müller]

Am Sonntag, den 24.05.2009, 20:04 +0200 schrieb lx...@sabayonlinux.org:
> 
> On Sun, May 24, 2009 at 7:03 PM, Ciaran McCreesh 
>  wrote:
> > On Sun, 24 May 2009 19:04:08 +0200 (CEST)
> > lx...@sabayonlinux.org wrote:
> >> app-admin/equo (sabayon overlay -- Entropy Framework client) supports
> >> the postfix "@repository" to let users force the installation of a
> >> package from a specific repository.
> >
> > @ is used by Portage for sets. Paludis has been using ::repo for repo
> > dependencies for years. Why not go with the established syntax?
> 
> I wrote "postfix" not "prefix". Sets use "@" prefix.
> Regarding your "why", why not going through GLEP and gentoo-dev acceptance ;) 
> ?
> 
> >
> >> Users of multiple repositories seem to appreciate the freedom that is
> >> brought with this small-but-effective(TM) feature.
> >
> > Note that Portage doesn't support multiple repositories, so this one's
> > probably not very straight-forward... It supports overlays, which means
> > only one thing is ultimately visible for a c/p-v.
> 
> I know.
> 
> >
> > --
> > Ciaran McCreesh
> >
> 
> I am wondering if enabling @overlay postfix support could be just restricted 
> to command line arguments, at least for the beginning.

And then it's a pm thing. So the person you want to talk about it is
zmedico.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Re: EAPI Changes

[Tiziano Müller]

Am Sonntag, den 17.05.2009, 11:11 -0600 schrieb Ryan Hill:
> On Fri, 15 May 2009 23:31:25 +0200
> Tiziano Müller  wrote:
> 
> > Wrong. For example:
> > - stuff like docompress may change the content being installed depending
> > on the package manager
> > - --disable-static (maybe in a later EAPI) changes content
> > - slot-dep-operators change the rdepend of installed packages, so it
> > changes how the package manager has to handle reverse packages on
> > uninstall (in EAPI 3)
> 
> None of which are a problem when changing the EAPI from 0 to 1, which is the
> situation here. The first two examples fall under the currently established
> guideline of revbumping when content changes (and I emphasize guideline).  I
> don't see how the third example is any different than adding or removing
> dependencies, which also does not require a revbump.
Which is mostly wrong as well since a change in dependency means that
the currently installed stuff may break if a package (the new dependency
for example) gets removed and since the package you changed does not
reference it, it gets broken (for example if you had a magic dep before
and add it now as an explicit dep). So, unless you're doing a pkgmove
it's a dangerous thing since the PM can't reliably track reverse deps
when doing uninstalls since it has to use the vdb entry for that,
doesn't it?

>   So I'd argue that an
> EAPI change does not require a revision bump in and of itself.
EAPI may imply a decent implicit change to the ebuild and therefore
needs a rev-bump as per the manual.

>   That's not to
> say it shouldn't be done if the situation allows, or you have any doubts, or
> just because you want to. But unconditionally putting an ebuild through full
> ~arch to stable cycle because you added a simple SLOT dependency or a + to a
> USE flag is bureaucratic nonsense.
> 
> > And we also always said that a rev bump should be done on non trivial
> > changes or non-build-fixes and changing the EAPI is technical seen
> > mostly a non-trivial change.
> 
> As above, it depends on the situation.  0 -> 1 is a trivial change.
> 
> > Do we want to document the following? (do we have already?)
> > - When is it allowed to use an EAPI in the tree (given as offset to the
> > release of portage supporting that eapi)
> > - When is it allowed to use an EAPI in the stable tree (given as offset
> > of when a portage version supporting that EAPI got stable)
> 
> As soon as a version of portage supporting that EAPI is available.
And how much time a portage with a new EAPI got stabled?
(see for example early python eapi bumps)

> 
> This is the entire point of the EAPI, that we don't have to wait X amount of
> time before using new features.  If the user hasn't updated portage yet, they
> simply won't see ebuilds which use the new EAPI.
> 
> We may want to document a suggested waiting time before removing ebuilds
> using older EAPI's.  For example, should we always keep an EAPI 0 ebuild in
> stable as a fallback?  Or if the user tries to install or update a package
> where all versions are masked by EAPI, should (does?) portage suggest updating
> itself?
It would maybe suggest to update to an unstable version of portage, not
so good then?

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Tiziano Müller]

Am Sonntag, den 17.05.2009, 01:50 +0100 schrieb Ciaran McCreesh:
> On Sun, 17 May 2009 00:35:45 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
> > As for ciaranm's argument that you're restricting changes to the
> > version string, say allowing -rc where _rc is now required, one-time
> > restriction of a year or two, yes.  However, if the spec is crafted
> > such that the EAPI must be checked FIRST
> 
> ...then the package manager has to inspect the metadata for every
> version of a package before it can do anything, rather than just
> starting at the best version and working downwards until it finds
> something usable, which is a pretty hefty price to pay.
> 

... if the cache can be parsed at all. With GLEP-55 we might even choose
to change the cache format.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] EAPI Changes

[Tiziano Müller]

Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty:
> William Hubbs wrote:
> > On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
> >> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
> >>> Thanks Robin for finally pushing this in the tree, just didn't find the
> >>> time to.
> >>>
> >>> Maybe it's a good time to emphasize this: Keep in mind that changing the
> >>> EAPI in an ebuild requires a revision bump (including reset to unstable
> >>> keywords, etc.).
> >> That's going to cause a large problem.
> > 
> >> The entire point is that the STABLE ebuilds need to be changed,
> >> otherwise they will try to depend on the libusb-1 series (and fail
> >> dismally).
> > 
> >> For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
> >> then I see no reason that a slot dep change cannot be just put in with
> >> the EAPI change. (The same cannot be said for EAPIx -> EAPI2, as further
> >> changes are needed for that case).
> >  
> >  As far as I know, the only time you need to do a rev bump and reset to
> >  unstable is if you change the files that are installed by the package.
> > 
> >  So, as far as I know, unless you are migrating to an EAPI that is not
> >  stable or changing the files that are installed by the package, it is
> >  not necessary to do a rev bump just for changing the EAPI as long as
> >  you make sure that the ebuild emerges fine under the new EAPI.
> > 
> 
> Indeed there's no problem switching EAPIs as long as a stable Portage
> supports the EAPI you are migrating to. Portage was buggy with this when
> EAPI 2 was introduced but that has since been fixed.

Wrong. For example:
- stuff like docompress may change the content being installed depending
on the package manager
- --disable-static (maybe in a later EAPI) changes content
- slot-dep-operators change the rdepend of installed packages, so it
changes how the package manager has to handle reverse packages on
uninstall (in EAPI 3)

On the other hand you also have to make sure you have a stable portage
for a time long enough so mostly everyone has it installed. Otherwise
you could break users systems pretty badly depending on the packages.
And Arch-Teams usually do a pretty good job in catching such cases.

And we also always said that a rev bump should be done on non trivial
changes or non-build-fixes and changing the EAPI is technical seen
mostly a non-trivial change.

Do we want to document the following? (do we have already?)
- When is it allowed to use an EAPI in the tree (given as offset to the
release of portage supporting that eapi)
- When is it allowed to use an EAPI in the stable tree (given as offset
of when a portage version supporting that EAPI got stable)

Cheers,
Tiziano


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] libusb-1/libusb-compat landing - testing and DEPEND changes needed

[Tiziano Müller]

gt; media-tv/linuxtv-dvb-apps/linuxtv-dvb-apps-1.1.1.20080113.ebuild
> media-tv/linuxtv-dvb-apps/linuxtv-dvb-apps-1.1.1.20080317.ebuild
> media-video/isight-firmware-tools/isight-firmware-tools-1.2-r1.ebuild
> media-video/isight-firmware-tools/isight-firmware-tools-1.4.1.ebuild
> net-dialup/umtsmon/umtsmon-0.8.ebuild
> net-dialup/umtsmon/umtsmon-0.9.ebuild
> net-misc/dahdi-tools/dahdi-tools-2.1.0.2.ebuild
> net-misc/zaptel/zaptel-1.2.18.ebuild
> net-misc/zaptel/zaptel-1.2.18-r1.ebuild
> net-misc/zaptel/zaptel-1.2.24.ebuild
> net-misc/zaptel/zaptel-1.2.26-r1.ebuild
> net-misc/zaptel/zaptel-1.2.27.ebuild
> net-print/hplip/hplip-2.8.6b.ebuild
> net-print/hplip/hplip-2.8.7.ebuild
> net-print/hplip/hplip-3.9.2.ebuild
> net-print/mtink/mtink-1.0.11.ebuild
> net-wireless/bluez/bluez-4.28.ebuild
> net-wireless/bluez/bluez-4.38.ebuild
> net-wireless/bluez/bluez-4.39.ebuild
> net-wireless/bluez-utils/bluez-utils-2.25-r1.ebuild
> net-wireless/bluez-utils/bluez-utils-3.25.ebuild
> net-wireless/bluez-utils/bluez-utils-3.27.ebuild
> net-wireless/bluez-utils/bluez-utils-3.28.ebuild
> net-wireless/bluez-utils/bluez-utils-3.28-r1.ebuild
> net-wireless/bluez-utils/bluez-utils-3.30.ebuild
> net-wireless/bluez-utils/bluez-utils-3.32.ebuild
> net-wireless/bluez-utils/bluez-utils-3.36.ebuild
> net-wireless/wispy-tools/wispy-tools-2006.03.1.ebuild
> net-wireless/wispy-tools/wispy-tools-2006.09.1.ebuild
> net-wireless/wispy-tools/wispy-tools-2009.02.1.ebuild
> sci-geosciences/gpsbabel/gpsbabel-1.3.6.ebuild
> sci-geosciences/qlandkartegt-garmindev/qlandkartegt-garmindev-0.1.0.ebuild
> sci-geosciences/qlandkartegt-garmindev/qlandkartegt-garmindev-0.1.1.ebuild
> sci-geosciences/qlandkartegt-garmindev/qlandkartegt-garmindev-0.2.0.ebuild
> sci-geosciences/qlandkarte/qlandkarte-0.7.3.ebuild
> sci-geosciences/qlandkarte/qlandkarte-0.7.4.ebuild
> sci-libs/indilib/indilib-0.5.ebuild
> sci-libs/libticables2/libticables2-1.2.0.ebuild
> sys-apps/hal/hal-0.5.11-r4.ebuild
> sys-apps/hal/hal-0.5.11-r8.ebuild
> sys-apps/hal/hal-0.5.12_rc1-r2.ebuild
> sys-apps/hal/hal-0.5.12_rc1-r3.ebuild
> sys-apps/hal/hal-0.5.12_rc1-r4.ebuild
> sys-apps/hal/hal-0.5.9.1-r3.ebuild
> sys-apps/ifd-gempc/ifd-gempc-1.0.3.ebuild
> sys-apps/ifd-gempc/ifd-gempc-1.0.4.ebuild
> sys-apps/ifd-gempc/ifd-gempc-1.0.5.ebuild
> sys-apps/lomoco/lomoco-1.0-r1.ebuild
> sys-apps/lomoco/lomoco-1.0-r2.ebuild
> sys-apps/pcsc-lite/pcsc-lite-1.4.102.ebuild
> sys-apps/pcsc-lite/pcsc-lite-1.4.2.ebuild
> sys-apps/pcsc-lite/pcsc-lite-1.4.4.ebuild
> sys-apps/pcsc-lite/pcsc-lite-1.4.99.ebuild
> sys-apps/pcsc-lite/pcsc-lite-1.5.2.ebuild
> sys-apps/pcsc-lite/pcsc-lite-1.5.3.ebuild
> sys-apps/usb_modeswitch/usb_modeswitch-0.9.4.ebuild
> sys-apps/usbutils/usbutils-0.73.ebuild
> sys-apps/usbutils/usbutils-0.80.ebuild
> sys-apps/usbutils/usbutils-0.82.ebuild
> sys-auth/thinkfinger/thinkfinger-0.2.2-r1.ebuild
> sys-auth/thinkfinger/thinkfinger-0.3.ebuild
> sys-auth/thinkfinger/thinkfinger-0.3-r1.ebuild
> sys-fs/owfs/owfs-2.7_p4.ebuild
> sys-libs/libchipcard/libchipcard-3.0.4.ebuild
> sys-libs/libchipcard/libchipcard-4.2.4.ebuild
> sys-libs/libchipcard/libchipcard-4.2.5.ebuild
> sys-libs/libchipcard/libchipcard-4.2.7.ebuild
> sys-power/nut/nut-2.0.5-r2.ebuild
> sys-power/nut/nut-2.2.2.ebuild
> sys-power/nut/nut-2.4.1.ebuild
> sys-power/nut/nut-2.4.1-r1.ebuild
> sys-power/sispmctl/sispmctl-2.7.ebuild
> x11-misc/ifpgui/ifpgui-0.10.8.ebuild
> xfce-extra/xfce4-cellmodem/xfce4-cellmodem-0.0.5.ebuild
> 

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for May 14

[Tiziano Müller]

Updated meeting agenda can be found here:

http://dev.gentoo.org/~dev-zero/council/meeting-agenda-20090514.txt

Changes:
- Added the issue of removing old eclasses to the list.

Cheers,
Tiziano

Am Sonntag, den 03.05.2009, 23:47 +0200 schrieb Tiziano Müller:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
> 
> If you have something you'd wish for us to chat about, maybe even vote
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> list to see.
> 
> For more info on the Gentoo Council, feel free to browse our homepage:
> http://www.gentoo.org/proj/en/council/
> 
> Following is the preliminary meeting agenda. It consists of two EAPI-3
> related topics as well as two almost rusty topics where we should
> finally make a decision to be able to move on.
> 
> 
> EAPI 3: Short discussion of the progress
> 
> 
> zmedico will provide an update on the progress of the implementation.
> Short discussion of problems and implementation decisions if needed.
> 
> 
> EAPI 3: PMS approval
> 
> 
> Goal: Approve EAPI-3 extension of the PMS. Any open questions should be
> on the mailing list before the meeting.
> 
> 
> GLEP 54: Dealing with live SCM packages
> ---
> 
> Goal: Since no consensus is reached or progress has been made voting
> seems appropriate.
> 
> 
> Handling EAPI versioning in a forwards-compatible way
> -
> 
> Goal: Since no consensus is reached vote on the implementation for the
> problem solved in GLEP 55.
> 
> 
> Handling static libraries more flexibly
> ---
> 
> Goal: Decision-making by consensus. 
> Should we move forward with USE=static-libs to control 
> building of static libraries? Should/Must this be an EAPI feature?
> 
> 
> Define EAPI development/deployment cycles
> -
> 
> Goal: Start discussion about EAPI development/deployment. For example:
> Collect problems of eapi introductions in the past, like reverting
> ebuilds to former eapis to get them stable, not waiting for the pm
> support a certain eapi before requesting stable keywords for ebuilds
> using the new eapi,  Collect problems of EAPI development like
> feature-freeze, late feature removals (due to implementation problems).
> Eventually develop a lightweight EAPI development model.
> 
> 
> Cheers,
> Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for May 14

[Tiziano Müller]

Am Montag, den 04.05.2009, 07:50 -0700 schrieb Donnie Berkholz:
> On 08:34 Mon 04 May , Thomas Anderson wrote:
> > On Mon, May 04, 2009 at 02:06:47PM +0300, Petteri R??ty wrote:
> > > Isn't it second and fourth Thursday?
> > > 
> > > Regards,
> > > Petteri
> > > 
> > 
> > That's an oversimplification. That varies because of when we have some
> > holidays and skip meetings, throughing the schedule off. It's easiest to
> > remember it as every other thursday.
> 
> As a rule, it is the 2nd and 4th Thursday of each month. This is 
> announced in every meeting email.
> 
> Of course there are occasional exceptions, but they are exceptions and 
> not the rule. I don't see why this would be one because I haven't heard 
> anything about next week being bad.

Well then, let it be May 14 and consider this an early agenda post :)


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Retiring

[Tiziano Müller]

Am Montag, den 04.05.2009, 15:35 +0300 schrieb Markos Chandras:
> On Monday 04 May 2009 14:50:56 Ferris McCormick wrote:
> > On Mon, 4 May 2009 04:34:20 -0400
> [..]
> > I've been a developer a bit over 5 years.  We know the problems and are
> > working to fix them.
> >
> I am sure that you know them. But those problems are the reasons why more and 
> more developers are demotivated and leaving Gentoo. 'Fixing' those problems 
> should be a N1 priority on every gentoo council meeting until they are gone. 
> There is absolutely no point in trying to introduce new features and stuff 
> when 
> we are so understaffed. First we need to bring more people on Gentoo and keep 
> the current manpower motivated. When we are done with that, we can focus on 
> features :\

The point of most features is to make maintenance easier and reduce
breakages at user-side which hopefully reduces the amount of bugs
reported because of such breakages and keep our users happy and happy
users are more likely to contribute or become devs when they see some
progress.
But you're right, we have to find the balance somehow...


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for May 7

[Tiziano Müller]

Am Montag, den 04.05.2009, 00:25 +0100 schrieb Roy Bamford: 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 2009.05.03 22:47, Tiziano Müller wrote:
> > This is your friendly reminder! Same bat time (typically the 2nd & 
> > 4th
> > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council 
> > @
> > irc.freenode.net) !
> > 
> >
> [snip]
> 
> Tiziano,
> 
> The 7th is the first Thursday this month.  Has there been a change to 
> the meeting dates ?

We usually have the meeting every two weeks, so the next meeting would
be the next Thursday. Unless someone has objections I'd propose to hold
the meeting then.
I guess I have to change the template a little :)

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[gentoo-dev] Gentoo Council Reminder for May 7

[Tiziano Müller]

This is your friendly reminder! Same bat time (typically the 2nd & 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even vote
on, let us know! Simply reply to this e-mail for the whole Gentoo dev
list to see.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/

Following is the preliminary meeting agenda. It consists of two EAPI-3
related topics as well as two almost rusty topics where we should
finally make a decision to be able to move on.


EAPI 3: Short discussion of the progress


zmedico will provide an update on the progress of the implementation.
Short discussion of problems and implementation decisions if needed.


EAPI 3: PMS approval


Goal: Approve EAPI-3 extension of the PMS. Any open questions should be
on the mailing list before the meeting.


GLEP 54: Dealing with live SCM packages
---

Goal: Since no consensus is reached or progress has been made voting
seems appropriate.


Handling EAPI versioning in a forwards-compatible way
-

Goal: Since no consensus is reached vote on the implementation for the
problem solved in GLEP 55.


Handling static libraries more flexibly
---

Goal: Decision-making by consensus. 
Should we move forward with USE=static-libs to control 
building of static libraries? Should/Must this be an EAPI feature?


Define EAPI development/deployment cycles
-

Goal: Start discussion about EAPI development/deployment. For example:
Collect problems of eapi introductions in the past, like reverting
ebuilds to former eapis to get them stable, not waiting for the pm
support a certain eapi before requesting stable keywords for ebuilds
using the new eapi,  Collect problems of EAPI development like
feature-freeze, late feature removals (due to implementation problems).
Eventually develop a lightweight EAPI development model.


Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for April 23

[Tiziano Müller]

Am Mittwoch, den 22.04.2009, 23:21 -0700 schrieb Donnie Berkholz:
> On 15:27 Fri 17 Apr , Donnie Berkholz wrote:
> > On 15:17 Fri 17 Apr , Donnie Berkholz wrote:
> > > If you have something you'd wish for us to chat about, maybe even vote
> > > on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> > > list to see.
> > 
> > I've got a few items pending that I would like to propose. It should be 
> > clear that there are way too many topics in this list for a single 
> > meeting, so we'll have to prioritize a bit and discuss on list in 
> > advance as much as possible.
> > 
> > Feel free to reply to this email regarding any of the below items. 
> > Please change the subject so it's easier to parse through the 
> > subthreads.
> 
> Here is an updated agenda. I've removed a few items that I consider 
> lower priority and unlikely for us to have time for during this week's 
> meeting. Also, I added the issue about USE=static-libs because I think 
> it's important.
> 

I'd really like to see the topic about "portage changing behaviour"
being discussed since I see it as crucial for future eapi/portage/pm
development and I therefore consider it urgent as well. Furthermore it
has been deferred already once.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] PROFILE-IUSE-INJECTION implicit things (Was: PMS EAPI 3 more or less ready)

[Tiziano Müller]

Am Montag, den 20.04.2009, 13:41 +0100 schrieb Ciaran McCreesh:
> Let's see if we can keep to one thread per item here.
> 
> On Mon, 20 Apr 2009 07:14:00 +0200
> Tiziano Müller  wrote:
> > > * PROFILE-IUSE-INJECTION
> > yes, but *_IMPLICIT has to be discussed.
> 
> There are a few suggested use cases for these:
> 
> * Avoiding the need for developers to have to explicitly list ARCH in
>   IUSE. Without implicits, ARCH will be empty and USE won't contain the
>   arch flag name unless IUSE explicitly lists it. Some developers would
>   rather not list arch flags explicitly.

> * Ditto for things like USERLAND.
> 
> * People want to be able to carry on using flags like 'build' that
>   wouldn't otherwise work.

Why should those USE flags be different than others?

The user should anyway not check the ebuild if he wants to figure out
what USE flags a package supports but rather consult the PM's output
(because USE flags may also come from an eclass), so the argument of
hiding that info from the user is nil (and with USE_EXPAND_HIDDEN
userland and arch USE flags get hidden anyway as pointed out below).
So, with _IMPLICIT we would have some USE flags which don't have to be
added while some will have to be added and in the end devs who use those
vars only occasionally will always have to consult the specs.
Instead I'd prefer to be implicit about it: the use flags you use have
to be given in IUSE. One simple rule to remember...


> 
> And a few related points that people might otherwise miss:
> 
> * Listing something in IUSE does not have to mean it will show up in
>   package manager output. There are special HIDDEN variables for those.
> 
> * Without this whole stricter USE mess, [use(+)] dependencies are
>   rather crippled. You can't do [linguas_en(+)] against any existing
>   EAPI, for example.
> 


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] PMS EAPI 3 more or less ready

[Tiziano Müller]

Am Sonntag, den 12.04.2009, 20:59 +0100 schrieb Ciaran McCreesh:
> I've got the EAPI 3 branch for PMS more or less ready:
> 
> http://github.com/ciaranm/pms/tree/eapi-3
> 
> The provisional included feature list is everything that was ready
> before the deadline.
Thanks a lot for your work.
Sorry, I was quiet busy the last week with real life.

> 
> Before the next Council meeting (ideally a week before, so we've got
> time to get the questions worked out), I'd appreciate it if every
> Council member could go through each item on the list below, check its
> description in PMS (Appendix E has a handy list of links to the
> relevant text, or look for the boxed labels in the margin) and
> provisionally mark it as one of:
> 
> * critical: EAPI 3 needs to be held up until this feature is in Portage.
> 
> * yes: This feature should be in EAPI 3, but can be dropped if it turns
>   out it's going to take ages to get into Portage.
> 
> * no: This feature shouldn't be in EAPI 3.
> 
> * whatever: You have no strong opinion on whether this feature should
>   be in EAPI 3.
> 
> * query: You have questions about this feature, or you think parts of
>   it need discussion, or you've found a mistake in the PMS draft.
> 
> I'll try to address any queries as they come so people can update their
> opinions.
> 
> I'd also appreciate any review of wording features from anyone else.
> There are probably still a few holes.
> 
> Hopefully we can get a final list decided upon and provisionally
> approved by the next Council meeting, and then as soon as Portage is
> ready to go we can merge everything into PMS proper and get a signed
> approval tag as we did for EAPI 2.
> 
> Here's the list:
> 
> * PKG-PRETEND
critical.

> * SLOT-OPERATOR-DEPS
critical.

> * USE-DEP-DEFAULTS
critical.

> * DEFINED-PHASES
critical.

> * PROPERTIES
critical.

> * SRC-INSTALL
critical.

> * CONTROLLABLE-COMPRESS
no.

> * DODOC
critical.

> * DOINS
critical.

> * ANY-USE
yes.

> * BANNED-COMMANDS
yes.

> * DOEXAMPLE
whatever.
... with dodoc getting recursive behaviour I guess this is not really
critical. If portage penalizes it's users by compressing those examples,
that's their problem.

> * DOINCLUDE
yes.

> * UNPACK-EXTENSIONS
yes.

> * ECONF-OPTIONS
yes.

> * PKG-INFO
critical.

> * PROFILE-IUSE-INJECTION
yes, but *_IMPLICIT has to be discussed.

> * AA
yes.

> * KV
yes.

> * REPLACE-VERSION-VARS
critical.

> * S-WORKDIR-FALLBACK
yes.

> * UNPACK-IF-COMPRESSED
yes.

> * RDEPEND-DEPEND
critical.

> * DIE-ON-FAILURE
yes.

> * NONFATAL
yes.

> 
> Some answers to existing queries that I can remember:
> 
> * DEFINED-PHASES and PROPERTIES have to be EAPI linked because of the
>   metadata cache.
> 
> * ANY-USE is already special cased in the package manager and
>   specification. Everywhere that's using it is doing it wrong. It's
>   possible to rewrite the dep to mean same thing using an expanded
>   form, although it'll still be impossible to use it correctly if you
>   do that.
> 
> * ECONF-OPTIONS is very unlikely to break custom configure scripts. We
>   already pass various weird things through econf, so any configure
>   script that dies on unrecognised options is probably going to break
>   anyway. No-one's managed to name a configure script that would be
>   broken by this change that isn't already not using econf anyway.
... or using econf even if it shouldn't.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

Am Donnerstag, den 09.04.2009, 13:13 -0400 schrieb Richard Freeman:
> Ciaran McCreesh wrote:
> > 
> > Most packages that have tests have working tests. For those that don't,
> > the tests have to be restricted. All this proposal does is ensures that
> > that happens in a progressive, incremental and safe way.
> > 
> 
> I agree with this point - failing tests are more the exception than the 
> rule.
> 
> Looking at my system the only packages I'm skipping tests for are:
> openldap|parted|orbit|samba|kpilot|nautilus|libksieve|karm|libbonoboui|gnome-vfs|pkgconfig|pam|coreutils|pan|mono|glibc|gettext|curl
No need to skip samba, there are no tests anymore.

> 
> Some of those might be fixed now.
> 
> > If packages are failing tests, either it's a legitimate reason, in
> > which case it needs to be fixed, or it's not, in which case it needs to
> > be restricted. The problem is, currently there's no way for users to
> > know which is which. With an EAPI mandated src_test, users will know
> > that any failure that gets to them is legitimate.
> 
> Hence my having the list posted above (which is just the ones I use that 
>   I've found problems with).
> 
> I also would like to say that the "slow-test" compromise sounds like a 
> good idea.
> 
> A fast-running automated test routine is a good sanity check to show 
> that nothing went wrong during the build.  Maybe the user has some odd 
> version of a dependency that no developer checked with the new package. 
>   Arch testers can't test every combination of dependencies, 
> configurations, use-flags, etc.
> 
> I would think that this might even cut down on user-reported issues. 
> Better to find out that a package has a problem BEFORE it is actually 
> installed.
> 
> If a user is going to spend 10 minutes building a bunch of packages 
> spending another 30-60 seconds on some basic tests doesn't sound 
> unreasonable.  We could also make it easy for users to disable testing 
> entirely if they want to live dangerously.
> 


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] EAPI-3 draft: slot operator support

[Tiziano Müller]

Am Donnerstag, den 09.04.2009, 23:36 +0530 schrieb Nirbheek Chauhan:
> On Thu, Apr 9, 2009 at 10:15 PM, Tiziano Müller  wrote:
> > roughly 90% packages depending on one of:
> >
> > sys-libs/db
> 
> Why the hell does this have so many slots in-tree? I am unaware of the
> reasons for it. Horribly changed API every release? How does every
> other distro handle sys-libs/db ?
Doesn't matter in this context since somebody just wanted examples.

> 
> > dev-libs/boost
> 
> Has one unmasked slot in-tree
Oh, you got me. Nevertheless, will be 4 by the end of the week.

> 
> > dev-lang/python
> >
> 
> So, wait, you want to depend on specific slots of python and keep them
> around, and manage all their related bugs? Isn't that exactly the
> opposite of what python upstream suggests, and *ALL* distros do?
See dleverton's reply.

> 
> > Besides: We wouldn't need the need_python_rebuild anymore, users could
> > safely uninstall old sys-libs/db versions, old dev-libs/boost versions
> 
> @preserved-libs. More generic, a low-level catch-all for library
> breakages, and more convenient for users (rebuild as and when
> possible, not *right now* lest everything break).
> 
> > and the list of packages to reinstall in python-updater boils down to
> > what "paludis -u dev-lang/python:2.4" spits out as reverse-dependencies
> > (or the corresponding portage command).
> 
> You mean emerge -C dev-lang/python:2.4 ? That'll say "bai bai python".
> In any case, what is wrong with python_need_rebuild ?
> 
> Slot operators need changes to the ebuilds, so does python_need_rebuild.
> Slot operators need an EAPI bump for the ebuild, python_need_rebuild doesn't.
> 
> So, isn't python_need_rebuild superior.. ?
> 
No. Python rebuild makes explicit use of how vdb works. Which is not
specified by eapi and therefore not guaranteed to work.
But since you checked how things work before you start writing you
already know that, don't you?



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] EAPI-3 draft: slot operator support

[Tiziano Müller]

Am Donnerstag, den 09.04.2009, 12:03 +0200 schrieb Rémi Cardona:
> Mart Raudsepp a écrit :
> > Hello,
> > 
> > 
> > This thread is for any discussion about the slot operator support item
> > in EAPI-3 draft.
> 
> Could anyone actually give a good reason for slot operators? What 
> packages would have a _clear_ benefit from using them? I'm asking for an 
> actual list of packages, not just some package that may exist in a 
> parallel universe.

roughly 90% packages depending on one of:

sys-libs/db
dev-libs/boost
dev-lang/python

Sooo, something around 500 packages.

Besides: We wouldn't need the need_python_rebuild anymore, users could
safely uninstall old sys-libs/db versions, old dev-libs/boost versions
and the list of packages to reinstall in python-updater boils down to
what "paludis -u dev-lang/python:2.4" spits out as reverse-dependencies
(or the corresponding portage command).



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] EAPI-3 draft: slot operator support

[Tiziano Müller]

Am Donnerstag, den 09.04.2009, 05:25 +0300 schrieb Mart Raudsepp:
> Hello,
> 
> 
> This thread is for any discussion about the slot operator support item
> in EAPI-3 draft.
> 
> The premise is good what := and :* allow for, but I'm concerned about
> the syntax possibly ending up being suboptimal in relation to the syntax
> we come up in the future for covering the cases not covered now.
> 
> 
> Such cases are for example:
> 
> * A library package has slots 2.4, 2.6 and 2.8. An application works
> with either 2.6 or 2.8, but needs a recompile for changed ABI. It does
> not work with 2.4 - it has API missing that it needs.
  DEPEND=RDEPEND=">=cat/lib-2.6:="

> * Same case as previous, but additionally the library has a version with
> slot 3.0 - it is a complete redesign and applications working with 2.8
> have no chance of working. So need to express a list of acceptable SLOTs
> or a minimum and maximum (but slots aren't really guaranteed to be
> numeric and versionable).
slot operators won't help here, so it remains:
  RDEPEND="|| ( cat/lib:2.6 cat/lib:2.8 )"

with ranged dependencies:
  RDEPEND="cat/lib[>=2.6&<3]:="

or slot ranges:
  RDEPEND="cat/lib:[2.6|2.8]="
or
  RDEPEND="cat/lib:=[2.6|2.8]"
(depends on how we want to define the syntax)

> * Same case as previous (either of them), but if using SLOT 2.6, it
> needs to be at least >=libr/ary-2.6.5:2.6 and if SLOT 2.8 at least
> >=libr/ary-2.8.3:2.8. A re-compile if switching provider may or may not
> be necessary (considering both cases separately)
slot operators won't help here, so it remains:
  RDEPEND="|| ( >=cat/lib-2.8.3:2.8 >=cat/lib-2.6.5:2.6 )"

again with ranged dependencies (somebody please check this):
  RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:="
or
  RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:*"

or maybe combined with slot ranges:
  RDEPEND="cat/lib[>=2.8.3|>=2.6.5]:=[2.8|2.6]

please note: the ebuild maintainer has to make sure that the package has
to use the best-matching version, otherwise even the slot specifiers are
worthless.

Real-world example for that:
DEPEND="sys-libs/db:="
RDEPEND="${RDEPEND}"

By the time of installation you have sys-libs/db:{4.6,4.7} installed,
then your app has to use sys-libs/db:4.7.
(best_version should provide that information as far as I know).

> 
> * A library provides slots 1.2, 1.4 and 1.6. An application can work
> with all of them, but needs a recompile if upgrading from being linked
> against 1.2 to newer. 1.4 and 1.6 are runtime interchangeable. Very rare
> possibility of this though, involving dlopen and more. Probably
> acceptable to declare rebuild need for all changes.
Yes.

> Are we sure := and :* is the syntax that makes sense once we try to
> cover some of the above with new syntax?
Yes. It's quiet extendable (as seen above).

> 
> Perhaps some forward thinking is sensible here to not end up with having
> to deprecate the := and :* syntax soon after its introduction.
Done.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

Am Donnerstag, den 09.04.2009, 04:51 +0300 schrieb Mart Raudsepp:
> Hello,
> 
> On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote:
> 
> > With eapis 1 and 2 we introduced nice features but also a couple of
> > new
> > problems. One of them are the use dependencies when the package you
> > depend on doesn't have the use flag anymore (see [1] for an example).
> > 
> > So I think it's time for a short eapi bump with some distinct
> > improvements:
> > 
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
> > 
> > 
> > Please discuss.
> 
> 
> Sorry for getting my points of discussion on the details to the list so
> late.
> I have covered some of my concerns on the items in meetings and
> otherwise on IRC, but now I'll try to get to them in further detail and
> better wording to the mailing list.
> 
> I'm going to go item-by-item here for the things I don't expect much
> replies to, and then starting separate threads for those that I do.
> 
> 
> pkg_pretend
> ===
> 
> No objections.
> Gives an intermediate step for handling USE flag combination
> incompatibilities at pretend stage (to not find it failed in the
> morning), yet has uses outside that as well. So, once there is a way to
> express those kind of USE flag dependencies outside of pkg_pretend in a
> better way in a future EAPI, pkg_pretend will still be useful for other
> (less common) cases and can provide a description of the problem to the
> user.
> 
> 
> Use based deps with non-existing USE flags
> ==
> 
> No objections.
> Implements the missing bit of "built_with_use --missing"
> Main driving force behind EAPI-3.
> 
> 
> default src_install
> ===
> 
> No considerable input yet, catching up with the latest thread about
> src_install bikeshedding
> 
> 
> doinclude
> =
> 
> Unnecessary. Might be interesting for automatic executable permission
> removing, but upstream build systems should be fixed instead for such a
> big and rare error.
> 
> 
> ban dosed
> =
> 
> I don't exactly see a reason for the banning yet, but no objections due
> to general agreement on it and having no technical objections
> 
> 
> doins support for symlinks
> ==
> 
> Lacking information. Need to see if the PMS draft has anything about it.
> The bug and summaries just talk about the support, but no details. Would
> it be an argument to doins?
> 
> 
> unpack failing on unknown types
> ===
> 
> Uncertain about it's worthiness. Might rather have the opposite with a
> --strict argument kind of deal. No official objection from me.
> 
> 
> docompress
> ==
> 
> Need some more time to digest through it in relation to
> PORTAGE_COMPRESS, prepalldocs and co. Will try to follow-up before
> meeting.
> 
> 
> properties must be cached properly
> ==
> 
> No opinion, up to the package manager developers.
> Don't see offhand why it should be an EAPI item at all. Feels like an
> implementation detail.

The metadata cache needs to be specified to make it work with compliant
PM's and is therefore a part of the PMS.
A change is therefore required to be done on a per-EAPI base.

> 
> 
> DEFINED_PHASES must be supported (and cached properly)
> ==
> 
> No opinion, up to the package manager developers more or less.
> Not sure why this needs to be an EAPI item. Hard to see a use case for
> the variable being available for ebuild usage for it to be necessary to
> be an EAPI item.
> By my understanding it is (also?) a required implementation detail to
> handle pkg_pretend sanely and with minimal time hit.
> 
> 
> Limit values in $USE to ones in $IUSE:
> ==
> 
> Seems more of a QA test, but forcing it can make it be caught at start.
> Don't see why it must be an EAPI item. Just vet the tree of (future?)
> repoman warnings about it and make it happen for
> all EAPIs. Impact on overlays is minimal because it is a QA error to not
> define them and they get what they asked for.
> 
> Not strongly opposed to it being in the EAPI.
> 
Why it has to be done in an EAPI: It matters whether you have to put for
example userland_GNU in IUSE if you want to use it in the ebuild or not.


> 
> --disable-dependency-tracking:
> ==
> 
> possible breakage of (custom) configure scripts that don't accept
> unknown arguments. Wo

Re: [gentoo-dev] Real multilib support for Gentoo

[Tiziano Müller]

Am Sonntag, den 05.04.2009, 10:18 +0200 schrieb Thomas Sachau:
> Mike Frysinger schrieb:
> > On Saturday 04 April 2009 08:59:22 Thomas Sachau wrote:
> >> i would like to hear about other opinions about real multilib support
> >> within our tree and package managers. From what i know, there are mainly 2
> >> different ideas:
> >>
> >> 1. Do the main stuff in the package manager (e.g. if the ARCH is amd64 and
> >> the package has x86 keyword, the package manager adds a lib32 useflag,
> >> which would additionally install the 32bit variant of that package together
> >> with the normal 64bit install).
> >>
> >> pro:   -much lesser work for package maintainers
> >>
> >> contra:-needs addition in PMS and support in the pms, which will need 
> >> some
> >> work on their side
> > 
> > get a *working* implementation first and *then* worry about specing it.  
> > once 
> > you have something running with portage, the spec should fall naturally 
> > out.  
> > previous multilib methods attempted to spec things out without any real 
> > code 
> > and they've all just died.
> > 
> >> 2. Do the main stuff in the ebuilds themselves (e.g. an additional eclass
> >> multilib-native.eclass, any ebuild with 32bit support would then need
> >> adaption and of course inheriting that eclass)
> > 
> > this is dead end and useless overhead, and i would reject it from any core 
> > package someone would try to merge.
> > -mike
> 
> 
> From what i got until now, it seems that all answers prefer this option, so i 
> would like to move
> forward and create some aggreement on how this should look like or some 
> implementation that at least
> the majority can accept. With this, i would also like to see any changes that 
> need an EAPI to get
> into EAPI-3.
No. Won't happen.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Preserving mtimes for EAPI3

[Tiziano Müller]

Am Montag, den 30.03.2009, 18:05 +0200 schrieb Peter Alfredsen:
> On Mon, 30 Mar 2009 15:40:14 +0100
> Ciaran McCreesh  wrote:
> 
> > No, an EAPI bump is necessary. Older (post-EAPI) Portage versions do
> > something different, so any ebuild relying upon particular behaviour
> > is already broken.
> 
> For an example of this, see http://bugs.gentoo.org/264308
> 

I currently fail to see how mtime preservation is related to this
since .py[co] files are generated in pkg_postinst() and therefore not
installed by the PM.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Tiziano Müller]

Am Donnerstag, den 26.03.2009, 19:12 +0100 schrieb Donnie Berkholz:
> On 12:25 Mon 23 Mar , Robert Buchholz wrote:
> > On Monday 23 March 2009, Tiziano Müller wrote:
> > > Spec needed. DOCS or no DOCS?
> > 
> > DOCS, and non-empty default value, please [1].
> > Some eclasses already do this (not base, but others), and if that 
> > default doesn't cover it for you, the function can be overridden.
> > 
> > Concerning the argument of declarative ebuilds vs. bash-oriented ebuilds 
> > brought up by Donnie: Our ebuilds always had declarative parts with an 
> > impact on the PM (e.g. RESTRICT), or on eclasses (WANT_AUTOCONF, or 
> > look at the games eclass).
> > I think if we stay within sane limits[2], following this paradigm is 
> > going to help developers because more simple cases will be caught by 
> > the default implementation without adding the complexities of having to 
> > know tons of (aka "more than one") variables and how they interact.
> 
> I probably would have agreed with you a few EAPIs ago where stuff was 
> more painful. Take a look at this, though -- it doesn't seem so bad to 
> me in a non-DOCS, EAPI=3 world:
> 
> src_install() {
>   default
>   dodoc foo bar
> }
> 
Well, we can just start with such a default src_install and then change
it in a later EAPI if we see that it would be more useful to have
DOCS="".

But again: eclasses for certain package classes already provide
src_install implementations considering DOCS for installing
documentation. Which shows that some developers think it's useful.




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Tiziano Müller]

Am Mittwoch, den 25.03.2009, 23:23 + schrieb Ciaran McCreesh:
> On Wed, 25 Mar 2009 23:06:37 +0100
> Donnie Berkholz  wrote:
> > > 9) EAPI 3 bans || ( use? ( ... ) )
> > 
> > What is the suggested replacement? If there's a decent one, sure.
> 
> The replacement is to write the deps out correctly. Every single use of
> || ( use? ( ... ) ) in the tree is wrong.
I created bug #262297 for that (with more text, featuring a citation
from a famous non-gentoo-dev ;-).

> 
> > > 2) EAPI 3 supports slot operator dependencies
> > 
> > Was this for bug #229521? If so, sure.
> 
> Yup. I'm avoiding the term 'multi-slot', though, since that's not what
> this is and we're already using multi- in relation to slots for the
> non-static SLOT idea.
> 
> > > 10) dohard and dosed banned in EAPI 3
> > 
> > I think I missed the reasoning for removing these, particularly
> > dosed. pybugz didn't see any open bugs.
> 
> Portage doesn't merge hardlinks correctly, so dohard is bad.
And there's at least one ebuild in the tree which tries to create a
hardlink across multiple directories and there fails if those are on
separate volumes

>  And
> dosed's been considered deprecated for years.
I've been taught so as well.


> 
> > > 11) doinclude, newinclude for EAPI 3
> > 
> > Is installing to /usr/include by default useful for most packages
> > that want to use this? Or would they /usr/include/${PN}? If you have
> > to change it often, aren't you just as well off using insinto/doins?
> > Should there be an "includeinto"?
> I'd be inclined to agree on that one, but people seem to be after more
> of these do* things.
Would it be possible that doinclude could also strip "+x" from
permission bits? I encountered quiet a few packages having +x set for
whatever reason and I had to change that manually.

> 
> 
> > > 21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3
> > 
> > I'm curious why it isn't global. Seems like it would make sense to
> > put it near dependencies. Also I could be wrong, but wouldn't you
> > want to be able to cache this and show smart pretend output, etc?
> 
> I think you're misunderstanding what this is for. It's to allow
> packages to work out whether they're upgrading / downgrading /
> reinstalling / whatever, since Zac broke the devmanual-documented and
> PMS-required way of doing it using has_version and refuses to revert it.
> 
... and this also more or less explains why it's only available in some
phases. What must be said here is that REPLACING_VERSIONS and
REPLACED_BY_VERSION in pkg_pretend and pkg_setup must be used carefully
since they may or may not be defined in those phases and there's also no
way to guarantee it (think of binary packages).



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Tiziano Müller]

Am Mittwoch, den 25.03.2009, 23:26 + schrieb Ciaran McCreesh:
> On Mon, 23 Mar 2009 09:08:37 +0100
> Tiziano Müller  wrote:
> > > 8) EAPI 3 requires doins support for symlinks
> >
> > Current behaviour is to copy the file the symlink points to, right?
> 
> No, current behaviour is undefined for not a file.

from ebuild-helpers/doins:
_doins() {
local mysrc="$1" mydir="$2" cleanup="" rval

if [ -L "$mysrc" ] ; then
cp "$mysrc" "$TMP/2"
mysrc="$TMP/2/${mysrc##*/}"
cleanup=${mysrc}
fi
[...]
seems like it's copying the target of the symlink.

> 
> > > 14) EAPI 3 supports pkg_info on installed packages
> > you probably mean: uninstalled
> 
> Yup. The diff's right, just the commit message that's wrong.
> 
> > > 15) USE is stricter in EAPI 3
> >
> > Proper documentation for IUSE_IMPLICIT/USE_EXPAND_IMPLICIT is needed.
> > In the PMS draft there's only a reference to section 11.1.1, but in
> > that section is nothing about it.
> 
> I'm still not sure a) whether we want those, b) how exactly they work
> or c) whether there's any chance at all of Portage supporting this in
> the time we're after.
It completely depends on whether people agree that every USE flag should
be stated in IUSE or not.

> 
> > > 20) EAPI 3 has doexample.
> > Including "-r" or implicit recursive?
> 
> Nope.
Well, I think I want "-r" then.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Packages up for grabs: genstef gems special edition

[Tiziano Müller]

Am Montag, den 23.03.2009, 23:08 +0100 schrieb Peter Alfredsen:
> Since genstef has been .away for some time, I arranged with him that I'd
> send a list of his ebuilds that need maintenance to be put up for grabs.
> This list contains all ebuilds that have no herd, at least one open bug
> and where genstef is the maintainer.
> 
> media-video/linux-uvc
I'd have the hardware for that one if nobody else takes it.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] newins "-" for standard input?

[Tiziano Müller]

Am Montag, den 23.03.2009, 09:22 +0100 schrieb Ulrich Mueller:
> Now that "dosed" is going to be banned, what would people think of
> "newins" (and the other "new*" commands) accepting "-" as the first
> argument? I don't know how many usage cases there are, but the
> following are obvious:
> 
>sed 's/quux/quuux/' foo | newins - foo
> 
> It would allow for here documents:
> 
>newins - bar <<-EOF
># configuration file (for example)
>EOF
> 
> or even:
> 
>newins - baz <<<$'# a short\n# file'
> 

I like it :-)



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Tiziano Müller]

Am Sonntag, den 22.03.2009, 20:38 + schrieb Ciaran McCreesh:
> On Sun, 22 Mar 2009 21:18:52 +0100
> Donnie Berkholz  wrote:
> > If you have something you'd wish for us to chat about, maybe even vote
> > on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> > list to see.
> 
> Continuing the whole EAPI 3 thing...
> 
> http://github.com/ciaranm/pms/tree/eapi-3 is a draft based upon
> ongoing discussion. There's more or less one commit per new feature. For
> each feature, I'd like to know:
> 
> * whether there are any objections to that feature as a candidate for
>   EAPI 3
> 
> * what the plan is for Portage implementation of that feature, and the
>   likelihood of it making it
I already started to implement small proposals for portage. For some
issues some minor structural/architectural have to be made.

> 
> * whether that feature is considered critical for EAPI 3, or whether it
>   can be dropped if necessary if Portage can't get it implemented
>   within a certain time
> 
> Also, I'd like to know of any potential omissions.
> 
> I'd imagine this'd go easier of Council members went through before the
> meeting and provided individual opinions on each item, and then just
> discussed any disagreements during the meeting, but whatever's best for
> you...
> 
> This list might help for those who're scared of git:
> 
> 1) EAPI 3 has pkg_pretend.
We have to write something here (probably not in PMS but in the
devmanual) to make clear what is allowed in pkg_pretend and what not.

> 2) EAPI 3 supports slot operator dependencies
> 3) EAPI 3 has use dependency defaults
> 4) PROPERTIES, DEFINED_PHASES mandatory in EAPI 3
> 5) EAPI 3 has a default src_install
Spec needed. DOCS or no DOCS?

> 6) EAPI 3 has controllable compression and docompress
> 7) EAPI 3 has dodoc -r
> 8) EAPI 3 requires doins support for symlinks
Current behaviour is to copy the file the symlink points to, right?
Is that behaviour unsafe and should be deprecated completely or do we
add a flag turning on the new/the old behaviour?

> 9) EAPI 3 bans || ( use? ( ... ) )
> 10) dohard and dosed banned in EAPI 3
> 11) doinclude, newinclude for EAPI 3
> 12) EAPI 3 supports .xz, .tar.xz
> 13) EAPI 3 has more econf arguments
> 14) EAPI 3 supports pkg_info on installed packages
you probably mean: uninstalled

> 15) USE is stricter in EAPI 3
Proper documentation for IUSE_IMPLICIT/USE_EXPAND_IMPLICIT is needed. In
the PMS draft there's only a reference to section 11.1.1, but in that
section is nothing about it.

> 16) AA, KV gone in EAPI 3
> 17) S to WORKDIR fallback conditional for EAPI 3
> 18) EAPI 3 has unpack --if-compressed, new src_unpack
> 19) RDEPEND=DEPEND gone in EAPI 3
> 20) EAPI 3 has doexample.
Including "-r" or implicit recursive?

> 21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3
Same thing as for 1)

> 22) EAPI 3 has nonfatal, utilities die

... and we've got most (if not all) proposals with reasons documented
here:
  http://dev.gentoo.org/~dev-zero/docs/EAPI3.html

Cheers,
Tiziano



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

Am Dienstag, den 17.03.2009, 00:22 +0100 schrieb Tiziano Müller:
> Btw, I put up a document explaining the changes in some detail here:
> http://dev.gentoo.org/~dev-zero/docs/EAPI3.{rst,html}
> (including references to bugs if any, etc.)
> It is completely based on the spreadsheet we used earlier for
> discussion. I'll finish it within the next days.

Ok, feature descriptions are pretty much complete. Please send
patches/comments if something is unclear or completely wrong.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

Am Dienstag, den 17.03.2009, 09:05 +0100 schrieb Ulrich Mueller:
> > On Tue, 17 Mar 2009, Peter Volkov wrote:
> 
> > Probably this is not best implementation, but it describes idea
> > well. If failures are non fatal I don't object to having src_test
> > enabled by default and I'll all for this even.
> 
> [Replying to a random message in this thread.]
> 
> Has anyone already noted that for some packages (especially in sci-*)
> tests just take ages, namely a multiple of the compile time?
> 
> If we are to enable tests for all users by default, we need some way
> to deal with this.

Definitely. Not only sci-*, but also dev-libs/boost (for example) takes
more than a day on a fast machine while I can't even fail src_test if
some tests fail because the tests are sometimes really sensitive to some
gcc/glibc/arch/whatever.




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

Am Dienstag, den 17.03.2009, 07:47 +0100 schrieb Ulrich Mueller:
> >>>>> On Tue, 17 Mar 2009, Tiziano Müller wrote:
> 
> > You forgot to mentioned that we probably also want that
> > default_src_configure/src_compile die when they try to `cd` to an
> > invalid ${S}.
> 
> Sorry, seems that I've missed the discussion on this one.
> 
> There is no 'cd "${S}"' command in the default functions. It's not
> needed since they already start with S as their initial working
> directory. If S doesn't point to an existing directory, WORKDIR is
> used instead.
> 
> I hope you don't propose to remove this useful fallback behaviour in
> general?

Yes I do since I don't see anything useful in it. But I'm ready to be
taught otherwise.




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

Thanks a lot for your work.

Am Montag, den 16.03.2009, 20:47 + schrieb Ciaran McCreesh:
> I've got a very rough draft of what EAPI 3 might end up looking like,
> based upon discussion:
> 
> http://github.com/ciaranm/pms/tree/eapi-3
> 
> Note that I will probably rebase and modifying the branch quite a bit,
> so if you don't know how to deal with that when using git, don't track
> it.
> 
> It should be one commit per feature, which makes it fairly easy to
> remove anything that ends up not making it, and very easy to see what's
> proposed, which currently looks like this:
> 
> * Introduce eapi 3
> * Rework tables for EAPI 3.
> * EAPI 3 has pkg_pretend.
> * EAPI 3 supports slot operator dependencies
> * EAPI 3 has use dependency defaults
> * PROPERTIES, DEFINED_PHASES mandatory in EAPI 3
> * EAPI 3 has a default src_install
> * EAPI 3 has controllable compression and docompress
> * EAPI 3 has dodoc -r
> * EAPI 3 requires doins support for symlinks
> * EAPI 3 bans || ( use? ( ... ) )
> * dohard and dosed banned in EAPI 3
> * doinclude, newinclude for EAPI 3
> * EAPI 3 supports .xz, .tar.xz
> * EAPI 3 has more econf arguments
> * EAPI 3 supports pkg_info on installed packages
> * USE is stricter in EAPI 3
> * Note that (+) won't work on USE_EXPAND etc things
> * AA, KV gone in EAPI 3
> 
> Still to work out:
> 
> * The exact details for the new USE restrictions. In particular, do we
>   want IUSE_IMPLICIT? We'll also need an accurate list of all
>   possible values for things like LINGUAS.
> 
> * The [use(+)] thing. For various really pesky reasons, there's no way
>   things like [video_cards_radeon(+)] can be expected to work when
>   applied against EAPIs before 3, but it can be made to work if we know
>   it'll only ever be applied against things with EAPI 3 or later. Is it
>   easier to just say it's never allowed, though?
> 
> * What's a doexample?


> 
> * What's default_src_install going to do? I've seen a load of
>   variations. It looks like our choices are between things that ignore
>   docs, making it largely worthless, or things that use a DOCS
>   variable, which Donnie hates (despite making extensive use of such
>   things himself in eclasses).
Well, we have distutils and gnome2 eclass using DOCS (to name a few,
short glep shows around 18 eclasses), so I'd say: if we go for a
default_src_install it needs surely DOCS.
If default_src_install should install some DOCS automatically, I'd like
to have a way to disable that behaviour without having to roll my own
src_install.
You forgot to mentioned that we probably also want that
default_src_configure/src_compile die when they try to `cd` to an
invalid ${S}.



> 
> * "Provide ebuilds a way to differentiate between updates and
>   removals". I suggested REPLACING_VERSIONS and REPLACED_BY_VERSION,
>   but I've not had any feedback on that.


> 
> * "Utility commands, even the ones that aren't functions, should die.".
>   Is Portage likely to be able to do this in the timeframe we're after?
I'd say this is a pretty isolated task even people without in-depth
portage knowledge can work on, so I guess it can be implemented.

> 
> * "Calling unpack on an unrecognised extension should be fatal, unless
>   --if-compressed is specified.". There've been questions on this, but
>   no obvious outrage. Is this in or out?
I'd vote for "in" here since I prefer defined behaviour over undefined
and people who want unpack to unpack not-packed files should state it
explicitly.

> 
> * I've left out killing off dohtml. Was a decision reached on that?
No.


> 
> * RDEPEND=DEPEND is still in. Again, was a decision reached?
No, but since repoman is already warning when no RDEPEND or DEPEND is
specified I guess most people want it to be explicit.


> 
> * xz is in, but do we really want to do that when there appears to be
>   nothing stable that can deal with xz? lzma going in was a mistake
>   caused by people being too eager here in exactly the same way they
>   were for making Portage handle xz...
> 
> * Am I to take it src_test is to remain in its current worthless state?
Yes, I'd like to see it enable by default as well, but we have to
discuss that further. So, not suited for a fast eapi release.


Btw, I put up a document explaining the changes in some detail here:
http://dev.gentoo.org/~dev-zero/docs/EAPI3.{rst,html}
(including references to bugs if any, etc.)
It is completely based on the spreadsheet we used earlier for
discussion. I'll finish it within the next days.

Cheers,
Tiziano



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

Am Freitag, den 13.03.2009, 20:11 + schrieb Ciaran McCreesh:
> On Sun, 08 Mar 2009 08:49:16 +0100
> Tiziano Müller  wrote:
> > So I think it's time for a short eapi bump with some distinct
> > improvements:
> 
> Some more small candidates to discuss:
> 
> * How would people feel about killing off automagic RDEPEND=DEPEND
>   behaviour?
> 
> * Officially kill off AA. It's not useful.
Never used it, thus ++

> 
> * Kill off KV. This should be eclass territory.
++

> 
> * Ban dohtml, which is weird, and add '-u dir' to dodoc, so you
>   can use dodoc -r -u html blah instead.
But then we shouldn't introduce doexample, but use "dodoc -r -u
examples" instead.
I liked that dohtml can filter based on file endings, this made it in
the past easier to install html docs.
So, if we could have something like:
  filter_files -t web docs/ | dodoc -r -u html
that would be fine :-)

> 
> * We currently have .xz / .tar.xz support for unpack down for EAPI 3.
>   Am I right in thinking there's nothing stable that can handle .xz
>   files?
> 
As far as I know, but vapier is probably the expert here.




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

Am Sonntag, den 08.03.2009, 23:31 -0700 schrieb Donnie Berkholz:
> On 21:22 Sun 08 Mar , Donnie Berkholz wrote:
> > On 23:35 Sun 08 Mar , Tiziano Müller wrote:
> > > Well, the point I'm trying to make here is a different one: The syntax 
> > > you proposed is more to write but still equivalent to the one using 
> > > vars. And looking at the ebuilds - taking G2CONF as an example - it 
> > > seems that people don't have a problem with putting their config 
> > > options into vars. And furthermore with your syntax you still have to 
> > > write out "econf $(use_with ...)" explicitly while adding it the 
> > > conf-vars to a var (as proposed) makes the complete src_configure 
> > > function obsolete, allows the usage of the default 
> > > src_configure/src_compile/src_install (see 
> > > http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml
> > >  
> > > for example) and is therefore even shorter to write.
> > 
> > I think the idea of ebuilds as scripts showing directly how to build 
> > software is a core part of the Gentoo build-system philosophy. This 
> > proposal pushes ebuilds toward a formatted file that is not a script. 
> > Instead, it is more like an Ant XML file that more abstractly describes 
> > a build. I think this is the wrong direction for ebuilds because they 
> > should directly resemble how software is built by hand.
> > 
> > One of the key reasons people use Gentoo is that ebuilds are so easy to 
> > "get" for anyone who has ever built software by hand. I will continue to 
> > vehemently defend anything that I think retains this key advantage of 
> > Gentoo over other distributions.
> 
> To return to the original point of this whole thread, your goal was to 
> get EAPI=3 through fairly quickly without tons of controversial points. 
> I don't think this component qualifies. Feel free to bring it up again 
> for 4.

Wanted to say the same thing. Removed from the list.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Tiziano Müller]

Am Montag, den 09.03.2009, 10:06 +0100 schrieb Christian Faulhammer:
> Hi,
> 
> Daniel Pielmeier :
> 
> > 2009/3/9 Christian Faulhammer :
> > >
> > >  I don't know if there is a bug somewhere (I did not find one), but
> > > what about having the possibility to ask for one out many USE flags
> > > of a dependency.  For example app-misc/gramps needs dev-lang/python
> > > with USE=berkdb or USE=sqlite, but Portage won't tell the user that
> > > he can enable one but always asks for the first in the || () string.
> > >
> > 
> > || ( dev-lang/python[berkdb] dev-lang/python[sqlite] )
> 
>  That's the solution currently and not the optimum.
>  
> > The only way I found to get around this is to recompile python with
> > the new use flags first. Afterwards dependency calculation succeeds.
> 

Correctly you should probably add a berkdb or sqlite USE flag to gramps
and then do:
sqlite? ( dev-lang/python[sqlite] )
!sqlite? ( dev-lang/python[berkdb] )

Because if the user currently installs gramps and has
dev-lang/python[sqlite] and then later decides to reinstall
dev-lang/python with USE=-sqlite, everything's fine from a package
managers view as long as dev-lang/python has at least USE=berkdb, but
the user looses the data in gramps.

Well, even then it's not safe since it's python and gramps may offer
berkdb as a storage backend even if USE=sqlite, so you should patch
gramps to blend out what's not available from a dependency
perspective...




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

Am Sonntag, den 08.03.2009, 15:16 -0700 schrieb Donnie Berkholz:
> On 19:27 Sun 08 Mar , Tiziano Müller wrote:
> > Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
> > > It would just eliminate all but one call to use_with(). Depending on how 
> > > many you've got, this can shorten things up a fair bit. Here's an 
> > > example:
> > > 
> > >   econf \
> > >   $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
> > 
> > The above could be rewritten to:
> > 
> > ECONF_USE_WITH="'x X' 'foo libfoo' 'bar' 'python pygtk'"
> > econf $(use_with ${ECONF_USE_WITH})
> 
> Why would I want to obfuscate my code like that by purposely making 
> people look in multiple places to figure out what it's doing? I don't 
> see how this is any improvement.
> 
> > or an eclass could even export this:
> > 
> > src_configure() {
> > [ -n ${ECONF_USE_WITH} ] && USE_WITH="$(use_with
> > \"${ECONF_USE_WITH}\")"
> > econf ${USE_WITH}
> > }
> > 
> > Guessing from what I see in the gnome/kde eclasses I think people will
> > implement the above then in eclasses and I therefore don't see why we
> > can't do it like that from the beginning...
> 
> If it can be implemented in an eclass, why would we want to do it as an 
> EAPI in a package manager? Eclasses can be easily changed, you only need 
> to write them once, and you don't have to deal with updating & approving 
> a spec and new implementation for a bug in the previous implementation 
> (which you have to retain indefinitely).

Well, the point I'm trying to make here is a different one:
The syntax you proposed is more to write but still equivalent to the one
using vars.
And looking at the ebuilds - taking G2CONF as an example - it seems that
people don't have a problem with putting their config options into vars.
And furthermore with your syntax you still have to write out "econf
$(use_with ...)" explicitly while adding it the conf-vars to a var (as
proposed) makes the complete src_configure function obsolete, allows the
usage of the default src_configure/src_compile/src_install (see
http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml 
for example) and is therefore even shorter to write.




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

Am Sonntag, den 08.03.2009, 11:24 -0700 schrieb Donnie Berkholz:
> On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
> > On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> > > On Sun, 8 Mar 2009 09:42:29 -0700
> > > Donnie Berkholz  wrote:
> > > > - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I 
> > > > strongly oppose this implementation because it makes ebuilds less
> > > > like bash scripts that are easy to understand. Instead I suggest
> > > > extending use_with() and use_enable() to accept multiple sets of
> > > > arguments (alternately, making custom, similar functions that will
> > > > take multiple args).
> > > 
> > > How would that work? I can't see an obvious way of doing it that isn't
> > > more or less as verbose as just using multiple calls.
> > 
> > It would just eliminate all but one call to use_with(). Depending on how 
> > many you've got, this can shorten things up a fair bit. Here's an 
> > example:
> > 
> > econf \
> > $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
> > econf \
> > $(use_with x X) \
> > $(use_with foo libfoo) \
> > $(use_with bar) \
> > $(use_with python pygtk)
> 
> And the straightforward evolution of this would be additional with() and 
> enable() functions for mandatory support. I still find this more 
> intuitive than the set of variables.
> 
> econf \
>   $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') \
>   $(with foo bar blah baz) \
>   $(enable bam paw tick)
> 

Which could already be written as ...
   econf --with-{foo,bar}
using bash :-)

(or did I miss the point?)



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil