Re: [gentoo-dev] =dev-lang/{tcl,tk}-8.5* unmask

2009-04-17 Thread Santiago M. Mola
On Fri, Apr 17, 2009 at 11:07 PM, Federico Ferri mescali...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 It's been long time since tcl-8.5 is sitting in tree p.masked.

 a number of bugs have been fixed in the past (last bugs I've fixed
 this evening: itcl-3.3, tix, tclpython; one I can't fix is otcl -
 moreover, it's damn obsolete (last commit 2 years ago))
 the remaining bugs in the tracker [1] are mostly applications (not
 tcltk's herd) with (mostly) no rdeps.


++

Two years is enough. That's even more than what took Python 2.5 to get
out p.mask ;-)

After various heads up on the bug and on @g-dev, I think it's time to
unmask. Incompatible packages should be fixed ASAP (after unmasking)
or punted from the tree if they can't keep up with tcl/tk development.

Best regards,
-- 
Santiago M. Mola
Jabber ID: cooldw...@gmail.com



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

2009-04-04 Thread Santiago M. Mola
On Sat, Apr 4, 2009 at 2:59 PM, Thomas Sachau to...@gentoo.org wrote:
 Hi folks,


 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:

The proposals are not exactly these.

1. Make package managers multilib-aware [1][2].

Package managers would be able to have a default ABI (say, x86_64) and
optional ones (x86). Everything would be built for the default ABI,
and the package manager could build things for optional ABIs on an as
needed basis. That is, if I install a 32bit binary package, the
package manager will build any 32bit libraries it needs automatically.

Package managers will have to expose to ebuilds a mechanism to iterate
over enabled ABIs and build anything needed for each one.

Pros:
- Any package can be made multilib aware, getting rid of the emul-* packages.
- 32bit libraries are built automatically and as needed.
- This system can be extended to support other kind of ABIs. Making it
possible to build packages for various versions of Python/GHC/etc
simultaneously.

Cons:
- Needs to be implemented on the PM-side and needs a new EAPI.

2. Implement multilib on the ebuild level.

For amd64, this would mean adding a 'lib32' USE flag to every multilib
ebuild, and use it for building 32bit libs as needed.

Pros:
- Any package can be made multilib aware, getting rid of the emul-* packages.
- Doesn't need PM changes.

Cons:
- Package manager won't be multilib-aware, so it won't be able to
build 32bit libraries automatically and as needed.
- Users will have to enable 'lib32' USE flag manually for every
library they needed. Enabling 'lib32' by default is not an option
since it would build tons of unneeded 32bit libraries for every user.


[1] http://dev.exherbo.org/~pioto/abi-ideas.html
[2] http://bugs.gentoo.org/show_bug.cgi?id=145737

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldw...@gmail.com



Re: [gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

2009-03-10 Thread Santiago M. Mola
On Tue, Mar 10, 2009 at 4:58 PM, Christian Faulhammer fa...@gentoo.org wrote:

  Having the EAPI stored outside the ebuild's scope is generally a bad
 idea, because someone has to tell you that the ebuild you just
 downloaded from Bugzilla is EAPI x.  And the package manager will be
 totally confused when assuming an EAPI that is wrong.  So the EAPI
 should be stored inside (best solution regarding giving ebuilds away)
 or in the file name (best compromise regarding the whole situation.


Most ebuilds in Bugzilla have a proper name. I suggest you to download
them with pybugz:
$ bugz attachment ATTACHMENT-ID
that will download it with the proper name.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldw...@gmail.com



Re: [gentoo-dev] when the music's over

2009-03-09 Thread Santiago M. Mola
On Mon, Mar 9, 2009 at 12:03 AM, Ali Polatel hawk...@gentoo.org wrote:
 Hey everyone,
 It's my turn to say goodbye.
 It's been really nice for two years. I've had great fun and have no bad
 feelings as I leave. This mail is meant as an apology to people who are
 awaiting my return. I'm sorry to let you down.
 So when the fun^Wmusic's over, turn off gentoo^Wthe lights.

 Ah.. the reasons? there are no reasons, who needs reasons when you got 
 exherbo?

Good luck with Exherbo and Sydbox ;-)

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldw...@gmail.com



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

2009-02-24 Thread Santiago M. Mola
On Tue, Feb 24, 2009 at 6:47 PM, Brian Harring ferri...@gmail.com wrote:

 At the very least I'm after having the non-pms repos marked in some
 fashion so that alt implementations don't have to assume the portage
 standard (rather then the *agreed to* pms standard) to avoid
 exploding, but that's a rather short sighted solution- something is
 needed long term.


And/or make Portage noisy on PMS violations.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldw...@gmail.com



[gentoo-dev] Packages up for grabs

2009-02-11 Thread Santiago M. Mola
Hello,

All my packages are up for grabs. Feel free to add yourself to
metadata.xml and don't hesitate to ask me any doubts about them.

Telepathy stuff
---
dev-util/telepathy-inspector (low maintainance)
dev-python/pymsn
net-im/empathy
net-im/telepathy-mission-control
net-irc/telepathy-idle
net-voip/telepathy-butterfly
net-voip/telepathy-haze

Packages that I've been taking care of and could use a maintainer:
net-libs/telepathy-glib (frequent bumps)
net-voip/telepathy-gabble (frequent bumps)

Other stuff
---
app-text/xmldiff (maintainance close to zero)
app-vim/exheres-syntax
games-arcade/whichwayisup (low maintainance)
media-tv/w_scan (low maintainance)
media-libs/libdiscid (dep of picard)
media-sound/last-exit
media-sound/picard
media-video/qc-usb-messenger (semi-inactive upstream, users send patches
for new kernels)
net-p2p/lince
net-p2p/museek+
x11-misc/dzen (low maintainance)
x11-misc/lsw (maintainance close to zero)

Packages that I've been taking care of and could use a maintainer:
app-shells/bash-completion
net-p2p/nicotine+

Best regards,
-- 
Santiago M. Mola
Jabber ID: cooldw...@gmail.com



Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

2009-01-21 Thread Santiago M. Mola
El mar, 20-01-2009 a las 21:04 +0200, Petteri Räty escribió:

 d) something else

e) use a hook around unpack on your local system to detect new build.xml
for a list of packages.

AFAIK, checking changes is part of the bump process, so I think that's a
check you can do either at hand, with a script (it's always a good thing
to look for new files in the project, or look at the diffs), or as I
said in 'e)', use some tricks with /etc/portage/bashrc.

Regards,
-- 
Santiago Moisés Mola
Jabber: cooldw...@gmail.com | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada digitalmente


Re: [gentoo-dev] Detecting Baselayout2/openrc - no-symlink profiles leading to breakage

2009-01-19 Thread Santiago M. Mola
On Sun, Jan 18, 2009 at 12:52 AM, Friedrich Oslage blueb...@gentoo.org wrote:

 Why not teach /sbin/runscript it's own version? With something like this
  we could also do stuff depending on a specific version of openrc:


That would be a good solution since it'll allow us to check higher
versions for new features. Otherwise, it's very likely that we need to
solve the same problem again in the near future.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldw...@gmail.com



Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs

2009-01-17 Thread Santiago M. Mola
El sáb, 17-01-2009 a las 16:41 +0100, Thomas Sachau escribió:
 Marius Mauch schrieb:
  On Sat, 17 Jan 2009 14:09:49 +0100
  Thomas Sachau to...@gentoo.org wrote:
  
  Hi,
 
  as specified in the PMS spec [1] and stated in #gentoo-portage,
  RDEPEND will be set to DEPEND, if it is not defined in the ebuild
  itself. But devmanual [2] and developer handbook [3] both state, you
  have do explicitly set RDEPEND because it may be removed in the
  future. Since package manager have to follow the PMS spec, i would
  suggest to change those docs [2][3] and let them follow the PMS spec.
 
  Any problems, suggestions or anything else about this?
  
  It's strongly recommended to set both explicitly as the behavior could
  change in future EAPI versions, and to ensure that you actually think
  about which deps are build deps and which are runtime deps.
  Also there is nothing wrong with policies being stricter than the
  underlying spec.
  
  Marius
  
  
 
 If i want to use some future EAPI (give me some reasons, why this should be 
 changed there by
 default), i should think about it. But most ebuilds will stay with the 
 default. I do think about
 runtime deps and build deps. In my eyes, this is similar to src_unpack and 
 src_compile. They have
 defaults, noone specifies the defaults, even if they are changed in some EAPI.
 

You may want to change the wording in docs to make it say it's
encouraged to set both but it's not technically needed.

Note that PMS is *not* a good practice guidelenes. There are a bunch of
things that are technically valid but wrong from a QA point of view.

Regards,
-- 
Santiago Moisés Mola
Jabber: cooldw...@gmail.com | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada digitalmente


Re: [gentoo-dev] reorganization of /var/lib gentoo-related files

2008-12-31 Thread Santiago M. Mola
El mié, 31-12-2008 a las 15:33 +0100, Fabio Rossi escribió:
 On Wednesday 31 December 2008, Marius Mauch wrote:
 
  Well, the impact is about the same wether you want to change one or the
  other (btw, what about other admin tools on Gentoo, e.g.
  paludis/pkgcore, by your definition they'd also have to go
  into /var/lib/gentoo, right?)
 
 Yes. So you don't think that a /var/lib/distribution_name directory makes 
 sense for collecting all admin files *strictly* related to the distribution, 
 do you?
 
 If portage/paludis/pkgcore were used in other distributions I'd not consider 
 their files related to the admin purposes of one specific distrib, at that 
 point their files could be directly put inside /var/lib.

They are used in other distributions. Paludis is the default package
manager on Exherbo. Also, think about all Gentoo derivatives like
Sabayon.

Regards,
-- 
Santiago Moisés Mola
Jabber: cooldw...@gmail.com | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada digitalmente


Re: [gentoo-dev] app-admin/eselect needs YOUR help

2008-12-08 Thread Santiago M. Mola
(I'm replying to Ciaran's email, but my reply is for Donnie too)

El lun, 08-12-2008 a las 17:44 +, Ciaran McCreesh escribió:
 On Mon, 8 Dec 2008 08:37:42 -0800
 Donnie Berkholz [EMAIL PROTECTED] wrote:
  Open and public debate about the right way to do things does take 
  longer, and it's something you certainly participate in quite
  frequently so I'm surprised to hear you badmouth it when it comes to
  your own ideas.
 
 Open and public debate requires two or more well informed parties who
 are seeking to reach the best solution regardless of who proposed it,
 and a deciding body who are prepared to go for the best solution even
 if it isn't universally popular. This sometimes happens with Gentoo,
 but unfortunately all too often it's one of these instead:
 
 [long rant]

It's simpler. An alternatives framework was discussed openly and
publicly through @exherbo-dev. Discussing Exherbo development through
@gentoo-dev is impractical for both Gentoo and Exherbo.

Now, some Exherbo devs came up with an eselect fork, and Ciaran pointed
out in this thread that it could be useful for people looking for
improving eselect.

Anything else is irrelevant here.

Regards,
-- 
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada digitalmente


Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Santiago M. Mola
El dom, 30-11-2008 a las 14:23 +0100, Diego 'Flameeyes' Pettenò
escribió:
 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions) and we
 get rid of the variable for the next EAPI version?
 

 
 Please submit all comments, as long as they are not I don't like XML
 or XML is the wrong answer and similar since the point here is not to
 discuss the format of metadata but rather where to have it.

As suggested by Ciaran and Serkan, this could also be achieved with
per-package eclasses [1].

That way, it would be easy to avoid duplication of not only HOMEPAGE but
also SRC_URI, LICENSE, or any other part of an ebuild.

In fact, this idea is already being used in the tree in the form of bash
scripts in ${FILESDIR} that are source'd in the ebuild [2].

[1] https://bugs.gentoo.org/show_bug.cgi?id=69714
[2]
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/glibc/files/eblits/

Regards,
-- 
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente


