[gentoo-dev] Re: headless herds

2009-03-23 Thread Ryan Hill
On Mon, 23 Mar 2009 06:55:48 +0100
Jeroen Roovers j...@gentoo.org wrote:

 On Sun, 22 Mar 2009 17:55:38 -0600
 Ryan Hill dirtye...@gentoo.org wrote:
 
  These herds have no members:
 
  ... 
 
  live-cd:
  app-admin/pwgen
  app-arch/pbzip2
  app-misc/livecd-tools
  dev-python/pyparted
  dev-util/catalyst
  media-gfx/splash-themes-livecd
  sys-apps/ddcxinfo-knoppix
  sys-apps/gli
  sys-apps/hwdata-gentoo
  sys-apps/hwsetup
  sys-apps/parted
  sys-fs/squashfs-tools
  sys-libs/libkudzu
  x11-misc/mkxf86config
  x11-themes/gdm-themes-livecd
  x11-themes/gentoo-artwork-livecd
 
 A trivial matter - I've added the four @gentoo.org maintainers from
 the livecd alias list to herds.xml.

Thanks!

-- 
gcc-porting,  by design, by neglect
treecleaner,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

2009-03-23 Thread Alin Năstac
On 3/23/09 1:42 AM, Ryan Hill wrote:
 On Mon, 23 Mar 2009 01:19:26 +0100
 Alin Năstac mrn...@gentoo.org wrote:

   
 Fine, then remove $PV from patch name and use it in any ebuild version
 you want. Or just decouple the patch version from the ebuild version
 (foo-bar-r1.patch sounds OK to me).
 

 No.  It's done this way for a reason.

   
I saw your reason about wanting to know the package version for which
the patch was created and I cannot see any reason for knowing that other
than submitting the patch to upstream.
Somehow I doubt upstream is interested in patches for version x.y.1 when
the current version is x.y.10.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

2009-03-23 Thread Alin Năstac
On 3/23/09 1:44 AM, Jeremy Olexa wrote:
 Alin Năstac wrote:
 snip
 Fine, then remove $PV from patch name and use it in any ebuild version
 you want. Or just decouple the patch version from the ebuild version
 (foo-bar-r1.patch sounds OK to me).


 What exactly is your problem that you are trying to solve here?
 Posting to the community to stop doing something without providing
 reasons to stop is not going to go anywhere. I like having the PV in
 the patch name..so, you haven't convinced me.

IMO prefixing a patch name with $P creates the perception that the patch
is used only from ebuild version $PV. Apparently we do not agree on this
so there is not much more I can tell to convince others.

I suppose what everyone does in their part of the tree is their
business, but a small subset of packages I maintain have other
maintainers as well. It is annoying to see rules you assume being
respected on your ebuilds being broken at every bump made by others.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Gentoo Council Reminder for March 26

2009-03-23 Thread Tiziano Müller
Am Sonntag, den 22.03.2009, 20:38 + schrieb Ciaran McCreesh:
 On Sun, 22 Mar 2009 21:18:52 +0100
 Donnie Berkholz dberkh...@gentoo.org wrote:
  If you have something you'd wish for us to chat about, maybe even vote
  on, let us know! Simply reply to this e-mail for the whole Gentoo dev
  list to see.
 
 Continuing the whole EAPI 3 thing...
 
 http://github.com/ciaranm/pms/tree/eapi-3 is a draft based upon
 ongoing discussion. There's more or less one commit per new feature. For
 each feature, I'd like to know:
 
 * whether there are any objections to that feature as a candidate for
   EAPI 3
 
 * what the plan is for Portage implementation of that feature, and the
   likelihood of it making it
I already started to implement small proposals for portage. For some
issues some minor structural/architectural have to be made.

 
 * whether that feature is considered critical for EAPI 3, or whether it
   can be dropped if necessary if Portage can't get it implemented
   within a certain time
 
 Also, I'd like to know of any potential omissions.
 
 I'd imagine this'd go easier of Council members went through before the
 meeting and provided individual opinions on each item, and then just
 discussed any disagreements during the meeting, but whatever's best for
 you...
 
 This list might help for those who're scared of git:
 
 1) EAPI 3 has pkg_pretend.
We have to write something here (probably not in PMS but in the
devmanual) to make clear what is allowed in pkg_pretend and what not.

 2) EAPI 3 supports slot operator dependencies
 3) EAPI 3 has use dependency defaults
 4) PROPERTIES, DEFINED_PHASES mandatory in EAPI 3
 5) EAPI 3 has a default src_install
Spec needed. DOCS or no DOCS?

 6) EAPI 3 has controllable compression and docompress
 7) EAPI 3 has dodoc -r
 8) EAPI 3 requires doins support for symlinks
Current behaviour is to copy the file the symlink points to, right?
Is that behaviour unsafe and should be deprecated completely or do we
add a flag turning on the new/the old behaviour?

 9) EAPI 3 bans || ( use? ( ... ) )
 10) dohard and dosed banned in EAPI 3
 11) doinclude, newinclude for EAPI 3
 12) EAPI 3 supports .xz, .tar.xz
 13) EAPI 3 has more econf arguments
 14) EAPI 3 supports pkg_info on installed packages
