-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
On Fri, 19 May 2006 15:13:48 +0200
Stefan Schweizer [EMAIL PROTECTED] wrote:
Marc Hildebrand wrote:
Otoh LC_ALL=C could help if you intend to use a .utf-8 locale as
root, though. So if it does help solving bugs and causes no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
debug-build can always be expanded to turn on generic debugging
for other build systems and languages.
Really? Perhaps you can explain the implementation details a little
more, because it's not obvious to me. From my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Wednesday 07 June 2006 16:10, Zac Medico wrote:
Grant Goodyear wrote:
Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]
Mike Frysinger wrote:
this is a *huge* con ... developers are lazy, *i'm* lazy ... i
certainly do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
Well, all that's required is modification to rsync gen script;
I'll do it, assuming that a location has been agreed upon.
$PORTDIR/metadata/herds.xml is the place?
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
Interested in
figuring out what use flags were turned off? Check out
/usr/portage/profiles/base/use.defaults and other use.defaults files
that correspond to your profile.
It's probably easier to let portage do the work and run
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
When FEATURES=mirror, and you try to fetch, it does indeed contain unevaluated
USE flags. However for FEATURES=-mirror, the content of it is correct - no USE
flags at all.
Are you sure about the SRC_URI being different? I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
Zac Medico schrieb:
If a version of SRC_URI that has all the conditionals evaluated is
needed in the ebuild environment, then I think we should use a new
variable name. Otherwise, it's ambiguous.
Doesn't $AA already satisfy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
Is there any particular reason USE_EXPAND_HIDDEN needs to be in
make.globals, as opposed to in base/make.defaults alongside USE_EXPAND?
Seems to me it'd make more sense were the two kept together...
Given the support that's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Fish wrote:
On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote:
per pkg cflags are here already it would fall under the per
pkg env variables.
Please forgive my stupidity, but the only place I could see to set a
env var per package was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Diego 'Flameeyes' Pettenò wrote:
Per-package use.mask is not here for another year and in the mean time I
needed a working solution, this is it.
It think we can have it sooner than another year. There are lots of fixes in
2.1.1_pre and I'd like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Heim wrote:
I'm currently preparing one of my embedded system for a test-run and noticed
that a *binary* package of media-libs/libpng pulls in the autofoo-stuff.
I went looking for the reason, looked into the eutils, multilib and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Saturday 05 August 2006 15:32, Zac Medico wrote:
The actual fault is in libpng-1.2.12-r1.ebuild where RDEPEND= should be
explicitly set.
the actual fault is portage
instead of half-assing all this DEPEND/RDEPEND
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Saturday 05 August 2006 17:29, Zac Medico wrote:
I'm not satisfied with the current implicit RDEPEND behavior either. I
propose that we make repoman force explicit definition of RDEPEND.
and i'm on the opposite side
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
agaffney suggested this in the first place, and every time I think about
it, it seems like a better idea. If we set VIDEO_CARDS and INPUT_DEVICES
in the arch profiles, we get the arch-specific defaults we need without
the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've written a patch [1] that implements support for use.force and
package.use.force as originally described by Sven Wegener [2] over a year ago.
Basically, this feature is the exact opposite of use.mask and package.use.mask.
It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
I read the portage-dev discussion, and I'm still not seeing how this is
superior to make.defaults.
The difference with use.force is that it prevents flags, that are deemed
extremely important, from being accidentally
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
On Tue, Aug 08, 2006 at 08:33:51AM +0100, Ciaran McCreesh wrote:
On Tue, 8 Aug 2006 00:22:50 -0700 Brian Harring [EMAIL PROTECTED]
wrote:
| On Tue, Aug 08, 2006 at 07:23:31AM +0100, Ciaran McCreesh wrote:
| On Mon, 7 Aug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stuart Herbert wrote:
Any chance of per-package USE defaults support? That's much more useful
to me.
Attached to bug 61732 there's a patch that implements this via a new
IUSE_DEFAULTS ebuild variable. If people like that particular
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Currently, portage only allows single inheritance in profiles, but it's easy to
enable multiple inheritance. In order to do this, we only need to unconstrain
the number of parents allowed in the parent file (only 1 is currently
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico [EMAIL PROTECTED]
wrote:
| Currently, portage only allows single inheritance in profiles, but
| it's easy to enable multiple inheritance. In order to do this, we
| only need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
Said single inheritance protection was added 06/05/06 (rev 3544),
stabled for x86 roughly 06/22/06.
Hasn't even yet made it to a release media- meaning folk installing
from the most current release media still can get bit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
Zac Medico wrote:
I'm not sure what the probability of people hurting themselves like
this is. Perhaps it's a negligible corner case and a note in the
upgrade guide will be enough to keep the vast majority of users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Grant Goodyear wrote:
42 (critical news) -- Change owner to zmedico?
Yes, I'll adopt it.
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE/FW3/ejvha5XGaMRAvILAKCUtgAfK4MJzvcmDMnXKHDLiP+7qgCeNU/a
b1umAqjbf5AGkJRmOmhjT+Y=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Portage currently has two hard-coded lists of variables that control
the behavior of env-update. I'd like to make these variables
configurable so that package maintainers have direct control over
them. The variables break down into two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
Zac Medico wrote:
We can store them in /etc/env.d/ itself. The env-update tool could
be hare coded to consider COLON_SEPARATED and SPACE_SEPARATED as
being implicitly within the SPACE_SEPARATED class. The tool would
make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Sun, 10 Sep 2006 18:44:23 -0700 Zac Medico [EMAIL PROTECTED]
wrote:
| Portage currently has two hard-coded lists of variables that control
| the behavior of env-update.
I realise GLEP 24 is considered not going very
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul de Vrieze wrote:
On Monday 11 September 2006 03:44, Zac Medico wrote:
What is the best way to propagate information about these two
variable types? For example, we can have a list of variable names
stored in a new variable called
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Tue, 12 Sep 2006 10:19:40 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| Protected Locations
| ===
|
| Protected locations are determined by the ``CONFIG_PROTECT``
| environment variable, which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Tue, 12 Sep 2006 10:19:40 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| Protected Locations
| ===
|
| Protected locations are determined by the ``CONFIG_PROTECT``
| environment variable, which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Tue, 12 Sep 2006 15:44:22 -0700 Zac Medico [EMAIL PROTECTED]
wrote:
| 3) Prevents /etc/foo from matching /etc/foobaz or /etc/foobaz/bar.
Is this really desired behaviour?
In my opinion, it is a desirable change. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Sunday 10 September 2006 21:44, Zac Medico wrote:
For example, we can have a list of variable names
stored in a new variable called COLON_SEPARATED that will reside
in either the profiles or /etc/env.d/ itself.
/etc
On 11/25/2012 12:27 PM, Lars Wendler wrote:
I also planned to release a news through the portage news system as soon as I
lastrite xchat so people know how to move over to hexchat. As I never did
this
before I'd like to have some help concerning this matter. Is there some
documentation
On 11/28/2012 09:50 AM, Michał Górny wrote:
On Wed, 28 Nov 2012 10:05:55 -0500
Richard Yao r...@gentoo.org wrote:
On 11/28/2012 09:17 AM, Maxim Kammerer wrote:
On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao r...@gentoo.org wrote:
We could slightly simplify the handbook installation procedure
Mon Sep 17 00:00:00 2001
From: Zac Medico zmed...@gentoo.org
Date: Fri, 30 Nov 2012 23:28:30 -0800
Subject: [PATCH] Add mirrorselect --list-only option
---
mirrorselect/main.py | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mirrorselect/main.py b/mirrorselect/main.py
On 12/09/2012 09:15 PM, Brian Dolbec wrote:
No, once they are downloaded, they don't change ever after the quarterly
rollover which starts a new updates file. Nor do they take up
significant storage space. They probably take up a higher percentage of
your fs's inodes than % diskspace.
But
On 12/10/2012 01:27 PM, Michał Górny wrote:
1) duplicate most of the major profiles. Make an EAPI 5-enabled wrapper
profiles which will provide the *use.stable.mask files. Require users
to migrate to those profiles after getting an EAPI 5 capable package
manager (how?). Possibly mask the
On 12/11/2012 01:45 PM, Michał Górny wrote:
On Mon, 10 Dec 2012 22:35:07 -0800
Zac Medico zmed...@gentoo.org wrote:
On 12/10/2012 01:27 PM, Michał Górny wrote:
1) duplicate most of the major profiles. Make an EAPI 5-enabled wrapper
profiles which will provide the *use.stable.mask files
On 12/12/2012 01:32 AM, Michał Górny wrote:
On Tue, 11 Dec 2012 16:44:25 -0800
Zac Medico zmed...@gentoo.org wrote:
On 12/11/2012 01:45 PM, Michał Górny wrote:
On Mon, 10 Dec 2012 22:35:07 -0800
Zac Medico zmed...@gentoo.org wrote:
On 12/10/2012 01:27 PM, Michał Górny wrote:
1) duplicate
On 12/13/2012 12:43 PM, Michał Górny wrote:
On Thu, 13 Dec 2012 21:33:50 +0100
Andreas K. Huettel dilfri...@gentoo.org wrote:
Am Mittwoch, 12. Dezember 2012, 11:30:17 schrieb Zac Medico:
Yes, and having 'stable' and 'unstable' profiles will work just
the same. Except for the fact
On 12/17/2012 09:59 PM, Duncan wrote:
viv...@gmail.com posted on Mon, 17 Dec 2012 12:37:49 +0100 as excerpted:
Some numbers:
Packages installed: 1756
Packages in world:626
Packages in system: 42
Required packages:1756
Number to remove: 0
Heh... try my depclean summary
On 12/18/2012 12:26 AM, Duncan wrote:
Zac Medico posted on Mon, 17 Dec 2012 23:31:24 -0800 as excerpted:
On 12/17/2012 09:59 PM, Duncan wrote:
[1] I long ago filed a bug suggesting a new world-sets line for
depclean,
but I expect it'll be resolved/fixed about the time sets support
On 12/17/2012 02:19 AM, Tomáš Chvátal wrote:
Currently we put portage into /usr/portage and all related stuff is to
be in the subfolders there (distfiles, binpkg).
I've always myself override these defaults in make.conf to point for
/var/portage/ (not /var/lib because I never bothered enough
On 12/17/2012 02:19 AM, Tomáš Chvátal wrote:
Currently we put portage into /usr/portage and all related stuff is to
be in the subfolders there (distfiles, binpkg).
I've always myself override these defaults in make.conf to point for
/var/portage/ (not /var/lib because I never bothered enough
On 12/18/2012 01:33 PM, Diego Elio Pettenò wrote:
No /var/gentoo. No /var/repositories.
/var/db/gentoo, /var/db/repositories, /var/cache/portage ... as long as
Zac is fine with one whatever, but let's not invent any new top-level.
Yeah, /var/db or /var/cache sounds good to me.
I would
On 12/18/2012 11:58 PM, Duncan wrote:
Zac Medico posted on Tue, 18 Dec 2012 09:58:42 -0800 as excerpted:
It's important to clarify that, because /etc/portage/sets (aka GLEP 21
User Sets) has already been supported in stable portage since 2.1.11.9
[1].
I didn't know that. Last I knew
On 12/19/2012 02:01 PM, Alan McKinnon wrote:
On Wed, 19 Dec 2012 14:56:44 +0100
Diego Elio Pettenò flamee...@flameeyes.eu wrote:
Just mv /usr/portage /var/portage ? FFS no. Among other things, as
many said before, we should really take distfiles out of the tree
itself, and packages the
On 12/20/2012 06:12 AM, Graham Murray wrote:
Zac Medico zmed...@gentoo.org writes:
On 12/19/2012 02:01 PM, Alan McKinnon wrote:
If we are going to move distfiles out of the tree into, what are the
odds of getting /some/path/portage/local to move somewhere else too?
What program uses
On 12/20/2012 03:36 AM, Alan McKinnon wrote:
On Wed, 19 Dec 2012 14:19:52 -0800
Zac Medico zmed...@gentoo.org wrote:
On 12/19/2012 02:01 PM, Alan McKinnon wrote:
On Wed, 19 Dec 2012 14:56:44 +0100
Diego Elio Pettenò flamee...@flameeyes.eu wrote:
Just mv /usr/portage /var/portage ? FFS
On 12/20/2012 12:09 PM, Rich Freeman wrote:
On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico zmed...@gentoo.org wrote:
On 12/18/2012 11:58 PM, Duncan wrote:
I didn't know that. Last I knew, stable portage had special-case
acceptance of @system and @world to prepare the way, but I hadn't seen
On 12/20/2012 10:19 AM, Ian Stakenvicius wrote:
On 20/12/12 01:12 PM, Ulrich Mueller wrote:
What about /usr/portage/licenses, for example? Some of the
licenses are required to be present on the system if the
corresponding software is installed. So users cannot legally remove
them.
...
On 12/20/2012 12:35 PM, Pacho Ramos wrote:
El jue, 20-12-2012 a las 12:23 -0800, Zac Medico escribió:
On 12/20/2012 12:09 PM, Rich Freeman wrote:
On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico zmed...@gentoo.org wrote:
On 12/18/2012 11:58 PM, Duncan wrote:
I didn't know that. Last I knew
AM, Zac Medico zmed...@gentoo.org
wrote:
On 12/18/2012 11:58 PM, Duncan wrote:
I didn't know that. Last I knew, stable portage had special-case
acceptance of @system and @world to prepare the way, but I hadn't
seen that full /etc/portage/sets/* and /var/lib/portage/world_sets
support
On 12/23/2012 08:35 AM, Brian Dolbec wrote:
On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote:
On Sun, 2012-12-23 at 12:20 +, Markos Chandras wrote:
But like I said, elog messages are already saved in
/var/log/portage/elog/$cat/$pf so people can
read these. Isn't this the same
On 12/27/2012 05:37 AM, Michał Górny wrote:
EAPI 5 provides use.stable.mask files to solve this but those files
require profiles to be EAPI 5. Therefore, in order to be able to use it
we would have to actually break the update path for older portage
versions completely.
So, adding new
On 12/27/2012 03:40 PM, Andreas K. Huettel wrote:
Am Donnerstag, 27. Dezember 2012, 14:37:37 schrieb Michał Górny:
a) adding new profiles which will require EAPI=5 and requiring all
users to migrate to them after upgrading portage. Using new
use.stable.mask files in those profiles.
OK
On 12/31/2012 09:14 AM, Maxim Kammerer wrote:
Hi,
stage3 now includes non-ASCII paths, via app-misc/ca-certificates -- e.g.:
/usr/share/ca-certificates/mozilla/TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.crt
Working with those (e.g., backup) probably requires a UTF-8 locale.
On 12/31/2012 05:21 AM, Pacho Ramos wrote:
pkg_postinst() {
Some improvements I am not sure how to implement just now:
- What would be the proper way to elog contents
of /usr/share/doc/${PF}/CONFIGURATION.bz2 and, then, allow the following
to be shorter:
if ! has_version
On 12/31/2012 07:22 AM, Leho Kraav wrote:
Hi all
Just bumped into something I haven't encountered before. Running amd64.
Already had sys-auth/pambase-20101024-r2 (stable) installed. Then
installed gnome-base/gdm-3.4.1-r3 binpkg, binhost had newer pambase,
which is why this didn't
On 01/01/2013 05:39 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
#
On 01/02/2013 03:48 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 16:01 -0800, Zac Medico escribió:
On 01/01/2013 05:39 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo
On 01/02/2013 02:46 PM, Brian Dolbec wrote:
On Mon, 2012-12-10 at 08:59 +0100, Ulrich Mueller wrote:
On Mon, 10 Dec 2012, Sergei Trofimovich wrote:
gentoo-x86/profiles/updates $ LANG=C ls -1 --sort=time
[long list omitted]
old entries are done in different context (comparing to 2012):
-
On 01/02/2013 08:49 AM, Leho Kraav wrote:
Ok my conclusion is then that gdm-3.4.1.ebuild should be patched for
[systemd?-], considering it seems otherwise fully compatible with current
stable pambase. Opinions?
Since gdm is using EAPI 4, sys-auth/pambase[consolekit?,systemd(-)?]
seems
On 01/03/2013 02:09 AM, Dirkjan Ochtman wrote:
In any case, we probably shouldn't spend a whole lot of effort on this
given the somewhat-impending git migration, which neatly solves this
problem. Maybe there's some low-hanging fruit in the commit ordering,
though? I was thinking it might be
On 01/02/2013 10:13 PM, Alexandre Rostovtsev wrote:
On Thu, 2013-01-03 at 00:25 -0500, Rick Zero_Chaos Farina wrote:
On 01/03/2013 12:06 AM, Michał Górny wrote:
On Wed, 02 Jan 2013 19:49:02 -0800
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
It came up again with
On 01/06/2013 01:04 AM, Ralph Sennhauser wrote:
On Fri, 4 Jan 2013 23:34:59 -0600
Donnie Berkholz dberkh...@gentoo.org wrote:
On 10:26 Sat 22 Dec , Pacho Ramos wrote:
Hello
After seeing:
https://bugs.gentoo.org/show_bug.cgi?id=440214
Looking to a lot of its blockers shows that we
On 01/06/2013 05:36 PM, Michael Mol wrote:
On Jan 6, 2013 8:32 PM, Zac Medico zmed...@gentoo.org
mailto:zmed...@gentoo.org wrote:
On 01/06/2013 01:04 AM, Ralph Sennhauser wrote:
On Fri, 4 Jan 2013 23:34:59 -0600
Donnie Berkholz dberkh...@gentoo.org mailto:dberkh...@gentoo.org
wrote
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/07/2013 11:46 AM, Amadeusz Żołnowski wrote:
Hi,
Quoting Pacho Ramos (2013-01-07 10:34:52)
- Eclass was originally oriented to cover those kind of messages
that could be shown by elog first time the package is merged and,
later, rely on
On 01/07/2013 05:35 PM, Michael Mol wrote:
On Sun, Jan 6, 2013 at 8:54 PM, Zac Medico zmed...@gentoo.org wrote:
On 01/06/2013 05:36 PM, Michael Mol wrote:
On Jan 6, 2013 8:32 PM, Zac Medico zmed...@gentoo.org
mailto:zmed...@gentoo.org wrote:
On 01/06/2013 01:04 AM, Ralph Sennhauser wrote
On 01/08/2013 11:24 PM, Douglas Freed wrote:
On Thu, Jan 3, 2013 at 5:23 AM, Zac Medico zmed...@gentoo.org wrote:
The CVS keyword expansion causes the ebuild digest to mutate during the
commit. If we repoman could predict correctly emulate the CVS keywords
expansion on the client side
On 01/08/2013 11:36 PM, Zac Medico wrote:
On 01/08/2013 11:24 PM, Douglas Freed wrote:
On Thu, Jan 3, 2013 at 5:23 AM, Zac Medico zmed...@gentoo.org wrote:
The CVS keyword expansion causes the ebuild digest to mutate during the
commit. If we repoman could predict correctly emulate the CVS
On 01/08/2013 11:49 PM, Duncan wrote:
Zac Medico posted on Tue, 08 Jan 2013 23:36:59 -0800 as excerpted:
Thought: Do the CVS keyword expansion in repoman, and then feed the
expanded file to CVS for commit. This gives you a fixed file, which
you can then generate your manifest against
On 01/09/2013 12:40 AM, justin wrote:
My question, did anybody else might have observed similar things? Is
there a flaw in this *ECLASS_ONCE_* stuff?
There could well be, but even in the absence of the *ECLASS_ONCE_*
stuff, the problem that you're describing could be attributed to eclass
On 01/09/2013 01:09 AM, Fabian Groffen wrote:
On 09-01-2013 00:31:04 -0800, Zac Medico wrote:
Of course that assumes that the keywords are suitably distinct such that
they won't ordinarily be found in the pre-expanded lines. Whether that's
actually the case or not I've no idea...
Well
On 01/09/2013 12:31 AM, Zac Medico wrote:
I guess we could use the cvs -ko option [1] on all files. That's
apparently what prevents $Header expansion for $PORTDIR/skel.ebuild.
Actually, we should use -kb rather than -ko, since -kb disables
transformations entirely [1]. The -ko mode is identical
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
--
On 01/11/2013 01:10 AM, Brian Dolbec wrote:
On Wed, 2013-01-02 at 17:05 -0800, Zac Medico wrote:
This command seems to do the trick:
$ ls -1 /usr/portage/profiles/updates/ | grep -Ev '(08|09|10|11|12|13)$'
1Q-2004
1Q-2005
1Q-2006
1Q-2007
2Q-2004
2Q-2005
2Q-2006
2Q-2007
3Q-2004
3Q
On 01/12/2013 01:46 AM, Pacho Ramos wrote:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2013 02:34 AM, Pacho Ramos wrote:
El sáb, 12-01-2013 a las 02:01 -0800, Zac Medico escribió:
On 01/12/2013 01:46 AM, Pacho Ramos wrote:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
--
Thanks,
Zac
On 01/13/2013 09:43 AM, hasufell wrote:
On 01/13/2013 03:24 PM, Michał Górny wrote:
Hello,
Right now an attempt to commit an ebuild with no HOMEPAGE results
in:
HOMEPAGE.missing 1
app-admin/eselect-sh/eselect-sh-0.4.ebuild
Note: use --include-dev (-d) to check
On 01/13/2013 04:59 AM, Pacho Ramos wrote:
El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash
On 01/14/2013 01:33 AM, Dirkjan Ochtman wrote:
I've seen this pop up a lot recently:
* One or more symlinks to directories have been preserved in order to
* ensure that files installed via these symlinks remain accessible. This
* indicates that the mentioned symlink(s) may be obsolete
On 01/14/2013 06:46 AM, Ian Stakenvicius wrote:
This particular symlink was put there by openrc though, wasn't it?
Yeah, openrc uses the migrate_to_run function from /etc/init.d/bootmisc.
So
I'd expect that on the whole this should be left for openrc to deal
with or otherwise left to the
On 01/14/2013 07:09 AM, Ian Stakenvicius wrote:
On 14/01/13 09:57 AM, Zac Medico wrote:
On 01/14/2013 06:46 AM, Ian Stakenvicius wrote:
This particular symlink was put there by openrc though, wasn't
it?
Yeah, openrc uses the migrate_to_run function from
/etc/init.d/bootmisc.
So I'd
On 01/14/2013 07:44 AM, Zac Medico wrote:
On 01/14/2013 07:09 AM, Ian Stakenvicius wrote:
OK i'm a little confused. Putting my earlier note aside, if the
symlink will be auto-cleaned after no packages use it, what's the
point/need for the original message from portage then?? Is it just QA
On 01/14/2013 08:26 AM, Ian Stakenvicius wrote:
On 14/01/13 10:53 AM, Zac Medico wrote:
On 01/14/2013 07:44 AM, Zac Medico wrote:
On 01/14/2013 07:09 AM, Ian Stakenvicius wrote:
OK i'm a little confused. Putting my earlier note aside, if
the symlink will be auto-cleaned after no packages use
On 01/14/2013 09:23 AM, Diego Elio Pettenò wrote:
On 14/01/2013 18:14, Zac Medico wrote:
It might be a lot simpler to just go and patch all the ebuilds that
installed stuff in /var/run with a one-liner like this at the end of
src_install:
It's a good idea to do so to avoid the check coming
On 01/16/2013 04:00 PM, Michael Weber wrote:
On 01/16/2013 06:33 PM, Michael Orlitzky wrote:
Yes, sorry for the confusion. I use more than one package manager,
and when doing an update or upgrade I'm basically flipping a
coin.
hehe, as long as we don't --dist-upgrade ;-)
the g was
On 01/16/2013 09:32 AM, Michael Orlitzky wrote:
On 01/16/2013 12:24 PM, Ian Stakenvicius wrote:
On 16/01/13 11:47 AM, Michael Orlitzky wrote:
On 01/16/2013 11:36 AM, Michael Weber wrote:
emerge --upgrade
with a predefined EMERGE_UPGRADE_OPTS in make.conf (where
EMERGE_DEFAULT_OPTS lives).
On 01/17/2013 07:17 AM, Pacho Ramos wrote:
El lun, 14-01-2013 a las 01:29 -0800, Zac Medico escribió:
On 01/13/2013 04:59 AM, Pacho Ramos wrote:
El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use
On 01/17/2013 08:00 AM, Pacho Ramos wrote:
Another try ;)
Looks good to me.
--
Thanks,
Zac
On 01/17/2013 08:47 AM, Ciaran McCreesh wrote:
On Thu, 17 Jan 2013 07:47:18 -0800
Zac Medico zmed...@gentoo.org wrote:
REPLACING_VERSIONS always refers to packages with identical SLOT to
the current package
No it doesn't. If you have foo-1:a and foo-2:b installed, and then you
install foo
On 01/17/2013 12:32 AM, Dustin C. Hatch wrote:
On 1/16/2013 11:32, Alexis Ballier wrote:
Other option: kill the server subprofiles, keep profiles/target/server
and let people finally set /etc/make.profile as a dir and play with
multiple inheritance. We don't need dozens of subprofiles with
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host.
If necessary, you can use /etc/portage/bashrc to override
CONFIG_CHECK_FATAL for binary packages. Something like this
On 01/21/2013 08:10 PM, Rick Zero_Chaos Farina wrote:
On 01/21/2013 10:56 PM, Zac Medico wrote:
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host.
If necessary, you
On 01/22/2013 01:22 AM, Markos Chandras wrote:
On 22 January 2013 03:56, Zac Medico zmed...@gentoo.org wrote:
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host
On 01/21/2013 10:22 PM, Sergey Popov wrote:
22.01.2013 08:23, Mike Gilbert wrote:
I guess this change is ok, given that I can opt-out fairly easily. Zac's
workaround for binary packages makes me feel better too.
I am curious, can not this check be added to eclass? Or eclass does not
know
On 01/24/2013 07:15 AM, Ian Stakenvicius wrote:
In general, I would recommend for any library maintainers, to either
file bugs against the rdeps of a package or directly update the rdeps
(with permission, of course) when implementing sub-slots. Of course,
I believe the rdeps of a library can
On 01/23/2013 12:42 PM, Tomáš Chvátal wrote:
It might be pretty usefull to actually see where the deps needed to be
updated so we can take use of this feature where possible (also its a
hint for lib maintainers to update their libs and see real impact).
Another useful hint, for those that have
On 01/27/2013 03:26 AM, Pacho Ramos wrote:
El dom, 27-01-2013 a las 00:26 +0100, Andreas K. Huettel escribió:
Just to keep everyone updated, ...
FYI, the new 13.0 profiles are now all available in profiles.desc, for now
all with status dev (i.e. repoman includes them only when you request
1 - 100 of 3129 matches
Mail list logo