Re: [gentoo-dev] Re: Some support for Sunrise Overlay :-)

2008-11-26 Thread Santiago M. Mola
On Wed, Nov 26, 2008 at 4:02 PM, Duncan [EMAIL PROTECTED] wrote:

 Exactly. =:^)

 I'm really too deliberative a thinker to comfortably keep up with IM/IRC,
 and there tend to be problems with either incoming message overload or
 (effectively) remote end time-out because they get bored waiting for me.


If there are Sunrise collaborators (or people with strong intentions
of becoming one) who want to propose a Sunrise mailing list, that's
fine. Otherwise, this discussion is pointless. I don't think we want
to start a debate in @gentoo-dev where everyone in this list state his
opinion about what communication methods are more effective.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] Proposal for how to handle stable ebuilds

2008-11-10 Thread Santiago M. Mola
El lun, 10-11-2008 a las 13:13 -0500, Mark Loeser escribió:
 
 Ebuild Stabilization Time
 
 Arch teams will normally have 30 days from the day a bug was filed, keyworded
 STABLEREQ, the arch was CCed, and the maintainer either filed the bug or
 commented that it was OK to stabilize (clock starts when all of these
 conditions are met).

 
 Removing Stable Ebuilds
 
 If an ebuild meets the time criteria above, and there are no technical issues
 preventing stabilization, then the maintainer MAY choose to delete an older
 version even if it is the most recent stable version for a particular arch.
 
 If an ebuild meets the time criteria above, but there is a technical issue
 preventing stabilization, and there are no outstanding security issues, then
 the maintainer MUST not remove the highest-versioned stable ebuild for any
 given arch without the approval of the arch team.
 
 Security issues are to be handled by the recommendations of the Security Team.
 

If this proposal had been approved a year ago as is, amd64 stable
keywords could have been dropped all over the place, making stable tree
unsupported on amd64 de facto (guess how many users would have left
Gentoo) and agravating our past workload problems.

So the consequences of this policy being applied on a regular basis can
be far worse than arches lagging behind.

Regards,
-- 
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente


Re: [gentoo-dev] DEFAULT_* proposal

2008-11-09 Thread Santiago M. Mola
Hello,

El dom, 09-11-2008 a las 15:39 +0300, Peter Volkov escribió:
 
 1. Functions we have now are much more flexible then proposed arrays. Do
 I need to think of some example of code that is impossible to do with
 arrays but still possible with functions?
 

The same concern was raised in the default src_install proposal. Making
default functions a bit more flexible doesn't mean we need default
functions which cover every possible case, that's just impossible.

 
 At the same time this new syntax make some things worse:

 
 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad
 practice of using patches instead of sed.

As shown in the proposal, this variable is already used in many eclasses
and it has been proven useful.

I'm not sure the existence of PATCHES is promoting any kind of patch
abuse. As far as I know, it's more common the concern about abusing sed
for things that should be patched rather than the other way.

But, in any case, both methods would still be available:

src_prepare {
epatch ${FILESDIR}/some-stuff.patch
sed -i -e s:FOO:BAR:g Makefile
}

would still be correct.

If someone is using the PATCHES variable like this:

PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... )

a sed call would be easy to add if needed as follows:

PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... )

src_prepare() {
default
sed -i -e s:FOO:BAR:g Makefile
}


It's quite straight-forward.

 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus
 easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES,
 btw). (highlighting helps here but does not makes that variables easier
 to read or type in?)

This is the easier part to address. If these names are a problem, other
names can be used. For example, what it's called
DEFAULT_SRC_INSTALL_DOCS in this proposal, it's called just DOCS in
others.

If people likes this approach better, then similar names can be chosen
for the rest of proposed variables. For example:

DEFAULT_SRC_PREPARE_PATCHES - PATCHES, EPATCHES...
DEFAULT_SRC_CONFIGURE_ENABLES - ECONF_ENABLES
DEFAULT_SRC_COMPILE_PARAMS - EMAKE_PARAMS, EMAKE_EXTRA_PARAMS...

Anyway, it'd be better if people focus on discussing the actual
functionality rather than the chosen names.

 
 4. it also conflates multiple concepts into a single variable name (the
 function name, whether it's USE-dependent, and how the configure flag is
 passed). (-- Donnie Berkholz [6])

ECONF_USE_ENABLES might solve that problem.

 
 5. One of the great things about ebuilds is that they're very natural
 to write in most cases, if you can manage to build the program by hand.
 Raising this barrier of entry for questionable benefit seems like a bad 
 idea. (-- Donnie Berkholz [7])

Functions would still be overridable. And, in fact, they will need to be
overriden in many cases. There's no change there. With respect this
barrier, it already exists with the many eclasses we have.

Regards,
-- 
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente


Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-15 Thread Santiago M. Mola
El mar, 14-10-2008 a las 18:24 -0700, Alec Warner escribió:
 On Tue, Oct 14, 2008 at 3:34 PM, Petteri Räty [EMAIL PROTECTED] wrote:
 
 
  There's no need to commit straight to stable. Just make two different
  new revisions for each EAPI. Then the arch teams can test it like usual.
 
 Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are
 there multiple versions of the same package' questions and
 complexities.
 

If you're thinking about having two equal versions with different EAPIs,
that's not allowed by GLEP 55:

Note that it is still not permitted to have more than one ebuild with
equal category, package name, and version. Although it would have the
advantage of allowing authors to provide backwards compatible ebuilds,
it would introduce problems too. The first is the requirement to have
strict EAPI ordering, the second is ensuring that all the ebuilds for a
single category/package-version are equivalent, i.e. installing any of
them has exactly the same effect on a given system.

Regards,
-- 
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente


Re: [gentoo-dev] Re: Slacking arches - which are stable, which aren't?

2008-10-07 Thread Santiago M. Mola
El lun, 06-10-2008 a las 23:13 +, Duncan escribió:
 Jeremy Olexa [EMAIL PROTECTED] posted [EMAIL PROTECTED],
 excerpted below, on  Mon, 06 Oct 2008 15:07:14 -0500:
 
  AFAIK, it is incorrect right now to exclude s390, arm, sh, etc on
  stablereqs right now..But, I ask this question to the dev community:
  Why? There are ~190 open bugs with s390 as assignee or on the CC list.
  Does it *really* matter if these under-staffed odd arches have a
  stable tree or not?
 
 Having been an amd64 user back when it was much smaller, and having 
 followed the previous discussion on this here, including the mips - 
 experimental move, yes, it does matter.  With the bugs there's at least 
 some info on a package and its stabilization potential when/if someone 
 gets around to doing something about it.  Without them, the job of 
 bringing them back to unsupported and then to full supported, if there's 
 suddenly a leap in interest, becomes much harder as there's that much 
 less info on what /was/ stable at one point, and on anything in the ~arch 
 versions that might need checked before they go stable again.
 

I fully agree. I think bringing some understaffed arches back to ~arch
is an option, but should be avoided if possible.

I wonder how many of these 190 open bugs in s390 are actually bugs about
brokenness, and not just regular stabilizations...

And by the way, amd64 had a similar amount of open bugs by the end of
2007.

Regards,
-- 
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente


Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

2008-09-24 Thread Santiago M. Mola
El mié, 24-09-2008 a las 02:35 +0200, Robert Buchholz escribió:
 
 Let's go with an even simpler default implementation:
 
 default_src_install() {
   if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
   emake DESTDIR=${D} install || die emake install failed
 fi
   if [ -n ${DOCS} ]; then
   dodoc ${DOCS} || die dodoc failed
   fi
 }
 
 It addresses the following issues:
 * Do not run einstall if emake fails
 * Run dodoc even if no Makefile is present, this might come in handy for
   ebuilds calling default()
 * die dodoc failure case
 * hopefully fix the flaws (not really) pointed out by zlin
 

Looks far better. In my opinion, that would be an acceptable
implementation of default_src_install.

Regards,
-- 
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente


Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

2008-09-17 Thread Santiago M. Mola
On Wed, Sep 17, 2008 at 9:59 AM, C. Bergström
[EMAIL PROTECTED] wrote:
 Ulrich Mueller wrote:
 On Wed, 17 Sep 2008, C. Bergström wrote:




 Here's another idea and I don't know why I didn't think of it
 sooner.. Instead of any system change to the patch ebuild.. Inside
 the eutils.eclass do a quick check for gpatch and if it exists use
 that vs patch.


 Why not simply alias patch=gpatch in profile.bashrc?
 See the FreeBSD profile for an example.


 I'd like to package portage for OpenSolaris and have it just drop-in work so
 modifications like what you suggest wouldn't be required.

You'd still need to create an OpenSolaris profile. While you're at it,
you can create a profile.bashrc with the required modifications.

I don't see any reason to not do the gpatch change, but it looks like
unecessary to me because you already have simpler ways to solve the
problem. So, requiring others to do a significant useless amount of
work when you can solve it with just a line is not fair.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


Re: [gentoo-dev] Preventing $ARCH flags in USE

2008-09-15 Thread Santiago M. Mola
On Mon, Sep 15, 2008 at 9:45 PM, Vlastimil Babka [EMAIL PROTECTED] wrote:

 I think it's better to prevent this rather than waste time with bug
 reports like that. I asked Zac on IRC whether portage could filter such
 flags. He suggested using use.mask in profiles. Well since ARCH is also
 set by a profile, why not. Although a really persistent and stupid user
 could use.unmask, it's better than no protection. And then we can think
 how to replace the current ARCH-USE flag system with e.g. USE_EXPAND.
 What do you think?


Seems like an acceptable workaround.

For future EAPIs, ARCH could be a regular USE_EXPANDed flag as you
suggest, and package managers could filter any flag in USE which is
not listed in IUSE.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] One-Day Gentoo Council Reminder for September

