Re: LSB?

[Chris Lawrence]

On Jan 18, Jason Gunthorpe wrote:
> It contains many interesting things that I know we disagree with. Someone
> should look at it perhaps?

Among the interesting things:

> The closing date for comments is January 11th 1999.

Nice that it was announced today then :-)

***
> Reference 3.4-2(A)
> The implementation provides the file /etc/adjtime
> Result: PASS/FAIL

This is an Intel-ism.  adjtimex does not exist for several non-X86
platforms.

***
> Reference 3.8-1(A)
> The /opt directory exists and is searchable
> Result: PASS/FAIL

Um, why?  We already have /usr/local...

***
> Reference 3.10-2(A)
> The implementation provides an exec-able version of the clock
> utility in the /sbin directory.
> Result: PASS/FAIL

hwclock should be an allowable alternative.  hwclock also supports
GNU-style options better than clock.

***
> Reference 3.10-11(A)
> The implementation provides an exec-able version of the fdisk
> utility in the /sbin directory.
> Result: PASS/FAIL

This only makes sense where MS-DOS partitioning is the rule.  Perhaps
fdisk should be a symbolic link to the appropriate partitioning
software (mac-fdisk, msdos-fdisk, amiga-fdisk, etc.) for the
implementation.

***
> Reference 3.10-14(A)
> For each file system type fstype supported by the system:
The /sbin directory contains the commands fsck.fstype
and mkfs.fstype.
> Result: PASS/FAIL
> Notes typically fstype = ext, ext2, minix, msdos, xia and others
> unspecified

Are they mentally ill?  Let's try "mkfs.nfs" on for size...


Nice to see the Open Group and X/Open are going to send us chasing our
tails trying to get this stuff together (so we can call our Linux
implementations "Linux" :-p) instead of pursuing Unix branding.


Chris
-- 
=
|   Chris Lawrence|My home page:|
|  <[EMAIL PROTECTED]>   |  http://www.clark.net/pub/lawrencc/ |
| | |
|Amiga A4000/060 with |Watch Babylon 5 on TNT   |
| Linux/m68k 2.1.127  |   <*> http://tnt.turner.com/babylon5/ <*>   |
=

Re: LSB?

[Robert Woodcock]

Chris Lawrence wrote:
>Nice to see the Open Group and X/Open are going to send us chasing our
>tails trying to get this stuff together (so we can call our Linux
>implementations "Linux" :-p) instead of pursuing Unix branding.

Indeed. I thought LSB was going to be an Application Environment
specification - so that apps developed on one distribution would run on all
the others.

