[gentoo-dev] Re: gentoo commit in xml/htdocs/proj/en/council/meeting-logs: 20100809-summary.txt
* Tomas Chvatal (scarabeus) scarab...@gentoo.org: 4) Bugs assigned to council@ in bugzilla and their progress https://bugs.gentoo.org/buglist.cgi?query_format=advancedshort_desc_type= allwordssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type =allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstr status_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMED bug_status=NEWbug_status=ASSIGNEDemailassigned_to1=1emailcc1=1emailtype1= substringemail1=council%40gentoo.orgemailassigned_to2=1emailreporter2=1 emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes= chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+ last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= Look up bugzilla's quicksearch help. The following quicksearch lists all unresolved bugs: http://bugs.gentoo.org/buglist.cgi?quicksearch=assignedto,cc:coun...@gentoo.org
[gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Mon, Aug 09, 2010 at 07:05:11PM -0400, Mike Frysinger wrote: On Mon, Aug 9, 2010 at 7:03 PM, Markos Chandras wrote: On Sat, Aug 07, 2010 at 10:16:24PM -0400, Mike Frysinger wrote: obviously you only mean linux x86/amd64 dev profiles. i dont have a strong opinion on that small subset in either direction. So do you agree to make this linker option default to linux x86/amd64 dev/ profiles? add them or dont add them, i dont have a [...] opinion [...] in either direction. if put to a vote, i'd abstain. Possibly a stupid question, but any reason we've not looked at injecting something that has lower actual affect but can still be used for a canary? I'm thinking of --build-id specifically... ~brian pgpXeWakMzWiT.pgp Description: PGP signature
Re: [gentoo-dev] Re: gentoo commit in xml/htdocs/proj/en/council/meeting-logs: 20100809-summary.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 10.8.2010 10:32, Torsten Veller napsal(a): * Tomas Chvatal (scarabeus) scarab...@gentoo.org: 4) Bugs assigned to council@ in bugzilla and their progress https://bugs.gentoo.org/buglist.cgi?query_format=advancedshort_desc_type= allwordssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type =allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstr status_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMED bug_status=NEWbug_status=ASSIGNEDemailassigned_to1=1emailcc1=1emailtype1= substringemail1=council%40gentoo.orgemailassigned_to2=1emailreporter2=1 emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes= chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+ last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= Look up bugzilla's quicksearch help. The following quicksearch lists all unresolved bugs: http://bugs.gentoo.org/buglist.cgi?quicksearch=assignedto,cc:coun...@gentoo.org You win da cookies :] I updated it in cvs :] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxhFxcACgkQHB6c3gNBRYc1sQCdEAphf5x6S1VSzcuWqT22OiUZ kVIAnjMXh3TsQ6bzmLEpFPy6fzcFKjqA =oRMh -END PGP SIGNATURE-
[gentoo-dev] /bin and /sbin to /usr
[Following a similar discussion in another mailing list]
As you know, only a few directories can be assumed to be available after
boot[1]. Notably, /usr and /var are not among them. Binaries in /bin
and /sbin should be enough to do basic maintanence/repair and to mount
other volumes. Since we are using the binaries in /bin and /sbin to
potentially mount /usr, they should not depend on them. Or can they?
On my laptop:
# for f in /bin/* /sbin/*; do if [ $(file $f | grep ELF) != ] ;
then if [ $(ldd $f | grep /usr) != ] ; then echo $(equery belongs
$f) $f; ldd $f; fi; fi; done
net-firewall/iptables-1.4.6 /sbin/iptables-multi
linux-vdso.so.1 = (0x7fffc77e8000)
libip4tc.so.0 = /usr/lib/libip4tc.so.0 (0x7f27e4781000)
libxtables.so.4 = /usr/lib/libxtables.so.4 (0x7f27e4579000)
libm.so.6 = /lib/libm.so.6 (0x7f27e42f8000)
libc.so.6 = /lib/libc.so.6 (0x7f27e3f9f000)
libdl.so.2 = /lib/libdl.so.2 (0x7f27e3d9b000)
/lib64/ld-linux-x86-64.so.2 (0x7f27e4988000)
sys-apps/hal-0.5.14-r2 /sbin/umount.hal
linux-vdso.so.1 = (0x7fff6b5f3000)
libhal.so.1 = /usr/lib/libhal.so.1 (0x7fd52e637000)
libhal-storage.so.1 = /usr/lib/libhal-storage.so.1 (0x7fd52e42c000)
libdbus-1.so.3 = /usr/lib/libdbus-1.so.3 (0x7fd52e1ec000)
libc.so.6 = /lib/libc.so.6 (0x7fd52de93000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7fd52dc77000)
librt.so.1 = /lib/librt.so.1 (0x7fd52da6e000)
/lib64/ld-linux-x86-64.so.2 (0x7fd52e848000)
Questions:
1. Is this OK or should we file bugs against binaries in {/bin,/sbin} linking
against libraries in /usr/lib? Fix is relatively easy in general (give
--libdir=/lib against the config script)
2. Is the below acceptable? (symlinking from /bin to /usr/bin)
# ls -l $(find {/bin,/sbin}/ -type l)|grep /usr
lrwxrwxrwx 1 root root 20 Oct 28 2008 /bin/igawk -
/usr/bin/igawk-3.1.6
lrwxrwxrwx 1 root root 14 Aug 10 13:29 /bin/mail - /usr/bin/mailx
lrwxrwxrwx 1 root root 20 Oct 28 2008 /bin/pgawk -
/usr/bin/pgawk-3.1.6
Corollary to both: If yes, tinderbox/buildbot against other packages
are probably in order as well.
Thanks
--
Eray
[1]
/dev
/etc
/lib
/bin
/sbin
/proc (Linux)
/sys (Linux-2.6)
/libexec (*BSD)
Re: [gentoo-dev] /bin and /sbin to /usr
On 8/10/10 4:22 AM, Eray Aslan wrote:
1. Is this OK or should we file bugs against binaries in {/bin,/sbin} linking
against libraries in /usr/lib? Fix is relatively easy in general (give
--libdir=/lib against the config script)
I'd suggest a fix that is guaranteed to work: make portage refuse to
install anything in /bin that depends on /usr (based on say ldd check).
2. Is the below acceptable? (symlinking from /bin to /usr/bin)
# ls -l $(find {/bin,/sbin}/ -type l)|grep /usr
lrwxrwxrwx 1 root root 20 Oct 28 2008 /bin/igawk -
/usr/bin/igawk-3.1.6
lrwxrwxrwx 1 root root 14 Aug 10 13:29 /bin/mail - /usr/bin/mailx
lrwxrwxrwx 1 root root 20 Oct 28 2008 /bin/pgawk -
/usr/bin/pgawk-3.1.6
I don't know the reason behind it. Both /usr/bin and /bin are in PATH...
maybe for compatibility reasons.
Paweł
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] QA last rites for sys-apps/gluelog
# Diego E. Pettenò flamee...@gentoo.org (10 Aug 2010) # on behalf of QA team # # Website's dead; install init scripts not suited for Gentoo # rc system; there are no source packages, the files are # directly in CVS; code comes 2002, and no way to track down # anything newer; LICENSE value and source files don't agree # on a GPL-2. # # Removal on 2010-10-09 sys-apps/gluelog
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
2010/8/10 Brian Harring ferri...@gmail.com
On Mon, Aug 09, 2010 at 07:05:11PM -0400, Mike Frysinger wrote:
On Mon, Aug 9, 2010 at 7:03 PM, Markos Chandras wrote:
On Sat, Aug 07, 2010 at 10:16:24PM -0400, Mike Frysinger wrote:
obviously you only mean linux x86/amd64 dev profiles. i dont have a
strong
opinion on that small subset in either direction.
So do you agree to make this linker option default to linux x86/amd64
dev/
profiles?
add them or dont add them, i dont have a [...] opinion [...] in
either direction. if put to a vote, i'd abstain.
Possibly a stupid question, but any reason we've not looked at
injecting something that has lower actual affect but can still be used
for a canary? I'm thinking of --build-id specifically...
~brian
I don't know how --hash-style=gnu is used to check for LDFLAGS, so this may
be OT.
On my personal and _breakable_ desktop I do use
LDFLAGS=${LDFLAGS} -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-Wl,--sort-common -Wl,--build-id
in make.conf.
Would this two liners tell me which package who install binaries in /usr/bin
does not respect ldflags?
# for i in /usr/bin/* ; do eu-unstrip -n -e $i ; done build-id.txt
# qfile $(grep '0x[0-9]*+0x[0-9]* - ' build-id.txt | awk '{ print $3 }')
On a side note, I've noticed that build-id change at every re-compilation of
the package, even if nothing changed in the system, since it's supposed to
be a 160-bit SHA1 hash on the normative parts of the output contents
should it be the same if the package is compiled on the same system with no
changes?
Output of the two liners for this system:
sys-apps/turbotail (/usr/bin/turbotail)
app-arch/rzip (/usr/bin/runzip)
app-arch/rzip (/usr/bin/rzip)
dev-lang/go (/usr/bin/6a)
dev-lang/go (/usr/bin/6cov)
dev-lang/go (/usr/bin/6l)
dev-lang/go (/usr/bin/6nm)
dev-lang/xharbour (/usr/bin/pprun)
dev-lang/xharbour (/usr/bin/hbmake)
dev-lang/xharbour (/usr/bin/hbdict)
dev-lang/xharbour (/usr/bin/xbscript)
dev-lang/perl (/usr/bin/perl)
dev-lang/perl (/usr/bin/perl5.12.1)
dev-lang/R (/usr/bin/Rscript)
x11-misc/xcb (/usr/bin/xcb)
dev-libs/dietlibc (/usr/bin/dnsd)
dev-libs/dietlibc (/usr/bin/elftrunc)
app-text/o3read (/usr/bin/utf8tolatin1)
app-accessibility/festival (/usr/bin/audsp)
app-accessibility/espeak (/usr/bin/espeak)
sys-devel/gcc (/usr/bin/x86_64-pc-linux-gnu-gcjh-4.4.4)
sys-devel/gcc (/usr/bin/gcjh-4.4.4)
sys-devel/llvm-gcc (/usr/bin/llvm-gcov)
sys-devel/qconf (/usr/bin/qconf)
www-plugins/lightspark (/usr/bin/lightspark)
[gentoo-dev] QA last rites for app-admin/webmin
# Diego E. Pettenò flamee...@gentoo.org (10 Aug 2010) # on behalf of QA team # # Breaks about any QA policy regarding not touching # live filesystem as it writes to LVM configuration, # cron configuration, current-running kernel modules, RPM # library, ... # # Removal on 2010-10-09 app-admin/webmin
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Tue, Aug 10, 2010 at 2:40 PM, Francesco R wrote:
I don't know how --hash-style=gnu is used to check for LDFLAGS, so this may
be OT.
it looks to see what ELFs still have a .hash section
On my personal and _breakable_ desktop I do use
LDFLAGS=${LDFLAGS} -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-Wl,--sort-common -Wl,--build-id
in make.conf.
Would this two liners tell me which package who install binaries in /usr/bin
does not respect ldflags?
# for i in /usr/bin/* ; do eu-unstrip -n -e $i ; done build-id.txt
# qfile $(grep '0x[0-9]*+0x[0-9]* - ' build-id.txt | awk '{ print $3 }')
way more complicated than necessary. simply do:
scanelf -qyRk.hash -F'%F#k' /usr/bin/
this is after all what portage is using now
-mike
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Tue, Aug 10, 2010 at 4:45 AM, Brian Harring wrote: On Mon, Aug 09, 2010 at 07:05:11PM -0400, Mike Frysinger wrote: On Mon, Aug 9, 2010 at 7:03 PM, Markos Chandras wrote: On Sat, Aug 07, 2010 at 10:16:24PM -0400, Mike Frysinger wrote: obviously you only mean linux x86/amd64 dev profiles. i dont have a strong opinion on that small subset in either direction. So do you agree to make this linker option default to linux x86/amd64 dev/ profiles? add them or dont add them, i dont have a [...] opinion [...] in either direction. if put to a vote, i'd abstain. Possibly a stupid question, but any reason we've not looked at injecting something that has lower actual affect but can still be used for a canary? I'm thinking of --build-id specifically... my gut reaction there is now you're requiring even newer versions of binutils than before, and not just to find ones that support --build-id, but do so without bugs (that's my vague recollection of things; perhaps i'm wrong). and you still wouldnt pass the not safe outside of Gentoo Linux profiles. also, although the overhead is minor, the build id section would serve no useful purpose that i can think once it has been merged. gnu hash however is always used at runtime. -mike
Re: [gentoo-dev] /bin and /sbin to /usr
On Tue, Aug 10, 2010 at 7:22 AM, Eray Aslan wrote:
net-firewall/iptables-1.4.6 /sbin/iptables-multi
linux-vdso.so.1 = (0x7fffc77e8000)
libip4tc.so.0 = /usr/lib/libip4tc.so.0 (0x7f27e4781000)
libxtables.so.4 = /usr/lib/libxtables.so.4 (0x7f27e4579000)
libm.so.6 = /lib/libm.so.6 (0x7f27e42f8000)
libc.so.6 = /lib/libc.so.6 (0x7f27e3f9f000)
libdl.so.2 = /lib/libdl.so.2 (0x7f27e3d9b000)
/lib64/ld-linux-x86-64.so.2 (0x7f27e4988000)
file a bug. probably an oversight on my part.
sys-apps/hal-0.5.14-r2 /sbin/umount.hal
linux-vdso.so.1 = (0x7fff6b5f3000)
libhal.so.1 = /usr/lib/libhal.so.1 (0x7fd52e637000)
libhal-storage.so.1 = /usr/lib/libhal-storage.so.1
(0x7fd52e42c000)
libdbus-1.so.3 = /usr/lib/libdbus-1.so.3 (0x7fd52e1ec000)
libc.so.6 = /lib/libc.so.6 (0x7fd52de93000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7fd52dc77000)
librt.so.1 = /lib/librt.so.1 (0x7fd52da6e000)
/lib64/ld-linux-x86-64.so.2 (0x7fd52e848000)
file a bug. hal places its umount binary in / only because
historically, `mount` has been stupid and only searched that path, not
because it was needed early. since ive fixed util-linux though, the
hal mount helpers should be moved to /usr.
2. Is the below acceptable? (symlinking from /bin to /usr/bin)
it depends
# ls -l $(find {/bin,/sbin}/ -type l)|grep /usr
lrwxrwxrwx 1 root root 20 Oct 28 2008 /bin/igawk -
/usr/bin/igawk-3.1.6
lrwxrwxrwx 1 root root 20 Oct 28 2008 /bin/pgawk -
/usr/bin/pgawk-3.1.6
file a bug so i can fix gawk
lrwxrwxrwx 1 root root 14 Aug 10 13:29 /bin/mail - /usr/bin/mailx
/bin/mail is kept for compatibility with random admin scripts (both
packaged and custom). not a big deal as anyone who needs to send mail
isnt going to have /usr missing. i'd forget about this and work on
something else.
-mike
Re: [gentoo-dev] /bin and /sbin to /usr
On Tue, Aug 10, 2010 at 10:01 AM, Paweł Hajdan, Jr. wrote:
On 8/10/10 4:22 AM, Eray Aslan wrote:
1. Is this OK or should we file bugs against binaries in {/bin,/sbin} linking
against libraries in /usr/lib? Fix is relatively easy in general (give
--libdir=/lib against the config script)
I'd suggest a fix that is guaranteed to work: make portage refuse to
install anything in /bin that depends on /usr (based on say ldd check).
not a chance. some of the reasons why this isnt realistic:
- ldd is not portable
- ldd *executes* things
- ldd cannot easily/sanely handle a mix of installed system paths and
temporary paths ($D)
- ldd will not work with cross-compiling
- ldd shows the entire dependency tree, not just the program in
question ... so one broken library can easily cause other packages to
be flagged
- even if ldd showed only direct dependencies, one broken library
package could break the packages that use it
- prevents historical compat links that are otherwise irrelevant
- the vast majority of the time, users dont give a sh*t, and this
doesnt affect them -- people who do a sep /usr mount from / are a
small fraction
-mike
[gentoo-dev] nsbrowser plugins
Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins. However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's what many software projects (including Chromium) target. Why are we using nsbrowser/plugins instead of mozilla/plugins, and how relalistic would it be to switch to mozilla/plugins? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
It seems like few of our fellow developers don't know how to track down packages that don't respect LDFLAGS. Adding -Wl,--hash-style=gnu is a good way to do that. I would like to see this linker flag enabled by default on LDFLAGS (or at least for the dev/ profiles for now). Do you agree? I would really really *really* appreciated if our beloved arch testers ( at least for linux amd64/x86 because they are the first who stabilize a package ) make this default on their build boxes. It is annoying to mark a package stable when it has *clear* QA problems. Please make your build box stricter on QA rules and don't mark a package stable that easy. Marking a package stable with multiple QA warnings, is forcing QA team to either fix a *stable* package, which is violating the policy, or doing some useless revbumps to fix QA issues which shouldn't be there if arch testers did actual testing at the first place 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 pgpkYFvm4C36K.pgp Description: PGP signature
[gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Tue, Aug 10, 2010 at 5:53 PM, Markos Chandras wrote: It seems like few of our fellow developers don't know how to track down packages that don't respect LDFLAGS. Adding -Wl,--hash-style=gnu is a good way to do that. I would like to see this linker flag enabled by default on LDFLAGS (or at least for the dev/ profiles for now). Do you agree? I would really really *really* appreciated if our beloved arch testers ( at least for linux amd64/x86 because they are the first who stabilize a package ) make this default on their build boxes. 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 is annoying to mark a package stable when it has *clear* QA problems. please dont blow this out of proportion. two points: - stabilizing newer versions of a package when there is no QA regression is fine. - ignoring LDFLAGS, while incorrect, is rarely going to lead to broken packages being emerged on end users' systems. ignoring CFLAGS/CXXFLAGS however is much more likely to result in problems for end users when working with multilib or cross builds. -mike
Re: [gentoo-dev] nsbrowser plugins
On Tue, Aug 10, 2010 at 7:28 PM, Jeroen Roovers wrote: On Tue, 10 Aug 2010 14:29:20 -0700 Paweł Hajdan, Jr. wrote: Why are we using nsbrowser/plugins instead of mozilla/plugins, and how relalistic would it be to switch to mozilla/plugins? --- nsplugins.eclass 1 May 2009 23:03:00 - 1.24 +++ nsplugins.eclass 10 Aug 2010 23:21:19 - -PLUGINS_DIR=nsbrowser/plugins +PLUGINS_DIR=mozilla/plugins You would then need to re-emerge all users of this eclass. All I want to ask is why? In fact *most browsers* have no trouble finding plugins, and provide options through which you can inform them where the plugins might be. What's bugging Chromium? Why does it insist on using a competing browser vendor's name instead of the much more neutral nsbrowser, which generally denotes browsers with a Netscape style plugin interface? indeed. we've been using nsbrowser/plugins literally for 8 years and no one has complained. i dont think mozilla is an improvement over nsbrowser. -mike
Re: [gentoo-dev] nsbrowser plugins
On Tue, 10 Aug 2010 14:29:20 -0700
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins.
However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's
what many software projects (including Chromium) target.
Could you name them? Opera looks into tons of directories.
Why are we using nsbrowser/plugins instead of mozilla/plugins, and how
relalistic would it be to switch to mozilla/plugins?
Index: nsplugins.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/nsplugins.eclass,v
retrieving revision 1.24
diff -u -B -r1.24 nsplugins.eclass
--- nsplugins.eclass1 May 2009 23:03:00 - 1.24
+++ nsplugins.eclass10 Aug 2010 23:21:19 -
@@ -10,7 +10,7 @@
DESCRIPTION=Based on the ${ECLASS} eclass
-PLUGINS_DIR=nsbrowser/plugins
+PLUGINS_DIR=mozilla/plugins
# This function move the plugin dir in src_install() to
# ${D}/usr/$(get_libdir)/${PLUGIN_DIR}. First argument should be
You would then need to re-emerge all users of this eclass.
All I want to ask is why? In fact *most browsers* have no trouble
finding plugins, and provide options through which you can inform them
where the plugins might be.
What's bugging Chromium? Why does it insist on using a competing
browser vendor's name instead of the much more neutral nsbrowser,
which generally denotes browsers with a Netscape style plugin interface?
jer
Re: [gentoo-dev] nsbrowser plugins
On 8/10/10 4:28 PM, Jeroen Roovers wrote: Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins. However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's what many software projects (including Chromium) target. Could you name them? Opera looks into tons of directories. Sorry, I used a weasel word many software projects without naming them. I don't know packages other than www-client/chromium that would have problems with this. You would then need to re-emerge all users of this eclass. I see. This puts some burden for our users with no obvious gains. What's bugging Chromium? Why does it insist on using a competing browser vendor's name instead of the much more neutral nsbrowser, which generally denotes browsers with a Netscape style plugin interface? Well, the fact that every distributions chooses its own directory for NPAPI plugins is sort of sad. The number of directories that have to be searched for plugins is ridiculously long. I was talking with Evan Martin, a Chromium developer, and he asked whether Gentoo could switch to mozilla/plugins, so I started this thread. After the results, my patch to add nsbrowser/plugins to the plugins search path is probably going to be accepted. By the way, I just wonder... why not _symlink_ mozilla/plugins to nsbrowser/plugins? That would solve the technical problem, while keeping a good, more general name. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] nsbrowser plugins
On Tue, Aug 10, 2010 at 11:50 PM, Paweł Hajdan, Jr. wrote: By the way, I just wonder... why not _symlink_ mozilla/plugins to nsbrowser/plugins? That would solve the technical problem, while keeping a good, more general name. some plugins like to change their behavior based on the path they're loaded from ... -mike
Re: [gentoo-dev] nsbrowser plugins
On Wednesday 11 of August 2010 05:50:47 Paweł Hajdan, Jr. wrote: On 8/10/10 4:28 PM, Jeroen Roovers wrote: Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins. However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's what many software projects (including Chromium) target. Could you name them? Opera looks into tons of directories. Sorry, I used a weasel word many software projects without naming them. I don't know packages other than www-client/chromium that would have problems with this. You would then need to re-emerge all users of this eclass. I see. This puts some burden for our users with no obvious gains. What's bugging Chromium? Why does it insist on using a competing browser vendor's name instead of the much more neutral nsbrowser, which generally denotes browsers with a Netscape style plugin interface? Well, the fact that every distributions chooses its own directory for NPAPI plugins is sort of sad. The number of directories that have to be searched for plugins is ridiculously long. I was talking with Evan Martin, a Chromium developer, and he asked whether Gentoo could switch to mozilla/plugins, so I started this thread. After the results, my patch to add nsbrowser/plugins to the plugins search path is probably going to be accepted. By the way, I just wonder... why not _symlink_ mozilla/plugins to nsbrowser/plugins? That would solve the technical problem, while keeping a good, more general name. How about asking Evan Martin (and other browser developers) to add means to specify netscape plugin paths for plugin lookup, either as UI element or at compilation time. The former is exactly what konqueror provides for instance on so it can scan for plugins in many locations (including ~/ for some private/local plugins). Hardcoding paths is a bad design™. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] nsbrowser plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/2010 11:40 PM, Mike Frysinger wrote: On Tue, Aug 10, 2010 at 11:50 PM, Paweł Hajdan, Jr. wrote: By the way, I just wonder... why not _symlink_ mozilla/plugins to nsbrowser/plugins? That would solve the technical problem, while keeping a good, more general name. some plugins like to change their behavior based on the path they're loaded from ... -mike Why can chromium not do like firefox and others and make the plugins dir scalable via a wrapper script. You should be able to pass system plugins dir from a wrapper script upon launch this is possible in firefox; this is possible in firefox but easier to just sed the change myself via ebuild and be done with it. - -- == Jory A. Pratt anarchy -at- gentoo.org Gentoo Mozilla Lead GPG: 2C1D 6AF9 F35D 5122 0E8F 9123 C270 3B43 5674 6127 == -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxiLRUACgkQwnA7Q1Z0YSfn9gCePKvoZapicRLFHcTdHKOgYr+w rZ8AoJqxLVzJXTxOxZpgA3R7E/61uZIx =OmsL -END PGP SIGNATURE-