2008-09-11 Thread Santiago M. Mola
On Thu, Sep 11, 2008 at 4:55 PM, Robert Buchholz [EMAIL PROTECTED] wrote:
 On Thursday 11 September 2008, Ciaran McCreesh wrote:
 On Wed, 10 Sep 2008 23:43:54 -0700

 Zac Medico [EMAIL PROTECTED] wrote:
  [2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html

 By table 6.11, are you implying that you consider the new pkg_ phase
 order to be part of EAPI 2?

 Really, Portage needs to revert the order and go back to the way it
 used to be for all EAPIs. The change breaks lots of existing ebuilds
 (you claim you've probably fixed everything in ::gentoo, but you
 don't know that and you've definitely not fixed overlays), including
 ebuilds using a common documented technique recommended by the
 devmanual.

 If you want the new pkg_* ordering to go through at all, it really
 needs a lengthy discussion on its own and it mustn't apply to any
 action that involves any existing EAPI.

 I'd like the Council to say that for anything involving EAPIs 0, 1 or
 2 we stick to the pkg_* phase ordering we've used years.

 What is the change of order you witnessed in table 6.11 of the draft?
 Comparing that to the PMS on [3], the order looks identical to me
 (except for the two new phases). Am I missing something?


 Robert

 [3] http://dev.gentoo.org/~coldwind/pms.pdf Section 10.2


Previously, the order was different for upgrading/downgrading
packages. You can see a summary of the problem in bug #235020 [1]. I
sent a note to @-dev [2] with a list of all packages *in the tree*
which were affected by the most common problem of the order change
(using has_version in pkg_postinst), all of them were quickly fixed by
Zac. But there may be more packages affected not included there.

[1] https://bugs.gentoo.org/show_bug.cgi?id=226505
[2] 
http://archives.gentoo.org/gentoo-dev/msg_27feec8fc563e406b174386d24c39fdc.xml

Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

2008-09-08 Thread Santiago M. Mola
On Mon, Sep 8, 2008 at 9:48 AM, Vaeth [EMAIL PROTECTED] wrote:

 But it doesn't do this well, because it is incompatible with any other
 case. Assume, for example, that you have an ebuild in this manner and
 that for the new release or for a bugfix you need a small non-included
 thing - then this means that you have to rewrite the ebuild almost
 completely. The suggestion violates in an extreme way the golden design
 rule that small changes in effect should require small changes in source.
 Moreover, a second syntax is introduced which everybody has learn,
 although it could be done as easily by the standard commands.



Yes, you're right. That would  be really tedious and stupid... but
we're lucky, and EAPI-2 introduced the 'default' function. So if you
need to do a small change not covered by this method, you just define
the phase, make the little change, and then call the 'default'
function. Clean and simple.

In any case, I guess people are not considering this change for
EAPI-2. I think we'll come up with a more extense proposal which could
be targeted for EAPI-3.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

2008-09-08 Thread Santiago M. Mola
On Mon, Sep 8, 2008 at 10:44 AM, Alec Warner [EMAIL PROTECTED] wrote:

 Most obvious failure cases these days have build logs and the build
 logs will specify what the configure command
 was, so the only problematic area is looking at the ebuild to
 determine what will happen during execution.  Arguably having
 an ebuildshell would assist here.  However, ebuilds are already
 sufficiently complicated by eclass inheritance that reading
 many ebuilds is already difficult and I think this extension does not
 make that significantly worse.

If you're just dealing with the default phases, it's not too hard to
say in advance the exact command that will be executed. Default phases
are well-defined in PMS. So you can look at them to see what will
happend if you define some variable.

For example, for the proposed arguments for src_configure, a
definition would be something like this (taken from Exherbo, just
pretend it says USE instead OPTION and you're done):
default_src_configure()
{
if [[ -x ${ECONF_SOURCE:-.}/configure ]] ; then
econf \
[EMAIL PROTECTED] \
$(for s in ${DEFAULT_SRC_CONFIGURE_OPTION_ENABLES} ; do \
option_enable ${s} ; \
done ) \
$(for s in ${DEFAULT_SRC_CONFIGURE_OPTION_WITHS} ; do \
option_with ${s} ; \
done )
fi
}

It's quite straightforward.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

2008-09-08 Thread Santiago M. Mola
On Mon, Sep 8, 2008 at 1:56 PM, Vaeth [EMAIL PROTECTED] wrote:
 Santiago M. Mola wrote:
 Vaeth [EMAIL PROTECTED] wrote:
 
  [...] The suggestion violates in an extreme way the golden design
  rule that small changes in effect should require small changes in source.
 [...]

 Yes, you're right. That would  be really tedious and stupid... but
 we're lucky, and EAPI-2 introduced the 'default' function. So if you
 need to do a small change not covered by this method, you just define
 the phase, make the little change, and then call the 'default'
 function. Clean and simple.

 How does this little change look like if you have to call ./autogen.sh
 instead of ./configure?

Most of the time you don't call autogen.sh, but eautoreconf. And when
you have to call ./autogen.sh you usually do it in src_unpack (or
src_prepare if it's introduced in EAPI-2).

 Or if you want to call a second ./configure
 in some subdirectory with the same options but one option changed?

This is not a small change that happens on any package too often (if
ever). For such cases you can define  a custom
src_configure/src_compile which fits your needs.


 These are just some examples, I hope that the point becomes clear:
 You simply cannot cover all natural modifications which might be
 necessary unless you really can access the commands themselves;

You can access the commands themselves,I think no one said ever in
this thread that use_with, use_enable or econf are going to be
deprecated.


Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] Bug wrangling

2008-09-08 Thread Santiago M. Mola
On Mon, Sep 8, 2008 at 10:38 PM, Dawid Węgliński [EMAIL PROTECTED] wrote:
 On Monday 08 of September 2008 22:22:12 Joe Peterson wrote:
 Christian Faulhammer wrote:
  everyone working on bugs, please add all people from metadata.xml to
  the assignee or cc field, I regularly have to search for bugs where a
  team and I maintain a package because only the team has been added.
   Second, please use full atoms (cat-egory/package) in the Summary
  field, so searching is easier.

 Sorry if this answer can be found elsewhere, but if one has a proxy
 maintainer (i.e. not a Gentoo dev) for a package, can/should this person be
 added to metadata.xml?  Is there a special tag for this?  I can certainly
 see this being helpful (so that person automatically gets on the cc list at
 least).

   Thanks, Joe

 Yes, and usually that's how it's done. Eg eix' metadata.xml says:

  maintainer
email[EMAIL PROTECTED]/email
nameMartin Väth/name
  /maintainer



Yep. And for more completeness you can add something like
descriptionProxied maintainerdescription/. Although, it's quite
obvious when it's a non-Gentoo email.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

2008-09-07 Thread Santiago M. Mola
On Sun, Sep 7, 2008 at 6:50 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
 On Sun, 07 Sep 2008 12:46:45 -0400
 Marcus D. Hanwell [EMAIL PROTECTED] wrote:
  The proposal is not designed to replace all cases. It's designed to
  replace the common 50%.
 
 I personally agree with several others who have replied to this
 thread. The reduction in lines of code/characters seems to introduce
 an uglier syntax which is harder to read with questionable benefits.

 Try using it for a few weeks. Once you're used to it it's considerably
 nicer than going through and implementing pointless src_configures all
 over the place...


Yes. And here another point should be brought up. This proposal should
be wider and consider similar changes for the most common used
operations on all phases. Implementing it only for
src_{configure,compile} won't feel so useful as implementing similar
variables for most phases.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

2008-09-06 Thread Santiago M. Mola
On Sat, Sep 6, 2008 at 9:00 PM, Alec Warner [EMAIL PROTECTED] wrote:
 On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson [EMAIL PROTECTED] wrote:
 Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}

Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS

The code from above could be rewritten like so:

DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )

That's much simpler.

 It saves you 1 line and reduces readability and intuitiveness by a
 fair margin; how is it simpler?


In the given example it's not a big deal. However, when you're dealing
with more arguments it simplifies things.

For example, this (based on an existing ebuild, but simplified a bit
for brevity):

--
src_compile() {
local myconf=
--sysconfdir=/etc/${PN}
--without-xgrid
--enable-pretty-print-stacktrace
--enable-orterun-prefix-by-default
--without-slurm

if use threads; then
myconf=${myconf}
--enable-mpi-threads
--with-progress-threads
fi

econf ${myconf} \
$(use_enable !nocxx mpi-cxx) \
$(use_enable romio io-romio) \
$(use_enable heterogeneous) \
$(use_with pbs tm) \
$(use_enable ipv6) \
|| die econf failed

emake  || die emake failed
}
--

becomes

--
SRC_DEFAULT_CONFIGURE_WITHS=( pbs tm ipv6 threads progress-threads
SRC_DEFAULT_CONFIGURE_ENABLES=(
cxx mpi-cxx
romio io-romio
heterogeneous
threads mpi-threads
SRC_DEFAULT_CONFIGURE_EXTRA_PARAMS=(
--sysconfdir=/etc/${PN}
--without-xgrid
--enable-pretty-print-stacktrace
--enable-orterun-prefix-by-default
--without-slurm )
--

You save some lines, but also you keep out all the use_* calls with
their backslashes, myconf=$myconf crap, econf/emake || die...

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

2008-09-06 Thread Santiago M. Mola
On Sat, Sep 6, 2008 at 10:10 PM, Ben de Groot [EMAIL PROTECTED] wrote:
 Alec Warner wrote:
 On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson [EMAIL PROTECTED] wrote:
 Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}

Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS

The code from above could be rewritten like so:

DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )

That's much simpler.

 It saves you 1 line and reduces readability and intuitiveness by a
 fair margin; how is it simpler?

 It may be 2 lines less, but it is 42 characters more.
 Plus, I dislike caps. :-p

In the example I posted it's 339 characters less. Almost half of the
original ;-)

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] The Plethora of Patches

2008-08-18 Thread Santiago M. Mola
On Tue, Aug 19, 2008 at 12:02 AM, Tobias Scherbaum
[EMAIL PROTECTED] wrote:
 Santiago M. Mola wrote:

 However, tracking the status of every patch since its inclusion in
 portage until it's removed would be a huge work overhead... and I
 doubt it's worthy.

 I don't think it's a huge work overhead, it'll take an additional minute
 per included patch to include a minimal description into the ebuild(s)
 and use a standardized header for the patch. Compared to the time one
 needs to spend when searching for information on that patch somewhen
 later on it's worth every minute.


Of course, puting a header with info in every patch is not a work
overhead and I'd say it should be policy. What I meant is that it's no
worth to track the status of every patch after it's added, as was
suggested.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] The Plethora of Patches

2008-08-14 Thread Santiago M. Mola
On Thu, Aug 14, 2008 at 4:17 AM, Andrew D Kirch [EMAIL PROTECTED] wrote:

 Patches in the metadata.xml should have some sort of status tracking for
 each patch, repoman should flag any that don't, and warn on any that have
 not been submitted upstream unless the status is signed off on by a herd
 leader (such as Gentoo specific patches). This would provide visual feedback
 for users and developers with regard to a pretty important metric on how
 successful Gentoo is at getting patches pushed back to developers.

It was proposed recently to add some standarized headers to all new
patches for maintenance purposes. Something like:

Source: patch by John Foo, backported from upstream, whatever.
Upstream: In revision 245, rejected, foo.
Reason: Build system sucks

I think that's all we need in order to know how were things when the
patch was added and if it needs to be pushed/tracked upstream, removed
in the next version of the package, etc.

Some of us already put these kind of headers, or at least an URL to
upstream bug or a meaningful source of info about the patch.

However, tracking the status of every patch since its inclusion in
portage until it's removed would be a huge work overhead... and I
doubt it's worthy.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]

2008-08-13 Thread Santiago M. Mola
On Wed, Aug 13, 2008 at 7:11 PM, Doug Goldstein [EMAIL PROTECTED] wrote:
 Howdy all,

 Further questions regarding use.desc have come up with regard to this GLEP.
 My proposed solution would be a potential amendment to the GLEP to state
 that

 flag name='png' /

 Would be allowed. This syntax is not actually disallowed or allowed by the
 current GLEP, but mentioning it would allow a metadata.xml contain all the
 USE flags that appear in IUSE, even the global ones. By using the above
 syntax, it would simply state that there is no additional descriptions or
 details but to just use the use.desc description.

 Further more, it would allow us in the future to make that mandatory and
 repoman would only have to check metadata.xml for your USE flag.

 Comments, Suggestions, Input are all welcome.


What is the benefit?

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] Retirement

2008-08-11 Thread Santiago M. Mola
On Sun, Aug 10, 2008 at 10:56 PM, Ingmar Vanhassel [EMAIL PROTECTED] wrote:

 There're other projects in the Free-Software world that I currently
 enjoy putting my time into more, I'm sure it's more than obvious to those
 of you who know me which...


Good luck with that project!

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] Retirement

2008-08-11 Thread Santiago M. Mola
On Mon, Aug 11, 2008 at 12:26 AM, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
 My retirement is probably long overdue as I haven't really been active for
 several months. It is now clear to me that Gentoo is not moving in the
 direction I had wished for and the last council election indicates that most
 current Gentoo developers appear to be satisfied with this current direction.
 Therefore farewell. If anybody wants to reach me I can be reached at
 bo.andresen at zlin.dk.


So long, and see you on the evil side ;-)

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


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

2008-08-08 Thread Santiago M. Mola
On Tue, Aug 5, 2008 at 1:06 AM, Alec Warner [EMAIL PROTECTED] wrote:
 On Mon, Aug 4, 2008 at 11:29 AM, Stephen Bennett [EMAIL PROTECTED] 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 would like to put forward the following suggestion for the Council's
 consideration:

 While the current state of PMS is not perfect, it is a reasonably
 close approximation to existing and historical behaviour of EAPI 0.
 Given this, and that getting a perfect definition is not feasible on a
 timescale shorter than several years, it should be treated as a draft
 standard, and any deviations from it found in the gentoo tree or
 package managers should have a bug filed against either the deviator
 or PMS to resolve the differences.

 [...]

 Is there some reason why this needs to be stated explicity (eg. are
 you having difficulty getting things fixed in the tree?)