If that's still the case, I wanna know WTF they are thinking/smoking,
specifying kernel locations, netstat, mount/umount, fdisk, setserial,
disktab, adjtime, csh.login (!), fdprm, fstab, gettydefs (!!!), group,
passwd, inittab, lilo, mtab, profile, securetty, exports, hosts,
hosts.allow, hosts.deny, networks, printcap, protocols, services, rpc,
/home, /lib/modules, /opt existing (conflicts with FHS), /root, clock,
getty, init, update, mkswap, swapon, swapoff, telinit, shutdown, fsck, mkfs,
ifconfig, route, /tmp cleaning, /usr/X386 (?!?), includes, g++,
/usr/local/*, process accounting, utmp (ALL programs should use the
wrapper), /var/spool/lpd, rwho, /var/tmp persistance, NIS, ALL OF THE DAMN
MAJOR/MINOR NUMBERS FOR THE DEVICES, /usr/src, /usr/src/linux, compilers...

*NO* well-behaved application should use/twiddle/tinker with ANY of the
above. (Well, I could be wrong in a couple spots, but... wow.)

P.S.: From where is /bin/domainname standard? I can see it's purpose in an
app env standard, so I'm curious...
-- 
Robert Woodcock - [EMAIL PROTECTED]
"Unix and C are the ultimate computer viruses" -- Richard Gabriel

Re: LSB?

[Anthony Towns]

On Tue, Jan 19, 1999 at 06:09:45AM -, Robert Woodcock wrote:
> Indeed. I thought LSB was going to be an Application Environment
> specification - so that apps developed on one distribution would run on all
> the others.
> 
> If that's still the case, I wanna know WTF they are thinking/smoking,
> specifying kernel locations, netstat, mount/umount, fdisk, setserial,

...and whatever happened to specifying things like update-rc.d,
update-inetd, and so on? Or was that the LSC or something?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

``Like the ski resort of girls looking for husbands and husbands looking
  for girls, the situation is not as symmetrical as it might seem.''


pgpzb7Evji2J3.pgp
Description: PGP signature

Re: LSB?

[Joseph Carter]

It has come to my attention that recent decisions made by the Linux
Standard Base body (I hesitate to say "committee" as I have never been
party to any of their internal discussions and am unaware of their
internal organizational structrure) are possibly unwise and have been
determined by at least a few individuals as A Bad Thing.  Particularly
worth note are several i386isms and other things which those who have
spoken already feel are oversights with potentially disasterous results.

Reasonable objection notwithstanding, I intend to write a letter to those
responsible for the LSB to attempt to raise the issues we have with their
current proposal.  I would appreciate discussion on these issues in other
parts of this thread.  I encourage those who have a significant opinion
not yet voiced in the LSB thread found on debian-devel to write them down
either as part of the thread or directly to me to aid in the drafting of
this letter.


For those who missed the thread on -devel, relevant URLs can be found at
http://ct.us.mirrors.freshmeat.net/news/1999/01/18/916679929.html


-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

Re: LSB?

[Olivier Tharan]

On Tue, Jan 19, 1999 at 06:09:45AM -, Robert Woodcock wrote:
> P.S.: From where is /bin/domainname standard? I can see it's purpose in an
> app env standard, so I'm curious...

It comes from the FHS. domainname, hostname, ping, netstat are the
network commands suitable for /bin, as they will be executed both by root and
normal users, and they might be needed in a /-only environment (ie, no /usr
yet).

http://www.pathname.com/fhs/

olive
-- 
Olivier Tharan, <[EMAIL PROTECTED]>

I haven't lost my mind; it's backed up on tape somewhere.

Re: LSB?

[Michael Stone]

Quoting Robert Woodcock ([EMAIL PROTECTED]):
> P.S.: From where is /bin/domainname standard? I can see it's purpose in an
> app env standard, so I'm curious...

NIS/yp. You'll find it in the nis package.

Mike Stone

Re: LSB?

[Vincent Renardias]

On Mon, 18 Jan 1999, Joseph Carter wrote:

> Reasonable objection notwithstanding, I intend to write a letter to those
> responsible for the LSB to attempt to raise the issues we have with their
> current proposal.  I would appreciate discussion on these issues in other
> parts of this thread.

If you're interested in the LSB, you should join the LSB mailing list and
offer to help.

"writing a letter to those responsible" is _very_ likely to be useless
considering this lsb-fhs is a very first snapshot and that most problems
with it reported on debian-devel have already been reported on the LSB
mailing-list.

> I encourage those who have a significant opinion not yet voiced in the
> LSB thread found on debian-devel to write them down either as part of
> the thread or directly to me to aid in the drafting of this letter.

Please just don't do that.
Whining on debian-devel/Freshmeat/Slashdot will _not_ help. Joining the
LSB-test mailing-list and offer to help is a much better thing to do.

Cordialement,

-- 
- Vincent RENARDIAS  [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux:   http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://www.ldsol.com -
---
-"Microsoft est à l'informatique ce que le grumeau est à la crépe..." -

Re: LSB?

[Joel Klecker]

At 23:31 -0600 1999-01-18, Chris Lawrence wrote:
***
Reference 3.4-2(A)
The implementation provides the file /etc/adjtime
Result: PASS/FAIL
This is an Intel-ism.  adjtimex does not exist for several non-X86
platforms.
I disagree, that file is also used by clock/hwclock (depending on 
architecture) as well.
--
Joel Klecker (aka Espy) http://web.espy.org/>
mailto:[EMAIL PROTECTED]>  mailto:[EMAIL PROTECTED]>
Debian GNU/Linux PowerPC -- http://www.debian.org/ports/powerpc/>

Re: LSB?

[Ean R . Schuessler]

You can start by writing to our man on point with the LSB, Dale Scheetz.

It is noteworthy, however, that Dale hasn't already commented in this 
thread. Are you still actively following the LSB, Dale?

On Mon, Jan 18, 1999 at 10:51:03PM -0800, Joseph Carter wrote:
> It has come to my attention that recent decisions made by the Linux
> Standard Base body (I hesitate to say "committee" as I have never been
> party to any of their internal discussions and am unaware of their
> internal organizational structrure) are possibly unwise and have been
> determined by at least a few individuals as A Bad Thing.  Particularly
> worth note are several i386isms and other things which those who have
> spoken already feel are oversights with potentially disasterous results.
> 
> Reasonable objection notwithstanding, I intend to write a letter to those
> responsible for the LSB to attempt to raise the issues we have with their
> current proposal.  I would appreciate discussion on these issues in other
> parts of this thread.  I encourage those who have a significant opinion
> not yet voiced in the LSB thread found on debian-devel to write them down
> either as part of the thread or directly to me to aid in the drafting of
> this letter.

-- 
___
Ean Schuessler As above
Novare International Inc.  so below
*** WARNING: This signature may contain jokes.

Re: LSB?

[Dale Scheetz]

On Tue, 19 Jan 1999, Ean R . Schuessler wrote:

> You can start by writing to our man on point with the LSB, Dale Scheetz.

Absolutely!

> 
> It is noteworthy, however, that Dale hasn't already commented in this 
> thread. Are you still actively following the LSB, Dale?

That only has to do with the fact that I also have "billions" of other
things to do besides reading ill informed postings on this list.

I'm sorry if I sound harsh. It is only because I am already overloaded
with "other people's problems" as well as a raft of my own.

If you wish to educate yourself with /. and not check the facts before
spreading fud, then I have no time for you. For information about what the
LSB is doing check the web site (www.linuxbase.org), where you will find
all of the borring details about how this committee is organized and what
is currently going on, or ask me <[EMAIL PROTECTED]>.

Ok, now that I've unloaded my baggage, let me speak to the issues
addressed.

The test suite under discussion is completely the product of TOG, as a
"favor" to the LSB. I made my objections to the chair of the LSB Committee
when TOG first suggested the name of the test suite, but (as usual) my
objections were ignored ;-)

The FHS test suite was suggested, soon after the license was resolved on
the POSIX test suite produced by TOG. With the current license, we can
"pick and choose" from the test suites available, those tests that suit
the needs of the LSB. So, it really doesn't matter if TOG insists on
misnaming the test suite, we can still use it as we please, within the
constraints of the Artistic license.

Keep clearly in mind that this test suite (just like VSX-PCTS) was written
to a particular standard (the FHS) and that any problems you have with the
test suite should only be those where the test suite violates the FHS. I
know that Debian has not (yet?) accepted the FHS. It wasn't clear which
portions are going to be useful to the LSBC until the suite was released.
Since that time I have been working on packaging the TET and VSX software
as Debian packages. Some of the unique characteristics of these packages
have been forcing me to think about just how that can be accomplished
under the current Policy structure of Debian, but that's another story.

In addition, there is going to be a "physical" meeting of the major
participants (myself included) soon, so we can get to know each other
better, and get a better idea of what we are each going to be able to
accomplish. There is also going to be a meeting between us and the various
vendors and distributions that have an interest in the outcome of this
standard, so that we can come to understand their needs better as well.
I believe that Ian J.  will be representing Debian at
that meeting.

So, if I seem to not be "johnie on the spot" as much as I have in the
past, rest assured that I am grinding away on LSB Testing issues, right
along with all the other things I grind at ;-)

> 
> On Mon, Jan 18, 1999 at 10:51:03PM -0800, Joseph Carter wrote:
> > It has come to my attention that recent decisions made by the Linux
> > Standard Base body (I hesitate to say "committee" as I have never been
> > party to any of their internal discussions and am unaware of their
> > internal organizational structrure) are possibly unwise and have been
> > determined by at least a few individuals as A Bad Thing.  Particularly
> > worth note are several i386isms and other things which those who have
> > spoken already feel are oversights with potentially disasterous results.
> > 
The following is directed at Joseph:

If you insist on associating the deficiencies in one thing with the
capabilities of another, I'm surprised your life isn't total chaos. Such
reasoning is totally without logic, and you would be better off rolling
dice to decide your next move.

I strongly suggest you do better research, next time you think you should
badmouth someone else's work. There are some very quality folks working on
the LSB, and you denigrate their efforts when you draw the unsubstantiated
conclusions you presented above.

Grrr...

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-

Re: LSB?

[Remco Blaakmeer]

On Mon, 18 Jan 1999, Chris Lawrence wrote:

> On Jan 18, Jason Gunthorpe wrote:
> > It contains many interesting things that I know we disagree with. Someone
> > should look at it perhaps?
> 
> Among the interesting things:

> ***
> > Reference 3.8-1(A)
> > The /opt directory exists and is searchable
> > Result: PASS/FAIL
> 
> Um, why?  We already have /usr/local...

My guess:

- /usr/local is for programs "supplied" by the sysadmin (i.e. self-made
scripts and stuff the sysadmin compiled)
- the rest of /usr is the domain of the OS vendor (so don't mess with
it or be prepared to redo your modifications on every OS upgrade)
- "third party" packages (like commercial software not made by the OS
vendor) go into /opt, while (optionally?) placing their config files
somewhere under /etc/opt

Remco
-- 
rd31-144:  9:00pm  up 5 days, 10:52,  7 users,  load average: 1.00, 1.04, 1.04

Re: LSB?

[Joseph Carter]

On Tue, Jan 19, 1999 at 05:38:25PM +0100, Vincent Renardias wrote:
> > Reasonable objection notwithstanding, I intend to write a letter to those
> > responsible for the LSB to attempt to raise the issues we have with their
> > current proposal.  I would appreciate discussion on these issues in other
> > parts of this thread.
> 
> If you're interested in the LSB, you should join the LSB mailing list and
> offer to help.

Last I heard the LSB list was closed to the general public, though
archives were available.  Is this still the case?  If the LSB project now
welcomes "outsiders" to work with the project, great.  Otherwise I'm
concerned doing that would be in vain.


> "writing a letter to those responsible" is _very_ likely to be useless
> considering this lsb-fhs is a very first snapshot and that most problems
> with it reported on debian-devel have already been reported on the LSB
> mailing-list.

As I've said, last I heard this list was not available to the public.


> > I encourage those who have a significant opinion not yet voiced in the
> > LSB thread found on debian-devel to write them down either as part of
> > the thread or directly to me to aid in the drafting of this letter.
> 
> Please just don't do that.
> Whining on debian-devel/Freshmeat/Slashdot will _not_ help. Joining the
> LSB-test mailing-list and offer to help is a much better thing to do.

That's not what I intended to do.  I _WAS_ intending to draft a letter
based on what we think as a group and send it to -private for peer review
and figuring out who does what next.  I wouldn't want to publish the
letter on -devel as some non-developers would read the draft as a final
letter to the LSB people and I want some peer review before anything is
read as "official" from Debian.


The reaction to Ian's original dfsg2 proposal (which IMO was right to
send to -devel) from those outside Debian who heard only rumors
indirectly or read what they wanted into the proposal and went around
bashing Debian for adopting this new dfsg indicates to me there is at
least some reason for a letter which in the draft stages and is intended
to be reviewed by developers first to be handled in this way.  To those
who went on rumor or read what they wanted into a proposal without
reading the attached threads, consider yourselves flamed and read before
you comment in the future.  =p  (this is of course not directed at you
personally Vincent..)


-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

Re: LSB?

[Joseph Carter]

On Tue, Jan 19, 1999 at 02:57:46PM -0500, Dale Scheetz wrote:
> > You can start by writing to our man on point with the LSB, Dale Scheetz.
> 
> Absolutely!

As said elsewhere, I was going to submit the draft to -private.  If you
think it would be better for you to handle it, say so and I'll stay out
of it.  I offered because nobody else had and based on opinions found
here on -devel and on Debian's irc channels, I felt someone should do
something.  I'm not trying to work around you or without the opinions of
other developers.


> > It is noteworthy, however, that Dale hasn't already commented in this 
> > thread. Are you still actively following the LSB, Dale?
> 
> That only has to do with the fact that I also have "billions" of other
> things to do besides reading ill informed postings on this list.
> 
> I'm sorry if I sound harsh. It is only because I am already overloaded
> with "other people's problems" as well as a raft of my own.

I can understand that you've had a lot to do.


> If you wish to educate yourself with /. and not check the facts before
> spreading fud, then I have no time for you. For information about what the
> LSB is doing check the web site (www.linuxbase.org), where you will find
> all of the borring details about how this committee is organized and what
> is currently going on, or ask me <[EMAIL PROTECTED]>.

I was using just what they had released.  Not anything based on Slashdot
(which probably has a story on this by now, but I haven't read it..)


> The test suite under discussion is completely the product of TOG, as a
> "favor" to the LSB. I made my objections to the chair of the LSB Committee
> when TOG first suggested the name of the test suite, but (as usual) my
> objections were ignored ;-)

Figures.  =>


> The FHS test suite was suggested, soon after the license was resolved on
> the POSIX test suite produced by TOG. With the current license, we can
> "pick and choose" from the test suites available, those tests that suit
> the needs of the LSB. So, it really doesn't matter if TOG insists on
> misnaming the test suite, we can still use it as we please, within the
> constraints of the Artistic license.

Why then did the release info indiciate this was the first version of a
LSB compliance test suite but wasn't finished yet so we can't claim based
on it that we're compliant?  The FUD was not in a Slashdot article, it
was on the page which you download the thing from.  Essentially, anyone
not part of the (AFAIK never opened to the public) LSB mailing list would
read this exactly as I did.  And in fact that's what they did read,
before I even knew there was a release.


> In addition, there is going to be a "physical" meeting of the major
> participants (myself included) soon, so we can get to know each other
> better, and get a better idea of what we are each going to be able to
> accomplish. There is also going to be a meeting between us and the various
> vendors and distributions that have an interest in the outcome of this
> standard, so that we can come to understand their needs better as well.
> I believe that Ian J.  will be representing Debian at
> that meeting.
> 
> So, if I seem to not be "johnie on the spot" as much as I have in the
> past, rest assured that I am grinding away on LSB Testing issues, right
> along with all the other things I grind at ;-)

Mostly I am concerned with the information which you regard as FUD being
found at the original URLs, not in any story published on Slashdot or
whatever.  I am glad to see it's not as much a worry as I originally
thought and (as Vincent suggested) I am interested in helping however I
can.  I didn't mean to step on your toes and I am sorry if my message
indicated that was my intent.  Based on the information I had, the
release info for this test suite, I saw the same problems other people
were seeing and felt it necessary to start to get the ball rolling to
avert disaster with the LSB.


> The following is directed at Joseph:
> 
> If you insist on associating the deficiencies in one thing with the
> capabilities of another, I'm surprised your life isn't total chaos. Such
> reasoning is totally without logic, and you would be better off rolling
> dice to decide your next move.
> 
> I strongly suggest you do better research, next time you think you should
> badmouth someone else's work. There are some very quality folks working on
> the LSB, and you denigrate their efforts when you draw the unsubstantiated
> conclusions you presented above.

I consider this unfair at the very least.  Before the LSB project was
created there was an irc meeting which was held somewhat in secret,
though I heard about it.  I attended about half of that meeting based on
what I know and there I offered to help.  My offer was rejected then.  I
tried to follow the project afterward, but information was kept internal
and the only way I could follow anything was by reading public archives
of a private list, which I wasn't even aware of until su

Re: LSB?

[Dale Scheetz]

On Tue, 19 Jan 1999, Joseph Carter wrote:



> 
> > The test suite under discussion is completely the product of TOG, as a
> > "favor" to the LSB. I made my objections to the chair of the LSB Committee
> > when TOG first suggested the name of the test suite, but (as usual) my
> > objections were ignored ;-)
> 
> Figures.  =>
> 
> 
> > The FHS test suite was suggested, soon after the license was resolved on
> > the POSIX test suite produced by TOG. With the current license, we can
> > "pick and choose" from the test suites available, those tests that suit
> > the needs of the LSB. So, it really doesn't matter if TOG insists on
> > misnaming the test suite, we can still use it as we please, within the
> > constraints of the Artistic license.
> 
> Why then did the release info indiciate this was the first version of a
> LSB compliance test suite but wasn't finished yet so we can't claim based
> on it that we're compliant?  The FUD was not in a Slashdot article, it
> was on the page which you download the thing from.  Essentially, anyone
> not part of the (AFAIK never opened to the public) LSB mailing list would
> read this exactly as I did.  And in fact that's what they did read,
> before I even knew there was a release.

My point is that you failed, and continue to fail, to recognize the
ownership of the location you "download the thing from", which is not the
LSB web site, but the site of "The Open Group", and TOG is _not_ the LSBC.

> 
> 


> > 
> > I strongly suggest you do better research, next time you think you should
> > badmouth someone else's work. There are some very quality folks working on
> > the LSB, and you denigrate their efforts when you draw the unsubstantiated
> > conclusions you presented above.
> 
> I consider this unfair at the very least.  Before the LSB project was
> created there was an irc meeting which was held somewhat in secret,
> though I heard about it.  I attended about half of that meeting based on
> what I know and there I offered to help.  My offer was rejected then.  I
> tried to follow the project afterward, but information was kept internal
> and the only way I could follow anything was by reading public archives
> of a private list, which I wasn't even aware of until such time as things
> started happening which lead to Bruce Perens leaving the LSB project.

All of which is old news. So what?

> 
> When the LCS project was formed I joined the list with the hopes of being
> able to help where I could and at least follow development of the
> project.  When LCS was merged back into LSB, people like me were left out
> in the cold.  No information since has been exactly released to the
> public, though I have been watching for it.
> 
While people like you may have been "left out in the cold", there was
plenty of effort to announce the new list organization. Everything
released by the LSBC is available at the linuxbase web site and has been
since shortly after "the reorganization".


> Then when the LSB project releases something and I go to check it out and
> read lots of stuff, much of it alarming and what you call FUD and bring
> it up here offering once again to do something, you tell me I haven't
> done my research.  I read the page attached to the official release.  If
> that page is in error it is not my error.
> 
Your error is in assigning authorship to the LSBC. 

> I propose the LSB project stop releasing FUD if they don't want it spread
> and that they stop keeping people who would like to at least follow the
> project and help it succeed where they can from doing so.
> 
To my knowledge no one has ever been "turned away" who has offered to help
with LSB work, not even TOG. If you realy wish to help then stop spreading
FUD. 

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-

Re: LSB?

[Daniel Quinlan]

Joseph Carter <[EMAIL PROTECTED]> writes:

> Reasonable objection notwithstanding, I intend to write a letter to those
> responsible for the LSB to attempt to raise the issues we have with their
> current proposal.  I would appreciate discussion on these issues in other
> parts of this thread.  I encourage those who have a significant opinion
> not yet voiced in the LSB thread found on debian-devel to write them down
> either as part of the thread or directly to me to aid in the drafting of
> this letter.

I'm jumping in the discussion a little late (I just joined this list),
but please let me try to help explain things...

I'd like to fix the problems that Debian developers are finding in the
LSB.  I think most of the i386isms are due to problems in FHS (you can
blame me), which will be fixed in FHS 2.1.  Remember that the original
FHS dates back to when i386 was the only architecture included in
Linus' kernel. (Patches to the FHS source are welcome.)

I also imagine that some people have some concerns with the TOG FHS
test suite.  Basically, anyone is free to make a contribution to the
LSB test suite effort -- provided that:

  - It's free ("Open Source") and released under the license we say it
should use.  (Since we haven't chosen that license yet, Andrew Josey
is using the Artistic license for now, but he agreed to switch when
the LSB makes that decision.)
  - It must be in sync with the LSB written spec (which references the
FHS) and the LSB sample implemention should pass it.
  - It won't be incorporated into LSB 1.0 without passing muster of
the LSB test suite group (headed by Dale Scheetz).

The technical problems you note are due to deficiencies in the written
specification (in FHS 2.0), and are not mistakes on the part of Andrew
Josey of the Open Group.

Andrew has contributed more to the LSB effort than most people.  BUT,
the TOG is *not* defining LSB.  Linux people are defining it -- and if
a company passes every hurdle we insist that they pass, why shouldn't
we allow them to help?  (I haven't seen any marketing spin from TOG,
but if there is any, please point me to it.)

If anyone has interest in helping develop LSB test suites (or other
parts of the LSB), please email me and Dale Scheetz <[EMAIL PROTECTED]>.

- Dan

(By the way, before taking on other projects, I was heavily involved
in Debian, from the early days with Ian Murdock through Bruce Perens.)

Re: LSB?

[Wayne Schlitt]

In <[EMAIL PROTECTED]> Joseph Carter <[EMAIL PROTECTED]> writes:
> Last I heard the LSB list was closed to the general public, though
> archives were available.  Is this still the case?  If the LSB project now
> welcomes "outsiders" to work with the project, great.  Otherwise I'm
> concerned doing that would be in vain.

(I'm not a debian developer, so maybe I should keep my nose out of
this, but...)


To the best of my knowledge, the LSB lists have never been *closed* to 
the general public.  I have been subscribed to them for months, and I
found out about them by reading /., debian-devel, and looking at a few 
web pages.

I have to admit that the LSB lists aren't the most exciting lists, and 
I often leave the unread for several weeks, before I skim through
them.  Still, I find them interesting enough to keep subscribed.

If you want me to, I can go do your research for you and point you to
the info about subscribing


-wayne



-- 
Wayne Schlitt can not assert the truth of all statements in this
article and still be consistent.

Re: LSB?

[Johnie Ingram]

"Wayne" == Wayne Schlitt <[EMAIL PROTECTED]> writes:

Wayne> To the best of my knowledge, the LSB lists have never been
Wayne> *closed* to the general public.  I have been subscribed to them
Wayne> for months, and I found out about them by reading /.,
Wayne> debian-devel, and looking at a few web pages.

Historical note: the original LSB list predates this, set up by Bruce
in July and including just a few distribution and ISV representatives
-- most of whom had met in person at the Expo in May.  It was closed,
but did have Debian people on it (and was run on one of our
mail servers).

After he resigned in August, Debian and Red Hat quickly agreed to
continue creation of a written standard under the name LCS.  Up until
then the LSB was focused mainly on creating a reference implantation,
not the specification we wanted.

But the remaining members of the LSB wanted a written spec too, so LCS
merged back into LSB again, becoming a subproject.  Project leadership
was reorganized under Dan Quinlan who opened up the lists on August
24.

There were some press releases and /. postings about this, which in
addition to reassuring everyone was also meant to crush the LSA, which
was effective.  (The LSA situation at that time had achieved Crisis
status on IRC.)

The rest is on the web archives at linuxbase.org, housed at Transmeta.
Debian still manages the LSBs actual mailing lists.


-  PGP  E4 70 6E 59 80 6A F5 78  63 32 BC FB 7A 08 53 4C
 
   __ _Debian GNU Johnie Ingram <[EMAIL PROTECTED]>  mm   mm
  / /(_)_ __  _   ___  __"netgod" irc.debian.org  mm mm
 / / | | '_ \| | | \ \/ / m m m
/ /__| | | | | |_| |>  <  Yes, I'm Linus, and I am your God. mm   mm
\/_|_| |_|\__,_/_/\_\   -- Linus, keynote address, Expo 98   GO BLUE

Re: lsb-base

[Petter Reinholdtsen]

[Marco d'Itri]
> I am considering switching the init scripts of my packages to
> lsb-base (which means that it will have to be promoted to important
> priority, at least).
> If anybody has objections please voice them now.

I already did this for discover1, but did this in a way to make it use
lsb-base only if it is installed.

I used this code to make lsb-base optional, and used the lsb functions
for output:

  if [ -f /lib/lsb/init-functions ]; then
. /lib/lsb/init-functions
  else
log_begin_msg()   { echo "$@"; }
log_success_msg() { echo "$@"; }
log_warning_msg() { echo "$@"; }
  fi

Perhaps an idea for you too?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Thomas Hood]

On Sun, 17 Jul 2005 20:33:40 +0200, Petter Reinholdtsen wrote:
> I used this code to make lsb-base optional, and used the lsb functions
> for output:
> 
>   if [ -f /lib/lsb/init-functions ]; then
> . /lib/lsb/init-functions
>   else
> log_begin_msg()   { echo "$@"; }
> log_success_msg() { echo "$@"; }
> log_warning_msg() { echo "$@"; }
>   fi
> 
> Perhaps an idea for you too?


The package is only 20 kbytes installed.  Let's just start Depending on it.

-- 
Thomas Hood


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Petter Reinholdtsen]

[Thomas Hood]
> The package is only 20 kbytes installed.  Let's just start Depending on it.

I agree.  We should start using the LSB, not just talk about trying to
be LSB conforming. :)

But I made the use optional for discover1 because someone complained
and said it was just a fancy way to get colors in the boot screen, and
besides lsb-base is not a commonly installed package yet.  I believe
it is a good idea to standardize the init.d message reporting, to make
it easier to redirect them to a common location, and believe using the
lsb-base functions is a step in the right direction.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Marco d'Itri]

On Jul 17, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:

> I already did this for discover1, but did this in a way to make it use
> lsb-base only if it is installed.
I can't see the point. The package is tiny, so if it should be used then
everybody should install it.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: lsb-base

[Bernhard R. Link]

* Marco d'Itri <[EMAIL PROTECTED]> [050717 18:50]:
> I am considering switching the init scripts of my packages to lsb-base
> (which means that it will have to be promoted to important priority, at
> least).
> If anybody has objections please voice them now.

Is there a way to configure this to not create masses of processes and
confusing the user with colors?

  Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Marco d'Itri]

On Jul 18, "Bernhard R. Link" <[EMAIL PROTECTED]> wrote:

> Is there a way to configure this to not create masses of processes and
> confusing the user with colors?
You can write your own package which conflicts+provides lsb-base and
implements /lib/lsb/init-functions.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: lsb-base

[Andreas Barth]

* Marco d'Itri ([EMAIL PROTECTED]) [050718 20:17]:
> On Jul 18, "Bernhard R. Link" <[EMAIL PROTECTED]> wrote:
> 
> > Is there a way to configure this to not create masses of processes and
> > confusing the user with colors?
> You can write your own package which conflicts+provides lsb-base and
> implements /lib/lsb/init-functions.

It would be better if there would be some configureable option in
lsb-base.


Cheers,
Andi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Stig Sandbeck Mathisen]

Andreas Barth <[EMAIL PROTECTED]> writes:

> It would be better if there would be some configureable option in
> lsb-base.

,
| Angry Fruit Salad?
| 
| [yes] [no]
`

Anyway, I like the pretty colours.  It makes it very easy to see if
something is wrong during boot or service startup with just a glance.

-- 
Stig Sandbeck Mathisen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Andreas Barth]

* Stig Sandbeck Mathisen ([EMAIL PROTECTED]) [050719 09:31]:
> Andreas Barth <[EMAIL PROTECTED]> writes:
> > It would be better if there would be some configureable option in
> > lsb-base.
 
> ,
> | Angry Fruit Salad?
> | 
> | [yes] [no]
> `

configuration option like in "set style = plain" in
/etc/defaults/lsb-base if you don't like the colours.

> Anyway, I like the pretty colours.  It makes it very easy to see if
> something is wrong during boot or service startup with just a glance.

I didn't say _anything_ against using them as default, but giving the
people the choice to select another style without the need to make a
custom package would be good.


Cheers,
Andi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Thomas Hood]

The lsb functions currently only support this:

Doing something...[ ok ]

They don't support:

Doing something...doing something else... [ ok ]

or

Doing something...warning: no foo...  [ ok ]

For this a log_progress_msg() would have to be added.
-- 
Thomas Hood


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Bernhard R. Link]

* Stig Sandbeck Mathisen <[EMAIL PROTECTED]> [050719 09:30]:
> Anyway, I like the pretty colours.  It makes it very easy to see if
> something is wrong during boot or service startup with just a glance.

That's one of the reasons I dislike colours. Having other peoples
system display fatal error messages followed by a light green "OK"
might be funny, I'd not like to see it on mine. While Suse's and Redhat's
failure does admittedly not mean it will also happen to Debian, it
still gives a hint about the likelyhood of success. 

Hochachtungsvoll,
  Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Jon Dowland]

On Tue, Jul 19, 2005 at 09:30:33AM +0200, Stig Sandbeck Mathisen wrote:
> Anyway, I like the pretty colours.  It makes it very easy to see if

Colours aside, having the last six-or-so characters dedicated to a
PASS/FAIL style string makes summing up the boot process at a glance
much easier, and makes the boot procedure generally look tidier.

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Thomas Hood]

I have a couple of initscripts that print progress messages and I do
not want to be too hasty in eliminating them so I am thinking of
doing the following for now:

...

if [ -r /lib/lsb/init-functions ] ; then
. /lib/lsb/init-functions
print_warning_msg() { log_warning_msg "$*" ; }
print_begin_msg() { log_begin_msg "$*" ; }
print_progress_msg() { : ; }
print_end_msg_and_exit() { log_end_msg "$1" ; exit $1 ; }
else
print_warning_msg() { echo -n "$*" >&2 ; }
print_begin_msg() { echo -n "$*" ; }
print_progress_msg() { echo -n " $*" ; }
print_end_msg_and_exit() { case "$1" in (0) echo "${2}." ;; (*) echo 
"${3}." ;; esac ; exit $1 ; }
fi

...

case "$1" in
  start)
print_begin_msg "Doing foo..."
foo
print_progress_msg "and now bar..."
bar
print_end_msg_and_exit "$?" "done" "failed"
;;

...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Pierre Habouzit]

Le Ven 22 Juillet 2005 11:14, Thomas Hood a écrit :
> I have a couple of initscripts that print progress messages and I do
> not want to be too hasty in eliminating them so I am thinking of
> doing the following for now:
>
> ...
>
> if [ -r /lib/lsb/init-functions ] ; then
>   . /lib/lsb/init-functions
>   print_warning_msg() { log_warning_msg "$*" ; }
>   print_begin_msg() { log_begin_msg "$*" ; }
>   print_progress_msg() { : ; }
>   print_end_msg_and_exit() { log_end_msg "$1" ; exit $1 ; }
> else
>   print_warning_msg() { echo -n "$*" >&2 ; }
>   print_begin_msg() { echo -n "$*" ; }
>   print_progress_msg() { echo -n " $*" ; }
>   print_end_msg_and_exit() { case "$1" in (0) echo "${2}." ;; (*) echo
> "${3}." ;; esac ; exit $1 ; } fi
>
> ...

well, it seems complicated, why don't you fake the lsb-base names ? like 
it :

###
### fake lsb
###

if [ -r /lib/lsb/init-functions ] ; then
. /lib/lsb/init-functions
else
log_warning_msg () { echo -n "$*" &>2; }
log_begin_msg ()   { echo -n "$*"; }
log_progress_msg() { echo -n "$*"; }
// put here what you need
fi

###
### my functions
###

print_end_msg_and_exit() { log_end_msg "$1" ; exit $1 ; }


it seems simple, does it ?

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpBaUJERgHk5.pgp
Description: PGP signature

Re: lsb-base

[Marco d'Itri]

On Jul 22, Thomas Hood <[EMAIL PROTECTED]> wrote:

> I have a couple of initscripts that print progress messages and I do
> not want to be too hasty in eliminating them so I am thinking of
> doing the following for now:
Please don't. lsb-base is a tiny package, either use it or don't.
It will have standard priority soon anyway.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: LSB init scripts

[Russ Allbery]

Lennart Sorensen <[EMAIL PROTECTED]> writes:
> On Thu, May 03, 2007 at 10:08:20PM +0200, Marc Haber wrote:

>> This is also a "sales" issue. I have seen to many faces darken when
>> people see a Debian system boot for the first time. People get reminded
>> of the old DOS days and decide that this Linux thing is too ugly to
>> use.

> So knowledge is ugly?  It is obviously so much better to not know what
> is going on so that if it doesn't work you don't have to worry about it
> because you know nothing that could help you to solve it so it isn't
> your problem of course.

> Now being able to just turn on the details when something is wrong, and
> have them no there the rest of the time might be OK.  On the other hand
> you boot once every few months so who cares what the boot messages look
> like. :)

My ideal output format would just list "subsystem OK" (probably lined up
neatly) for each subsystem that's started successfully, so if everything
is fine, you'd see nothing but OKs.  (Special exception for startup that
needs to tell you what it's doing, in which case I'd like to see the
indented output of that subsystem before or after or bracketed by the OK
messages.)  If something fails, I want it to say it failed and show all of
the appropriate error messages immediately before or after.

I think that would give you the best of both worlds, particularly if it's
combined with logging so that the *full* output, without any
prettification, goes into a file on disk somewhere.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts

[Lars Wirzenius]

On to, 2007-05-03 at 13:39 -0700, Russ Allbery wrote:
> My ideal output format would just list "subsystem OK"

While we're daydreaming, I'd like an empty screen with a timer counting
down how long (in seconds) I have until I can actually use the machine.
Unless there's a problem, of course, in which case I want all the info I
need to debug things.

(If I'm *really* daydreaming, I want a boot so fast I can't even see the
timer.)

-- 
C is the *wrong* language for your application.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts

[Russ Allbery]

Lars Wirzenius <[EMAIL PROTECTED]> writes:
> On to, 2007-05-03 at 13:39 -0700, Russ Allbery wrote:

>> My ideal output format would just list "subsystem OK"

> While we're daydreaming, I'd like an empty screen with a timer counting
> down how long (in seconds) I have until I can actually use the machine.
> Unless there's a problem, of course, in which case I want all the info I
> need to debug things.

One of the great parts of using a library to handle the output formatting
is that people who want this sort of boot presentation (or anything else,
really) can then develop themes that do exactly what they want.

I really want to enable that feature.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts

[Tim Dijkstra]

On Thu, 03 May 2007 18:13:25 -0700
Russ Allbery <[EMAIL PROTECTED]> wrote:

> Lars Wirzenius <[EMAIL PROTECTED]> writes:
> > On to, 2007-05-03 at 13:39 -0700, Russ Allbery wrote:
> 
> >> My ideal output format would just list "subsystem OK"
> 
> > While we're daydreaming, I'd like an empty screen with a timer counting
> > down how long (in seconds) I have until I can actually use the machine.
> > Unless there's a problem, of course, in which case I want all the info I
> > need to debug things.
> 
> One of the great parts of using a library to handle the output formatting
> is that people who want this sort of boot presentation (or anything else,
> really) can then develop themes that do exactly what they want.
> 

Splashy is indeed already using that functionality. It installs a file 
/etc/lsb-base-logging.sh, which is their to override functions from the
LSB library. It increments a progress bar triggered by calls to
log_end_msg made from init-scripts. That way we don't need change the
initscripts or install extra scripts, we get out info from all scripts
that use the LSB library.

grts Tim


signature.asc
Description: PGP signature

Re: LSB init scripts

[Marc Haber]

In Thu, 03 May 2007 13:39:32 -0700, Russ Allbery <[EMAIL PROTECTED]>
wrote:
>I think that would give you the best of both worlds, particularly if it's
>combined with logging so that the *full* output, without any
>prettification, goes into a file on disk somewhere.

Agreed, with the option of having the whole blurb on the console for
debugging just in case that the box does not come up cleanly.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: LSB init scripts

[Wesley J. Landaker]

On Friday 04 May 2007 05:53:39 Marc Haber wrote:
> >I think that would give you the best of both worlds, particularly if
> > it's combined with logging so that the *full* output, without any
> >prettification, goes into a file on disk somewhere.
>
> Agreed, with the option of having the whole blurb on the console for
> debugging just in case that the box does not come up cleanly.

Or, having the option to have the main vt console come up with nice, 
minimal, terse output, and have full output spit to a different console 
(e.g. vt12).

(I've actually set up a few of my systems manually to do something similar, 
like have different syslog levels/types go to vt10, vt10, and vt12, since 
those are rarely used for anything else.)

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgpU7OKC6VAYL.pgp
Description: PGP signature

Re: LSB-ize daemon without pidfile handling

[Hamish Moffatt]

On Thu, Nov 08, 2007 at 09:36:24PM +0100, Marc Haber wrote:
> ser2net, a small daemon in a package maintained by me, cannot write
> its own pidfile. Since it forks and detaches by default,
> start-stop-daemon's --make-pidfile option is of no use as well, since
> the daemon that ends up running has a different pid than s-s-d's
> child.
> 
[..]
> 
> How am I supposed to properly lsb-ize ser2net's init script? Is it ok
> to directly call s-s-d from the init script or do I need other
> workarounds?

Perhaps you could patch the daemon to add pidfile writing?

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Wouter Verhelst]

On Thu, Nov 08, 2007 at 09:36:24PM +0100, Marc Haber wrote:
> Hi,
> 
> ser2net, a small daemon in a package maintained by me, cannot write
> its own pidfile. Since it forks and detaches by default,
> start-stop-daemon's --make-pidfile option is of no use as well, since
> the daemon that ends up running has a different pid than s-s-d's
> child.
> 
> Before, I started that daemon with
> s-s-d --background --make-pidfile --exec $DAEMON -- -n,
> with -n being its option for "do not fork and background yourself".
> 
> While I do not find this particularly elegant (is there any better
> way?),

As Hamish said: patch the source. Writing a PID file is not particularly
hard. From nbd-server:

pidf=fopen(pidfname, "w");
if(pidf) {
fprintf(pidf, "%d\n", (int)getpid());
fclose(pidf);
} else {
/* error handling; if not running as root, probably a
 * permission issue or so */
}

