Re: [gentoo-dev] Python 3.1: Stabilization and news item

2010-03-26 Thread Marijn Schouten (hkBst)
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

2010-03-18 Thread Marijn Schouten (hkBst)
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?

2010-01-29 Thread Marijn Schouten (hkBst)
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

2009-12-28 Thread Marijn Schouten (hkBst)
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

2009-10-07 Thread Marijn Schouten (hkBst)
-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

2009-09-12 Thread Marijn Schouten (hkBst)
-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 ?)

2009-08-31 Thread Marijn Schouten (hkBst)
-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

2009-08-25 Thread Marijn Schouten (hkBst)
-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.)

2009-07-26 Thread Marijn Schouten (hkBst)
-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

2009-07-15 Thread Marijn Schouten (hkBst)
-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

2009-07-13 Thread Marijn Schouten (hkBst)
-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.

2009-07-13 Thread Marijn Schouten (hkBst)
-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

2009-07-13 Thread Marijn Schouten (hkBst)
-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

2009-06-18 Thread Marijn Schouten (hkBst)
-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

2009-06-17 Thread Marijn Schouten (hkBst)
-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

2009-06-03 Thread Marijn Schouten (hkBst)
-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

2009-06-03 Thread Marijn Schouten (hkBst)
-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)

2009-05-31 Thread Marijn Schouten (hkBst)
-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

2009-05-31 Thread Marijn Schouten (hkBst)
-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

2009-05-29 Thread Marijn Schouten (hkBst)
-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

2009-05-28 Thread Marijn Schouten (hkBst)
-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

2009-05-16 Thread Marijn Schouten (hkBst)
-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

2009-05-15 Thread Marijn Schouten (hkBst)
-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

2009-05-11 Thread Marijn Schouten (hkBst)
-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

2009-05-09 Thread Marijn Schouten (hkBst)
-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

2009-05-07 Thread Marijn Schouten (hkBst)
-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)

2009-04-14 Thread Marijn Schouten (hkBst)
-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

2009-04-11 Thread Marijn Schouten (hkBst)
-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

2009-03-30 Thread Marijn Schouten (hkBst)
-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}

2009-03-24 Thread Marijn Schouten (hkBst)
-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

2009-03-24 Thread Marijn Schouten (hkBst)
-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}

2009-03-24 Thread Marijn Schouten (hkBst)
-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

2009-03-23 Thread Marijn Schouten (hkBst)
-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

2009-03-16 Thread Marijn Schouten (hkBst)
-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

2009-03-12 Thread Marijn Schouten (hkBst)
-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

2009-03-12 Thread Marijn Schouten (hkBst)
-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

2009-03-09 Thread Marijn Schouten (hkBst)
-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?

2009-03-08 Thread Marijn Schouten (hkBst)
-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 )

2009-03-07 Thread Marijn Schouten (hkBst)
-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 )

2009-03-06 Thread Marijn Schouten (hkBst)
-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 )

2009-03-06 Thread Marijn Schouten (hkBst)
-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 )

2009-03-06 Thread Marijn Schouten (hkBst)
-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

2009-03-05 Thread Marijn Schouten (hkBst)
-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 )

2009-03-05 Thread Marijn Schouten (hkBst)
-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

2009-03-05 Thread Marijn Schouten (hkBst)
-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.

2009-03-03 Thread Marijn Schouten (hkBst)
-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 ?

2009-02-23 Thread Marijn Schouten (hkBst)
-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

2009-02-13 Thread Marijn Schouten (hkBst)
-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-portage-dev] equery: RFC and code review

2009-02-12 Thread Marijn Schouten (hkBst)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alec Warner wrote:
 On Tue, Feb 10, 2009 at 2:53 AM, Douglas Anderson d...@gendja.com wrote:
snip
 belongs.py has this gem:
 q.append(('^' if query[0] == '/' else '/') + re.escape(query) + '$')
 
 I realize it works; but honestly, not readable.
 
 append_str = 
 if query[0] == '/' append_str += '^' else append_str += '/'
 append_str += re.escape(query) + '$'
 q.append(append_str)
 
 Slightly better (if append_str has a shorter name, maybe).  I don't
 like 1 line if EXPR STATEMENT else STATEMENT but sometimes they are
 shorter
 Putting a conditional in the function call is horrible looking though.