Currently it can't be referenced from other official documentation.
There's already one GLEP which had to get references to PMS removed
because of this. And it will become a bigger problem when we have more
EAPIs and we can't rely on any spec except short summaries posted to
@dev-announce.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?

2008-08-03 Thread Santiago M. Mola
On Sun, Aug 3, 2008 at 12:25 AM, Zac Medico [EMAIL PROTECTED] wrote:
 Santiago M. Mola wrote:

 I don't think we're in a hurry for this feature, so I don't see the
 need of using suboptimal hacks in order to avoid an EAPI bump.
 Furthermore, EAPI 2 is supposed to be done in the near future, right?

 Regards,

 I don't view the RESTRICT=live idea as suboptimal or a hack in
 any way. I see it as a legitimate use of an existing ebuild variable
 that's already used for lots of other legitimate purposes.


Let me rephrase the point as that this method should not be favoured
over others just because it doesn't require an EAPI bump.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?

2008-08-02 Thread Santiago M. Mola
On Sat, Aug 2, 2008 at 12:26 PM, Zac Medico [EMAIL PROTECTED] wrote:
 Mike Auty wrote:

 If there's need for a new class of ebuild information (such as a new
 way of categorizing ebuilds by feature), perhaps we should add an ebuild
 features variable specifically for the purpose?

 That requires an EAPI bump, which also means that it can't be used
 in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we
 can use it right now in any ebuild.


I don't think we're in a hurry for this feature, so I don't see the
need of using suboptimal hacks in order to avoid an EAPI bump.
Furthermore, EAPI 2 is supposed to be done in the near future, right?

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]



Re: [gentoo-dev] Council meeting summary for 10 July 2008

2008-07-14 Thread Santiago M. Mola
On Mon, Jul 14, 2008 at 5:32 AM, Jeroen Roovers [EMAIL PROTECTED] wrote:

 What GLEP 55 fails to address right now is the very development process
 it is seemingly supposed to alleviate. It addresses the issue of EAPI
 implementation from the viewpoint of the package manager's developer,
 but it doesn't begin to address the viewpoint of the package
 maintainer or architecture developer at all. It looks to me like a lot
 of problems are moved out of the package manager(s) and into this
 already huge tree of files, with different EAPI-suffixed files
 addressing different problems, and that indicate be a non-trivial
 increase in the number of files in the tree - files which would
 address the equal purpose of installing exactly one =cat/pkg-ver.

GLEP 55 says:
Note that it is still not permitted to have more than one ebuild with
equal category, package name, and version.

 In other words, disregarding its other real world deficiencies like an
 immediate goal, GLEP 55 fails to describe a keywording policy for
 architecture developers

Keywording policy wouldn't change.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Tags vs. categories (was: sci-libs/scipy - dev-python/scip)

2008-07-08 Thread Santiago M. Mola
On Tue, Jul 8, 2008 at 9:31 AM, Josh Saddler [EMAIL PROTECTED] wrote:

 Tags instead of categories . . . Now here's a very interesting idea, indeed.
 Has there ever been a proposal like this for Gentoo?



 Tags . . . I like the idea. I like it a lot. Thoughts? Exciting? Or is it an
 old issue, and I'm 5 years late to the party. :)


Exherbo will change its category system at some point. There has been
some discussion about it which may be interesting for people thinking
about possible replacements in Gentoo:
http://lists.exherbo.org/pipermail/exherbo-dev/2008-May/000149.html

There was similar discussions in @g-dev but I'm too lazy to start
serching the relevant threads.

Best regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Multislot dependencies

2008-07-01 Thread Santiago M. Mola
On Tue, Jul 1, 2008 at 2:47 PM, Enrico Weigelt [EMAIL PROTECTED] wrote:

 Well, some of you might still remember what I said about gtk and
 slots long time ago. Just to summarize my point:

 * the use of slots should be MINIMIZED. IMHO, the kernel is one
  of the few valid uses, gtk is NOT (1.* and 2.* are *different*
  packages and so should be treated differently).

 * at runtime an most packages need that variant/slot they were
  built for (and gtk1'ed package needs gtk-1.x, NOT gtk-2.* and
  vice versa)


This is not going to change. We already unified the gtk USE flag, we
have SLOT dependencies now, and, generally, prior discussion,
decisions and common practices shows that we're not going to follow
that path.

We are talking about multislot dependencies. At this point, your
arguments are noise. So, please, don't continue with these points in
this thread.

Thanks,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] When the version scheme changes

2008-06-29 Thread Santiago M. Mola
On Sun, Jun 29, 2008 at 9:41 PM, Marijn Schouten (hkBst)
[EMAIL PROTECTED] wrote:

 The benefit is being able to automatically reversion an ebuild. Reversioning 
 may
 not be necessary very often, but it's annoying when it is and there is no good
 reason that it should. There is no benefit in keeping the version variables
 read-only.

 Marijn


I think that doing PV=${PV/0./} is asking for trouble, even if we
had a function for reseting it after the change. In any case it should
be a function like reset_pv ${PV/0./} which keeps other variables (P,
S...) consistent. Also, this would imply an EAPI bump.

I doubt this change is worth the trouble.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: What to do when Python 2.5 is blocking your package from entering stable? (Agenda for next council meeting?)

2008-06-20 Thread Santiago M. Mola
On Fri, Jun 20, 2008 at 9:34 AM, Tiziano Müller [EMAIL PROTECTED] wrote:
 Rob Cakebread wrote:

 Samuli Suominen wrote:
 I don't know about you, but when a package can't be stabled because
 it's depending on Python 2.5 and current stable is broken I'd like
 to start reverting stable keywords back to ~arch as noone wants to
 maintain broken junk. Latest being app-cdr/gtkcdlabel, and
 media-video/gaupol. Perhaps it should be a council agenda?

 Not much different from slacking arches, it's simple, lack of
 active devs. What I would prefer, of course, is a list from one of
 python members to get it into stable but have no expetations, since
 I've asked it many times past 1-2 years.

 Unless there are any objections from the rest of the Python project,
 I'll try to get this done within the next 24 hours.

 I think it's good to go.


There are a few things which need some kind of action before/during
python 2.5 stabilization:

