[gentoo-dev] Re: gentoo-dev digest, Vol 1 #528 - 13 msgs

[Erik Mathisen]

-----Opprinnelig melding-----
Fra: gentoo-dev-admin@g.o [mailto:gentoo-dev-admin@g.o]På
vegne av gentoo-dev-request@g.o
Sendt: 3. september 2002 09:04
Til: gentoo-dev@g.o
Emne: gentoo-dev digest, Vol 1 #528 - 13 msgs


Send gentoo-dev mailing list submissions to
	gentoo-dev@g.o

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.gentoo.org/mailman/listinfo/gentoo-dev
or, via email, send a message with subject or body 'help' to
	gentoo-dev-request@g.o

You can reach the person managing the list at
	gentoo-dev-admin@g.o

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gentoo-dev digest..."


Today's Topics:

   1. Re: CDRW permissions and devfsd (=?utf-8?q?Yrj=C3=B6=20Hatakka?=)
   2. Gentoo Problems (jkitching@×××××××.com)
   3. Re: CDRW permissions and devfsd (Martin Schlemmer)
   4. Re: ebuild problem (Thomas T. Veldhouse)
   5. CVS read only access (Columbia, Richard)
   6. Re: CDRW permissions and devfsd (Bauno)
   7. Re: ebuild problem (Paul de Vrieze)
   8. optimizing many systems / cflags (Noah Justin Norris)
   9. printing-howto (Dave Gudeman)
  10. Re: CDRW permissions and devfsd (Martin Schlemmer)
  11. Re: CDRW permissions and devfsd (Bauno)
  12. RFC: gentoo emacs elisp ebuilds (Matthew Kennedy)
  13. [Fwd: Re: [gentoo-dev] optimizing many systems / cflags] (Mikko
Moilanen)

--__--__--

Message: 1
From: =?utf-8?q?Yrj=C3=B6=20Hatakka?= <yrjo.hatakka@×××××××.fi>
To: Bauno <bauno@××××××.it>
Subject: Re: [gentoo-dev] CDRW permissions and devfsd
Date: Mon, 2 Sep 2002 20:15:22 +0300
Cc: gentoo-dev@g.o

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 31 August 2002 04:07, Bauno wrote:

>
> I have "sg" compiled as module, and solved the problem with this entry =
in
> devfsd.conf (may be wrapped):
>
> LOOKUP          ^sg.*$      MODLOAD ACTION sg
> REGISTER        ^scsi/host.*/bus.*/target.*/lun.*/generic    PERMISSION=
S
> root.disk 660
>
> It works, even if I'm not sure why :)

Yes, confirmed :) this really works, thanx

- --=20
Linux cartman.linux.home 2.4.19-gentoo-r7 #1 Fri Jul 5 00:45:50 EEST 2002=
 i686=20
AuthenticAMD=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9c5yx6BYkNNMD2uARAuTTAJkBLqDToZwsXElwh8j8F3mZvt1b+QCfTuE+
nZmMDi6fKsR2srUtsWfSOYo=3D
=3DVQBk
-----END PGP SIGNATURE-----



--__--__--

Message: 2
Date: Mon, 2 Sep 2002 13:02:50 -0500 (CDT)
From: jkitching@×××××××.com
To: gentoo-dev@g.o
Subject: [gentoo-dev] Gentoo Problems

Hi, I just installed Gentoo, and when I booted, my modules did not load.  I
had a look in /lib/modules, and the only module there is called "dummy.o" in
drivers/net.  Where did all my modules go and how do I get them back?

....................................
Get your own free email account from
http://www.popmail.com


--__--__--

Message: 3
Subject: Re: [gentoo-dev] CDRW permissions and devfsd
From: Martin Schlemmer <azarah@g.o>
To: =?ISO-8859-1?Q?Yrj=F6?= Hatakka <yrjo.hatakka@×××××××.fi>
Cc: Bauno <bauno@××××××.it>, Gentoo-Dev <gentoo-dev@g.o>
Date: 02 Sep 2002 20:06:45 +0200

