xterm: either fix it, or remove it. please.

xterm: either fix it, or remove it. please.

[Robert P. J. Day]

  seriously, either the build of xterm_207 should be fixed, or that
package should be dropped in its entirety.  it's been at least three
weeks since i pointed out that it doesn't build, and even explained in
detail *why* it doesn't build and how to fix it.  to no avail.

  so, a humble suggestion -- either fix it, or remove it from OE
entirely.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Holger Hans Peter Freyther]

On Thursday 12 November 2009 06:47:22 Robert P. J. Day wrote:
>   seriously, either the build of xterm_207 should be fixed, or that
> package should be dropped in its entirety.  it's been at least three
> weeks since i pointed out that it doesn't build, and even explained in
> detail *why* it doesn't build and how to fix it.  to no avail.
> 
>   so, a humble suggestion -- either fix it, or remove it from OE
> entirely.

Did you attempt to create a patch?

Re: xterm: either fix it, or remove it. please.

[Robert P. J. Day]

On Thu, 12 Nov 2009, Holger Hans Peter Freyther wrote:

> On Thursday 12 November 2009 06:47:22 Robert P. J. Day wrote:
> >   seriously, either the build of xterm_207 should be fixed, or
> > that package should be dropped in its entirety.  it's been at
> > least three weeks since i pointed out that it doesn't build, and
> > even explained in detail *why* it doesn't build and how to fix it.
> > to no avail.
> >
> >   so, a humble suggestion -- either fix it, or remove it from OE
> > entirely.
>
> Did you attempt to create a patch?

  no, but i explained in precise detail (down to the exact line) what
the problem was, and *one* possible way it could be fixed, but given
that there was more than one possible fix, i left it with the list to
decide how to resolve it.

  and before someone lays the blame back at my feet, it was koen who
posted that, when bugs are identified and posted to the list, they are
typically fixed within a day.  it's been about three weeks now, and
the breakage remains.

  so, once again, seriously, either fix it or officially obsolete that
package and remove it from any builds that currently include it.
either way would work just fine.

rday

p.s.  do you want me to, once again, explain what the problem is and a
couple possible solutions?

--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Holger Hans Peter Freyther]

On Thursday 12 November 2009 06:56:41 Holger Hans Peter Freyther wrote:
> On Thursday 12 November 2009 06:47:22 Robert P. J. Day wrote:
> >   seriously, either the build of xterm_207 should be fixed, or that
> > package should be dropped in its entirety.  it's been at least three
> > weeks since i pointed out that it doesn't build, and even explained in
> > detail *why* it doesn't build and how to fix it.  to no avail.
> >
> >   so, a humble suggestion -- either fix it, or remove it from OE
> > entirely.
> 
> Did you attempt to create a patch?

and on top of that it...it builds here... creates a ipk with the xterm binary 
in it. So I don't see the need to remove the recipe.

z.

Re: xterm: either fix it, or remove it. please.

[Robert P. J. Day]

On Thu, 12 Nov 2009, Holger Hans Peter Freyther wrote:

> On Thursday 12 November 2009 06:56:41 Holger Hans Peter Freyther wrote:
> > On Thursday 12 November 2009 06:47:22 Robert P. J. Day wrote:
> > >   seriously, either the build of xterm_207 should be fixed, or that
> > > package should be dropped in its entirety.  it's been at least three
> > > weeks since i pointed out that it doesn't build, and even explained in
> > > detail *why* it doesn't build and how to fix it.  to no avail.
> > >
> > >   so, a humble suggestion -- either fix it, or remove it from OE
> > > entirely.
> >
> > Did you attempt to create a patch?
>
> and on top of that it...it builds here... creates a ipk with the
> xterm binary in it. So I don't see the need to remove the recipe.

  philip balister confirmed some time back that he's reproduced the
error, but i'll be happy to explain one more time what the problem is.

  in the work directory for xterm_207, you can find the install script
