[gentoo-dev] Last rites: dev-ruby/misen, dev-ruby/dpklib

2009-07-13 Thread Hans de Graaff
# Will be removed in 60 days. No release since 2003, deprecation
# of ruby features has caught up. If you want this to stay
# then please fix bug 276980.
dev-ruby/misen
dev-ruby/dpklib



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches

2009-07-13 Thread Zhang Le
On 15:53 Sun 12 Jul , Sebastian Pipping wrote:
 The output produces line like
 
   MISMATCH gentoo-china (layman-global) versus china (repo_name)
 

I have just changed gentoo-china overlay's repo_name to gentoo-china.

-- 
Zhang, Le
Gentoo/Loongson Developer
http://zhangle.is-a-geek.org
0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973


pgpohUiov0DfE.pgp
Description: PGP signature


[gentoo-dev] Last rites: 14 X input drivers

2009-07-13 Thread Rémi Cardona

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


More will probably come later, but this is the first round of 
low-hanging fruits.


Thanks

Rémi



Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches

2009-07-13 Thread Matthias Schwarzott
On Sonntag, 12. Juli 2009, Sebastian Pipping wrote:

 vdr-xine-overlay,  # vdr-xine

Fixed to be vdr-xine.

Zzam



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



[gentoo-dev] stacking profile.bashrc?

2009-07-13 Thread Michael Haubenwallner
Hi,

I'm facing this problem in Prefix on AIX, although it is a generic
problem IMO:

We do have post_src_install() hook in profiles/prefix/profile.bashrc to
drop charset.alias for packages != libiconv, required for non-glibc
platforms.

In profiles/prefix/aix/profiles.bashrc, there is another
post_src_install() hook with some aix specific hacks, required for
portage to allow for merging shared libraries there.

The problem now is that the latter post_src_install() overrides the
former, and I get collisions on charset.alias as the former is not
executed.

Is this a portage bug (each of them should be executed)?
Or is there some defined way to handle this I just was unable to find?

Thank you!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level




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: [gentoo-dev] Last rites: 14 X input drivers

2009-07-13 Thread Rémi Cardona

Le 13/07/2009 16:56, Marijn Schouten (hkBst) a écrit :

Why were they marked unsupported by upstream? Is there a replacement, are they
no longer needed, some other reason?


Some are now supported by the kernel. For the rest, nobody owns the 
hardware anymore. (ur98 is for a head-tracker... does anyone own that?)


All have in common that they've been broken (in portage) for many months 
and no-one noticed until Sabayon folks started doing tinderbox builds :)


If someone is sincerely impacted by this, please get in touch with 
upstream (CC me) because most of those drivers could come back to life 
with very little work. They mostly need someone testing them.


But as they stand now, I'm getting rid of them.

Cheers,

Rémi



[gentoo-dev] Re: Progress on Universal Select Tool

2009-07-13 Thread Sérgio Almeida
Hello,

Missed a weekly report, busy week. Will try to post 2 reports this week
as I am also working twice as much time.

Progress since last report:

* Converted all modules into plain python.
* uselect got even faster
* symlinking dependencies (ex: ruby and ruby-gems)
* several links per action (ex: bash-completion)

New module example:

# Python Module

from umodule import *

module = Module(name = python, description = Python Version
Switcher, version = 0.1, author =meph...@gmail.com) # We define the
module
bin = Action (name = 'bin', description = Change Python's Version,
type = sym) # Define a Symlinking Action

python = Link(alias = python, target = /usr/bin/python, prefix =
/usr/bin/, regexp = python([0-9]+\.[0-9]+$)) 
python_config = Link(alias = python-config, target =
/usr/bin/python-config, prefix = /usr/bin/, regexp =
python([0-9]+\.[0-9]+)-config$)


bin.add_link(python_config) # For inheritance
bin.add_link(python) # Adding The Link to the action
module.add_action(bin) #Adding the action to the module

# End

Only 1 module per file and modules are retrieved via the variable
module on each module. I couldn't find out a better way of doing this
but I'm sure there is one. Anyone?

This seems a bit messy but will be much easier to create support for
markup languages (I'm starting to love the idea of JSON).

This is a very good progress but brought a problem. Managing symlinking
dependencies (tree-like) became a huge headache. (Due to infinite
dependency capabilities). Suggestions are welcome in this part.

At this point I am creating a new way of managing several targets and
it's dependencies automatically in an indexed way either for easy
displaying and also for easy choosing. (No indexing is beeing done right
now, just plain object count)

I plan to start the profiling capabilities later this week.

Cheers,
Sérgio
-- 
Sérgio Almeida - meph...@gmail.com
mephx @ freenode



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Last rites: 14 X input drivers

2009-07-13 Thread Robert Buchholz
On Monday 13 July 2009, Rémi Cardona wrote:
 Le 13/07/2009 16:56, Marijn Schouten (hkBst) a écrit :
 All have in common that they've been broken (in portage) for many
 months and no-one noticed until Sabayon folks started doing tinderbox
 builds :)

We're using the x11-drivers/xf86-input-microtouch for a cash register. 
It works fine, but I think the machine is still on Xorg Server 1.3.

I don't have the capacity to maintain this driver myself, but it seems 
bug #276615 has a patch, so I wonder why it needs to be abandoned. Whom 
exactly shall I contact upstream about the deprecation?


Thanks,
Robert


signature.asc
Description: This is a digitally signed message part.