Needs stabilization:
* dev-python/python-bibtext-1.2.3
* dev-python/pyvorbis-1.4-r3 (a bit buggy, debian has patches for 1.3,
some of them can be ported)
* tinyerp? http://qa.mandriva.com/show_bug.cgi?id=31554
* dev-libs/xapian-1.0.6
* dev-libs/xapian-bindings-1.0.6
* dev-python/pygame-1.8.0 (buggy, I have patches from trunk, we might
want to wait to 1.8.1)
* dev-python/soappy-0.12.0 (bug #216385)

Needs fix:
* x11-misc/qterm (bug #216466)
* dev-db/rekall (bug #141068) - needs bump, probably this is going to
be p.masked and eventually removed from the tree

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
���^�X�����(��j)b�b�

Re: [gentoo-dev] Packages broken by phase ordering change

2008-06-15 Thread Santiago M. Mola
On Sun, Jun 15, 2008 at 12:32 PM, Matthias Schwarzott [EMAIL PROTECTED] wrote:
 On Freitag, 13. Juni 2008, Santiago M. Mola wrote:
 Hi all,

 As discussed in bug #222721, portage has changed the execution order
 of phases. It seems the change was introduced in portage-2.1.5 and it
 makes that, when upgrading a package, pkg_postinst is run after the
 old version has been removed. This breaks packages which use
 has_version in pkg_postinst to detect upgrades/downgrades. It can also
 break packages in more subtle ways.


 So someone that has access permissions here: Please do fix the devmanual
 http://devmanual.gentoo.org/ebuild-writing/functions/pkg_postinst/index.html


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

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: A few questions to our nominees

2008-06-14 Thread Santiago M. Mola
On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato [EMAIL PROTECTED] wrote:
 Ryan Hill wrote:

 I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
 0.26 was released.  I already need to do this with my live ebuilds.  Of
 course, with some projects you never know if the next version will be
 0.26.1, 0.27, or 0.3, or 1.0...

 That's an upstream issue, all we should care is about getting a version
 value that makes sense for us, better if it does for them.


I think upstream use release branches correctly here, and it's the
most widespread use.

There's some real examples where .live = _pre has problems.

* media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2,
but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when
it's released.

* media-video/ffmpeg: Pretty much the same that mplayer, but a bit worse.

* x11-wm/enlightenment: latest release is 0.16.8.13, current live
ebuild is 0.16.. If we use .live here we'd need either
0.16..live (which is quite pointless) or 0.16.8.14.live which
would need to be updated after every minor release. 0.17.live is not a
possibility at all since 0.17 is a rewrite from scratch and an entire
different application.

* media-sound/amarok: live version is 1.4.. Next version is 2.0,
but that's a different branch so I'd expect 2.0.live to give me the
latest 2.0 version available, not 1.4's.

With the current proposal, .live ebuilds should be changed after every
minor release, unless we use the number of the next release. Next
release isn't always known, and it's doesn't always make sense. This
puts us in a worse situation than with GLEP 54, or even with the
current use of . components.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Packages broken by phase ordering change

2008-06-13 Thread Santiago M. Mola
Hi all,

As discussed in bug #222721, portage has changed the execution order
of phases. It seems the change was introduced in portage-2.1.5 and it
makes that, when upgrading a package, pkg_postinst is run after the
old version has been removed. This breaks packages which use
has_version in pkg_postinst to detect upgrades/downgrades. It can also
break packages in more subtle ways.

The following ebuilds are affected by has_version problem. There may
be some affected ebuilds missing, and also ebuilds broken in a
different way.

app-pda/libopensync-0.22
app-portage/conf-update-1.0
dev-libs/libotf-0.9.4
dev-libs/libotf-0.9.5
dev-libs/libotf-0.9.6
dev-libs/libotf-0.9.7
dev-util/scons-0.97
dev-util/scons-0.98.3
dev-util/scons-0.98.4
mail-filter/dspam-3.8.0-r11
media-gfx/splashutils-1.5.2.1
media-gfx/splashutils-1.5.3.4
media-gfx/splashutils-1.5.4
media-gfx/splashutils-1.5.4.1
media-gfx/splashutils-1.5.4-r1
media-libs/libdvbpsi-0.1.5
media-libs/libdvbpsi-0.1.6
media-libs/libexif-0.6.16
media-libs/libexif-0.6.16-r1
media-libs/pdflib-7.0.2
media-libs/pdflib-7.0.2_p8
media-plugins/vdr-epgsearch-0.9.19
media-plugins/vdr-epgsearch-0.9.20
media-plugins/vdr-epgsearch-0.9.21
media-plugins/vdr-epgsearch-0.9.22
media-plugins/vdr-epgsearch-0.9.23
media-plugins/vdr-epgsearch-0.9.24
media-plugins/vdr-epgsearch-0.9.24_beta19
media-plugins/vdr-epgsearch-0.9.24_beta22
media-plugins/vdr-epgsearch-0.9.24_beta23
media-plugins/vdr-epgsearch-0.9.24_beta26
media-plugins/vdr-epgsearch-0.9.24_rc2
media-tv/gentoo-vdr-scripts-0.4.0
media-tv/gentoo-vdr-scripts-0.4.1
media-tv/gentoo-vdr-scripts-0.4.2
media-tv/gentoo-vdr-scripts-0.4.3
media-tv/gentoo-vdr-scripts-0.4.3-r1
media-tv/gentoo-vdr-scripts-0.4.4
media-tv/vdrplugin-rebuild-0.2
media-video/vdr-1.4.6
media-video/vdr-1.4.7-r10
media-video/vdr-1.6.0
media-video/vdr-1.6.0_p1
media-video/vdr-1.6.0_p1-r1
media-video/vdr-1.6.0-r1
media-video/vdr-1.6.0-r2
net-analyzer/fail2ban-0.8.0-r1
net-analyzer/fail2ban-0.8.1
net-analyzer/fail2ban-0.8.2
net-dialup/ppp-2.4.4-r14
net-dialup/ppp-2.4.4-r15
net-firewall/iptables-1.3.5-r4
net-firewall/iptables-1.3.6
net-firewall/iptables-1.3.6-r1
net-firewall/iptables-1.3.7
net-firewall/iptables-1.3.8
net-firewall/iptables-1.3.8-r1
net-firewall/iptables-1.3.8-r2
net-firewall/iptables-1.3.8-r3
net-firewall/iptables-1.4.0
net-mail/getmail-4.7.6
net-mail/getmail-4.7.7
net-mail/getmail-4.7.8
net-mail/getmail-4.8.1
net-mail/mailgraph-1.14
net-misc/asterisk-1.2.13
net-misc/asterisk-1.2.13-r1
net-misc/asterisk-1.2.14
net-misc/asterisk-1.2.14-r1
net-misc/asterisk-1.2.14-r2
net-misc/asterisk-1.2.17
net-misc/asterisk-1.2.17-r1
net-misc/asterisk-1.2.21.1
net-misc/asterisk-1.2.21.1-r1
net-misc/asterisk-1.2.27
net-misc/freenet6-4.2.2
net-misc/freenet6-5.0
net-misc/freenet6-5.1
net-misc/ser-0.9.4
net-misc/ser-0.9.6
net-misc/ser-0.9.7
net-print/cups-1.2.12-r4
net-print/cups-1.2.12-r7
net-print/cups-1.2.12-r8
net-print/cups-1.3.7-r1
net-print/cups-1.3.7-r2
sys-cluster/util-vserver-0.30.214
sys-cluster/util-vserver-0.30.215
sys-fs/udev-114
sys-fs/udev-114-r1
sys-fs/udev-114-r2
sys-fs/udev-115
sys-fs/udev-115-r1
sys-fs/udev-115-r5
sys-fs/udev-115-r6
sys-fs/udev-116
sys-fs/udev-116-r1
sys-fs/udev-117
sys-fs/udev-118
sys-fs/udev-118-r1
sys-fs/udev-118-r2
sys-fs/udev-118-r3
sys-fs/udev-119
sys-fs/udev-119-r1
sys-fs/udev-120
sys-fs/udev-121
sys-fs/udev-122
sys-fs/udev-122-r1
sys-fs/udev-124
sys-process/vixie-cron-4.1-r10
www-client/surfraw-2.1.5
www-servers/apache-2.2.8
www-servers/apache-2.2.8-r3
www-servers/apache-2.2.8-r4

If the new phase order is staying, then all those packages should be
fixed. It's possible to use has_version in pkg_setup or other phase
and cache the result in a global variable.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-council] Re: [gentoo-dev] One-Day Gentoo Council Reminder for June

2008-06-12 Thread Santiago M. Mola
On Thu, Jun 12, 2008 at 7:14 PM, Mike Frysinger [EMAIL PROTECTED] wrote:
 On Thursday 12 June 2008, Donnie Berkholz wrote:
 On 04:11 Wed 11 Jun , Brian Harring wrote:
  Reiterating the early request, I'd like the council to please discuss
  the current status of PMS,

 People actually working on the PMS would be better-placed to discuss its
 current status, if by that you mean progress toward an approved spec.
 The last I heard was a couple months ago when Ciaran asked us whether
 there were any further major issues and removed kdebuild-1 from the PDF
 to be approved.

 he was told to remove kdebuild-1 from the repo and this has yet to happen


This shouldn't block PMS discussions. There's an up to date copy in
pdf of PMS built without kdebuild at
http://dev.gentoo.org/~coldwind/pms-without-kdebuild.pdf

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-11 Thread Santiago M. Mola
On Wed, Jun 11, 2008 at 7:53 AM, Luca Barbato [EMAIL PROTECTED] wrote:

 A whole bunch of science packages have upstreams that say If you're
 building from source, run 'make check' and if it fails don't carry on.

 Their rationale behind that is that their code is severely broken, using
  experimental features from their language of choice or, simply, that they
 are paranoid and couldn't think better ways to annoy people?


It's not as simple as that. A package may fail tests because compiler
bugs, build environment misconfiguration, problems in a library which
is being used, a setup problem or, of course, a bug in the package
which shows up in rare cases and haven't been spoted by upstream yet.

When the package can be critical for the system, upgrading to a buggy
version will eat people's dogs. I feel a bit safer when I run the test
phase for my package manager, and I wouldn't install it if it's
failing any test. I don't think that's too paranoid.

Also let's put a real example: gmplib. From www.gmplib.org on the front page:
 IMPORTANT INFORMATION FOR ALL GMP USERS:

GMP is very often miscompiled! We are seeing ever increasing problems
with miscompilations of the GMP code. It has now come to the point
where a compiler should be assumed to miscompile GMP. Please never use
your newly compiled libgmp.a or libgmp.so without first running make
check. If it doesn't complete without errors, don't trust the library.
Please try another compiler release, or change optimization flags
until it works. If you have the skill to isolate the problem, please
report it to us if it is a GMP bug; else to the compiler vendor. (The
compilers that cause problems are HP's unbundled compilers and GCC, in
particular Apple's GCC releases.) 

Upstream clearly states that a gmp build which tests have failed
shouldn't be used. I bet they deny support for users who fail to
follow that indication ;-)

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-11 Thread Santiago M. Mola
On Wed, Jun 11, 2008 at 12:05 PM, Olivier Galibert [EMAIL PROTECTED] wrote:
 On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote:
 !-- EAPI=3 --

 *Then* would be the time to change the extension.  As long as the
 ebuild is bash-parseable with an appropriate environment, it doesn't
 make sense to change the extension because a env-variable set or a
 comment are more natural methods.

 If/when the format changes to something not parseable by bash, then it
 will be time to change the extension.  And then how to mark
 (sub-)version will depend on the chosen new format, in case of xml
 that would be the dtd information.

 I suspect the rejection of the extension change will be there as long
 as the fundamental format (bash script) doesn't change.


If the extension was based on the fact that ebuilds are bash scripts,
they'd have .bash extension. The .ebuild extension means a specific
kind of bash script and it doesn't seem wrong to change the extension
if that specific kind changes, even if bash is still the
interpreter. Even if we switched to sh or zsh I doubt we'd use the .sh
or .zsh extension.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-11 Thread Santiago M. Mola
On Thu, Jun 12, 2008 at 4:07 AM, Jim Ramsay [EMAIL PROTECTED] wrote:
 Why not just bump the filename suffix when it is required to support a
 new EAPI that breaks the sourcing rules of previous EAPIs?

 Or will backwards-incompatible changes be happening so frequently that
 the package suffix will have to change for every EAPI bump anyway,
 which would make this proposal equivalent to GLEP55?

That works. Although, we'd have to keep track of two parameters when
setting our EAPI. One being the EAPI itself and the suffix needed for
that EAPI. So this doesn't seem to make the problem simpler.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Santiago M. Mola
On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri [EMAIL PROTECTED] wrote:

 The so-called shebang; very good in my opinion!

 Works very well for true shell scripts. why it can't work for ebuilds?

This option was already discussed when GLEP 55 was proposed, and in my
opinion it's totally discarded. The concept of shebang doesn't apply
here at all. Plus /usr/bin/ebuild is a binary provided by portage
which has nothing to do with the process of sourcing ebuilds nor even
with the internals of portage (not to speak of other package
managers).

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] die/QA notice for do* failure?

2008-06-08 Thread Santiago M. Mola
On Sun, Jun 8, 2008 at 4:48 PM, Arun Raghavan [EMAIL PROTECTED] wrote:
 Hello All,
 We were just discussing if it makes sense to either die or issue a QA
 notice if one of the do* functions fail. It turns out that there's
 already a bug for this [1]. This potentially applies to all helper
 functions that don't currently die on failure.


That's indeed a good idea, and we can do a step further.

We can define a new EAPI which makes all do* functions die on error,
and provide non-fatal versions as trydo* where it makes it sense.
emake could also die since we currently add die calls for all emake
occurences.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] die/QA notice for do* failure?

2008-06-08 Thread Santiago M. Mola
On Sun, Jun 8, 2008 at 7:19 PM, Arun Raghavan [EMAIL PROTECTED] wrote:
 On Sun, Jun 8, 2008 at 10:21 PM, Ciaran McCreesh
 [EMAIL PROTECTED] wrote:
 [...]
 That's not how it works. We've seen plenty of times in the past
 that forcing QA by making users' systems break (which is how far these
 things get before they're fixed) just leads to lots of annoyed users.
 EAPI, plus slowly moving things towards new EAPIs on version bumps once
 newer EAPIs are widely supported, is the clean way of doing this.

 This might be the clean way to do it, but the unfortunate truth is
 that new EAPIs seem to be becoming standard pretty darn slowly, and
 counting on one to implement a feature that is definitely very useful
 for QA seems to be miring ourselves in unnecessary bureaucracy.

(Replying to a random snippet)

There has been previous discussion on
https://bugs.gentoo.org/show_bug.cgi?id=138792

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Nominations for council

2008-06-07 Thread Santiago M. Mola
On Thu, Jun 5, 2008 at 9:44 AM, Fernando J. Pereda [EMAIL PROTECTED] wrote:

 I'd like to nominate:

 ColdWind


ferdy, thanks for the nomination.

astinus, thanks for your support and inspiration, which almost
convinced me for running for Council.

I decline.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



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

2008-06-02 Thread Santiago M. Mola
On Mon, Jun 2, 2008 at 11:18 AM, Raúl Porcel [EMAIL PROTECTED] wrote:
 Ryan Hill wrote:

 On Sun, 01 Jun 2008 19:41:28 +0200
 Raúl Porcel [EMAIL PROTECTED] wrote:

 IMHO the packages should be keyworded if an arch team member or an
 user of that arch requests it. Keywording something if an user of
 said arch doesn't request it, is a waste of resources.

 How is making things available to your users a waste of resources?
 Anyways, if you're so far behind that you don't think you can manage
 keywording another package then just say so and deny the request.

 What does this have to do with council?


 And whats the point of having some package keyworded if nobody is going to
 use it?
 I don't care anyway, i just want an official clarification, personally i
 tend to keyword stuff if i think its going to be useful.

 Thing is, whats the difference in a maintainer asking for a package to be
 keyworded and keywording all the packages in the tree?

You're not going to be asked to keyword the whole tree, that's the
difference ;-)

I think we have not enough feedback from users about this. Either
Bugzilla is not the right tool, or we don't encourage users enough to
ask for keywords when they need them. Currently, some people assume
that if a user from $arch needed this package, he'd have requested
keywords, but that's wrong.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
���^�X�����(��j)b�b�

Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?

2008-05-30 Thread Santiago M. Mola
On Fri, May 30, 2008 at 9:16 AM, Mike Auty [EMAIL PROTECTED] wrote:

 Peter Volkov wrote:
 | Is there any reason why --as-needed is not enabled by default?

 There's still about 18 open bugs on the tracker[1] for it.  You can see
 how many problems it had been causing by the huge number of blocking bugs.

 I've been using it for a pretty long time now (probably a couple weeks
 after Diego first blogged about it) and don't have many problems at all
 (now), but every once in a while a version bump or a new package will
 just fail to compile properly and the problem leads back to as-needed.
 I'm not sure whether ~arch users would be able to catch all the
 as-needed bugs before they hit stable, so I couldn't say whether it
 should be enabled by default or not.

That's not a problem at all. If we choose to support --as-needed by
default we'd get testing from maintainers when adding new ebuilds, and
from arch teams before ebuilds hit stable.

--as-needed breaking legitimate code is a problem, though. I wonder if
we have that kind of code in any application in the tree and if we
have some way to detect it.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: About herds and their non-existant use