On Mon, 2002-09-02 at 19:15, Yrj=F6 Hatakka wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On Saturday 31 August 2002 04:07, Bauno wrote:
>=20
> >
> > I have "sg" compiled as module, and solved the problem with this entry =
in
> > devfsd.conf (may be wrapped):
> >
> > LOOKUP          ^sg.*$      MODLOAD ACTION sg

Tells devfs to load the 'sg' module if /dev/sg* is accessed

> > REGISTER        ^scsi/host.*/bus.*/target.*/lun.*/generic    PERMISSION=
S
> > root.disk 660

Basically just set the permissions to 0660, and ownership to root.disk
when /dev/sg* is registered (the generic scsi module loaded ..)

> >
> > It works, even if I'm not sure why :)
>=20
> Yes, confirmed :) this really works, thanx
>

We have the PERMISSIONS entry in our /etc/devfsd.conf:

-----------------------cut-------------------------------------
# Give the cdrw group write permissions to /dev/sg0
# This is done to have non root user use the burner (scan the scsi bus)
#REGISTER        ^sg0$       PERMISSIONS root.cdrw 660
---------------------------------------------------------------

Just commented by default.  As I always have my generic scsi into
kernel, I am not sure that first line is really needed, as there is an
alias in /etc/modules.devfs.  Will try to find the time though to
verify it.
=20


> - --=20
> Linux cartman.linux.home 2.4.19-gentoo-r7 #1 Fri Jul 5 00:45:50 EEST 2002=
 i686=20
> AuthenticAMD=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>=20
> iD8DBQE9c5yx6BYkNNMD2uARAuTTAJkBLqDToZwsXElwh8j8F3mZvt1b+QCfTuE+
> nZmMDi6fKsR2srUtsWfSOYo=3D
> =3DVQBk
> -----END PGP SIGNATURE-----
>=20
>=20
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@g.o
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
--=20

Martin Schlemmer
Gentoo Linux Developer, Desktop Team Developer
Cape Town, South Africa



--__--__--

Message: 4
From: "Thomas T. Veldhouse" <veldy@×××××.net>
To: "Paul de Vrieze" <pauldv@××××××.nl>, <gentoo-dev@g.o>
Subject: Re: [gentoo-dev] ebuild problem
Date: Mon, 2 Sep 2002 13:46:20 -0500

It would probably help if you ran the ebuild as root :)

Tom Veldhouse

----- Original Message -----
From: "Paul de Vrieze" <pauldv@××××××.nl>
To: <gentoo-dev@g.o>
Sent: Monday, September 02, 2002 3:07 AM
Subject: Re: [gentoo-dev] ebuild problem


On Saturday 31 August 2002 21:54, mschroer wrote:
> I am new to Gentoo and having trouble with an ebuild.  I put the latest
> tarball of anjuta-0.9.99.tar.gz in the distfile directory and built a
> new ebuild file from the anjuta-0.1.9.ebuild.  When I emerge, running as
> root, I get the following error:
>
> ******** all the unpack and compile seem to work fine and the image is
> built in var///  and I get to here *******
>
> make  install-man1
> make[3]: Entering directory
> `/var/tmp/portage/anjuta-0.9.99/work/anjuta-0.9.99/doc'
> /bin/sh ../mkinstalldirs /usr/share/man/man1
>  /bin/install -c -m 644 ./anjuta.1 /usr/share/man/man1/anjuta.1
> ACCESS DENIED  open_wr:   /usr/share/man/man1/anjuta.1
> /bin/install: cannot create regular file `/usr/share/man/man1/anjuta.1':
> Permission denied
>  /bin/install -c -m 644 ./anjuta_launcher.1
> /usr/share/man/man1/anjuta_launcher.1
> ACCESS DENIED  open_wr:   /usr/share/man/man1/anjuta_launcher.1
> /bin/install: cannot create regular file
> `/usr/share/man/man1/anjuta_launcher.1': Permission denied
> make[3]: *** [install-man1] Error 1
> make[3]: Leaving directory
> `/var/tmp/portage/anjuta-0.9.99/work/anjuta-0.9.99/doc'
> make[2]: *** [install-man] Error 2
> make[2]: Leaving directory
> `/var/tmp/portage/anjuta-0.9.99/work/anjuta-0.9.99/doc'
> make[1]: *** [install-am] Error 2
> make[1]: Leaving directory
> `/var/tmp/portage/anjuta-0.9.99/work/anjuta-0.9.99/doc'
> make: *** [install-recursive] Error 1
>
> !!! ERROR: The ebuild did not complete successfully.
> !!! Function src_install, Line 8, Exitcode 2
> !!! (no error message)
>
> --------------------------- ACCESS VIOLATION SUMMARY
> ---------------------------
> LOG FILE = "/tmp/sandbox-anjuta-0.9.99-23571.log"
>
> open_wr:   /usr/share/man/man1/anjuta.1
> open_wr:   /usr/share/man/man1/anjuta_launcher.1
> --------------------------------------------------------------------------
-
>----- !!! emerge aborting on
> /usr/portage/dev-util/anjuta/anjuta-0.9.99.ebuild .
>
>
> Can anyone help me ?
>

