Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Thursday 25 March 2010 20:05:17 Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-25 19:34:24 Roy Bamford napisał(a): On 2010.03.24 21:12, William Hubbs wrote: The case where Python-3 cannot be used as the default Python is transitory (it may be a long time). Gentoo Python Project will soon start supporting setting Python 3 as main active version of Python. Currently about 57% of our packages from dev-python category are prepared. That's really good news! Why not wait a little bit until this is accomplished? I know it would make me feel a lot more comfortable with having python 3 in stable. Marijn
Re: [gentoo-portage-dev] a feature called stabilize wanted
On Wednesday 10 March 2010 10:58:45 Johannes Kellner wrote: Hello List ans anyone! I'm searching for a feature or an hint how and where to implement it. The desired feature could be called stabilize or update to stable and would change the selected packages when doing an update (emerge -avuND world). [snip] Anyone, could help me? Give me a hint if this would be possible? Any hints where in code this could be implemented? I'm programmer, professional, so if I get the right hints, will invest spare time in this. Also I'll ready to setup and run various tests. But I never before worked at portage... It might be a good start if the people with the Know-How, will start a discussing about this idea, what problems need to be solved, which code parts will need an update and so one. Than I could try to get it working, but right now, I doesn't even know the right questions. Best regards, - Johannes Kellner At first glance your idea seems very interesting. However the versions you end up with under your system critically depends on the timing between when things go stable and when you perform an update. You could skip past a ~ version that is just about to go stable, because a newer ~ was visible, but if you'd waited just a bit longer with syncing and updating you would have gotten the stable version and no further update would have gotten you the newer ~ version. If you still wish to implement it anyway, then I would suggest that you need a new keyword modifier to indicate ``highest stable version or if that is not available the highest testing version'' and adapt the visibility code to understand that new keyword modifier and make the appropriate versions visible. I don't actually know about portage internals, but this is how I imagine it should work. Marijn
[gentoo-dev] up-to-date presentations on Gentoo?
Hi, I am planning on going to ``FOSS Nigeria 2010'' (http://fossnigeria.org/) and have been asked to do a presentation on Gentoo. My current expectation is that they are expecting and would benefit most from a very basic introduction. If anyone has anything like that (doesn't even have to be complete) that I could start from that would a be great help. The PR subproject Gentoo Presentations has a listing of available presentations: http://www.gentoo.org/proj/en/pr/docs/presentation-listing.xml but they are all dated in 2005. Marijn
Re: [gentoo-dev] Gentoo Prefix Lite Quiz
On Friday 18 December 2009 14:00:06 Fabian Groffen wrote: As promised, here is the slimmed down version of the Prefix quiz. As requested, I'll post the answers on -core. Prefix development quiz (Zero taste) ** when porting ebuilds for Gentoo Prefix, one will get confronted with certain problems, these two questions hint at such problems ** 4. Package Y has a configure script that's just being run by econf. You just added Y and now try to install it. What do you watch for? Maybe better: 4. Package Y's configure script has just been run. What potential problems do you especially need to be on the lookout for in the output of ./configure? Marijn
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 these
ebuilds two weeks from now unless a reason is given why not to. If you
see an ebuild on the list that should be kept, please migrate it to EAPI
2. If you need assistance in migrating, I can help. With these gone
built_with_use usage will be down to about 600:
I have some ebuilds on the list: plt-scheme, stklos, lilypond. I usually clean
up unused ebuilds some time after a new version has gone stable.
Anyway my question is: what is the point of removing unused versions in the
proposed manner? If the newer version is not ported to EAPI 2 and also uses
built_with_use what do we gain? Even if it is already ported, do we gain
anything by the propsed removal? Are all unused ebuilds evil?
If built_with_use is to be eliminated from the tree I propose that effort is
directed towards porting and stabling ebuilds that still use it. After the
stable version has begun using EAPI 2 use deps, then all uses of built_with_use
in other versions can be considered obsolete and those ebuilds can be removed in
one fell sweep if need be.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkrMedEACgkQp/VmCx0OL2zCEACeK0xQpwjf1UPGVWz4izqD/km6
6ZoAn2BQAcS8Ir0NKAkaH5ui1U/cN1V3
=rmtP
-END PGP SIGNATURE-
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sebastian Pipping wrote:
Hello there!
Among other information the Gentoo page at DistroWatch [1] displays a
table on about 200 selected packages [2] and how up to date Gentoo is
per package. I assume that DistroWatch is still one of the first places
people go to get a feeling for a Distro they heard about, besides
Wikpedia and ${distro}.org.
The freshness of these 200 packages have influence on how people
perceive Gentoo on DistroWatch. While the tree as a whole is what we
should keep as up to date as possible keeping these 200 packages (list
further down) up to date can therefore be of particular importance.
From a quick look at the table these packages seem to need extra care in
Gentoo:
cups (1.4.0) 1.3.11 -- latest in Gentoo unstable/testing
koffice (2.0.2) 1.6.3
There has been koffice-meta-2.0.2 for a while.
mysql (5.1.38) 5.0.84
perl (5.10.1)5.8.8
php (5.3.0) 5.2.10
samba (3.4.1)3.3.7
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqrhLwACgkQp/VmCx0OL2xRjQCfUPpebxYVEaUC2aMAgFGOm8ov
Y/oAoLWiRr4kXCsS/JCFb6R5mleJKCqi
=DENW
-END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Sun, 30 Aug 2009 19:06:02 +0200
Mounir Lamouri volk...@gentoo.org wrote:
So I think we should add a new feature in PMS already used in Exherbo
EAPI, USE flags requirements [1]. That means an ebuild should be able
to say a USE flag is available only if some other ones are in a
specific state. Let's take the mplayer example, if we have a line
like this: USE_REQUIREMENTS=encode? ( mp2 mp3 faac x264 xvid ), PM
should be able to show the user USE=mp3 will be ignored because he
didn't set USE=encode and the PM will disable this USE flag by
himself. The same way, for ekiga:
USE_REQUIREMENTS=kde? ( kontact ), PM should be able to show thed
user if he set USE=kontact, kde USE flag is enabled and the PM will
enable this USE flag by himself.
Is the less expressive solution you're describing still useful enough
to make it worthwhile? When we were doing this for Exherbo, we
identified five types of inter-use-flag dependency:
* if a then b
* if a then not b
* at least one of a b c, possibly only if d
* exactly one of a b c, possibly only if d
* at most one of a b c, possibly only if d
Does Gentoo make use of all of these, and are there any cases that the
above doesn't cover? How would you express each of the above using
USE_REQUIREMENTS?
From a package manager perspective, it's much easier to give good
advice to the user if we're told by the ebuild exactly what's going on.
I've said this before, but maybe now the time is right.
I think that many of these issues are caused by use flags being binary which
causes the total number of options to be a power of 2. If the real total number
of options is not a pwoer of 2 then some combinations of use flags are a priori
bad and thus currently we try to work around this.
I propose that use flag are not merely binary flags, but can take a value out of
a range of possible values. Binary use flags could be `on' or `off'. Other use
flags could range over a wider range of values. We could then catch errors early
as use flag $flag has bad value $badvalue.
* if a then b
This means that the situation +a -b is bad. So going with the ekiga example
above, there could be a `kontact' use flag with possible values `off-kde',
`off+kde' and `on'. The same situation can also be modeled by a `kde' use flag
with possible values `on-with-kontact', `on-without-kontact', `off'.
* if a then not b
Basically the same as above: +a +b is bad, so use flag `f' could range over
a-b -a-b -ab and signal an error for any other value.
* at least one of a b c, possibly only if d
I would be interested in knowing the specifics of packages wanting this. (It
could possibly be addressed by use flags that take a set of values
simultaneously.)
* exactly one of a b c, possibly only if d
There should be a use flag `d' with possible values in `a', `b', `c' and
possibly `off'. This is really the situation where my proposal shines. This
covers the situation where you need an implementation of $proglang but don't
care whether it is $progimpl-lolcat, $progimpl-fuzzycat, $progimpl-dog or any
one of a number of other supported implementations.
* at most one of a b c, possibly only if d
This situation is equivalent to the situation:
* exactly one of `a' `b' `c' `none', possibly only if d which was solved above.
4 out of 5 ain't bad ;P
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqbq4YACgkQp/VmCx0OL2wyLQCgiZz5l+UyPEMc8Ci35C/muAmd
IZEAniGWrm52eWZTsyJUDGzVJjx8uRlH
=iieZ
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: EAPI 3 and nonfatal die
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Faulhammer wrote:
Hi,
Ryan Hill dirtye...@gentoo.org:
On Fri, 21 Aug 2009 21:56:41 +0100
David Leverton levert...@googlemail.com wrote:
Does anyone have any opinions on which of the four options (#1
make die respect nonfatal, #2 make die always die, #3 add a new
die variant that respects nonfatal, #4 make regular die respect
nonfatal, and add a new variant that doesn't) we should go with?
We should definitely get this resolved and agreed on before EAPI
3 is finalised.
I'd like die to respect nonfatal. People using nonfatal should check
beforehand that the functions they're calling won't do anything
stupid if die's are ignored. If there's something that absolutely
has to die, nonfatal or not, then use a variable. I guess that's #4?
I agree here (yes, I know, a ME TOO posting, but I say this as PMS
team member).
I thought the whole idea was that functions that don't currently die by default
because sometimes this is unwanted will now die by default but provide an opt
out --non-fatal switch to get back the old behavior. In the non-fatal case such
functions should then again (as in the current situation) not call die.
Some functions will not have a --non-fatal switch.
Some functions should not have a --non-fatal switch.
Some functions will call die unconditionally.
What is the reason that we are trying to generalize non-fatal from a simple
switch to a full-blown primitive that should handle whatever it's thrown?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqTuzoACgkQp/VmCx0OL2xh1ACgjvtPz+3uke5p2p+iVuSmGw1u
JKwAn2O2l1h8gRDkGnfZ2aIwaIHvlr/L
=ybPQ
-END PGP SIGNATURE-
Re: [gentoo-dev] Support for multiple ABIs (for Python modules etc.)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arfrever Frehtes Taifersar Arahesis wrote:
I would like to present the plan of support for multiple ABIs. It should be
sufficient for
Python modules and might be also appropriate for some other ABI types (e.g.
for Ruby modules).
In the context of which problem are you brainstorming?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpsTq0ACgkQp/VmCx0OL2xqtACglJ7tpOXL4DAeSvo+sLpSc5ir
NsEAoLmyH9EbXydfk4dpCJiHxLqr6WFS
=lmdT
-END PGP SIGNATURE-
Re: [gentoo-dev] gpe-games: new category
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Angelo Arrifano wrote:
Hello all,
I have the following packages that need a home in the portage tree:
gpe-go
gpe-julia
gpe-life
gpe-lights
gpe-othello
gpe-tetris
gsoko
xdemineur
They are only a few and they won't increase much in the future.
For this reason I'm reticent in creating the gpe-games category in the
portage tree as we currently have in the overlay.
So what is this gpe/GPE palm environment thingy?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpdm4EACgkQp/VmCx0OL2y2CQCfY83dRlPb2yMc5uNpb3EDAyX/
OCYAnjGnNYA+qihTJcndB/sQSIoR9Q5d
=DJhp
-END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] QA last rites for x11-libs/ViewKlass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Diego E. 'Flameeyes' Petten wrote:
# Diego E. Pettenò flamee...@gentoo.org (6 Jul 2009)
# on behalf of QA Team
#
+# Fails to build; mirror-restricted; unmaintained in Gentoo (but
+# active upstream); not used by anything in-tree.
I'm not interested in saving this, but this seems to be LGPL'ed software[1], so
it seems odd that it is mirror-restricted.
Marijn
[1]http://viewklass.cvs.sourceforge.net:80/viewvc/viewklass/viewklass/COPYING?revision=1.1.1.1view=markup
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpbNf0ACgkQp/VmCx0OL2wrcACgpxhzATXIaFBMxmshpR0OK9UQ
Qo0AninUxK7uoeeyX78F1hfA4X3CZVkS
=OpVa
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Problems with the current bzr eclass.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Faulhammer wrote:
Hi,
Harley Peters har...@thepetersclan.net:
Since I did a full checkout with the EBZR_FETCH_CMD=bzr checkout
it now deletes the entire previous checked out branch (to save disk
space ?) and proceeds to fetch the entire source again.
Why would I ever want to do that ? The whole point of bzr is to save
bandwidth not disk space. Is there a way arouund this ?
You can add a modified bzr.eclass to a local overlay which will shadow
the one from the Portage tree. This idea was born because initial
checkouts are/were incredibly slow, so give first time users a better
first experience and not let them wait 20 minutes (what happened with
the Emacs repository).
V-Li
I understand that the time trade-off favors lightweight checkouts, but if there
is a pre-existing full checkout then why secondguess the user and delete it? It
seems to me that the lines
elif [[ -d ${EBZR_BRANCH_DIR}/.bzr/repository/ ]]; then
einfo Re-fetching the branch to save space...
rm -rf ${EBZR_BRANCH_DIR}
bzr_initial_fetch ${EBZR_REPO_URI} ${EBZR_BRANCH_DIR}
should be removed. If users want to get rid of full checkouts they can easily
delete them themselves.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpbOMwACgkQp/VmCx0OL2yXBQCfVAGkJGkugj3nOoa2vgOn6cLj
X+YAn2LtVEZ3jsFVdAUArtuuRkJfKrp1
=HmE/
-END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: 14 X input drivers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
� wrote:
# 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-elo2300
x11-drivers/xf86-input-jamstudio
x11-drivers/xf86-input-magellan
x11-drivers/xf86-input-magictouch
x11-drivers/xf86-input-microtouch
x11-drivers/xf86-input-palmax
x11-drivers/xf86-input-spaceorb
x11-drivers/xf86-input-summa
x11-drivers/xf86-input-tek4957
x11-drivers/xf86-input-ur98
All of those are marked as unsupported by upstream and their git code no
longer builds (./configure was made to abort on purpose).
Why were they marked unsupported by upstream? Is there a replacement, are they
no longer needed, some other reason?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpbSwYACgkQp/VmCx0OL2yaawCfZ3n8ANUJQc6ucoKcZP9OBmKW
eVUAn1XAh/G474UQZMGIcH6yAOgjyT4e
=aQRY
-END PGP SIGNATURE-
Re: [packagekit] [gentoo-dev] Inviting you to project PackageMap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sebastian Pipping wrote:
Marijn Schouten (hkBst) wrote:
Sebastian Pipping wrote:
I start to understand the real benefits of moving a larger
part of the maintenance down to the distro level as you proposed.
Okay, let's add support for CPEs at distro package level
and sync up and down with the central packagemap database.
Please contact me for collaboration on sync scripts
and modeling of details.
Do we not already have enough information available to automatically
determine
derived unique identifiers like CPE?
We have the package homepage and the package name (and the package category)
and
the combination should be enough information to do direct comparisons to data
gathered from other repos (assuming they also contain such data).
You are asking a valid question. The homepage links can be a great
helper in mapping and they have been of help already for the mapping
of the first 1000 Gentoo packages in packagemap.
However it might not be as easy you make it sound, as there are
a few things that complicate things and produce extra work:
- In many cases a project can be reached from several URLs.
For a project on SF.net you might have
- http://sf.net/projects/${name}
- http://${name}.sf.net/
- http://www.${name}.org/
That case can be handled rather easily but there are many more
special cases and a manual map may be required for stuff that's
not hosted on a larger hosting site.
But homepage is just ONE of the things that help you to identify a package. Some
packages that are the same will have different homepages and some packages which
are different will have the same homepage. If you take just homepage, package
name into account and the fact that packages from the same repo are different,
you can probably match over 95% of all packages correctly.
- Split packages (think Git or Qt) may all have the same homepage.
In Debian the source package might help there, in Gentoo you'd
have to do common prefix detection or so, that's special
cases again, and continuous review that it still does what you need.
Neither of the gits gentoo has seems very split, so I'll only address qt. Gentoo
has qt-core and qt-svg (and many more). I would say that they would each have to
get a different CPE and that none of them is equivalent to a package in another
or the same distro that has all of qt combined. Packages that get manually split
are a minority AFAIK, though texlive is another big one that comes to mind.
Debian does splitting into ``normal'' and ``devel'' packages. Has it been
decided what to do with those?
Now that you got me thinking about split packages, I realize that the exact
files installed by a package are also all by themselves a way to get over 95%
correct matching. For distros (like Gentoo) that have packages that have flags
that influence the list of installed files you must decide whether to add them
to the database last, or whether you will try to use an imprecise file list.
For example you can determine automatically that gentoo:dev-scheme/gambit and
debian:gambc are the same package because although their names differ they
have
the same homepage and share a category.
To detect equal categories you need a map for categories for all
participating distros. Yes, it's smaller than mapping all packages
but it involves a manual map and keeping it in sync.
No, there need not be a manual mapping. There is no reason to do true/false
comparisons. All we need is a distance function, like for example Levenshtein
distance (http://en.wikipedia.org/wiki/Levenshtein_distance). Actually on second
thought Levenshtein distance is probably not what we want, since we would be
more interested in how much strings have in common than in how much they differ.
I think the idea is clear though.
Another word on homepage collisions: A few days before I wrote
a script that builds a map from homepages to packagenames for the
whole Gentoo tree (code/gentoo/gentoo-world-to-homepage-map.sh).
The generated table from my run was 12330 lines long, each line for
a different package.
If you run an analysis over that table you see that many
homepages appear many more times than just once.
Here's the top ten:
68 http://www.gnome.org/
67 http://www.gentoo.org/
58 http://www.gentoo.org/proj/en/perl/
42 http://lingucomponent.openoffice.org/
26 http://www.kde.org/
25 http://www.gentoo.org
20 http://sourceforge.net/projects/synce/
19 http://www.trolltech.com/
19 http://search.cpan.org/~rjbs/
18 http://opensuse.foehr-it.de/
texlive with (http://www.tug.org/texlive/) seems to be missing from this list.
$ eix -H http://www.tug.org/texlive/ | tail -n 1
Found 79 matches.
I suspect you used grep (or whatever) to construct your data, instead of using
the package manager or a tool that knows how to extract the data available in
packages (and eclasses
Re: [packagekit] [gentoo-dev] Inviting you to project PackageMap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sebastian Pipping wrote:
I start to understand the real benefits of moving a larger
part of the maintenance down to the distro level as you proposed.
Okay, let's add support for CPEs at distro package level
and sync up and down with the central packagemap database.
Please contact me for collaboration on sync scripts
and modeling of details.
Do we not already have enough information available to automatically determine
derived unique identifiers like CPE?
We have the package homepage and the package name (and the package category) and
the combination should be enough information to do direct comparisons to data
gathered from other repos (assuming they also contain such data).
For example you can determine automatically that gentoo:dev-scheme/gambit and
debian:gambc are the same package because although their names differ they have
the same homepage and share a category.
To create the database, every time you see a package you get its metadata from
its home repo. Use those values to compare to existing CPEs. If it is not yet in
the database create a new entry (CPE) for it with all the metadata like
homepage, categories, other-stuff-that-is-useful that is available. Every time
you get a match you may want to improve the metadata of the CPE with the
metadata of the newly added match. The very least you want to do is record the
addition of the new match. For example if you just automatically determined that
debian:gambc matches the CPE you already have for gentoo:dev-scheme/gambit then
you add debian:gambc to the list of matches.
This should get you 99,99% of all packages. You can arrange to be able to
provide hints to the system for cases where it isn't able to do the correct
derivation automatically. This can be done by adding this information to an
empty CPE-database. For example if the system wouldn't be able to match
gentoo:dev-scheme/gambit and debian:gambc, then you can create a CPE entry that
contains both in its matchlist. The first thing that your program should then do
to populate the database is automatically fill out the rest of that CPE by
querying the gentoo and debian repos.
Users will be able to use names from any repo that they please in interactions
with packagekit's package manager (wrapper). For example they could do:
packagekit install debian:gambc. This is a lot more intuitive than using CPEs
directly (I don't know if this is what is intended).
There does not seem to be a need to do any manual conversion, enlist help from a
lot of distro packagers or add CPE to our metadata.
Is this the way you are also intending this to work? If not, why?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAko4uUkACgkQp/VmCx0OL2ySvwCfQHwn2R/yC9EHx8KFjOE0B3f9
CCwAnRXqFX8q0Kt3MlMS9e63PC0LaiV+
=Y0gZ
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: How not to discuss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Freeman wrote:
Steven J Long wrote:
Getting into a nonsensical debate about PN being metadata seems to be
the level of the argument, so forgive me for not being very impressed.
(It's externally derived and in fact the whole point of the product;
unless someone is proposing losing PN and PV from filename, can we
*please* dismiss that argument as the irrelevance which it is?)
Without actually intending to open a new debate on that issue cringes,
I'm actually a fan of NOT obtaining PN and PV from the filename. I've
seen an approach like this used in various systems and I happen to like it:
In which systems did you see this approach?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkomU8YACgkQp/VmCx0OL2ym0QCfcbruFkqtUIBhdwhKIjaP9qol
Qi8An0TdECGv14pgMTmjdDhllvGylM7y
=1iV1
-END PGP SIGNATURE-
Re: [gentoo-portage-dev] Re: Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
On Sun, May 31, 2009 at 4:21 AM, Marijn Schouten (hkBst)
hk...@gentoo.org wrote:
Duncan wrote:
Patrick Börjesson psychoti...@lavabit.com posted
20090529201741.gb11...@nexon.nexus, excerpted below, on Fri, 29 May 2009
22:17:41 +0200:
Why exactly would you want to use --oneshot for a leaf package that is
not depended on by any other package in the world set? If spam IS
depended on by any other package (recursively) in the world set, it will
be pulled in by --complete-graph, but that's not the case here if i
understand it correctly, thus it's a package that you explicitly wanted
installed, thus it belongs in the world set, and you should thus not use
--oneshot for it.
I use -1 by default, here (via scriptlet), mainly so I don't have to
worry about cluttering up my world file while emerging individual
packages, just as I always use -NuD with my @system and @world runs.
But for leaf packages, it serves as a sort of test install as well.
Since I always do revdep-rebuild -p and emerge --depclean -p after every
update (typically 2-3 times a week), then rebuild and clean as I need to,
keeping the trial merges on the depclean list for a few days keeps me
aware of them. If I know it's something I want to keep, I run a
different scriptlet without the -1, but that's not often once a system is
up and running with the normal working set merged. Meanwhile, I
ultimately either emerge -C (or let depclean handle it) the trialware,
or emerge --noreplace, thus adding it to world.
But experimental installs and their deps typically sit in the --depclean
list for anything from a few minutes to a few days, until I decide
whether I want to keep or remove them.
If he was testing how the switches under discussion here worked and has a
similar policy, I could easily see him using -1 by habit, even if he
didn't explicitly reason that it was a test and therefore something he
didn't want in @world.
I think this is an interesting use-case. It would be very simple to handle it
by
introducing an additional file that the package manager would use to record
the
packages that are installed on trial-basis. This would make it possible to
include these packages in dep-calculations, while still distinguishing them
from
packages that are in @world. Of course you can also fake it by creating a
local
virtual/trialware package (or possibly a @trialware group) of which you edit
the
deps, but this would be less convenient. For my personal workflow using -1 for
trials is working well enough, atm.
Why is a custom set less convenient?
Well, instead of emerge --trialware package you would first have to edit your
@trialware set and then emerge @trialware. The same goes for when you want to
remove some trialware.
Perhaps some generalization of --trialware along the lines of
- --add-to-set=trialware could be fleshed out as a useful extension of portage.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkomWO8ACgkQp/VmCx0OL2wGHACfdlOdzvfLM3aUafiuOVQTlRnz
vvMAoMMeLUxnM2i8fpJhClxbsIqwMf3Z
=HSIG
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mounir Lamouri wrote:
I've attached a script to count how many instances of each license
there are, and how many instances in each group. Here are the group
counts I get:
@FSF-APPROVED 23641
@GPL-COMPATIBLE 22956
@OSI-APPROVED 23284
@other 5998
@total 30549
Thanks for reading,
Mounir
I always thought that @OSI-APPROVED would be a proper superset of @FSF-APPROVED,
but these numbers say otherwise.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoisFUACgkQp/VmCx0OL2yujgCfXO3b9ecobv5plZWR+ybdWfXU
ukQAoJWCU28z172+YQu6oiWmH7VshKqn
=4nwA
-END PGP SIGNATURE-
Re: [gentoo-portage-dev] Re: Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
Patrick Börjesson psychoti...@lavabit.com posted
20090529201741.gb11...@nexon.nexus, excerpted below, on Fri, 29 May 2009
22:17:41 +0200:
Why exactly would you want to use --oneshot for a leaf package that is
not depended on by any other package in the world set? If spam IS
depended on by any other package (recursively) in the world set, it will
be pulled in by --complete-graph, but that's not the case here if i
understand it correctly, thus it's a package that you explicitly wanted
installed, thus it belongs in the world set, and you should thus not use
--oneshot for it.
I use -1 by default, here (via scriptlet), mainly so I don't have to
worry about cluttering up my world file while emerging individual
packages, just as I always use -NuD with my @system and @world runs.
But for leaf packages, it serves as a sort of test install as well.
Since I always do revdep-rebuild -p and emerge --depclean -p after every
update (typically 2-3 times a week), then rebuild and clean as I need to,
keeping the trial merges on the depclean list for a few days keeps me
aware of them. If I know it's something I want to keep, I run a
different scriptlet without the -1, but that's not often once a system is
up and running with the normal working set merged. Meanwhile, I
ultimately either emerge -C (or let depclean handle it) the trialware,
or emerge --noreplace, thus adding it to world.
But experimental installs and their deps typically sit in the --depclean
list for anything from a few minutes to a few days, until I decide
whether I want to keep or remove them.
If he was testing how the switches under discussion here worked and has a
similar policy, I could easily see him using -1 by habit, even if he
didn't explicitly reason that it was a test and therefore something he
didn't want in @world.
I think this is an interesting use-case. It would be very simple to handle it by
introducing an additional file that the package manager would use to record the
packages that are installed on trial-basis. This would make it possible to
include these packages in dep-calculations, while still distinguishing them from
packages that are in @world. Of course you can also fake it by creating a local
virtual/trialware package (or possibly a @trialware group) of which you edit the
deps, but this would be less convenient. For my personal workflow using -1 for
trials is working well enough, atm.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoiaCoACgkQp/VmCx0OL2yMRgCeKQ+bIh6RViaTiHKBc8bkREBo
yF0An2XXyngQ2cfuYwKHdUMBP5efcHrV
=Xfc/
-END PGP SIGNATURE-
Re: [gentoo-dev] How not to discuss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Piotr Jaroszyński wrote:
I think what you are missing is that some people (me included) think
that the in-file approach is the cleanest and most obvious solution
(which also happens to not hurt performance). So if you want bad
design to be an objective argument you need to back it up with
something concrete. For example, could you foresee any actual problems
of the in-filename approach? Cause all I was hearing was it doesn't
look nice which now is oh no, don't expose metadata. The former is
clearly subjective and the latter is already done ($PN-$PV) and
doesn't seem to cause any problems.
What we care about doing is being able to install a package of a known name, PN,
with a known version, PV, and we may even want to make sure that the revision,
PR, is just right. Therefore PN, PV and PR are not metadata, but actual data to
identify a specific software unit. (This is also why PR should be bumped if (and
mostly only if) there are changes to files that will be installed.)
On the other hand, EAPI is a value that encodes what is valid in an ebuild and
as such is an implementation detail. Exposing implementation details is bad
design.
Actually I think just changing extensions is also an implementation detail. If
we need the user to make certain upgrades (portage, bash) before being able to
use certain ebuilds then we should just tell them. What else are news items for?
As long as we provide an upgrade path from version X_years_old to version
X_days_old via versions A, B and C, I think we have done our part. In fact we
already had one such situation with bash and portage.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkofqY4ACgkQp/VmCx0OL2xOLQCgqkXnwaThpT2oOdpiliS7SHRa
pt8An3/S6O+LiXkzQBRPsw0zRUmxhNZp
=Ntpj
-END PGP SIGNATURE-
Re: [gentoo-dev] GLEP 54 and hyphens in PV
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Piotr Jaroszyński wrote:
2009/5/28 Ulrich Mueller u...@gentoo.org:
On Thu, 28 May 2009, Tiziano Müller wrote:
${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
you probably mean:
${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild
No, I mean what I had written, namely to use an underscore as
separator, i.e., _live. But when the version is just live alone,
one would suppress the underscore for aesthetic reasons, i.e. instead
of foo-1a-_live it would be foo-1a-live.
but how would their vdb or binpkg names be unique?
vdb for example:
app-misc/foo-1a_live for app-misc/foo
PN=foo, PV=1a_live = app-misc/foo-1a_live
app-misc/foo-1a_live for app-misc/foo-1a
PN=foo-1a, PV=live = app-misc/foo-1a-live
am I missing something?
Everything is easy, if you keep the following rule in mind:
With our current versioning scheme the rule is very simple: ${P} is
split into ${PN} and ${PV} at the last hyphen. This can be done in
a straight forward way by regexp matching, and I would really hate
to lose this nice property.
I don't understand why this property is important. Can you please
explain?
See above, it automatically avoids any ambiguities in splitting P into
PN and PV. And look at function pkgsplit in Portage: It can just
treat PV as an opaque string.
What would be the advantage to use a hyphen instead of an underscore?
Mainly the thing you observed yourself - foo_live is a bit
inconsistent with current versions.
Ulrich is proposing foo-live if live is the entire version, foo_live is not a
legal `package name and version'. (It could be a package name though.)
The case you mention can be avoided with another restriction in PMS.
Buut we might as well go all the way and change the version separator
to -- or something, which would be the most flexible.
That would also be a good solution though we don't seem to need it yet. It would
also entail compatibility issues.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoeqg0ACgkQp/VmCx0OL2zn2gCfZl0knh8Er2x1B8PrbdwWSYHU
b/MAnj3pYO2qzXhUx+z1w9Vnrdf2/uJo
=EzB3
-END PGP SIGNATURE-
Re: [gentoo-dev] The fallacies of GLEP55
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Fri, 15 May 2009 14:43:29 -0500
William Hubbs willi...@gentoo.org wrote:
On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
It can't, because it doesn't know the EAPI until it's sourced the
thing using bash. Using things like += in global scope will break
older bash versions to the point that they can't reliably extract
EAPI.
I just figured out a line in bash that will get an EAPI without
sourcing the ebuild:
eval `grep '^EAPI=' ebuildfile | head -n 1`
will set EAPI in the current scope to EAPI in the ebuild, without
sourcing it, unless the issue with something like this would be its
use of grep and head, but these are both in the system set, so unless
you don't want to depend on the system set, I don't know what the
objection would be.
The objection is that your code doesn't work. It's entirely legal to
do, say:
export EAPI=1
or:
inherit versionator
if version_is_at_least 2 ; then
EAPI=2
else
EAPI=0
fi
Besides, if we were able to do what your code does, we'd just code it
natively, not use external programs.
How is it possible to do these things encoded in the filename?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoOhxcACgkQp/VmCx0OL2wXqACfSkZVqv2hcskm7Yw7vyizeh5r
UnIAn1npT5j6CcN23WE3yG6p8WDZiF9D
=bI9e
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thilo Bangert wrote:
Richard Freeman ri...@gentoo.org said:
AllenJB wrote:
All that's going to happen is Gentoo will have many many buggy and
out of date packages in the MAIN TREE. Exactly where they shouldn't
be. You claim quality won't be sacrificed, but I simply can't see
this without any attempt to solve the manpower issues first.
Isn't the purpose of this project already somewhat covered by
Sunrise?
I have to agree with your points. We need to have quality standards
for packages. Currently we have a couple of tiers:
1. Main tree - every ebuild has an official maintainer and gets prompt
security updates/etc. New features might get a little more stale, but
you aren't going to be running at risk if you only use the main tree
and routinely emerge -u world. If a package falls behind on security
it gets masked and booted.
2. Overlays - you're on your own and at the general mercy of the
overlay maintainer.
3. Sunrise (just a special case of an overlay) - somewhere in-between.
Again, you have to opt-in.
AFAIK, we have never explicitly made this distinction clear. if we had, we
would have to remove stuff from portage which doesnt live up to the
standards.
We should try to work with the maintainers of those packages to improve things.
it is also not true from a more real world perspective: there are many
packages in portage that have a standard which is much lower than what is
in some overlays. and there are many packages in overlays which live up to
a quality standard way above portage's average.
This is probably true, but without knowing which is which we can't do much about
it. Even if we did know, that still doesn't mean packages could be moved from
overlays to main tree, as they would instantly become unmaintained.
if you want to exaggerate a bit, we have roughly 500 ebuilds in portage
which are maintainer-needed and have only a few users and thats why you
want to keep popular packages out of the tree?
If packages are popular enough someone will care enough to add and maintain
them.
its weird, how this whole thing started with wanting to accomodate our
users better and then other people come around and argue against it in
order to protect our users...
user who want protection run stable arch!
Perhaps there are pros and cons to actually doing this, like with most things.
It seems like some are arguing that the value of having more ebuilds outweighs
the bad of having more less-maintained ebuilds. Others may feel differently.
given the current state of the tree, its hypocritical to be against this
proposal, IMHO.
See above.
however, one could try to implement the above quality standards, possibly
by splitting up the tree.
Overlays are effectively a splitting of the tree, so we are already there.
this issue, as well as some others very similar to this one, have come up
many times before. I suggest we do something about it... (splitting the
tree or moving more stuff wholesale into portage and have a better rating
system... whatever)
Fedora is a much more current distribution than Gentoo - and has been for
a couple of years...
Please elaborate what exactly you think Fedora does better than we do. I have no
first-hand experience with Fedora, but from what I read I had the impression
that sometimes they go with new stuff before it is ready, like KDE4 and
pulseaudio.
I like about the current situation that we also have all those things available
AFAICS, but have very broad choices in how much we want to bleed.
IMO this is a different issue than having supposedly popular ebuilds not in main
tree.
I think there is a steady inflow of fresh developers from sunrise (and other
places). Does anyone have a chart? I'd also like to know from prospective
developers if they have trouble getting recruited, through sunrise or other
projects.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoNPjsACgkQp/VmCx0OL2x/lgCgrvL/3f0XqLJPEe6+BOCl/0R8
j3kAn1jLAW1flDAZt7wu9IuSMO3jtmZe
=szxf
-END PGP SIGNATURE-
Re: [gentoo-dev] Files owned by multiple slots
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sven Schwyn wrote:
Hi
This question popped up while discussing how to deal with Ruby gems on
Gentoo in a way that gives the user the freedom to choose Portage,
RubyGems or both for gem management.
http://bugs.gentoo.org/show_bug.cgi?id=268857
Here's what it boils down to:
If a Ruby gem ebuild is slotted, the executables it writes to /usr/bin
are currently postfixed with a version as Portage does not yet allow a
file to be owned by more than one slot. This is not a good solution, see
below for details.
Is it feasable to extend Portage to allow a file to be owned by several
slots and remove it only once the last slot is uninstalled (aka: once
the ebuild is completely uninstalled)?
Do we have any guarantees that the file you want to share will be compatible
with all gems that will possibly use it?
Here's the background:
RubyGems (the gem manager) deals with dependencies and concurrent gem
versions. It's not unusual to have the same gem installed in various
versions as other installed gems may require different versions.
If a Ruby gem contains and installs executables, then those are mere
wrappers to a Ruby runner object. As per default, the wrapper will run
the most up-to-date code. You can, however, tell the wrapper to run a
specific code version (e.g. rake _0.7.3_ --version).
On Gentoo, slots are used for this and therefore ebuilds for software
written in Ruby should (and do) depend on slotted ebuilds of the gems
they need.
Unfortunately, Portage doesn't allow slots to share files at this point,
therefore every slot has to install it's own versioned copy of gem
supplied executables.
You could split the executable off into its own package to avoid this
duplication. On the other hand, these file collisions between different versions
of the same gem seem to be an upstream problem; how exactly does RubyGems handle
this?
This not only fills /usr/bin with unnecessary
identical wrappers, but has another consequence:
Hmm, so you aren't merely claiming compatibility (like I asked about above) but
identicalness (is that even a word?). Is that really realistic?
Every mayjor version of Ruby (currently 1.8, 1.9 and enterprise edition)
has it's own set of installed gems and therefore Ruby itself is slotted
and eselect-ruby does the switching. I've written a simple patch for
eselect-ruby which assures that all gem supplied executables are
switched correctly, no matter whether they were installed through
Portage or RubyGems. It will, however, only work, if Portage allows gem
executables to be shared between all slots of the gem.
And here's why plan B doesn't quite cut it:
You didn't mention any plan B.
Why not write a gem2ebuild tool and automatically add *all* gems from
Rubyforge and Github as ebuilds. This is most likely a bad idea, because:
- External dependencies (e.g. with C libs) must be maintained manually.
- All outdated ebuilds must be kept due to gem dependencies to outdated
versions.
I'm sure we can check this before gems are added and we can periodically
automatically remove old gems. Everything could also be kept in an overlay so as
not to pollute the tree.
- Some useful gems are neither on Rubyforge nor Github and wouldn't be
covered.
If we have an automatic converter, then it should be easy to direct it to
convert those gems that we are interested in regardless of where such gems are
found.
There are currently about 7500 gems on Rubyforge and Github as of now.
Multiplied by the number of versions, you get a shitload of ebuilds to
host and sync.
RubyGems does a very good job dealing with versions and dependencies, so
it's IMHO a good idea not to delegate this to Portage unless absolutely
necessary. We better find a way for Portage and RubyGems to work hand in
hand.
This problem isn't unique to Ruby. Common Lisp, chicken, plt-scheme, Scheme,
Haskell and Perl (and many more probably) each have repositories of
libraries/applications plus some sort of package manager to install and keep
track of them. Is there a general solution? Is it possible to redirect calls to
these external package managers to the main package manager through some
interface (a bit like pkgkit)? What about eix support?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoIANYACgkQp/VmCx0OL2y6KwCgpcweYSuXMn1+bl8NBuJ6+3Qu
2xgAoKyKix1AcUMkkc2SLjzkDSh4pn1e
=Aq03
-END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: a bunch of X stuff no one should be using since 1994
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
� wrote:
# R�mi Cardona r...@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?
Thanks,
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoFY2oACgkQp/VmCx0OL2wmtgCfRMu4oxJSgey5owGiN/09Qx/e
dOcAn0e/dWvj9cT7FPUFEk/zh9EzUpMB
=cpX0
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
Plus, as I said, with a pre-arrangement, it's possible to do email
reasonably close to real-time as well, close enough they'd not have time
to look it up unless they had /some/ idea what was going on.
What good is simulating real-time chat with email?
If you prefer not to use IRC most of the time, fine.
Refusing to use IRC when it is clearly the superior tool, that's just dumb. So
then I guess you are arguing email is better for this, right?
What's so bad about the real-time nature of IRC anyways? That's just like having
a genuine face-to-face conversation. Are those bad too? To be avoided at all
costs? What problem are we solving here again?
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoCoOcACgkQp/VmCx0OL2wrLQCfb+uED29OMrz5VBmGbnuJfQPB
UuIAnjYRJHXbXKFXtRLhRT9a7wd0bw2h
=dNZI
-END PGP SIGNATURE-
[gentoo-dev] pet feature: mtime preservation (was [gentoo-dev-announce] Council Summary from meeting on April 09, 2009)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Anderson wrote:
Hi,
Here is the summary from Thursday's council meeting. The full log along
with the summary will appear shortly at
http://www.gentoo.org/proj/en/council.
Regards,
Thomas
and from #gentoo-council:
[do apr 9 2009] [22:41:47] dberkholz those of you with a pet feature, feel
free to respond to the summary on -dev if you have some compelling reason why
it's super easy to get in and can't be pushed back. keep in mind there's no
reason we need to take forever for EAPI 4, either
pet feature: mtime preservation
supereasy: yes, this is already the current behavior of both portage and pkgcore
so nothing needs to be implemented here.
can't be pushed back: the mtime of to-be-installed files is currently
unspecified. Since the behavior of portage isn't changing nothing will break due
to this non-change, but it will make hacks that work around the package manager
(officially) obsolete and make it simpler to keep track of compiled code for
dynamic languages.
There is an extended proposal for changing only those mtimes that are too old or
too new (in the future). If that is indeed desirable this could be changed in
EAPI4, but it seems easy if not better/cleaner if mtime mangling is done on a
per-ebuild basis for those few that need it.
If the package manager preserves mtimes they can still easily be changed in
individual ebuilds.
However if the package manager does not preserve mtimes and they need to be
recovered, then the mtimes need to be saved at a point where mtimes have not yet
been mangled and then restored after the package manager is done with mtime
mangling. This is possible but the exact time of mangling would then need to be
specified. This is clearly a hack.
I know I personally asked for mtime preservation on 7-5-2008 on this list[1] and
the issue has surely existed even longer. Let's get rid of this problem already.
Thanks,
Marijn
[1]:http://thread.gmane.org/gmane.linux.gentoo.devel/55953
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknlJzEACgkQp/VmCx0OL2yokQCfRAjuMnssCQ1sVajiX+VVdHBC
FBUAnjUFcmBXQMvpqiFxrSNB4w69a3Fm
=RcL4
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: EAPI 3 PMS Draft
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Rowe wrote:
* Christian Faulhammer (fa...@gentoo.org) wrote:
Some years ago as a Gentoo beginner I read the documentation of
FEATURES and enabled test, because it sounded useful. After one week
I disabled it again as merges took too long and some failures occured.
Read: As a normal user I don't want src_test for every single package
that is installed on my system for whatever reason. FEATURES=test is
perfect for people who help maintain the distribution or want to test a
specific subset of packages they heavily rely on.
I'm just a user and I run with FEATURES=test, and have done since at
least March 2005[1]. I've definitely toyed with disabling it myself,
but only because developers aren't using it, which means I catch bugs[2]
that would have never existed if the developer had `test' enabled.
Just because we find failing tests doesn't mean we have time (or inclination) to
investigate and fix them.
So imposing that penalty on everyone even the unexperienced will
likely confuse some people. Go to the forums or the support mailing
list to see what I mean.
Package tests will have been run a -- possibly large -- number of
times when users see them if they are rolled in to the EAPI bump. This
isn't like the current situation of enabling tests and hoping somebody
has run them during testing.
You conclusion that developers do not run tests is based on nothing. Using
RESTRICT=test is not a fix and just hides the problem, so it is not unthinkable
that packages with failing tests get to stable.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkngd5UACgkQp/VmCx0OL2yxyQCfeV2wrXCd3M2nrhGYRnQtBh2u
O24AoJzvNKtnov0yjpQdtHao7fXcFPGx
=Unhp
-END PGP SIGNATURE-
[gentoo-dev] Preserving mtimes for EAPI3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On behalf of the Lisp project (which includes the Emacs subproject) I'd like to
propose that preservation of mtimes be included as a requirement of EAPI3.
An EAPI bump may not be really necessary for this - after all we're just
specifying previously unspecified behavior - but it will help Paludis.
Portage already supports this, and according to my information pkgcore too, but
unfortunately not paludis. More details on the bug mentioned below.
Background:
Dynamic languages such as Common Lisp and Elisp, but also python (and ruby?)
compile source files to some form which loads and executes faster; in Lisp-speak
these are called fasl's (for FASt Load), for python these are the pyc files.
Need for recompilation is determined by comparing the mtimes of the original
source and the fasl. Both source and fasl are usually installed. If the mtimes
are modified such that the fasl is not newer than the original source anymore
then implementations will attempt to recompile these sources and will try to
write the output alongside the sources. This will cause a sandbox violation if
it happens in an ebuild or fail due to permissions when done as a user.
See also:
https://bugs.gentoo.org/264130 PMS should require that file mtimes are
preserved on merge; Gentoo Hosted Projects, PMS/EAPI; NEW;
u...@g.o:pms-b...@g.o
Marijn
- --
Gods do not want you to think, lest they lose existence.
Religions do not want you to think, lest they lose power.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknQ1+wACgkQp/VmCx0OL2yE0QCeJZZJOCFuWY7+6FfnQUCnfFRK
YX0Anj+pGrV+kbkrW6UK2w6FNGF0vBzp
=sjQR
-END PGP SIGNATURE-
Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tomáš Chvátal wrote:
Dne neděle 22 Březen 2009 17:50:26 Alin Năstac napsal(a):
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
Cheers,
Alin
Hi,
I was working on patches glep [1] (nothing final and it is highly in progress
but as i can see more pple is interested so i am throwing it to the space so
there might be somebody else whom might help me with it).
I think the discussion made it clear that people want to do things differently
and there is no reason that we should not allow different teams to follow
different conventions.
Furthermore a lot of our patches are in the sed format and I happen to think
that's a good thing.
Unless your GLEP is prepared to handle these issues it seems completely useless
to me.
Marijn
- --
Gods do not want you to think, lest they lose existence.
Religions do not want you to think, lest they lose power.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknIw14ACgkQp/VmCx0OL2xTIwCfVJG03ysDRv2iCOWY/F0RFCTA
jBcAn06ku3nBjK/LKdMlg8Jc+48Dh+RU
=VqBN
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Last rites: dev-lang/pugs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Torsten Veller wrote:
* Marijn Schouten (hkBst) hk...@gentoo.org:
Torsten Veller wrote:
# Masked for removal (#151986,#171649,#239222) (23 Mar 2009)
# 151986 - dev-lang/pugs-6.2.13 installs stuff in /lib instead of /usr/lib
# 171649 - dev-lang/pugs-6.2.13 fails to build with ghc-6.6
# 239222 - Remove dependencies in pugs on dev-lang/ghc-bin
dev-lang/pugs
I don't see how any of the above is fatal. Can you explain a bit better why
you
want to remove this? Isn't pugs still the most complete implementation of
Perl6?
It fails to build. No release in the last years.
Do you want to maintain it?
No. I talked to some people in #perl6 and apparently pugs is abandoned.
Marijn
- --
Gods do not want you to think, lest they lose existence.
Religions do not want you to think, lest they lose power.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknIzxcACgkQp/VmCx0OL2zdmwCgusNN7dTGFp4ds8ibkHPByIfQ
85kAn3r7l1LTkyLMXj0AHVBr76yaIWy4
=vwtZ
-END PGP SIGNATURE-
Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sebastian Pipping wrote:
Marijn Schouten (hkBst) wrote:
Furthermore a lot of our patches are in the sed format and I happen to think
that's a good thing.
My current view is that sed patches should only be used where
static patches don't work, ignoring laziness (including mine)
for the moment.
That's enough reason right there. But also, static patches are very often not
what I want and they would often break unnecessarily where a sed would not have.
Lastly I prefer to have the source changes right there in the ebuild when they
are not too elaborate and patches don't allow that.
Why do you feel sed patches are a good thing? Who but the ebuild
writer would prefer that to patches? For instance isn't it much
easier to share patches among distros than parts of very distro-
specific scripts, ebuilds in our case?
sed's can very easily be turned into patches when needed, so we don't lose
anything. Patches are context dependent and usually this is not why I need.
Usually I need to replace certain strings irrespective of how many or where they
are or their context and sed is the tool that does exactly this and is more
robust to changes in the source that don't matter.
Marijn
- --
Gods do not want you to think, lest they lose existence.
Religions do not want you to think, lest they lose power.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknI1u4ACgkQp/VmCx0OL2yTzQCgtn3oWQihHbhWvr1/4a8MXncj
rgYAnih70WNPw5ErPKf9k7hn22DrUGbS
=RNV0
-END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: dev-lang/pugs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Torsten Veller wrote:
# Masked for removal (#151986,#171649,#239222) (23 Mar 2009)
# 151986 - dev-lang/pugs-6.2.13 installs stuff in /lib instead of /usr/lib
# 171649 - dev-lang/pugs-6.2.13 fails to build with ghc-6.6
# 239222 - Remove dependencies in pugs on dev-lang/ghc-bin
dev-lang/pugs
I don't see how any of the above is fatal. Can you explain a bit better why you
want to remove this? Isn't pugs still the most complete implementation of Perl6?
Marijn
- --
Gods do not want you to think, lest they lose existence.
Religions do not want you to think, lest they lose power.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknHduwACgkQp/VmCx0OL2wv/QCgjuQJbNsFCwfhoXJwRWfttl2u
RtIAnAvx8w8fU9pg+xmBO+FUl3iH4+Pf
=TOMU
-END PGP SIGNATURE-
Re: [gentoo-dev] Maintainence of /usr/portage/skel.* and some updates for skel.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Sachau wrote:
Petteri Räty schrieb:
Thomas Sachau wrote:
I would like to know, if there is some policy about editing skel.* files or
who owns/maintains them.
Additionally, i suggest some changes to skel.ebuild:
Posts diffs to gentoo-dev and if there are no objections -- commit.
Regards,
Petteri
ok, here my proposed diff for skel.ebuild
# Run-time dependencies. Must be defined to whatever this depends on to run.
# The below is valid if the same run-time depends are required to compile.
- -RDEPEND=${DEPEND}
+# You only need to define this, if you have run-time dependencies or dont have
+# run-time dependencies, but compile time dependencies set in DEPEND (in this
+# case, it should be RDEPEND=).
+#RDEPEND=${DEPEND}
Why not make it simple and require RDEPEND to be defined?
Marijn
- --
Gods do not want you to think, lest they lose existence.
Religions do not want you to think, lest they lose power.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm+yQkACgkQp/VmCx0OL2yXGwCgkaV9tQMuJg+A3VLjwHnCEQV2
KOcAoJ5yn+ZEEu8mZqXf5LwWWLEMb5yE
=Hpvn
-END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo is and will remain Free Software
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luke-Jr wrote:
I have been reporting bugs over the past few months regarding licensing
issues, and inappropriate dependencies on non-Free software. Someone
recommended I begin a thread on -dev, however, seeing as it may be of greater
concern in regard to Gentoo's Social Contract.
How have these bugs been handled?
Reading over the Social Contract, there is a bit of ambiguity about what is
meant by Gentoo not depending on non-compliant software: does this refer to
only the base system? A specific desktop or server configuration, or
configurations? To the maximum extent possible where upstream makes it
possible?
The most recent issues I have encountered are quite troubling with regard to
wanting a Free desktop OS: Gentoo now patches KDE to depend on a specific non-
Free font, and Poppler has a hard dependency on the non-Free poppler-data
(which is only needed for displaying non-embedded non-Latin fonts). Short of
workarounds via package.provided, these two dependencies make a simple KDE
desktop impossible on Gentoo without non-Free software. The xorg-x11 7.4
metapackage also added a number of dependencies on non-Free fonts. There have
been a number of other similar issues I've encountered over the past year.
I would not like it if we are patching software to depend on non-free fonts.
To help mitigate this problem, I propose completion of GLEP 23's
implementation; we already have a working ACCEPT_LICENSE, but the minimum
groups (in particular, @OSI-APPROVED) are as of yet still not defined. By
enabling more users to filter by approved licenses, I feel these issues will
get more attention.
I don't know how this has been implemented. I believe they are just lists, but I
am not sure where. We should probably have some file such that for each license
we can specify whether or not it is a member of some group. That will make it
clear which license has been considered for what:
GPL-2:OSI,FSF
MS-EULA:!OSI,!FSF
license-X:
license-Y:FSF
licenze-Z:OSI
With lists it isn't clear whether a license does not belong to a group or hasn't
been considered. Unless we introduce the complement groups explicitly. For each
group OSI we also have the group !OSI. That way the infos would be there, even
though they would still need to be extracted by some tool.
Comments? :)
Done! ;)
Luke
P.S. I'm subscribed to -nomail, so if your reply is directed specifically to
me or you want to ensure I read it, feel free to CC.
Live Free or Die,
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm497EACgkQp/VmCx0OL2yCzQCfUK4d7HJxN8vPXQxt2zxAAt3D
KfAAni2yfu0V3+nv4iZsSWN7bmb/Wsqj
=ZcqH
-END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo is and will remain Free Software
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
� wrote:
Luke-Jr a �crit :
The xorg-x11 7.4 metapackage also added a number of dependencies on
non-Free fonts. There have been a number of other similar issues I've
encountered over the past year.
I'll reply to that. The xorg-x11 meta package contains everything
upstreams considers important, including fonts.
With the latest patches in =x11-base/xorg-server-1.5.3-r3, X can work
_without_ any fonts at all. Old apps and toolkits (xterm, motif, tk,
Xaw, ...) will look ugly as hell but they should work.
In a nutshell, don't use the xorg-x11 meta.
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
?
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm5NnwACgkQp/VmCx0OL2xL4QCeNib5vE60KfZq6Ot2/3dxy/74
vxcAoK2uHibxNqFSl+vLYs4OKECvEu44
=zpZg
-END PGP SIGNATURE-
Re: [gentoo-dev] Developer Retirements
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Olexa wrote:
On Mon, Mar 9, 2009 at 1:44 PM, Doug Goldstein car...@gentoo.org wrote:
I'm wondering what exactly is the harm in letting developers idle for a
while? While they might not be actively committing they are still
knowledgeable people that are just as capable as everyone else to push in a
fix for small packages. There's lots of bugs in bugzilla with items that
just need someone active to commit them. There's even a lot of these items
are filed by retired Gentoo developers who could have easily pushed this fix
for all users. The fact that someone only does one commit a year does not
marginalize their contribution. While it may be small it is improving the
overall quality of the distro. I'm constantly seeing developers getting
upset over getting pushed out.
The problem comes when $idle_dev has XX bugs assigned to them and they
don't get resolved and no one else knows that there are issues.
As opposed to those same bugs being assigned to maintainer-needed and getting
lots of attention?
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm1oXIACgkQp/VmCx0OL2wymACfWGNpz9UgudSfO0VkbHiXROL5
IgUAnRtIgbhQTj2pSyCC5E8VpPpQQwtR
=z5EV
-END PGP SIGNATURE-
Re: [gentoo-portage-dev] What is a meta package?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amit Dor-Shifer wrote:
Hi.
i read in
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=3
QUOTE
Never depend on a meta-package.
So don't depend on gnome-base/gnome, always depend on the specific
libraries like libgnome.
UNQUOTE
Where can I find a definition of this term?
Is there some equery/qsearch invocation that returns a list of such
packages (installed or available)?
Is there some ebuild setting that marks a package as being a meta
package? Does gnome-base/gnome carry this setting?
Thanks,
Amit
Hi Amit,
a meta-package is a package that depends on a group of other packages but
doesn't contain any source of itself. Basically it's a shorthand for the entire
group for installing from command line.
Portage is getting explicit support for groups so I think we then no longer need
metapackages.
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmzy5IACgkQp/VmCx0OL2y1cwCeKLo/u6u6cNhimb6zFXPgW4FO
zJwAn0UvF6OzakSuJmYH4P+Cxb75FOF4
=R05+
-END PGP SIGNATURE-
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Caleb Cushing wrote:
On Fri, Mar 6, 2009 at 3:44 PM, Marijn Schouten (hkBst)
hk...@gentoo.org wrote:
Don't you get that?
the janitor gets hit by a car and no ones around to clean the
bathrooms. You can't fire him because of contract, his job has to be
waiting for him when he gets back in 2 months. what do you do?
We make do. That means that someone else might drop (some of) their tasks to
step in. In the end, less total work will get done.
the answer is you get someone else to do it.
Aha, so this is what the community service project is gonna do after they chase
away their volunteers! They hire professionals instead. Good thing they are
never short on cash. Fortunately we have a never-ending supply of Gentoo-credits
and they are just as good as real money. We can even give all current developers
a 10% raise while we're spending money anyway.
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmy9IsACgkQp/VmCx0OL2zgswCdGSOUfZ4SyemZrlPW/97IBIvf
wDoAn1E1OYf3fCJWiiKqoZdm8uQYvRes
=ysPe
-END PGP SIGNATURE-
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Caleb Cushing wrote:
Your demands because of your feelings of entitlement are what are costing you
respect.
why do people keep telling me what I feel? anyone else ever notice
feelings don't convey well over text.
Well, you spoke of owing users, and the right to open a bug and watch for
progress reports combined with this:
right now you are the kind of person that thinks being a volunteer is a
privilege and not a responsibility. You think that because you don't get paid
that you don't have to do it. I assure you that if you look at most non foss
volunteer jobs you either have to do your job or quit. it is the same in open
source. perhaps I'm judging you wrongly. --
https://bugs.gentoo.org/show_bug.cgi?id=260582#c6
It seems like you want to tell us how to do our jobs. It seems like you think
you have the right to tell us what to do. Now, I'm happy to be wrong about those
views, but that's what it looks like to me.
Yes, it's extremely frowned upon to step on another developers toes; Gentoo
is
not a one-man show. Would you like ME to stomp all over your tree? Didn't
think so.
that depends on what you mean by 'stomp' if by stomp you mean fix
problems for users, stomp away. if by stomp you mean break stuff, then
no. I don't care if you change something I changed if it's better,
it's better.
The point is that you don't know whether someone else has a good judgement of
better. People that have been taking care of certain parts of the tree may just
know something you don't. This is why we encourage people to talk to maintainers
when they touch their packages but also encourage maintainers not to feel too
possessive.
Just so we're clear. I really hope you change your attitude and take Peter
Alfredsen (loki_val) up on his generous offer.
and my attitude is? what is it that you think I think?
I've answered that above.
I may take him up. but I'm also considering the possible conflict of
interest, as well as the additional time requirement. I hope you
understand. even if I do I have a commitment to what I've already
started.
On your blog[1] you imply that if you decide to not, that you wouldn't be able
to to talk to people to understand something. I just want to stress that this
is not so. Many of us are available on #gentoo-dev-help and this mailing list
for technical questions.
Marijn
[1]:http://xenoterracide.blogspot.com/2009/03/to-gentoo-dev-or-not-to-gentoo-dev.html
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmxEyEACgkQp/VmCx0OL2xG7QCgwCML2vEUSIO6LBeXSIYcApRT
J8sAnR7AgV4EeyiZnNLYQH0SsoKia0+s
=YNn/
-END PGP SIGNATURE-
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Caleb Cushing wrote:
On Fri, Mar 6, 2009 at 7:12 AM, Marijn Schouten (hkBst)
hk...@gentoo.org wrote:
right now you are the kind of person that thinks being a volunteer is a
privilege and not a responsibility. You think that because you don't get paid
that you don't have to do it. I assure you that if you look at most non foss
volunteer jobs you either have to do your job or quit. it is the same in open
source. perhaps I'm judging you wrongly. --
https://bugs.gentoo.org/show_bug.cgi?id=260582#c6
It seems like you want to tell us how to do our jobs. It seems like you think
you have the right to tell us what to do. Now, I'm happy to be wrong about
those
views, but that's what it looks like to me.
and what's your perspective? who gets to tell you what to do? it's not
that I get to. but what I said I do believe, is common among foss
developers. they don't take volunteering as a responsibility. They
don't think of it as their other job. I think they should. It's also a
pet peeve of mine so I kinda flew off the handle.
Why do you think they should?
question is do you understand what I've written? given your statement
below on my blogpost on what you think I've implied (I'll respond
directly) you might be wrong about this to.
this is also the reason that I have to carefully consider being a
gentoo dev. if I do, I have a responsibility to the users of my
packages.
The point is that you don't know whether someone else has a good judgement of
better. People that have been taking care of certain parts of the tree may
just
know something you don't. This is why we encourage people to talk to
maintainers
when they touch their packages but also encourage maintainers not to feel too
possessive.
sometimes it's just a difference of opinion. it depends on your
opinion of what's right and what's better. but sometimes even the
smartest person is wrong. I do not claim to be always right, and I'm
most certainly not.
but I don't think I'm wrong when I say it's wrong not to version bump
a package when all it takes is the copy of a previous ebuild. I don't
think I'm wrong when a bug is put on hold due to other bugs, (for 6+
months) but the maintainer never answers what other bugs.
No, you are not wrong, but it does not follow that the people who are already
investing time towards similar issues are slackers. It's a manpower issue. Even
trivial bumps have to be tested and bugzilla is there such that it can help each
developer work more efficiently.
On your blog[1] you imply that if you decide to not, that you wouldn't be
able
to to talk to people to understand something. I just want to stress that
this
is not so. Many of us are available on #gentoo-dev-help and this mailing list
for technical questions.
no that's not what I'm saying at all. I'm saying that it's easier to
get help if you got 1 or more specific mentor's to help you. asking
for help on irc, forums, mailing lists, is often a crap shoot at best.
given I get help more often than not. but sometimes you still don't
get any (for various reasons, don't know, don't care, not around,
don't understand). You read an implication that I didn't actually say.
I just wanted to make my point. It isn't really material whether you implied
what I said you did or not.
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmxOI8ACgkQp/VmCx0OL2yAkgCeJ0rZjcHUg1SMbIlCkmNCxuGs
PjAAnjt82/3Fd6zVz/ph6ijjRSrkwFRD
=M3JG
-END PGP SIGNATURE-
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Caleb Cushing wrote:
On Fri, Mar 6, 2009 at 9:51 AM, Marijn Schouten (hkBst)
hk...@gentoo.org wrote:
Why do you think they should?
you must have not read what I said on that bugtracker because I'm
thought I was pretty clear, that when you work as a volunteer it's
still a job. Don't believe me, go volunteer for community service or
something. Then try saying I don't have to I'm a volunteer. They might
just ask you to leave on that note.
You don't even know how much time these people spend on Gentoo. If you make them
leave it will stretch the other developers more and decrease the number of
manhours spent on Gentoo. In what universe is this useful? It certainly won't
get xorg-server bumped faster or ghc or some java packages. Don't you get that?
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmxi0QACgkQp/VmCx0OL2yqmgCeOiftQrMt2pHQAjf6BOrfWxF/
XhsAnjptd0eplNepVesOLhrf3X78Tf9r
=pPoD
-END PGP SIGNATURE-
Re: [gentoo-dev] Repository stacking and complementary overlays
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The problem of ebuilds in one overlay not seeing ebuilds in another overlay,
would also be solved by the package manager NOT failing to see/notice/use/allow
ebuilds from all installed overlays. Then there would be no need for a hierarchy
among overlays.
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmvp1IACgkQp/VmCx0OL2wFqACfSTjfdtY7abG/yc06gW4Q+YlT
Nd0AoIYIwFBD4BEKoA/PVg35K4Sia+C4
=IWat
-END PGP SIGNATURE-
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Caleb Cushing wrote: Bugzilla is a tool for developers to track progress, not for third-party distributions to track progress. You've forked the tree. That's fine. The license allows that. But it doesn't obligate us to adapt our tools to fit your purpose. I've done lots of version bump bugs over the years. my reasons for doing so may have changed. But the general process has not. Does it matter if I've forked? doesn't the package still need an update? I think a lot (most?) of us agree that bugs shouldn't be closed until fixes hit the main tree. But it indeed does not matter that you've forked, so you shouldn't even have brought it up on the bug report. Bugs aren't a good way to keep in touch with developers, that's what irc is for. Your behavior on bug 260582 was clearly unacceptable. You seem to think that we owe you something. Please re-examine your premises. Donnie already told you he was working on it. Our job is not to support your distribution. It is to make the best distro for ourselves. In the case of xorg-server, that means getting something into the tree that works. A masked ebuild will in this case be more bother than it's worth because the mask would have to encompass a bunch of other packages. Which leads me on to the next paragraph... this and all the cases given are examples, and perhaps my behavior was unacceptable. But I think the response to my bug was too. No gentoo doesn't owe me or regen2, a thing. It might, however, owe users something. I agree on committing ebuilds that work, that doesn't mean I don't have the right to open a bug and watch for progress reports. No, you don't have that right. It's just how it usually works and how it should work IMO, but that doesn't entitle you to it. In many cases that's true, but on average, the QA of the tree is much better than overlays. I couldn't say... I suppose I agree yes on most overlays, but a few are supposed to be more 'exceptional'. the biggest problem is the bugs that result between ebuilds in the tree and those of overlays. like one I filed on virtual/perl-Mime-Base64. or like how inkscape won't build against 5.10, except with patches already in bugzilla, but both cases seemed to be one of 'perl 5.10 isn't in the tree so we won't fix' I think they should put it in before 5.10 is in the tree. put that's just me. And they probably will, but as perl-5.10 isn't in the tree, there is no rush. Either way, it's the perl team's decision to go with the patch in bugzilla or some other option and when they do it, whether they make that decision consciously or are forced into it due to real life time-constraints. We Need Git. It would really ease the workflow of accepting user contributions if users could just set up their own overlay and sent me an email asking to merge their changesets. git's great. but I've actually found 'merging' changesets to be a bad idea from people. It can lead to some really sloppy commits, and merging is a less stringent review than cherry-picking patches. I've found that git's patches aren't really what we want in the case of bumping. For bug reports we usually ask for a patch against the last ebuild in the tree. Is there perhaps a way to make git do that automatically? You could have made thousands of commits already, fixing a substantial amount of the problems you've raised. thousands seem like a high number. I think I've been pushing an average one 1 patch per day since january to the tree (my tree). *laughing* I'm still the #1 contributor of git patches to funtoo. It's great that people are doing their own thing, but to get it into OUR tree it will need to be comitted to OUR tree by someone who has access to OUR tree. Patches are great, but commits are better. This isn't a quick fix. You'll have to work with people and that can sometimes be frustrating. I already have to 'work' with these people, the difference would be what? how much respect I get? in gentoo land having @gentoo.org seems to mean something... if you don't have that, you seem to auto-magically get less respect, than you would if you did have it. Your demands because of your feelings of entitlement are what are costing you respect. But you'll get to be part of the development process and you'll get to work with the things you care about. you mean I'll be part of 'a' development process and work on some of the things I care about. Obviously stepping on other developers toes seems to be a taboo. Yes, it's extremely frowned upon to step on another developers toes; Gentoo is not a one-man show. Would you like ME to stomp all over your tree? Didn't think so. Just so we're clear. I really hope you change your attitude and take Peter Alfredsen (loki_val) up on his generous offer. Marijn - -- Sarcasm puts the iron in irony, cynicism the steel. Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML http://www.gentoo.org
Re: [gentoo-dev] Repository stacking and complementary overlays
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marijn Schouten (hkBst) wrote:
The problem of ebuilds in one overlay not seeing ebuilds in another overlay,
would also be solved by the package manager NOT failing to
see/notice/use/allow
ebuilds from all installed overlays. Then there would be no need for a
hierarchy
among overlays.
Marijn
It was pointed out to me by zlin that this does not help with installing
`missing' `master' overlays. This is a good point. However it is possible that
even though an overlay is missing, ebuilds from another installed overlay or
main tree or a local overlay can satisfy dependencies. Further it is possible
that two overlays have a mutual dependency on eachother.
Maybe these possibilities are only theoretical.
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmvxGMACgkQp/VmCx0OL2x2+ACgh6ESoDDWhW1DCFnc2bz1VItw
xFIAoLuSQt1G42MR5umWrCoZwGD3thbG
=XnsF
-END PGP SIGNATURE-
Re: [gentoo-dev] QA Overlay Layout support.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Caleb Cushing wrote:
Are we to say that we shouldn't allow tools to have support for this. I
think that it is a nature progression that if we are to allow overlays to
extend the portage tree that we should allow overlays to extend other
overlays.
I probably shouldn't butt in...
first, no I don't want you to merge java-overlay and
java-experimental, that's a bad idea (well at least for me)
If you think neither should exist why do you have an opinion about this at all?
second. I generally think anything beyond a personal overlay is crap.
All these overlays like sunrise, java-overlay, and on and on...
basically official, overlays that have qa and are pretty stable. are
crap. they should be in the tree. an overlay for developers is fine,
you know. where you are working on stuff... stuff that someone who
wouldn't want to hack on it wouldn't want, because it's too broken.
What makes you think that overlays aren't for developers, aspiring developers
and interested users where they are working on stuff? It is desirable IMO that
all such people can easily be given full access to muck around and learn.
Further, overlays are good places to put ebuilds for software that is more
experimental than what's expected for ~arch. That includes live ebuilds. In the
end, overlays have a (far) lower level of guaranteed quality than the main tree,
for their ebuilds.
but one of the few good things about gentoo, in relation to other
distro's, 1 tree no repos, continues to fall further and further
apart.
The only thing I see is that the flow of ebuilds from overlays into the main
tree, when they and their software have reached sufficient quality, is sometimes
slow because of lack of developer manpower. For example, Common Lisp is almost
entirely maintained in the lisp overlay and I have the impression that the
Haskell team is having similar issues with many of their former developers no
longer working on Gentoo.
I might even argue that Funtoo is one big overlay. When your own ability to
contribute directly depends on an overlay, then why are you arguing against
other people's overlays?
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmtDPUACgkQp/VmCx0OL2z6lwCdHqP2shPhD91HU9Ld+f/Ma+K3
/6YAnR0cMKEXkqF3ZzA4hkahkPmTQYxR
=MVhI
-END PGP SIGNATURE-
Re: [gentoo-dev] Should that file be a License ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mounir Lamouri wrote:
Hi,
I was writing a trivial version bump for net-voip/gnugk-2.2.8 (bug
#258518) but upstream added a file named p2pnat_license.txt (see
http://dpaste.com/123376/) This file looks to authorize gnugk project
(and users) to use p2pnat technology. gnugk is already licensed under
GPL-2 and I was wondering if this new file should be considered as
another license and if it has to be in the LICENSE line ? In this case,
should the file be added like he is in the gnugk tarball or should it be
templatized like most licenses ?
Thanks,
Mounir
That paste is gone/expired.
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmixHYACgkQp/VmCx0OL2wURgCff8WSLE9PHXfO/HI+GdrE1W3J
0/kAoLpB4oFEwOx5Dk+ceo70vCueZgbk
=hKRC
-END PGP SIGNATURE-
Re: Fwd: [gentoo-portage-dev] search functionality in emerge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Emma Strubell wrote:
Hi!
If I can find an unpickler that can unpickle at a reasonable speed, my
search implementation would be significantly faster than the one currently
in use. I'd show you my code, but I have to admit I'm intimidated by Alec's
recent picking apart of Doug's code! For example, I don't even know how to
use docstrings... The code probably could be cleaned up a lot in general
since I was eventually just trying to get it to work before it was due.
Please don't be intimidated by it. Code review is one of the best methods to
improve your skills. We all sucked at programming at one time and perhaps we
still suck in anything but our favorite language. But if we are to improve
ourselves we need to spend a lot of time reading and coding and still we will
not always get it right. Furthermore other people learn from our code review,
such as you learnt about docstrings. Here[1] is a quick explanation of them.
Have fun,
Marijn
[1]:http://epydoc.sourceforge.net/docstrings.html
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmVd5AACgkQp/VmCx0OL2zIFQCgyJYZve1o6DnBBV/HgRV/gWMc
9NkAoLl0M4NX8l+kgWYY3B1dQQtU0/4k
=p/Pq
-END PGP SIGNATURE-
Re: [gentoo-dev] ebuild for x11-libs/qt-3.3.8-r3 is missing after portage update but required by the system configuration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dimitris Kavadas wrote:
Hello,
After updating portage via emerge --sync, I tried to perform world
update issuing the following command:
emerge -DupvN world
The command ended with the following message:
These are the packages that would be merged, in order:
Calculating dependencies... done!
emerge: there are no ebuilds to satisfy =x11-libs/qt-3.3.8-r3.
(dependency required by net-wireless/kdebluetooth-1.0_beta1-r2 [installed])
(dependency required by world [argument])
So, what seems to be the problem?
Is it my system configuration or is it a portage issue?
Both of those versions are no longer in the main tree. I suggest you sync again
and that should do it.
These kinds of questions aren't appropriate for gentoo-dev btw.
Good luck,
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmHfpgACgkQp/VmCx0OL2xfzQCfbnkX50IbVvU6eXTMUBPfCUpG
vwwAnRROnCVtdwZJ0SMfIO4AIFQmrVn8
=mjpq
-END PGP SIGNATURE-
Re: [gentoo-dev] sci-libs/scipy - dev-python/scipy ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Tue, 08 Jul 2008 18:34:46 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
I suppose you mean git. Since it tracks content and not files, moves
are trivial. Git actually finds your moves for you, after you've
moved content around; such as when doing a bump.
Ever tried git on an ebuild repository? Ebuilds are sufficiently
similar to each other that it quite often gets this horribly wrong. And
to make matters worse, there's no way of overriding it when it does.
Yes, we have a git overlay. I haven't noticed it getting it wrong yet.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkh0jcwACgkQp/VmCx0OL2xA6QCeIgh+/CyZXnGmW5+wNirR+Rao
NnEAnRvj9/dIE7WTfG3a/R3TmWFbFaVM
=xuwQ
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] sci-libs/scipy - dev-python/scipy ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe Peterson wrote:
Donnie Berkholz wrote:
I meant moves were largely pointless, although categories are to a
lesser extent. Tags would be a lot better, since nothing can be
categorized perfectly into a single place.
Yes, I can see the benefit of a tag paradigm. I, myself, find it more
trouble than benefit to have the extra directory level. I often do cd
/usr/portage/*/foo to get to the foo package, and it often gets a hit
in licenses or elsewhere that trips up this practice...
I don't think it's worth losing track of the CVS history just so we can
have something in a different place that ultimately is hardly useful to
anyone.
Ah yes, CVS would present a problem here. I suppose if/when the whole
tree is converted to svn, at that point moves would be more practical.
I suppose you mean git. Since it tracks content and not files, moves are
trivial. Git actually finds your moves for you, after you've moved content
around; such as when doing a bump.
Too bad, though, that this has become a barrier to the ability to change
a category easily and without losing the history.
-Joe
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhzlyYACgkQp/VmCx0OL2wQhACfa+iXqTwStNuVC26R9IylNq4r
QKMAnjisaTHaqe/Mbu6vMt/waElHgVRb
=97k+
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-scheme/drscheme: drscheme-4.0.2.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
On Sat, Jul 05, 2008 at 10:21:50AM +, Marijn Schouten (hkbst) wrote:
hkbst 08/07/05 10:21:50
Added:drscheme-4.0.2.ebuild
Log:
bump
(Portage version: 2.2_rc1/cvs/Linux 2.6.23-gentoo-r8 x86_64)
...
Revision ChangesPath
1.1 dev-scheme/drscheme/drscheme-4.0.2.ebuild
...
You missed updating ChangeLog.
added now, thanks,
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhwn/EACgkQp/VmCx0OL2zr+gCgx8VyQJI8xrg9sto+xQO3ijLh
zDUAmwfFvJyIvtWQoBj7v+iOjx0R9uiN
=RTuP
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: 0-day bump requests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeroen Roovers wrote:
Hi fellow developers,
it seems I've run into a minor issue with fellow bug wrangler carlo
(who has been putting a lot of work into that, for which we should all
be grateful).
Carsten has a cut-and-paste message that he posts in comments to
version bump bug reports that he finds have been filed on the day the
software version in question was released/announced. The gist of the
message is that none of or most ebuild developers do not like these
0-day requests and that users (and developers) should refrain from
filing them on the same day. Waiting a week would be OK, the message
seems to say.
Being an ebuild developer myself, I have to say that I do not hold that
stance and that I welcome early version bump requests. Therefore, I
refrain from adding such messages to the bugs that I wrangle and indeed
welcome any bump requests[1].
Finding myself in conflict with someone I have come to share a certain
workload with, notably someone who has a few more years of Gentoo
experience, I wonder what the majority of our ebuild developers
actually think. In that spirit, I hope the following questions are
neutral enough for everyone to *not* start a flamewar over this. :)
-
1) How do you feel when you receive an early version bump request?
Since current mores make sure there are not so many, I don't mind them.
2) If you had your way, would you discourage users from filing early
version bump requests?
To prevent every package from getting a 0-day bump request, I'd say give it a
day or two at least, unless you have some info other than that there is a new
version. For example that the current ebuild still works with the new version or
that it doesn't. It helps with gauging which bumps are trivial and which aren't.
If someone only wants to tell me some new version is out, I prefer they ping me
on irc.
-
I know, it's not a particularly good survey, but I hope the plenty and
diversity of your answers will shed more light on the matter. :)
Thank you and kind regards,
JeR
[1] In fact I regularly use the opportunity to check on the HOMEPAGE
whether the release was security related, and I assign directly to
security@ when that is the case (CC'ing the package's maintainers) and
perhaps pasting ChangeLog or advisory info in a comment.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkht4WkACgkQp/VmCx0OL2xJ6QCfbX/IvrzARx3AY2FzAHW4sD2P
TasAn2NTD0c+HE0ehaG3wd9bFdk+yzSh
=pj1H
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-scheme/drscheme: ChangeLog reversion.patch drscheme-4.0.1.ebuild drscheme-0.372-r1.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
On Sat, Jun 28, 2008 at 04:53:06PM +, Marijn Schouten (hkbst) wrote:
hkbst 08/06/28 16:53:06
Modified: ChangeLog
Added:reversion.patch drscheme-4.0.1.ebuild
drscheme-0.372-r1.ebuild
Log:
add new major version 4.0.1 and reversion latest ~
(Portage version: 2.2_rc1/cvs/Linux 2.6.23-gentoo-r8 x86_64)
...
1.1 dev-scheme/drscheme/reversion.patch
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-scheme/drscheme/reversion.patch?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-scheme/drscheme/reversion.patch?rev=1.1content-type=text/plain
Why was reversion.patch committed directly to dev-scheme/drscheme
instead of files/?
Because it is a patch I would've liked to apply to some ebuilds, not something
I'm applying to sources. The tools won't let me keep it uncommitted easily.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhsqIUACgkQp/VmCx0OL2xnGwCgwy1QiSruuSFBLHgw4aMHvMCD
gjwAn0oi7WAoTozSdprszabKgLmlugBJ
=Ywad
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] When the version scheme changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bo Ørsted Andresen wrote:
On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
PV=${PV/0./}
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 illegal per current PMS as PV is a
read-only variable. Right now I feel that the gain of having PV read-only
(catch a few bugs?) is much lower than the pain (extensive ebuild-dependend
changes when the version scheme changes). Please comment.
I don't really see how making PV not read-only is any easier than using
MY_PV.
Did you expect changing PV to magically change P, PVR and PF too?
If we can agree to have those values writable we could define a function that
will handle resetting all those too.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhnk6UACgkQp/VmCx0OL2xJPgCghPdttL5ruS/qkoZzsrKn8WL7
9OAAn3FGZrQMRsRGHlmAgdf1uiyjuJH9
=EmW/
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] When the version scheme changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
On Sun, 29 Jun 2008 15:52:37 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bo Ørsted Andresen wrote:
On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
PV=${PV/0./}
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
illegal per current PMS as PV is a read-only variable. Right now I
feel that the gain of having PV read-only (catch a few bugs?) is
much lower than the pain (extensive ebuild-dependend changes when
the version scheme changes). Please comment.
I don't really see how making PV not read-only is any easier than
using MY_PV. Did you expect changing PV to magically change P, PVR
and PF too?
If we can agree to have those values writable we could define a
function that will handle resetting all those too.
Not going to happen. These variables are used internally by portage in
various ways, and making their content inconsistent with the version in
the filename is likely to cause subtle bugs and/or weird behavior.
Besides, you've yet to explain the benefit of it, short of avoiding a
simple replace operation in an ebuild, and the given use case isn't all
that common anyway.
Why can't portage use its own variables and export these with an initial value
but not use them further?
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhntjYACgkQp/VmCx0OL2yxdgCght6buiC3nTWqQiaADBOVR2Xw
ezYAnA57T74GJ6izX2mk8XuOX/c8MyL4
=zW3N
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] When the version scheme changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
On Sun, 29 Jun 2008 18:20:06 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
On Sun, 29 Jun 2008 15:52:37 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bo Ørsted Andresen wrote:
On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
PV=${PV/0./}
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
illegal per current PMS as PV is a read-only variable. Right now
I feel that the gain of having PV read-only (catch a few bugs?)
is much lower than the pain (extensive ebuild-dependend changes
when the version scheme changes). Please comment.
I don't really see how making PV not read-only is any easier than
using MY_PV. Did you expect changing PV to magically change P, PVR
and PF too?
If we can agree to have those values writable we could define a
function that will handle resetting all those too.
Not going to happen. These variables are used internally by portage
in various ways, and making their content inconsistent with the
version in the filename is likely to cause subtle bugs and/or weird
behavior. Besides, you've yet to explain the benefit of it, short
of avoiding a simple replace operation in an ebuild, and the given
use case isn't all that common anyway.
Why can't portage use its own variables and export these with an
initial value but not use them further?
Because there is no need to create even more variables when there is
absolutely no benefit.
The benefit is being able to automatically reversion an ebuild. Reversioning may
not be necessary very often, but it's annoying when it is and there is no good
reason that it should. There is no benefit in keeping the version variables
read-only.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhn5XkACgkQp/VmCx0OL2xBgwCfbOtDaJ27kj1A2CbO95dkrkZb
x0MAn1usfmfaktYA83MoiukBvlXIuuUN
=BQs/
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: When the version scheme changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
Marijn Schouten (hkBst) [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Sun, 29 Jun 2008
18:20:06 +0200:
Why can't portage use its own variables and export these with an initial
value but not use them further?
One way of looking at is that these /are/ the PM's own variables, simply
exposed read-only to make life simpler. There's nothing you can't do by
setting your own variables initially equal to the read-only vars and
modifying them as you wish, that you could do if the PM exported them
writable but ignored any rewritten values itself. Either a read-only
variable works fine, or a rewritable value then ignored by the PM
wouldn't work either.
That would work but it would require writing ebuilds in a funny way and would
unexpectedly break when someone DID improperly use the non-writable variables
for anything else than that initial copying. It's really not a solution, because
since there are no guarantees you still have to check all the code and can't do
automatic reversioning. Also doing this would basically be the same as manually
reversioning the entire tree.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhoJzIACgkQp/VmCx0OL2x4wgCfUoPNEtFWvV/PhIlBk05Cf2FR
rwoAoMlOTrgtoujSqJB5Az1wDSCVXFMB
=I1/q
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] When the version scheme changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi list,
recently drscheme changed versioning scheme in such a way that the newer
versions(4.0.1) rank lower than the old versions(372). The only way to affect
ordering is to change the PV part of the filename, preferably the old one, so I
created a 0.372 version that was to be a copy of the old 372 version. To make
this work I also added a
PV=${PV/0./}
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 illegal per current PMS as PV is a read-only
variable. Right now I feel that the gain of having PV read-only (catch a few
bugs?) is much lower than the pain (extensive ebuild-dependend changes when the
version scheme changes). Please comment.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhmUrEACgkQp/VmCx0OL2wKcACePBrxQ9N6sQVenMLewf3fVR95
1fQAoIBIookA65il9e70Hqs3SgWaLaoT
=V0bU
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Panagiotis Christopoulos wrote:
| On 02:00 Thu 05 Jun , Łukasz Damentko wrote:
| Hi guys,
|
| Nominations for the Gentoo Council 2008/2009 are open now and will be
| open for the next two weeks (until 23:59 UTC, 18/06/2008).
|
| I want to nominate:
|
| 1. Marijn Schouten (hkBst)
I accept.
| 2. Ulrich Müller (ulm)
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhZABIACgkQp/VmCx0OL2yo5gCghRY3IHt/NDbytCSxnp1wdrBk
ResAn2NvnoLoc17TZHZhlpvwWD2o8dei
=dMmo
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
| On 14:52 Thu 05 Jun , Samuli Suominen wrote:
| # Samuli Suominen [EMAIL PROTECTED] (05 Jun 2008)
| # Masked for removal in ~30 days by treecleaners.
| # Replaced by USE libffi in sys-devel/gcc. Bug 163724.
| dev-libs/libffi
| dev-lang/squeak
| x11-libs/gtk-server
|
| The latest version of g-wrap (1.9.11) requires the external libffi
| released a month or two ago, because it looks for the pkgconfig file
| installed by that and not gcc:
|
| - libffi is no longer distributed with g-wrap, as it is available
| as a stand-alone package now (instead of being burried in the
| GCC sources).
|
| Thoughts?
I think we should use this unbundled libffi in favor of the one that will
continue to be
bundled with gcc. A normal dep is nicer than a use dep on gcc with libffi for
one. I don't
see any reason why this ``new'' libffi should become unmaintained again soon.
Marijn
Relevant bug: http://bugs.gentoo.org/show_bug.cgi?id=163724
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhRU9cACgkQp/VmCx0OL2x56gCfbBE7GiypORQqcyKnjUaGgHc/
0WcAnA31US1030TisMMUN9D2OCJuJZb3
=1xLl
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: About herds and their non-existant use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tiziano � wrote:
| Marius Mauch wrote:
| - only have one location where members of a given team are listed,
| currently it's possible and quite likely that herds.xml and the mail
| alias files get out of sync
| Well, we need one location where the name of the team is mapped to the
| actual mail-alias. But I don't get what you're trying to say...
While we're changing things around, perhaps we can then also standardize the
mail alias to
[EMAIL PROTECTED]
What Marius is saying though is that there are two files that handle people and
their
herds. One XML for saying who is in a herd and one for each herd mail alias on
woodpecker
with a list of developer email prefixes.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkg2U5gACgkQp/VmCx0OL2wIVQCfVRE1/lP60+cspM6Zay5kyVwl
yUUAn1rBssAT2ndNpo55NLI3vzLrWdIN
=RMvL
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] dedicated USE-flag is inconsequent and confusing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Albert Zeyer wrote:
| Hi!
[snip]
| So, what do you think?
I think it makes no sense to have a no-server no-gui option, so this just
doesn't map
cleanly to our binary use flag system.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgsE+4ACgkQp/VmCx0OL2x4qACfRIJWzYc6oSswKzWCqxNLa5cp
46cAoKz672K5fmmaQMSw6HCpzDLB+AvT
=CiF4
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] preserving mtimes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi list,
files installed by portage to ${ROOT} do not have the same time stamps as the
same files
in ${D}. This creates problems for Common Lisp implementations and one Scheme
implementation in our overlay, explained in [1]. Current work-around is tarring
up and
untarring to preserve mtimes. Fixes mentioned in [2] could reduce that hack to
a touch of
some generated files to make them older than their sources, at least in our
case.
Unfortunately not all package managers implement the same behaviour and I don't
think PMS
says anything about it.
With reference counting implemented there doesn't seem to be any reason not to
preserve
mtimes by default anymore and I think that would be the correct thing to do,
but either
way I'd like PMS to specify what should happen wrt to mtimes, so that I can
rely on that.
Marijn
[1]:http://bugs.gentoo.org/show_bug.cgi?id=16162#c32
[2]:http://bugs.gentoo.org/show_bug.cgi?id=16162#c52
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgg30wACgkQp/VmCx0OL2xnQwCfayTo5PATYpCPRgcROP+9p0ES
jroAn3H2XJ103UC3V7XglDGSWZLHPDRH
=4pVG
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Markus Duft (mduft)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Markus,
Denis Dupeyron wrote:
| It's my pleasure to introduce Markus Duft (mduft) as a new developer.
| He will go among us under the name of mduft, and will work in the
| Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that
| means Gentoo on Win32.
What's the attraction?
Is this something you'd want to use?
Are you just interested in the challenge?
| Please everybody, give a very warm welcome to mduft.
Let me present you with this magic wand with 50 charges of
change-blue-screen-of-death-to
red-screen-of-death. May it last a long time,
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgY9u0ACgkQp/VmCx0OL2xjoQCgvLeuCIIanb8cTkopGKJJHiMe
95MAn1qPab5QEaa4kXLQ01GOE0Joxf4f
=5V7x
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| On Sun, 20 Apr 2008 22:17:27 -0700
| Donnie Berkholz [EMAIL PROTECTED] wrote:
| I don't think I understand the difference between the effects of
| these two options.
|
| cat/a-1 is installed and has RDEPEND cat/b
| cat/a-2 is to be installed and has DEPEND cat/b and RDEPEND =cat/b-2
| cat/b-1 is installed and has RDEPEND cat/a
| cat/b-2 is to be installed and has DEPEND cat/a and RDEPEND =cat/a-2
|
| Solve this and enlightenment shall be yours!
|
| Or a headache.
|
This problem has the two obvious solutions: either install a-2 and then b-2 or
the other
way around. But to be relevant to the current discussion you need to specify
whether or
not there are any pkg_{pre,post}inst functions. If there are too many then it
becomes
unsolvable and is probably a bug, as I already explained:
| If only one of those packages has a pkg_postinst then it is still
| solvable. If they both have a pkg_postinst then one of those is
| probably not essential for the actual usability of the package and
| should be removed. A final possibility is that the pkg_postinsts are
| both necessary for a fully functional package but not for the
| functionality used in the other pkg_postinst. If this is the case,
| then perhaps we should specify deps according to which ebuild phase
| they are necessary for?
|
| Not with current EAPIs we can't.
|
| SRC_UNPACK_DEP=app-arch/unzip
| SRC_COMPILE_DEP=dev-scheme/bigloo
| SRC_INSTALL_DEP=
|
| Labels are a cleaner solution to this. But again, we're discussing
| current EAPIs here.
Labels seems to be another syntax for providing the same information as I
proposed AIUI,
i.e. finer-grained deps.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgMVekACgkQp/VmCx0OL2waMgCglvtOPnu1xBIpUn0EbG7jDNsf
xLQAoLfQR4s8hAvzhgfx5JuY4sj9gp7+
=Creb
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| I'm rewording the PMS sections on dependencies to avoid permitting
| overly lax circular dependency resolution. Which of these wordings is
| accurate, given that usable means has its RDEPENDs installed and
| usable?
|
| 1. During pkg_preinst and pkg_postinst, any package dependency that is
| in both DEPEND and RDEPEND must be installed and usable.
|
| 2. During pkg_preinst and pkg_postinst, at least one of the following
| conditions must be met:
| a. every package dependency in DEPEND must be installed and usable
| b. every package dependency in RDEPEND must be installed and usable
|
| Do not attempt to write on both sides of the paper at once.
Every package dependency in DEPEND is installed and usable before src_unpack
starts,
right? So is the question here whether or not they can be uninstalled right
before
pkg_{pre,post}inst starts?
I don't know what the general use of pkg_preinst is, but in pkg_postinst the
package
itself should be runnable, so its RDEPENDS should be installed and usable at
this point.
So perhaps we should define that usable means each of its RDEPENDs is
installed and has
had its pkg_postinst function run. The recursion of that definition then comes
from the
requirement that RDEPENDs should be usable before pkg_postinst starts running.
| For why this matters:
|
| cat/a-1: RDEPEND cat/b
| cat/b-1: RDEPEND cat/a
|
| This is solvable. If package managers can't solve this, they can't
| install Gnome off a stage 3...
If only one of those packages has a pkg_postinst then it is still solvable.
If they both have a pkg_postinst then one of those is probably not essential
for the
actual usability of the package and should be removed. A final possibility is
that the
pkg_postinsts are both necessary for a fully functional package but not for the
functionality used in the other pkg_postinst. If this is the case, then perhaps
we should
specify deps according to which ebuild phase they are necessary for?
cat/a:
SRC_UNPACK_DEP=app-arch/unzip
SRC_COMPILE_DEP=dev-scheme/bigloo
SRC_INSTALL_DEP=
PKG_PREINST_DEP=
PKG_POSTINST_DEP=cat/b
RDEPEND=cat/b
and then cat/b would say:
PKG_PREINST_DEP=
PKG_POSTINST_DEP=
RDEPEND=cat/a
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgKH+4ACgkQp/VmCx0OL2xJOwCfdEO5IhWbjPvFRidzgdyFanEd
0v4An26a2XJ9Y4hwDz/bpqeUWeDMXAuk
=v/UL
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: What are blocks used for?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Mateusz A. Mierzwiński,
I really appreciate your trying to help, but your command of the English
language is such
that I and others have a lot of trouble making sense out of what you write.
Perhaps you
should consider that you also have problems understanding Ciaran's proposal
because of
this and refrain from commenting further.
Distrowatch page rankings are essentially noise. We continue to have between
900 and 1000
users in #gentoo. Try ranking that.
Thank you,
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgF8WwACgkQp/VmCx0OL2yImgCgssm1R901NwHGMjIKuzWZl5n5
PtwAoLi+u0AvuUf3Ow/X6AbdQblYdeyA
=p1+7
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] escaping variables in sed expressions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi list,
it seems I have been using some fragile sed expression and I'd like to tap the
collective
wisdom for avoiding doing that in the future.
dev-scheme/slib-3.1.5-r1 currently does
sed s_prefix = /usr/local/_prefix = ${D}/usr/_ -i Makefile
to make it not violate the sandbox. However a user had set
PORTAGE_TMPDIR=/home/gentoo_overflow/tmp causing the sed expression to contain
too may
underscores and failing.[1]
There are several option to handle this. I could use a less common delimiter or
I could
escape it: ${D//_/\_} instead of ${D}. I could use a sed expression that
doesn't suffer
from this problem (thanks to dleverton):
sed -ne '\_^prefix = /usr/local_!{p;d}' -e iprefix = ${D} -i Makefile
Comments?
Marijn
[1]: http://bugs.gentoo.org/show_bug.cgi?id=217735
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgEjjEACgkQp/VmCx0OL2zGDQCcCcgx1/g/UXpB38HIjKjNhmL6
S4MAoK1aXJS6SW9FaZT4i2iaeo6AlD2u
=Id31
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-editors/leafpad: ChangeLog leafpad-0.8.14.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
| On Sunday 30 March 2008, Ulrich Mueller wrote:
| On Sun, 30 Mar 2008, Mike Frysinger wrote:
| And IMHO the emacs USE flag should not be used here:
|
| $ ./configure -hs
| Configuration of Leafpad 0.8.12:
|
| Optional Features:
| [...]
| --enable-emacs implement Emacs key theme (experimental)
|
| $ equery uses =leafpad-0.8.12
| [...]
| + + emacs : Adds support for GNU Emacs
|
| As its description says, the flag is intended for GNU Emacs support
| which is not the case here.
| i think the USE flag makes sense. perhaps the description should be
| changed.
| Certainly a USE flag makes sense here, but it shouldn't be USE=emacs.
|
| The emacs global USE flag is used by 82 other packages (all outside
| the app-emacs category). Its purpose is always that GNU Emacs specific
| files are installed; either directly, or indirectly by pulling another
| package via *DEPEND.
|
| why cant it mean both ? USE flags are intended to control features, not
| dependencies. often times that just happens to translate into dependencies.
| realistically though, anyone who wants emacs wants all emacs things. if
| it were to just pull in the emacs dependency, then that could just as easily
| be accomplished by `emerge emacs` and then we can drop the USE flag entirely.
| -mike
If this in an emacs thing, then I guess it includes its own emacs-compatible
elisp
implementation with editor primitives exported to the user? Otherwise
customizability is
something of a laugh. Keybindings can be rewired. Simply having the same default
keybindings as emacs does not make a package emacsy.
Seeing as this is an editor and a GTK+ based simple text editor I doubt it
has much
claim to emacs-ness.
If my explanation doesn't make any sense to anyone, please trust our emacs
team's
judgement in this.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfwhCAACgkQp/VmCx0OL2yXPgCcD2K/7QKMe1V6S2mmXNRj213n
KmkAoJs7Tdrgka4Hgm33AdplqtTf+MH+
=4jAE
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: explicit -r0 in ebuild filename
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
| Brian Harring [EMAIL PROTECTED] posted
| [EMAIL PROTECTED], excerpted below, on
| Sun, 30 Mar 2008 02:39:46 -0700:
|
| No need to ban 1.00; it's already banned by PMS- quoting from names.tex:
|
| A version starts with the number part, which is in the form
| \t{[0-9]+($\backslash$.[0-9]+)*} (a positive integer, followed by zero
| or more dot-prefixed positive integers).
|
| Note the 'positive integers'; so 1.00 is actually blocked by PMS. That
| said, that same text seems to invalidly ban 1.0 also.
|
| Well, positive integer as used must include zero also, or by that
| definition, 0.xx style versions would be disallowed as well. That just
| wouldn't be sane if we're to keep anything even /close/ to upstream
| version mapping, so positive as used here must include 0 (and does by
| the literal ranged definition), and both 0.xx and x.00 are therefore
| defined as allowed, unless there's a further restriction elsewhere that
| hasn't been quoted.
|
non-negative integer must've been meant.
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfvqZAACgkQp/VmCx0OL2xPsQCbBNKtynU9aSdr3uY+x+sDt4tR
0SQAoK/sGruoV0qr8wyfB2qNPy0SzH7q
=QsyO
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] [LAST RITES] mit-scheme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Binary package mit-scheme has been masked and will be removed from the tree.
Our overlay
has source mit-scheme-c ebuilds which is the C compiler backend.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH3DOkp/VmCx0OL2wRAltSAJ4kq6LHxUqBAaQlM/IaSfVOyif1DQCghK3J
tgh2SCkK3NDmBFUUP/KT+s0=
=Mihm
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Projects and subproject status
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbato wrote:
| Here is a list of interesting questions: Are we fine? What are we
| going to do?
|
| Please project leaders try to reply in short.
To complete the reports for the Lisp project, I will now report for the Common
Lisp and
Scheme stuff.
How are we doing?
We are seriously understaffed. Joslwah and me are the only devs working here.
To make it
easier for users to help and get experience we have a git overlay.
My own focus is the Scheme area, Joslwah does CL, but he is very busy with real
life and
work so I'm trying to help out there too. This means that I try to keep at
least CL
implementations current in the main tree. Almost all other CL ebuilds are
unmaintained in
main tree. We have one very active user (Stelian Ionescu) maintaining a lot of
this other
CL stuff in our overlay who will hopefully be recruited.
For Scheme most of the ebuilds we have are implementations. Anything that
doesn't support
the amd64 architecture is not maintained in main tree by me. This means that
R6RS
implementations Larceny and Ikarus for example are in our overlay, but I'm not
sure how
well they work. There is little time to add non-implementations, but we have
bugs for most
of the stuff I want added. Some users have helped in the past and one is
helping currently
whom I hope to recruit.
| What are we going to do:
Keep implementations current and add new implementations to complete my
collection.
Hopefully do some recruiting. Maybe complete a wrapper script so it is possible
to
superficially test the more than a dozen Scheme implementations we have. Try to
interest
more people in Lisp. On that note:
Lisp is a family of very flexible and powerful programming languages. Compared
to other
languages there are fewer restrictions (if any), more supported paradigms, more
powerful
primitives (first-class continuations in Scheme for example) and infinitely
better
metaprogramming facilities due to superior lack of syntax.
Interested parentheses-non-bigots are very welcome to join us in our IRC
channel.
Marijn
Any sufficiently complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common Lisp.
— Philip Greenspun, often called Greenspun's Tenth Rule of Programming
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHjgKpp/VmCx0OL2wRAo6wAJ9ff056rDMZ/rCD21lDpyzJIUp1nwCghODl
8I7fNkL7jE6h7FjiaPibwBI=
=G3qR
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: categorizing RDEPEND to help --newuse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
Please comment on my ideas in http://bugs.gentoo.org/show_bug.cgi?id=201499
Regards,
Petteri
As requested on the bug by other people, could you please explain what exactly
you are proposing, what problem it is solving and how it solves that. If you
throw in a free example you'll make me real happy,
thank you,
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHWTIup/VmCx0OL2wRAtxkAKCTOGuMLMqdYE4ueSuviDL8M5tqOgCgoiFc
Pq/f+trtXxzsbdN14nOqRkg=
=r3wN
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Features and documentation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
How the recent changes happened to allow USE flag descriptions in
metadata.xml (which I'm not taking any position on now) gave me an idea.
The Linux kernel requires that any needed documentation accompany all
changes requiring said documentation -- part of the source-code patch
must apply to the Documentation/ directory. Should we require that
before you commit any changes, you (or someone) write the documentation
for them and commit it or submit a patch at the same time?
We're not talking about ebuilds here, are we? So what ARE we talking about?
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHTVPKp/VmCx0OL2wRAoMqAJ4zkrWMSmthzxNNjc+/syiz4EMq2wCcCnSE
CA8fiI/lq716rIV5+i9r4lI=
=ypdc
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Justin Bronder (jsbronder)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan Coutts wrote:
On Fri, 2007-11-16 at 14:40 +0200, Petteri Räty wrote:
It's my usual please to announce a new ebuild monkey. Justin hails from
Brighton, Massachusetts. His educational background should provide a
good theoretical approach to all the future flames on gentoo-dev:
I'm pretty much self taught computer wise as I went to the University
of Maine in order to get my Master's in Mathematics where I focused on
abstract algebra and number theory, I liked the challenges of
discovering proofs, and pretty much ignored any real applications.
Please give him the normal welcome.
Welcome Justin!
If you like beautiful code with firm mathematical underpinnings and a
slight lack of real applications you'll love Haskell ;-)
You're most welcome to come chat with us in #gentoo-haskell
Hmm, a mystery developer.
Hi Justin, I wonder why I haven't seen you on the functional programming side
of Gentoo, you being a maths guy and all. Anyway, welcome and don't let the
Haskell guys fool you ;P
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHPZm3p/VmCx0OL2wRAtx0AJ97ki35trBO9RsKlLdJg/76SsuXbQCguENA
8E4R7f997n4x/hv7FBRqQ2w=
=MqZL
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New eclass: emul-linux-x86.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Piotr Jaroszyński wrote:
On Wednesday 14 of November 2007 11:31:13 Torsten Rehn wrote:
On Wednesday 14 November 2007, Mike Doty wrote:
S=${WORKDIR}
Shouldn't ${WORKDIR} be quoted here, too?
No need to quote in assignments.
But why is it standard to quote other assignments like in DESCRIPTION and
HOMEPAGE then?
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHOvZ2p/VmCx0OL2wRAtqZAJ9xUyUsTOF8OZEeAjZ5JMwksqpDigCeLCLG
veWYwxkBPTb5aAidxFxBIx4=
=09PE
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Phase invariancy and exclusivity requirements
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Fri, 9 Nov 2007 22:40:08 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
Is the following set sufficient? Is the following set the least
restrictive correct solution?
... to explain the implications of these...
Say we have packages a, b and c, and none of them have any
dependencies. One valid solution to the build ordering is as follows:
* Install a
* Install b
* Install c
One of many solutions that is *not* valid is:
* Start doing a, b and c in parallel. Install them as they become
ready, doing only one merge at once.
Another that is not valid is:
* Start doing a, b and c in parallel, but don't merge them.
* Merge a.
* Merge b.
* Merge c.
One that is valid is:
* Build binary packages for a, b and c in parallel.
* Merge a's binary.
* Merge b's binary.
* Merge c's binary.
What exactly is the difference between this valid situation and the previous
invalid one?
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHOEaGp/VmCx0OL2wRAlShAKCNohJzGNppNM7LFgHT/ID/9AyVjwCeJhlM
vGHuzGLLa/+Oyj1t2T1KTP4=
=TKhb
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
src_fetch (was Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April))
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Fri, 13 Apr 2007 14:21:16 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
On Wed, 11 Apr 2007 15:41:01 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:
* Phase changes: src_fetch - src_unpack - src_prepare -
src_configure - src_compile - src_test - src_install
No to src_fetch
Why? It would be useful for CVS, SVN etc ebuilds. I'm not suggesting it
be used for SRC_URI things.
Hi list,
Not having src_fetch is really braindead. There are always gonna be silly
packages that don't fit into the nice default SRC_URI scheme.
Use case one: package is completely unversioned upstream.
Have src_fetch add a version as appropriate to the downloaded/mirrored
version. This will work as change of upstream sources will be detected by all
the checksums we do.
Use case two: package is incompatibly versioned.
smlnj for example releases unversioned files in a versioned directory. There
is currently no way to mirror that in distfiles as there is nowhere that I
could specify that I want files to go to a separate directory.
Right. These use cases are really a bonus. Having src_fetch that we can
redefine is simply the right thing and I can't believe it doesn't exist already.
Consider this my vote for an EAPI 2 which adds user-redefinable src_fetch ASAP.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHNJvRp/VmCx0OL2wRAnc9AJ0bIm1snoGivLSZgTEE4dx7e2VgQwCeL7Kk
fwvaBcfVHv+nSXQd1KTT3ls=
=44uf
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
� wrote:
Wulf C. Krueger schrieb:
On Friday, 09. November 2007 10:10:42 Rený 'Necoro' Neumann wrote:
But as I think, that the uppercase version is the common behavior here,
it should not need this extra PYTHON. :) That's why the patch ;)
Actually, the mixed-case is what we have encountered in most cases.
Furthermore, as you stated correctly yourself, cmake is case-sensitive and
a patch that works around that fact only to have one parameter less for a
function doesn't really make much sense in my book.
Hmm ... ok - if you say, that more applications used the mixed case
versions, the current version is ok :)
I did not want to reduce one parameter, but when I first used this
eclass function, I assumed, that it will do the right thing (that is:
make it uppercase). It did not do so - that's why the patch ;).
Another way would be to enhance the comment and state explicitly that it
takes the useflag literally and does not do any case transition :)
Please don't reuse other people's digital signatures, Necoro.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHNJy/p/VmCx0OL2wRApycAJwLttjtkPEEzEEkM0XlNg93FCzgCgCgtkRU
/HTtrpUXuHV4jjcQ8qGqlSM=
=K51B
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marijn Schouten (hkBst) wrote:
ý wrote:
Wulf C. Krueger schrieb:
On Friday, 09. November 2007 10:10:42 Rený 'Necoro' Neumann wrote:
But as I think, that the uppercase version is the common behavior here,
it should not need this extra PYTHON. :) That's why the patch ;)
Actually, the mixed-case is what we have encountered in most cases.
Furthermore, as you stated correctly yourself, cmake is case-sensitive and
a patch that works around that fact only to have one parameter less for a
function doesn't really make much sense in my book.
Hmm ... ok - if you say, that more applications used the mixed case
versions, the current version is ok :)
I did not want to reduce one parameter, but when I first used this
eclass function, I assumed, that it will do the right thing (that is:
make it uppercase). It did not do so - that's why the patch ;).
Another way would be to enhance the comment and state explicitly that it
takes the useflag literally and does not do any case transition :)
Please don't reuse other people's digital signatures, Necoro.
Never mind, I take it back.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHNJ4Qp/VmCx0OL2wRAlNSAJwMzJyjMgcywE05LQSJIIvlZp8L5ACfUEnU
d0YFSB4eC7r+dHvVY1j4y9A=
=qJmh
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: cmake.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Krzysiek Pawlik wrote: A little introduction: cmake is an alternative for autotools, more and more packages are using it (and some new big ones are on the way, KDE4 for example). I've wrote an eclass that makes writing ebuilds for such packages a little easier - it provides an ecmake function that takes care of few needed variables, prefix and such. I'm a bit confused now. Both this eclass and the recently submitted cmake-utils.eclass seem to handle CMake-based packages. Can someone clarify? Marijn - -- Marijn Schouten (hkBst), Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHLdC/p/VmCx0OL2wRAqkvAKCamrr4efE6byCFxKV3+FktlTdEtwCgsXGZ k+2A7Ib+BnfNw7wAa+//INg= =BV6f -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New global USE flag: modplug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeroen Roovers wrote:
On Thu, 1 Nov 2007 23:32:34 +0200
Samuli Suominen [EMAIL PROTECTED] wrote:
I'd like to add USE modplug to use.desc. I'll do it tomorrow,
unless someone objects.
Remember that tomorrow is always too soon in projects like Gentoo. :)
$ euses -s mod fmod modplug
media-video/vlc:mod - Enables Mod demux support.
games-strategy/dark-oberon:fmod - Add sound support (fmod)
media-libs/panda3d:fmod - Enables support for using mod files for audio
support gnustep-apps/cynthiune:modplug - Build with modplug support
media-libs/xine-lib:modplug - Build with modplug support
media-plugins/audacious-plugins:modplug - Build with modplug support
media-sound/audacious:modplug - Build with modplug support
media-sound/bmpx:modplug - Build with modplug support
media-sound/cmus:modplug - Build with modplug support
media-sound/herrie:modplug - Build with modplug support
media-sound/moc:modplug - Add support for modplug
That's three USE flags describing the same support for (playing) mod
files, but ebuilds depend on either media-libs/{fmod,libmodplug} and
the former has its own USE flag.
media-video/vlc has a libmodplug dependency and should probably be
changed to use IUSE=modplug instead of IUSE=mod, if USE=modplug goes
global.
Another prime example for use flags with more than two values:
mod=off
mod=fmod
mod=libmodplug
the first for disabling mod support, the second for enabling it and preferring
fmod implementation, the third for enabling it and preferring libmodplug
implementation.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKxrHp/VmCx0OL2wRApqiAJ9gDyyqH4JdJu4p8MzmcWOGuBVzHwCfXR1/
WHIaIUtpJqfM0SW+GMdEl9A=
=fQgi
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New global USE flag: modplug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeroen Roovers wrote: On Fri, 02 Nov 2007 13:40:40 +0100 Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote: Another prime example for use flags with more than two values: mod=off mod=fmod mod=libmodplug the first for disabling mod support, the second for enabling it and preferring fmod implementation, the third for enabling it and preferring libmodplug implementation. I don't think you've actually argued the case why one USE flag with three, perhaps four modes (off, fmod, libmodplug, and perhaps default) is preferable to two USE flags with two modes each (fmod and modplug, both refering to the libs a package links to, either on or off). I tried to explain this before. See http://article.gmane.org/gmane.linux.gentoo.devel/52316/match=use+options. Having an ordinary use flag for each library may work well enough when there are less than three libraries that provide a certain functionality, although with 2 old-style use flags you already have one bogus fourth option. Default should not be an option of its own; one of the three options should be the default. Besides, could you explain why are you trying to hijack a short and simple thread about globalising one or two USE flags? I'm not trying to hijack this thread. I'm just injecting one message pointing this out as something I think could benefit from my proposal. A few real examples may go a long way to explaining something. Marijn - -- Marijn Schouten (hkBst), Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKzDup/VmCx0OL2wRAo5vAJ0VLX8BSFLFTY2K1wLADtS35jZHnwCfS8Vd IgDXBRNrzWbiLfuZadHIzj8= =MHt+ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Drake wrote:
Marijn Schouten (hkBst) wrote:
use_mime() {
local WORD=$(ifv $2 $2 $1)
ifuse $1 ${WORD};
}
for generating a string of ';'-separated mime-types based on use flags.
The explanation of this function is:
#set WORD to argument 2 or if that is empty to argument 1
#output ${WORD}; if use flag $1 is set (or if it starts with ! and
is unset)
#otherwise don't output anything
I don't quite understand what this function does. What ebuild nastiness
does it replace, or what does it allow that was not previously possible?
(can you give an example?)
It's something I built following some questions by lack in #gentoo-dev-help.
Perhaps he can clarify if necessary.
[di okt 30 2007] [18:02:10]
lack Now, I want to have each ebuild have a global variable called
'APPMIME' that somehow contains the mime-types available and the associated
USE flags, such that the eclass that actually creates the .desktop file can
appropriately go through and add only the mime-types that are enabled by the
USE flags.
zlin no, there is no such convenience function.
lack That's too bad - it would be pretty useful. Oh well, I'll have to
write some sort of fancy function in the ebuild then.
hkBst lack: what about APPMIME=thing1 $(usev thing2)?
zlin I you think such a flattener would be really useful I suppose you
can suggest it on -dev@ ..
lack hkBst: Hm, that's not too bad.
zlin *If
lack I wonder, would that work like: APPMIME=one;$(if usev
thing2;thing3);thing4?
lack Maybe I'd have to do some odd escaping in that case of a
semicolon-separated list.
hkBst lack: why do you want it to be ;-separated?
lack Because that's the eventual format of 'MIME=type/one;type/two' in
the .desktop file.
lack If I could just set up the variable so the eclass doesn't have to
actually do any parsing that would be easiest.
lack APPMIME=type/one;type/two$(if use foo ';type/foo1;type/foo2')$(if
use bar ';type/barx;type/bary') Perhaps?
zlin usemime() { useq $1 echo $2;; }; APPMIME=thing1;$(usemime
useflag thing2)$(usemime useflag2 thing3;thing4)thing5
lack Ah, that usemime feature looks useful, thanks!
But
usemime() { useq $1 echo $2;; }
lacks default arguments and ifuse provides a nicer interface if you want to do
output, which is the use case I am proposing ifuse for.
Some other examples:
in dev-scheme/bigloo-3.0b_p2 I use (econf doesn't work):
./configure \
$(use java echo --jvm=yes --java=$(java-config --java)
- --javac=$(java-config --javac)) \
- --prefix=/usr \
# --bee=$(if use fullbee; then echo full; else echo partial; fi)
it would be a bit nicer if I could just write:
./configure \
$(ifuse java --jvm=yes --java=$(java-config --java) --javac=$(java-config
- --javac)) \
- --prefix=/usr \
# --bee=$(ifuse fullbee full partial)
The example from
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1
if use gnutls ; then
myconf=${myconf} --enable-ssl --with-ssl=gnutls
elif use ssl ; then
myconf=${myconf} --enable-ssl --with-ssl=openssl
else
myconf=${myconf} --disable-ssl
fi
econf \
# Other stuff
${myconf} \
|| die configure failed
could become:
econf \
# Other stuff
$(ifuse gnutls --enable-ssl --with-ssl=gnutls \
$(ifuse ssl --enable-ssl --with-ssl=openssl --disable-ssl)) \
|| die configure failed
which may require some getting used to. But no functionality will be lost, so
if you prefer the old way, all your existing methods will continue to work.
There will just be another option.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKzmzp/VmCx0OL2wRAk8bAJ9rDW57WStJ79PBpXIbQN9phEv6GwCcChaR
OqLUSnsTRttVwFdmCwDnW7I=
=Zw+z
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Drake wrote:
Marijn Schouten (hkBst) wrote:
use_mime() {
local WORD=$(ifv $2 $2 $1)
ifuse $1 ${WORD};
}
for generating a string of ';'-separated mime-types based on use flags.
The explanation of this function is:
#set WORD to argument 2 or if that is empty to argument 1
#output ${WORD}; if use flag $1 is set (or if it starts with ! and
is unset)
#otherwise don't output anything
I don't quite understand what this function does. What ebuild nastiness
does it replace, or what does it allow that was not previously possible?
(can you give an example?)
It's something I built following some questions by lack in #gentoo-dev-help.
Perhaps he can clarify if necessary.
[di okt 30 2007] [18:02:10]
lack Now, I want to have each ebuild have a global variable called
'APPMIME' that somehow contains the mime-types available and the associated
USE flags, such that the eclass that actually creates the .desktop file can
appropriately go through and add only the mime-types that are enabled by the
USE flags.
zlin no, there is no such convenience function.
lack That's too bad - it would be pretty useful. Oh well, I'll have to
write some sort of fancy function in the ebuild then.
hkBst lack: what about APPMIME=thing1 $(usev thing2)?
zlin I you think such a flattener would be really useful I suppose you
can suggest it on -dev@ ..
lack hkBst: Hm, that's not too bad.
zlin *If
lack I wonder, would that work like: APPMIME=one;$(if usev
thing2;thing3);thing4?
lack Maybe I'd have to do some odd escaping in that case of a
semicolon-separated list.
hkBst lack: why do you want it to be ;-separated?
lack Because that's the eventual format of 'MIME=type/one;type/two' in
the .desktop file.
lack If I could just set up the variable so the eclass doesn't have to
actually do any parsing that would be easiest.
lack APPMIME=type/one;type/two$(if use foo ';type/foo1;type/foo2')$(if
use bar ';type/barx;type/bary') Perhaps?
zlin usemime() { useq $1 echo $2;; }; APPMIME=thing1;$(usemime
useflag thing2)$(usemime useflag2 thing3;thing4)thing5
lack Ah, that usemime feature looks useful, thanks!
But
usemime() { useq $1 echo $2;; }
lacks default arguments and ifuse provides a nicer interface if you want to do
output, which is the use case I am proposing ifuse for.
Some other examples:
in dev-scheme/bigloo-3.0b_p2 I use (econf doesn't work):
./configure \
$(use java echo --jvm=yes --java=$(java-config --java)
- --javac=$(java-config --javac)) \
- --prefix=/usr \
# --bee=$(if use fullbee; then echo full; else echo partial; fi)
it would be a bit nicer if I could just write:
./configure \
$(ifuse java --jvm=yes --java=$(java-config --java) --javac=$(java-config
- --javac)) \
- --prefix=/usr \
# --bee=$(ifuse fullbee full partial)
The example from
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1
if use gnutls ; then
myconf=${myconf} --enable-ssl --with-ssl=gnutls
elif use ssl ; then
myconf=${myconf} --enable-ssl --with-ssl=openssl
else
myconf=${myconf} --disable-ssl
fi
econf \
# Other stuff
${myconf} \
|| die configure failed
could become:
econf \
# Other stuff
$(ifuse gnutls --enable-ssl --with-ssl=gnutls \
$(ifuse ssl --enable-ssl --with-ssl=openssl --disable-ssl)) \
|| die configure failed
which may require some getting used to. But no functionality will be lost, so
if you prefer the old way, all your existing methods will continue to work.
There will just be another option.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKzmzp/VmCx0OL2wRAk8bAJ9rDW57WStJ79PBpXIbQN9phEv6GwCcChaR
OqLUSnsTRttVwFdmCwDnW7I=
=Zw+z
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roy Marples wrote:
On Fri, 2007-11-02 at 14:44 +0100, Marijn Schouten (hkBst) wrote:
[[ ${flag} = !* ]] { success=1 ; flag=${flag:1} }
Could be written as
[ ${flag#!} != ${flag} ] { success=1; flag=${flag#!}; }
string=$( (( ${success} == 0 )) echo ${string_success} || echo
${string_failure} )
[[ -n ${string} ]] echo ${string}
if [ ${success} = 0 ]; then
string=${string_success}
else
string=${string_failure}
fi
[ -n ${string} ] echo ${string}
Actually I'd prefer to introduce
ifz() {
[[ $1 = 0 ]] echo $2 || echo $3
}
and reimplement as follows
string=$(ifz ${success} ${string_success} ${string_failure})
but I don't want to push my luck,
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKzPXp/VmCx0OL2wRAhvNAKCB5yPezkffi/QXx6aDEXsgB662kwCfb3DV
SDZ66FZzdoSF3uftGd+ZBik=
=ylxW
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New global USE flag: modplug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeroen Roovers wrote:
On Thu, 1 Nov 2007 23:32:34 +0200
Samuli Suominen [EMAIL PROTECTED] wrote:
I'd like to add USE modplug to use.desc. I'll do it tomorrow,
unless someone objects.
Remember that tomorrow is always too soon in projects like Gentoo. :)
$ euses -s mod fmod modplug
media-video/vlc:mod - Enables Mod demux support.
games-strategy/dark-oberon:fmod - Add sound support (fmod)
media-libs/panda3d:fmod - Enables support for using mod files for audio
support gnustep-apps/cynthiune:modplug - Build with modplug support
media-libs/xine-lib:modplug - Build with modplug support
media-plugins/audacious-plugins:modplug - Build with modplug support
media-sound/audacious:modplug - Build with modplug support
media-sound/bmpx:modplug - Build with modplug support
media-sound/cmus:modplug - Build with modplug support
media-sound/herrie:modplug - Build with modplug support
media-sound/moc:modplug - Add support for modplug
That's three USE flags describing the same support for (playing) mod
files, but ebuilds depend on either media-libs/{fmod,libmodplug} and
the former has its own USE flag.
media-video/vlc has a libmodplug dependency and should probably be
changed to use IUSE=modplug instead of IUSE=mod, if USE=modplug goes
global.
Another prime example for use flags with more than two values:
mod=off
mod=fmod
mod=libmodplug
the first for disabling mod support, the second for enabling it and preferring
fmod implementation, the third for enabling it and preferring libmodplug
implementation.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKxrHp/VmCx0OL2wRApqiAJ9gDyyqH4JdJu4p8MzmcWOGuBVzHwCfXR1/
WHIaIUtpJqfM0SW+GMdEl9A=
=fQgi
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] More general interface to use flags
Hi list,
the current interface to use flags, useq, usev, use_with, use_enable, as
defined in /usr/lib/portage/bin/ebuild.sh lacks generality. The common thing
is testing a use flag and possibly echoing a string, but there is no function
that implements this common behaviour.
I propose that we add such a function. Proposed name for the function is
ifuse.
I also propose to add the utility function ifv which is useful for writing
concise and clean code.
These additions would allow you to easily define your own function for
processing use flags in ebuilds and eclasses. One such example is
use_mime() {
local WORD=$(ifv $2 $2 $1)
ifuse $1 ${WORD};
}
for generating a string of ';'-separated mime-types based on use flags.
The explanation of this function is:
#set WORD to argument 2 or if that is empty to argument 1
#output ${WORD}; if use flag $1 is set (or if it starts with ! and is unset)
#otherwise don't output anything
The existing interface is also simple to reimplement:
use() {
ifuse ${1}
}
useq() {
ifuse ${1}
}
usev() {
ifuse ${1} ${1}
}
use_with() {
local SUFFIX=$(ifv $3 =$3)
local WORD=$(ifv $2 $2 $1)
ifuse $1 --with-${WORD}${SUFFIX} --without-${WORD}
}
use_enable() {
local SUFFIX=$(ifv $3 =$3)
local WORD=$(ifv $2 $2 $1)
ifuse $1 --enable-${WORD}${SUFFIX} --disable-${WORD}
}
ifuse's code is much like useq's code now, but more versatile. You can find it
attached along with ifv.
Please comment,
Marijn
--
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
# test a use flag and return the result, possibly echo a non-empty string
ifuse() {
local flag=$1
local string_success=$2
local string_failure=$3
local success=0
# invert the return value for !blah and strip the '!'
[[ ${flag} = !* ]] { success=1 ; flag=${flag:1} }
# Make sure we have this USE flag in IUSE
if ! hasq ${flag} ${IUSE} ${E_IUSE} ! hasq ${flag}
${PORTAGE_ARCHLIST} selinux; then
eqawarn QA Notice: USE Flag '${flag}' not in IUSE for
${CATEGORY}/${PF}
fi
hasq ${flag} ${USE} || ((success=1-success))
string=$( (( ${success} == 0 )) echo ${string_success} || echo
${string_failure} )
[[ -n ${string} ]] echo ${string}
return ${success}
}
ifv() {
[[ -n $1 ]] echo $2 || echo $3
}
signature.asc
Description: OpenPGP digital signature
[gentoo-portage-dev] Re: [gentoo-dev] More general interface to use flags
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Drake wrote:
Marijn Schouten (hkBst) wrote:
use_mime() {
local WORD=$(ifv $2 $2 $1)
ifuse $1 ${WORD};
}
for generating a string of ';'-separated mime-types based on use flags.
The explanation of this function is:
#set WORD to argument 2 or if that is empty to argument 1
#output ${WORD}; if use flag $1 is set (or if it starts with ! and
is unset)
#otherwise don't output anything
I don't quite understand what this function does. What ebuild nastiness
does it replace, or what does it allow that was not previously possible?
(can you give an example?)
It's something I built following some questions by lack in #gentoo-dev-help.
Perhaps he can clarify if necessary.
[di okt 30 2007] [18:02:10]
lack Now, I want to have each ebuild have a global variable called
'APPMIME' that somehow contains the mime-types available and the associated
USE flags, such that the eclass that actually creates the .desktop file can
appropriately go through and add only the mime-types that are enabled by the
USE flags.
zlin no, there is no such convenience function.
lack That's too bad - it would be pretty useful. Oh well, I'll have to
write some sort of fancy function in the ebuild then.
hkBst lack: what about APPMIME=thing1 $(usev thing2)?
zlin I you think such a flattener would be really useful I suppose you
can suggest it on -dev@ ..
lack hkBst: Hm, that's not too bad.
zlin *If
lack I wonder, would that work like: APPMIME=one;$(if usev
thing2;thing3);thing4?
lack Maybe I'd have to do some odd escaping in that case of a
semicolon-separated list.
hkBst lack: why do you want it to be ;-separated?
lack Because that's the eventual format of 'MIME=type/one;type/two' in
the .desktop file.
lack If I could just set up the variable so the eclass doesn't have to
actually do any parsing that would be easiest.
lack APPMIME=type/one;type/two$(if use foo ';type/foo1;type/foo2')$(if
use bar ';type/barx;type/bary') Perhaps?
zlin usemime() { useq $1 echo $2;; }; APPMIME=thing1;$(usemime
useflag thing2)$(usemime useflag2 thing3;thing4)thing5
lack Ah, that usemime feature looks useful, thanks!
But
usemime() { useq $1 echo $2;; }
lacks default arguments and ifuse provides a nicer interface if you want to do
output, which is the use case I am proposing ifuse for.
Some other examples:
in dev-scheme/bigloo-3.0b_p2 I use (econf doesn't work):
./configure \
$(use java echo --jvm=yes --java=$(java-config --java)
- --javac=$(java-config --javac)) \
- --prefix=/usr \
# --bee=$(if use fullbee; then echo full; else echo partial; fi)
it would be a bit nicer if I could just write:
./configure \
$(ifuse java --jvm=yes --java=$(java-config --java) --javac=$(java-config
- --javac)) \
- --prefix=/usr \
# --bee=$(ifuse fullbee full partial)
The example from
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1
if use gnutls ; then
myconf=${myconf} --enable-ssl --with-ssl=gnutls
elif use ssl ; then
myconf=${myconf} --enable-ssl --with-ssl=openssl
else
myconf=${myconf} --disable-ssl
fi
econf \
# Other stuff
${myconf} \
|| die configure failed
could become:
econf \
# Other stuff
$(ifuse gnutls --enable-ssl --with-ssl=gnutls \
$(ifuse ssl --enable-ssl --with-ssl=openssl --disable-ssl)) \
|| die configure failed
which may require some getting used to. But no functionality will be lost, so
if you prefer the old way, all your existing methods will continue to work.
There will just be another option.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKzmzp/VmCx0OL2wRAk8bAJ9rDW57WStJ79PBpXIbQN9phEv6GwCcChaR
OqLUSnsTRttVwFdmCwDnW7I=
=Zw+z
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
[gentoo-portage-dev] Re: [gentoo-dev] More general interface to use flags
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Drake wrote:
Marijn Schouten (hkBst) wrote:
use_mime() {
local WORD=$(ifv $2 $2 $1)
ifuse $1 ${WORD};
}
for generating a string of ';'-separated mime-types based on use flags.
The explanation of this function is:
#set WORD to argument 2 or if that is empty to argument 1
#output ${WORD}; if use flag $1 is set (or if it starts with ! and
is unset)
#otherwise don't output anything
I don't quite understand what this function does. What ebuild nastiness
does it replace, or what does it allow that was not previously possible?
(can you give an example?)
It's something I built following some questions by lack in #gentoo-dev-help.
Perhaps he can clarify if necessary.
[di okt 30 2007] [18:02:10]
lack Now, I want to have each ebuild have a global variable called
'APPMIME' that somehow contains the mime-types available and the associated
USE flags, such that the eclass that actually creates the .desktop file can
appropriately go through and add only the mime-types that are enabled by the
USE flags.
zlin no, there is no such convenience function.
lack That's too bad - it would be pretty useful. Oh well, I'll have to
write some sort of fancy function in the ebuild then.
hkBst lack: what about APPMIME=thing1 $(usev thing2)?
zlin I you think such a flattener would be really useful I suppose you
can suggest it on -dev@ ..
lack hkBst: Hm, that's not too bad.
zlin *If
lack I wonder, would that work like: APPMIME=one;$(if usev
thing2;thing3);thing4?
lack Maybe I'd have to do some odd escaping in that case of a
semicolon-separated list.
hkBst lack: why do you want it to be ;-separated?
lack Because that's the eventual format of 'MIME=type/one;type/two' in
the .desktop file.
lack If I could just set up the variable so the eclass doesn't have to
actually do any parsing that would be easiest.
lack APPMIME=type/one;type/two$(if use foo ';type/foo1;type/foo2')$(if
use bar ';type/barx;type/bary') Perhaps?
zlin usemime() { useq $1 echo $2;; }; APPMIME=thing1;$(usemime
useflag thing2)$(usemime useflag2 thing3;thing4)thing5
lack Ah, that usemime feature looks useful, thanks!
But
usemime() { useq $1 echo $2;; }
lacks default arguments and ifuse provides a nicer interface if you want to do
output, which is the use case I am proposing ifuse for.
Some other examples:
in dev-scheme/bigloo-3.0b_p2 I use (econf doesn't work):
./configure \
$(use java echo --jvm=yes --java=$(java-config --java)
- --javac=$(java-config --javac)) \
- --prefix=/usr \
# --bee=$(if use fullbee; then echo full; else echo partial; fi)
it would be a bit nicer if I could just write:
./configure \
$(ifuse java --jvm=yes --java=$(java-config --java) --javac=$(java-config
- --javac)) \
- --prefix=/usr \
# --bee=$(ifuse fullbee full partial)
The example from
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1
if use gnutls ; then
myconf=${myconf} --enable-ssl --with-ssl=gnutls
elif use ssl ; then
myconf=${myconf} --enable-ssl --with-ssl=openssl
else
myconf=${myconf} --disable-ssl
fi
econf \
# Other stuff
${myconf} \
|| die configure failed
could become:
econf \
# Other stuff
$(ifuse gnutls --enable-ssl --with-ssl=gnutls \
$(ifuse ssl --enable-ssl --with-ssl=openssl --disable-ssl)) \
|| die configure failed
which may require some getting used to. But no functionality will be lost, so
if you prefer the old way, all your existing methods will continue to work.
There will just be another option.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKzmzp/VmCx0OL2wRAk8bAJ9rDW57WStJ79PBpXIbQN9phEv6GwCcChaR
OqLUSnsTRttVwFdmCwDnW7I=
=Zw+z
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
[gentoo-portage-dev] More general interface to use flags
Hi list,
the current interface to use flags, useq, usev, use_with, use_enable, as
defined in /usr/lib/portage/bin/ebuild.sh lacks generality. The common thing
is testing a use flag and possibly echoing a string, but there is no function
that implements this common behaviour.
I propose that we add such a function. Proposed name for the function is
ifuse.
I also propose to add the utility function ifv which is useful for writing
concise and clean code.
These additions would allow you to easily define your own function for
processing use flags in ebuilds and eclasses. One such example is
use_mime() {
local WORD=$(ifv $2 $2 $1)
ifuse $1 ${WORD};
}
for generating a string of ';'-separated mime-types based on use flags.
The explanation of this function is:
#set WORD to argument 2 or if that is empty to argument 1
#output ${WORD}; if use flag $1 is set (or if it starts with ! and is unset)
#otherwise don't output anything
The existing interface is also simple to reimplement:
use() {
ifuse ${1}
}
useq() {
ifuse ${1}
}
usev() {
ifuse ${1} ${1}
}
use_with() {
local SUFFIX=$(ifv $3 =$3)
local WORD=$(ifv $2 $2 $1)
ifuse $1 --with-${WORD}${SUFFIX} --without-${WORD}
}
use_enable() {
local SUFFIX=$(ifv $3 =$3)
local WORD=$(ifv $2 $2 $1)
ifuse $1 --enable-${WORD}${SUFFIX} --disable-${WORD}
}
ifuse's code is much like useq's code now, but more versatile. You can find it
attached along with ifv.
Please comment,
Marijn
--
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
# test a use flag and return the result, possibly echo a non-empty string
ifuse() {
local flag=$1
local string_success=$2
local string_failure=$3
local success=0
# invert the return value for !blah and strip the '!'
[[ ${flag} = !* ]] { success=1 ; flag=${flag:1} }
# Make sure we have this USE flag in IUSE
if ! hasq ${flag} ${IUSE} ${E_IUSE} ! hasq ${flag}
${PORTAGE_ARCHLIST} selinux; then
eqawarn QA Notice: USE Flag '${flag}' not in IUSE for
${CATEGORY}/${PF}
fi
hasq ${flag} ${USE} || ((success=1-success))
string=$( (( ${success} == 0 )) echo ${string_success} || echo
${string_failure} )
[[ -n ${string} ]] echo ${string}
return ${success}
}
ifv() {
[[ -n $1 ]] echo $2 || echo $3
}
signature.asc
Description: OpenPGP digital signature
[gentoo-portage-dev] More general interface to use flags
Hi list,
the current interface to use flags, useq, usev, use_with, use_enable, as
defined in /usr/lib/portage/bin/ebuild.sh lacks generality. The common thing
is testing a use flag and possibly echoing a string, but there is no function
that implements this common behaviour.
I propose that we add such a function. Proposed name for the function is
ifuse.
I also propose to add the utility function ifv which is useful for writing
concise and clean code.
These additions would allow you to easily define your own function for
processing use flags in ebuilds and eclasses. One such example is
use_mime() {
local WORD=$(ifv $2 $2 $1)
ifuse $1 ${WORD};
}
for generating a string of ';'-separated mime-types based on use flags.
The explanation of this function is:
#set WORD to argument 2 or if that is empty to argument 1
#output ${WORD}; if use flag $1 is set (or if it starts with ! and is unset)
#otherwise don't output anything
The existing interface is also simple to reimplement:
use() {
ifuse ${1}
}
useq() {
ifuse ${1}
}
usev() {
ifuse ${1} ${1}
}
use_with() {
local SUFFIX=$(ifv $3 =$3)
local WORD=$(ifv $2 $2 $1)
ifuse $1 --with-${WORD}${SUFFIX} --without-${WORD}
}
use_enable() {
local SUFFIX=$(ifv $3 =$3)
local WORD=$(ifv $2 $2 $1)
ifuse $1 --enable-${WORD}${SUFFIX} --disable-${WORD}
}
ifuse's code is much like useq's code now, but more versatile. You can find it
attached along with ifv.
Please comment,
Marijn
--
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
# test a use flag and return the result, possibly echo a non-empty string
ifuse() {
local flag=$1
local string_success=$2
local string_failure=$3
local success=0
# invert the return value for !blah and strip the '!'
[[ ${flag} = !* ]] { success=1 ; flag=${flag:1} }
# Make sure we have this USE flag in IUSE
if ! hasq ${flag} ${IUSE} ${E_IUSE} ! hasq ${flag}
${PORTAGE_ARCHLIST} selinux; then
eqawarn QA Notice: USE Flag '${flag}' not in IUSE for
${CATEGORY}/${PF}
fi
hasq ${flag} ${USE} || ((success=1-success))
string=$( (( ${success} == 0 )) echo ${string_success} || echo
${string_failure} )
[[ -n ${string} ]] echo ${string}
return ${success}
}
ifv() {
[[ -n $1 ]] echo $2 || echo $3
}
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-portage-dev] use* cleanup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Wednesday 31 October 2007, Marijn Schouten (hkBst) wrote:
I hope this is just an artifact of the patch being a bit opaque. The
inconsistent indentation in the patch is a consequence of emacs bash mode
using a different indentation style than (I guess) vi(m). I'm sure even in
vi you can re-indent my code with one simple key-chord.
no idea, i dont use vi ... but you're writing the patch which means you get
to
fix it ;)
Sure, I can do that.
The immediate motivation of my examining this code was a request on
#gentoo-dev-help by lack for something which I could with my new code
easily write like this:
use_mime() {
local WORD=$(_if $2 $2 $1)
_use $1 ${WORD};
}
write where ? in eclasses/ebuilds ?
yes
local SUFFIX=$(_if $3 =$3)
local WORD=$(_if $2 $2 $1)
local FOO=$(...)
extraneous quoting makes eyes bleed
_if() {
if $1; then echo $2; else echo $3; fi
}
$1 echo $2 || echo $3
Sure :)
if hasq ${flag} ${USE} ; then
echo ${string_success}; return ${found}
else
echo ${string_failure}; return $((!found))
fi
no point in cuddling those lines
Hmm, cuddling? I don't know what that means in this context.
What's not to like?
when you've written it out, it does look much nicer ... but i'd like to
understand the motivation behind it first ...
It seems the logical way to do it. Having a versatile function that checks use
flags and emits strings is very useful. Without it people will reimplement it
in a half-assed way time and time again in their ebuilds or eclasses. I've
done this myself. For example in dev-scheme/bigloo-3.0b_p2 I use:
./configure \
$(use java echo --jvm=yes --java=$(java-config --java)
- --javac=$(java-config --javac)) \
- --prefix=/usr \
# --bee=$(if use fullbee; then echo full; else echo partial; fi)
it would be a bit nicer if I could just write:
./configure \
$(_use java --jvm=yes --java=$(java-config --java) --javac=$(java-config
- --javac)) \
- --prefix=/usr \
# --bee=$(_use fullbee full partial)
In gambit I used:
econf $(if use static; then echo --disable-shared; else echo --enable-shared;
fi) \
could become:
econf $(_use static --disable-shared --enable-shared) \
The example from
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1
if use gnutls ; then
myconf=${myconf} --enable-ssl --with-ssl=gnutls
elif use ssl ; then
myconf=${myconf} --enable-ssl --with-ssl=openssl
else
myconf=${myconf} --disable-ssl
fi
econf \
# Other stuff
${myconf} \
|| die configure failed
could become:
econf \
# Other stuff
$(_use gnutls --enable-ssl --with-ssl=gnutls \
$(_use ssl --enable-ssl --with-ssl=openssl --disable-ssl)) \
|| die configure failed
which may require some getting used to.
These are just a few small examples. I'm sure there are much better examples,
perhaps the use_mime thingy, but more importantly perhaps there is nothing
that you cannot do with the new code that you could do with the old.
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKfNBp/VmCx0OL2wRAuvfAJ9LUmLZ4SAMrGzgtF53MjDd+kLuVACeIRFY
eb+8W/SVH2R23y3RZ43b5Hk=
=fHxw
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] use* cleanup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marijn Schouten (hkBst) wrote:
In gambit I used:
econf $(if use static; then echo --disable-shared; else echo --enable-shared;
fi) \
could become:
econf $(_use static --disable-shared --enable-shared) \
as zlin rightly pointed out on irc. That should really be $(use_enable !static
shared) so scrap this ``example``. Unfortunately my rewrite has a bug such
that it doesn't handle !blah correctly. Fixed version:
_use() {
local flag=$1
local string_success=$2
local string_failure=$3
local success=0
# invert the return value for !blah and strip the '!'
[[ ${flag} = !* ]] { success=1 ; flag=${flag:1} }
# Make sure we have this USE flag in IUSE
if ! hasq ${flag} ${IUSE} ${E_IUSE} ! hasq ${flag}
${PORTAGE_ARCHLIST} selinux; then
eqawarn QA Notice: USE Flag '${flag}' not in IUSE for
${CATEGORY}/${PF}
fi
hasq ${flag} ${USE} || ((success=1-success))
echo $(_if success ${string_success} ${string_failure})
return success
}
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKgT2p/VmCx0OL2wRAl5eAKCRpLUiH4k3l6bxmCIP7611FG4bIQCgpkeo
j+nSg9Dl4rAHX39rg08bWoY=
=isO1
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/deluge: ChangeLog deluge-0.5.6.2.ebuild deluge-0.5.6.1.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
On 15:38 Wed 31 Oct , Raul Porcel (armin76) wrote:
1.1 net-p2p/deluge/deluge-0.5.6.2.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-p2p/deluge/deluge-0.5.6.2.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-p2p/deluge/deluge-0.5.6.2.ebuild?rev=1.1content-type=text/plain
pkg_setup() {
if has_version dev-libs/boost-1.34 \
! built_with_use dev-libs/boost threads; then
eerror dev-libs/boost has to be built with threads USE-flag.
die Missing threads USE-flag for dev-libs/boost
fi
}
src_compile() {
filter-ldflags -Wl,--as-needed
distutils_src_compile
}
If you moved the filter-ldflags() call up to pkg_setup(), you could drop
src_compile() altogether to clean up the ebuild a little.
Wouldn't that make binary packages cry?
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKMiMp/VmCx0OL2wRAuCGAJ9WdFT5k7bGxZCEJOT0hiwjWZafpgCfYh5F
ONjgCrQ0Y8kf7HI/97YU4AU=
=tPfT
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] use* cleanup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Tuesday 30 October 2007, Marijn Schouten (hkBst) wrote:
The purpose of this patch is to expose a generic function, namely _use,
which can be used to build your own use* variant if you need that. I
reimplemented all other current use function using _use (and _if) to cut
out duplicate and verbose code. Comments expected. I didn't test this code.
i guess i dont really see it ... there isnt that much duplicate code to begin
with, and the end result is kind of hard to understand at first glance which
is a bad thing ...
-mike
I hope this is just an artifact of the patch being a bit opaque. The
inconsistent indentation in the patch is a consequence of emacs bash mode
using a different indentation style than (I guess) vi(m). I'm sure even in vi
you can re-indent my code with one simple key-chord.
The immediate motivation of my examining this code was a request on
#gentoo-dev-help by lack for something which I could with my new code easily
write like this:
use_mime() {
local WORD=$(_if $2 $2 $1)
_use $1 ${WORD};
}
This is possible because besides being shorter, my code is more general and
exposes utility functions to write your own use_* functions with.
The explanation of this function is:
#set WORD to argument 2 or if that is empty to argument 1
#output ${WORD}; if use flag $1 is set
I don't think it gets any clearer/directer/shorter than that. Other existing
functions that are trivial to re-implement:
use() {
_use ${1}
}
useq() {
_use ${1}
}
usev() {
_use ${1} ${1}
}
use_with() {
local SUFFIX=$(_if $3 =$3)
local WORD=$(_if $2 $2 $1)
_use $1 --with-${WORD}${SUFFIX} --without-${WORD}
}
use_enable() {
local SUFFIX=$(_if $3 =$3)
local WORD=$(_if $2 $2 $1)
_use $1 --enable-${WORD}${SUFFIX} --disable-${WORD}
}
All that is needed is:
_if() {
if $1; then echo $2; else echo $3; fi
}
and a function which is slightly extended from what is now useq to allow for
choosing to echo strings. Please excuse some line-wrapping.
_use() {
local flag=$1
local string_success=$2
local string_failure=$3
local found=0
# invert the return value for !blah and strip the '!'
[[ ${flag} = !* ]] { found=1 ; flag=${flag:1} }
# Make sure we have this USE flag in IUSE
if ! hasq ${flag} ${IUSE} ${E_IUSE} ! hasq ${flag}
${PORTAGE_ARCHLIST} selinux; then
eqawarn QA Notice: USE Flag '${flag}' not in IUSE for
${CATEGORY}/${PF}
fi
if hasq ${flag} ${USE} ; then
echo ${string_success}; return ${found}
else
echo ${string_failure}; return $((!found))
fi
}
What's not to like?
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKHQ6p/VmCx0OL2wRAl4dAJ4ilITOLQapD2NXCenw+YOYMPyOxwCgunjt
yKFi0LaXlEzAKQYnO2BS1SI=
=XQvd
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
[gentoo-portage-dev] src_test cleanup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The following patch was also on gentoo-dev before. It eliminates some dead
code paths from default src_test and in the process eliminates references to
FEATURES which is good for allowing ebuild.sh to be shared with other package
managers.
Marijn
diff -uw /usr/lib64/portage/bin/ebuild.sh ~/ebuild.sh
@@ -709,16 +666,10 @@
src_test() {
if emake -j1 check -n /dev/null; then
vecho Test phase [check]: ${CATEGORY}/${PF}
- - if ! emake -j1 check; then
- - hasq test $FEATURES die Make check failed. See
above for details.
- - hasq test $FEATURES || eerror Make check failed. See
above for details.
- - fi
+emake -j1 check || die Make check failed. See above for details.
elif emake -j1 test -n /dev/null; then
vecho Test phase [test]: ${CATEGORY}/${PF}
- - if ! emake -j1 test; then
- - hasq test $FEATURES die Make test failed. See
above for details.
- - hasq test $FEATURES || eerror Make test failed. See
above for details.
- - fi
+emake -j1 test || die Make test failed. See above for details.
else
vecho Test phase [none]: ${CATEGORY}/${PF}
fi
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHJ2usp/VmCx0OL2wRArFMAKC7kPj/i9pxUNOM3nsG99qzIFP9AQCfepvh
HmpExOB6pc4ZZFlxOFC3G1I=
=eboG
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
[gentoo-portage-dev] use* cleanup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The purpose of this patch is to expose a generic function, namely _use, which
can be used to build your own use* variant if you need that. I reimplemented
all other current use function using _use (and _if) to cut out duplicate and
verbose code. Comments expected. I didn't test this code.
Marijn
diff -uw /usr/lib64/portage/bin/ebuild.sh ~/ebuild.sh
@@ -150,40 +150,68 @@
return 0
}
- -use() {
- - useq ${1}
+_if() {
+$1 echo $2 || echo $3
}
- -usev() {
- - if useq ${1}; then
- - echo ${1}
- - return 0
- - fi
+# Fully generic conditional use flag function.
+# $1: calling function
+# $2: use flag to check
+# $3: string to echo on success
+# $4: string to echo on failure
+_use() {
+ if [[ $# = 1 ]]; then
+ echo !!! $1() called without a parameter. 2
+ echo !!! $1 USEFLAG [flagname [value]] 2
return 1
- -}
+ fi
- -useq() {
- - local u=$1
+ local flag=$2
+ local string_success=$3
+ local string_failure=$4
local found=0
- - # if we got something like '!flag', then invert the return value
- - if [[ ${u:0:1} == ! ]] ; then
- - u=${u:1}
- - found=1
- - fi
+# when $flag is '!blah', invert the return value and strip the '!' from
flag
+ [[ ${flag} = !* ]] { found=1 ; flag=${flag:1} }
# Make sure we have this USE flag in IUSE
- - if ! hasq ${u} ${IUSE} ${E_IUSE} ! hasq ${u}
${PORTAGE_ARCHLIST} selinux; then
- - eqawarn QA Notice: USE Flag '${u}' not in IUSE for
${CATEGORY}/${PF}
+ if ! hasq ${flag} ${IUSE} ${E_IUSE} ! hasq ${u}
${PORTAGE_ARCHLIST} selinux; then
+ eqawarn QA Notice: USE Flag '${flag}' not in IUSE for
${CATEGORY}/${PF}
fi
- - if hasq ${u} ${USE} ; then
- - return ${found}
+ if hasq ${flag} ${USE} ; then
+ echo ${string_success}; return ${found}
else
- - return $((!found))
+ echo ${string_failure}; return $((!found))
fi
}
+use() {
+ _use ${FUNCNAME[0]} ${1}
+}
+
+useq() {
+ _use ${FUNCNAME[0]} ${1}
+}
+
+usev() {
+_use ${FUNCNAME[0]} ${1} ${1}
+}
+
+use_with() {
+ local SUFFIX=$(_if [ -z $3 ] =$3)
+ local WORD=$(_if [ -z $2 ] $1 $2)
+
+ _use ${FUNCNAME[0]} $1 --with-${WORD}${SUFFIX} --without-${WORD}
+}
+
+use_enable() {
+ local SUFFIX=$(_if [ -z $3 ] =$3)
+ local WORD=$(_if [ -z $2 ] $1 $2)
+
+ _use ${FUNCNAME[0]} $1 --enable-${WORD}${SUFFIX} --disable-${WORD}
+}
+
has_version() {
if [ ${EBUILD_PHASE} == depend ]; then
die portageq calls (has_version calls portageq) are not
allowed in the global scope
@@ -227,56 +255,6 @@
${PORTAGE_BIN_PATH}/portageq 'best_version' ${ROOT} $1
}
- -use_with() {
- - if [ -z $1 ]; then
- - echo !!! use_with() called without a parameter. 2
- - echo !!! use_with USEFLAG [flagname [value]] 2
- - return 1
- - fi
- -
- - local UW_SUFFIX=
- - if [ ! -z ${3} ]; then
- - UW_SUFFIX==${3}
- - fi
- -
- - local UWORD=$2
- - if [ -z ${UWORD} ]; then
- - UWORD=$1
- - fi
- -
- - if useq $1; then
- - echo --with-${UWORD}${UW_SUFFIX}
- - else
- - echo --without-${UWORD}
- - fi
- - return 0
- -}
- -
- -use_enable() {
- - if [ -z $1 ]; then
- - echo !!! use_enable() called without a parameter. 2
- - echo !!! use_enable USEFLAG [flagname [value]] 2
- - return 1
- - fi
- -
- - local UE_SUFFIX=
- - if [ ! -z ${3} ]; then
- - UE_SUFFIX==${3}
- - fi
- -
- - local UWORD=$2
- - if [ -z ${UWORD} ]; then
- - UWORD=$1
- - fi
- -
- - if useq $1; then
- - echo --enable-${UWORD}${UE_SUFFIX}
- - else
- - echo --disable-${UWORD}
- - fi
- - return 0
- -}
- -
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHJ3jUp/VmCx0OL2wRAnduAJ9BkYDzf7ROLUeVVOQ4m5oVZ3TNoQCeIlQ9
9XN6WDbj4CtojnRX9Zc9ny8=
=4pj9
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] allowed in SRC_URI?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is the following syntax for SRC_URI allowed:
mips? ( mirror://sourceforge/sbcl/${PN}-${BV_MIPS}-$([[$(tc-endian) = big]]
echo mips || echo mipsel)-linux-binary.tar.bz2 )
It is supposed to be a replacement of:
mips? ( !cobalt? (
mirror://sourceforge/sbcl/${PN}-${BV_MIPS}-mips-linux-binary.tar.bz2 ) )
mips? ( cobalt? (
mirror://sourceforge/sbcl/${PN}-${BV_MIPSEL}-mipsel-linux-binary.tar.bz2 ) )
relevant tc-endian source:
tc-endian() {
local host=$1
[[ -z ${host} ]] host=${CTARGET:-${CHOST}}
host=${host%%-*}
case ${host} in
mips*l*)echo little;;
mips*) echo big;;
*) echo wtf;;
esac
}
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHIc3Fp/VmCx0OL2wRAq83AKCnHTVai8exLca9R50/7G2SHUgbMQCfSOQB
EmDPVakhM1vf5/AQXk8xtSk=
=B+0g
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