2008-05-23 Thread Santiago M. Mola
On Fri, May 23, 2008 at 10:39 AM, Tiziano Müller [EMAIL PROTECTED] wrote:
 Marijn Schouten (hkBst) wrote:
 While we're changing things around, perhaps we can then also standardize
 the mail alias to [EMAIL PROTECTED]
 What Marius is saying though is that there are two files that handle
 people and their herds. One XML for saying who is in a herd and one for
 each herd mail alias on woodpecker with a list of developer email
 prefixes.

 Which could be generated out of the XML file, right?


It could, but it would be nice to preserve a method for allowing
lurkers on aliases.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


Re: [gentoo-dev] am I ready to step into Gentoo?

2008-05-20 Thread Santiago M. Mola
On Tue, May 20, 2008 at 7:20 PM, Federico Ferri [EMAIL PROTECTED] wrote:

 my computer-related hobbies (or I should say time-killers!) are Tcl
 (scripting language) and Pure-Data (multimedia dataflow environment). I
 regularly use Pd to create audio/video apps, and Tcl for everything else
 that doesn't fit Pd, I've also developed a Tcl-Pd loader, that allows to
 code externals for Pd in Tcl.
 see my Pd page at [3].

 perhaps that's the category I should belong to...(?)
 I keep occasional contact with Tcl developers, so I could bring some love to
 the Tcl/Tk Gentoo herd (yes, I am a Tcl/Tk fan, as you can see on my
 wikipage at [4])
 I've also set up an overlay (pd-overlay, [5]) and used to develop together
 with ColdWind (actually a Gentoo dev) ebuilds for EVERY pd external!

 [...]

 so what's going to be my next step into Gentoo? perhaps finding a mentor?
 ColdWind would you...? any one else?


I'm in contact with Federico, we agreed that the recruitment process
will start when the exams are over, but he's going to start slowly
working on it before.

I think he can do good work on tcltk, and who knows if he'll work on
bringing PureData to Gentoo too!

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: dedicated USE-flag is inconsequent and confusing

2008-05-16 Thread Santiago M. Mola
On Fri, May 16, 2008 at 3:07 AM, Duncan [EMAIL PROTECTED] wrote:
 However, AFAIK USE defaults are an EAPI=1 feature, and thus
 not quite yet encouraged for the general tree.

EAPI-1 is approved for use in the tree. People are encouraged to use
it whenever they need any feature provided by it. IIRC, system
packages are an exception, but it's perfectly ok for the rest.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



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

2008-05-08 Thread Santiago M. Mola
On Thu, May 8, 2008 at 1:15 PM, Brian Harring [EMAIL PROTECTED] wrote:
  If PMS is going to be discussed in some form, it's a fair request that
  folks have an easily readable version.

Here you have latest pms revision built without kdebuild-1 spec:
http://dev.gentoo.org/~coldwind/pms.pdf

It's not that hard to extract the relevant paragraph from the tex
sources, though.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



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

2008-05-08 Thread Santiago M. Mola
On Thu, May 8, 2008 at 2:01 PM, Brian Harring [EMAIL PROTECTED] wrote:
 On Thu, May 08, 2008 at 01:44:53PM +0200, Santiago M. Mola wrote:
  
   Here you have latest pms revision built without kdebuild-1 spec:
   http://dev.gentoo.org/~coldwind/pms.pdf
  

  Already did (hence the bash 3.0 comment), that said having a live copy
  of the doc for ebuild devs to review, or portage tree tool developers
  to review isn't exactly a bad idea.


I've updated it now to:
http://dev.gentoo.org/~coldwind/pms.pdf
http://dev.gentoo.org/~coldwind/pms-without-kdebuild.pdf

Someone may want to automate it. At the moment, ping me if you want me
to update them.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: lzma tarball usage

2008-05-08 Thread Santiago M. Mola
On Thu, May 8, 2008 at 9:09 PM, Fabian Groffen [EMAIL PROTECTED] wrote:

   e) It has been suggested the support should have been added with new
   EAPI instead of local build deps (some of which are missing, for
   instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format
   net-tools doesn't have a dep in addition to using lzma for no good
   reason)

  Chill, relax and cool down.  Instead, just ask those who decided to
  follow upstream why and if they have even thought about the issues you
  brought up.


Note that we're also speaking about downstream lzma archives. Like in
sys-apps/net-tools, where lzma hasn't been adopted even by upstream.

Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: language bindings as separate packages

2008-05-01 Thread Santiago M. Mola
On Thu, May 1, 2008 at 5:09 PM, Enrico Weigelt [EMAIL PROTECTED] wrote:

  Hi folks,

  while building yum, I again ran into trouble because one
  dependency has to be rebuilt with an specific useflag first
  (in this case it was libxml2 + python useflag). Actually,
  there are *lots* of these cases and (AFAIK) portage has no
  way for properly handling this - it's up to the individual
  ebuilds to check for those situations and artifically breaking
  the build. Of coure, breaking builds are ugly.

The proper solution for these cases is implementing USE dependencies,
which would obsolete pkg_setup checks, and would provide portage with
info about which USE flags are needed for each dependency. This
feature is already implemented in other package managers (it's in
Paludis, maybe in pkgcore too?) and I think we all look forward its
inclusion in portage.

  My suggestion: make those language bindings being separate
  packages. So, other packages can depend on them directly,
  instead of the current, build-breaking hack.

  I'm not advocating gentoo should do this step alone, but
  instead join in the upstream and solve it there.


Yes, sometimes it makes sense for upstream to split packages, anyone
is free to push them for doing so.

Regards,

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Nazi symbols on Gentoo (and other offending content)

2008-04-27 Thread Santiago M. Mola
Hi there,

Other devs and me have been worried about the use of Nazi symbols on
forums.gentoo.org [1]. While some find it specially a problem because
of German laws (which it seems make illegal to visit webs with such
symbols), I'm more worried because these symbols, as well as others
related to recent dictatorships or hate-promoting movements, are
offending for a good amount of people in the community.

The offending nature of Nazi symbols, and their total irrelevance in a
distro community makes me wonder why the hell should we have this on
our communication channels?.

The fact that political and religious discussions are also irrelevant
in this context makes me wonder also why the hell should we keep any
of this potentially offending and flame-maker?

Gentoo is a community made of people of all around the world, with
different cultures and political views, and we have to work together.
So why don't put the politics aside and continue the work respecting
each other? The Internet is plenty of forums where people can flame
about politics or create a Nazi alter-ego and offend each other,
Gentoo should not be a place for this purpose.

Thoughts? Isn't there anyone else willing to keep Nazi symbols outside
forums? If yes, at the expense of punting all politics or just as a
special case?

Regards,

PS.1 - An apology for forum mods because the avatar I've been using
may offend them, my purpose was to raise awareness of the issue of
using extremely offending content on the forums. While I think my
avatar is valid, I prefer to calm things down and try to work out the
issue with forum mods without attacking. I decided to remove the
avatar.

PS.2- Before someone says Godwin, this is not using Nazis in a
discussion about something else, this is directly a discussion about
Nazi symbols.

[1] http://forums.gentoo.org/viewtopic-t-480537.html

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: OT: [gentoo-dev] Nazi symbols on Gentoo (and other offending content)

2008-04-27 Thread Santiago M. Mola
On Mon, Apr 28, 2008 at 1:57 AM, Petteri Räty [EMAIL PROTECTED] wrote:
 Santiago M. Mola kirjoitti:

 
  Thoughts? Isn't there anyone else willing to keep Nazi symbols outside
  forums? If yes, at the expense of punting all politics or just as a
  special case?
 
 

  Again this is the wrong mailing list. I don't see this thread having any
 technical content.


Actually I thought about it, but it seems @-project has no attention
from developers, and what I want to know if is more developers see
this as a problem, or not, or just don't care (if the later is the
case, the thread will just die shortly).

Anyway, next time I'll use @-project, and let's see if someone
actually cares about that mailing list.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


Re: [gentoo-dev] lastrite: sys-apps/systrace (security/treecleaners)

2008-04-21 Thread Santiago M. Mola
On Mon, Apr 21, 2008 at 9:01 PM, Samuli Suominen [EMAIL PROTECTED] wrote:
 # Samuli Suominen [EMAIL PROTECTED] (21 Apr 2008)
  # Masked for removal in 30 days. Doesn't build
  # wrt bug 178036 and has open CVE-2007-4773 wrt
  # security bug 203195.
  sys-apps/systrace
  --
  gentoo-dev@lists.gentoo.org mailing list



http://www.citi.umich.edu/u/provos/systrace/systrace-1.6e.tar.gz

1.6e solves the security problem. Just in case someone wants to fix it.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Dependencies that're available at pkg_*inst

2008-04-20 Thread Santiago M. Mola
On Sun, Apr 20, 2008 at 10:36 AM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
 On Sat, 19 Apr 2008 18:29:10 -0700
  Brian Harring [EMAIL PROTECTED] wrote:

   Stop name dropping labels until you tell folk about what labels are.
   I know, but I'd rather not have the notion labels solves all pushed
   forth w/ out people knowing what it is, please.

  Labels are already documented and discussable in the appropriate place.
  This is not supposed to be a discussion about future direction. It's
  supposed to be about one specific issue regarding how we word things for
  current implementations. The two wordings in the original email do not
  have equivalent implications, and selecting the correct one affects
  whether certain problems are solvable. Let's discuss that, not what
  we're going to do six years from now.


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

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: New global USE flag: keyring

2008-04-20 Thread Santiago M. Mola
On Sun, Apr 20, 2008 at 6:17 PM, Peter Weller [EMAIL PROTECTED] wrote:
 On Sun, 2008-04-20 at 18:06 +0200, Tiziano Müller wrote:
  
   I'd say we should convert it to a global use flag now with a good
   description and change it to gnome-keyring later in case we really have a
   package which needs 'keyring' for something else.
  I agree with what dev-zero just wrote there.


That's unlikely to happen. When a program needs 'keyring' for
something else, the maintainer will see that 'keyring' is used for
'gnome-keyring' and will choose another name ('foo-keyring').

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
���^�X�����(��j)b�b�

Re: [gentoo-dev] Re: escaping variables in sed expressions

2008-04-17 Thread Santiago M. Mola
On Thu, Apr 17, 2008 at 6:31 AM, Duncan [EMAIL PROTECTED] wrote:

  While you are almost certainly correct on POSIX/Unix filenames and the
  shell won't accept / in a filename, IIRC (from reading) it's often
  possible for C programs to code a literal / in a filename, and possible
  for some filesystems (also written in C, generally) to accept it.  Thus,
  while POSIX/Unix standards don't allow it, in practice, it's sometimes
  possible, if rare.

If that's possible, we shouldn't support it anyway. If someone wants
to use /var/tmp/port\/age we'll just stab him, if someone releases a
tarball with such filenames we'll stab him, too.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Early stabilisation

2008-04-17 Thread Santiago M. Mola
On Thu, Apr 17, 2008 at 2:33 PM, Samuli Suominen [EMAIL PROTECTED] wrote:
 Thu, 17 Apr 2008 09:43:59 +0200
  Vlastimil Babka [EMAIL PROTECTED] kirjoitti:

   Okay. So we can just agree it's better if the maintainer tells his
   reasons when opening the bug, to spare the later clarifications?

  It works. Do it.


While I agree with you, and I think we are free to request
stabilization before the 30 days window, I also love when people give
details about the stabilization and not just a do it.

Emacs team's test plans [1] are the better example. Thanks to them
I'm able to save a _lot_ of time figuring out how a package works and
which features should test.

Some details about changes since last stable are usually useful too.
In latest wgetpaste stabilization [2] we are told that this is a
trivial bugfix release fixing osl support, so we can just test osl
support and skip most of other tests.

Also, when a program needs a sample file with some obscure format, I
really appreciate when maintainers give a URL to a sample file so I
don't need to search for suitable files and can strictly focus on
testing.

Of course, everyone could continue with the do it style, but keep in
mind that adding info like I described above can save a lot of AT work
and, as a result, make stabilization process faster.