The trick is that portage uses sandboxing. This means building is only
allowed
in /var/tmp/portage/<bla>

This means you must persuade anjuta to install in the destination root which
is given in an ebuild by ${D}. This technique makes it a lot easier to track
which files should become part of the package.

Oftern this persuading can be done with the DESTDIR variable, but sometimes
further tricks are nescesary. I advise you to look at some ebuilds (look for
PREFIX=${D}/usr/ ), and check the makefile of anjuta.

Paul

--
Paul de Vrieze
Junior Researcher
Mail: pauldv@××××××.nl
Homepage: http://www.devrieze.net

_______________________________________________
gentoo-dev mailing list
gentoo-dev@g.o
http://lists.gentoo.org/mailman/listinfo/gentoo-dev




--__--__--

Message: 5
Date: Mon, 2 Sep 2002 14:53:53 -0400
From: "Columbia, Richard" <richc@××××××××××××××××××.cc>
To: <gentoo-dev@g.o>
Subject: [gentoo-dev] CVS read only access

I am interested in attempting to port Gentoo to an Alpha Box.  I feel
that the easiest way to begin is to get read access to the the cvs
repository.  I have read the FAQ regaurding anonymous cvs access but it
appears that the site no longer allows such access.  Any help would be
greatly appreaciated.

Thank you
Rich Columbia


--__--__--

Message: 6
From: Bauno <bauno@××××××.it>
Organization: Bauno Engineering
To: Martin Schlemmer <azarah@g.o>
Subject: Re: [gentoo-dev] CDRW permissions and devfsd
Date: Mon, 2 Sep 2002 21:03:18 +0200
Cc: gentoo-dev@g.o

On Monday 02 September 2002 20:06, Martin Schlemmer wrote:
> We have the PERMISSIONS entry in our /etc/devfsd.conf:
>
> -----------------------cut-------------------------------------
> # Give the cdrw group write permissions to /dev/sg0
> # This is done to have non root user use the burner (scan the scsi bus)
> #REGISTER        ^sg0$       PERMISSIONS root.cdrw 660
> ---------------------------------------------------------------
>
> Just commented by default.  As I always have my generic scsi into
> kernel, I am not sure that first line is really needed, as there is an
> alias in /etc/modules.devfs.  Will try to find the time though to
> verify it.

The original line in devfsd.conf (that you report above) doesn't work if =
sg=20
is compiled as module. You need to set the permissions on the=20
scsi/bus/.../generic and not on the symbolic links /dev/sg*. I *think* it=
's=20
because /dev/sg* doesn't exist (yet) when devfsd tries to apply the=20
permissions, but I may be wrong.