and that's really it. Of course, you should add this after the daemon()
or fork() call in your program, otherwise it won't really help ;-)

> it precludes me from using /lib/lsb/init-function's
> start_daemon function as start_daemon is not able to pass arbitrary
> options to s-s-d, and there is no option to invoke --background
> --make-pidfile.
> 
> How am I supposed to properly lsb-ize ser2net's init script? Is it ok
> to directly call s-s-d from the init script or do I need other
> workarounds?

Reading through init-functions:

log_daemon_msg "Starting Foo Daemon" "foo"
start-stop-daemon --whatever --you --want --here
log_end_msg 0

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Fri, 9 Nov 2007 14:00:03 +1100, Hamish Moffatt <[EMAIL PROTECTED]>
wrote:
>On Thu, Nov 08, 2007 at 09:36:24PM +0100, Marc Haber wrote:
>> How am I supposed to properly lsb-ize ser2net's init script? Is it ok
>> to directly call s-s-d from the init script or do I need other
>> workarounds?
>
>Perhaps you could patch the daemon to add pidfile writing?

I do not plan to do so for obvious reasons.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Fri, 9 Nov 2007 08:49:22 +0100, Wouter Verhelst <[EMAIL PROTECTED]>
wrote:
>On Thu, Nov 08, 2007 at 09:36:24PM +0100, Marc Haber wrote:
>> How am I supposed to properly lsb-ize ser2net's init script? Is it ok
>> to directly call s-s-d from the init script or do I need other
>> workarounds?
>
>Reading through init-functions:
>
>log_daemon_msg "Starting Foo Daemon" "foo"
>start-stop-daemon --whatever --you --want --here
>log_end_msg 0

