[gentoo-dev] USE flag transition: tetex and latex

2007-10-31 Thread Christian Faulhammer
Hi, What are we going to do with the global tetex USE flag? app-text/tetex is deprecated in favour of TeXLive which is still hard masked but will be the default TeX distribution in the future. Rename it to tex as TeXLive is based on teTeX? And what about USE=latex? Use a generic tex for it,

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-admin/webmin: ChangeLog webmin-1.370-r1.ebuild

2007-10-31 Thread Roy Marples
On Tue, 2007-10-30 at 22:46 -0700, Donnie Berkholz wrote: On 10:36 Tue 30 Oct , Roy Marples (uberlord) wrote: 1.1 app-admin/webmin/webmin-1.370-r1.ebuild file :

Re: [gentoo-dev] USE flag transition: tetex and latex

2007-10-31 Thread Alexis Ballier
Hi, What are we going to do with the global tetex USE flag? app-text/tetex is deprecated in favour of TeXLive which is still hard masked but will be the default TeX distribution in the future. Rename it to tex as TeXLive is based on teTeX? And what about USE=latex? Use a generic tex for it,

Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Daniel Drake
Robin H. Johnson wrote: Heya, So now this is not a flamewar. Jakub was originally going to complain at me for the upstream usbutils adding support for gzipped usb.ids files, but a group of us (myself, dsd, jakub, leio, steev) had a discussion about it, and came up with a solution that both

[gentoo-dev] Re: Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Guilherme Amadio
Hi guys, I totally agree with the patch sent by Daniel in the previous message. I think it clarifies to the user (me, for example), why it's not possible to build pciutils with the zlib USE flag. This is just my humble opinion, though, as a user. And sorry to a bit off this thread, but I

Re: [gentoo-dev] Re: Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Jan Kundrát
Guilherme Amadio wrote: And sorry to a bit off this thread, but I also would like to help with some translations of official docs and development. I've been using Gentoo since 1.4, but never really had time to help. Now I feel I'll have more time and, if you can point me to some Brazilian

[gentoo-dev] Re: Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Ryan Hill
Daniel Drake wrote: + if [[ ! -e ${ROOT}/usr/share/misc/pci.ids ]]; then + myconf=--disable-pci-ids - don't use ${ROOT} outside of pkg_* - en/disabling functionality based on existence of files is kinda gross, especially when based on what exists on the compiling system,

Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Wulf C. Krueger
Hello Daniel! I don't feel strongly enough to make an objection to your commit, but I think pciutils is doing the right thing, The question is not if some software is doing the right thing or not but if our packages behave like they should for our users. and despite me and Mike putting a

Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Daniel Drake
Wulf C. Krueger wrote: The question is not if some software is doing the right thing or not but if our packages behave like they should for our users. There is also value in satisfying and not deviating away from upstream, as well as respecting values of upstream decisions (such as offering

Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Doug Goldstein
Daniel Drake wrote: Robin H. Johnson wrote: Heya, So now this is not a flamewar. Jakub was originally going to complain at me for the upstream usbutils adding support for gzipped usb.ids files, but a group of us (myself, dsd, jakub, leio, steev) had a discussion about it, and came up with

Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Roy Marples
On Wed, 2007-10-31 at 11:40 -0400, Doug Goldstein wrote: When HAL evaluated the usage of libpci the following issues were identified: 1) increased memory usage, to the point that HAL was not usable on the OLPC project 2) ABI breakage between patch revisions (i.e. x.y.z and x.y.z+1 were

Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Jan Kundrát
Daniel Drake wrote: OK, so having a dynamic libpci is an outstanding requirement for the patch. I will follow up with pciutils upstream about the current state of that. If you had any issues with Martin Mares, I can talk to him as he's my teacher in one course at the university. He looks like

Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Daniel Drake
Doug Goldstein wrote: When HAL evaluated the usage of libpci the following issues were identified: 1) increased memory usage, to the point that HAL was not usable on the OLPC project I was only ever aware of concerns that memory usage might be high, but wasn't aware it caused specific

Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Rémi Cardona
Roy Marples a écrit : Begs the question why does HAL use libpci in the first place. 2 reasons (that I know of) : 1) to make things pretty in lshal 2) to make writing FDI files somewhat less cryptic http://gitweb.freedesktop.org/?p=hal.git;a=blob;f=hald/linux/device.c#l1554 Rémi -- [EMAIL

[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 Donnie Berkholz
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:

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 :

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 Rémi Cardona
Marijn Schouten (hkBst) wrote: Donnie Berkholz wrote: 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? In theory, autotools scripts allow users to set env variables

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 Donnie Berkholz
On 19:25 Wed 31 Oct , Marijn Schouten (hkBst) wrote: Donnie Berkholz wrote: 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? Binary packages don't do any linking,

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/nxserver-freenx: nxserver-freenx-0.7.0-r1.ebuild ChangeLog nxserver-freenx-0.7.1.ebuild

2007-10-31 Thread Donnie Berkholz
On 19:49 Wed 31 Oct , Bernard Cafarelli (voyageur) wrote: 1.1 net-misc/nxserver-freenx/nxserver-freenx-0.7.1.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/nxserver-freenx/nxserver-freenx-0.7.1.ebuild?rev=1.1view=markup plain:

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 Mike Frysinger
On Wednesday 31 October 2007, 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:

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

Re: [gentoo-portage-dev] use* cleanup

2007-10-31 Thread Mike Frysinger
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