sinstall.sh, which contains the snippet:

  case ".$cf_mode" in #(vi
        .???s??s*) #(vi
                PROG_SUID=4000
                PROG_SGID=2000
                ;;
        .???s*) #(vi
                PROG_SUID=4000
                PROG_GRP=
                ;;
        .??????s*)
                PROG_SGID=2000
                PROG_USR=
                ;;
        esac
        PROG_MODE=`echo ".$cf_mode" | sed -e 's/^..//' -e 's/rw./7/g' -e 's/r-./5/g' -e 's/--[sxt]/1/g'`

the above is switching on a symbolic mode, and that final line is
using sed to convert the symbolic mode to the corresponding numeric
mode for installation.

  that worked fine a few years back, but it fails on newer linux
distros for which the long listing might have a trailing period, as
does my fedora 11 system:

$ ls -l /etc/passwd
-rw-r--r--. 1 root root 2474 2009-11-09 14:59 /etc/passwd
          ^ there

  that collection of sed operations doesn't take that into account,
and ends up converting a symbolic mode to something like "755.",
*also* with a trailing period, which causes the eventual install
operation to fail thusly (from the log file):

checking for presumed installation-mode
... if "/usr/bin/xterm" is null, try the ls -g option
... if "/usr/bin/xterm" is null, we do not look for group
... if we have date in proper columns (Sep 29 05:41), "" is null
... derived user "root", group "root" of previously-installed xterm
... see if mode "-rwxr-xr-x." has s-bit set
... installing xterm as user "rpjday", group "rpjday"
/usr/bin/install -c -m 755.   xterm
/home/rpjday/oe/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/xterm-207-r0/image/usr/bin/xterm
/usr/bin/install: invalid mode `755.'
make: *** [install] Error 1
FATAL: oe_runmake failed

  notice how the install command is complaining about an invalid mode
of "755.", as well it should.  a simple (albeit hacky) fix is to
simply add the line

  PROG_MODE=${PROG_MODE%\.}

to whack off a possible trailing period after that last line above.
i've verified that this in fact works.  perhaps a cleaner option is to
delete that trailing period from $cf_mode right up front.  either way
would work fine, but it's clear that the period needs to go.  why
*your* build works is a mystery, unless you're doing this on a system
that somehow doesn't display that period with a long listing, or
something like that.

  anyway, this is about the fourth time i've explained this, either
here or on the angstrom-devel list.  that's the error, and it's
entirely reproducible on my f11 system.  at this point, i'm leaving it
with the powers that be, and you're free to deal with it or totally
ignore it.  whatever suits you.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Holger Hans Peter Freyther]

On Thursday 12 November 2009 07:36:32 Robert P. J. Day wrote:


>   anyway, this is about the fourth time i've explained this, either
> here or on the angstrom-devel list.  that's the error, and it's
> entirely reproducible on my f11 system.  at this point, i'm leaving it
> with the powers that be, and you're free to deal with it or totally
> ignore it.  whatever suits you.

Robert,

I totally agree that bugs should be fixed. Your attitude is somehow weird as 
you demand others to fix problems you are experiencing. Honestly speaking I am 
a bit disturbed by this attitude. Work on OE is purely community driven, if 
something reported is not picked up, it is saddening, but you really can't 
play the escalation game from the commercial world.

Did you consider updating xterm from 207 to something more recent, or did you 
consider taking a newer install script and patch it into 207? Apparently 
between 207 and 243 (as of ubuntu) there must have been changes.

z.

Re: xterm: either fix it, or remove it. please.

[Holger Hans Peter Freyther]

On Thursday 12 November 2009 08:20:08 Holger Hans Peter Freyther wrote:
> On Thursday 12 November 2009 07:36:32 Robert P. J. Day wrote:
> >   anyway, this is about the fourth time i've explained this, either
> > here or on the angstrom-devel list.  that's the error, and it's
> > entirely reproducible on my f11 system.  at this point, i'm leaving it
> > with the powers that be, and you're free to deal with it or totally
> > ignore it.  whatever suits you.
> 
> Robert,
> 
> I totally agree that bugs should be fixed. Your attitude is somehow weird
>  as you demand others to fix problems you are experiencing. Honestly
>  speaking I am a bit disturbed by this attitude. Work on OE is purely
>  community driven, if something reported is not picked up, it is saddening,
>  but you really can't play the escalation game from the commercial world.
> 
> Did you consider updating xterm from 207 to something more recent, or did
>  you consider taking a newer install script and patch it into 207?
>  Apparently between 207 and 243 (as of ubuntu) there must have been
>  changes.

And diffing sinstall.sh from 207 to 243 one is seeing some interesting
changes... the first is to set the locale to C (good change) and the second
is in changing PROGRAM_MODE.. Maybe you want to test this and then
come up with a patch? I'm happy to review and land it.

z.


-       PROG_MODE=`echo ".$cf_mode" | sed -e 's/^..//' -e 's/rw./7/g' -e 's/r-./5/g' -e 's/--[sxt]/1/g'`
+       PROG_MODE=`echo ".$cf_mode" | sed -e 's/^..//' -e 's/rw./7/g' -e 's/r-./5/g' -e 's/---/0/g' -e 's/--[sxt]/1/g' -e 's/+//g'`

Re: xterm: either fix it, or remove it. please.

[Robert P. J. Day]

On Thu, 12 Nov 2009, Holger Hans Peter Freyther wrote:

> On Thursday 12 November 2009 07:36:32 Robert P. J. Day wrote:
>
> >   anyway, this is about the fourth time i've explained this,
> > either here or on the angstrom-devel list.  that's the error, and
> > it's entirely reproducible on my f11 system.  at this point, i'm
> > leaving it with the powers that be, and you're free to deal with
> > it or totally ignore it.  whatever suits you.
>
> Robert,
>
> I totally agree that bugs should be fixed. Your attitude is somehow
> weird as you demand others to fix problems you are experiencing.
> Honestly speaking I am a bit disturbed by this attitude.

  at this point, i don't much care.  recently, i've been investing
some time in OE, doing some builds and reporting bugs when i've found
them so, yes, i am *also* part of that community of which you speak.
i even promoted OE for the beagleboard when i gave a talk recently at
ontario linux fest:

  http://onlinux.ca/node/78

  when i first ran across that xterm bug, i reported it.  nothing
happened.  i waited, and mentioned it again.  eventually, philip
balister admitted that he'd reproduced it.  good, i thought, someone
else has seen it so it should be fixed eventually.

  nothing.  so i mentioned it *again*, but only after doing some
research, to the point where i tracked down the *cause* of the bug,
posted a detailed explanation of that cause, and even mentioned that
i'd verified that a proposed fix solved the problem.

  nothing.  at this point, i've quite given up on investing any more
time trying to help out.

> Work on OE is purely community driven, ...

  i'm well aware of that.  i was trying to become a productive
*member* of that community.  at this point, i've pretty much lost
interest.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Frans Meulenbroeks]

2009/11/12 Robert P. J. Day <rpjday@crashcourse.ca>:

> the above is switching on a symbolic mode, and that final line is
> using sed to convert the symbolic mode to the corresponding numeric
> mode for installation.
>
>  that worked fine a few years back, but it fails on newer linux
> distros for which the long listing might have a trailing period, as
> does my fedora 11 system:
>
> $ ls -l /etc/passwd
> -rw-r--r--. 1 root root 2474 2009-11-09 14:59 /etc/passwd
>          ^ there

Hm. I've never ever heard about this trailing period. Where does it
come from/how was it introduced?

IEEE Std 1003.1, 2004 Edition does not specify the trailing dot
(http://www.opengroup.org/onlinepubs/000095399/utilities/ls.html )

My OpenSuse 11.2 system also gives no period and as far as I know
neither busybox nor the gnu coreutlis ls gives this period.

Personally I'm inclined to say that fedora's ls is broken.
Adding a dot after the mode bits seems meaningless for me and will
break more than one shell script.

But of course anyone feel free to enlighten me where this dot comes
from or what the use of it is.

@Robert: do you have any info where your fedora ls comes from? Is this
a shell builtin (and if so which shell), is it a busybox ls, a gnu
coreutils ls, something else?
what does
which ls
say ?

(btw sometimes /bin/ls and /usr/bin/ls and ls produce different results).

(and yeah trivial patches mailed to the list seem to be applied fairly
quickly, if more work is involved the chance decreases that someone
picks it up, especially when things seemingly work for them).

Frans

Re: xterm: either fix it, or remove it. please.

[Graeme Gregory]

On Thu, Nov 12, 2009 at 08:20:08AM +0100, Holger Hans Peter Freyther wrote:
> On Thursday 12 November 2009 07:36:32 Robert P. J. Day wrote:
> 
> 
> >   anyway, this is about the fourth time i've explained this, either
> > here or on the angstrom-devel list.  that's the error, and it's
> > entirely reproducible on my f11 system.  at this point, i'm leaving it
> > with the powers that be, and you're free to deal with it or totally
> > ignore it.  whatever suits you.
> 
> Robert,
> 
> I totally agree that bugs should be fixed. Your attitude is somehow weird as 
> you demand others to fix problems you are experiencing. Honestly speaking I am 
> a bit disturbed by this attitude. Work on OE is purely community driven, if 
> something reported is not picked up, it is saddening, but you really can't 
> play the escalation game from the commercial world.
> 
I agree with Holger here, we are not you contractors/slaves. I can fix it
for you but it will costs $$$ I can give you the email address of my
manager who will negotiate a fee.

Or you could get with the rest of the open source community and start
to understand that whining is not a construction addition to the community.

It would take you maybe 2 minutes to make a patch. Why be so damn difficult?

And I also see no problem here.

Graeme

Re: xterm: either fix it, or remove it. please.

[Michael 'Mickey' Lauer]

> > Work on OE is purely community driven, ...
> 
>   i'm well aware of that.  i was trying to become a productive
> *member* of that community.  at this point, i've pretty much lost
> interest.

That would be sad. Please don't let yourself be driven a way buy a
single incident. I appreciate you looking into things. Surely we will
find a way to fix this little recipe...

Cheers,

:M:

Re: xterm: either fix it, or remove it. please.

[Philip Balister]

On 11/12/2009 12:47 AM, Robert P. J. Day wrote:
>
>    seriously, either the build of xterm_207 should be fixed, or that
> package should be dropped in its entirety.  it's been at least three
> weeks since i pointed out that it doesn't build, and even explained in
> detail *why* it doesn't build and how to fix it.  to no avail.
>
>    so, a humble suggestion -- either fix it, or remove it from OE
> entirely.

Current status, dev changes aren't building at all for me and now the 
machine I work decided to hang in grub. Yah, this recipe is cursed.

You could remove it locally for your build.

Philip


>
> rday
> --
>
> ========================================================================
> Robert P. J. Day                               Waterloo, Ontario, CANADA
>
>              Linux Consulting, Training and Kernel Pedantry.
>
> Web page:                                          http://crashcourse.ca
> Twitter:                                       http://twitter.com/rpjday
> ========================================================================
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: xterm: either fix it, or remove it. please.

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1279 bytes --]

On Thu, 12 Nov 2009, Frans Meulenbroeks wrote:

> 2009/11/12 Robert P. J. Day <rpjday@crashcourse.ca>:
>
> > the above is switching on a symbolic mode, and that final line is
> > using sed to convert the symbolic mode to the corresponding numeric
> > mode for installation.
> >
> >  that worked fine a few years back, but it fails on newer linux
> > distros for which the long listing might have a trailing period, as
> > does my fedora 11 system:
> >
> > $ ls -l /etc/passwd
> > -rw-r--r--. 1 root root 2474 2009-11-09 14:59 /etc/passwd
> >          ^ there
>
> Hm. I've never ever heard about this trailing period. Where does it
> come from/how was it introduced?

https://fedoraproject.org/wiki/Fedora_11_FAQ#Why_does_ls_show_a_dot_.28..29_or_a_plus_.28.2B.29_at_the_end_on_the_file_modes_for_some_files.3F

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Frans Meulenbroeks]

2009/11/12 Robert P. J. Day <rpjday@crashcourse.ca>:
> On Thu, 12 Nov 2009, Frans Meulenbroeks wrote:
>
>> 2009/11/12 Robert P. J. Day <rpjday@crashcourse.ca>:
>>
>> > the above is switching on a symbolic mode, and that final line is
>> > using sed to convert the symbolic mode to the corresponding numeric
>> > mode for installation.
>> >
>> >  that worked fine a few years back, but it fails on newer linux
>> > distros for which the long listing might have a trailing period, as
>> > does my fedora 11 system:
>> >
>> > $ ls -l /etc/passwd
>> > -rw-r--r--. 1 root root 2474 2009-11-09 14:59 /etc/passwd
>> >          ^ there
>>
>> Hm. I've never ever heard about this trailing period. Where does it
>> come from/how was it introduced?
>
> https://fedoraproject.org/wiki/Fedora_11_FAQ#Why_does_ls_show_a_dot_.28..29_or_a_plus_.28.2B.29_at_the_end_on_the_file_modes_for_some_files.3F
>
> rday
> --

Robert thanks for the link.
Didn't know that. Apparently one is never too old to learn something new.

So it is not really fedora specific, but it is SELinux specific.
Do we want to support SELinux as build host ?
(the ideal solution of course would be to have our own ls in the cross dir).

Frans.

PS: Personally I think it is a bad idea to change the output format of
a utility that is more than 30 years old and that is so widespread.
(and I did not even see an obvious way to get the old behaviour).

Re: xterm: either fix it, or remove it. please.

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2935 bytes --]

On Thu, 12 Nov 2009, Frans Meulenbroeks wrote:

> 2009/11/12 Robert P. J. Day <rpjday@crashcourse.ca>:
> > On Thu, 12 Nov 2009, Frans Meulenbroeks wrote:
> >
> >> 2009/11/12 Robert P. J. Day <rpjday@crashcourse.ca>:
> >>
> >> > the above is switching on a symbolic mode, and that final line is
> >> > using sed to convert the symbolic mode to the corresponding numeric
> >> > mode for installation.
> >> >
> >> >  that worked fine a few years back, but it fails on newer linux
> >> > distros for which the long listing might have a trailing period, as
> >> > does my fedora 11 system:
> >> >
> >> > $ ls -l /etc/passwd
> >> > -rw-r--r--. 1 root root 2474 2009-11-09 14:59 /etc/passwd
> >> >          ^ there
> >>
> >> Hm. I've never ever heard about this trailing period. Where does it
> >> come from/how was it introduced?
> >
> > https://fedoraproject.org/wiki/Fedora_11_FAQ#Why_does_ls_show_a_dot_.28..29_or_a_plus_.28.2B.29_at_the_end_on_the_file_modes_for_some_files.3F
> >
> > rday
> > --
>
> Robert thanks for the link. Didn't know that. Apparently one is
> never too old to learn something new.

  i was a bit puzzled the first time i saw that, and had to ask around
about what it meant.

> So it is not really fedora specific, but it is SELinux specific. Do
> we want to support SELinux as build host ? (the ideal solution of
> course would be to have our own ls in the cross dir).
>
> Frans.
>
> PS: Personally I think it is a bad idea to change the output format of
> a utility that is more than 30 years old and that is so widespread.

  i have to agree but, frankly, i'm astonished that that fundamental a
change caused breakage in only one package out of about 10,000 (i
tripped across that building beagleboard-demo-image -- it was the only
package that failed because of that; i actually think that shows an
amazing level of robustness).

> (and I did not even see an obvious way to get the old behaviour).

  i'm checking right now if there's an option to "ls" to turn *off*
that feature, but i don't see one offhand.  perhaps a better lesson is
that the way xterm's sinstall.sh script works is really hacky, using
sed to allegedly reproduce a file's existing mode settings.  perhaps
there's a simpler way to get that effect without dragging "sed" into
it.  but, again, if only one package was affected, maybe just hack up
an xterm fix and move on, and deal with things on a case-by-case
basis as they come up.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Graeme Gregory]

On Thu, Nov 12, 2009 at 07:58:23AM -0500, Robert P. J. Day wrote:
> > PS: Personally I think it is a bad idea to change the output format of
> > a utility that is more than 30 years old and that is so widespread.
> 
>   i have to agree but, frankly, i'm astonished that that fundamental a
> change caused breakage in only one package out of about 10,000 (i
> tripped across that building beagleboard-demo-image -- it was the only
> package that failed because of that; i actually think that shows an
> amazing level of robustness).
> 
And it doesnt make it fail here, selinux enabled, can see the extra .
in my normal ls commands. xterm still builds fine.

G

Re: xterm: either fix it, or remove it. please.

[Holger Hans Peter Freyther]

On Thursday 12 November 2009 13:58:23 Robert P. J. Day wrote:

>   i'm checking right now if there's an option to "ls" to turn *off*
> that feature, but i don't see one offhand.  perhaps a better lesson is
> that the way xterm's sinstall.sh script works is really hacky, using
> sed to allegedly reproduce a file's existing mode settings.  perhaps
> there's a simpler way to get that effect without dragging "sed" into
> it.  but, again, if only one package was affected, maybe just hack up
> an xterm fix and move on, and deal with things on a case-by-case
> basis as they come up.

Could you please try this patch to the sinstall.sh?

http://paste.lisp.org/display/90216

Re: xterm: either fix it, or remove it. please.

[Robert P. J. Day]

On Thu, 12 Nov 2009, Frans Meulenbroeks wrote:

> PS: Personally I think it is a bad idea to change the output format
> of a utility that is more than 30 years old and that is so
> widespread. (and I did not even see an obvious way to get the old
> behaviour).

  someone on the fedora list just suggested the following if all you
want is the numeric mode of a file:

$ stat -c %a /etc/passwd
644
$

  i'm fairly sure that's safe for the rare occasion when you need that
information.  but, as i suggested, given that this only caused a
problem with a single package, it's probably not worth obsessing over
unless that breakage begins to occur more often.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Robert P. J. Day]

On Thu, 12 Nov 2009, Graeme Gregory wrote:

> On Thu, Nov 12, 2009 at 07:58:23AM -0500, Robert P. J. Day wrote:
> > > PS: Personally I think it is a bad idea to change the output format of
> > > a utility that is more than 30 years old and that is so widespread.
> >
> >   i have to agree but, frankly, i'm astonished that that
> > fundamental a change caused breakage in only one package out of
> > about 10,000 (i tripped across that building
> > beagleboard-demo-image -- it was the only package that failed
> > because of that; i actually think that shows an amazing level of
> > robustness).
> >
> And it doesnt make it fail here, selinux enabled, can see the extra
> . in my normal ls commands. xterm still builds fine.

  ok, that's just odd since i was sure it was that trailing period
that was causing all the trouble.  and adding a single line to the
sinstall.sh script to strip it fixed the problem.  how curious.

  in any event, i think it's safe to say that that sinstall.sh script
was a bit of a hack.  if one wanted to dup some file perms onto a new
file, it would have been way easier to just:

  $ chmod --reference=oldfile newfile

or something like that.  running the symbolic mode through multiple
sed's to get the numeric mode is the definition of massive overkill.

  and i'll try that posted patch shortly, i suspect it will work just
fine.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Mike Westerhof]

Frans Meulenbroeks wrote:

> So it is not really fedora specific, but it is SELinux specific.
> Do we want to support SELinux as build host ?

Do we want to?  Yes, it would be a nice thing to support.

Is it practical?  I think the answer is no.  In my experience, tools
like selinux have a tendency to require inordinate amounts of
administrative burden that just isn't practical in a development
environment.  I think requiring that selinux be disabled on build hosts
is a reasonable requirement, and will avoid wasting a lot of cycles that
should be spent on OE, and not on administration (or sending lots of
emails).

-Mike (mwester)

Re: xterm: either fix it, or remove it. please.

[GNUtoo]

> Is it practical?  I think the answer is no.  In my experience, tools
> like selinux have a tendency to require inordinate amounts of
> administrative burden that just isn't practical in a development
> environment.  I think requiring that selinux be disabled on build
> hosts
> is a reasonable requirement, and will avoid wasting a lot of cycles
> that
> should be spent on OE, and not on administration (or sending lots of
> emails).
What about supporting only the unconfined user selinux
type(unconfined_u),in targeted mode?
Denis.

Re: xterm: either fix it, or remove it. please.

[Philip Balister]

On 11/12/2009 04:42 PM, GNUtoo wrote:
>> Is it practical?  I think the answer is no.  In my experience, tools
>> like selinux have a tendency to require inordinate amounts of
>> administrative burden that just isn't practical in a development
>> environment.  I think requiring that selinux be disabled on build
>> hosts
>> is a reasonable requirement, and will avoid wasting a lot of cycles
>> that
>> should be spent on OE, and not on administration (or sending lots of
>> emails).
> What about supporting only the unconfined user selinux
> type(unconfined_u),in targeted mode?

I'm running default Selinux on F11, I don't think we can just say OE 
must have SELinux turned off.

Philip


> Denis.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: xterm: either fix it, or remove it. please.

[Graeme Gregory]

On Thu, Nov 12, 2009 at 04:59:41PM -0500, Philip Balister wrote:
> On 11/12/2009 04:42 PM, GNUtoo wrote:
> >>Is it practical?  I think the answer is no.  In my experience, tools
> >>like selinux have a tendency to require inordinate amounts of
> >>administrative burden that just isn't practical in a development
> >>environment.  I think requiring that selinux be disabled on build
> >>hosts
> >>is a reasonable requirement, and will avoid wasting a lot of cycles
> >>that
> >>should be spent on OE, and not on administration (or sending lots of
> >>emails).
> >What about supporting only the unconfined user selinux
> >type(unconfined_u),in targeted mode?
> 
> I'm running default Selinux on F11, I don't think we can just say OE
> must have SELinux turned off.
> 
And the SELinux problem doesnt seem to trip up my SELinux F11.

Graeme

Re: xterm: either fix it, or remove it. please.

[Robert P. J. Day]

On Thu, 12 Nov 2009, Philip Balister wrote:

> On 11/12/2009 04:42 PM, GNUtoo wrote:
> > > Is it practical?  I think the answer is no.  In my experience,
> > > tools like selinux have a tendency to require inordinate amounts
> > > of administrative burden that just isn't practical in a
> > > development environment.  I think requiring that selinux be
> > > disabled on build hosts is a reasonable requirement, and will
> > > avoid wasting a lot of cycles that should be spent on OE, and
> > > not on administration (or sending lots of emails).

> > What about supporting only the unconfined user selinux
> > type(unconfined_u),in targeted mode?
>
> I'm running default Selinux on F11, I don't think we can just say OE
> must have SELinux turned off.

  at the very least, selinux needs to be configured to allow
/proc/sys/vm/mmap_min_addr = 0.  here's the corresponding selinux
diagnostic you get because of that:

Summary:

SELinux is preventing
/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/bin/qemu-arm
"mmap_zero" access on <Unknown>.

Detailed Description:

[SELinux is in permissive mode. This access was not denied.]

SELinux denied access requested by qemu-arm. The current boolean
settings do not allow this access. If you have not setup qemu-arm to
require this access this may signal an intrusion attempt. If you do
intend this access you need to change the booleans on this system to
allow the access.

Allowing Access:

Confined processes can be configured to run requiring different
access, SELinux provides booleans to allow you to turn on/off access
as needed. The boolean mmap_low_allowed is set incorrectly. Boolean
Description: Allow certain domains to map low memory in the kernel

Fix Command:

# setsebool -P mmap_low_allowed 1

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Robert P. J. Day]

On Fri, 13 Nov 2009, Holger Hans Peter Freyther wrote:

> On Thursday 12 November 2009 13:58:23 Robert P. J. Day wrote:
>
> >   i'm checking right now if there's an option to "ls" to turn *off*
> > that feature, but i don't see one offhand.  perhaps a better lesson is
> > that the way xterm's sinstall.sh script works is really hacky, using
> > sed to allegedly reproduce a file's existing mode settings.  perhaps
> > there's a simpler way to get that effect without dragging "sed" into
> > it.  but, again, if only one package was affected, maybe just hack up
> > an xterm fix and move on, and deal with things on a case-by-case
> > basis as they come up.
>
> Hi Robert,
>
> Could you please try this patch to the sinstall.sh?
>
> http://paste.lisp.org/display/90216

  xterm was recently upgraded to version 251 so that patch no longer
applies.  give me a few minutes and i'll fix and test it.


rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Robert P. J. Day]

On Fri, 13 Nov 2009, Holger Hans Peter Freyther wrote:

> On Thursday 12 November 2009 13:58:23 Robert P. J. Day wrote:
>
> >   i'm checking right now if there's an option to "ls" to turn
> > *off* that feature, but i don't see one offhand.  perhaps a better
> > lesson is that the way xterm's sinstall.sh script works is really
> > hacky, using sed to allegedly reproduce a file's existing mode
> > settings.  perhaps there's a simpler way to get that effect
> > without dragging "sed" into it.  but, again, if only one package
> > was affected, maybe just hack up an xterm fix and move on, and
> > deal with things on a case-by-case basis as they come up.
>
> Hi Robert,
>
> Could you please try this patch to the sinstall.sh?
>
> http://paste.lisp.org/display/90216

  it looks like that patch was already applied, but that doesn't solve
the problem since the final numeric mode string still has that
trailing period that mucks things up.

  as a simple fix that i've used before, i just added this to
sinstall.sh, at line 131:

        PROG_MODE=`echo ".$cf_mode" | sed -e 's/^..//' -e 's/rw./7/g'
-e 's/r-./5/g' -e 's/---/0/g' -e 's/--[sxt]/1/g' -e 's/+//g'`
        $trace "final PROG_MODE = ${PROG_MODE}"  # prints "755."
        PROG_MODE=${PROG_MODE%\.}     <--  manually strip that period
        $trace "really final PROG_MODE = ${PROG_MODE}"  # prints "755"

and it works, i just tested that.  so i'm not sure what that extended
sed expression was supposed to accomplish but it did nothing to solve
this issue.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: xterm: either fix it, or remove it. please.

[Graeme Gregory]

On Fri, Nov 13, 2009 at 03:55:02AM -0500, Robert P. J. Day wrote:
> and it works, i just tested that.  so i'm not sure what that extended
> sed expression was supposed to accomplish but it did nothing to solve
> this issue.
> 

Panic over, the issue is nothing to do with F11, SELinux, sed or
any other crazyness. The simple problem is the install script
checks /usr/bin/X11/xterm.

I have pushed a fix after I debugged the problem and worked
out what was actually happening. The fix turns out to be
real simple.

Graeme