There seems to be two different schools on who to assign a keywording
bug with only a single arch. I have myself assigned it to the arch in
question but there's a difference of opinion here:
http://bugs.gentoo.org/show_bug.cgi?id=272160#c5
Let's get agreed on a single approach and I will add a
In eclasses there's often use for outputting QA warnings for ebuild
authors (at least in java and python could immediately make use of
this). Currently Portage has eqawarn available but it's considered
internal. Hopefully eqawarn finds it's way to the next EAPI but in the
mean while do we want:
On 03/12/2010 09:39 PM, Paweł Hajdan, Jr. wrote:
On 3/12/10 8:18 PM, Petteri Räty wrote:
There seems to be two different schools on who to assign a keywording
bug with only a single arch.
Why a special case for that? The general rule seems to be that the owner
is the maintaining herd
On 8.3.2010 16.23, Peter Hjalmarsson wrote:
AFAICS you are right (and that is also why I have a hard time
understanding the flames here, are people so against fixing the deps in
their packages and/or filing bugs and/or contacting devrel about those
maintainers who refuse to fix their
On 03/07/2010 07:11 PM, Mark Loeser wrote:
Absolutely not. Its actually the opposite. Until 90+% of the tree just
works with the new version of python, it should not be stabilized. The
stable tree should all Just Work together. Stabilizing python-3 at this
point would be the equivalent
On 03/07/2010 07:32 PM, Samuli Suominen wrote:
+1
no need to stabilize experimental python, not even convinced it should
be in ~arch yet (but package.masked for testing)
I don't think upstream considers python 3 experimental so when it can be
installed side by side with 2.6 so that
On 03/07/2010 07:42 PM, Mike Frysinger wrote:
On Saturday 06 March 2010 02:11:15 Petteri Räty wrote:
On 03/05/2010 08:59 PM, Mike Frysinger wrote:
sometimes i have optional patches (ignoring the patches should always be
applied) where autotools should be run. always inheriting autotools
On 03/07/2010 08:36 PM, Mike Frysinger wrote:
On Sunday 07 March 2010 13:31:56 Petteri Räty wrote:
On 03/07/2010 07:42 PM, Mike Frysinger wrote:
On Saturday 06 March 2010 02:11:15 Petteri Räty wrote:
On 03/05/2010 08:59 PM, Mike Frysinger wrote:
sometimes i have optional patches (ignoring
On 03/07/2010 11:44 PM, Mike Frysinger wrote:
On Sunday 07 March 2010 14:08:29 Petteri Räty wrote:
On 03/07/2010 08:36 PM, Mike Frysinger wrote:
On Sunday 07 March 2010 13:31:56 Petteri Räty wrote:
On 03/07/2010 07:42 PM, Mike Frysinger wrote:
On Saturday 06 March 2010 02:11:15 Petteri Räty
On 03/06/2010 08:28 PM, Jonathan Callen wrote:
On 03/06/2010 02:11 AM, Petteri Räty wrote:
What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
DEPENDs should be under. This approach doesn't allow the ebuild
maintainer to forget adding the depends.
That approach also
On 03/05/2010 10:14 PM, Ryan Hill wrote:
Because then people use them. Don't ask me why. I have things I deprecated
over two years ago still being used by a dozen ebuilds bumped within the last
three months. You should be familiar with this behaviour wrt.
built_with_use. So, when I'm
On 03/05/2010 07:18 PM, Sebastian Pipping wrote:
On 03/05/10 18:10, Jeroen Roovers wrote:
4. Notify
=
[..]
This step should probably include correcting all open bug
reports' Summaries to point to the new category, so that CAT/PN can be
found using the simple search interface.
On 03/05/2010 08:59 PM, Mike Frysinger wrote:
sometimes i have optional patches (ignoring the patches should always be
applied) where autotools should be run. always inheriting autotools is
currently annoying because it always adds the related dependencies. USE based
inherits are obviously
On 03/04/2010 11:35 AM, Ciaran McCreesh wrote:
On Thu, 4 Mar 2010 10:32:47 +0100
Ulrich Mueller u...@gentoo.org wrote:
On Thu, 4 Mar 2010, Christian Faulhammer wrote:
My proposal would be to call it dev-scm and put all version
controls, direct frontends, plugins and the like into that.
On 03/04/2010 11:28 PM, Markos Chandras wrote:
On Thursday 04 March 2010 23:08:06 Sebastian Pipping wrote:
- Update reverse dependencies
http://tinderbox.dev.gentoo.org/misc/dindex/dev-util/${PN}
http://tinderbox.dev.gentoo.org/misc/rindex/dev-util/${PN}
This might require too much
On 3.3.2010 11.23, Nirbheek Chauhan wrote:
2010/3/3 Tomáš Chvátal scarab...@gentoo.org:
Removing eclass functions like this is not allowed by current policy. If
you want to do it, you should discuss about changing policy.
?!
since when?
Since ever.
If you change eclass abi you need to
On 03/03/2010 02:47 PM, Ciaran McCreesh wrote:
On Wed, 03 Mar 2010 09:47:37 +0100
Tomáa Chvátal scarab...@gentoo.org wrote:
Removing eclass functions like this is not allowed by current
policy. If you want to do it, you should discuss about changing
policy.
since when?
Since ever.
If you
On 03/03/2010 02:40 PM, Ryan Hill wrote:
On Wed, 03 Mar 2010 13:09:49 +0200
Petteri Räty betelge...@gentoo.org wrote:
On 3.3.2010 11.23, Nirbheek Chauhan wrote:
2010/3/3 Tomáš Chvátal scarab...@gentoo.org:
Removing eclass functions like this is not allowed by current policy. If
you want
On 03/03/2010 11:39 PM, Ryan Hill wrote:
Also policies should be changed when they don't make sense any more as I
said in my first response but I am not sure if that's the case here.
The problem is I don't think this is actually a policy. One of the first
projects I did as a developer,
On 03/04/2010 09:39 AM, Ulrich Mueller wrote:
On Thu, 04 Mar 2010, Petteri Räty wrote:
If we decide allowing removal of functions, we should come up with a
common procedure like the eclass removal policy:
http://devmanual.gentoo.org/eclass-writing/index.html
I think removal of functions
On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:
Members of Gentoo Python Project have agreed to deprecate the following
functions
in EAPI =2:
- python_version()
- python_mod_exists()
- python_tkinter_exists()
- distutils_python_version()
-
On 24.2.2010 8.19, Jeroen Roovers wrote:
Oh, and one other thing. Attached is a list of ebuild that use
ftp.gnu.org instead of mirror://gnu in their SRC_URI. Please make the
switch. Maybe this should be a QA check as well? repoman would have all
the information it needed...
There's already
On 21.2.2010 1.11, Paweł Hajdan, Jr. wrote:
Is it acceptable for another dev to jump in and add RESTRICT=test to
an ebuild if the maintainer does not respond to a bug report in a timely
manner?
Preference order:
1. Fix the tests
2. Disable just the failing test
3. RESTRICT=test
Regards,
On 20.2.2010 14.28, Zac Medico wrote:
Hi,
Since portage-2.1.7.x is stable now, with ACCEPT_LICENSE support, we
can think about deprecating check_license [1]. This will allow us to
avoid using PROPERTIES=interactive in cases when it is due to
check_license alone, since anything with a
On 21.2.2010 14.17, Zac Medico wrote:
On 02/21/2010 09:08 AM, Petteri Räty wrote:
On 20.2.2010 14.28, Zac Medico wrote:
Hi,
Since portage-2.1.7.x is stable now, with ACCEPT_LICENSE support, we
can think about deprecating check_license [1]. This will allow us to
avoid using PROPERTIES
On 21.2.2010 14.49, Zac Medico wrote:
On 02/21/2010 02:36 PM, Petteri Räty wrote:
On 21.2.2010 14.17, Zac Medico wrote:
On 02/21/2010 09:08 AM, Petteri Räty wrote:
On 20.2.2010 14.28, Zac Medico wrote:
Hi,
Since portage-2.1.7.x is stable now, with ACCEPT_LICENSE support, we
can think about
On 21.2.2010 15.21, Zac Medico wrote:
Likely there wouldn't be any breakage with it doing it in EAPI 3 but it
would be against the eclass contract of not changing expected behavior.
Given that check_license already returns silently if the user has
accepted the appropriate license(s) via
On 17.2.2010 16.33, Torsten Veller wrote:
--- eutils.eclass 15 Feb 2010 02:10:39 - 1.330
+++ eutils.eclass 17 Feb 2010 14:13:16 -
@@ -50,6 +50,15 @@
done
fi
}
+else
+ ebeep() {
+ eqawarn ebeep is not defined in
On 17.2.2010 20.03, Jeremy Olexa wrote:
What is going on with all these undocumented changes? When I look at the
council logs to see what is in EAPI3, I don't see anything about removing
functions. This is just silly and wastes alot of people's time for no
practical gain. In my EAPI3
On 15.2.2010 22.26, Robin H. Johnson wrote:
As soon as the 72 hours on this news announcement are done, I'm going to
be unmasking it. I do expect most of the breakage to come from the
client libraries, and NOT any actual data storage issues. If MySQL
detects that it's not safe to access a
On 01/25/2010 02:02 AM, Dale wrote:
Is there something that I am missing here? For me, system should
include the things needed for booting and for the package manager to
work. If it can't contain python then portage has a problem. As I
pointed out in another reply, portage won't let you
On 25.1.2010 13.02, Dale wrote:
Petteri Räty wrote:
On 01/25/2010 04:28 AM, Dale wrote:
Well put. I would agree that a simple warning should be given before
removing a system package or a package that system must have, especially
portage.
Maybe what portage needs is a reverse -n feature
On 25.1.2010 13.30, Petteri Räty wrote:
So there is already a option that is the reverse of -n ?
Dale
:-) :-)
You would first have to define the reverse to avoid misunderstanding.
--noreplace (-n)
Skips the packages specified on the command-line that have already been
installed.
Reverse
On 25.1.2010 18.20, Jacob Godserv wrote:
On Mon, Jan 25, 2010 at 06:32, Petteri Rätybetelge...@gentoo.org wrote:
I should also add that this is not a user support mailing list as there's
gentoo-user for that purpose. I think the original purpose of the thread was
already fulfilled.
So then
On 25.1.2010 18.06, Dale wrote:
I am subscribed to -user as well. I been using Gentoo since the 1.4
days. This is about improving portage which is a good thing to talk
about here. The devs do it, not the user. ;-) Also, I already know how
to use portage pretty good. I'm not asking for support
On 01/25/2010 07:07 PM, Dale wrote:
Petteri Räty wrote:
On 25.1.2010 18.20, Jacob Godserv wrote:
On Mon, Jan 25, 2010 at 06:32, Petteri Rätybetelge...@gentoo.org
wrote:
I should also add that this is not a user support mailing list as
there's
gentoo-user for that purpose. I think
On 01/17/2010 11:12 PM, David Leverton wrote:
On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
With GLEP 42 and proper logging of e* messages I think we shouldn't
annoy users any more with ebeep or epause so attached is a patch only
defines these functions for EAPIs 0, 1 and 2. Anyone
On 01/24/2010 07:12 AM, Benny Pedersen wrote:
should not be marked as system ?
it removes python-wrapper and this remove python link from
/usr/bin/python linked to /usr/bin/python-wrapper so all portage does
not work after this, but i solved it with a quickpkg from another host
my dump
On 01/24/2010 07:12 AM, Benny Pedersen wrote:
should not be marked as system ?
it removes python-wrapper and this remove python link from
/usr/bin/python linked to /usr/bin/python-wrapper so all portage does
not work after this, but i solved it with a quickpkg from another host
my dump
I looked at what kind of a difference cvs up made to built_with_use usage.
betelge...@pena /usr/portage $ grep --include *.ebuild built_with_use
-r . | wc -l
690
cvs up
betelge...@pena /usr/portage $ grep --include *.ebuild built_with_use
-r . | wc -l
708
There should be no legitimate reason
On 01/24/2010 03:02 PM, Ben de Groot wrote:
2010/1/24 Petteri Räty betelge...@gentoo.org:
The meaning of the system set is to have only the packages directly
required to have a minimal functioning system. Having python by itself
is not a requirement for that but having package management
On 01/24/2010 08:09 PM, Paweł Hajdan, Jr. wrote:
On 1/24/10 5:51 PM, Petteri Räty wrote:
There should be no legitimate reason for the number to go up so please
whenever bumping ebuilds, remove the usage of built_with_use.
How about adding a repoman check for that?
Paweł
Already done
On 01/24/2010 08:20 PM, Ben de Groot wrote:
2010/1/24 Petteri Räty betelge...@gentoo.org:
On 01/24/2010 03:02 PM, Ben de Groot wrote:
You can't have functioning package management without the hard
dependencies it requires. So both portage and python should be in the
system set.
Why should
On 01/24/2010 10:12 PM, Diego Elio “Flameeyes” Pettenò wrote:
Il giorno dom, 24/01/2010 alle 18.51 +0200, Petteri Räty ha scritto:
There should be no legitimate reason for the number to go up so please
whenever bumping ebuilds, remove the usage of built_with_use.
There is still legitimate
On 01/22/2010 10:58 AM, Torsten Veller wrote:
EAPI-3 was approved by the council during their last meeting (2010-01-18).
Which portage versions do support it?
(I wasn't able to find it in the docs.)
I haven't heard of a release that would.
When can we stabilize EAPI-3 ebuilds?
(I guess
On 18.1.2010 4.17, Richard Freeman wrote:
On 01/17/2010 08:23 PM, Ben de Groot wrote:
What about something like: if a bug has been open for 2 months without
any apparent maintainer activity, anyone can step in and commit a fix?
How about - anybody at any time can at their discretion post a
On 01/19/2010 10:37 AM, Peter Volkov wrote:
В Втр, 19/01/2010 в 01:22 +0200, Petteri Räty пишет:
On 01/18/2010 03:02 PM, Tiziano Müller wrote:
The proper replacement for such interactive notifications when called in
pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
Thus
On 01/18/2010 03:02 PM, Tiziano Müller wrote:
The proper replacement for such interactive notifications when called in
pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
Thus I'd keep them around until then.
Cheers,
Tiziano
ebeep or epause don't make your ebuild
On 01/18/2010 10:07 AM, Ulrich Mueller wrote:
On Sun, 17 Jan 2010, Petteri Räty wrote:
With GLEP 42 and proper logging of e* messages I think we shouldn't
annoy users any more with ebeep or epause
Agreed.
so attached is a patch only defines these functions for EAPIs 0, 1
and 2. Anyone
With GLEP 42 and proper logging of e* messages I think we shouldn't
annoy users any more with ebeep or epause so attached is a patch only
defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
keep these around for EAPI 3? If not I will apply the attached patch.
Regards,
Petteri
On 01/12/2010 12:23 AM, Brian Harring wrote:
On Mon, Jan 11, 2010 at 09:25:51PM +0100, Raaal Porcel wrote:
scarabeus told me that the eclass can't be removed until two years since
the deprecation date, so...
Removal of the eclass on 2012/01/11
Reasoning? Prior to env saving we couldn't
On 01/15/2010 12:54 AM, Robin H. Johnson wrote:
That top item is the largest blocker. The actual conversion time is down
to 9 hours, but with more than that again in setting it up. I'd like to
get the conversion time down to UNDER 4 hours. It's mostly
single-threaded, and we've got lots of
On 12/30/2009 12:11 PM, Robert Bradbury wrote:
For the last week or so, there have been packages in the world
distribution list which previously installed fine which currently do
not, these include ruby-gdkpixbuf2, ruby-pango, ruby-gtk2,
ruby-gnomecanvas2, ruby-gnome2 and ruby-libglade2 (this
On 12/28/2009 11:10 AM, lx...@gentoo.org wrote:
To x11, just don't get angry (eheh), let's discuss concerns here
(actually I don't see any and I am willing to fix all the ebuilds and
close all my bugs if you ack).
Filing bugs first and then opening discussion here doesn't make sense.
It
On 12/25/2009 10:41 PM, Jeremy Olexa wrote:
James Cloos wrote:
Diego == Diego E Petten� flamee...@gmail.com writes:
Diego # Fails to build if /usr/X11R6 is not present (bug #247737,
A bit trivial of an issue to drop a package, ja?
The QA team should generate more patches and fewer kills.
On 12/13/2009 04:28 PM, Jonathan Callen wrote:
Recently a change was made to cmake-utils.eclass, changing the
mycmakeargs parameter from a flat string to an array. This change was
also made to kde4-{base,meta}.eclass. The primary reason for this
change was to allow parameters passed to cmake
Doug Goldstein wrote:
GLEP 27 [1] seems pretty stagnant and I'm planning on giving it a bit
of a refresh and actually implementing it. Now before I do this I'm
not in love with the format in tree but I haven't decided on a format
exactly in my head. So that being said, I'm sending this out
Robin H. Johnson wrote:
On Fri, Nov 13, 2009 at 08:04:59PM +, Tomas Chvatal (scarabeus) wrote:
scarabeus09/11/13 20:04:59
Added:metadata.xml ChangeLog aurorae-0.2.1.ebuild
Log:
Initial commit. From sabayon overlay, basic ebuild from Thev00d00.
(Portage
Nirbheek Chauhan wrote:
On Sun, Nov 8, 2009 at 2:19 AM, Zac Medico zmed...@gentoo.org wrote:
Peter Volkov wrote:
Looks like this will not work for all noarch packages. Stardict
dictionary itself is noarch, but it RDEPENDS on stardict package which
is keyworded only on some archs. So we'll be
Patrick Lauer wrote:
On Sunday 08 November 2009 15:21:18 Peter Volkov wrote:
В Вск, 08/11/2009 в 11:56 +, Patrick Lauer (patrick) пишет:
patrick 09/11/08 11:56:46
Log:
Bump
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/foremost/fo
Patrick Lauer wrote:
So I'd appreciate if y'all stopped obsessing about such details and just fix
it instead of whining at me until my motivation takes a long walk on the
beach
and doesn't return for quite some time. At least I'm trying to keep these
packages alive, which noone else
Mike Frysinger wrote:
On Sunday 08 November 2009 10:25:56 Peter Volkov wrote:
В Вск, 08/11/2009 в 09:40 -0500, Mike Frysinger пишет:
On Sunday 08 November 2009 08:35:10 Joe Sapp wrote:
Samuli Suominen wrote:
Joe Sapp (nixphoeni) wrote:
nixphoeni09/10/27 11:21:25
Log: Directory
Tobias Klausmann wrote:
Hi!
On Wed, 04 Nov 2009, Ryan Hill wrote:
Is there any interest in allowing certain packages to be stabilized by the
maintainer without going through the arch teams? I always feel guilty when i
file stabilization bugs for app-doc pkgs.
I think for bugs which
Peter Volkov wrote:
Hi. How do we handle packages that provide client, server, and possibly
extra tools/libraries? Do we split packages like binary distros do or do
we use USE flags? What USE flags? Currently some packages are split
other use client, server or minimal USE flag(s).
Back in
Richard Freeman wrote:
Mart Raudsepp wrote:
Is it stated in any documentation that 30 days is a policy?
Not that I'm aware of - it is a guideline as you indicate. However,
don't expect anybody to actually take action on a STABLEREQ if there
isn't some kind of rationale for going stable
Tomáš Chvátal wrote:
Please turn your KDE radio on, and make sure to turn the volume to its maximum
level for this important message.
When I am reading the news item I have already actively done it with
eselect news so I think it should be better to just start with the
actual content.
Mike Frysinger wrote:
On Tuesday 27 October 2009 14:46:31 Petteri Räty wrote:
Normally old versions are not kept around as already said if you read
the thread.
normal is not the same thing as always. unless you're the maintainer,
you
have no idea whether old versions are kept
# Samuli Suominen ssuomi...@gentoo.org (26 Oct 2009)
# Doesn't work with new xfce-base/exo API, bug #289867.
# Replaced by media-video/parole.
# Masked for removal in 30 days.
media-video/xfmedia
This is not a KDE3-only application.
Regards,
Petteri
signature.asc
Description: OpenPGP
Mike Frysinger wrote:
On Tuesday 27 October 2009 02:07:02 Ryan Hill wrote:
On Sun, 25 Oct 2009 11:48:39 +0200 Petteri Räty wrote:
James Cloos wrote:
When you first psoted this list I noticed some (or several?) live
ebuilds. Git- is the one I remember.
Those should not get nuked during
James Cloos wrote:
Petteri == Petteri Räty betelge...@gentoo.org writes:
Petteri Their maintainers should be active and switch their ebuilds to
Petteri EAPI 2. If they don't have an active maintainer, then do we
Petteri want to keep live ebuilds for them around?
What possible benefit
Mike Frysinger wrote:
On Tuesday 27 October 2009 09:09:48 Petteri Räty wrote:
Mike Frysinger wrote:
On Tuesday 27 October 2009 02:07:02 Ryan Hill wrote:
On Sun, 25 Oct 2009 11:48:39 +0200 Petteri Räty wrote:
James Cloos wrote:
When you first psoted this list I noticed some (or several?) live
James Cloos wrote:
When you first psoted this list I noticed some (or several?) live
ebuilds. Git- is the one I remember.
Those should not get nuked during global cleanups, as they are likely to
be in active use notwithstanding their keywording or masking.
-JimC
Their maintainers
Petteri Räty wrote:
I wrote a script to check which ebuilds use built_with_use and have
keywords in never versions making the ebuild unused. This means that
neither arch or ~arch users are likely to install the ebuild. The script
and the list of ebuilds is attached. I plan on removing all
Nirbheek Chauhan wrote:
2009/10/24 Maciej Mrozowski reave...@gmail.com:
If you have any comments, suggestions, important notices regarding this
change, please keep discussion in gentoo-desktop mailing list.
What about people who like to install both gnome and kde on their
systems? (Perhaps
Fabian Groffen wrote:
On 18-10-2009 14:31:15 +0200, Fabian Groffen wrote:
On 18-10-2009 13:57:10 +0200, Tomáš Chvátal wrote:
Hi,
You know i am totaly supporting prefix but i have one point.
Why on earth portage simply does not detect the prefix enviroment is being
run
and then INTERNALY
Thomas Sachau wrote:
In addition, i see a trend to enabled more more more USE flags (either over
profiles or via IUSE
+flag). Whats the reason for forcing a big load of default enabled USE flags
on every user including
more dependencies, more compile time, more wasted disk space and more
Ulrich Mueller wrote:
On Fri, 23 Oct 2009, Samuli Suominen wrote:
So I was told Council needs to approve inheritance of eapi files
from parent profiles?
Doesn't http://bugs.gentoo.org/288320#c7 cover this? Why would you
need explicit inheritance?
Well technically you still shouldn't
Samuli Suominen wrote:
Samuli Suominen wrote:
For http://bugs.gentoo.org/287976, A news item:
Would this work?
Does this mean that you haven't tested it? If it's tested with the
oldest Portage version that people are expected to be using, then fine
by me. I don't think this bug comes to play
Tobias Klausmann wrote:
Come to think of it, how about an ewarn/einfo that is only
triggered on fresh installs, but not on upgrades? You can still
warn that foobard needs an etc-update and a restart, but I don't
need to be reminded where the examples are every time.
Ideally, one would be
Thomas Sachau wrote:
Hi together,
as announced in a previous mail, i created a fork of portage, which has
support to create 32bit libs
during compile phase for 64bit platforms (currently amd64 tested, ppc64
untested).
In short, it does execute every src_* phase twice with keeping a
Patrick Lauer wrote:
And that's with all the forced migrations for features like use-deps or the
removal of built_with_use. So unless there's some strongly needed features
there's no need for it. I can't remember any feature in the EAPI 3 list that
really looked useful to me, so not
Tomáš Chvátal wrote:
On čtvrtek 08 Říjen 2009, 23:34:10 Petteri Räty wrote:
Even this is wrong because:
Hi
...
betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10
IUSE nls
For most packages old versions are not kept around so just doing
=cat/foo-X.Y[use] is fine
Alex Alexander wrote:
On Thu, Oct 8, 2009 at 14:07, Markos Chandras hwoar...@gentoo.org wrote:
Crowded? I don't think so :)
The number of news items is quite small, so I think we can afford having them
all in the same folder
I'm assuming devs will eventually pick this feature up and use it
Marijn Schouten (hkBst) wrote:
Petteri Räty wrote:
I wrote a script to check which ebuilds use built_with_use and have
keywords in never versions making the ebuild unused. This means that
neither arch or ~arch users are likely to install the ebuild. The script
and the list of ebuilds
Stelian Ionescu wrote:
On Tue, 2009-09-29 at 16:32 +0300, Petteri Räty wrote:
I wrote a script to check which ebuilds use built_with_use and have
keywords in never versions making the ebuild unused. This means that
neither arch or ~arch users are likely to install the ebuild. The script
Jeremy Olexa wrote:
On Thu, Oct 8, 2009 at 4:34 PM, Petteri Räty betelge...@gentoo.org wrote:
Stelian Ionescu wrote:
On Tue, 2009-09-29 at 16:32 +0300, Petteri Räty wrote:
I wrote a script to check which ebuilds use built_with_use and have
keywords in never versions making the ebuild unused
Rémi Cardona wrote:
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
I wrote a script to check which ebuilds use built_with_use and have
keywords in never versions making the ebuild unused. This means that
neither arch or ~arch users are likely to install the ebuild. The script
and the list of ebuilds is attached. I plan on removing all these
ebuilds two weeks from
Josh Sled wrote:
Display-If-Installed: media-libs/jpeg
media-libs/jpeg-7, perhaps?
Yes there should be such a restriction to avoid hitting people who have
already upgraded.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Ulrich Mueller wrote:
On Tue, 22 Sep 2009, Dawid Węgliński wrote:
People may have upgraded but not have followed the advice in the
news item.
If they had upgraded, they also probably have it fixed already.
So for everybody it's obvious how to fix it? If you argue like this,
then you
Samuli Suominen wrote:
Łukasz P. Michalik wrote:
Oh, so there was a change in dependencies without a revbump?
Package managers have always picked up dep. changes without revbump.
-Samuli
s/Package managers have/Portage has/
Regards,
Petteri
signature.asc
Description: OpenPGP digital
Alex Alexander wrote:
*On Sat, Sep 19, 2009 at 23:21, Robert Bridge rob...@robbieab.com wrote:
So the question isn't SHOULD python-3 be stabilised, it's what will break if
it is surely?
There seems to be a misunderstanding on what will happen if/when
python 3 gets stabilized.
The short
Ryan Hill wrote:
(Yes, this has EAPI in the title, so that means everyone will chime in)
I'd like to clarify and (eventually) set in stone our ideas of best practices
when it comes to bumping EAPI for system packages. I was of the belief that
we had decided that system packages should
Arfrever Frehtes Taifersar Arahesis wrote:
2009-09-20 16:44:09 Jesús Guerrero napisał(a):
On Sat, 19 Sep 2009 19:09:38 +0200, Dirkjan Ochtman d...@gentoo.org
wrote:
On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
What is the point of stabilizing it if users shouldn't use it
Arfrever Frehtes Taifersar Arahesis wrote:
2009-09-19 20:20:10 AllenJB napisał(a):
Dirkjan Ochtman wrote:
On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
What is the point of stabilizing it if users shouldn't use it as main
interpreter? Just leave it in ~arch until it can be
Arfrever Frehtes Taifersar Arahesis wrote:
Python 2.4 is deprecated. There are plans to mask for removal it when
remaining packages incompatible with Python 2.5 are fixed.
(We will announce masking of Python 2.4 at least 1 month before masking it.)
Please don't add new packages to the tree
As many of you know EAPI 3 has been waiting for Portage to implement it
for many months now and I asked zmedico for his estimate on whether it
will be done this year:
19:50 Betelgeuse zmedico: Let's put it this way. How likely in
percentages is EAPI 2 this year?
19:50 Betelgeuse s/2/3/
19:51
Nirbheek Chauhan wrote:
On Fri, Jul 31, 2009 at 9:11 PM, Samuli Suominenssuomi...@gentoo.org wrote:
I've just closed http://bugs.gentoo.org/show_bug.cgi?id=105016. But bugs
like these shouldn't be around in the first place. When you remove a
package from tree, please grep the profiles/
I run:
find /usr/portage/profiles/ -name make.defaults -exec grep ssl {} +
It seems quite a few profiles enable ssl. To me it seems makes sense to
enable it by default in base instead. If any profiles want it off by
default they can start disabling it. Any objections?
Regards,
Petteri
Ben de Groot wrote:
Dear fellow devs,
We would like to draw your attention to the fact that the Gentoo Qt team
now officially discourages further usage of Qt3. Version 3 is no longer
being developed or supported upstream. All users are strongly encouraged
to use Qt version 4 where
201 - 300 of 893 matches
Mail list logo