I do not think that this is particularly elegant since it duplicates
code from init-functions. But if people think that this is ok, it'll
be the way to go.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: LSB-ize daemon without pidfile handling

[Petter Reinholdtsen]

[Marc Haber]
> I do not plan to do so for obvious reasons.

It is not obvious for me.  Can you explain why it should be obvious
that you do not plan to patch the daemon to write its own pid file?
For me, the obvious solution for a daemon unable to write its own pid
file is to patch the daemon.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Adeodato Simó]

* Petter Reinholdtsen [Fri, 09 Nov 2007 22:00:42 +0100]:

> It is not obvious for me.  Can you explain why it should be obvious
> that you do not plan to patch the daemon to write its own pid file?
> For me, the obvious solution for a daemon unable to write its own pid
> file is to patch the daemon.

Well, it's obvious it's the best approach if you're willing to do it. ;-)
As a Debian packager, though, I would most likely just trust the authors
of start-stop-daemon and its --make-pidfile.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The first step on the road to wisdom is the admission of ignorance. The
second step is realizing that you don't have to blab it to the world.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Fri, 09 Nov 2007 22:00:42 +0100, Petter Reinholdtsen
<[EMAIL PROTECTED]> wrote:
>[Marc Haber]
>> I do not plan to do so for obvious reasons.
>
>It is not obvious for me.  Can you explain why it should be obvious
>that you do not plan to patch the daemon to write its own pid file?
>For me, the obvious solution for a daemon unable to write its own pid
>file is to patch the daemon.

I generally try not to patch upstream code if avoidable. Especially if
a patch would not be acceptable to upstream in the form we would apply
as a quick fix (no command line option, hard-coded path to the pid
file).

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: LSB-ize daemon without pidfile handling

[Wouter Verhelst]

On Fri, Nov 09, 2007 at 04:15:24PM +0100, Marc Haber wrote:
> On Fri, 9 Nov 2007 08:49:22 +0100, Wouter Verhelst <[EMAIL PROTECTED]>
> wrote:
> >log_daemon_msg "Starting Foo Daemon" "foo"
> >start-stop-daemon --whatever --you --want --here
> >log_end_msg 0
> 
> I do not think that this is particularly elegant since it duplicates
> code from init-functions. But if people think that this is ok, it'll
> be the way to go.

That is one way to look at it. The other way would be that these are
just three lines of "code" being duplicated here, and that start_daemon
is just a convenience function, nothing more.

Honestly, I don't see what the problem is.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Wouter Verhelst]

