Re: Fw: [gentoo-dev] Gentoo Enterprise 10000 support and developer access
Raúl Porcel wrote: From yesterday: PROMLIB: Sun IEEE Boot Prom 3.2.9 2001/08/21 20:14 <4>Linux version 2.4.31 ([EMAIL PROTECTED]) (gcc version 3.3.6 (Gentoo Linux 3.3.6)) #4 Sun Jul 17 13:51:21 MDT 2005 <4>ARCH: SUN4U Linux version 2.4.31 ([EMAIL PROTECTED]) (gcc version 3.3.6 (Gentoo Linux 3.3.6)) #4 Sun Jul 17 13:51:21 MDT 2005 <4>ARCH: SUN4U ARCH: SUN4U Ethernet address: 00:00:be:a6:6e:05 Remapping the kernel... done. You're using a really old netboot image. Try with http://gentoo.osuosl.org/experimental/sparc/tftpboot/sparc64/netboot-sparc64-20070724.img or http://dev.gentoo.org/~agaffney/sparc/misc/gentoo-sparc64-20071227.tftpboot I had tried those too actually, started with the newest of course. Yesterday I just reattempted where I had left off..the oldest. Thanks though! I need to rack down Dave Miller and get his attention. Which is probably going to be difficult heh. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: bzr.eclass into Portage
Hi, René 'Necoro' Neumann <[EMAIL PROTECTED]>: > I guess this fix will make it into bzr-1.4. Should the eclass then > depend on this version or should it still not allow the lp:-scheme? This eclass is still experimental...but I am all for raising the version requirement and allow as much features as possible. Let's wait for 1.4 then. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Testing to see if services have crashed on hardened
On 21-03-2008 12:07:24 +, Roy Marples wrote: > On Friday 21 March 2008 10:37:11 Fabian Groffen wrote: > > Assuming you would use libkvm, on Darwin this means as unprivileged user > > (not using suid) you can't see any processes at all. > > That's different from FreeBSD and NetBSD then. Indeed. And I just found out that Leopard (10.5) dropped the entire kvm which wasn't working to funky anyway. I just made some implementation of walking through all running processes for portage-utils' `qlop -c` using sysctl calls -- the way to do it on Darwin, and that works even as normal unprivileged user, so I guess we can just use that. > > Is there a way to just have some fallback method which is less > > functional, but just uses some pid file with a lock or something? > > Not all services use pidfiles. Also, some services re-fork and re-write their > pidfiles and I'm not sure the lock would carry across in that instance. I was thinking of a wrapping process, but I only later realised that this isn't working since many/most daemons fork into the background, so you loose the control over it anyway. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: bzr.eclass into Portage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann schrieb: | Hi, | | Christian Faulhammer schrieb: | | We have a prior version for some time now in the Emacs overlay for two | | live ebuilds...so we go and merge your changed (ulm already did), test | | it and report any problems. | | I just copied the bzr.eclass from the desctop-effects overlay over to my | own one. And I had to find out, that bzr fails when updating an ebuild | which uses the "lp:" address scheme[1]. So perhaps, the support for this | scheme should be removed until it is fixed. | | Regards, | Necoro | | [1] https://bugs.launchpad.net/bzr/+bug/181945 Ok - seems like it got fixed in the meantime ... (bug is open for several months --- and then gets fixed minutes after I post here ... ;)) I guess this fix will make it into bzr-1.4. Should the eclass then depend on this version or should it still not allow the lp:-scheme? Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6Rfv4UOg/zhYFuARAsgFAJoDn9csUloGQxZ4tHhInKxQ2LvkTwCeJRg0 xNqxCP0FbbgG22At64IcovU= =G5Er -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC & baselayout-2 meets Gentoo
On Monday 24 March 2008, Doug Goldstein wrote: > Mike Frysinger wrote: > > On Monday 24 March 2008, Doug Goldstein wrote: > >> /etc/modules.autoload.d has always allowed module parameters to appear > >> after the module name. > >> > >> /etc/conf.d/modules has allowed a completely different syntax requiring > >> variables based on the module name to be set with the module parameters. > >> > >> This is where Roy and I have been stuck as far as an automatic > >> conversion process. The stuff you included in the openrc- ebuild was > >> something I had sent to Roy months ago before I realized module > >> parameters would be an issue. Looking at a swath of various > >> /etc/modules.autoload.d/ files, I haven't come up with shell code that > >> does the right thing everytime with all the files, which is why I've > >> left it up to being a manual process for the user and simply documenting > >> it. > > > > expecting users to read and do it themselves is certainly a path to > > destruction for many. while i could have written it in shell, i just did > > it in awk. i hope you're just overstating things when you say months, > > because FIXED:INCVS. > > > > we're going to need to extend the syntax anyways to allow for > > per-version-per-module arguments. unless openrc does that now ... Roy ? > > Currently OpenRC does not support per-version-per-module arguments. What > is your proposed syntax? i'd assume logically extended based on existing behavior. Roy's done it now though. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] OpenRC & baselayout-2 meets Gentoo
On Tuesday 25 March 2008, Roy Marples wrote: > On Monday 24 March 2008 22:03:48 Mike Frysinger wrote: > > we're going to need to extend the syntax anyways to allow for > > per-version-per-module arguments. unless openrc does that now ... Roy ? > > It now supports per module per kernel version arguments. thanks ... ebuild now prefers that form: modules__args_= -mike signature.asc Description: This is a digitally signed message part.
Re: Fw: [gentoo-dev] Gentoo Enterprise 10000 support and developer access
From yesterday: PROMLIB: Sun IEEE Boot Prom 3.2.9 2001/08/21 20:14 <4>Linux version 2.4.31 ([EMAIL PROTECTED]) (gcc version 3.3.6 (Gentoo Linux 3.3.6)) #4 Sun Jul 17 13:51:21 MDT 2005 <4>ARCH: SUN4U Linux version 2.4.31 ([EMAIL PROTECTED]) (gcc version 3.3.6 (Gentoo Linux 3.3.6)) #4 Sun Jul 17 13:51:21 MDT 2005 <4>ARCH: SUN4U ARCH: SUN4U Ethernet address: 00:00:be:a6:6e:05 Remapping the kernel... done. You're using a really old netboot image. Try with http://gentoo.osuosl.org/experimental/sparc/tftpboot/sparc64/netboot-sparc64-20070724.img or http://dev.gentoo.org/~agaffney/sparc/misc/gentoo-sparc64-20071227.tftpboot -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC & baselayout-2 meets Gentoo
On Monday 24 March 2008 22:03:48 Mike Frysinger wrote: > we're going to need to extend the syntax anyways to allow for > per-version-per-module arguments. unless openrc does that now ... Roy ? It now supports per module per kernel version arguments. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Updated GLEP 46: Allow upstream tags in metadata.xml (again)
Hi there Sorry for the delay but I was busy organizing our booth at the OpenExpo in Bern. You can find the updated GLEP46 here: http://dev.gentoo.org/~dev-zero/glep-0046.txt Difference in words --- Restriction to http/https has been dropped as pointed out by council members (amne and Flameeyes if I'm right). The point for restricting the URLs to the mentioned protocols was that they shouldn't link to automatically updated ressources. This has been replaced by an explicit specification and a recommandation that http/http should be favoured over ftp/svn/gopher/etc to make the implementation for automated update discovery tools easier (they should of course ignore URLs they can't handle). `cvs diff` -- Index: glep-0046.txt === RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/glep-0046.txt,v retrieving revision 1.4 diff -r1.4 glep-0046.txt 80,81c80,90 < ``changelog`` should contain a URL prefixed with ``http://`` or < ``https://`` where the location of the upstream changelog can be found. --- > ``changelog`` should contain a URL where the location of the upstream > changelog can be found. The URL must be version independent and must point to > a changelog which is only updated on new releases of the corresponding > package. (This also implies that one can link to an automatically updated > changelog in case of vcs snapshots only.) > > ``doc`` should contain a URL where the location of the upstream > documentation can be found. The link must not point to any third party > documentation and must be version independent. If the documentation is > available in more than one language, a ``lang`` attribute can be used > which follows the same rules as the one for ``longdescription``. 83,92c92,93 < ``doc`` should contain a URL prefixed with with ``http://`` or < ``https://`` where the location of the upstream documentation can be found. < The link must not point to any third party documentation and must be version < independent. If the documentation is available in more than one language, a < ``lang`` attribute can be used which follows the same rules as the one < for ``longdescription``. < < ``bugs-to`` should contain a place where bugs can be filed, a URL < prefixed with ``http://`` or ``https://`` or an e-mail address prefixed < with ``mailto:``. --- > ``bugs-to`` should contain a place where bugs can be filed, a URL or an > e-mail address prefixed with ``mailto:``. 106c107 < in ``metadata/dtd/remote-id-tags.dtd``. --- > in ``metadata/dtd/remote-id-tags.dtd`` or ``metadata/dtd/metadata.dtd``. 121c122 < http://foo.bar./doc/index.de.html --- > http://foo.bar/doc/index.de.html 135a137,145 > Notes > = > > The specified URLs must include a protocol as described in RFC 3986. > Furthermore the most common protocol should be used in case of several > possibilities (http should be favoured over https or ftp over gopher or svn, > etc). > > Cheers, Tiziano -- gentoo-dev@lists.gentoo.org mailing list