[1] http://overlays.gentoo.org/proj/emacs/wiki/test%20plans
[2] http://bugs.gentoo.org/show_bug.cgi?id=211894


Regards,
-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] escaping variables in sed expressions

2008-04-15 Thread Santiago M. Mola
On Tue, Apr 15, 2008 at 1:14 PM, Marijn Schouten (hkBst)
[EMAIL PROTECTED] wrote:

  Hi list,

  it seems I have been using some fragile sed expression and I'd like to tap
 the collective
  wisdom for avoiding doing that in the future.

  dev-scheme/slib-3.1.5-r1 currently does

  sed s_prefix = /usr/local/_prefix = ${D}/usr/_ -i Makefile

  to make it not violate the sandbox. However a user had set
  PORTAGE_TMPDIR=/home/gentoo_overflow/tmp causing the sed expression to
 contain too may
  underscores and failing.[1]

  There are several option to handle this. I could use a less common
 delimiter or I could
  escape it: ${D//_/\_} instead of ${D}. I could use a sed expression that
 doesn't suffer
  from this problem (thanks to dleverton):

  sed -ne '\_^prefix = /usr/local_!{p;d}' -e iprefix = ${D} -i Makefile

  Comments?


Currently is use ':' as sed delimiter when paths are involved. I'd
also like to hear from you about proper delimiters if you think ':' is
not safe enough.

AFAIK, the only corner case which would make this fail would be
Windows paths (C:/gentoo-prefix).

Regards,

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: [gentoo-dev-announce] New developer: Thomas Sachau (tommy)

2008-03-21 Thread Santiago M. Mola
On Thu, Mar 20, 2008 at 7:07 PM, Petteri Räty [EMAIL PROTECTED] wrote:
 Part of the ever growing German conspiracy, we have Thomas (tommy)
  Sachau. He will be joining us to help with the pile of broken ebuilds
  that some people call the Sunrise overlay. He has previously contributed
  to the Freenet project. On his free time he likes listening to music and
  attending concerts. On IRC you can find him as Tommy[D].


Welcome Tommy!

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


Re: [gentoo-dev] New developer: Tobias Klausmann (klausman)

2008-03-10 Thread Santiago M. Mola
On Mon, Mar 10, 2008 at 10:13 PM, Petteri Räty [EMAIL PROTECTED] wrote:
 One of those people working on those weird paper weights. This time our
  monkey comes from the world of alphas. Tobias hails from Germany (there
  seems to be no end). He works as a sysadmin so perhaps he will some idea
  about stability. He is the author of pymetar and carl (emerge and try).
  Here's how he tells about himself: I'm an avid motorbike rider (*not* a
  biker!), I enjoy electronic music and good SF literature and graphic
  novels. Photography is another hobby (which I find too little time for).
  I've been the admin of the Alpha Arch Team's main dev machine since it
  was donated (mid-May 2007). Also, I run rsync5.de.g.o and have been
  doing so since about mid-2002.

Welcome Tobias!

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


Re: [gentoo-dev] New keyword monkey: Kenneth Prug (ken69267)

2008-03-08 Thread Santiago M. Mola
On Sat, Mar 8, 2008 at 9:33 PM, Thomas Anderson [EMAIL PROTECTED] wrote:
 On Saturday 08 March 2008 12:30:17 Petteri Räty wrote:
   Joining us from the zoos of Florida, we have Kenneth keninsert random
   numbers here Prugh. Ken did such a fine job testing all those random
   packages for amd64 that it will be the sole purpose of his life from now
   on. He tells me his hobby is to learn new programming languages so I
   guess he doesn't get bored easily. Time for the usual spanking everyone.
  
   Regards,
   Petteri


  use adjutrix || die failee!

  And goodbye most active Arch Tester!


And hello most active amd64 dev (I hope) ;-)

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
���^�X�����(��j)b�b�

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

2008-03-05 Thread Santiago M. Mola
On Wed, Mar 5, 2008 at 6:11 PM, Anant Narayanan [EMAIL PROTECTED] wrote:
  Some of you may argue that we already have proxy-maintainers. That's a
  great idea, all I'm asking for is for us to formalize the position.
  Giving a proxy-maintainer an official acknowledgement will definitely
  attract more users to contribute.

IMO the problem with proxy-maintainers is that most users don't know
such a thing exists. I bet some users could proxy-maintain a lot of
orphaned packages if we potentiate proxy-maint.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



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

2008-03-02 Thread Santiago M. Mola
On Sat, Mar 1, 2008 at 7:45 PM, Christian Faulhammer [EMAIL PROTECTED] wrote:

   What we propose is proper testing and keywording by anyone
  around...not just team members.


Writing test plans like emacs team does really helps too. I waste too
much time figuring out how to test properly some packages, and I'm
sure me and other ATs miss a lot of important use cases.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Keyword request interface (SoC candidate?)

2008-02-28 Thread Santiago M. Mola
On Thu, Feb 28, 2008 at 10:43 PM, Alec Warner [EMAIL PROTECTED] wrote:
 cvs.gentoo.org:/var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/index2008.xml

  Add it ;)


I'm not 100% sure this is a good idea, that's why I'm asking for
opinions here ;-)

Also, I doubt I can mentor.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] The future of ebuild

2008-02-24 Thread Santiago M. Mola
On Sun, Feb 24, 2008 at 12:02 PM, Felipe Contreras
[EMAIL PROTECTED] wrote:
 On Thu, Feb 21, 2008 at 2:29 PM, Duncan Coutts [EMAIL PROTECTED] wrote:
   
Why not create a new build system with a state of the art programming
language, and an advanced DSL that actually other distributions could
use?
   
I would like to hear your opinions on this matter.
 
   Take a look at Nix. It's a distribution-agnostic package manager that
   uses a purely functional DSL for package specifications.
   http://nix.cs.uu.nl/index.html

 That's exactly what I'm taking about :) I'll try it out. Thanks for
 sharing the link.

 Is there any interest in the Gentoo community to migrate to Nix?


This is not going to happen. Migrating to Nix means rewriting the
distro from scratch.  If you´re interested in a distro built on top
of Nix, you can try NixOS (which looks really nice IMO).

Regards,
Santiago

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
���^�X�����(��j)b�b�

Re: [gentoo-dev] Re: I want to steal your tools

2008-02-05 Thread Santiago M. Mola
On Feb 5, 2008 4:21 AM, Ryan Hill [EMAIL PROTECTED] wrote:
 Heath N. Caldwell wrote:
  On 2008-02-04 14:51, Ryan Hill wrote:
  Can someone provide a tool that given a package name simply prints the
  category or cat/pkg, or if ambiguous, prints the multiple cat/pkgs or
  returns an error code?  I don't care what it's written in as long as it's
  relatively quick.  I'm sick of depending on udept (which is an incredible
  tool but a lot heavy for a simple shell script) just to get a simple
  category.
 
  What about something like this:
 
  --
  #!/bin/bash
 
  source /etc/make.globals
  source /etc/make.conf
 
  for i in ${PORTDIR} ${PORTDIR_OVERLAY}; do
(cd $i; a=(*/$1); [ -e ${a[0]} ]  ls -1 -d */$1)
  done | sort | uniq
  --
 
  It's really fast, at least.

 Also very good, thanks.  Instead of sourcing, we can instead use

 $ portageq envvar PORTDIR
 $ portageq portdir_overlay

 How do paludis and pkgcore make this info available?

You can get PORTDIR with:
paludis --configuration-variable gentoo location

AFAIK, PORTDIR_OVERLAY is more tricky:
for r in $(paludis --list-repositories | sed -e s/^*\ //g) ; do
if [[ $(paludis --configuration-variable ${r} format) = ebuild ]] ; then
paludis --configuration-variable ${r} location
fi
done


-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] gentoo-commit messages for SVN

2008-02-04 Thread Santiago M. Mola
On Feb 4, 2008 12:54 PM, Robin H. Johnson [EMAIL PROTECTED] wrote:

 Included:
 pybugz

 If you think a repo is on the wrong side, please respond here!


This is no longer in use and can be even removed.

It's now an external project, hosted on http://code.google.com/p/pybugz/

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] debianutils: system worthy ?

2008-01-30 Thread Santiago M. Mola
On Jan 30, 2008 6:35 PM, Philip Webb [EMAIL PROTECTED] wrote:

 'equery d debianutils' gives me

   app-admin/sysklogd-1.4.2_pre20061230 (sys-apps/debianutils)
   app-portage/gentoolkit-0.2.3-r1 (userland_GNU? sys-apps/debianutils)
   sys-apps/mktemp-1.5 (=sys-apps/debianutils-2.16.2)

 The 2nd cb ignored, but the others seem important.
 I have Mktemp-1.5 installed, so what do you mean by your lines 1-2 ?
 Sysklogd seems to be an important pkg too.
 What am I missing (smile) ?

Removing debianutils from the system _set_ doesn't mean to completely
remove it from the portage tree or user systems. It'll be a dependency
of sysklogd and mktemp anyway. This change does not affect you.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: removal of digest files from the tree

2008-01-30 Thread Santiago M. Mola
On Jan 31, 2008 12:32 AM, Robin H. Johnson [EMAIL PROTECTED] wrote:

 On Thu, Jan 31, 2008 at 12:05:26AM +0100, Vlastimil Babka wrote:
  Chris Gianelloni wrote:
  I think throwing up an announcement today/tomorrow for Thursday/Friday
  should be sufficient for this sort of a change, as it won't affect any
  user who has a version of portage released in the past ~1.5 years.
  So, since it seems nobody objected it, time for the announcement? And the
  removal (server-side by robbat2) would be best done right before the
  snapshot?
 It's pretty much irrelevant to the snapshot. wolf31o2 has my patch to
 exclude digests in the snapshot anyway.


Then I guess it could be done as soon as the doc patch is prepared...

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: removal of digest files from the tree

2008-01-28 Thread Santiago M. Mola
On Jan 28, 2008 2:44 AM, Chris Gianelloni [EMAIL PROTECTED] wrote:
 I think throwing up an announcement today/tomorrow for Thursday/Friday
 should be sufficient for this sort of a change, as it won't affect any
 user who has a version of portage released in the past ~1.5 years.

+1, too.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Packages up for grabs

2008-01-20 Thread Santiago M. Mola
On Dec 25, 2007 7:19 PM, Christian Heim [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED]:
  - x11-misc/xdesktopwaves

desktop-misc takes this, if someone wants to get maintainership go ahead.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

2008-01-19 Thread Santiago M. Mola
On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] wrote:

 Current state: Deferred
 Wanted state: Accepted/Implemented (at least by me)

The GLEP should be updated. Motivation section does not seem to
justify the changes. IMO Meatoo [1]  (and its hipothetical rewrite
using Doapspace [2]) would be the right tool to detect version bumps.
Maybe metadata.xml should contain a  Freshmeat or DOAP entry so meatoo
could get more automation.

Anyway, I don't know how much would take the new version of meatoo.
Pythonhead, could you give us some news about it? Or it's just planned
for the long-term future?


[1] http://meatoo.gentooexperimental.org/
[2] http://blog.doapspace.org/

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