--=20
Bauno - Eurydices, oro, properata retexite fata!
"Even now I can feel it. Buried somewhere deep inside. Watching me...=20
waiting. But you know what scares me the most. When I can't fight it=20
anymore. When it takes over. When I totally lose control. I like it."


--__--__--

Message: 7
From: Paul de Vrieze <pauldv@××××××.nl>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] ebuild problem
Date: Mon, 2 Sep 2002 21:07:52 +0200

On Monday 02 September 2002 20:46, Thomas T. Veldhouse wrote:
> It would probably help if you ran the ebuild as root :)
>
> Tom Veldhouse

Portage doesn't even try to run as non-root, he is just being sandboxed

Paul

--=20
Paul de Vrieze
Junior Researcher
Mail: pauldv@××××××.nl
Homepage: http://www.devrieze.net


--__--__--

Message: 8
From: Noah Justin Norris <gentoo@×××××.com>
Date: Mon, 2 Sep 2002 14:52:38 +0000
To: gentoo-dev@g.o
Subject: [gentoo-dev] optimizing many systems / cflags

what optimizing would i use for the following system i would like to run =
the
fastest as possible, im gona include processor speed and memory for each
system i would like to know for gentoo 1.2 and 1.4 optimzations ( i curre=
ntly
run gentoo 1.2 on all systems )
1. anthlon tbird 900 mhz 256 mb ram
2. pentuim 3 450 mhz 256 mb ram
3. amd k6-2 500 128 mb ram
4. pentuim 2 (laptop) 366 mhz 196 mb ram
5. amd k6-2 366 mhz 128 mb ram
6. 2 dual pentuim 133's both have 64 mb ram
7. pentuim 233 mmx 96 mb ram
8.  dual pentuim 2 350 mhz 256 mb ram
and many more ( not mentioned cause would be repeats of above ) including
power pc's which i have not messed with yet
--
life is linux
linux is life
_______________________________________________
gentoo-user mailing list
gentoo-user@g.o
http://lists.gentoo.org/mailman/listinfo/gentoo-user

-------------------------------------------------------

--=20
life is linux=20
linux is life=20

--__--__--

Message: 9
Date: Mon, 02 Sep 2002 14:02:17 +0000
From: Dave Gudeman <base@××××××××××××××××××××.net>
To: gentoo-dev@g.o
Subject: [gentoo-dev] printing-howto

I just did a printer install with a parport printer. It was a nightmare=20
because I was trying to do it without reading all the necessary=20
documentation, and the gentoo printing-howto didn't help since it made th=
e=20
same wrong assumption I did: that the printer device is /dev/lp0. I think=
=20
there is some devfs compatibility mode where this works, but in general w=
ith=20
devfs the printer is at /dev/printers/0. Once I discovered this, magic=20
happened.

Anyway, you might want to add the following to the printing-howto:
--------------
The device for the printer is /dev/printers/0, not /dev/lp0 (unless you h=
ave=20
the devfs compatibility stuff).

To activate the modules for parallel port printers:

  insmod parport
  insmod parport_pc
  insmod lp

However, you should probably mention that module autoloading will take ca=
re of=20
this once you get cups set up, I thought originally that I had to add the=
se=20
to modules.autoload or something similar.

You don't have to do anything special for KDE, they automatically recogni=
ze=20
cups printers.


--__--__--

Message: 10
Subject: Re: [gentoo-dev] CDRW permissions and devfsd
From: Martin Schlemmer <azarah@g.o>
To: Bauno <bauno@××××××.it>
Cc: Gentoo-Dev <gentoo-dev@g.o>
Date: 03 Sep 2002 02:37:13 +0200