It's called functional programming. Maybe it takes a little getting used to, but
as your own example shows, it can cut your code base by a significant factor.

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.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmUB54ACgkQp/VmCx0OL2wIOQCfdd0U1TJ/GXxTwvV8vmMpW2u9
hfsAoIXkWvJP8sOGK4NstuXiCAgy5OIf
=qfq4
-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

2009-02-02 Thread Marijn Schouten (hkBst)
-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 ?

2008-07-09 Thread Marijn Schouten (hkBst)
-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 ?

2008-07-08 Thread Marijn Schouten (hkBst)
-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

2008-07-06 Thread Marijn Schouten (hkBst)
-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

2008-07-04 Thread Marijn Schouten (hkBst)
-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

2008-07-03 Thread Marijn Schouten (hkBst)
-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

2008-06-29 Thread Marijn Schouten (hkBst)
-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

2008-06-29 Thread Marijn Schouten (hkBst)
-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

2008-06-29 Thread Marijn Schouten (hkBst)
-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

2008-06-29 Thread Marijn Schouten (hkBst)
-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

2008-06-28 Thread Marijn Schouten (hkBst)
-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

2008-06-18 Thread Marijn Schouten (hkBst)

-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)

2008-06-12 Thread Marijn Schouten (hkBst)

-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

2008-05-23 Thread Marijn Schouten (hkBst)

-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

2008-05-15 Thread Marijn Schouten (hkBst)

-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

2008-05-06 Thread Marijn Schouten (hkBst)

-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)

2008-04-30 Thread Marijn Schouten (hkBst)

-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

2008-04-21 Thread Marijn Schouten (hkBst)

-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

2008-04-19 Thread Marijn Schouten (hkBst)

-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?

2008-04-16 Thread Marijn Schouten (hkBst)

-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

2008-04-15 Thread Marijn Schouten (hkBst)

-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

2008-03-31 Thread Marijn Schouten (hkBst)

-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

2008-03-30 Thread Marijn Schouten (hkBst)

-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

2008-03-15 Thread Marijn Schouten (hkBst)

-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

2008-01-16 Thread Marijn Schouten (hkBst)

-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

2007-12-07 Thread Marijn Schouten (hkBst)
-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

2007-11-28 Thread Marijn Schouten (hkBst)
-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)

2007-11-16 Thread Marijn Schouten (hkBst)
-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

2007-11-14 Thread Marijn Schouten (hkBst)
-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

2007-11-12 Thread Marijn Schouten (hkBst)
-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))

2007-11-09 Thread Marijn Schouten (hkBst)
-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

2007-11-09 Thread Marijn Schouten (hkBst)
-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

2007-11-09 Thread Marijn Schouten (hkBst)
-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

2007-11-04 Thread Marijn Schouten (hkBst)
-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

2007-11-02 Thread Marijn Schouten (hkBst)
-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

2007-11-02 Thread Marijn Schouten (hkBst)
-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

2007-11-02 Thread Marijn Schouten (hkBst)
-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

2007-11-02 Thread Marijn Schouten (hkBst)
-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

2007-11-02 Thread Marijn Schouten (hkBst)
-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

2007-11-02 Thread Marijn Schouten (hkBst)
-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

2007-11-02 Thread Marijn Schouten (hkBst)
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

2007-11-02 Thread Marijn Schouten (hkBst)
-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

2007-11-02 Thread Marijn Schouten (hkBst)
-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

2007-11-02 Thread Marijn Schouten (hkBst)
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

2007-11-02 Thread Marijn Schouten (hkBst)
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

2007-11-01 Thread Marijn Schouten (hkBst)
-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

2007-11-01 Thread Marijn Schouten (hkBst)
-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

2007-10-31 Thread Marijn Schouten (hkBst)
-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

2007-10-31 Thread Marijn Schouten (hkBst)
-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

2007-10-30 Thread Marijn Schouten (hkBst)
-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

2007-10-30 Thread Marijn Schouten (hkBst)
-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



  1   2   >