Robin H. Johnson wrote:
On Mon, Jun 08, 2009 at 12:00:59AM +0100, Roy Marples wrote:
Roy: [[ or [?
Entirely depends on system.
OpenRC uses /bin/sh to process the actual init script. We rely on /bin/sh
claiming POSIX compat [1]. On Gentoo Linux systems, this is normally a link
to bash, so you
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing the
version (possible including a git ID) of the release.
that requires us to actually utilize /libexec/ which is not a Linux convention
on any
Mike Frysinger wrote:
On Monday 08 June 2009 06:12:04 Roy Marples wrote:
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing the
version (possible including a git ID) of the release.
that requires
Joe Peterson wrote:
Mike Frysinger wrote:
maybe, but since we arent going to use /libexec/ at this time, that means /etc
is the next best place
How about /usr/share/openrc/version?
The only dirs that are guaranteed to be available at boot are
/dev
/etc
/lib
/bin
/sbin
Plus these OS
Mike Frysinger wrote:
On Monday 08 June 2009 06:35:37 Roy Marples wrote:
Mike Frysinger wrote:
On Monday 08 June 2009 06:12:04 Roy Marples wrote:
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing
Mike Frysinger wrote:
the original discussion made it sound like /etc/openrc-version always existed
independent of libexec
That is incorrect.
Thanks
Roy
Mike Frysinger wrote:
i didnt see any real discussion of /sbin/functions.sh ... i dont recall there
being a reason historically for not checking for this file to detect
baselayout-1 vs openrc, and no one has complained about its usage in mdadm ...
That works as a baselayout-1 vs openrc test.
Mike Frysinger wrote:
if openrc versions are causing a level of incompatibility, then it should
itself be setting up an env var for init.d scripts to key off of rather than
having to figure out what's going on via the filesystem. the point of this
thread is to detect baselayout-1 vs openrc
Mike Frysinger wrote:
On Monday 08 June 2009 09:09:43 Roy Marples wrote:
Mike Frysinger wrote:
if openrc versions are causing a level of incompatibility, then it should
itself be setting up an env var for init.d scripts to key off of rather
than having to figure out what's going on via
Josh Saddler wrote:
Also, if OpenRC/baselayout is dropping support for things like PPP or
ADSL[1], and will not guarantee a stable configuration (i.e. as
final as baselayout-1 has been, not needing constant user-side
updates)[2] . . . then we need to find some other solution for our users.
Robin H. Johnson wrote:
On Mon, Jun 08, 2009 at 12:02:44AM +0200, Ulrich Mueller wrote:
On Sun, 7 Jun 2009, Robin H Johnson wrote:
2. Right now, every init.d script that needs to detection should revbump
and change to the following:
[[ -f /lib/librc.so -o -f /etc/init.d/sysfs -o -f
Robert Buchholz wrote:
On Saturday 23 May 2009, Roy Marples wrote:
Basically as Doug said, each OpenRC version comes with a few big
chances. Well not massive as in your box will break now, but just a
different spin on how things should work. OpenRC-0.5 will have the
biggest re-spin to date
Mike Auty wrote:
Roy Marples wrote:
Attached is the new conf.d/net sample.
Sorry, I missed those. Did lists.g.o remove them, or were they not
attached?
As such, a side project I've started is a new ifconfig tool
[1] to handle everything from vlans, to bridging, to bonding, to
wireless
Alin Năstac wrote:
Doug Goldstein wrote:
The only reason why OpenRC has not come up for stabilization by it's
maintainers is the fact that everytime there's a new version readied
for release, on the horizon there's new incompatible changes being
planned for the next version. The OpenRC
Roy Marples wrote:
One side effect of this is that daemons such was wpa_supplicant and PPP
are now init scripts proper - this is good. The only downside is that
you lose the ability to control each interface via init.d. Instead I
propose you control this via ifconfig.
Uh, so in summary any
On Thursday 19 June 2008 02:43:12 Chris Gianelloni wrote:
Nope. What I see as a problem is that the primary author and current
de facto maintainer is so much of an asshole that he was forcibly
removed from the Gentoo project, which PMS is supposed to be written
for, and has ostracized (at
On Wednesday 11 June 2008 19:00:16 David Leverton wrote:
On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
David Leverton [EMAIL PROTECTED] wrote:
Since at least one ebuild has already been modified specifically to
work around the bug, I'd say it's pretty real.
For those of us
On Monday 09 June 2008 09:06:24 Ciaran McCreesh wrote:
So how, specifically, is PMS wrongly written, and why hasn't anyone
who thinks so bothered to provide details?
Probably because you have such a long history of saying it's broken without
providing any details. Even when asked you sometimes
On Saturday 31 May 2008 00:16:31 Ciaran McCreesh wrote:
Ok, then everything in the tree is covered and we can move to having
--as-needed as default.
Is the next version of everything in the tree covered? Have you made
sure that software isn't merely working by fluke?
We interupt this
On Thursday 24 April 2008 00:01:01 Robin H. Johnson wrote:
The problem in this is that you cannot set the properties for each
address or route. Please don't take us back to the stoneage of writing
the advanced networking configuration manually.
As an example of an ip address line with
On Wednesday 23 April 2008 23:01:38 Graham Murray wrote:
Roy Marples [EMAIL PROTECTED] writes:
On Wednesday 23 April 2008 21:46:18 Robin H. Johnson wrote:
See my attached example from work, we use a lot of the various options
on stuff.
No, we won't support that. However, we will bring
OK, it seems that hard lines in multipart configs seem to be an issue, so I'm
doing this now.
For a summary of why we're using hard lines you can read this thread
http://thread.gmane.org/gmane.linux.gentoo.devel/45756/focus=45765
Basically, just using whitespace to seperate configs is nice and
On Wednesday 23 April 2008 19:46:35 Joe Peterson wrote:
Roy Marples wrote:
config_eth0=1.2.3.4 netmask 255.255.255.0
5.6.7.8 netmask 255.255.0.0
routes_eth0=1.2.4.0 netmask 255.255.255.0 gw 1.2.3.6
5.6.7.9 gw 5.6.7.10
default gw 1.2.3.1
If one choose to separate by lines, will tabs
On Wednesday 23 April 2008 21:46:18 Robin H. Johnson wrote:
On Wed, Apr 23, 2008 at 04:21:27PM +0100, Roy Marples wrote:
OK, it seems that hard lines in multipart configs seem to be an issue, so
I'm doing this now.
For a summary of why we're using hard lines you can read this thread
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
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.
This isn't really an easy answer, as we could have installed
On Friday 21 March 2008 10:44:12 Natanael Copa wrote:
err... run rc-status as root?
I mean if you are not supposed to see if a process is running or not as
normal user, then hardned is doin it's job when does not allow rc-status
to show this info to the unprivileged user.
if (!HARDENED ||
On Friday 21 March 2008 12:39:48 Natanael Copa wrote:
/* pid 1 is most likely owned by root */
hardened = pid_is_running(1);
if (!hardened || (hardened euid==0) {
OK, we'll go with that for the time being.
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
On Thursday 20 March 2008 06:59:24 Josh Saddler wrote:
I'll be working on the migration guide with Cardoe (and possibly Roy, if
we can tag-team him into submission). As much of a pain as migration
will be, we'll definitely need a howto. Fun, fun.
I already provide documentation with commands
On Monday 10 March 2008 05:21:51 Alec Warner wrote:
Did freeBSD not care if you knew what you were doing? What happens if
you totally screw up your package? What happens if you do something
malicious?
Gentoo has a cvs-commit mailing list, so everyone knows if they care enough.
I suggest you
OK, this the only release post I'll make here :)
OpenRC-0.1 has been released. It successfully boots Gentoo/Linux,
Gentoo/FreeBSD, FreeBSD-7 and NetBSD-4. It works (for me) in an unprivileged
prefix as well. It's pretty much feature complete for a first release.
What's left is fixing any
On Wednesday 05 March 2008 17:11:58 Anant Narayanan wrote:
If it's not too late for this month's meeting, I'd like to discuss the
possibility of including a new post in our developer base - the
package maintainer.
a) The requirements to become a package maintainer for Gentoo may be
lesser
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
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
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
On Saturday 01 March 2008 22:26:24 Ed W wrote:
Hmm, all interesting stuff
You mention in the notes also that openrc has some kind of keepalive
function which can restart crashing services. Can point me towards how
that works (assuming it needs some kind of config?)
No such function :)
We
On Friday 29 February 2008 16:15:51 Ed W wrote:
On the other hand since there still isn't a masked ebuild in portage
(and I seem some notes on my on Roy's site) then I have to assume that
in fact we are still a good way away from calling it a replacement and
starting to push it out to users?
On Friday 29 February 2008 15:56:44 Ed W wrote:
Alon Bar-Lev wrote:
Check out OpenRC it is baselayout successor and works great!
Funnily enough I came across this earlier today for different reasons.
However, I hadn't realised that it was a full baselayout competitor?
Does Roy hang out
On Friday 29 February 2008 18:32:44 Stefan Hellermann wrote:
I just tried openrc and I really like it! All the things changed from
baselayout-2.0.0-rc6 are really good ideas! good work! Thanks!
:)
Two small things happened here:
After Login I the shell looks like:
-bash-3.2#
when I start
On Friday 29 February 2008 23:23:34 Ed Wildgoose wrote:
[2] I use busybox as a shell and can support it when it's internal
start-stop-daemon applet disabled (as OpenRC has it's own variant).
I guess I could just check it out instead of asking but What's
missing from the busybox
On Wed, 27 Feb 2008 09:42:05 +0100, Fabian Groffen [EMAIL PROTECTED]
wrote:
- baselayout porting to Prefix (mostly the start stop mechanisms)
What start stop mechanics do you mean?
OpenRC already has full FreeBSD jail support in services like do
depend() { keyword nojail; }
That effectively
On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen [EMAIL PROTECTED]
wrote:
Well... that's great! But a jail or a (ch)root is in general not the
same as a prefix.
No, but it's the same kettle of fish as chroots, jails and vps systems -
basically
there is a need to disable dependencies that
On Wednesday 27 February 2008 14:21:58 Fabian Groffen wrote:
On 27-02-2008 13:56:51 +, Roy Marples wrote:
On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen [EMAIL PROTECTED]
wrote:
Well... that's great! But a jail or a (ch)root is in general not the
same as a prefix
On Monday 18 February 2008 21:20:52 Donnie Berkholz wrote:
@@ -614,7 +614,7 @@
# @DESCRIPTION:
# DEPRECATED - Gets the flags needed for NOW binding
bindnow-flags() {
- ewarn QA: stop using the bindnow-flags function ... simply drop it
from your ebuild + ewarn QA: stop using the
On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote:
In my opinion WIPE_TMP should be in the same state
as RC_PARALLEL_STARTUP.
That's a fair point.
Luckily, the all the Gentoo init scripts that all my computers use are
now at the stage where we could easily flick parallel startup on by
On Fri, 2008-01-18 at 06:41 -0500, Mike Frysinger wrote:
right, there is no way (by design) to force these settings on an already
created user. if the old path really truly should not be the old value, you
can do something like this in pkg_setup:
if [[ $(egetent passwd user | cut -d: -f6)
On Wed, 2008-01-09 at 17:01 +, Ciaran McCreesh wrote:
3.5.5 was good enough to be keyworded stable at one point. Thus, it
can't be *that* bad.
So what happens if a flaw is discovered in KDE 3.5.5 that allows root
access?
In your world you allow mips users to trivially install now flawed
On Wednesday 09 January 2008 18:16:24 Ciaran McCreesh wrote:
On Wed, 09 Jan 2008 17:27:52 +
Roy Marples [EMAIL PROTECTED] wrote:
On Wed, 2008-01-09 at 17:01 +, Ciaran McCreesh wrote:
3.5.5 was good enough to be keyworded stable at one point. Thus, it
can't be *that* bad.
So
On Thu, 2008-01-03 at 10:58 +0200, Alon Bar-Lev wrote:
At: default.mk, the _SUBDIR loop is somehow incorrect, as it will not
pass subdir make result to rule.
So if rule fails the build still considered a success.
make[1]: *** [start-stop-daemon.o] Error 1
make[1]: *** Waiting for
On Thu, 2008-01-03 at 12:02 +0200, Alon Bar-Lev wrote:
On 1/3/08, Roy Marples [EMAIL PROTECTED] wrote:
I knew there was a reason for not adding digests :)
I've removed them for now.
Why remove?!?!?!
This way we cannot use layman in order to sync with your changes.
Because Gentoo/Linux
On Thu, 2008-01-03 at 10:50 -0500, Mike Frysinger wrote:
it also means a deprecation notice needs to be added here and everywhere else
that has changed. perhaps create a small script that takes
the /etc/modules.autoload.d/ directory and converts it into the
corresponding
On Thu, 2008-01-03 at 16:24 +, Roy Marples wrote:
On Thu, 2008-01-03 at 10:50 -0500, Mike Frysinger wrote:
it also means a deprecation notice needs to be added here and everywhere
else
that has changed. perhaps create a small script that takes
the /etc/modules.autoload.d
On Thu, 2008-01-03 at 10:49 -0500, Mike Frysinger wrote:
while is_older_than is negotiable, removing KV_* is not. those are pretty
tight utility functions which duplication in $random-packages will only lead
to problems (especially considering the history of making sure they were
coded
On Wed, 2008-01-02 at 16:39 +0200, Alon Bar-Lev wrote:
On 1/1/08, Roy Marples [EMAIL PROTECTED] wrote:
It took me some time to find /etc/conf.d/modules, but it's certainly
useful :).
It also means all config files, with the exceptions of fstab and rc.conf
are in conf.d and not some
On Wed, 2008-01-02 at 17:15 +0200, Alon Bar-Lev wrote:
On 1/2/08, Roy Marples [EMAIL PROTECTED] wrote:
Those functions were removed from functions.sh as only update-modules
still uses them. udev does use KV_to_int though. I don't really want to
add those functions back. Although we could
On Mon, 2007-12-31 at 14:50 -0600, William Hubbs wrote:
brltty is one of our accessibility packages. It is a program that
drives a braille display which is one way a blind person can access the
computer.
The project's guidelines for linux distributions at
Hi List
2008 is here and it's time for some change!
OpenRC is now ready for testing. There are no ebuilds in the tree, but
some are available here [1] that offers a baselayout-2 shell that pulls
in openrc-. I'll just offer a git ebuild for the time being, so bugs
can be fixed fast without
Uh, forgot the link :)
http://git.overlays.gentoo.org/gitweb/?p=dev/uberlord.git;a=summary
--
[EMAIL PROTECTED] mailing list
On Tue, 2008-01-01 at 18:55 +0200, Alon Bar-Lev wrote:
Thanks!
Works!
Roy, why didn't you digest and commit the files?
Dunno. Have now done so.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
On Tue, 2008-01-01 at 11:11 -0600, William Hubbs wrote:
On Tue, Jan 01, 2008 at 12:27:24PM +, Roy Marples wrote:
Just make a standard init script for it with this dependency block
depend() {
before checkfs
}
Would it be safe to change this to before checkroot'?
Some scripts
On Tue, 2008-01-01 at 19:22 +0200, Alon Bar-Lev wrote:
Thanks for adding digest, but:
Calculating dependencies /!!! Digest verification failed:
!!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 3629
!!!
On Tue, 2008-01-01 at 12:04 -0600, William Hubbs wrote:
On Tue, Jan 01, 2008 at 05:19:39PM +, Roy Marples wrote:
Some scripts do run before checkroot, such as clock. clock should be the
first script started, so if you want it to go really early then
My goal is to have the braille
On Tue, 2008-01-01 at 20:16 +0100, Thomas Pani wrote:
Works fine here (x86). Having set both RC_{QUIET,VERBOSE}=no it's a
little more verbose than what I'm used to (especially udev loading
madwifi) but that's early enough in the boot sequence not to bug me.
That's a udev issue, not a
On Sat, 2007-12-29 at 23:20 +, Ciaran McCreesh wrote:
On Sun, 30 Dec 2007 00:16:22 +0100
Federico Ferri [EMAIL PROTECTED] wrote:
sorry if this has already suggested.
It has. It solves nothing.
If it solves nothing you should at least post a link to the post you
made explaining so,
On Tue, 2007-12-25 at 04:16 -0500, Ciaran McCreesh wrote:
On 12/25/07, Roy Marples [EMAIL PROTECTED] wrote:
Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI
1 environment, or what?
If it's that such a big deal, then simply ensure that
Thankyou for reading
On Thu, 2007-12-27 at 16:39 +0100, Jan Kundrát wrote:
Roy Marples wrote:
I understand that metadata in a file name is pure and simple hackery
that has no place here and the GLEP is a flimsy attempt to justify it.
Do you count version as metadata?
No.
--
[EMAIL PROTECTED] mailing list
On Thu, 2007-12-27 at 16:32 +, Ciaran McCreesh wrote:
On Thu, 27 Dec 2007 15:04:52 +
Roy Marples [EMAIL PROTECTED] wrote:
I understand that metadata in a file name is pure and simple hackery
that has no place here and the GLEP is a flimsy attempt to justify it.
Alright, so where
On Thu, 2007-12-27 at 16:50 +, Ciaran McCreesh wrote:
On Thu, 27 Dec 2007 16:45:06 +
Roy Marples [EMAIL PROTECTED] wrote:
Alright, so where would you stick EAPI such that all the
requirements that've previously been described are met?
I neither know, nor care.
I just
On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote:
Or to put it another way, you're objecting to painting the house pink
rather than green because you don't like pink (because your last house
was green too), ignoring that it's been demonstrated that when painted
green, it's impossible
On Thu, 2007-12-27 at 18:11 +, Ciaran McCreesh wrote:
On Thu, 27 Dec 2007 18:03:27 +
Roy Marples [EMAIL PROTECTED] wrote:
On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote:
Or to put it another way, you're objecting to painting the house
pink rather than green because you
On Tue, 2007-12-25 at 02:43 -0500, Ciaran McCreesh wrote:
On Dec 25, 2007 2:38 AM, Roy Marples [EMAIL PROTECTED] wrote:
On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
On Dec 24, 2007 7:53 AM, Roy Marples [EMAIL PROTECTED] wrote:
So to obtain EAPI from .ebuild you would always
On Tue, 2007-12-25 at 15:51 +0800, Shyam Mani wrote:
PS : Aam chahiye kya? :)
Note : The above line means Do you want a Mango? in Hindi. If any of
you *ever* meet Seemant, don't forget to ask him this :D
It's what he does with it that scares me o_O ;)
Roy
--
[EMAIL PROTECTED] mailing list
Just picked this particular email to reply with my thoughts on this
thread.
On Mon, 2007-12-24 at 10:52 +, Steve Long wrote:
But they come under the scope of this discussion, since this is about the
long-term future of *every* EAPI. So let's discuss them
Impossible. History has proven
On Mon, 2007-12-24 at 21:39 +, Duncan wrote:
Apparently, at present, pretty much the only one with access
is the one who actually did the port, and he's hasn't done much with it
since.
I beg to differ - I've down an awful lot with the code.
It now installs and works cleanly on a vanilla
On Mon, 2007-12-24 at 19:52 -0800, Robin H. Johnson wrote:
The CVS stuff should have been locked out already, not sure how you
tested that.
I didn't.
I assumed that as I had access to d.g.o, I had CVS access too.
My bad.
The Git stuff is coming very shortly (probably as a Christmas gift from
On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
On Dec 24, 2007 7:53 AM, Roy Marples [EMAIL PROTECTED] wrote:
So to obtain EAPI from .ebuild you would always do
EAPI=`. /path/to/ebuild.ebuild; echo ${EAPI}`
Doesn't work with current ebuilds, nor future ebuilds. No points!
Works
On Thursday 13 December 2007 09:18:45 Peter Volkov wrote:
2. Modify ebuilds to use arrays.
-FONT_CONF=path1 path2
+FONT_CONF=( path1 path2 )
Why not use a function in pkg_setup as suggested earlier and pass each path
component as $1, $2, etc. Then the ebuild itself doesn't actually care
On Tuesday 11 December 2007 08:17:12 Peter Volkov wrote:
Some eclasses (kernel-2, font) use variable to pass space separated PATH
to patch or fontconfig files from ebuild to eclass. In ebuild we use:
FONT_CONF=path1 path2
Then eclasses use the variable:
for conffile in ${FONT_CONF}; do
On Tuesday 11 December 2007 08:44:51 Donnie Berkholz wrote:
Roy solved a similar problem in baselayout-2 using hardcoded newlines,
although it had the additional constraint of sh compatibility. It's
worth considering code clarity between that and arrays.
Only because some commands could
On Tuesday 11 December 2007 11:14:49 Peter Volkov wrote:
That way you work the same way as the classic $PATH variable.
But this seems to fail if we have ':' inside path{1,2}. Is that true?
For PATH the same question stands, but I think that ':' is used there
for historical reasons.
Yes,
On Tue, 2007-11-06 at 08:03 +, Ciaran McCreesh wrote:
On Tue, 06 Nov 2007 07:40:20 +
Roy Marples [EMAIL PROTECTED] wrote:
On Tue, 2007-11-06 at 07:12 +, Ciaran McCreesh wrote:
Except it won't, because ebuilds require bash regardless of which
package manager is being used
While I still have access to the [EMAIL PROTECTED] email, I'll respond here.
On Mon, 2007-11-05 at 10:22 +0100, Michael Haubenwallner wrote:
On Sat, 2007-11-03 at 00:47 +, Roy Marples wrote:
As it seems too few people really accept your suggestion, I feel it's
time for me to chime
On Mon, 2007-11-05 at 14:21 +0100, Michael Haubenwallner wrote:
Actually you missed the mark completely.
Nothing in the tree itself specifies what shell to use - instead it's
the package manager. So the PM on Gentoo/Linux/FreeBSD *could*
be /bin/sh and on the systems where /bin/sh is not
On Mon, 2007-11-05 at 16:21 -0400, Mike Frysinger wrote:
we want the installed environment to be portable, not the build environment.
i do not see any benefit from forcing the build environment to be pure POSIX
compliant and i see many many detrimental problems.
Oh I don't know. Imagine how
On Tue, 2007-11-06 at 07:12 +, Ciaran McCreesh wrote:
Except it won't, because ebuilds require bash regardless of which
package manager is being used. If you want to change that you'll have to
rewrite the entire tree.
Az once said near enough the same thing about baselayout. And that's
On Fri, 2007-11-02 at 11:38 -0400, Mike Frysinger wrote:
wrong. the point of the discussion on the gentoo dev mailing list is to go
over the exported API for *ebuilds*, not for the implementation. the
implementation is already baked and really, Marijn shouldnt have sent it to
the gentoo
On Fri, 2007-11-02 at 10:59 -0400, Mike Frysinger wrote:
On Friday 02 November 2007, Roy Marples wrote:
On Fri, 2007-11-02 at 14:44 +0100, Marijn Schouten (hkBst) wrote:
[[ ${flag} = !* ]] { success=1 ; flag=${flag:1} }
Could be written as
irrelevant, thanks
My mail was relevant
On Fri, 2007-11-02 at 15:27 +0100, Marijn Schouten (hkBst) wrote:
ifz() {
[[ $1 = 0 ]] echo $2 || echo $3
}
And that could be written as
[ $1 = 0 ] echo $2 || echo $3
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
On Fri, 2007-11-02 at 14:44 +0100, Marijn Schouten (hkBst) wrote:
[[ ${flag} = !* ]] { success=1 ; flag=${flag:1} }
Could be written as
[ ${flag#!} != ${flag} ] { success=1; flag=${flag#!}; }
string=$( (( ${success} == 0 )) echo ${string_success} || echo
${string_failure} )
[[ -n
On Fri, 2007-11-02 at 11:58 -0400, Mike Frysinger wrote:
and the answer is still the same. POSIX conversions are irrelevant until you
can propose solutions for the things bash can do but POSIX cannot. you can
only provide workarounds or hacks, so any further attempt on the topic is
half
On Fri, 2007-11-02 at 18:17 +0100, Bo Ørsted Andresen wrote:
On Friday 02 November 2007 17:52:13 Roy Marples wrote:
On Fri, 2007-11-02 at 17:30 +0100, Bo Ørsted Andresen wrote:
Please explain why you hijack this thread to discuss POSIX vs. bash when
it's supposed to be about the API
On Fri, 2007-11-02 at 17:30 +0100, Bo Ørsted Andresen wrote:
Please explain why you hijack this thread to discuss POSIX vs. bash when it's
supposed to be about the API for ebuilds.
I dislike the gratuitous use of bash for no good reason - and in the
code he gave there is no good reason for
On Sat, 2007-11-03 at 01:19 +0100, Fabian Groffen wrote:
On 02-11-2007 17:35:08 +, Roy Marples wrote:
I don't see them as inferior.
I see them as more portable and less confusing.
Please stop calling it more portable.
But is it more portable as then then works across more than one
On Sat, 2007-11-03 at 01:19 +0100, Fabian Groffen wrote:
On 02-11-2007 17:35:08 +, Roy Marples wrote:
I don't see them as inferior.
I see them as more portable and less confusing.
Please stop calling it more portable. The shell code you see in
configure can in a way be called
On Sat, 2007-11-03 at 01:19 +0100, Fabian Groffen wrote:
Please stop calling it more portable. The shell code you see in
configure can in a way be called portable. Your POSIX compliant stuff
isn't. In fact, by stating #!/bin/sh you actually make the code useless
on a number of platforms,
On Tue, 2007-10-30 at 22:46 -0700, Donnie Berkholz wrote:
On 10:36 Tue 30 Oct , Roy Marples (uberlord) wrote:
1.1 app-admin/webmin/webmin-1.370-r1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-admin/webmin/webmin-1.370-r1.ebuild?rev=1.1view
On Wed, 2007-10-31 at 11:40 -0400, Doug Goldstein wrote:
When HAL evaluated the usage of libpci the following issues were
identified:
1) increased memory usage, to the point that HAL was not usable on the
OLPC project
2) ABI breakage between patch revisions (i.e. x.y.z and x.y.z+1 were
On Thu, 2007-10-25 at 16:40 +0100, Roy Marples wrote:
array=1.2.3.4 netmask 5.6.7.8;
\*
'host.name' netmask 1.2.3.4
-I 'option; $FOO with spaces'
Everyone who commented has agreed that this is the most readable,
maintainable and documentable. As such I've comitted a patch
On Thu, 2007-10-25 at 23:13 -0700, Alec Warner wrote:
Can I vote for none of the above? :)
Sure you can - provided you come up with an alternative approach to the
problem :)
1 *
Yes, that appears to be every ones thought so far.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
On Thu, 2007-10-25 at 15:56 -0700, Donnie Berkholz wrote:
On 22:49 Thu 25 Oct , Roy Marples wrote:
On Thu, 2007-10-25 at 14:31 -0700, Donnie Berkholz wrote:
Is there any way we could avoid these altogether, and instead use
separate variables for each array element?
Well, we
1 - 100 of 349 matches
Mail list logo