On Mon, 2002-09-02 at 21:03, Bauno wrote:
> On Monday 02 September 2002 20:06, Martin Schlemmer wrote:
> > We have the PERMISSIONS entry in our /etc/devfsd.conf:
> >
> > -----------------------cut-------------------------------------
> > # Give the cdrw group write permissions to /dev/sg0
> > # This is done to have non root user use the burner (scan the scsi bus)
> > #REGISTER        ^sg0$       PERMISSIONS root.cdrw 660
> > ---------------------------------------------------------------
> >
> > Just commented by default.  As I always have my generic scsi into
> > kernel, I am not sure that first line is really needed, as there is an
> > alias in /etc/modules.devfs.  Will try to find the time though to
> > verify it.
>
> The original line in devfsd.conf (that you report above) doesn't work if
sg
> is compiled as module. You need to set the permissions on the
> scsi/bus/.../generic and not on the symbolic links /dev/sg*. I *think*
it's
> because /dev/sg* doesn't exist (yet) when devfsd tries to apply the
> permissions, but I may be wrong.
>

No, the REGISTER means it only gets done when the /dev/sg0 device is
registered in the devfs namespace.  The only real difference between
that line, and:

REGISTER        ^sg.*$       PERMISSIONS root.disk 660

is that above works for *all* /dev/sg* devices, and have group as "disk"
and not "cdrw".  devfsd knows to give the permissions to the real device
in a line such as above.

The real fix for modules, is the line:

LOOKUP          ^sg.*$      MODLOAD ACTION sg

which cause the "sg" module to be loaded when you "lookup" (try to
open) /dev/sg*

>
> --
> Bauno - Eurydices, oro, properata retexite fata!
> "Even now I can feel it. Buried somewhere deep inside. Watching me...
> waiting. But you know what scares me the most. When I can't fight it
> anymore. When it takes over. When I totally lose control. I like it."
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@g.o
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
--

Martin Schlemmer
Gentoo Linux Developer, Desktop Team Developer
Cape Town, South Africa



--__--__--

Message: 11
From: Bauno <bauno@××××××.it>
Organization: Bauno Engineering
To: Martin Schlemmer <azarah@g.o>
Subject: Re: [gentoo-dev] CDRW permissions and devfsd
Date: Tue, 3 Sep 2002 03:04:08 +0200
Cc: gentoo-dev@g.o

On Tuesday 03 September 2002 02:37, Martin Schlemmer wrote:
> > [snipped]
> > The original line in devfsd.conf (that you report above) doesn't work
> > if sg is compiled as module. You need to set the permissions on the
> > scsi/bus/.../generic and not on the symbolic links /dev/sg*. I *think=
*
> > it's because /dev/sg* doesn't exist (yet) when devfsd tries to apply
> > the permissions, but I may be wrong.
>
> No, the REGISTER means it only gets done when the /dev/sg0 device is
> registered in the devfs namespace. =20
>=20
> The real fix for modules, is the line:
>
> LOOKUP          ^sg.*$      MODLOAD ACTION sg
>
> which cause the "sg" module to be loaded when you "lookup" (try to
> open) /dev/sg*

I really don't think so (everything's wrapped):

Default Gentoo style:

------------------devfsd.conf--------------------------------------------=
---

# Give the cdrw group write permissions to /dev/sg0
# This is done to have non root user use the burner (scan the scsi bus)
LOOKUP          ^sg.*$      MODLOAD ACTION sg
#REGISTER        ^scsi/host.*/bus.*/target.*/lun.*/generic    PERMISSIONS=
=20
root.disk 660
REGISTER        ^sg.*$       PERMISSIONS root.disk 660

--------------devfsd.conf------------------------------------------------=
---

bauniga root # modprobe sg
bauniga root # ll /dev/scsi/host0/bus0/target0/lun0/generic
crw-r-----    1 root     root      21,   0 Jan  1  1970=20
/dev/scsi/host0/bus0/target0/lun0/generic
bauniga root # killall -HUP devfsd
bauniga root # ll /dev/scsi/host0/bus0/target0/lun0/generic
crw-rw----    1 root     disk      21,   0 Jan  1  1970=20
/dev/scsi/host0/bus0/target0/lun0/generic




Bauno :) style:

