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.
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
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
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
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 r...@gentoo.org
Thanks
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
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
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
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
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
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.
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
, 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
LRI, INRIA
remi.card
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
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
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 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
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
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
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
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
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
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 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
Petteri Räty a écrit :
Ciaran McCreesh wrote:
On Mon, 09 Feb 2009 14:30:58 +0200
Petteri Räty betelge...@gentoo.org 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
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.
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
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 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
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 idea.
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
Le 16/11/2008 09:44, Michael Haubenwallner a écrit :
Never *unconditionally* switch back from libltdl to dlopenco 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
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-platform
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
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]
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
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
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 :)
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL
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
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 :
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
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
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
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 ofmaintainerteamcpp/team/maintainer, why
do we
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 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
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
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,
snip
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
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
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,
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
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
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
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 PROTECTED]
[EMAIL
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 for various
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
a 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
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]
--
gentoo-dev@lists.gentoo.org
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
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
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
--
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
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.
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,
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 this
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
# 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
--
gentoo-dev
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
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,
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
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
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.gentoo.org
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
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
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.
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 target
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 :
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
we feel it's ready and when most outstanding bugs are solved.
The Gnome 2.21/22 series of packages have been available for months in
the gnome overlay. If you want to try it out on an ~ system, use layman
and knock yourself out.
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED
:
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 PROTECTED
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
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
Peter Volkov a écrit :
В Чтв, 28/02/2008 в 21:49 -0500, Richard Freeman пишет:
Santiago M. Mola wrote:
What do you think about? Would it be easy to integrate it with
packages.g.o or should it belong somewhere else? Do you think this is
a suitable project for SoC?
I like the idea, although it
You're hijacking threads again. Please stop.
If you have an issue, file a bug report at http://bugs.gentoo.org/ The
-dev mailing list is the _wrong_ place for that.
Thanks
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
enabled KDE4
coming to our main tree via contributing to their overlays.
Boo! Hiss!
Just kidding ;)
Anyway, Welcome to our crazy team and have fun !
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
joshua jackson a écrit :
2) We need mentors, so far confirmed I have: Diego and Saleem
What kind of work is involved there? I wouldn't mind being a mentor but
I'd like to know a bit more about what's expected from a good mentor.
Thanks,
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
William L. Thomson Jr. a écrit :
Please excuse my ignorance if this is a naive comment or has been
brought up before. With all the non amd processors now with 64bit
support. amd64 as a keyword seems a bit odd and off maybe.
I think we'd already discussed this a while back, and decided not to
Oleg Puchinin a écrit :
Day kind!
I recently have started to use Gentoo, and I had one question.
What for to charge developers of a problem of check of packages?
Why to not make public system of ratings? For example voting
We already have such a implicit rating system :) It's called bugzilla.
of adding yet another eclass (which
we wouldn't be able to remove :p)
Cheers
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Petteri Räty a écrit :
What do you think about adding support to base.eclass for running
eautoreconf?
*puts on Gnome hat*
In most of the ebuilds where we need to run eautoreconf, we usually
apply patches. I can't remember of an ebuild where we just run
eautoreconf on its own.
In the end,
Vlastimil Babka a écrit :
How about just some elog If you use make install, emerge --noreplace
debianutils in the kernel's postinst or something.
Bellow is my contribution to this thread :)
Cheers,
Rémi
--- kernel-2.eclass 2007-12-17 17:06:02.0 +0100
+++ kernel-2.eclass
Caleb Tennis a écrit :
Any objections to this potential move, or comments on a better category name?
No objections. Just wondering about tools like gitweb, will they stay in
web-apps?
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
101 - 200 of 286 matches
Mail list logo
