Le 29/11/2020 à 16:48, Andreas K. Hüttel a écrit :
x11-misc/i855crt
I'm fairly certain this package cannot work with post-KMS kernel
drivers, so anything after 2010 or so. And the laptops that sport this
chip are probably all dead by now (mine is anyway).
I'd say, let's push this one to
Le 01/10/2018 à 00:50, Mike Gilbert a écrit :
> update-desktop-database and update-mime-database are called from ROOT in
> pkg functions, so the related dependenices belong in RDEPEND.
>
> Signed-off-by: Mike Gilbert
As far as the eclass goes, this is correct. But AFAIR, this was needed
because
Le 19/07/2015 18:42, Ben de Groot a écrit :
I would like to note that we only have around 50 packages that require
python3, while the majority requires python2, and the remainder will
function with either.
How far are we from building a python3-only stage3? Are there any major
blockers? Would
Le 26/02/2015 09:39, Markos Chandras a écrit :
Excellent! Looks great. Thank you very much for your hard work
Seconded, this is a huge improvement over the old site.
Thanks to all involved, this is fantastic work!
Rémi
Le 19/01/2015 23:40, Michał Górny a écrit :
1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in
a lot of packages. If we changed the meaning, libav users will end up
switching '-ffmpeg libav' per-package. Ugly.
2. Feature-oriented flags. USE=ffmpeg represents the generic
Why not :
libav? ( media-libs/libav:= )
ffmpeg? ( media-libs/ffmpeg:= )
+ REQUIRED_USE=^^ ( libav ffmpeg )
I for one would never expect USE=-libav to enable ffmpeg (nor
USE=-ffmpeg to enable libav FWIW).
Rémi
Le 19/11/2014 03:17, Alec Ten Harmsel a écrit :
Hey devs,
Hi Alec,
This is my first mail to this list. If this is out of line, let me know.
Not out of line on the topic/content, but try to avoid sending 3MB
attachments to hundreds (thousands?) of people.
* 9233 ebuilds that use a deprecated
Le 02/11/2014 17:48, Alex Xu a écrit :
so... instead of emailing 4 people (three bug-wranglers plus one
maintainer), you email around 300 people (assuming that subscriber count
is around the same as #gentoo-dev users, which is probably a severe
underestimate).
Alex: no need for a snarky
Le vendredi 23 mai 2014 à 22:57 +0700, gro...@gentoo.org a écrit :
# Google closed free usage of the translate api
# Masked for removal in 30 days
app-text/qgoogletranslator
# openmcl has been renamed to clozurecl
# Masked for removal in 30 days
dev-lisp/openmcl
Le lundi 14 avril 2014 à 10:48 +0200, Tiziano Müller a écrit :
Not really, no. I would rather wait until other people have reviewed
and/or it has been pulled into openssl.
To cite the Akamai dev who posted the patch [1]:
Let me restate that: *do not just take this patch and put it into
Le dimanche 29 décembre 2013 à 00:19 +, Robin H. Johnson a écrit :
sys-apps/vbetool
Is this still remotely useful with KMS-enabled kernels ?
Cheers,
Rémi
Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit :
in short: if a package requires version X then the ebuild should require
version X; it can be forgotten but it's a bug.
That _is_ our policy. Ebuilds should - at the very least - mirror what
upstream's build script requires.
So,
Le mardi 20 août 2013 à 12:26 +0200, Michał Górny a écrit :
3. FEATURES=ipc-sandbox
Requires: CONFIG_NAMESPACES, CONFIG_IPC_NS
Applies to: src_*
This one separates the ebuild's *nix IPC stuff from host. This includes
semaphores, shared memory etc. Similarly to network-sandbox, this
Le vendredi 26 juillet 2013 à 21:19 -0700, Paweł Hajdan, Jr. a écrit :
The real question is, how realistic can we make a process of testing and
moving to stable?
We have arch teams, we have users... when several users say it's OK I
think it is OK. As compared to a script pushing it to the
Le dimanche 17 février 2013 à 22:47 -0600, Ryan Hill a écrit :
Even after you do that it's hard to figure out what firmware files you
actually
need. I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
linux-firmware contains:
iwlwifi-6000-4.ucode
iwlwifi-6000g2a-5.ucode
Hi Andreas,
Le dimanche 20 janvier 2013 à 16:20 +0100, Andreas K. Huettel a écrit :
So, a thread like Should we enable useflag Z by default would then include
Please discuss here, vote on ... with a link to the count page (updated via
cron every 1h). On login to ..., a message similar to the
Le mercredi 28 novembre 2012 à 22:49 +0100, Justin a écrit :
Solution:
Create them by hand.
The solution is to tell *upstream* how to build and ship .pc files with
their build system.
If we start shipping .pc files no one else has, projects that use such
libraries will have only 2 choices:
-
Le jeudi 22 novembre 2012 à 20:59 +0100, Michał Górny a écrit :
You could say it's an algo like this:
1) if you want phase functions for distutils all other automagic,
use distutils-r1;
2) if you don't want phase functions but want PYTHON_TARGETS and other
metadata stuff, use
Le jeudi 01 novembre 2012 à 23:30 +0100, Michał Górny a écrit :
Do you have any ideas how to solve that kind of stalemate?
How about a carefully crafted news item inviting users to enable the
latest python version and to emerge -C argparse afterwards?
We've already asked users to handle more
Le 17/08/2011 21:57, Matthew Summers a écrit :
+1 on this. It saves the ebuild for posterity AND prevents users
hitting nasty bits. This seems to me to beg for a proper well-defined
policy, in any case.
We already have a policy for this and it's called portage.
If a package is broken (and I
Le 12/04/2011 16:56, William Hubbs a écrit :
All,
at long last, we have an openrc stable candidate.
Thanks to all of you who worked on this over the years, your efforts are
_really_ appreciated.
This means we need more testers.
Openrc being so central to Gentoo, may I suggest a bigger
Le 27/03/2011 10:36, Samuli Suominen a écrit :
Also, both udisks and upower now have blockers for sys-apps/hal to
prevent overlapping features.
Samuli,
I know you want to kill HAL with a vengeance. I don't disagree with the
ultimate goal but I think you've gone too far.
HAL and u{power,disks}
Le 24/03/2011 22:59, Mike Frysinger a écrit :
is there any reason we should allow people to commit unsigned
Manifest's anymore ? generating/posting/enabling a gpg key is
ridiculously easy and there's really no excuse for a dev to not have
done this already.
I, for one, have never signed my
Le 26/02/2011 17:08, Enrico Weigelt a écrit :
I could imagine a way like that:
[...]
Or we can do it like distributions always do (at least we do) :
1) find packages that don't work out of the box with libpng 1.5
2) work with upstream to fix them
Really, libpng15 is to libpng14 what gtk3 is to
Le 24/01/2011 13:31, Christian Faulhammer a écrit :
Hi,
over the course of the years the x86 (and other architectures as well)
has given away permissions to maintainers/teams to mark packages
stable themselves. As there never was a definitive list what
exceptions exist, I compiled a list
Le 31/12/2010 17:04, Brian Harring a écrit :
Quick scan of the tree via `pinspect eapi_usage`, the percentile is
eapi: '0' 13934 pkgs found, 50.43% of the repository
eapi: '2' 8679 pkgs found, 31.41% of the repository
eapi: '3' 4432 pkgs found, 16.04% of the repository
eapi: '1' 583
Le 06/12/2010 01:25, Robin H. Johnson a écrit :
Removals:
media-libs/libresample2010-12-01 19:06:41 chainsaw
Additions:
media-libs/libresample2010-12-01 16:59:41 chainsaw
A glitch in the matrix?
Rémi
Le 04/10/2010 08:35, Michał Górny a écrit :
On Mon, 04 Oct 2010 00:00:22 +0200
Rémi Cardona r...@gentoo.org wrote:
#2a) pkg-config is one solution (what upstream Xorg says: if you
want a static libX11, use pkg-config --static), other teams/herds
could fix their packages' .pc files
Le 03/10/2010 16:29, Luca Barbato a écrit :
I think the simpler solution is that if it needs .la, before reaching
the tree it has to be fixed...
Using libltdl (libtool's dlopen wrapper) is a *legitimate* use of .la
files. Those programs do not need to be fixed as they are not broken.
The
Le 02/10/2010 21:54, Jorge Manuel B. S. Vicetto a écrit :
With that goal in mind, I'd like to ask anyone with arguments about this
issue to present them as a reply to this thread.
[putting on my X11 cap]
As far as X11 packages are concerned (libX11, libXext, cairo, etc), we
can remove .la
Le 26/06/2010 21:39, Enrico Weigelt a écrit :
#2 One point i don't agree is the dont add -Werror rule. actually,
i'm thinking of making -Wall and -Werror mandatory. if some
package doenst build fine, it's simply broken. period.
You're obviously new here...
Just take a stroll through bugzilla
Le 10/06/2010 22:45, Arfrever Frehtes Taifersar Arahesis a écrit :
2010-06-10 22:20:44 Nirbheek Chauhan napisał(a):
On Fri, Jun 11, 2010 at 1:30 AM, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
2010-06-10 21:27:40 Jeremy Olexa napisał(a):
I see no reason to *not* add a
Le 06/06/2010 02:08, Sebastian Pipping a écrit :
can you explain how that happens?
Standard dependency resolution for packages with slots, there's nothing
specific about python.
Cheers,
Rémi
Le 25/05/2010 00:17, Mike Frysinger a écrit :
so prove me wrong and post some useful feedback on the change. i'm
simply being realistic.
Even if you think no one will ever comment on your patches, I've seen
enough projects where posting patches and doing reviews generated
interest and got
Le 25/05/2010 09:23, Mike Frysinger a écrit :
Even if you think no one will ever comment on your patches, I've seen
enough projects where posting patches and doing reviews generated
interest and got people to contribute.
i'm just asking for proof that it's useful here
And I'm asking you to
Le 14/05/2010 14:45, Jorge Manuel B. S. Vicetto a écrit :
Please share your thoughts on this so we can decide how to act on this case.
X11 team doesn't use it. While some of our users do come back and close
bugs as VERIFIED every now and then, it just doesn't mean anything in
the team's
Le 29/04/2010 09:06, Paweł Hajdan, Jr. a écrit :
What actions would you suggest?
Don't use ccache. We (speaking as a former gnome herd member) have had
countless unexplained bugs due to ccache.
Now, the gnome procedure for build failures is to ask users to first
disable distcc and ccache before
Le 24/04/2010 19:40, Petteri Räty a écrit :
What do you think about not allowing commits to eclasses without
mentioning an another developer who has reviewed and approved the diff
in the commit message? There's enough people on gentoo-dev for urgent
stuff too.
More bureaucracy and policies
Le 11/04/2010 15:16, Markos Chandras a écrit :
How about the participation to the discussions which took place every
day on our mailing lists or in IRC?
I, for one, am actually glad that the council (as such) isn't involved
in every troll fest we have on -dev, and I hope we keep it that way.
Le 03/04/2010 11:50, Petteri Räty a écrit :
I don't think later is valid resolution. If there's a valid bug it just
means it's never looked at again. If the bug is not valid then a
different resolution should be used. So what do you think about
disabling later? I would like to avoid things
Le 01/03/2010 11:38, Samuli Suominen a écrit :
I'd prefer EAUTORECONF (as it's already used in xfconf.eclass for the
same purpose, and has no reason to differ) or even SNAPSHOT, but XORG_
prefix seems redudant
We decided to put the prefix to make things clearer for ebuild writers
and to make
Le 08/02/2010 03:24, Mike Frysinger a écrit :
if we wanted to specifically target semi-common errors (and i think 'epatch'
w/out eutils.eclass falls into this category), then a repoman check would be
good.
it might also be useful to add a default epatch() to the initial env that
would be
Le 17/01/2010 12:26, Tomáš Chvátal a écrit :
Howdy guys,
please review the attached file and suggest updates to in.
I was asked for this thing going stable due to its being dependency of
new nvidia-drivers.
Also this thing is probably blocker for the bug on eselect-opengl i just
opened:
Le 29/12/2009 14:43, Henry Gebhardt a écrit :
4) add a USE-flag, say devel, that, when enabled, allows
compiling programs against the package. x11-libs/libXtst would
have an RDEPEND like this:
RDEPEND=devel? x11-libs/inputproto
This doesn't solve anything. It will just annoy users as they
Le 28/12/2009 06:36, Vincent Launchbury a écrit :
Hi,
I recently emailed the Gentoo PR team, voicing my concerns about the
amount of non-free software within Gentoo. I got an interesting response
from Sebastian Pipping, who said that while Gentoo is all about choice,
including the choice to
Le 28/12/2009 10:10, lx...@gentoo.org a écrit :
List of Gentoo bugs:
298616
298618
298620
298621
298623
298624
298626
298627
298629
298631
298633
298634
298636
298638
298640
298642
298644
298645
298646
298648
298649
298653
298654
298656
298657
298658
298659
RESOLVED -
Le 28/12/2009 22:04, Fabio Erculiani a écrit :
On Mon, Dec 28, 2009 at 9:51 PM, David Leverton
levert...@googlemail.com wrote:
On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote:
What all this has to do with the fact that they are just build
dependencies? Just wondering.
They're not
Le 28/12/2009 23:53, Fabio Erculiani a écrit :
Interesting, eventually somebody gave me a detailed and technical
explanation without [bla bla snip]. Thanks Rémi.
Yes, I agree with you that the best (and the one I would go for, too)
solution is adding support to a new *DEPEND, perhaps one that
Le 15/12/2009 16:19, Peter Volkov a écrit :
we will force all metadata.xml files have strict order of tags: first
herd/ then other tags. Currently there are about 200 ebuilds with
different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 .
Others and I actually make use of the order in
Le 15/12/2009 08:09, Ulrich Mueller a écrit :
On Tue, 15 Dec 2009, Peter Hjalmarsson wrote:
On the other hand this may be something for treecleaners? A package
that has not been bumped for 7 years? With at least three releases
since, and a bumprequest open for at least one year? A link to a
Dear all,
I've started working on one of my to-do items that is usually very
low-priority : cleaning up X-related licenses in portage.
This is one of the last remains of the Xorg split from a few years ago.
X being a big hairy mess, those who managed the transition a few years
ago decided
Le 15/12/2009 10:35, Ulrich Mueller a écrit :
On Tue, 15 Dec 2009, Rémi Cardona wrote:
And here's a list of packages that use one or more of these licenses.
Please let me know if/when you've fixed them.
app-editors/emacs
app-editors/emacs-cvs
x11-libs/openmotif
x11-libs/openmotif-compat
# Rémi Cardona r...@gentoo.org (13 Dec 2009)
# ttmkfdir had multiple QA issues and bugs (bugs #209616, #235354 and
#262945)
# xfs is completely useless, even on thin clients
# and xfsinfo is useless if xfs goes
x11-apps/ttmkfdir
x11-apps/xfs
x11-apps/xfsinfo
Cheers,
Rémi
Le 10/12/2009 17:22, Samuli Suominen a écrit :
In perfect world ~amd64 shouldn't be much different from amd64, so
here's a list generated from up-to-date system (stable chroot) from today.
If you maintain some of these packages, and it could go stable, please
open a stablereq for it. :-)
If
Le 04/12/2009 11:41, Mike Frysinger a écrit :
On Wednesday 02 December 2009 20:22:07 Jeremy Olexa wrote:
Can parallel init script startup be made the default yet? I've been
running with it for months and never noticed a problem..
not for stable. no point in proactively shooting our
Le 03/12/2009 02:22, Jeremy Olexa a écrit :
Can parallel init script startup be made the default yet? I've been
running with it for months and never noticed a problem..
I've been running it for more than a year on half a dozen boxes, without
any issues as well.
+1 for making it the default.
Le 30/11/2009 05:26, Jonathan Callen a écrit :
gst-plugins.eclass
ACK on this one, Gilles and I have been meaning to remove it a long time
ago.
Thanks for cleaning it all up :)
Rémi
Le 15/11/2009 00:16, Doug Goldstein a écrit :
The css USE flag currently says:
Enables ripping of encrypted DVDs
But that really doesn't describe the usage correctly. It enables the
ability to READ encrypted DVDs. I'm going to make the change if no one
objects.
+1, makes perfect sense.
Rémi
# Rémi Cardona r...@gentoo.org (15 Nov 2009)
# Broken since xorg-server 1.5 stabilization
# see bugs #248529 and #248531
# Masked for removal in 7 days
x11-drivers/xf86-video-imstt
x11-drivers/xf86-video-vermilion
'nuff said :)
Rémi
Le 09/11/2009 17:30, Patrick Lauer a écrit :
Ok, here's the real problem;
Unmaintained stuff is unmaintained
Patrick,
Just piping in to say that dropping a package from portage isn't the end
of the world, we have a very good process for it and it has proven to be
very effective.
Dead
Le 24/10/2009 15:42, Maciej Mrozowski a écrit :
If you have any comments, suggestions, important notices regarding this
change, please keep discussion in gentoo-desktop mailing list.
IMHO, we shouldn't even have desktop/server subprofiles to begin with.
I've always considered Gentoo to be an
Le 26/10/2009 22:58, Richard Freeman a écrit :
Gentoo is about choice.
No it isn't. Gentoo is about empowering users, giving them the ability
and tools to _change_ the distro to _their_ needs.
Gentoo does _not_ cater to all the possible needs.
This is somewhat off-topic, but it irks me
Hi Daniel,
Le 17/10/2009 01:29, Daniel Bradshaw a écrit :
So as I say, it occurs to me that most people probably follow some
variation of this selective upgrade method.
It might be handy to have some kind of metadata in the ebuilds that can be
used to indicate a package that is demanding.
Then
this change
Reviewed-by: Rémi Cardona r...@gentoo.org
Cheers
Thanks for the wording, I've somewhat made it a bit stronger.
@Dev, please ACK or NAK or whatever.
Thanks
Title: Migration to X.org Server 1.6 and libxcb 1.4
Author: Remi Cardona r...@gentoo.org
Content-Type: text/plain
Posted: 2009-10-02
Revision: 1
News-Item-Format: 1.0
Le 02/10/2009 09:43, Ulrich Mueller a écrit :
On Fri, 02 Oct 2009, Rémi Cardona wrote:
We're pleased to announce the stabilization of xorg-server-1.6. Users
are strongly encouraged to read the following two guides before upgrading:
GLEP 42 says that you should wrap lines at 72 columns
Le 02/10/2009 10:22, Petteri Räty a écrit :
Thus, at least 72 hours before a proposed news item is committed, it
must be posted to the gentoo-dev mailing list and Cc:ed to p...@gentoo.org
(exceptions may be made in exceptional circumstances). Any complaints —
for example regarding wording,
Hi guys,
Could anyone write up a one-liner news item for the xorg-server 1.6
stabilization with there 2 upgrade guides :
http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml
I tried figuring out
# Rémi Cardona r...@gentoo.org (24 Sep 2009)
# Both require xorg-server's libxf86config library which is busted
# and they both have no maintainer. See bug #222683
# Masked for removal in 30 days
dev-python/pyxf86config
dev-python/rhpxl
Cheers,
Rémi
# Rémi Cardona r...@gentoo.org (19 Sep 2009)
# Outdated and useless X doc packages
# Masked for removal in 30 days
app-doc/opengl-manpages
app-doc/xorg-sgml-doctools
app-doc/xorg-docs
Before anyone asks, opengl-manpages is a snapshot for Dec '00. The
online documentation at opengl.org is much
Le 20/09/2009 02:31, Ryan Hill a écrit :
If not, when can
we drop support for old EAPIs? Your opinions please.
Let's drop it now. We've waited long enough. Portage with EAPI=2 has
been stable for more than a year.
Rémi
Le 06/09/2009 02:34, Thomas Anderson a écrit :
Ciaran's really not making homework up for gentoo. Why, remi stated himself that
we have homework to do(and we sometimes don't do that homework)
I did, but I also stated upstream might have some homework to do
themselves. Here's a list of things
Le 05/09/2009 11:25, Duncan a écrit :
[...]
This is off-topic for gentoo-dev. Please continue this discussion in
private.
Thanks
Rémi
Le 03/09/2009 23:27, Mounir Lamouri a écrit :
But the content of the license is the same. That only means you can use
a newer one.
I mean we do not need a new license file for that. It's up to upstream
to write somewhere if it's GPL-2 or GPL-2+, am I right ?
Yes, that's for upstream to figure
Le 04/09/2009 20:52, David Leverton a écrit :
Is that really a problem?
To me, it's not. :)
I admit to not being around for the original design
decisions, but I would assume that the purpose of having LICENSE in ebuilds
is to tell users what licence the package is under (whether or not it's
# Rémi Cardona r...@gentoo.org (04 Sep 2009)
# Masked for removal in 60 days, old and unmaintained in Gentoo
# Uses removed VIDEO_CARDS flag (see bug #282981)
www-plugins/gnash
Cheers,
Rémi
Le 04/09/2009 22:41, Andrew John Hughes a écrit :
So there'll be no Free Flash support in Gentoo any more?
I hope someone will pick this up, this is a high priority FSF project after all.
There's media-libs/swfdec that's still offically maintained by the Gnome
herd.
As far as gnash is
Le 03/09/2009 23:10, Mounir Lamouri a écrit :
Duncan wrote:
Sebastian Pipping posted on Tue, 01 Sep 2009 04:21:49 +0200 as excerpted:
However I do notice that GPL-2+ could make things easier. Why not
introduce a license group for it like @GPL-2+ or so, instead? That would
be transparent and
Le 01/09/2009 00:12, Mounir Lamouri a écrit :
Hi,
As you should know, GLEP 23 [1] introduced USE flags conditions in
LICENSE variable and || operator in addition of licenses groups and
ACCEPT_LICENSE variable.
[1] http://www.gentoo.org/proj/en/glep/glep-0023.html
/me still thinks LICENSE
Le 23/08/2009 11:02, Chip Parker a écrit :
On Sun, Aug 23, 2009 at 12:07 AM, Alexey Shvetsovale...@gentoo.org wrote:
Hi all!
Also i think it wil be good idea to include parted into liveDVD since
its only tool that support gpt partition tables =)
+1 On this one. Since parted comes with
Samuli Suominen a écrit :
description: Support for MP4 container format
[+ C ] mp4 (media-sound/amarok):
Build the TagLib plugin for writing tags in Mp4 container files (m4a).
Please note that by enabling this USE flag, the resulting package will
not be redistributable, as it links to
Paul de Vrieze a écrit :
As a service to users, you might want to create an empty library:
touch foo.c
gcc -shared foo.c -o libxcb-x11.so.0.0.0
That's all
Like Samuli said, it's a hack and doing that would be wrong. I will not
trade short-term peace of mind for a long term hell for whoever
Le 18/08/2009 03:30, Steven J Long a écrit :
[snip]
Steven,
This thread was dead for more than 4 days. Yet you pick it up and you
try to pick a fight with Ciaran.
I for one am tired of your behavior on this list and I will not hesitate
to contact UserRel to get you out of this list if you
Hi all,
Just a quick heads up that I have just unmasked x11-libs/libxcb-1.4 and
its companion libraries in all profiles _except_ 2008.0.
As some of you have already found out, since 1.2, libxcb stopped
shipping a very specific library: libxcb-xlib.so. This library was only
ever meant to be
Le 13/07/2009 19:22, Robert Buchholz a écrit :
We're using the x11-drivers/xf86-input-microtouch for a cash register.
It works fine, but I think the machine is still on Xorg Server 1.3.
I don't have the capacity to maintain this driver myself, but it seems
bug #276615 has a patch, so I wonder
# Rémi Cardona r...@gentoo.org (13 Jul 2009)
# broken and unmaintained by upstream, masked for removal in 30 days
# see bug #277521 for more info
x11-drivers/xf86-input-calcomp
x11-drivers/xf86-input-digitaledge
x11-drivers/xf86-input-dmc
x11-drivers/xf86-input-dynapro
x11-drivers/xf86-input
Le 13/07/2009 16:56, Marijn Schouten (hkBst) a écrit :
Why were they marked unsupported by upstream? Is there a replacement, are they
no longer needed, some other reason?
Some are now supported by the kernel. For the rest, nobody owns the
hardware anymore. (ur98 is for a head-tracker... does
Le 07/07/2009 18:20, Ciaran McCreesh a écrit :
I would be entirely happy if you could get the people whose stated aim
is to disrupt PMS and / or third party package managers to stop
poisoning the atmosphere.
Then _please_ for the love of God just _ignore_ him.
Thank you
Le 05/07/2009 03:12, Sebastian Pipping a écrit :
Lars Wendler wrote:
So what do you think? Should we convert the bug into a tracker and open bugs
for any package using the USE-flag that should be converted into the other
one?
+1 from me, sounds reasonable.
Ditto, sounds good.
And now for
Ned Ludd a écrit :
[snip, lots of insightful stuff I either agree with or don't really
understand]
So lets have some damn fun again !...@#$
_That_ I whole heartedly agree with. Please, all of you in the new
council, try to keep this in mind :)
Thanks
Rémi
Seriously, let's stop.
This endless debate has gone on for waaay too long and it is just plain
spam now.
I'm just too tired of reading those endless discussions that are going
_nowhere_.
Let's just all agree we've failed to reach a consensus and let's spend
time on something else.
Le 26/05/2009 22:43, Sérgio Almeida a écrit :
Hello,
There isn't yet. The code is still pretty ugly and I'm still refactoring
to the new architecture before I can make it public (or even officially
git it). I will post it on this mailing list as soon as experimentations
are possible.
Please
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
Le 09/05/2009 13:05, Marijn Schouten (hkBst) a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
� wrote:
# R�mi Cardonar...@gentoo.org (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
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
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
# Rémi Cardona r...@gentoo.org (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
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
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
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
1 - 100 of 286 matches
Mail list logo