----------------------------devfsd.conf----------------------------------=
--
# Give the cdrw group write permissions to /dev/sg0
# This is done to have non root user use the burner (scan the scsi bus)
LOOKUP          ^sg.*$      MODLOAD ACTION sg
REGISTER        ^scsi/host.*/bus.*/target.*/lun.*/generic    PERMISSIONS=20
root.disk 660
#REGISTER        ^sg.*$       PERMISSIONS root.disk 660
--------------devfsd.conf------------------------------------------------=
---

bauniga root # modprobe sg
bauniga root # ll /dev/scsi/host0/bus0/target0/lun0/generic
crw-rw----    1 root     disk      21,   0 Jan  1  1970=20
/dev/scsi/host0/bus0/target0/lun0/generic


So, I think the Gentoo default devfsd.conf isn't well suited for the sg=20
module....

--=20
Bauno - Eurydices, oro, properata retexite fata!
"Even now I can feel it. Buried somewhere deep inside. Watching me...=20
waiting. But you know what scares me the most. When I can't fight it=20
anymore. When it takes over. When I totally lose control. I like it."


--__--__--

Message: 12
To: gentoo-dev@g.o, gentoo-user@g.o
From: Matthew Kennedy <mkennedy@g.o>
Date: 03 Sep 2002 02:04:04 -0500
Subject: [gentoo-dev] RFC: gentoo emacs elisp ebuilds


http://www.gentoo.org/~mkennedy/emacs-packages.html

I would like to get people who use Emacs to comment on the above set
of emacs elisp ebuilds. These are being maintained outside of portage
until after Gentoo 1.4 is released.

The goal of this project is to greatly enhance the support of
Emacs/XEmacs in Gentoo's portage.

Points to note:

 * eclasses/elisp.eclass -- especially the scheme for re-generating
   the site-start.el file.
 * the possibility of an /etc/emacs/site.el for site-wide config not
   to be touched by portage (eg. sourced by site-start.el)
 * the app-emacs category -- does it make sense
 * thoughts on adding XEmacs support -- should we/how etc.
 * how much configuration should be done by portage? eg. should we
   just append to the load-path or should we go further and call
   (require 'foo) etc.

I intend to release a new snapshot of app-emacs-*.tar.bz2
periodically, so be sure to check back at the above URL.

Thanks,

Matt

--
Matthew Kennedy
Gentoo Linux Developer
Bugs go to http://bugs.gentoo.org!


--__--__--

Message: 13
Date: Tue, 03 Sep 2002 10:25:48 +0300
From: Mikko Moilanen <baldor@××××××.fi>
To: gentoo-dev@g.o
Subject: [Fwd: Re: [gentoo-dev] optimizing many systems / cflags]

  Time to start correcting mistakes. Message sent to wrong address and
forwarded to correct.

-------- Original Message --------
Subject: Re: [gentoo-dev] optimizing many systems / cflags
Date: Tue, 03 Sep 2002 10:22:15 +0300
From: Mikko Moilanen <baldor@××××××.fi>
To: Noah Justin Norris <gentoo@×××××.com>
References: <200209021452.38441.gentoo@×××××.com>



Noah Justin Norris wrote:

>what optimizing would i use for the following system i would like to run
the
>fastest as possible, im gona include processor speed and memory for each
>3. amd k6-2 500 128 mb ram
>5. amd k6-2 366 mhz 128 mb ram


I use in my Gentoo 1.4 (GCC3.2) something like under.

CHOST="i586-pc-linux-gnu"

CFLAGS="-march=k6-2 -Os -pipe -mmmx -m3dnow"

That -0s means -02 with some optimization to make executable smaller.

CXXFLAGS="${CFLAGS}"

USE="X gtk -gnome -alsa -gpm -svga dvd mozilla gtk2 acl dga directfb"

If you read your "/etc/make.conf" file and "man gcc" you will find some
more information.

--

http://baldor.ath.cx:2000





--

http://baldor.ath.cx:2000




--__--__--

_______________________________________________
gentoo-dev mailing list
gentoo-dev@g.o
http://lists.gentoo.org/mailman/listinfo/gentoo-dev


End of gentoo-dev Digest