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
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.1&view=markup plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-p2p/deluge/deluge-0.5
> >.6.2.ebuild?rev=1.1&content-type=text/plain
> >
> > pkg_setup() {
> > if has_version " > ! built_with_use "dev-libs/boost" threads; then
> > eerror "dev-libs/boost has to be built with threads USE-flag."
> > die "Missing threads USE-flag for dev-libs/boost"
> > fi
> > }
> >
> > src_compile() {
> > filter-ldflags -Wl,--as-needed
> >
> > distutils_src_compile
> > }
>
> If you moved the filter-ldflags() call up to pkg_setup(), you could drop
> src_compile() altogether to clean up the ebuild a little.
a better idea is to fix the problem instead of ignoring it with filter-ldflags
-mike
signature.asc
Description: This is a digitally signed message part.
[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
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.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/nxserver-freenx/nxserver-freenx-0.7.1.ebuild?rev=1.1&content-type=text/plain
> pkg_postinst () {
> usermod -s /usr/bin/nxserver nx || die "Unable to set login shell of nx
> user!!"
> usermod -d ${NX_HOME_DIR} nx || die "Unable to set home directory of nx
> user!!"
This isn't safe with ROOT != / and it looks wrong too, you oughta be
using enewuser for this stuff.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/deluge: ChangeLog deluge-0.5.6.2.ebuild deluge-0.5.6.1.ebuild
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, so they don't pay any attention to LDFLAGS. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/deluge: ChangeLog deluge-0.5.6.2.ebuild deluge-0.5.6.1.ebuild
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 only during the configure phase. Running 'CFLAGS="blah" make' should be exactly the same as runing make on its own. So I'd go as far as saying that puting the filter-ldflags() in src_compile() would not work. As for what python distutils scripts do exactly ... Rémi -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/deluge: ChangeLog deluge-0.5.6.2.ebuild deluge-0.5.6.1.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
> On 15:38 Wed 31 Oct , Raul Porcel (armin76) wrote:
>> 1.1 net-p2p/deluge/deluge-0.5.6.2.ebuild
>>
>> file :
>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-p2p/deluge/deluge-0.5.6.2.ebuild?rev=1.1&view=markup
>> plain:
>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-p2p/deluge/deluge-0.5.6.2.ebuild?rev=1.1&content-type=text/plain
>
>> pkg_setup() {
>> if has_version "> ! built_with_use "dev-libs/boost" threads; then
>> eerror "dev-libs/boost has to be built with threads USE-flag."
>> die "Missing threads USE-flag for dev-libs/boost"
>> fi
>> }
>>
>> src_compile() {
>> filter-ldflags -Wl,--as-needed
>>
>> distutils_src_compile
>> }
>
> If you moved the filter-ldflags() call up to pkg_setup(), you could drop
> src_compile() altogether to clean up the ebuild a little.
Wouldn't that make binary packages cry?
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project
[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
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.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-p2p/deluge/deluge-0.5.6.2.ebuild?rev=1.1&content-type=text/plain
> pkg_setup() {
> if has_version " ! built_with_use "dev-libs/boost" threads; then
> eerror "dev-libs/boost has to be built with threads USE-flag."
> die "Missing threads USE-flag for dev-libs/boost"
> fi
> }
>
> src_compile() {
> filter-ldflags -Wl,--as-needed
>
> distutils_src_compile
> }
If you moved the filter-ldflags() call up to pkg_setup(), you could drop
src_compile() altogether to clean up the ebuild a little.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
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 PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
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 a reasonable person. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
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 problems. I went through the first 3 pages of google results for "pciutils inurl:hal site:lists.freedesktop.org" "libpci inurl:hal site:lists.freedesktop.org" and didn't see anything. Maybe it was discussed elsewhere. Anyway, if this did happen once, it doesn't seem to happen any more, see below. 2) ABI breakage between patch revisions (i.e. x.y.z and x.y.z+1 were not ABI compatible) This doesn't matter when you statically link against the library, as long as the API doesn't change. The API that is used in Mike's patch does not seem to have changed for a long time. (Nevertheless, see my notes under the following item -- this will be solved when the next one is solved.) 3) no shared library This is a fair point, but I thought it was never raised as an objection, I didn't think it was actually a blocker for acceptance. Especially given that parts of HAL already statically link against libpci. I just looked over the threads again and I now see this: http://lists.freedesktop.org/archives/hal/2007-June/008836.html I apologise, I must have missed that before. 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. 4) the library calls exit() when it encounters an error in parsing it's own pci.ids file which would kill the whole app using it. There might have been more. I don't remember. Refer to ML discussions and refer to IRC logs with me. I looked over them, I don't see any others. Now Mike (vapier) rectified #4 several pciutils releases ago by providing a callback function that we could define which would override the default exit() behavior. I still think it's sub-par to have an utility library call exit() by default but whatever. Yeah. You were told by me and the HAL ML that once #2 and #3 are rectified and if you could provide some basic memory usage information along with your patch (i.e. show #1 isn't true anymore) that we would happily accept your patch. You addressed #1 on the mailing list with a simple statement, which I will paraphrase. "It doesn't use more memory on my machine". To which Danny K asked if you could provide some basic data behind that and you never did. I did: http://lists.freedesktop.org/archives/hal/2007-June/008852.html http://lists.freedesktop.org/archives/hal/2007-June/008861.html Anyway, apologies for the oversight on the shared library thing -- it appears it wasn't total silent rejection after all. I'll let you know where that leads. Thanks, Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
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 > not ABI compatible) > 3) no shared library > 4) the library calls exit() when it encounters an error in parsing it's > own pci.ids file which would kill the whole app using it. > > There might have been more. I don't remember. Refer to ML discussions > and refer to IRC logs with me. Begs the question why does HAL use libpci in the first place. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
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 a >> solution that both ends the breakage for direct users (HAL and others), >> and provides forward momentum. >> >> So firstly, what's the real problem? The original complaint came up >> because HAL expected the uncompressed file to exist as pci.ids, and >> wasn't ready to look at pci.ids.gz. While this caused breakage, it was >> only a warning sign that there was a deeper problem. > > I don't feel strongly enough to make an objection to your commit, but > I think pciutils is doing the right thing, and despite me and Mike > putting a hours into getting a decent HAL patch together the response > I got was that as upstream they are simply "not interested" (no > technical or logical objections provided), so I don't feel you should > be putting workarounds in pciutils just to make HAL happy. > > > > Daniel Daniel, That's a LOAD of garbage and you know it. You're just straight away making up stuff, essentially lying. You know damn well what the reasons were since they were explained to you on numerous occasions. 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 not ABI compatible) 3) no shared library 4) the library calls exit() when it encounters an error in parsing it's own pci.ids file which would kill the whole app using it. There might have been more. I don't remember. Refer to ML discussions and refer to IRC logs with me. Now Mike (vapier) rectified #4 several pciutils releases ago by providing a callback function that we could define which would override the default exit() behavior. I still think it's sub-par to have an utility library call exit() by default but whatever. You were told by me and the HAL ML that once #2 and #3 are rectified and if you could provide some basic memory usage information along with your patch (i.e. show #1 isn't true anymore) that we would happily accept your patch. Now #2 and #3 are still not true in the latest release. There is no guarantee by the pciutils maintainers that they will maintain ABI compatibility while keeping the same .so version number. And there is still no shared library built. You addressed #1 on the mailing list with a simple statement, which I will paraphrase. "It doesn't use more memory on my machine". To which Danny K asked if you could provide some basic data behind that and you never did. As a result, 3 out of 4 concerns with your patch and pciutils were never addressed and the issue was dropped on the HAL ML pending more feedback. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
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 compressed IDs to save bandwidth and disk space). But yes, the correct software behaviour is useful too, and I wouldn't be pushing a solution that caused a degradation in user experience. Neither is the question if any of us are happy but if our *users* are happy when their installation process breaks because of "that HAL bug". We don't make HAL, its upstream or anyone but our users happy. Our obligation is primarily to them. pciutils has an upstream too. I am attaching a HAL ebuild patch which is the approach ... that still potentially allows things to break because of animosities among ourselves. HAL handles the missing file condition at runtime if it was compiled with support for it. So, there will be no breakage under circumstances where the package was built for a different box. No issue here. We have a good solution, namely robbat2's, which will make sure things don't break for our users. IMO, that's the way to go because the other approaches make us look bad and are unworthy of a distribution that wants to be taken seriously. Things already work for the users with the hal useflag for pciutils, and things will also work with my patch in a slightly nicer/more robust way, without having to extend the HAL issue to the pciutils package. I'm going to drop out of this discussion here, just wanted to point out that there is both technical reasoning behind my suggestion, no technical flaws that I know of, and no degradation in user experience. Only in distant corner cases would someone notice a difference, and the "fix" is easy and documented by the ebuild messages. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
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 hours into getting a decent HAL patch together the response I got was that as upstream they are simply "not interested" (no technical or logical objections provided), so I don't feel you should be putting workarounds in pciutils just to make HAL happy. Neither is the question if any of us are happy but if our *users* are happy when their installation process breaks because of "that HAL bug". We don't make HAL, its upstream or anyone but our users happy. Our obligation is primarily to them. I am attaching a HAL ebuild patch which is the approach ... that still potentially allows things to break because of animosities among ourselves. We have a good solution, namely robbat2's, which will make sure things don't break for our users. IMO, that's the way to go because the other approaches make us look bad and are unworthy of a distribution that wants to be taken seriously. -- Best regards, Wulf pgp24UJA49nRG.pgp Description: PGP Digital Signature
[gentoo-dev] Re: Resolving HAL vs. pciutils/usbutils
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,
which could be different than the system the package is ultimately
installed on. yes it doesn't make much difference right now, but
what happens if hal does start making good use of pci.ids someday?
having pciutils install both a compressed and uncompressed file when
zlib is enabled is a much cleaner solution IMO.
--
fonts / wxWindows / gcc-porting / treecleaners
EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662)
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Resolving HAL vs. pciutils/usbutils
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 dev, if there are any, I > can take some stuff to do. Hi Guilherme, thanks for your interest, but this isn't really appropriate for this list. Please see [1] and [2]. [1] http://www.gentoo.org/proj/en/gdp/doc/translators-howto.xml [2] http://www.gentoo.org/proj/en/gdp/doc/doc-policy.xml Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Resolving HAL vs. pciutils/usbutils
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 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 dev, if there are any, I can take some stuff to do. Cheers, Guilherme -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
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 ends the breakage for direct users (HAL and others),
and provides forward momentum.
So firstly, what's the real problem? The original complaint came up
because HAL expected the uncompressed file to exist as pci.ids, and
wasn't ready to look at pci.ids.gz. While this caused breakage, it was
only a warning sign that there was a deeper problem.
I don't feel strongly enough to make an objection to your commit, but I
think pciutils is doing the right thing, and despite me and Mike putting
a hours into getting a decent HAL patch together the response I got was
that as upstream they are simply "not interested" (no technical or
logical objections provided), so I don't feel you should be putting
workarounds in pciutils just to make HAL happy.
Especially because HAL really doesn't use pci.ids for anything useful. I
am attaching a HAL ebuild patch which is the approach I'm in favour of
and first mentioned several months ago. It does not require any HAL
patches or pciutils modifications. It stems from the fact that really
HAL doesn't really do anything useful with the ID-to-name mappings
provided in pci.ids. It makes "that HAL bug" disappear with the click of
the fingers. I didn't really get any proper answer why our HAL
maintainers weren't keen on this when I first mentioned it.
Daniel
--- hal-0.5.9-r1.ebuild.orig2007-10-31 10:34:34.0 +
+++ hal-0.5.9-r1.ebuild 2007-10-31 10:46:15.0 +
@@ -80,13 +80,6 @@ function notify_inotify() {
}
pkg_setup() {
- if ! built_with_use --missing false sys-apps/pciutils hal ; then
- if built_with_use --missing false sys-apps/pciutils zlib ; then
- eerror "You MUST build sys-apps/pciutils without the
zlib USE flag"
- die "You MUST build sys-apps/pciutils without the zlib
USE flag"
- fi
- fi
-
if use kernel_linux; then
kernel_is ge 2 6 17 || ewarn "HAL requires a kernel version
2.6.17 or newer"
@@ -147,6 +140,7 @@ src_unpack() {
src_compile() {
local backend=""
local acpi=""
+ local myconf=""
# TODO :: policykit should have a pam useflag
append-flags -rdynamic
@@ -164,6 +158,15 @@ src_compile() {
acpi="--disable-acpi-proc --disable-acpi-acpid"
fi
+ if [[ ! -e "${ROOT}"/usr/share/misc/pci.ids ]]; then
+ myconf="--disable-pci-ids"
+ elog "It looks like you've built pciutils with the zlib USE
flag"
+ elog "meaning that your /usr/share/misc/pci.ids file is
compressed"
+ elog "and incompatible with HAL. You almost certainly won't
notice "
+ elog "any feature loss here, but if you do, just re-emerge
pciutils "
+ elog "without the zlib flag, then re-emerge hal."
+ fi
+
econf --disable-policy-kit \
--docdir=/usr/share/doc/${PF} \
--with-os-type=gentoo \
@@ -182,6 +185,7 @@ src_compile() {
$(use_enable selinux) \
--disable-console-kit \
${acpi} \
+ $myconf \
|| die "configure failed"
#$(use_enable pam console-kit)
Re: [gentoo-dev] USE flag transition: tetex and latex
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, too? I had been thinking about it and am not sure what would be the best option: Some packages use the tetex useflag to enable some latex support, in which case a latex useflag should be fine. (e.g. doxygen is the first one I found that seems to be in that case) Some others use it to enable kpathsea support, where tetex is the historical distribution that provides it for us. From quickly digging into lcdf-typetools code for ex., it seems it is used there to locate files and update the kpathsea files so that other apps using kpathsea will see the changes it has made. That way it integrates with a tetex-alike distribution. So, imho, in that case a kpathsea useflag would make more sense; but I doubt such a useflag name will speak by itself. Alexis. signature.asc Description: PGP signature
