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

[Ulrich Mueller]

> On Mon, 23 Mar 2009, Tiziano Müller wrote:

>> what would people think of "newins" (and the other "new*" commands)
>> accepting "-" as the first argument?

> I like it :-)

Bug 263565 now.

Ulrich

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

[Tiziano Müller]

Am Montag, den 23.03.2009, 23:08 +0100 schrieb 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
I'd have the hardware for that one if nobody else takes it.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

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


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

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

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

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

[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] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

[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] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

[Ryan Hill]

On Mon, 23 Mar 2009 11:51:28 +0100
Fabian Groffen  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] [undertakers] Packages with updated metadata.xml

[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

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

[Alec Warner]

On Mon, Mar 23, 2009 at 8:41 AM, Ulrich Mueller  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
>
>

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

[Torsten Veller]

* "Marijn Schouten (hkBst)" :
> 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?

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

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

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

[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] Packages up for grabs

[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] updating baselayout PERMS_PROTECT

[Ciaran McCreesh]

On Sun, 22 Mar 2009 23:53:23 -0400
Caleb Cushing  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] newins "-" for standard input?

[Ciaran McCreesh]

On Mon, 23 Mar 2009 09:22:06 +0100
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?

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

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

[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] Packages up for grabs

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

Re: [gentoo-dev] Packages up for grabs

[Ricardo Mendoza]

2009/3/24 Jorge Manuel B. S. Vicetto :

> 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

[Peter Alfredsen]

On Mon, 23 Mar 2009 11:26:06 -0100
"Jorge Manuel B. S. Vicetto"  wrote:

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

[gentoo-dev] Packages up for grabs

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

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

iEYEARECAAYFAknHf90ACgkQcAWygvVEyALDiQCgh677f6ygsdZrMrGg8mB58r0g
BJYAn1IRuFuxifmV2kvN4+3pkkIzDmVy
=wNc4
-END PGP SIGNATURE-

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

[Timothy Redaelli]

On Monday 23 March 2009 12:45:55 Nirbheek Chauhan wrote:
> On Mon, Mar 23, 2009 at 3:33 PM, 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 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

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

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

[Nirbheek Chauhan]

On Mon, Mar 23, 2009 at 3:33 PM, 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
> 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] Re: EAPI roadmap

[Thilo Bangert]

Serkan Kaba  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] newins "-" for standard input?

[Nirbheek Chauhan]

On Mon, Mar 23, 2009 at 1:52 PM, Ulrich Mueller  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

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

[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: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

[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] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

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

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

[Sebastian Pipping]

Ryan Hill wrote:
> Alin Năstac  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}-
  - 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

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

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

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

[Ryan Hill]

On Mon, 23 Mar 2009 09:04:32 +0100
Alin Năstac  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

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

[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

[gentoo-dev] newins "-" for standard input?

[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

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

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

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

[Alin Năstac]

On 3/23/09 1:44 AM, Jeremy Olexa wrote:
> Alin Năstac 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).
>>
>
> 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] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

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

[gentoo-dev] Re: headless herds

[Ryan Hill]

On Mon, 23 Mar 2009 06:55:48 +0100
Jeroen Roovers  wrote:

> On Sun, 22 Mar 2009 17:55:38 -0600
> Ryan Hill  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