Re: [gentoo-dev] Strange behavior of fonts... help :(
On Tue, 2008-03-04 at 20:34 +1300, Alistair Bush wrote: > This is not a support channel and that, while an interesting picture, > provides absolutely no information whatsoever. > Indeed. Please try [EMAIL PROTECTED] and include some useful background information. Matthias signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Strange behavior of fonts... help :(
This is not a support channel and that, while an interesting picture, provides absolutely no information whatsoever. Please don't post to the gentoo-dev ml. Alistair. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] The eight digit limit
PMS currently has the following: > The package manager must not impose fixed limits upon the number of > version components. No integer part of a version specification may > contain more than eight digits. Package managers should indicate or > reject any version that is invalid according to these rules. Historically, Portage had weird bugs for excessively long version parts, especially when leading zeroes were involved, although as far as I'm aware it's clean with arbitrary lengths now. Paludis is clean (and issues a QA notice for violations), but portage-utils fails the whole version handling thing in an epic fashion. Given this, do we still need that restriction in place? There're quite a few violations in the tree. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Google SOC 2008
On Mon, 03 Mar 2008 16:50:49 +0100, Michael Haubenwallner <[EMAIL PROTECTED]> wrote: > For hpux fex this just is adding some symlinks: > /sbin/init.d/name -> /my/prefix/sbin/init.d/distccd > /sbin/rc3.d/S990name -> /sbin/init.d/name # to start in runlevel 3 > /sbin/rc2.d/K100name -> /sbin/init.d/name # to kill for runlevel 2 > > When doing so with OpenRC's main process, it could integrate smoothly > with normal system reboot and start prefixed init.d scripts. Yes, that should work fine if it ends up calling /sbin/init.d/name start and /sbin/init.d/name stop to start and stop it. You just have to somehow inject rc sysinit into the boot process to remove all state data. But a better way would be like so /my/prefix/sbin/rc-wrapper #/bin/sh case "$1" in start) /my/prefix/sbin/rc default;; stop) /my/prefix/sbin/rc single;; esac As you then get OpenRC handling the dependency order if you have >1 service. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Mon, 3 Mar 2008 15:53:20 +0100, Fabian Groffen <[EMAIL PROTECTED]> wrote: > On 03-03-2008 13:36:25 +, Roy Marples wrote: >> On Thursday 28 February 2008 11:22:13 Roy Marples wrote: >> > So the only thing left (aside from bug fixing) is to instruct OpenRC >> > dependency >> > code that it's in a prefix and to respect the noprefix keyword in > services, >> > or >> > to provide dummy services. >> >> This is now done. >> >> I have OpenRC fully working in a prefixed non priviledged install on a > NetBSD >> box. > > Can you define how this is working? Do you just have NetBSD and install > OpenRC in /my/arbitrary/path, or do you have a full set of utilities > under /my/arbitrary/path with OpenRC as one of them? I did this in OpenRC source rm -rf /home/roy/pkg make PREFIX=/home/roy/pkg PKG_PREFIX=/usr/pkg install Create Gentoo style init script in /home/roy/pkg/etc/init.d for say boinc export PATH=$PATH:/home/roy/pkg/bin:/home/roy/pkg/sbin rc-update add boinc default rc default boinc started > >> The only question I have left is what mechanism resets service state, as > the >> prefixed state dir needs will presist between reboots which isn't > desirable. > > startprefix could maybe start some sort of process that lives on, > activated like keychain does, such that multiple startprefix invocations > do not start the system all the time -- if that is desired at all. In > a real scenario it may be just a hook from the host OS's start/stop > mechanism to tell OpenRC in what state it should run. > > If a service such as PostgreSQL is killed (maybe a reboot?) does OpenRC > then know it is not running any more? I guess it does, so that's good > enough, IMO. This needs to be done on startup rc sysinit rc default Which is pretty much what we do in Gentoo anyway. Just ensure that the sysinit runlevel only runs once, as it will remove all state when run again. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Mon, 2008-03-03 at 15:53 +0100, Fabian Groffen wrote: > On 03-03-2008 13:36:25 +, Roy Marples wrote: > > On Thursday 28 February 2008 11:22:13 Roy Marples wrote: > > > So the only thing left (aside from bug fixing) is to instruct OpenRC > > > dependency > > > code that it's in a prefix and to respect the noprefix keyword in > > > services, > > > or > > > to provide dummy services. > > > > This is now done. > > > > I have OpenRC fully working in a prefixed non priviledged install on a > > NetBSD > > box. > > Can you define how this is working? Do you just have NetBSD and install > OpenRC in /my/arbitrary/path, or do you have a full set of utilities > under /my/arbitrary/path with OpenRC as one of them? > > > The only question I have left is what mechanism resets service state, as > > the > > prefixed state dir needs will presist between reboots which isn't desirable. > > startprefix could maybe start some sort of process that lives on, > activated like keychain does, such that multiple startprefix invocations > do not start the system all the time -- if that is desired at all. In > a real scenario it may be just a hook from the host OS's start/stop > mechanism to tell OpenRC in what state it should run. Must admit not having looked at OpenRC yet - maybe I understood sth. wrong, but: +1 for registering OpenRC into host OS's specific init.d mechanism. Here I'm doing so with distccd on ia64-hpux, having some (host OS specific) script in (not yet gentoo-) prefix, understanding additional '--install [name]' - or have a separate command for that. This needs to be run as root once to register into host OS's init.d mechanism. For hpux fex this just is adding some symlinks: /sbin/init.d/name -> /my/prefix/sbin/init.d/distccd /sbin/rc3.d/S990name -> /sbin/init.d/name # to start in runlevel 3 /sbin/rc2.d/K100name -> /sbin/init.d/name # to kill for runlevel 2 When doing so with OpenRC's main process, it could integrate smoothly with normal system reboot and start prefixed init.d scripts. /haubi/ -- Michael Haubenwallner Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On 03-03-2008 13:36:25 +, Roy Marples wrote: > On Thursday 28 February 2008 11:22:13 Roy Marples wrote: > > So the only thing left (aside from bug fixing) is to instruct OpenRC > > dependency > > code that it's in a prefix and to respect the noprefix keyword in services, > > or > > to provide dummy services. > > This is now done. > > I have OpenRC fully working in a prefixed non priviledged install on a NetBSD > box. Can you define how this is working? Do you just have NetBSD and install OpenRC in /my/arbitrary/path, or do you have a full set of utilities under /my/arbitrary/path with OpenRC as one of them? > The only question I have left is what mechanism resets service state, as the > prefixed state dir needs will presist between reboots which isn't desirable. startprefix could maybe start some sort of process that lives on, activated like keychain does, such that multiple startprefix invocations do not start the system all the time -- if that is desired at all. In a real scenario it may be just a hook from the host OS's start/stop mechanism to tell OpenRC in what state it should run. If a service such as PostgreSQL is killed (maybe a reboot?) does OpenRC then know it is not running any more? I guess it does, so that's good enough, IMO. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Thursday 28 February 2008 11:22:13 Roy Marples wrote: > So the only thing left (aside from bug fixing) is to instruct OpenRC > dependency > code that it's in a prefix and to respect the noprefix keyword in services, > or > to provide dummy services. This is now done. I have OpenRC fully working in a prefixed non priviledged install on a NetBSD box. The only question I have left is what mechanism resets service state, as the prefixed state dir needs will presist between reboots which isn't desirable. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Sunday, 2. March 2008, Richard Freeman Ви написали: > George Shapovalov wrote: > > The good thing about this approach is that it only requires an initial > > investment of organizing and automating things but does not add any > > regular work to the devs. In fact, if the "tested" category becomes > > popular enough, it can cut the work for stable testers, may be even by > > something like a factor of 10 eventually (due to less requests for > > explicit stabilizaion being issued).. > > We might also aim to make it easy for users to mix-and-match levels of > stability by package. I know it is possible already, but perhaps it > could be improved, or pre-canned lists of packages that users might > typically want bleeding-edge vs stable could be compiled. Well, we already have "system set" and it is defined in profile. With users being able to define and use their own profiles all that is left to do is to add an ability by portage to use different stability settings for system and out-of-system packages, as the most trivial approach. Of course more complex combinations are possible, but would require a proper discussion. > I think there are a large number of users who wouldn't mind less > stability on packages that won't prevent booting or network-access or > general use of their system. If some nice-to-have utility breaks I > don't mind reverting it, but if baselayout goes haywire I could spend > hours just getting my system to boot. Exactly. I did not mention this in order not to overcomplicate my previous message, but this is one of the things I had in ming for a long time. Besides > I like your idea though. Thanks! Although it is somewhat strange to hear "idea" when it has been an "old news" :) (at least for me), just check the timing of that bug I mentioned above. I merely adapted one of the not-yet-implemented issues discussed there to the present situation. Oh, btw, these two issues (extra stability levels and separate stability rankings for groups of packages) are independant enough to make it possible to implement them separately. George -- gentoo-dev@lists.gentoo.org mailing list