On Fri, Nov 09, 2007 at 10:24:46PM +0100, Adeodato Simó wrote:
> * Petter Reinholdtsen [Fri, 09 Nov 2007 22:00:42 +0100]:
> > It is not obvious for me.  Can you explain why it should be obvious
> > that you do not plan to patch the daemon to write its own pid file?
> > For me, the obvious solution for a daemon unable to write its own pid
> > file is to patch the daemon.
> 
> Well, it's obvious it's the best approach if you're willing to do it. ;-)

It's three lines of code to write a PID file, and it's the best approach
to make sure you don't break stuff.

> As a Debian packager, though, I would most likely just trust the authors
> of start-stop-daemon and its --make-pidfile.

--make-pidfile, --exec, and friends, are all ugly workarounds for buggy
daemons that can't write a pidfile.

Really.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Manoj Srivastava]

On Sat, 10 Nov 2007 16:19:37 +0100, Marc Haber <[EMAIL PROTECTED]> said: 

> On Fri, 09 Nov 2007 22:00:42 +0100, Petter Reinholdtsen
>> [EMAIL PROTECTED]> wrote:
>> [Marc Haber]
>>> I do not plan to do so for obvious reasons.
>> 
>> It is not obvious for me.  Can you explain why it should be obvious
>> that you do not plan to patch the daemon to write its own pid file?
>> For me, the obvious solution for a daemon unable to write its own pid
>> file is to patch the daemon.

> I generally try not to patch upstream code if avoidable. Especially if
> a patch would not be acceptable to upstream in the form we would apply
> as a quick fix (no command line option, hard-coded path to the pid
> file).

I find that making the application better or more functional or
 reliable, or otherwise improve quality for users is a more compelling
 argument than not patching upstream code, or kowtowing to upstream.  So
 no, this was not at all obvious to me -- indeed, in my opinion, this is
 the wrong approach to take.

manoj
-- 
Guard against physical unruliness. Be restrained in body. Abandoning
physical wrong doing, lead a life of physical well doing. 231
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Sat, 10 Nov 2007 17:01:38 +0100, Wouter Verhelst
<[EMAIL PROTECTED]> wrote:
>On Fri, Nov 09, 2007 at 10:24:46PM +0100, Adeodato Simó wrote:
>> Well, it's obvious it's the best approach if you're willing to do it. ;-)
>
>It's three lines of code to write a PID file, and it's the best approach
>to make sure you don't break stuff.

How many seconds until the "please make pidfile location configurable"
wishlist bug?

>> As a Debian packager, though, I would most likely just trust the authors
>> of start-stop-daemon and its --make-pidfile.
>
>--make-pidfile, --exec, and friends, are all ugly workarounds for buggy
>daemons that can't write a pidfile.

And I think that it is less broken to use them than to patch
third-party software.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Sat, 10 Nov 2007 17:00:13 +0100, Wouter Verhelst
<[EMAIL PROTECTED]> wrote:
>That is one way to look at it. The other way would be that these are
>just three lines of "code" being duplicated here, and that start_daemon
>is just a convenience function, nothing more.

So, start_daemon is not part of the standard?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: LSB-ize daemon without pidfile handling

[Stephen Gran]

This one time, at band camp, Marc Haber said:
> On Sat, 10 Nov 2007 17:01:38 +0100, Wouter Verhelst
> <[EMAIL PROTECTED]> wrote:
> >On Fri, Nov 09, 2007 at 10:24:46PM +0100, Adeodato Simó wrote:
> >> Well, it's obvious it's the best approach if you're willing to do it. ;-)
> >
> >It's three lines of code to write a PID file, and it's the best approach
> >to make sure you don't break stuff.
> 
> How many seconds until the "please make pidfile location configurable"
> wishlist bug?

Which is another, what, 5-10 lines of code?

> >> As a Debian packager, though, I would most likely just trust the authors
> >> of start-stop-daemon and its --make-pidfile.
> >
> >--make-pidfile, --exec, and friends, are all ugly workarounds for buggy
> >daemons that can't write a pidfile.
> 
> And I think that it is less broken to use them than to patch
> third-party software.

Patching third-party software is the majority of what we do.  Why is
this a problem?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: LSB-ize daemon without pidfile handling

[Raphael Geissert]

Marc Haber wrote:
> On Sat, 10 Nov 2007 17:00:13 +0100, Wouter Verhelst
> <[EMAIL PROTECTED]> wrote:
>>That is one way to look at it. The other way would be that these are
>>just three lines of "code" being duplicated here, and that start_daemon
>>is just a convenience function, nothing more.
> 
> So, start_daemon is not part of the standard?

Actually, it is[1] (opening b.d.o/debhelper and check for an existing report
about it: /usr/share/debhelper/dh_make/debian/init.d.lsb.ex)

> 
> Greetings
> Marc
> 

[1]
http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Raphael Geissert]

Marc Haber wrote:
> On Fri, 09 Nov 2007 22:00:42 +0100, Petter Reinholdtsen
> <[EMAIL PROTECTED]> wrote:
>>[Marc Haber]
>>> I do not plan to do so for obvious reasons.
>>
>>It is not obvious for me.  Can you explain why it should be obvious
>>that you do not plan to patch the daemon to write its own pid file?
>>For me, the obvious solution for a daemon unable to write its own pid
>>file is to patch the daemon.
> 
> I generally try not to patch upstream code if avoidable. Especially if
> a patch would not be acceptable to upstream in the form we would apply
> as a quick fix (no command line option, hard-coded path to the pid
> file).

Then why don't you do it The Right Way (tm)?
It isn't hard to read command line arguments with options, see man
getopt(3?).

> 
> Greetings
> Marc
> 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Sun, 11 Nov 2007 11:47:49 +, Stephen Gran <[EMAIL PROTECTED]>
wrote:
>This one time, at band camp, Marc Haber said:
>> How many seconds until the "please make pidfile location configurable"
>> wishlist bug?
>
>Which is another, what, 5-10 lines of code?

I do not feel able to write C code for string operations without
introducing a truckload of buffer overflows and off-by-one-errors.

>> And I think that it is less broken to use them than to patch
>> third-party software.
>
>Patching third-party software is the majority of what we do.

I think we integrate them.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Sun, 11 Nov 2007 17:48:45 -0600, Raphael Geissert
<[EMAIL PROTECTED]> wrote:
>Then why don't you do it The Right Way (tm)?

No time, not enough C skill. To much other things to do.

If it is a requirement to be able to do bug-free C string operations
to be a DD, please remove me from the keyring.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: LSB-ize daemon without pidfile handling

[Reinhard Tartler]

Marc Haber <[EMAIL PROTECTED]> writes:

> On Sun, 11 Nov 2007 17:48:45 -0600, Raphael Geissert
> <[EMAIL PROTECTED]> wrote:
>>Then why don't you do it The Right Way (tm)?
>
> No time, not enough C skill. To much other things to do.
>
> If it is a requirement to be able to do bug-free C string operations
> to be a DD, please remove me from the keyring.

FWIW, I don't think that a DD is required to be able to prove
correctness of the code he is writing. At least my NM process didn't
suggest that to me.

However, I'd generally expect a Maintainer to be rather familiar with
the programming language of the software he is packaging, so he is able
to modify it so that it integrates with the rest of the debian system.
And this does fall into the case we are currently discussing.


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Robert Edmonds]

On 2007-11-14, Marc Haber <[EMAIL PROTECTED]> wrote:
> On Sun, 11 Nov 2007 11:47:49 +, Stephen Gran <[EMAIL PROTECTED]>
> wrote:
>>This one time, at band camp, Marc Haber said:
>>> How many seconds until the "please make pidfile location configurable"
>>> wishlist bug?
>>
>>Which is another, what, 5-10 lines of code?
>
> I do not feel able to write C code for string operations without
> introducing a truckload of buffer overflows and off-by-one-errors.

Have you tried asking the author of ser2net if he is willing to add the
functionality...?

Anyway, here's a (compile-tested only) patch:

--- ser2net-2.3/ser2net.c   2005-03-10 10:59:53.0 -0500
+++ ser2net-2.3.pidfile/ser2net.c   2007-11-14 12:56:07.885930455 -0500
@@ -41,6 +41,7 @@
 
 static char *config_file = "/etc/ser2net.conf";
 static char *config_port = NULL;
+static char *pid_file = NULL;
 static int detach = 1;
 static int debug = 0;
 #ifdef USE_UUCP_LOCKING
@@ -59,6 +60,7 @@ static char *help_string =
 " you must specify a -c after the last -C to have it read a config\n"
 " file, too."
 "  -p  - Start a controller session on the given TCP port\n"
+"  -P  - set location of pid file\n"
 "  -n - Don't detach from the controlling terminal\n"
 "  -d - Don't detach and send debug I/O to standard output\n"
 #ifdef USE_UUCP_LOCKING
@@ -83,6 +85,16 @@ arg_error(char *name)
 exit(1);
 }
 
+void
+make_pidfile(char *pidfile)
+{
+FILE *fpidfile;
+if (pidfile && (fpidfile = fopen(pidfile, "w"))) {
+   fprintf(fpidfile, "%d\n", getpid());
+   fclose(fpidfile);
+}
+}
+
 int
 main(int argc, char *argv[])
 {
@@ -147,6 +159,15 @@ main(int argc, char *argv[])
}
config_port = argv[i];
break;
+   
+   case 'P':
+   i++;
+   if (i == argc) {
+   fprintf(stderr, "No pid file specified with -P\n");
+   arg_error(argv[0]);
+   }
+   pid_file = argv[i];
+   break;
 
 #ifdef USE_UUCP_LOCKING
case 'u':
@@ -206,6 +227,10 @@ main(int argc, char *argv[])
close(0);
close(1);
close(2);
+
+   /* write pid file */
+   make_pidfile(pid_file);
+
 } else if (debug) {
openlog("ser2net", LOG_PID | LOG_CONS | LOG_PERROR, LOG_DAEMON);
 }

-- 
Robert Edmonds
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Josselin Mouette]

Le dimanche 11 novembre 2007 à 17:48 -0600, Raphael Geissert a écrit :
> Then why don't you do it The Right Way (tm)?
> It isn't hard to read command line arguments with options, see man
> getopt(3?).

Oh yes it is, because getopt is an arcane and error-prone interface.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: LSB-ize daemon without pidfile handling

[Wouter Verhelst]

On Sun, Nov 11, 2007 at 12:40:16PM +0100, Marc Haber wrote:
> On Sat, 10 Nov 2007 17:00:13 +0100, Wouter Verhelst
> <[EMAIL PROTECTED]> wrote:
> >That is one way to look at it. The other way would be that these are
> >just three lines of "code" being duplicated here, and that start_daemon
> >is just a convenience function, nothing more.
> 
> So, start_daemon is not part of the standard?

I didn't say that. Just that there might be multiple interfaces defined
in the standard whom just happen to do the same thing (except that one
way is shorter).

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Wouter Verhelst]

On Wed, Nov 14, 2007 at 03:16:28PM +0100, Marc Haber wrote:
> On Sun, 11 Nov 2007 11:47:49 +, Stephen Gran <[EMAIL PROTECTED]>
> wrote:
> >This one time, at band camp, Marc Haber said:
> >> How many seconds until the "please make pidfile location configurable"
> >> wishlist bug?
> >
> >Which is another, what, 5-10 lines of code?
> 
> I do not feel able to write C code for string operations without
> introducing a truckload of buffer overflows and off-by-one-errors.

man 3 snprintf

> >> And I think that it is less broken to use them than to patch
> >> third-party software.
> >
> >Patching third-party software is the majority of what we do.
> 
> I think we integrate them.