Re: [gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml

2008-01-19 Thread Santiago M. Mola
On Jan 19, 2008 4:13 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
Possibilities:
  An element: status{active/inactive}/status
 
  Status of what? seeing you have proposed a upstream-status and a
  maintainer status. what else is there left to status :P
 There will be a maintainer tag within the upstream/upstream, not the
 same as our already existing maintainer

 But the question I tried to express (probably not clear enough) is:
 Should (if at all) the status being tracked for upstream or for
 maintainer (within upstream).

 As an example dev-libs/xmlwrapp: The original maintainer is inactive, but
 there is a new one who took the package to sourceforge and it's not a fork
 since the original maintainer agreed up on this. Should such a case be
 tracked at all?


I think we don't want to track if previous maintainer is active or
not, or if it's changed. In your example, the important data is who
is the current maintainer and how to contact him and is she
active?. Keeping an entry for the old maintainer as inactive when
there's a new one is not like an useful piece of info.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
���^�X�����(��j)b�b�

Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

2008-01-19 Thread Santiago M. Mola
On Jan 19, 2008 4:24 PM, Denis Dupeyron [EMAIL PROTECTED] wrote:
 On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
  Your oppinion?

 Would this be the right time to discuss about moving other variables
 to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those
 hardly change and if they ever do we can restrict them to specific
 versions. I know there could be technical hurdles, but what do you
 think of the idea at least ?


I'm not sure about HOMEPAGE and DESCRIPTION, but I think LICENSE
should be per-ebuild variable. A license change is not so strange
(GPL-3, double licensing the source, or adding new artwork licensed
with a more restrictive license). Moreover, a license change does not
need to be retroactive, so using a global variable in metadata.xml
could lead to accidentally show a wrong license for old versions.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


Re: [gentoo-dev] Seeking questions for a user survey

2008-01-14 Thread Santiago M. Mola
On Jan 14, 2008 1:33 PM, Robin H. Johnson [EMAIL PROTECTED] wrote:
 Ok, so per the one discussion in #-dev this evening, I'm looking for
 questions to put on a new user survey.

An interesting question would be Which package manager do you use?.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] USE flag documentation

2008-01-13 Thread Santiago M. Mola
On 1/14/08, Yuri Vasilevski [EMAIL PROTECTED] wrote:

 [ebuild   R   ] media-video/mplayer-1.0_rc2_p24929-r2  USE=X cdio -aac#1 
 -cdparanoia#2 -encode ...

 #1 aac needs encode
 #2 cdio conflicts with cdparanoia

This can be implemented with use.desc/use.local.desc. Paludis already
does that by default.

 But this logic will have to be exposed on a .ebuild level.


I don't think this is worth an EAPI change, or adding new variables to
ebuilds. metada.xml USE flag documentation could be extended to cover
such cases if it's really needed... but is it?

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] USE flag documentation

2008-01-13 Thread Santiago M. Mola
On 1/14/08, Santiago M. Mola [EMAIL PROTECTED] wrote:
 On 1/14/08, Yuri Vasilevski [EMAIL PROTECTED] wrote:
 
  [ebuild   R   ] media-video/mplayer-1.0_rc2_p24929-r2  USE=X cdio -aac#1 
  -cdparanoia#2 -encode ...
 
  #1 aac needs encode
  #2 cdio conflicts with cdparanoia

 This can be implemented with use.desc/use.local.desc. Paludis already
 does that by default.


Sorry. Paludis shows USE flags, and overrides definitions with use.local.desc.
But stuff like aac needs encode  and cdio conflicts with
cdparanoia should be something separate from USE flag documentation.
As you said, it should be handled at ebuild level.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Improving use.desc

2008-01-04 Thread Santiago M. Mola
On Jan 4, 2008 6:31 AM, Donnie Berkholz [EMAIL PROTECTED] wrote:

 Are there any programs (make.conf / USE editors) that manage to read and
 set that stuff?


Paludis read and show them.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Improving use.desc

2008-01-02 Thread Santiago M. Mola
 scripts.
+vim-syntax - Pulls in related vim syntax scripts

Regards,
Santiago

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-28 Thread Santiago M. Mola
On Dec 28, 2007 1:03 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:

 There's no particular reason that new
 version formats can't be introduced in a new EAPI so long as the
 version strings don't appear in ebuilds using older EAPIs or in
 profiles. Ditto for naming rules.


Errr... so should we use new files in profiles for such new formats?
(for example, p.masking an ebuild with a new version format).

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-28 Thread Santiago M. Mola
On Dec 28, 2007 1:28 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
 On Fri, 28 Dec 2007 13:25:13 +0100
 Santiago M. Mola [EMAIL PROTECTED] wrote:
  On Dec 28, 2007 1:03 PM, Ciaran McCreesh
  [EMAIL PROTECTED] wrote:
   There's no particular reason that new
   version formats can't be introduced in a new EAPI so long as the
   version strings don't appear in ebuilds using older EAPIs or in
   profiles. Ditto for naming rules.
 
  Errr... so should we use new files in profiles for such new formats?
  (for example, p.masking an ebuild with a new version format).

 Possibly. Currently there's simply no way of doing it, nor of using
 non-EAPI-0 features anywhere in profiles (you can't, for example, use
 slot deps in package.mask).


It'd be nice to agree a new profile format before accepting version
format changes.

In the case of slot deps, it'd be desirable to use them in
package.mask, just desirable. But with version format changes we're
introducing ebuilds which can't be handled in package.mask, that's a
great loss of functionality.

GLEPs 54 and 55 could wait until we have figured out how to apply them
properly and without loss of current functionality.

--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [RFC] Some new global USE-flags

2007-12-21 Thread Santiago M. Mola
On Dec 20, 2007 10:48 PM, Jan Kundrát [EMAIL PROTECTED] wrote:
 Santiago M. Mola wrote:
  These are potentially ambiguos.

 Could you please elaborate a bit about the raw one?


Just that raw could mean more things. Anyway, I have no problem with
that since current packages in the tree use it as raw image format
and new packages which need such flag for a different meaning could
set it to something more meaningful.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


Re: [gentoo-dev] [RFC] Some new global USE-flags

2007-12-20 Thread Santiago M. Mola
On Dec 20, 2007 7:57 PM, Markus Meier [EMAIL PROTECTED] wrote:

 raw: Add support for raw image formats
 keyring: Enable gnome-keyring support for storing passwords


These are potentially ambiguos.

I have no objections for the others.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-20 Thread Santiago M. Mola
On Dec 20, 2007 8:01 PM, Zhang Le [EMAIL PROTECTED] wrote:

 How many EAPI's do we have now?

In Portage tree we have 0 (default) and 1. There are others in
external projects, for example prefix (in Gentoo/Alt:Prefix) or
paludis-1 (used in paludis repositories).

 Where is the detailed definition of those EAPI's?

0, 1 and any further official EAPI are defined in PMS. There's a
svn repository at http://svn.repogirl.net/pms

 How can we produce a new EAPI?

I can't tell you the exact process, but look at EAPI bug trackers or
search for bugs assigned to [EMAIL PROTECTED] Also, search in
@-dev's archive.


 IMO, we can not have more than two EAPI's simultaneously.
 The only situation in which we can have two EAPI is in the transition period
 of those two EAPI's. And we should set a time constraint on the transition.


Quite the opposite. EAPI's are designed to live happily together in
the same repository. A current example: most (or lots...) ebuilds in
the tree don't need EAPI=1 and it's pointless to migrate all of
them. We can switch EAPI on an as needed basis.

 Other than that we can only have one working EAPI which all package managers
 conforms to.

Read above, and other discussions. That's also pointless because we
don't need to force all third party overlays to upgrade EAPI everytime
we have a new one...

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-18 Thread Santiago M. Mola
On Dec 18, 2007 6:37 PM, Ulrich Mueller [EMAIL PROTECTED] wrote:
  On Tue, 18 Dec 2007, Fernando J Pereda wrote:

   It seems to me that this will inconvenience the users, in order to
   solve a technical problem of the package manager.
 
  Absolutely, +1.  This does indeed sound like a technical issue; how
  would requiring a dev to manually mirror the EAPI in the filename
  extension provide any benefit over caching it behind the scenes (using
  the Manifest file or similar mechanism)?

  You are yet to show what kind of inconvenience to the users this
  proposal will cause.

 One example was mentioned in this thread before: You cannot use
 find -name '*.ebuild' anymore.


So people could use a bit more elaborated expression to find them.
Things like this shouldn't be a reason for not applying
EAPI/GLEPs/PM-behaviour changes. If this GLEP is approved, it would be
fine to publish a quick guide of recipes to migrate scripts which rely
on the old naming convention and that should be enough.

IMO, keeping us away from improvements to Gentoo because they break
backwards compatibility with third party scripts is a no-go. Of
course, this kind of changes can't happen once a month, but they can
happen from time to time.

Regards,
Santiago

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Ebuilds I lastrited month ago for treecleaners, time to look at them once more.

2007-12-15 Thread Santiago M. Mola
On Dec 15, 2007 8:00 AM, Samuli Suominen [EMAIL PROTECTED] wrote:
 x11-wm/flwm (Coldwind promised to take a look at this, it needs a
 patched fltk.)

Both fltk and flwm fixed. x11-wm/flwm should go out of p.mask when
fltk and flwm get proper keywords again.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] EAPI placement

2007-12-12 Thread Santiago M. Mola
On Dec 12, 2007 1:21 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
 On Tue, 11 Dec 2007 16:59:28 -0500
 Doug Klima [EMAIL PROTECTED] wrote:
  discuss.

 * EAPI may only be set before the 'inherit' in an ebuild.

 * Eclasses may not set EAPI.

 * Eclasses may not assume a particular EAPI.

 * If an eclass needs to work with multiple EAPIs, EAPI-specific code
 should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code
 and a conditional inherit should remain in foo.eclass.

It seems the most reasonable option I've read until now.

Would it be possible to have eclass/eapiBLAH/foo.eclass?

 * Eclasses cannot be made not to work with any given EAPI. If such
 functionality is desirable, someone needs to file an EAPI request for
 permitting an alternative to 'die' that is legal in global scope.

So is it desirable?

If portage masks ebuilds with an unsupported EAPI, what's the point?
It'd be enough to be able to check EAPI compatibility in eclasses
quickly so repoman and others can print a nice error.

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [RFC] gnupg-2 stable plans

2007-12-12 Thread Santiago M. Mola
On Dec 12, 2007 4:08 PM, William L. Thomson Jr. [EMAIL PROTECTED] wrote:
 On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote:
  On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote:
   Alon Bar-Lev wrote:
As I told you before, I wont slot these two.
  
   Could you provide a link to reasons that lead you to this decision so
   that interested readers can make their own opinion?
 
  http://bugs.gentoo.org/show_bug.cgi?id=159623

 Again while there might not be technical issues, what is not covered
 there in the bug is why rob users of a choice? Why make users mask a 2.0
 version that's in the same slot as a 1.4.x version. Given that both will
 be actively maintained.

In short:
* It's upstream's choice.
* 2 is actively maintained and there's no deprectation planned.
* It's not a true drop-in replacement, even if it's fully compatible
with all packages in the tree.
* In some cases, people could get a benefit of using gpg-1, instead of gpg-2.
* There's no need of an eselect module, since gpg2 is supposed to be
called gpg2 and not just gpg.
* Again, it's upstream choice and, after considering the
possibilities, there's no major reason for not following it.

What else is needed for using SLOTs?

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]


Re: [gentoo-dev] EAPI placement

2007-12-12 Thread Santiago M. Mola
On Dec 12, 2007 11:14 PM, Carsten Lohrke [EMAIL PROTECTED] wrote:
 On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
  * Eclasses may not set EAPI.
 
  * Eclasses may not assume a particular EAPI.

 I disagree here. It would be annoying and possibly even hindering in future
 not being able to use higher EAPI features in eclasses. Point is the eclass
 has to check, if the author of an ebuild sets another EAPI and throw an
 error, in this case.

Nobody said that eclasses can't use new features. Just that they
cannot _set_ EAPI or assume they are working with any EAPI. But an
eclass can check which EAPI is set in the environment (that's which
EAPI the ebuild set) and act accordingly, using features available on
that EAPI.


 The most basic issue, which we didn't even discuss yet, afaik, is how to make
 every developer aware which feature belongs to which EAPI. I freely admit, I
 do not know that. Is there a list somewhere?

EAPIs are defined in PMS [1] although I don't find an officla copy
at gentoo.org (only the one in dev.g.o/~spb).


 EAPI issues may lead to a lot of confusion and eclass bloat, especially since
 we still can't remove stale eclasses afaik.


Yep, that issue should be addresses as it is in paludis and pkgcore.

[1] http://www.gentoo.org/proj/en/qa/pms.xml

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



  1   2   >