Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Sat, Aug 14, 2010 at 2:41 AM, Ryan Hill wrote:
> On Sat, 14 Aug 2010 00:14:28 -0400 Mike Frysinger wrote:
>> that's crap. fix the package or at least work around it:
>> LDFLAGS=`echo ${LDFLAGS}`
>>
>> we shouldnt be forced to add random hacks throughout the tree because
>> of one or two random broken packages
>
> Yes, I meant don't commit it until someone fixes boost-build. I just did so
> go ahead.
sorry, i thought you meant that we should block the profile change indefinitely
-mike
[gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Sat, 14 Aug 2010 00:14:28 -0400
Mike Frysinger wrote:
> that's crap. fix the package or at least work around it:
> LDFLAGS=`echo ${LDFLAGS}`
>
> we shouldnt be forced to add random hacks throughout the tree because
> of one or two random broken packages
Yes, I meant don't commit it until someone fixes boost-build. I just did so
go ahead.
--
fonts, gcc-porting, and it's all by design
toolchain, wxwidgetsto keep us from losing our minds
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
[gentoo-dev] last rites: dev-libs/linux-fusion
# Michael Sterrett (13 Aug 2010) # Mask for removal 20100913 # Doesn't work with newer kernels (Bug 316869) dev-libs/linux-fusion
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Fri, Aug 13, 2010 at 11:43 PM, Ryan Hill wrote:
> On Fri, 13 Aug 2010 18:11:42 +0300 Markos Chandras wrote:
>> Could someone guide me to add --hash-style=gnu to default/linux/amd64/dev
>> profile? I don't want to break anything
>
> The thing is, you can't right now. :D LDFLAGS don't stack, meaning you'd
> have to do something like
>
> --- targets/developer/make.defaults 26 Jul 2010 19:15:05 - 1.9
> +++ targets/developer/make.defaults 14 Aug 2010 03:31:18 -
> @@ -12,3 +12,6 @@
>
> # Log eqawarn messages
> PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa"
> +
> +# Help find packages not respecting LDFLAGS
> +LDFLAGS="-Wl,--hash-style=gnu ${LDFLAGS}"
>
>
> Which breaks boost-build (bug #293652). That's why I suggested just putting
> a message in targets/developer/profile.bashrc (which is otherwise completely
> useless).
that's crap. fix the package or at least work around it:
LDFLAGS=`echo ${LDFLAGS}`
we shouldnt be forced to add random hacks throughout the tree because
of one or two random broken packages
-mike
[gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Fri, 13 Aug 2010 21:43:35 -0600
Ryan Hill wrote:
> The thing is, you can't right now. :D LDFLAGS don't stack, meaning you'd
> have to do something like
>
> --- targets/developer/make.defaults 26 Jul 2010 19:15:05 - 1.9
> +++ targets/developer/make.defaults 14 Aug 2010 03:31:18 -
> @@ -12,3 +12,6 @@
>
> # Log eqawarn messages
> PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa"
> +
> +# Help find packages not respecting LDFLAGS
> +LDFLAGS="-Wl,--hash-style=gnu ${LDFLAGS}"
>
Oops, I guess that should be default/linux/amd64/dev/make.defaults.
--
fonts, gcc-porting, and it's all by design
toolchain, wxwidgetsto keep us from losing our minds
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
[gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Fri, 13 Aug 2010 18:11:42 +0300
Markos Chandras wrote:
> Could someone guide me to add --hash-style=gnu to default/linux/amd64/dev
> profile? I don't want to break anything
The thing is, you can't right now. :D LDFLAGS don't stack, meaning you'd
have to do something like
--- targets/developer/make.defaults 26 Jul 2010 19:15:05 - 1.9
+++ targets/developer/make.defaults 14 Aug 2010 03:31:18 -
@@ -12,3 +12,6 @@
# Log eqawarn messages
PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa"
+
+# Help find packages not respecting LDFLAGS
+LDFLAGS="-Wl,--hash-style=gnu ${LDFLAGS}"
Which breaks boost-build (bug #293652). That's why I suggested just putting
a message in targets/developer/profile.bashrc (which is otherwise completely
useless).
--
fonts, gcc-porting, and it's all by design
toolchain, wxwidgetsto keep us from losing our minds
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] keepdir /var/run/package/?
On Fri, Aug 13, 2010 at 1:04 PM, Ulrich Mueller wrote: > On Fri, 13 Aug 2010, Mike Frysinger wrote: >> for people who do wish to improve their init.d scripts, recreating a >> dir is easy if your init.d runs after localmount: >> [ ! -d /var/run/foo ] && install -d -m 755 -o fowner -g fgroup /var/run/foo > > Why not "checkpath -d -o fowner:fgroup -m 0755 /var/run/foo"? i thought there was something. that was the whole point of Bug 192682. if we dont get openrc out the door, i'll have to add to baselayout-1. -mike
Re: [gentoo-dev] keepdir /var/run/package/?
> On Fri, 13 Aug 2010, Mike Frysinger wrote: > for people who do wish to improve their init.d scripts, recreating a > dir is easy if your init.d runs after localmount: > [ ! -d /var/run/foo ] && install -d -m 755 -o fowner -g fgroup /var/run/foo Why not "checkpath -d -o fowner:fgroup -m 0755 /var/run/foo"? This also corrects wrong owner and permissions for an existing dir. Ulrich
Re: [gentoo-dev] keepdir /var/run/package/?
On Thu, 12 Aug 2010 15:40:31 -0400 Mike Frysinger wrote: > On Thu, Aug 12, 2010 at 3:33 PM, Eray Aslan wrote: > > On 08/12/2010 09:48 PM, Samuli Suominen wrote: > >> It says "Files under this directory", not "Files and directories > >> under this directory." > > > > Fair enough. > > > > So our policy basically is "tmpfs is not supported > > for /var/run" (and also for /var/lock I suppose). > > it may have been in the past, but it's best to move forward and not > sit in the past > > > It will be somewhat more work but instead of the above, we can say > > "tmpfs might be used for /var/run and /var/lock and the init > > scripts should handle this correctly". It feels (for want of a > > better word) better. > > i certainly use a tmpfs on /var/run to minimize disk writes. packages > that break i file bugs for and/or fix myself. it isnt that hard. > > plus, it's just good behavior. if /var/run gets removed for whatever > reason, people have to re-emerge a bunch of packages to simply create > a subdir ? that's silly. Bug #332633 tracks ebuilds (284) and eclasses (currently none) that run "keepdir /var/run*". https://bugs.gentoo.org/show_bug.cgi?id=332633 jer
Re: [gentoo-dev] keepdir /var/run/package/?
On Fri, Aug 13, 2010 at 12:17 PM, Mike Frysinger wrote: > for people who do wish to improve their init.d scripts, recreating a > dir is easy if your init.d runs after localmount: > [ ! -d /var/run/foo ] && install -d -m 755 -o fowner -g fgroup /var/run/foo oh, and for the very few cases that need to create a file with specific ownership ahead of time (because their daemon sucks and doesnt drop root properly), then you can do: install -m 644 -o fowner -g fgroup /dev/null /var/run/foo-file -mike
Re: [gentoo-dev] keepdir /var/run/package/?
On Thu, Aug 12, 2010 at 3:40 PM, Mike Frysinger wrote: > On Thu, Aug 12, 2010 at 3:33 PM, Eray Aslan wrote: >> It will be somewhat more work but instead of the above, we can say "tmpfs >> might be used for /var/run and /var/lock and the init scripts should handle >> this correctly". It feels (for want of a better word) better. > > i certainly use a tmpfs on /var/run to minimize disk writes. packages > that break i file bugs for and/or fix myself. it isnt that hard. > > plus, it's just good behavior. if /var/run gets removed for whatever > reason, people have to re-emerge a bunch of packages to simply create > a subdir ? that's silly. for people who do wish to improve their init.d scripts, recreating a dir is easy if your init.d runs after localmount: [ ! -d /var/run/foo ] && install -d -m 755 -o fowner -g fgroup /var/run/foo if your init.d runs before localmount, you'll have to resort to normal mkdir/chown/chmod, but i dont think there are many (any?) scripts that'll hit this set of requirements -mike
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Thu, Aug 12, 2010 at 10:35:57AM +0200, Christian Faulhammer wrote: > Hi, > > Mike Frysinger : > > sounds like someone needs to update/extend the arch testing > > documentation. random e-mails posted to random dev lists are quickly > > forgotten. new arch testers however should be reading the arch tester > > documnt. > > It has been added to the x86 AT guide. > > V-Li > > -- > Christian Faulhammer, Gentoo Lisp project > http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode > > http://gentoo.faulhammer.org/> Could someone guide me to add --hash-style=gnu to default/linux/amd64/dev profile? I don't want to break anything Thanks -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpi99CkxXDSC.pgp Description: PGP signature
Re: [gentoo-dev] Re: New global use flag: vpx or vp8
On Fri, 13 Aug 2010 10:11:32 +0200 Peter Hjalmarsson wrote: > So I think a USE="vp8" or USE="webm" (probably the first) to enable > decoding, and USE="vpx" should be used to fine tune what > implementation to use. Having USE="vp8" (no USE="vpx" specified) in > make.conf should give you support for vp8 in all packages and the > implementation should be the maintainers preference for that package. +1 Philipp
Re: [gentoo-dev] New global use flag: vpx or vp8
On 1 August 2010 01:32, Steve Dibb wrote: [...] > The description is misleading, and needs to be changed. Just because > something has an mp3 and a lame use flag, it does not mean that flipping on > lame means that the application will prefer lame over mad or mpg123. lame (the MP3 encoder) has nothing to do with mad or mpg123 (which are used to decode MP3s) -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
[gentoo-dev] Re: New global use flag: vpx or vp8
lör 2010-07-31 klockan 13:37 +0200 skrev Hanno Böck: > vpx for supporting googles vp8 codec used in webm. > > At the moment this is only mplayer and ffmpeg, but it's pretty obvious that > apps supporting vp8 will start popping up everywhere (currently working on > arista ebuild which will support it). > > Though we might discuss if vpx is really a good name or it shouldn't be vp8. > This feels like the standard discussion about a use flag for function versus a use flag for dependencies. Myself I think this should follow the most commonly for ssl found nameing convention which is that: USE="ssl" provides ssl support in all packages. If a package has optional ssl-support they should have this flag. USE="gnutls openssl nss ..." finetunes which implementation of ssl to use. They should never exist without USE="ssl" unless they package has unconditional ssl support. Of course there are people who think otherwise even for ssl/tls, and so you cannot be sure that you have ssl/tls support even if you have USE="ssl". For example if you cannot connect with vnc using tls to your qemu virtual machine then you have to look up that ebuild to see that tls is only enabled if you have USE="gnutls". I think that is suboptimal and confusing for the user. So I think a USE="vp8" or USE="webm" (probably the first) to enable decoding, and USE="vpx" should be used to fine tune what implementation to use. Having USE="vp8" (no USE="vpx" specified) in make.conf should give you support for vp8 in all packages and the implementation should be the maintainers preference for that package.