Well, we disagree then.

Even so, there's also nobody who told you that you can't supply the
patch upstream. Once it gets accepted there, it turns into a classic
case of Somebody Else's Problem[TM].

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Wed, 14 Nov 2007 17:57:56 + (UTC), Robert Edmonds
<[EMAIL PROTECTED]> wrote:
>Anyway, here's a (compile-tested only) patch:

Which I have submitted upstream (Debian #451472). Thanks!

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Fri, 16 Nov 2007 14:53:47 +0100, Marc Haber
<[EMAIL PROTECTED]> wrote:
>On Wed, 14 Nov 2007 17:57:56 + (UTC), Robert Edmonds
><[EMAIL PROTECTED]> wrote:
>>Anyway, here's a (compile-tested only) patch:
>
>Which I have submitted upstream (Debian #451472). Thanks!

And which Upstream has alreay accepted and released a new version.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: LSB init scripts and multiple lines of output

[Gustavo Franco]

On 6/1/06, martin f krafft <[EMAIL PROTECTED]> wrote:

Hi,

I am faced with the problem on how to tackle multiline output from
an init.d script, which I have just converted to LSB. Since the
package is mdadm and RAID is kinda essential to those that have it
configured, I'd rather not hide information but give the user the
entire process.

In my ideal world, this is what it would look like:

Starting RAID devices ...
  /dev/md0 has been started with 3 drives.
  /dev/md1 has been started with 3 drives.
  /dev/md2 assembled from 2 drives - need all 3 to start it
  /dev/md3 assembled from 1 drive - not enough to start the array.
  /dev/md4 has been started with 3 drives.
... done assembling RAID devices: failed.

I don't seem to be able to realise this with lsb-base, nor does it
seem that they even provide for this. The alternative -- all in one
line -- just seems rather uninviting:

  Starting RAID devices ... /dev/md0 has been started with 3 drives,
  /dev/md1 has been started with 3 drives, /dev/md2 assembled from
  2 drives - need all 3 to start it, /dev/md3 assembled from 1 drive
  - not enough to start the array, /dev/md4 has been started with
  3 drives. failed.

Generally, I would not have a problem doing something like

  Starting RAID devices ... failed (see log for details).

But the problem is quite simply that by the time the script runs,
/var may not be there, and neither is /usr/bin/logger.

So what to do?

My current approach, which is to map short terms to the long errors
is just too much of an obfuscating hack, and it runs more than 80
characters as well:

  Starting RAID devices ... md0 started, md1 started, md2
  degraded+started, md3 degraded+failed, md4 started ... failed.

Any suggestions?


Yes.

Starting RAID devices ... md0 ok, md1 ok, md2 2/3, md3 failed, md4
ok ... failed

I would go to check why just 2 out of 3 disks are ok in md2 and why
md3 failed. The only missing information from the output above is if
md3 failed with 0 or 1 disk ok.

I really think that all that multpline lines are annoying and hard to debug,
since it's not in RAID services but almost everywhere.

If the service 'foo' isn't starting and you've no idea the reason, because
there's too much stuff to read during the boot, it will be easier just look
at 'md3 failed', and associate it with the mountpoint that hosts the files
for that service. Unfortunately it seems that the common sense says
otherwise, and people are just populating more and more the boot
output as admin it isn't useful for me, really.

regards,
-- stratus


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[Andreas Fester]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

martin f krafft wrote:
> I am faced with the problem on how to tackle multiline output from
> an init.d script, which I have just converted to LSB. Since the
> package is mdadm and RAID is kinda essential to those that have it
> configured, I'd rather not hide information but give the user the
> entire process.
> 
> In my ideal world, this is what it would look like:
> 
> Starting RAID devices ...
>   /dev/md0 has been started with 3 drives.
>   /dev/md1 has been started with 3 drives.
>   /dev/md2 assembled from 2 drives - need all 3 to start it
>   /dev/md3 assembled from 1 drive - not enough to start the array.
>   /dev/md4 has been started with 3 drives.
> ... done assembling RAID devices: failed.
> 
> I don't seem to be able to realise this with lsb-base, nor does it
> seem that they even provide for this. The alternative -- all in one
[...]

what about

$ cat raid
. /lib/lsb/init-functions

log_action_msg "Starting RAID devices ..."
log_action_msg "  /dev/md0 has been started with 3 drives."
log_action_msg "  /dev/md1 has been started with 3 drives."
log_action_msg "  /dev/md2 assembled from 2 drives - need all 3 to start it"
log_action_msg "  /dev/md3 assembled from 1 drive - not enough to start the 
array."
log_action_msg "  /dev/md4 has been started with 3 drives."
log_failure_msg "... done assembling RAID devices: failed."

$ ./raid
Starting RAID devices ...
  /dev/md0 has been started with 3 drives..
  /dev/md1 has been started with 3 drives..
  /dev/md2 assembled from 2 drives - need all 3 to start it.
  /dev/md3 assembled from 1 drive - not enough to start the array..
  /dev/md4 has been started with 3 drives..
* ... done assembling RAID devices: failed.


Best Regards,

Andreas


- --
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEfyVLZ3bQVzeW+rsRAvD/AKCJza+5KPQOZ2wMVm/5upylsdcEjgCdFmT7
kfYIlW9IyE/Lcf4gZuWtzOU=
=HR7O
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[martin f krafft]

also sprach Andreas Fester <[EMAIL PROTECTED]> [2006.06.01.1935 +0200]:
> log_action_msg "Starting RAID devices ..."

log_action_msg is supposed to be used to log an atomic message,
which is not the case the way we/you use it here.

> log_failure_msg "... done assembling RAID devices: failed."

According to /usr/share/doc/lsb-base/README.Debian, this function
does not comply with Debian policy. Whether I can actually use it or
not isn't exactly clear from the README.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
i'd rather be riding a high speed tractor
with a beer on my lap,
and a six pack of girls next to me.


signature.asc
Description: Digital signature (GPG/PGP)

Re: LSB init scripts and multiple lines of output

[Andreas Fester]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

martin f krafft wrote:
> > also sprach Andreas Fester <[EMAIL PROTECTED]> [2006.06.01.1935 +0200]:
>> >> log_action_msg "Starting RAID devices ..."
> >
> > log_action_msg is supposed to be used to log an atomic message,
> > which is not the case the way we/you use it here.

why did I already expect that without having read the documentation?  :-(

module-init-tools also use the lsb functions, but they use
a raw "echo" to print the module list, one module per line.
Probably not the solution you are looking for ...

Another possibility:

log_begin_msg "Starting RAID devices ..."
log_success_msg "  /dev/md0 has been started with 3 drives."
log_success_msg "  /dev/md1 has been started with 3 drives."
log_failure_msg "  /dev/md2 assembled from 2 drives - need all 3 to start it"
log_failure_msg "  /dev/md3 assembled from 1 drive - not enough to start the 
array."
log_success_msg "  /dev/md4 has been started with 3 drives."
log_failure_msg "... done assembling RAID devices: failed."

but I did not have a look into the log_failure_msg and log_success_msg
constraints. I think there are no other possibilities because all
other functions internalls use "echo -n", and adding the line feed manually
might also not be what you want...

Regards,

Andreas

- --
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEfyxjZ3bQVzeW+rsRAt8qAJ4hIS/3TYtjC0UT/awzh3/TKDZPVwCggbMx
Dl+KYP3c3nYpDH+Lwxfqxt0=
=Bl++
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[Daniel Jacobowitz]

On Thu, Jun 01, 2006 at 06:51:54PM +0200, martin f krafft wrote:
> In my ideal world, this is what it would look like:
> 
> Starting RAID devices ...
>   /dev/md0 has been started with 3 drives.
>   /dev/md1 has been started with 3 drives.
>   /dev/md2 assembled from 2 drives - need all 3 to start it
>   /dev/md3 assembled from 1 drive - not enough to start the array.
>   /dev/md4 has been started with 3 drives.
> ... done assembling RAID devices: failed.

Have you considered:

Starting RAID device md0 ... 3 drives, done
Starting RAID device md1 ... 3 drives, done
Starting RAID device md2 ... 2/3 drives, degraded
Starting RAID device md3 ... 1/3 drives, failed
Starting RAID device md4 ... 3 drives, done

-- 
Daniel Jacobowitz
CodeSourcery


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[martin f krafft]

also sprach Daniel Jacobowitz <[EMAIL PROTECTED]> [2006.06.01.2012 +0200]:
> Starting RAID device md0 ... 3 drives, done
> Starting RAID device md1 ... 3 drives, done
> Starting RAID device md2 ... 2/3 drives, degraded
> Starting RAID device md3 ... 1/3 drives, failed
> Starting RAID device md4 ... 3 drives, done

What do people think about that?

The only problem is that I start them all at once, then parse the
output. So the above is not really true.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"when faced with a new problem, the wise algorithmist
 will first attempt to classify it as np-complete.
 this will avoid many tears and tantrums as
 algorithm after algorithm fails."
  -- g. niruta


signature.asc
Description: Digital signature (GPG/PGP)

Re: LSB init scripts and multiple lines of output

[martin f krafft]

also sprach martin f krafft <[EMAIL PROTECTED]> [2006.06.01.2122 +0200]:
> > Starting RAID device md0 ... 3 drives, done
> > Starting RAID device md1 ... 3 drives, done
> > Starting RAID device md2 ... 2/3 drives, degraded
> > Starting RAID device md3 ... 1/3 drives, failed
> > Starting RAID device md4 ... 3 drives, done
> 
> What do people think about that?
> 
> The only problem is that I start them all at once, then parse the
> output. So the above is not really true.

"not true" means that I am not "starting" md1 after md0 has started
successfully.

Right now, the script does this:

Stopping RAID devices... md6 busy; md5 busy; md3 busy; md2 busy; md0
busy; md1 busy; failed (6 busy, 1 stopped).
Starting RAID devices... md0 running; md1 running; md2 running; md3
running; md4 started (3/3); md5 running; md6 running; done (6
running, 1 started, 0 failed).

Which do people prefer? Btw: I cannot yet log which ones have been
stopped, there's no easy way to find out with only POSIX and without
/usr/bin/*.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
what do you mean, it's not packaged in debian?


signature.asc
Description: Digital signature (GPG/PGP)

Re: LSB init scripts and multiple lines of output

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

martin f krafft wrote:
> also sprach Daniel Jacobowitz <[EMAIL PROTECTED]> [2006.06.01.2012 +0200]:
>> Starting RAID device md0 ... 3 drives, done
>> Starting RAID device md1 ... 3 drives, done
>> Starting RAID device md2 ... 2/3 drives, degraded
>> Starting RAID device md3 ... 1/3 drives, failed
>> Starting RAID device md4 ... 3 drives, done
> 
> What do people think about that?
> 
> The only problem is that I start them all at once, then parse the
> output. So the above is not really true.

Starting them individually just seems "better" IMO, more atomic.

For example, if starting md1 pukes really hard, the parent process
still exists to start md[234].

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEf0bpS9HxQb37XmcRAhoZAJ4ydDm3roD7c9iuFKach2pwMgab/gCgpvjc
HaPS22BbDcMgUKlFaEkWDbw=
=dIUY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[martin f krafft]

also sprach Ron Johnson <[EMAIL PROTECTED]> [2006.06.01.2158 +0200]:
> Starting them individually just seems "better" IMO, more atomic.

Mh, I would have to do config file parsing in the init.d script to
figure out all available devices. mdadm already handles it; it
starts all devices that haven't been started; short of a segfault,
nothing can prevent it from starting md1 after md0 failed.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"everyone has a little secret he keeps,
 i like the fires when the city sleeps."
  -- mc 900 ft jesus


signature.asc
Description: Digital signature (GPG/PGP)

Re: LSB init scripts and multiple lines of output

[martin f krafft]

also sprach martin f krafft <[EMAIL PROTECTED]> [2006.06.01.2150 +0200]:
> Stopping RAID devices... md6 busy; md5 busy; md3 busy; md2 busy; md0
> busy; md1 busy; failed (6 busy, 1 stopped).
> Starting RAID devices... md0 running; md1 running; md2 running; md3
> running; md4 started (3/3); md5 running; md6 running; done (6
> running, 1 started, 0 failed).
> 
> Which do people prefer? Btw: I cannot yet log which ones have been
> stopped, there's no easy way to find out with only POSIX and without
> /usr/bin/*.

Here's the other version:

piper:~# /etc/init.d/mdadm-raid restart   [575]
Stopping RAID array md6...failed (busy).
Stopping RAID array md5...failed (busy).
Stopping RAID array md0...failed (busy).
Stopping RAID array md1...failed (busy).
Stopping RAID arrays...done (3 array(s) stopped).
Starting RAID array md0...done (already running).
Starting RAID array md1...done (already running).
Starting RAID array md2...failed (not enough devices).
Starting RAID array md3...done (started, degraded [2/3]).
Starting RAID array md4...done (started [3/3]).
Starting RAID array md5...done (already running).
Starting RAID array md6...done (already running).

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"everyone smiles as you drift past the flower
 that grows so incredibly high."
-- the beatles


signature.asc
Description: Digital signature (GPG/PGP)

Re: LSB init scripts and multiple lines of output

[Adam Borowski]

On Thu, Jun 01, 2006 at 06:51:54PM +0200, martin f krafft wrote:
> In my ideal world, this is what it would look like:
> 
> Starting RAID devices ...
>   /dev/md0 has been started with 3 drives.
>   /dev/md1 has been started with 3 drives.
>   /dev/md2 assembled from 2 drives - need all 3 to start it
>   /dev/md3 assembled from 1 drive - not enough to start the array.
>   /dev/md4 has been started with 3 drives.
> ... done assembling RAID devices: failed.
[...]
> Generally, I would not have a problem doing something like
> 
>   Starting RAID devices ... failed (see log for details).

Really, PLEASE, don't!
Hiding information is _never_ good.  For any reason.  Even if you
expect the user to be non-technical.


Let me go into a longer rant, only partially on the topic.


I witnessed a smart but non-guru user install a certain brand new
Debian-like distribution on her home box today.  That person is a
physicist doing medical research, with no sysadmin experience but
familiar with quite a bunch of Unices.
The machine was known to be good except for the disk, which in turn
was checked on an identical box before.

The trouble she faced consistent of a number of _random_ breakages
with totally no usable error messages:
* In about 1/3 tries, parted failed with whatever the error message
  was hidden by the installer's GUI.  Tell me, how she was supposed
  to figure out what's wrong?  (Skipping the fact that something as
  dangerous as parted should never be allowed to break in a common
  setup [1].)

* At some point during the main installation phase (with nothing but
  a progressbar shown), the installer coughed up and barfed a window
  full of a Python backtrace right in the user's face, then died.  I
  looked at the dialog, but couldn't figure out what went wrong,
  either.  Perhaps taking a look at the logs (HIDDEN FROM THE USER)
  would be insightful, but the friend claimed that if the
  installation is supposed to be graphical, she's not going to let me
  do everything by hand [2].

  Where's the goddamn meaningful error message?  

* Two times, a dialog simply popped up, saying: "The installer has
  crashed".  Just that.  Without a single damn word about the cause,
  or even just a mention of what it was doing at the time.

  The friend muttered something about Ubuntu being as flaky as
  Windows, then rebooted and started the installation anew...

* The GUI network setup tools simply ignore any failures.  After
  choosing a SSID from a list (the list shows that the hardware and
  kernel-side stuff was working ok) then clicking "Activate", the
  dialog simply shows nothing for ~20sec and then acts as if
  everything was in working order.

  What was wrong?  Can you tell me from the provided information? 
  Current vanilla text-mode Debian will give you a message after
  every action.  With Ubuntu, you need to dig deeply to force the
  system to reveal what's going on.

Finally, I had to leave; the friend hasn't succeed yet.

[1]. A 50GB unformatted primary partition, the rest being on
extended: two 50GB unformatted ones, 50+GB ext3 on /home, 1GB swap,
7GB ext3 on /.

[2]. Get a reflex of going into mkfs/debootstrap mode at the smell of
the first installer trouble and people will start spreading evil
rumors about you :p


--End of rant--

Now, let's go into your question:
> Starting RAID devices ...
>   /dev/md0 has been started with 3 drives.
>   /dev/md1 has been started with 3 drives.
>   /dev/md2 assembled from 2 drives - need all 3 to start it
>   /dev/md3 assembled from 1 drive - not enough to start the array.
>   /dev/md4 has been started with 3 drives.
> ... done assembling RAID devices: failed.

An user who has just the basic idea what RAID is will know what's
going on instantly.  When they'll call you, you will be able to help
them right away.

> Starting RAID devices ... failed (see log for details).

Now, you'll have to explain to the user how to get to the log.  And
what if the system is inoperative (with failed RAID, it almost
certainly will be)?


You can't be too verbose, but if you hide the most important parts,
it will be a great disservice to the users.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[Arjan Oosting]

Op do, 01-06-2006 te 22:29 +0200, schreef martin f krafft:
> also sprach martin f krafft <[EMAIL PROTECTED]> [2006.06.01.2150 +0200]:
> > Stopping RAID devices... md6 busy; md5 busy; md3 busy; md2 busy; md0
> > busy; md1 busy; failed (6 busy, 1 stopped).
> > Starting RAID devices... md0 running; md1 running; md2 running; md3
> > running; md4 started (3/3); md5 running; md6 running; done (6
> > running, 1 started, 0 failed).
> > 
> > Which do people prefer? Btw: I cannot yet log which ones have been
> > stopped, there's no easy way to find out with only POSIX and without
> > /usr/bin/*.
> 
> Here's the other version:
> 
> piper:~# /etc/init.d/mdadm-raid restart   
> [575]
> Stopping RAID array md6...failed (busy).
> Stopping RAID array md5...failed (busy).
> Stopping RAID array md0...failed (busy).
> Stopping RAID array md1...failed (busy).
> Stopping RAID arrays...done (3 array(s) stopped).
> Starting RAID array md0...done (already running).
> Starting RAID array md1...done (already running).
> Starting RAID array md2...failed (not enough devices).
> Starting RAID array md3...done (started, degraded [2/3]).
> Starting RAID array md4...done (started [3/3]).
> Starting RAID array md5...done (already running).
> Starting RAID array md6...done (already running).
Seems ok to me. This way all boot messages look consistent. 

It would be nice if the log_action_end_msg would support warnings in
addition to succes and failures, so the output would clearly distinguish
a degraded array from a completely succesfully started array.

Greetings Arjan
 


signature.asc
Description: Dit berichtdeel is digitaal ondertekend

Re: LSB init scripts and multiple lines of output

[martin f krafft]

also sprach Arjan Oosting <[EMAIL PROTECTED]> [2006.06.01.2307 +0200]:
> It would be nice if the log_action_end_msg would support warnings
> in addition to succes and failures, so the output would clearly
> distinguish a degraded array from a completely succesfully started
> array.

Consider filing a bug? It would be trivial, but the question is
whether we want to extend the policy in that way.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"geld ist das brecheisen der macht."
 - friedrich nietzsche


signature.asc
Description: Digital signature (GPG/PGP)

Re: LSB init scripts and multiple lines of output

[Matthew R. Dempsky]

On Thu, Jun 01, 2006 at 06:51:31PM +0200, martin f krafft wrote:
> Any suggestions?

Submit a feature request to LSB?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[martin f krafft]

also sprach Matthew R. Dempsky <[EMAIL PROTECTED]> [2006.06.02.0238 +0200]:
> > Any suggestions?
> 
> Submit a feature request to LSB?

And wait 15 years?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
microsoft: for when quality, reliability, and security
   just aren't that important!


signature.asc
Description: Digital signature (GPG/PGP)

Re: LSB init scripts and multiple lines of output

[Matthew R. Dempsky]

On Fri, Jun 02, 2006 at 02:44:54AM +0200, martin f krafft wrote:
> also sprach Matthew R. Dempsky <[EMAIL PROTECTED]> [2006.06.02.0238 +0200]:
> > > Any suggestions?
> > 
> > Submit a feature request to LSB?
> 
> And wait 15 years?

Eh, that's only 2 or 3 debian releases from now.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[Joey Hess]

Adam Borowski wrote:
>   The friend muttered something about Ubuntu being as flaky as
>   Windows, then rebooted and started the installation anew...

This is not an Ubuntu mailing list. It's pretty annoying to require all
us d-i developers to get this far down in the mail before we realize
that the problems you are describing are (probably) not d-i problems.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: LSB init scripts and multiple lines of output

[Thomas Viehmann]

martin f krafft wrote:
> also sprach martin f krafft <[EMAIL PROTECTED]> [2006.06.01.2122 +0200]:
>>> Starting RAID device md0 ... 3 drives, done
>>> Starting RAID device md1 ... 3 drives, done
>>> Starting RAID device md2 ... 2/3 drives, degraded
>>> Starting RAID device md3 ... 1/3 drives, failed
>>> Starting RAID device md4 ... 3 drives, done
>> What do people think about that?

Would combining the drives that went well make sense?
Starting RAID devices...  md0, md1, md4 done
Starting RAID device md2 ... 2/3 drives, degraded
Starting RAID device md3 ... 1/3 drives, failed

The "Starting RAID devices..." could be put before the startup.
I guess the gain I see is that on normal operation only one line is
printed while providing more detailed and still legible information in
case of a failure.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[Adam Borowski]

On Fri, Jun 02, 2006 at 02:36:15AM -0400, Joey Hess wrote:
> Adam Borowski wrote:
> >   The friend muttered something about Ubuntu being as flaky as
> >   Windows, then rebooted and started the installation anew...
> 
> This is not an Ubuntu mailing list. It's pretty annoying to require all
> us d-i developers to get this far down in the mail before we realize
> that the problems you are describing are (probably) not d-i problems.

My sincere apologies.  For my defense, I was ranting about "why
hiding error messages is unacceptable" not about "the installation is
bad", but certainly mentioning just "a certain brand new Debian-like
distribution" wasn't clear enough.


And I still haven't completed the report I once promised on the
behavior of d-i on low-end 486 with various amounts of memory...

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[martin f krafft]

also sprach Thomas Viehmann <[EMAIL PROTECTED]> [2006.06.02.0847 +0200]:
> Would combining the drives that went well make sense?
> Starting RAID devices...  md0, md1, md4 done
> Starting RAID device md2 ... 2/3 drives, degraded
> Starting RAID device md3 ... 1/3 drives, failed

Nice, but is it worth the trouble? Remember, I need to do all this
with POSIX shell. Sure, it's not that hard, but...

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"ah, but a man's reach should exceed his grasp,
 or what's a heaven for?"
-- robert browning


signature.asc
Description: Digital signature (GPG/PGP)

Re: [lsb-discuss] Does anyone care about LSB on arm?

[Jeff Licquia]

On 06/01/2011 07:25 AM, Luke Kenneth Casson Leighton wrote:

  so in _that_ regard, the question becomes: "are the efforts of the
free software community better off being spent elsewhere"?  and "what
benefit is there *TO THE FREE SOFTWARE COMMUNITY* of doing LSB for
ARM"?  forget the proprietary junkies, they'll suck anything from us
that moves and not give a dime in return.


That seems to be my cue to provide the community case for the LSB.

The LSB provides several things to the community:

 - a framework for allowing Linux distributions to pool their userbase 
and work together as one platform instead of multiple platforms, one per 
distro


 - test suites which identifies both compatibility problems and 
outright bugs to be detected and fixed


 - a method for targeting builds at multiple distributions at once, 
both proprietary and free


 - reporting tools for finding portability problems in built apps, 
again for both proprietary and free apps


We currently provide all of this for 7 architectures.  ARM benefits 
indirectly (for example, many of the compatibility breaks detected on, 
say, x86_64 will affect all archs equally), but indirect support doesn't 
include the tools we've developed, and often compatibility issues are 
arch-specific.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de653fd.5080...@licquia.org

Re: [lsb-discuss] Does anyone care about LSB on arm?

[Jesse Barker]

At the risk of overstating the obvious, there are also ABI guarantees
at stake here, which in my mind are architecture agnostic.  OpenGL
applications need to know which bits (API functions) of which core
versions can be expected to be resolved during load time and which
must be queried through GetProcAddress.  LSB specifies this and makes
it unambiguous.

cheers,
Jesse

On Wed, Jun 1, 2011 at 8:00 AM, Jeff Licquia  wrote:
> On 06/01/2011 07:25 AM, Luke Kenneth Casson Leighton wrote:
>>
>>  so in _that_ regard, the question becomes: "are the efforts of the
>> free software community better off being spent elsewhere"?  and "what
>> benefit is there *TO THE FREE SOFTWARE COMMUNITY* of doing LSB for
>> ARM"?  forget the proprietary junkies, they'll suck anything from us
>> that moves and not give a dime in return.
>
> That seems to be my cue to provide the community case for the LSB.
>
> The LSB provides several things to the community:
>
>  - a framework for allowing Linux distributions to pool their userbase and
> work together as one platform instead of multiple platforms, one per distro
>
>  - test suites which identifies both compatibility problems and outright
> bugs to be detected and fixed
>
>  - a method for targeting builds at multiple distributions at once, both
> proprietary and free
>
>  - reporting tools for finding portability problems in built apps, again for
> both proprietary and free apps
>
> We currently provide all of this for 7 architectures.  ARM benefits
> indirectly (for example, many of the compatibility breaks detected on, say,
> x86_64 will affect all archs equally), but indirect support doesn't include
> the tools we've developed, and often compatibility issues are arch-specific.
>
> ___
> linaro-dev mailing list
> linaro-...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktin3xg2ohzpjnklhm9w9xa-e7v5...@mail.gmail.com

Re: lsb-base "Fancy output"; please test lsb-base/experimental (4.1+Debian0+fancy0)

[Lisandro Damián Nicanor Pérez Meyer]

On Mié 04 Abr 2012 06:35:49 Didier 'OdyX' Raboud escribió:
> Hi -devel (and -lsb),
> 
> I have recently uploaded lsb-base 4.1+Debian0+fancy0 to experimental. As
> this version introduces a small change that has a big visual impact on
> the Debian boot, I would like to get some feedback on it before
> uploading it to unstable.

Just for the record: I like it :-)

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: lsb-base "Fancy output"; please test lsb-base/experimental (4.1+Debian0+fancy0)

[Thomas Goirand]

On 04/04/2012 05:35 PM, Didier 'OdyX' Raboud wrote:
> Hi -devel (and -lsb),
>
> I have recently uploaded lsb-base 4.1+Debian0+fancy0 to experimental. As
> this version introduces a small change that has a big visual impact on
> the Debian boot, I would like to get some feedback on it before
> uploading it to unstable.
>
> In short, this version implements a new "fancy output" in the form of
> [] blocks prepended to the daemon status messages:
>
>   Before:
>  Starting/stopping long daemon name: daemond daemon2d
>   After:
>  [] Starting/stopping long daemon name: daemond daemon2d
>
> This block will become either a green [ ok ], a yellow [warn] or a red
> [FAIL] depending on the daemon exit status. I plan to implement blue
> [info] blocks for log_action_msg calls too.
>   
I like it as well. *please* don't remove it, and send this to SID,
even deactivated by default (a simple switch in a configuration
file to have this would be cool anyway).

Debian shouldn't be the only distro where things stay ugly... :)

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8c4bd9.2010...@debian.org

Re: lsb-base "Fancy output"; please test lsb-base/experimental (4.1+Debian0+fancy0)

[Didier Raboud]

Hi -devel (and -lsb),

Le mercredi, 4 avril 2012 11.35:49, Didier 'OdyX' Raboud a écrit :
> I have recently uploaded lsb-base 4.1+Debian0+fancy0 to experimental. As
> this version introduces a small change that has a big visual impact on
> the Debian boot, I would like to get some feedback on it before
> uploading it to unstable.

Given the feedback I got and 7 days in experimental, I have just uploaded this 
change to unstable; let's see how much bugs it triggers!

Many thanks to those that provided concerns and feedback, it has been 
valuable.

Cheers, OdyX


signature.asc
Description: This is a digitally signed message part.

Re: LSB headers and other junk, how do you hack a quick init script in debian these days?

[Michael Ole Olsen]

Who needs to document their own pc they hack on daily?

suddenly I couldnt just place a script in rc2.d folder anymore, needed to 
symlink
needed to add an lsb header too it seems

maybe I'm overlooking something

I prefer to hack on my own without using debian tools, update-rc.d i.e.

would be nice to be able to place a script in rc2.d folder again, even though 
it isn't a symlink

it seems that 'feature' has been removed in the new debians

I wouldn't do it at work/anywhere where documentation is important though
but why force people to document / use the right tools?

I prefer an OS that is easy to hack around

debian init scripts is something that frustrates me often, because I can't just 
hack them easily
need to symlink in different folders or use the debian tool
got no experience with sysV or whatever it uses, only bash programming which I 
am fairly good with

so it frustrates me that hacking initscripts should be so annoying at times :P

it used to work good back in the days, I could just add an S99mio and that 
would get executed after booting
not anymore, now it needs to be symlinked and all it seems

there used to be an /etc file one could edit to make boot scripts
anyone remember which one?

rc.local or such I think, but not sure anymore, debian has changed a bit lately 
it seems

How do you hack a quick init script these days?:)

> 
> On Tue, 21 Oct 2014, Martinx - ジェームズ wrote:
> 
> > Hey Paul,
> > 
> > I really appreciate your feedback. Glad to see that at least, systemd in
> > Debian have some boundaries. Whew! Tks!
> > 
> > I'll try to disable html messages for all Debian Lists at my GMail account
> > right now, sorry about that.
> > 
> > Nevertheless, I'm not flaming (not my intention, really), I care about
> > Debian. ;-)
> > 
> > Cheers!
> > Thiago
> > 
> > ** We don't need "kdbus @ PID 1". It did not got merged into Linux 3.15...
> > Think about it.*
> > ** uselessd might replace systemd, since it have all that CGroups cool
> > stuff, without systemd's useless bits. We just need a new udev!  :-P*
> > 
> > On 21 October 2014 02:21, Paul Wise  wrote:
> > 
> > > Please do not use HTML mail on Debian lists.
> > >
> > > Please do not flame on Debian lists.
> > >
> > > https://www.debian.org/MailingLists/#codeofconduct
> > > https://www.debian.org/code_of_conduct
> > >
> > > On Tue, Oct 21, 2014 at 1:34 AM, Martinx - ジェームズ wrote:
> > >
> > > > tried it without success, lots of bugs popped everywhere when with
> > > systemd),
> > >
> > > Please file bugs about issues you find in Debian packages:
> > >
> > > https://www.debian.org/Bugs/Reporting
> > >
> > > >
> > > http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
> > > ...
> > > > So, is systemd even trying to replace dpkg+apt too?
> > >
> > > No.
> > >
> > > --
> > > bye,
> > > pabs
> > >
> > > https://wiki.debian.org/PaulWise
> > >


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141021064119.ga31...@rlogin.dk

Re: LSB headers and other junk, how do you hack a quick init script in debian these days?

[Josselin Mouette]

Michael Ole Olsen  wrote: 
How do you hack a quick init script these days?:)

I write a systemd unit file. It’s smaller, faster to write, easier to
understand and works more reliably. 

Cheers,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413876487.4673.191.camel@dsp0698014

Re: LSB headers and other junk, how do you hack a quick init script in debian these days?

[Thorsten Glaser]

On Tue, 21 Oct 2014, Michael Ole Olsen wrote:

> suddenly I couldnt just place a script in rc2.d folder anymore, needed to 
> symlink
> needed to add an lsb header too it seems

Indeed.

It took me quite some effort to learn about LSB headers, exit codes,
SYSV init scripts, and all that, in order to fix our machines, on
which coworkers had put “init scripts”, after Debian forcefully
required insserv even for file-rc. (I come from a DOS/BSD background,
so I haven’t had to deal with all that before.)

That was shortly before systemd was introduced. Just when I finally
learned how to write a proper Debian SYSV init script for things
like JBoss/Wildfly with Liferay.

I was not amused.

I’ll be amused when my coworkers upgrade systems I have no control
over, will get systemd (despite my warnings), and their scripts
and systemd will have “interesting” effects because they don’t
match what systemd documents a system state to be.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410211105540.10...@tglase.lan.tarent.de

Re: LSB headers and other junk, how do you hack a quick init script in debian these days?

[Marc Haber]

On Tue, 21 Oct 2014 09:28:07 +0200, Josselin Mouette 
wrote:
>Michael Ole Olsen  wrote: 
>   How do you hack a quick init script these days?:)
>
>I write a systemd unit file. It’s smaller, faster to write, easier to
>understand and works more reliably. 

And it is also a bug to not have an init script since we still have
ports that do not use systemd.

People are working hard on eliminating those (non-systemd ports, not
bugs).

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xgvdi-xv...@swivel.zugschlus.de

Re: LSB headers and other junk, how do you hack a quick init script in debian these days?

[Ralf Jung]

Hi,

>> I write a systemd unit file. It’s smaller, faster to write, easier to
>> understand and works more reliably. 
> 
> And it is also a bug to not have an init script since we still have
> ports that do not use systemd.

And this is also completely irrelevant as the question was about quickly
hacking something together for local use.
If it were about a package, then he would have to put stuff into
/etc/init.d anyway, and add LSB headers, etc. In other words, it would
work with systemd without him changing his habits.

Of course, Michael, you can also always choose not to use systemd,
should you wish to do so. It's not like that is complicated:
$ aptitude install systemd-sysv- sysvinit-core systemd-shim

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5446bb68.2030...@ralfj.de

Re: LSB init scripts (was: should an init-script print output, if verbose is set to no in /etc/default/rcS or by /lib/init/vars.sh?)

[Lennart Sorensen]

On Thu, May 03, 2007 at 10:08:20PM +0200, Marc Haber wrote:
> This is also a "sales" issue. I have seen to many faces darken when
> people see a Debian system boot for the first time. People get
> reminded of the old DOS days and decide that this Linux thing is too
> ugly to use.

So knowledge is ugly?  It is obviously so much better to not know what
is going on so that if it doesn't work you don't have to worry about it
because you know nothing that could help you to solve it so it isn't
your problem of course.

Now being able to just turn on the details when something is wrong, and
have them no there the rest of the time might be OK.  On the other hand
you boot once every few months so who cares what the boot messages look
like. :)

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]