:
layman -a gnome
Things to remember :
- don't try to install Gnome 2.22 on a *stable* system. If you do and
things break, you get to keep all the pieces.
- if you have bugs, don't report them here, use bugzilla with the
Gnome component.
Enjoy
--
Rémi Cardona
LRI, INRIA
[EMAIL
pkgs at all and the Portage support is
what it is.
+1 on that and if people who use binary pkgs don't tell us what breaks,
we won't know.
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
ked as fixed,
showing me that your patches got accepted. :) Which is good... isn't it?
I, for one, encourage you to keep opening bug reports.
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Fabio Erculiani a écrit :
I might found around 150-200 bugs on (R)DEPEND. Take 200 on about 6500
packages we have in our repository, if I take 5 minutes each, I'd end
up to take 16 hours.
Then open a reduced number of bugs, say one per portage category that
has over 20 bugs and group the rest
Hi folks,
During the past few weeks, I've been working on fixing and improving the
Gnome2 eclasses wrt bug #155993. We plan on pushing these eclasses to
portage before the Great Gnome 2.22 Unmask so that users can start
benefiting from the improvements during the upgrade to 2.22.
URL :
http
Denis Dupeyron a écrit :
On Fri, Mar 14, 2008 at 8:14 AM, Rémi Cardona <[EMAIL PROTECTED]> wrote:
- the gnome2 eclass now has a pkg_preinst, if you do multiple
inherits, make sure that gnome2_pkg_preinst is called too. The
_games_eclass_ is one of those.
[...]
*Please* review
David Leverton a écrit :
On Friday 14 March 2008 07:14:23 Rémi Cardona wrote:
- the gnome2 eclass now has a pkg_preinst, if you do multiple
inherits, make sure that gnome2_pkg_preinst is called too. The
_games_eclass_ is one of those.
Maybe worth adding a dummy to the current version of the
Torsten Rehn a écrit :
Two weeks ago, dirtyepic suggested making some modifications to how ATs and
developers interact using Bugzilla [1].
<+jakub> scel: basically... instead of KEYWORDREQ/STABLEREQ
<+jakub> create keywording and stabilization components
<+jakub> and use flags accordingly there
Raúl Porcel a écrit :
So, firefox-3, seamonkey-2, thunderbird-3 and other mozilla products
will be using xulrunner-1.9, which is the codebase the mozilla products
are based on. In fact, everytime you emerge any of those apps, you're
compiling xulrunner, which takes 90% of the time to build. The
Torsten Rehn a écrit :
On Saturday 15 March 2008, Rémi Cardona wrote:
Just curious, who would be the default assignee for those 2 new components?
I don't think anything should be changed here. Unpriviledged users
automatically assign to bug-wranglers, everyone else goes for the t
Christian Faulhammer a écrit :
Don't install COPYING.
Could repoman have a QA warning for COPYING inside DOCS="" and dodoc ?
Cheers,
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
stinst pkg_postrm
+EXPORT_FUNCTIONS src_unpack src_compile src_install pkg_preinst
pkg_postinst pkg_postrm
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Nirbheek Chauhan a écrit :
Shouldn't this function be
gnome2_pkg_preinst() {
:
}
? Because bash chokes on empty functions..
I was actually planning on using a bogus debug-print statement :) but
thanks for letting me know.
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
Petteri Räty a écrit :
http://archives.gentoo.org/gentoo-dev/msg_a57bf5f459324975bae8843fe7cdf469.xml
Sorry I didn't respond to you Petteri, but this is clearly missing
packages. For sure, it's missing gnome-games which inherits both the
gnome2 and the games eclasses. So I made the assumptio
Bo Ørsted Andresen a écrit :
On Tuesday 18 March 2008 00:42:02 Gilles Dartiguelongue wrote:
Now, basically, if the portage metadata or QA people could tell me a way
to figure *all* the ebuilds that inherit gnome2 *and* have a
pkg_preinst() function somewhere (either in the ebuild or in an eclass
What would be the point of such a change? What problem are you trying to
solve or to improve?
You'll need to answer those questions anyway should you ever need to
write a GLEP for that.
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gento
Steve Long a écrit :
First and foremost to give an environment wherein people can write their
installation scripts using the language they are most comfortable with.
If bash is not "easy" or straightforward enough for what you are trying
to achieve, then I'd say the package is broken (ie, hand
e yet with all the
bells and whistles to improve performance, and the concerned ebuilds
have been updated.
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
# Rémi Cardona <[EMAIL PROTECTED]> (12 Apr 2008)
# Masked for removal in 30 days. Still builds but
# nothing in the tree deps on it, upstream dead
# See bug #191855
dev-libs/libsigcx
We don't actually know of _any_ upstream project using that library...
Cheers,
Rémi
--
Duncan a écrit :
Whatever your faults, you /do/
tend to be quite accurate on such things.
Wow, you've managed to turn a nice technical discussion (which is rare
enough in recent history) into a let's-start-bashing-people thread.
You've lost all credibility in just one sentence... Pity.
If i
Hanno Böck a écrit :
Recently, GIMP got it's first development version based on gegl.
Sweet :)
Is there some brave gentoo dev (or non-dev, doesn't really matter)
volunteering to send patches to gegl-upstream?
I would really like to say that I can do it for you, but I'm very time
limited, s
Enrico Weigelt a écrit :
* Luca Barbato <[EMAIL PROTECTED]> schrieb:
Enrico Weigelt wrote:
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 thi
Steve Long a écrit :
Mark Loeser wrote:
Making an actual bug wrangling team (subproject of QA) is something
I've been toying around with in my head. I'd love to get an actual team
set up so we can encourage users to help us get the information we need
in bugs so it is less work for us. Several
Diego 'Flameeyes' Pettenò a écrit :
"Robin H. Johnson" <[EMAIL PROTECTED]> writes:
The sole reason that isn't possible is that some teams would have names
that conflict with system accounts. While it's possible to override
those in the Gentoo mail server setup, the system account versions DO
re
Marius Mauch a écrit :
So, do you think it should be enabled by default?
Does portage have a way to report which libraries it is keeping around
because of preserve-libs ? If there's an easy way to figure that out,
then enabling it by default is a very sane and sound idea.
Cheers,
Rémi
--
g
eded *today* does much more good than harm.
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Ulrich Mueller a écrit :
Speaking about statistics: Either I have missed it, or so far nobody
has presented any solid numbers showing what the benefit of
--as-needed in terms of memory usage or program startup time is.
The reduction in startup time may not be noticeable.
The real win is when l
net Gentoo and maybe
on the forums. If it's really important, you might want to get it
published in the official Gentoo News or the GMN.
If users don't read _any_ of those, then it's not your fault :)
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
ge
ChangeLog (too much detail) or a NEWS file
(usually not enough detail) ?
Thanks
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Peter Volkov a écrit :
Whenever you modify anything in profiles directory, please, fill in
ChangeLog. ChangeLogs became useless if only part of developers fill
them.
For additional info, echangelog works in there too as I found out a few
days ago.
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL
ata.xml) PM will have to learn to read XML (yuck)
That's about it, right?
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Ciaran McCreesh a écrit :
picard_facepalm.jpg
I don't think any of us are completely thrilled by either proposals, but
the EAPI-in-a-separate-file does have the potential for more
flexibility, ie package-wide EAPI.
And it does keep filenames simple enough.
--
Rémi Cardona
LRI,
pt for the broken compatibility, I know it's a big one) ?
This is basic stuff you really need to know before you can comment
sensibly on a discussion about package metadata.
Then, thanks for explaining those things :) We are learning stuff as we go.
--
Rémi Cardona
LRI, INRIA
[EMAIL PR
nly doubles the number
of files if there's only one ebuild in a given package :)
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Olivier Galibert a écrit :
On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote:
Ciaran McCreesh a écrit :
Kills the upgrade path completely. No good.
Lemme sum this up in layman's terms :
1) EAPI _has_ to be known before sourcing an ebuild. There's no way to
avoid that f
Ciaran McCreesh a écrit :
So how are we supposed to handle packages where upstream *require* that
anyone building from source runs 'make check'?
If it's required to get the final binaries, then it should be in
src_compile.
I don't know any package that does require such a thing, but IMHO it
ode.
Could you let us know of your progress here or on your blog? I'm
interested in maybe writing a couple tests for the gnome2* eclasses.
Thanks for your work on this :)
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
David Leverton a écrit :
Not for library consumers that use libtool but not pkgconfig.
I'd be in favor of having a _default_ configuration for Gentoo where
static binaries are never built except for some key packages (mainly for
rescue situations).
That way, in a dynamic-lib only system, l
Olivier Crête a écrit :
FOSS is the keyword here... the flash plugin dlopens a bunch of stuff
While I haven't checked, I doubt that it uses libltdl to do so :)
also kde-3.5 is using libtools dlopen for plugins
Yep, but then again, it's for plugins. The real problem is with static
linking :
Hi Marijn,
Marijn Schouten (hkBst) wrote:
PV=${PV/0./}
MY_PV=...
As others have said, PV is read only.
to that new ebuild. This is the cleanest way to do it and doesn't require any
variable name changes or any other changes to the ebuild regardless of what it
does. Unfortunately it is also
Duncan a écrit :
Probably others than GNOME, too.
Thus Mart's effort to bring it to gentoo-dev :)
This is the ticklish bit, but there's still a way around it for users
(such as those trying to fit GNOME on a liveCD) that need it. Useing
portage's bashrc, setup a conditional that excepts pac
Gilles Dartiguelongue a écrit :
Le lundi 30 juin 2008 à 13:33 -0700, Donnie Berkholz a écrit :
On 22:04 Mon 30 Jun , Gilles Dartiguelongue wrote:
PS: I'd like to remind users reading here that assigning bugs directly
is _bad_ if you didn't perform the above checks. It is _not_ ok to
assign
Enrico Weigelt wrote:
Hi,
I'm really curious to know why a new (global) useflag couldn't
do the trick.
Read Mart's mail again, that's exactly what he's proposing.
And if no-one objects, I'll be working this inside the gnome2 eclass
(with review on this list before the final commit of cours
Robin H. Johnson a écrit :
Ok, my bad. I screwed up. I changed something in cfengine, then rushed
off to a family dinner, and caused a couple of hours of bugzilla
badness because I didn't fully review my change.
http://en.wikipedia.org/wiki/Shit_happens :)
Everything should be back online in
Tiziano Müller wrote:
What do you think of them?
+1 on the first GLEP.
The second GLEP seems like a much better way of doing things, so +1 as
well, but I am no xml expert :)
Cheers,
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
Robin H. Johnson wrote:
On Fri, Jul 04, 2008 at 04:22:02PM +0200, Tiziano M?ller wrote:
One GLEP introduces new elements 'team', 'dev' and 'proxy':
http://dev.gentoo.org/~dev-zero/glep/glep-new_metadata_elements.html
1. With the addition ofcpp, why
do we still need elements?
The Gnome T
Marius Mauch wrote:
Potential problems:
- might cause trouble for some packages that use custom code for
unpacking, or due to circular deps, this could simply be solved with a
new RESTRICT value though.
As long as this is done to allow a 100% manual override, then this is a
_very_ good idea.
Fabian Groffen wrote:
Manual override as in "emerge --nodeps" or something.
No, manual override as in "the ebuild turns off auto-detection and
specifically asks for app-arch/{bzip2,gzip,tar,whatever} using DEPEND"
Cheers,
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
Duncan wrote:
Has anyone done a study of -Os vs -O2 with gcc-4.3.x,
Just a quick note while on the subject : -Os is known to break some
packages.
Although it has been a while since I've last had a full -Os system,
there was a time when -Os was a _very_bad_idea_. That's why the Gnome
Herd (
Christian Birchinger a écrit :
I use a plain XFCE setup and don't really want to install
stuff like Orbit and GConf etc.
FWIW, upcoming versions of GConf will use dbus instead of orbit for IPC.
That should reduce all the trouble we've all experienced with corba/orbit.
Cheers,
Rémi
Andrew D Kirch wrote:
Obviously the software needs to work, and therefore we need patches, but
Gentoo has not done enough to date to get them pushed upstream. Lets
look at some cringeworthy statistics on outstanding patches.
Have you even _looked_ at the patches? Can you tell which ones are :
Andrew D Kirch a écrit :
Here's the script that I used to generate this. I have not manually
reviewed all of thousands of patches to determine the unique situation
of each patch, however I would like a suggestion on how to demonstrate
_real_ statistics short of auditing each and every patch in
e "minor" licenses out :
- main software is GPL
- library is LGPL
- images/icons are CC-SA
- doc/man are GFDL, ...
As for the original question: I don't think a license change warrants a
rebuild for end users. It's just a waste of bandwidth and CPU cycles.
Cheers :)
--
Zac Medico a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Please consider a PROPERTIES=set value that allows an ebuild to
indicate that it should behave like a package set when selected on
the command line. This is behavior is somewhat difficult to describe
in words but th
Thomas Sachau a écrit :
Why not do both (rebuild and install) with the doc useflag and none of both, if
it is not set? Imho
the doc flag is for control of installation for (additional) docs, the way it
is used for gtk-doc is
surely confusing.
Building gtk-doc documentation pulls in a lot of
Daniel Gryniewicz a écrit :
> I agree. Let's just have zeroconf.
+1, zeroconf is what it should be called, regardless of different
implementations (especially if they are compatible).
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Le 12/11/2008 15:40, Peter Alfredsen a écrit :
But let me point out that in most leaf-packages, removing la files will
cause no pain, but will ensure that they do not have to be rebuilt if
a .la-listed dependency loses its .la file.
Mart, others and myself have already tried removing .la files
Alexis Ballier a écrit :
> Hi,
>
>> (I think pulseaudio is fixed, actually.)
>
> For what it's worth: removing the .la files from pulseaudio breaks its
> module loading on freebsd; and it's an elf system. I don't know what
> you mean by fixed
It's not fixed and it can't be. libtool's cross-plat
Le 16/11/2008 09:44, Michael Haubenwallner a écrit :
Never *unconditionally* switch back from libltdl to dlopen&co in source
code, as it is likely to break many non-linux platforms (Darwin, AIX,
HP-UX, ...).
I perfectly know this. My comment was *exactly* made to point out that
we cannot fix a
Peter Volkov a écrit :
> В Вск, 16/11/2008 в 21:13 +0100, Gilles Dartiguelongue пишет:
>> here is a list of packages gnome herd would like to get rid of since
>> no-one seem to take care of them and users are not so verbose about it
>> either:
>>
>> * app-text/ggv https://bugs.gentoo.org/show_bug.
Le 05/12/2008 05:33, Joe Peterson a écrit :
How about "PORTAGE_JOBS" to go along with "PORTAGE_OVERLAY",
"PORTAGE_NICENESS", etc.
While this part of the thread has a lot of bikeshedding potential, Joe's
name sounds more consistent with what we already have.
Naming issues appart, it's a good
Le 03/01/2009 18:57, Ulrich Mueller a écrit :
On Sat, 3 Jan 2009, Markus Meier wrote:
my proposals:
xft: Build with support for XFT font renderer (x11-libs/libXft)
+1
BTW, why do we have a virtual/xft? Is this a leftover from the times
of monolithic X?
I would say it was there for the
Hi all,
This virtual is a left-over from the transition to the modular X.org
stack. Ulrich (ulm) and I have converted all packages in portage to
depend on x11-libs/libXft directly.
Please update ebuilds in overlays. I'll remove the virtual in a couple
of days.
Thanks :)
Rémi
Le 01/02/2009 18:32, Norberto Bensa a écrit :
Excuse me for thread hijack.
Would it make sense to add (for example):
gnome-games
gnome-games is already the name of a package that contains all official
GNOME games. Only a handful are also released and packaged separately.
Useless for us
Le 08/02/2009 20:07, Angelo Arrifano a écrit :
I would keep existing categories and add a new TAG metadata to existing
ebuilds. Something like TAG="kde music player lyrics lastfm
visualization" for amarok, as example.
If anything, this sort of extra information should go to metadata.xml.
Cheer
Petteri Räty a écrit :
Ciaran McCreesh wrote:
On Mon, 09 Feb 2009 14:30:58 +0200
Petteri Räty wrote:
It would probably be useful to provide a central rsync infra for
overlays where overlay maintainers could subscribe their overlays to
and the machine would pull in their VCS and generate the me
Le 16/02/2009 07:17, Duncan a écrit :
That said, I don't have any particular interest in it, so I don't have a
problem with it disappearing. I just found the ONLY reason given an
uncommon enough reason for removal on its own that it warranted comment,
is all.
Hence the 30-day period when remo
Le 27/02/2009 06:32, Jeremy Olexa a écrit :
bump. Can anyone help out here? Is it a license or a doc?
I would say it is in fact a license, but since all it seems to do is to
confirm that whatever GnuGk does under the GPLv2 is allowed, I wouldn't
necessarily put it in the license dir. But do i
My 2¢ :
Keep the EAPI inside the ebuild itself. On the first line, on the fifth
line, as an argument with the shebang, as a comment, as a variable, as a
function call, ...
I really don't care what it looks like, as long as it's inside the ebuild.
Cheers,
Rémi
Le 03/03/2009 07:33, Donnie Berkholz a écrit :
Thoughts? Could we do something useful with this?
What about the various objects that make up the final lib/binary? How is
this handled?
Looks like a promising idea though
Cheers,
Rémi
Tomáš Chvátal a écrit :
Hi,
I am currently messing with git.eclass and i would like to see some other sets
of eyes on it.
I am throwing in full new eclass [1] and its diff [2].
I will be really happy for comments and even more for diffs :D
Oh and by the way, the diff looks nice to me. Maybe w
Tomáš Chvátal a écrit :
Hi,
I am currently messing with git.eclass and i would like to see some other sets
of eyes on it.
I am throwing in full new eclass [1] and its diff [2].
I will be really happy for comments and even more for diffs :D
Does/Can it fix bug #247187 ? Or is it something that
Le 06/03/2009 21:57, Donnie Berkholz a écrit :
Any thoughts?
Looks pretty good to me. I don't have much else to say :)
Cheers,
Rémi
Le 07/03/2009 09:10, Caleb Cushing a écrit :
If you had really been prepared you already had 2 or more janitors.
While I really appreciate you comparing us to janitors, ...
the answer is not to fire people, but not to be as reliant on single
points of failure. if you make it more than 1 perso
Le 08/03/2009 21:38, Tomáš Chvátal a écrit :
net-misc/mDNSResponder
How about dropping this one in favor of avahi? Or am I missing something
obvious?
Cheers :)
Rémi
Le 09/03/2009 02:50, Donnie Berkholz a écrit :
On 14:09 Tue 03 Mar , Bo Ørsted Andresen wrote:
On Tuesday 03 March 2009 12:13:34 Peter Volkov wrote:
Could you just use dosed here?
dosed needs to die.
Why?
Because it's utterly pointless and exists only for legacy reasons. Few
packages use
important, including fonts.
With the latest patches in >=x11-base/xorg-server-1.5.3-r3, X can work
_without_ any fonts at all. Old apps and toolkits (xterm, motif, tk,
Xaw, ...) will look ugly as hell but they should work.
In a nutshell, don't use the xorg-x11 meta.
Cheers
--
Rémi Cardona
LR
Le 12/03/2009 17:21, Marijn Schouten (hkBst) a écrit :
Do you mean:
1) don't use the xorg-x11 meta if you don't want not-completely-free fonts
or
2) don't ever use the xorg-x11 meta
?
A little bit of both. :)
Unlike the Gnome or KDE meta, most of the stuff in the xorg-x11 meta is
useless for
Le 16/03/2009 23:59, Maciej Mrozowski a écrit :
* RDEPEND=DEPEND is still in. Again, was a decision reached?
Imho it would be about time to kill implicit build time dependency assignment.
+1, let's rip it out.
Rémi
Le 19/03/2009 15:23, Robert Piasek a écrit :
Feel the trend? gnome-base/gnome-panel will follow soon. Lets make this
global. Unless we decide that PolicyKit is the future and make it
compulsory).
If no one complains, I will make the changes in a couple days.
That seems reasonable. ACK from me.
Le 19/03/2009 19:12, Doug Goldstein a écrit :
The problem would be a simple fix if PolicyKit supported groups and we
could just say "give all access to those in the wheel" group as a
reasonable default. But alas, it does not. Arguably we can probably
patch that in and just be done with it.
Actu
Le 22/03/2009 19:22, Nirbheek Chauhan a écrit :
The ${PV} in the patch name is a quick indication of the age of a
patch, the gnome herd especially *encourages* this behavior.
What I used to do back when I was still bumping packages in the Gnome
Herd, I would version the patch, but I would use
ns of dupes.
Thanks to everyone who helped test this release, it saved me a lot of
headaches.
Cheers
Rémi
--
Rémi Cardona
LRI, INRIA
remi.card...@lri.fr
r...@gentoo.org
ns of dupes.
Thanks to everyone who helped test this release, it saved me a lot of
headaches.
Cheers
Rémi
--
Rémi Cardona
LRI, INRIA
remi.card...@lri.fr
r...@gentoo.org
Simon C. Ion a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rémi Cardona wrote:
The Upgrade Guide is located at
http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
The upgrade guide indicates that one should use a .fdi file for the
linuxwacom driver. IIRC
Le 04/04/2009 00:01, Christian Faulhammer a écrit :
please see attached news item for review.
The wording is fine.
Signed-off-by: Rémi Cardona
Thanks
Le 03/04/2009 16:47, Jeremy Olexa a écrit :
However, we have toyed with other ideas. One of which is to introduce
IUSE=prefix in prefix.eclass similar to the USE=multilib approach. I
don't really like this idea because it exposes the use flag and we
don't want it exposed to the users.
Just of c
Ulrich Mueller a écrit :
More translations are welcome.
en: The www-plugins category contains plugins for Web browsers.
de: Die Kategorie www-plugins enthält Plugins für Webbrowser.
fr: Cette catégorie contient des plugins pour navigateurs Web.
Cheers,
Rémi
Gilles Dartiguelongue a écrit :
Le lundi 06 avril 2009 à 08:32 +0200, Rémi Cardona a écrit :
Ulrich Mueller a écrit :
More translations are welcome.
en: The www-plugins category contains plugins for Web browsers.
de: Die Kategorie www-plugins enthält Plugins für Webbrowser.
fr: Cette
Mike Frysinger a écrit :
This is your one-day friendly reminder ! The monthly Gentoo Council
meeting is tomorrow in #gentoo-council on irc.freenode.net. See the
channel topic for the exact time (but it's probably 2000 UTC).
I'd like for the Council to discuss a migration plan from old
defaul
Mart Raudsepp a écrit :
Hello,
This thread is for any discussion about the slot operator support item
in EAPI-3 draft.
Could anyone actually give a good reason for slot operators? What
packages would have a _clear_ benefit from using them? I'm asking for an
actual list of packages, not just
Le 09/04/2009 20:38, Donnie Berkholz a écrit :
I don't particularly wish for this to happen Real Soon, but drafting a
plan sounds like a good first step.
OK, I'm looking forward to reading your draft. =)
1) migrate
2) party
I don't really see what else should be in between steps 1 and 2.
I
Le 26/04/2009 23:55, Gilles Dartiguelongue a écrit :
Hello list,
As many of you might already know, gnome switched to git about 2 weeks
ago so I'd like to take a pick at what people do concerning upstream
using git. How do you present patches you maintain for gentoo to
upstream ? Own maintained
Petteri Räty a écrit :
Currently we really don't need to fail that many
people as those who end up at that point in the process almost always
have good enough skills as they have contributed via overlays for quite
a while.
Ditto on that. Most recruits I've been actively watching these past few
# Rémi Cardona (05 May 2009)
# Masked for removal in 30 days, maybe less
# has been blocked by xkeyboard-config for _years_
# see bug #196650
x11-misc/xkbdata
The future is now, rejoice!
Cheers,
Rémi
# Rémi Cardona (09 May 2009)
# Low-Bandwidth X and the X Proxy Management stuff has been declared
# dead since last century. All of those will be gone in 30 days
x11-apps/lbxproxy
x11-apps/proxymngr
x11-apps/xfindproxy
x11-apps/xfwp
x11-apps/xrx
x11-proto/xproxymanagementprotocol
# Rémi Cardona
Le 09/05/2009 13:05, Marijn Schouten (hkBst) a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
� wrote:
# R�mi Cardona (09 May 2009)
# XPrint is dead, long live XPrint
For kings I understand this comment, but can you explain how it applies to
XPrint?
The replacement for XPrint would
Le 06/05/2009 08:49, Christian Faulhammer a écrit :
Hi,
any project lead/member can post an answer to this mail for a status
report:
X11 Herd Status Update
Short term or recently done :
- 1.5.3-r5 went stable (I'm sure y'all noticed)
- there will be another 1.5 stable server within a few we
Le 10/05/2009 23:43, Gokdeniz Karadag a écrit :
It seems like you have forgotten the link.
[1] https://bugs.gentoo.org/show_bug.cgi?id=267769
Thanks
Le 15/05/2009 23:20, Ryan Hill a écrit :
Could I ask that people stop closing bugs against the gold linker with
such classy witticisms as "patches welcome".
Honestly, a little heads up before gold hit portage would have been nice
too.
I already had 2 bugs with gold-related issues even before
1 - 100 of 301 matches
Mail list logo