Hi all,
There is a couple of issues with the Mozilla instructions that I'd
like to get input from anyone interested, or anyone who wants to
suggest an idea. I realize Mozilla may be a thing of the past, now
that Seamonkey is available, but I believe both of these may still
be applicable after a
In the Firefox build instructions, the ownership of the
/usr/lib/firefox-1.5/extensions/[EMAIL PROTECTED]/* files is changed
to root:root. I found I had to change the permissions, too, as they were
rwX for the owner only. So I think the following command should be added
to the build instructions:
Tim van der Molen wrote these words on 02/03/06 10:01 CST:
I found I had to change the permissions, too, as they were
rwX for the owner only. So I think the following command should be added
to the build instructions:
chown -Rv u=rwX,go=rX \
/usr/lib/firefox-1.5/extensions/[EMAIL
On Fri, 03 Feb 2006 17:09:34 +0100, Randy McMurchy wrote:
I am not seeing this. I checked my build script to ensure there are
no commands that change permissions. There are none. Note:
The only reason I can think of at the moment is umask. I built Firefox
with umask 077. Did you run your build
Dear List,
http://www.linuxfromscratch.org/blfs/view/svn/general/libusb.html
has ensure the usb group exits for ensure the usb group exists
Bernard Leak
--
Never resist a cheap shot, it might actually land
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ:
go moko wrote these words on 02/03/06 13:02 CST:
I've installed libxklavier 2.1 as explained in SVN
book, and I took this error during the make:
[snip error stuff]
Well, not very bad warning, but the option -Werror was
passed to gcc.
So, to be able to compile it, I must have do the
go moko wrote:
I've installed libxklavier 2.1 as explained in SVN
book, and I took this error during the make:
Works for me. The same part of my compile log looks like this
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror
-DDATA_DIR=\/usr/share/libxklavier\ -I. -I/usr/include
go moko wrote:
I've installed libxklavier 2.1 as explained in SVN
book, and I took this error during the make:
If you're following the instructions in BLFS, why does it list DDATA_DIR
as /usr/local/share/libxklavier? Why is libxml2 in /usr/local? How else
have you deviated from BLFS?
gcc
On Fri, 03 Feb 2006 19:48:42 +0100, Dan Nicholson wrote:
If you built with umask 077, then didn't the permissions come out
correctly for you?
I'm not sure I understand what you mean. As a result of using a 077
umask, some installed files and directories were accessible only to
root. Which isn't
On 2/3/06, Tim van der Molen [EMAIL PROTECTED] wrote:
On Fri, 03 Feb 2006 19:48:42 +0100, Dan Nicholson wrote:
If you built with umask 077, then didn't the permissions come out
correctly for you?
I'm not sure I understand what you mean. As a result of using a 077
umask, some installed
On Fri, 03 Feb 2006 22:11:44 +0100, Dan Nicholson wrote:
Seems like you're asking
a lot for each package to specifically set the permissions of each
installed file to something that isn't the default of the build user.
Am I? Most packages install files using something like install -m...
or
On 2/3/06, Tim van der Molen [EMAIL PROTECTED] wrote:
On Fri, 03 Feb 2006 22:11:44 +0100, Dan Nicholson wrote:
Seems like you're asking
a lot for each package to specifically set the permissions of each
installed file to something that isn't the default of the build user.
Am I? Most
Dan Nicholson wrote these words on 02/03/06 16:05 CST:
I'd rather just have a dedicated build user with a umask
that creates files with the permissions I want for my system, not my
home directory.
That is exactly what I do. That doesn't make it right or wrong, but
it does provide consistency
Bruce Dubbs wrote:
To do this, we will need to disable adding new bugs and modifying
existing bugs on bugzilla, implement the new system, including importing
all data in the different repositories and then open up the trac ticket
system. There is no need to interrupt svn or the message lists.
Joe Ciccone wrote these words on 02/03/06 16:14 CST:
The DivX site has recent;y gone through some changes and one of which
making this link http://www.divx.com/divx/linux/ invalid. I found this
out when going to install mplayer. DivX for Linux moved here
http://labs.divx.com/DivXLinuxCodec .
On 2/3/06, Joe Ciccone [EMAIL PROTECTED] wrote:
The DivX site has recent;y gone through some changes and one of which
making this link http://www.divx.com/divx/linux/ invalid. I found this
out when going to install mplayer. DivX for Linux moved here
http://labs.divx.com/DivXLinuxCodec .
Joe,
go moko wrote:
I've installed libxklavier 2.1 as explained in SVN
book, and I took this error during the make:
If you're following the instructions in BLFS, why
does it list DDATA_DIR
as /usr/local/share/libxklavier? Why is libxml2 in
/usr/local? How else
have you deviated from BLFS?
Dan Nicholson wrote:
Joe, did you try the new codec yet? I never got to try the old one
because it's 3 years old and it didn't fly with libc.so.6 (IIRC).
Just curious how it stacks up.
I've encoded videos for friends with it on windows. Which worked well,
but I've never tried to use it on
On 2/3/06, Randy McMurchy [EMAIL PROTECTED] wrote:
Okay, you may wonder, why don't we just do like the Firefox
instructions and tell folks that if they have existing plugins in
/usr/lib/mozilla/plugins to copy (create links, whatever) them into
/usr/lib/mozilla-1.7.12/plugins and not worry
Dan Nicholson wrote these words on 02/03/06 17:27 CST:
I prefer this way. What if plugins such as libnullplugin.so are
incompatible between Mozilla-1.7 and Firefox-1.5? I think there's
plenty of information in the book about the plugins. If someone wants
to create a central repo of plugins
On 2/3/06, Randy McMurchy [EMAIL PROTECTED] wrote:
Firefox
and Mozilla each will install their own copy of libnullplugin.so in
the respective plugin directory of each package. Each package uses
its own copy.
OK, I thought you meant that the plugins dirs for each product would
be wiped and a
Randy McMurchy wrote:
This reminds me of something I've been meaning to bring up for a long
time. In the Samba instructions we recommend using Stunnel to encrypt
the use of SWAT, as it requires the root password and it is sent clear
text over the wire if not Stunneled.
Should we also recommend,
22 matches
Mail list logo