you probably mean: uninstalled

 15) USE is stricter in EAPI 3
Proper documentation for IUSE_IMPLICIT/USE_EXPAND_IMPLICIT is needed. In
the PMS draft there's only a reference to section 11.1.1, but in that
section is nothing about it.

 16) AA, KV gone in EAPI 3
 17) S to WORKDIR fallback conditional for EAPI 3
 18) EAPI 3 has unpack --if-compressed, new src_unpack
 19) RDEPEND=DEPEND gone in EAPI 3
 20) EAPI 3 has doexample.
Including -r or implicit recursive?

 21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3
Same thing as for 1)

 22) EAPI 3 has nonfatal, utilities die

... and we've got most (if not all) proposals with reasons documented
here:
  http://dev.gentoo.org/~dev-zero/docs/EAPI3.html

Cheers,
Tiziano



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


[gentoo-dev] newins - for standard input?

2009-03-23 Thread Ulrich Mueller
Now that dosed is going to be banned, what would people think of
newins (and the other new* commands) accepting - as the first
argument? I don't know how many usage cases there are, but the
following are obvious:

   sed 's/quux/quuux/' foo | newins - foo

It would allow for here documents:

   newins - bar -EOF
   # configuration file (for example)
   EOF

or even:

   newins - baz $'# a short\n# file'

Ulrich



[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

2009-03-23 Thread Ryan Hill
On Mon, 23 Mar 2009 09:04:32 +0100
Alin Năstac mrn...@gentoo.org wrote:

 I suppose what everyone does in their part of the tree is their
 business, but a small subset of packages I maintain have other
 maintainers as well. It is annoying to see rules you assume being
 respected on your ebuilds being broken at every bump made by others.

I'm sure they're just as annoyed by your bizarre take on patch version
numbering as you are with theirs. ;)


-- 
gcc-porting,  by design, by neglect
treecleaner,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature


[gentoo-dev] [RFC] git.eclass / subversion.eclass support for http proxy

2009-03-23 Thread Timothy Redaelli
Hi,
Some repositories has the git (or svn) and http support. I saw that we choose 
the git/svn one (it's faster i know, but it does not works under proxy).

I propose a E{GIT,SVN}_REPO_HTTP_URI (or similar) variable that uses the http 
variant when the global use is set (or we can use the http_proxy env 
variable).

What do you think?
-- 
Timothy `Drizzt` Redaelli
FreeSBIE Developer, Gentoo Developer, GUFI Staff
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.  -- Jeremy S. Anderson


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


Re: [gentoo-dev] newins - for standard input?

2009-03-23 Thread Tiziano Müller
Am Montag, den 23.03.2009, 09:22 +0100 schrieb Ulrich Mueller:
 Now that dosed is going to be banned, what would people think of
 newins (and the other new* commands) accepting - as the first
 argument? I don't know how many usage cases there are, but the
 following are obvious:
 
sed 's/quux/quuux/' foo | newins - foo
 
 It would allow for here documents:
 
newins - bar -EOF
# configuration file (for example)
EOF
 
 or even:
 
newins - baz $'# a short\n# file'
 

I like it :-)



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

2009-03-23 Thread Sebastian Pipping
Ryan Hill wrote:
 Alin Năstac mrn...@gentoo.org wrote:
 
 I suppose what everyone does in their part of the tree is their
 business, but a small subset of packages I maintain have other
 maintainers as well. It is annoying to see rules you assume being
 respected on your ebuilds being broken at every bump made by others.
 
 I'm sure they're just as annoyed by your bizarre take on patch version
 numbering as you are with theirs. ;)

Let me try summarizing and dissecting this issue.
Please correct and extend where necessary.


Bike shedding versus real issue

  - Issue itself might not be earth-shaking

  - Repeated frustration can become a problem

  - Frustration with this is present (me included)

  - Happy developers stay much longer


People split into three groups:

  - Friends of  ${P}-fix-issue.patch  naming

  - Friends of  ${PN}-fix-issue.patch  naming

  - Friends of  ${PN}-1.2.3-fix-issue.patch  naming


Qualities

  - ${P} i.e. ${PN}-${PV}
- On version bump either ..
  - Constant on version bump
  - Several same-content patch files across ebuilds
- .. or ..
  - Change to ${PN}-pre-bump-version
  - Single patch file across ebuilds
- Maybe helps reminding most patches should
  move from downstream to upstream?
- 1:1 patch-ebuild relation (see below)

  - ${PN}
- Constant on version bump
- Single patch file across ebuilds
- Several ebuilds need to be inspected
  to find out if a patch file is still used
- 1:1 patch-ebuild relation (see below)

  - ${PN}-1.2.3
- Constant on version bump
- Single patch file across ebuilds
- Several ebuilds need to be inspected
  to find out if a patch file is still used
- =${PV} values indicate things: either
  - the patch is downstream only
  - upstream has not applied it
