ntributed
> 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]
x = /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 c
/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
nd 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%20pla
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
for
'gnome-keyring' and will choose another name ('foo-keyring').
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
���^�X��� ��(��&j)b�b�
pps/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
omething 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
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
> &
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
~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
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
> >
.
>
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
ovided 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
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
e nice to preserve a method for allowing
lurkers on aliases.
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
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
word 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�
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.
Reg
ie 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
.
(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
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).
Regard
t 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 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'
sn't seem to make the problem simpler.
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
ny 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.g
x27;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
ve 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
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 i
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�
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
#x27;t continue with these points in
this thread.
Thanks,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
permail/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
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,
--
Sant
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]
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.
>> Furthe
enced 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]
..
>
Good luck with that project!
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
l 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]
criptions 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]
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]
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'
quot;
"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]
ity 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]
ns 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]
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]
$(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 )
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 r
at
>> least).
>>
>> Thanks, Joe
>
> Yes, and usually that's how it's done. Eg eix' metadata.xml says:
>
>
>[EMAIL PROTECTED]
>Martin Väth
>
>
Yep. And for more completeness you can add something like
Proxied maintainer. Although, it's quite
obvious when it's a non-Gentoo email.
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
roblem 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]
ke 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]
ou'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]
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
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
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.
>
>
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 t
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 sta
re everyone in this list state his
opinion about what communication methods are more effective.
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
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 al
(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 i
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
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 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
igher
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
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 scrip
-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
ding, 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
urn. 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
bugz:
$ bugz attachment
that will download it with the proper name.
Regards,
--
Santiago M. Mola
Jabber ID: cooldw...@gmail.com
ild 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
t 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
On 6/27/07, Luis Francisco Araujo <[EMAIL PROTECTED]> wrote:
Bienvenido Santiago!
One more developer from our #gentoo-es conspiracy!
Fear us!
Thanks all for the warm welcome.
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
On 7/14/07, Petteri Räty <[EMAIL PROTECTED]> wrote:
It's a joint pleasure for me and diox to introduce to you Pierre-Yves
"py" Rofes. Instead of the snake people he will be joining our security
team.
Please give him the usual flamy welcome.
PyWelcome!
--
Santiago M. M
of bug #27727, comment #2 ;-)
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
n as a new fellow developer among us !
>
Welcome!
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
llow developer among us !
Welcome!
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
.
>
> Wasn't that going to be removed due to a dispute re its licence ?
> Perhaps that got resolved without my noticing (smile).
>
There's no problem with ion2. That's with ion3.
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
dvent of ion3 stable in my overlay there's no use to keep it.
>
x11-wm/ion2 (and "ion1") is under desktop-wm herd maintainance now.
Let's file a bug, write to @desktop-wm or come to #-desktop if you
still want to remove it.
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
think it's an optimal solution, but adding a new local USE for
every tiny feature would be annoying, and USE="gnome-panel" or
USE="gnome-applets" flag is pretty senseless.
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
to test it.
>
> If you own this hardware, please take maintainership of this package.
>
I took its maintainership.
Regards,
Santiago
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
d at any
time (not only after installing a package). It'd be more reliable than
current pkg_postinst messages.
Regards,
Santiago
--
Santiago M. Mola
--
[EMAIL PROTECTED] mailing list
they are going to use?
>
Are they inconditional runtime deps? This looks like another case
where RECOMMENDS would be useful.
--
Santiago M. Mola
a bug asking for doc
update for the commited changes.
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
better
examples, but those are the ones I have right now.
Regards,
Santiago
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
r/portage/net-p2p/bittornado/files/bittornado.desktop
* desktop-file-validate /usr/portage/net-p2p/mldonkey/files/mldonkey-gui.desktop
Fixed.
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
ycle (as other people pointer out... ignoring the
community). So, I agree with people asking for freezing the use of the
new features until a GLEP is proposed, discussed and approved.
Regards,
Santiago
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
s to show you which branch you're getting.
>
Too tricky. It would confuse package managers and would break the
meaning of SLOT. An use expanded SCM_BRANCH combined with use
dependencies makes more sense and, hopefully, would be something
manageable.
Regards,
Santiago
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
ning behind them.
> > [...]
For my reasoning... just read Ciaran's reply ;-)
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
egal 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
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]
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
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. Mo
MO, 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
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
rate 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
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
itto 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
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:
> > > Ther
SVG (Scalable Vector Graphics).
+svg - Adds support for SVG (Scalable Vector Graphics)
-tiff - Adds support for the tiff image format
+tiff - Adds support for the TIFF image format
-vim-syntax - Pulls in related vim syntax scripts.
+vim-syntax - Pulls in related vim syntax scripts
Regards,
Santiago
ulaw multi null plug rate route share shm softvol"
APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon
authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache dav
dav_fs dav_lock deflate dir disk_cache env e
gain on this list.
>
I'm sure most people here want to hear major announcements about OpenRC.
At the moment, I'm emailing my OpenRC issues directly to you ;-)
Best regards,
Santiago
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
1 - 100 of 123 matches
Mail list logo