- 1:n patch-ebuild relation
  (inverse qualities of 1:1 patch-ebuild
  relation, see below)


  - 1:1 patch-ebuild relation
- Finding out if a patch is still needed
  is trivial
- In-place patch updates possible without
  affecting other ebuilds
- 1:1 benefits only apply if ${P} is used
  consistently in the whole tree


Possible solutions

  - *Communicating* your likes to all co-maintainers
in hope the will respect and remember your agreement

  - Add a related local comment (*documenting*) to ebuilds
and expect other developers to act accordingly on a bump

  - Making a GLEP *enforcing* on of these and make people
vote on which



Sebastian



Re: [gentoo-dev] [RFC] git.eclass / subversion.eclass support for http proxy

2009-03-23 Thread Sebastian Pipping
Timothy Redaelli wrote:
 Hi,
 Some repositories has the git (or svn) and http support. I saw that we choose 
 the git/svn one (it's faster i know, but it does not works under proxy).
 
 I propose a E{GIT,SVN}_REPO_HTTP_URI (or similar) variable that uses the http 

Good idea.


 variant when the global use is set

Which one?


 (or we can use the http_proxy env 
 variable).

The use flag approach is
- less flexible and therefore worse for ebuild testing?
- more stable as stuff like env -i emerge ... gives
  the same results



Sebastian



Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

2009-03-23 Thread Fabian Groffen
On 23-03-2009 11:41:08 +0100, Sebastian Pipping wrote:
 People split into three groups:
 
   - Friends of  ${P}-fix-issue.patch  naming
   - Friends of  ${PN}-fix-issue.patch  naming
   - Friends of  ${PN}-1.2.3-fix-issue.patch  naming
 
 Qualities

[snip]

I think what's missing is the following observation:

${PN}-fix-issue.patch naming is bad if you patch code that is (likely)
to change in newer releases.  This is almost always the case.  Ultimate
example, patch something in ffmpeg or mplayer, and the next snapshot
will break the patch.  (i.e. doesn't apply any more.)  Using
${PN}-fix-issue.patch in this case gets you into
${PN}-fix-issue-2.patch, which IMO is ugly.

If patches are named this way, they probably fall in the case where the
code it patches is unlikely to change.  (assumption)

 Possible solutions
 
   - *Communicating* your likes to all co-maintainers
 in hope the will respect and remember your agreement
 
   - Add a related local comment (*documenting*) to ebuilds
 and expect other developers to act accordingly on a bump

probably best solution

   - Making a GLEP *enforcing* on of these and make people
 vote on which

very bad one.


-- 
Fabian Groffen
Gentoo on a different level



Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

2009-03-23 Thread Sebastian Pipping
Fabian Groffen wrote:
 I think what's missing is the following observation:
 
 ${PN}-fix-issue.patch naming is bad if you patch code that is (likely)
 to change in newer releases.  This is almost always the case.  Ultimate
 example, patch something in ffmpeg or mplayer, and the next snapshot
 will break the patch.  (i.e. doesn't apply any more.)  Using
 ${PN}-fix-issue.patch in this case gets you into
 ${PN}-fix-issue-2.patch, which IMO is ugly.
 
 If patches are named this way, they probably fall in the case where the
 code it patches is unlikely to change.  (assumption)

Good point.  In that case the patch revision 2 in
${PN}-fix-issue-2.patch actually stands for
${PN}-fix-issue-1.2.4.patch where 1.2.4 is the
version of the new package.  Therefor we effectively
${PV} from the begining to the end.

So a conlusion from this would be that ${PN} is not
suited for all ebuilds and therefore should not be
standard alone if at all?



Sebastian



Re: [gentoo-dev] Gentoo Council Reminder for March 26

2009-03-23 Thread Robert Buchholz
On Monday 23 March 2009, Tiziano Müller wrote:
 Spec needed. DOCS or no DOCS?

DOCS, and non-empty default value, please [1].
Some eclasses already do this (not base, but others), and if that 
default doesn't cover it for you, the function can be overridden.

Concerning the argument of declarative ebuilds vs. bash-oriented ebuilds 
brought up by Donnie: Our ebuilds always had declarative parts with an 
impact on the PM (e.g. RESTRICT), or on eclasses (WANT_AUTOCONF, or 
look at the games eclass).
I think if we stay within sane limits[2], following this paradigm is 
going to help developers because more simple cases will be caught by 
the default implementation without adding the complexities of having to 
know tons of (aka more than one) variables and how they interact.

Robert

[1] As seen here: https://bugs.gentoo.org/show_bug.cgi?id=33544#c17
[2] That is very fuzzy, but we're talking about introducing one variable
in one function. Any lower limit would be to disallow.


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


Re: [gentoo-dev] Re: EAPI roadmap

2009-03-23 Thread Thilo Bangert
Serkan Kaba ser...@gentoo.org said:
 Thilo Bangert yazmış:
  i doesnt make sense to introduce EAPI=2 into ebuilds, if we dont
  expect to have en EAPI=2 capable package manager stable within a
  reasonable timeframe.

 2.1.6 is stable and supports EAPI2

thats pretty cool. thanks...




Re: [gentoo-dev] [RFC] git.eclass / subversion.eclass support for http proxy

2009-03-23 Thread Nirbheek Chauhan
On Mon, Mar 23, 2009 at 3:33 PM, Timothy Redaelli dri...@gentoo.org wrote:
 Hi,
 Some repositories has the git (or svn) and http support. I saw that we choose
 the git/svn one (it's faster i know, but it does not works under proxy).

 I propose a E{GIT,SVN}_REPO_HTTP_URI (or similar) variable that uses the http
 variant when the global use is set (or we can use the http_proxy env
 variable).

 What do you think?

Here's what I did:

Install net-misc/connect
Save the script below and do `export GIT_PROXY_COMMAND=/path/to/script`
set http_proxy, and everything works dandy.

Maybe this can be done inside the eclass if http_proxy is set? :)



proxy=${http_proxy#http://}
host=${proxy...@}
auth=${pro...@*}
if test ${auth} != ${proxy}; then
export HTTP_PROXY_USER=${auth%%:*}
export HTTP_PROXY_PASSWORD=${auth##*:}
fi
connect -H ${host} $1 $2




-- 
~Nirbheek Chauhan



Re: [gentoo-dev] newins - for standard input?

2009-03-23 Thread Nirbheek Chauhan
On Mon, Mar 23, 2009 at 1:52 PM, Ulrich Mueller u...@gentoo.org wrote:
 Now that dosed is going to be banned, what would people think of

I wouldn't call it banned, rather useless since everyone directly
uses sed instead.


-- 
~Nirbheek Chauhan



[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] [RFC] git.eclass / subversion.eclass support for http proxy

2009-03-23 Thread Timothy Redaelli
On Monday 23 March 2009 12:45:55 Nirbheek Chauhan wrote:
 On Mon, Mar 23, 2009 at 3:33 PM, Timothy Redaelli dri...@gentoo.org wrote:
  Hi,
  Some repositories has the git (or svn) and http support. I saw that we
  choose the git/svn one (it's faster i know, but it does not works under
  proxy).
 
  I propose a E{GIT,SVN}_REPO_HTTP_URI (or similar) variable that uses the
  http variant when the global use is set (or we can use the http_proxy env
  variable).
 
  What do you think?

 Here's what I did:

 Install net-misc/connect
 Save the script below and do `export GIT_PROXY_COMMAND=/path/to/script`
 set http_proxy, and everything works dandy.

 Maybe this can be done inside the eclass if http_proxy is set? :)

 

 proxy=${http_proxy#http://}
 host=${proxy...@}
 auth=${pro...@*}
 if test ${auth} != ${proxy}; then
 export HTTP_PROXY_USER=${auth%%:*}
 export HTTP_PROXY_PASSWORD=${auth##*:}
 fi
 connect -H ${host} $1 $2

Some environments has squid with CONNECT filtered only to a few known ports :(

-- 
Timothy `Drizzt` Redaelli
FreeSBIE Developer, Gentoo Developer, GUFI Staff
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.  -- Jeremy S. Anderson



Re: [gentoo-dev] Packages up for grabs

2009-03-23 Thread Peter Alfredsen
On Mon, 23 Mar 2009 11:26:06 -0100
Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote:

[...]
 Saleem Abdulrasool (compnerd)
[...]
 dev-dotnet/dbus-glib-sharp
 dev-dotnet/dbus-sharp
[...]
Snatched



Re: [gentoo-dev] Packages up for grabs

2009-03-23 Thread Ricardo Mendoza
2009/3/24 Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org:

 Hi.

 Following this month processing of the retirement batch, the following
 packages have been reassigned to maintainer-needed and can take some
 love. You know the drill, so if you want to maintain any of them please
 add yourself to the metadata.xml.

 Aggelos Orfanakos (agorf)
 dev-util/scanmem
 net-misc/metacafe-dl
 net-misc/youtube-dl

 Anant Narayanan (anant)
 app-doc/doc++
 dev-util/plan9port

 Saleem Abdulrasool (compnerd)
 app-editors/leafpad
 app-emulation/spim
 dev-dotnet/dbus-glib-sharp
 dev-dotnet/dbus-sharp
 dev-libs/gdl
 gnome-extra/gsynaptics
 sys-auth/nss-mdns
 x11-themes/gtk-engines-rezlooks

 Fernando J. Pereda (ferdy)
 app-i18n/man-pages-es
 dev-util/bouml
 dev-util/cogito
 dev-util/stgit

 Ali Polatel (hawking)
 app-admin/tmpreaper
 app-admin/xtail
 app-misc/pwsafe
 app-misc/screenie
 dev-libs/libtomcrypt
 dev-libs/libtomfloat
 dev-libs/libtommath
 dev-libs/libtompoly
 dev-libs/shhopt
 dev-libs/tomsfastmath
 dev-util/ccmalloc
 dev-util/cook
 dev-util/pmk
 dev-util/pretrace
 net-irc/bip
 net-misc/knock
 net-misc/sslwrap
 net-misc/unix2tcp

I'll take the following:

app-emulation/spim
dev-util/scanmem
net-misc/metacafe-dl
net-misc/youtube-dl


 Ricardo



Re: [gentoo-dev] Packages up for grabs

2009-03-23 Thread Gilles Dartiguelongue
Le lundi 23 mars 2009 à 11:26 -0100, Jorge Manuel B. S. Vicetto a
écrit :
 dev-libs/gdl
 gnome-extra/gsynaptics

will be taken by gnome.
  * gdl will die soonish because it's been integrated in anjuta
proper iirc.
  * gsynaptics will die soonish anyway due to xorg-server 1.6 and
xinput-2.

 sys-auth/nss-mdns

unless it goes to base-system or someone else that has more time, I'll
take care of it.

-- 
Gilles Dartiguelongue e...@gentoo.org
Gentoo




[gentoo-dev] [undertakers] Packages with updated metadata.xml

2009-03-23 Thread Jorge Manuel B. S. Vicetto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

Following this month processing of the retirement batch, the following
packages had their metadata.xml updated to remove all maintainers that
were retired.
If you are a maintainer or a member of a herd listed in these packages,
you may want to review the updates.

Aggelos Orfanakos (agorf)
app-vim/vim-spell-el
dev-ruby/coderay
dev-ruby/exifr
dev-ruby/png
dev-util/fuzz
media-video/luvcview

Anant Narayanan (anant)
dev-lang/dmd-bin
dev-php5/magickwand
dev-php5/php-gtk
net-analyzer/nam
net-analyzer/ns
sci-misc/apertium
sci-misc/lttoolbox
sys-devel/gcc

Saleem Abdulrasool (compnerd)
app-crypt/seahorse
app-shells/zsh-completion
dev-dotnet/galago-sharp
dev-dotnet/nini
dev-dotnet/pe-format
dev-util/glade
gnome-extra/gnome-screensaver
gnome-extra/nautilus-open-terminal
gnome-extra/policykit-gnome
net-fs/shfs

Fernando J. Pereda (ferdy)
app-doc/repodoc
app-vim/vim-spell-es
dev-util/git
dev-util/qgit
mail-client/mutt
mail-filter/maildrop
mail-mta/nbsmtp
net-mail/mailer-config
www-apps/gitweb
sys-apps/paludis

Ali Polatel (hawking)
app-admin/eselect-python
app-admin/sshguard
dev-python/cython
dev-python/mechanize
dev-python/optcomplete
dev-python/pp
dev-python/pylint
dev-python/pyparsing
dev-util/buildbot
dev-util/bzr
dev-util/bzrtools
sys-auth/pam_blue
sys-auth/pam_chroot

Joshua Ross (joslwah)
app-text/xdvipdfmx
app-text/xetex
media-fonts/sil-abyssinica
media-fonts/sil-arabicfonts
media-fonts/sil-charis
media-fonts/sil-doulos
media-fonts/sil-galatia
media-fonts/sil-padauk

Joshua Nichols (nichoj)
dev-java/jruby

The following list includes packages with maintainers that have scaled
back to Staff role and thus have no longer gentoo-x86 access.

Renat Lumpau (rl03)
www-apps/otrs
www-apps/rt

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknHjm0ACgkQcAWygvVEyAIY3ACeMxfS/dTpbFPZXqc+kCJINV4U
K1AAn0PAiY/HYMPhXk/MBvTKQ27nS/8N
=yud2
-END PGP SIGNATURE-



Re: [gentoo-dev] newins - for standard input?

2009-03-23 Thread Ciaran McCreesh
On Mon, 23 Mar 2009 09:22:06 +0100
Ulrich Mueller u...@gentoo.org wrote:
 Now that dosed is going to be banned, what would people think of
 newins (and the other new* commands) accepting - as the first
 argument?

There's a slightly different variation in exheres-0: as well as do* and
new*, there's also here*, which you use like this:

hereins foo 'END'
stuff
END

It magically barfs, rather than hanging indefinitely, if you forget to
give it some input.

The rationale for giving it a new name rather than overloading an
existing one is that some of the existing do* utilities don't take just
a single simple filename, so overloading would make the command line
somewhat convoluted.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] updating baselayout PERMS_PROTECT

2009-03-23 Thread Ciaran McCreesh
On Sun, 22 Mar 2009 23:53:23 -0400
Caleb Cushing xenoterrac...@gmail.com wrote:
 of course this leads to the problem... what if the 'admin' explicitly
 changed the permissions... Maybe we should have something like
 PERMS_PROTECT (similar to config_protect). where portage won't update
 the permissions if file/directory is protected.

The package manager shouldn't be messing with permissions on existing
directories at all (directories are a shared resource). If you want to
change permissions on an existing directory, do it in pkg_preinst.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2009-03-23 Thread Alex Legler
On Mo, 2009-03-23 at 11:26 -0100, Jorge Manuel B. S. Vicetto wrote:
 [...]
 Ali Polatel (hawking)
 [...]
 net-irc/bip

Shamelessly stole that one.

Gracias,
Alex


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


Re: [gentoo-dev] newins - for standard input?

2009-03-23 Thread Ulrich Mueller
 On Mon, 23 Mar 2009, Ciaran McCreesh wrote:

 Now that dosed is going to be banned, what would people think of
 newins (and the other new* commands) accepting - as the first
 argument?

 There's a slightly different variation in exheres-0: as well as do*
 and new*, there's also here*, which you use like this:

 hereins foo 'END'
 stuff
 END

Why would we need a new command for this? The minus sign denoting
standard input is fairly common with other utilities.

 It magically barfs, rather than hanging indefinitely, if you forget
 to give it some input.

I guess the same could be done for newins -, if you think that it is
necessary (test for stdin being a terminal?). But I don't really see
the point of it, since such a mistake would be noticed immediately
when testing the ebuild.

 The rationale for giving it a new name rather than overloading an
 existing one is that some of the existing do* utilities don't take
 just a single simple filename, so overloading would make the command
 line somewhat convoluted.

It doesn't make much sense to specify - as an argument for do*,
because the command would not know under which name the file should be
installed. OTOH, all new* commands have exactly two arguments, so we
could allow - for the first argument.

Ulrich



Re: [gentoo-dev] newins - for standard input?

2009-03-23 Thread Timothy Redaelli
On Monday 23 March 2009 09:22:06 Ulrich Mueller wrote:
 Now that dosed is going to be banned, what would people think of
 newins (and the other new* commands) accepting - as the first
 argument? I don't know how many usage cases there are, but the
 following are obvious:

sed 's/quux/quuux/' foo | newins - foo

 It would allow for here documents:

newins - bar -EOF
# configuration file (for example)
EOF

 or even:

newins - baz $'# a short\n# file'

Why can't you use newins /dev/stdin foo that it works out of the box?

-- 
Timothy `Drizzt` Redaelli
FreeSBIE Developer, Gentoo Developer, GUFI Staff
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.  -- Jeremy S. Anderson


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


Re: [gentoo-dev] newins - for standard input?

2009-03-23 Thread Michael Haubenwallner
On Mon, 2009-03-23 at 17:11 +0100, Timothy Redaelli wrote:
 On Monday 23 March 2009 09:22:06 Ulrich Mueller wrote:

 
 newins - baz $'# a short\n# file'
 
 Why can't you use newins /dev/stdin foo that it works out of the box?

Nope, /dev/stdin isn't portable.

While Linux and Solaris have it, AIX and HP-UX do not
provide /dev/stdin. Unsure about Interix and MacOSX.

Using '-' sounds familiar for me too.

/haubi/




[gentoo-dev] Re: Last rites: dev-lang/pugs

2009-03-23 Thread Torsten Veller
* 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?

http://search.cpan.org/dist/Perl6-Pugs/
http://bbbike.radzeit.de/~slaven/cpantestersmatrix.cgi?dist=Perl6-Pugs+6.2.13
http://www.cpantesters.org/show/Perl6-Pugs.html#Perl6-Pugs-6.2.13



Re: [gentoo-dev] newins - for standard input?

2009-03-23 Thread Alec Warner
On Mon, Mar 23, 2009 at 8:41 AM, Ulrich Mueller u...@gentoo.org wrote:
 On Mon, 23 Mar 2009, Ciaran McCreesh wrote:

 Now that dosed is going to be banned, what would people think of
 newins (and the other new* commands) accepting - as the first
 argument?

 There's a slightly different variation in exheres-0: as well as do*
 and new*, there's also here*, which you use like this:

 hereins foo 'END'
 stuff
 END

 Why would we need a new command for this? The minus sign denoting
 standard input is fairly common with other utilities.

 It magically barfs, rather than hanging indefinitely, if you forget
 to give it some input.

 I guess the same could be done for newins -, if you think that it is
 necessary (test for stdin being a terminal?). But I don't really see
 the point of it, since such a mistake would be noticed immediately
 when testing the ebuild.

No, they aren't 'noticed immediately'.  The ebuild hangs and then the
author spends 10 minutes trying to figure out why.  If its trivial to
implement..I don't see a downside to such a feature.


 The rationale for giving it a new name rather than overloading an
 existing one is that some of the existing do* utilities don't take
 just a single simple filename, so overloading would make the command
 line somewhat convoluted.

 It doesn't make much sense to specify - as an argument for do*,
 because the command would not know under which name the file should be
 installed. OTOH, all new* commands have exactly two arguments, so we
 could allow - for the first argument.

 Ulrich





Re: [gentoo-dev] [undertakers] Packages with updated metadata.xml

2009-03-23 Thread Hans de Graaff
On Mon, 2009-03-23 at 12:28 -0100, Jorge Manuel B. S. Vicetto wrote:

 dev-ruby/coderay
 dev-ruby/exifr
 dev-ruby/png

The ruby herd will take these.

Kind regards,

Hans


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


[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

2009-03-23 Thread Ryan Hill
On Mon, 23 Mar 2009 11:51:28 +0100
Fabian Groffen grob...@gentoo.org wrote:

 On 23-03-2009 11:41:08 +0100, Sebastian Pipping wrote:
  People split into three groups:
  
- Friends of  ${P}-fix-issue.patch  naming
- Friends of  ${PN}-fix-issue.patch  naming
- Friends of  ${PN}-1.2.3-fix-issue.patch  naming
  
  Qualities
 
 [snip]
 
 I think what's missing is the following observation:
 
 ${PN}-fix-issue.patch naming is bad if you patch code that is (likely)
 to change in newer releases.  This is almost always the case.
 Ultimate example, patch something in ffmpeg or mplayer, and the next
 snapshot will break the patch.  (i.e. doesn't apply any more.)  Using
 ${PN}-fix-issue.patch in this case gets you into
 ${PN}-fix-issue-2.patch, which IMO is ugly.
 
 If patches are named this way, they probably fall in the case where
 the code it patches is unlikely to change.  (assumption)
 
  Possible solutions
  
- *Communicating* your likes to all co-maintainers
  in hope the will respect and remember your agreement
  
- Add a related local comment (*documenting*) to ebuilds
  and expect other developers to act accordingly on a bump
 
 probably best solution
 
- Making a GLEP *enforcing* on of these and make people
  vote on which
 
 very bad one.
 
 

Thanks for this.  And apologies to Alin.  I was in a very bad mood
yesterday.


-- 
gcc-porting,  by design, by neglect
treecleaner,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature


Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

2009-03-23 Thread Tomáš Chvátal
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).

Please dont mind the warnings on the file, it is my first glep :] And if you 
know how to fix them source is out there too [2]. ;]

[1] - http://dev.gentoo.org/~scarabeus/patches-glep.html
[2] - http://dev.gentoo.org/~scarabeus/patches-glep.txt

Cheers,
Tomas


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


[gentoo-dev] Packages up for grabs: genstef gems special edition

2009-03-23 Thread Peter Alfredsen
Since genstef has been .away for some time, I arranged with him that I'd
send a list of his ebuilds that need maintenance to be put up for grabs.
This list contains all ebuilds that have no herd, at least one open bug
and where genstef is the maintainer.

media-video/linux-uvc
media-video/isight-firmware-tools
media-video/kavi2svcd
sys-fs/dmraid
dev-libs/liblazy
net-misc/vde
sys-apps/ivman
media-gfx/picasa
app-portage/getdelta
x11-themes/gtk-engines-qt
x11-misc/googleearth

And the grand prize:
x11-libs/agg
net-www/gnash
Which go together. I think gnash is agg's only consumer.

Please also note that genstef's .away is currently set to:
Feel free to fix or take over any of my packages @ 2009/03/23 21:21Z
So any other packages of genstef's are also up for the taking.

/loki_val



Re: [gentoo-dev] Packages up for grabs: genstef gems special edition

2009-03-23 Thread Markos Chandras
On Tuesday 24 March 2009 00:08:53 Peter Alfredsen wrote:
 Since genstef has been .away for some time, I arranged with him that I'd
 send a list of his ebuilds that need maintenance to be put up for grabs.
 This list contains all ebuilds that have no herd, at least one open bug
 and where genstef is the maintainer.
[..]
 Please also note that genstef's .away is currently set to:
 Feel free to fix or take over any of my packages @ 2009/03/23 21:21Z
 So any other packages of genstef's are also up for the taking.

 /loki_val

Also media-sound/lastfmplayer is another package that has genstef as a 
maintainer. I am willing to take care of it if that's ok. It belongs to 
sound herd anyway :)

Thanks
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
KDE/Qt/Sunrise/Sound
Web: http://hwoarang.silverarrow.gr


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


Re: [gentoo-dev] Packages up for grabs: genstef gems special edition

2009-03-23 Thread Gilles Dartiguelongue
Le lundi 23 mars 2009 à 23:08 +0100, Peter Alfredsen a écrit :
 Since genstef has been .away for some time, I arranged with him that I'd
 send a list of his ebuilds that need maintenance to be put up for grabs.
 This list contains all ebuilds that have no herd, at least one open bug
 and where genstef is the maintainer.

 media-video/isight-firmware-tools

I haven't had much time outside of gnome stuff but I still work on this
as time permits. Any help would of course be appreciated.

-- 
Gilles Dartiguelongue e...@gentoo.org
Gentoo


signature.asc
Description: Ceci est une partie de message numériquement signée


Re: [gentoo-portage-dev] prefix portage chaining

2009-03-23 Thread Markus Duft
On Mon, 2009-03-23 at 08:27 +0100, Markus Duft wrote:
 On Fri, 2009-03-20 at 12:11 +0100, Markus Duft wrote:
  On Fri, 2009-03-20 at 11:35 +0100, Markus Duft wrote:
   Hey guys :)
   
   Just wanted to stop by and get some opinions on a patch i wrote for the
   prefix branch.
  
 [snip]
 
 Hey there. Seemingly nobody has any comments on this..? :) here's a
 working version of the patch. i realized that the last one worked only
 by accident :) maybe now, some comments (or questions)?

i'm eager to find out how many times i can forget to attach the patch :)

sorry for the noise

Cheers, Markus

 
 Thanks, Cheers, Markus
 
 [snip]
   
   Waiting for comments, suggestions, etc.
   
   Thanks in advance,
   Cheers, Markus
   
   
 
 
diff -ru portage.orig/pym/_emerge/__init__.py portage/pym/_emerge/__init__.py
--- portage.orig/pym/_emerge/__init__.py	2009-03-18 10:13:34.0 +0100
+++ portage/pym/_emerge/__init__.py	2009-03-23 08:46:59.0 +0100
@@ -49,7 +49,7 @@
 import portage.xpak, commands, errno, re, socket, time
 from portage.output import blue, bold, colorize, darkblue, darkgreen, darkred, green, \
 	nc_len, red, teal, turquoise, xtermTitle, \
-	xtermTitleReset, yellow
+	xtermTitleReset, yellow, purple
 from portage.output import create_color_func
 good = create_color_func(GOOD)
 bad = create_color_func(BAD)
@@ -69,6 +69,7 @@
 from portage.util import cmp_sort_key, writemsg, writemsg_level
 from portage.sets import load_default_config, SETPREFIX
 from portage.sets.base import InternalPackageSet
+from portage.dbapi.vartree import vartree
 
 from itertools import chain, izip
 
@@ -4692,6 +4693,7 @@
 		self._unsatisfied_deps_for_display = []
 		self._unsatisfied_blockers_for_display = None
 		self._circular_deps_for_display = None
+		self._injected_readonly_deps_for_display = []
 		self._dep_stack = []
 		self._unsatisfied_deps = []
 		self._initially_unsatisfied_deps = []
@@ -5270,18 +5272,35 @@
 		if removal_action and self.myopts.get(--with-bdeps, y) == n:
 			edepend[DEPEND] = 
 
+		# MDUFT: create additional vartrees for every readonly root here
+		# (maybe FakeVartree's?). Then below search those trees and set
+		# mypriority.satisfied to True.
+		# the ro_vartrees instances are created below as they are needed to
+		# avoid reading vartrees of portage instances which aren't required
+		# while resolving this dependencies.
+		ro_trees = {}
+		ro_vartrees = {}
+		
+		for type in (DEPEND,RDEPEND, PDEPEND):
+			ro_trees[type] = []
+			
+			for ro_root, ro_dep_types in self.settings.readonly_roots.items():
+if type in ro_dep_types:
+	ro_trees[type].append(ro_root)
+
 		deps = (
-			(/, edepend[DEPEND],
+			(/, DEPEND,
 self._priority(buildtime=(not bdeps_optional),
 optional=bdeps_optional)),
-			(myroot, edepend[RDEPEND], self._priority(runtime=True)),
-			(myroot, edepend[PDEPEND], self._priority(runtime_post=True))
+			(myroot, RDEPEND, self._priority(runtime=True)),
+			(myroot, PDEPEND, self._priority(runtime_post=True))
 		)
 
 		debug = --debug in self.myopts
 		strict = mytype != installed
 		try:
-			for dep_root, dep_string, dep_priority in deps:
+			for dep_root, dep_type, dep_priority in deps:
+dep_string = edepend[dep_type]
 if not dep_string:
 	continue
 if debug:
@@ -5309,6 +5328,43 @@
 		if not atom.blocker and vardb.match(atom):
 			mypriority.satisfied = True
 
+		# MDUFT: How erver we do it - if we find atom beeing installed
+		# in a valid readonly root for the current dependency type, then
+		# _DONT_ call the below, but rather return 1 immediately.
+		ro_matched = False
+		for ro_root in ro_trees[dep_type]:
+			if not ro_vartrees.has_key(ro_root):
+# target_root=ro_root ok? or should it be the real target_root?
+_tmp_settings = portage.config(config_root=ro_root, target_root=ro_root,
+	config_incrementals=portage.const.INCREMENTALS)
+#_tmp_trees = portage.util.LazyItemsDict()
+#_tmp_trees.addLazySingleton(vartree, vartree, ro_root,
+#	categories=_tmp_settings.categories, settings=_tmp_settings)
+
+#setconfig = load_default_config(_tmp_trees[vartree].settings, _tmp_trees)
+#ro_vartrees[ro_root] = FakeVartree(RootConfig(_tmp_trees[vartree].settings,
+#	_tmp_trees, setconfig), acquire_lock=0)
+
+ro_vartrees[ro_root] = vartree(root=ro_root, categories=_tmp_settings.categories, 
+	settings=_tmp_settings, kill_eprefix=True)
+	
+			ro_matches = ro_vartrees[ro_root].dbapi.match(atom)
+			
+			if ro_matches:
+if dep_type is RDEPEND:
+	# we need to assure binary compatability, so it needs to be
+	# the same CHOST! But how? for now i cannot do anything...
+	pass
+
+# injected dep for display. those get shown with the merge list.
+self._injected_readonly_deps_for_display.append({ro_root : ro_root, atom : atom, 
+	matches: ro_matches, type: