Hi,
Thorsten Glaser:
> tglase@tglase:~ $ cat x
> #?/usr/bin/python
> import sys
> print sys.version
> tglase@tglase:~ $ ls -l x
> -rwxr-xr-x 1 tglase tglase 47 Apr 4 12:54 x
> tglase@tglase:~ $ ./x
> import.im6: unable to grab mouse ': Resource temporarily unavailable @
> error/xwindow.c/XSelect
On Fri, Apr 04, 2014 at 02:04:32PM +0200, Salvo Tomaselli wrote:
> > > Sure. I’ve patched mksh
> >
> > mksh doesn't count as a reference.
> Did you even read before replying? He patched it to use #? Instead of #! that
> was using.
> He was sure about it being there because he had patched it to b
In data venerdì 04 aprile 2014 17.38.12, Andrey Rahmatullin ha scritto:
> > Sure. I’ve patched mksh
>
> mksh doesn't count as a reference.
Did you even read before replying? He patched it to use #? Instead of #! that
was using.
He was sure about it being there because he had patched it to behave
* Thorsten Glaser , 2014-04-04, 12:58:
Try duckduckgoïng instead ☻ or searching POSIX, or something.
SUSv4 “helpfully” says:
If the first line of a file of shell commands starts with the characters
"#!", the results are unspecified.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-r
Hi,
Thorsten Glaser writes:
> On Fri, 4 Apr 2014, Chow Loong Jin wrote:
>
>> Are you sure about this?
>
> Yes.
>
>> Some references would be helpful. I can't seem to find anything on this
>> through
>
> Sure. I’ve patched mksh to use “#?” ipv “#!” as shebang, to
> simulate a kernel not supportin
On Fri, Apr 04, 2014 at 12:58:23PM +0200, Thorsten Glaser wrote:
> > Are you sure about this?
>
> Yes.
>
> > Some references would be helpful. I can't seem to find anything on this
> > through
>
> Sure. I’ve patched mksh
mksh doesn't count as a reference.
> > some cursory googling.
> Try duck
On Fri, 4 Apr 2014, Chow Loong Jin wrote:
> Are you sure about this?
Yes.
> Some references would be helpful. I can't seem to find anything on this
> through
Sure. I’ve patched mksh to use “#?” ipv “#!” as shebang, to
simulate a kernel not supporting the shebang:
Index: exec.c
===
In other news for Fri, Apr 04, 2014 at 05:24:50PM +0800, Chow Loong Jin has
been seen typing:
> On Fri, Apr 04, 2014 at 08:27:01AM +, Thorsten Glaser wrote:
> > Chow Loong Jin debian.org> writes:
> > Yes, and /bin/sh is supposed to parse the shebang and call out to
> > the interpreter. AFAIC
Chow Loong Jin wrote...
> Some references would be helpful. I can't seem to find anything on this
> through
> some cursory googling.
Perl scripts, when installed by ExtUtils::MakeMaker or similar, do
have
| eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
| if 0; # not running under some shell
i
On Fri, Apr 04, 2014 at 08:27:01AM +, Thorsten Glaser wrote:
> > For the record, there's CONFIG_BINFMT_SCRIPT, which when disabled, causes
> all
> > #! scripts to be run under /bin/sh unconditionally.
> >
> > *everything* runs under /bin/sh, including Perl, Python, and Bash scripts.
>
> Yes,
On Fri, Apr 04, 2014 at 08:27:01AM +, Thorsten Glaser wrote:
> Chow Loong Jin debian.org> writes:
>
> > For the record, there's CONFIG_BINFMT_SCRIPT, which when disabled, causes
> all
> > #! scripts to be run under /bin/sh unconditionally.
> >
> > *everything* runs under /bin/sh, including P
Chow Loong Jin debian.org> writes:
> For the record, there's CONFIG_BINFMT_SCRIPT, which when disabled, causes
all
> #! scripts to be run under /bin/sh unconditionally.
>
> *everything* runs under /bin/sh, including Perl, Python, and Bash scripts.
Yes, and /bin/sh is supposed to parse the sheba
On Thu, Apr 03, 2014 at 11:58:17AM +0200, Tollef Fog Heen wrote:
> [...]
> Am I understanding you correctly that you don't think there are any
> situations where compiling out features from the kernel can lead to pid1
> not working would be acceptable?
For the record, there's CONFIG_BINFMT_SCRIPT,
previously on this list Steve Langasek contributed:
> The avalanche has already started; it is too late for the pebbles to vote.
Winston Churchill said "It is never too late" a few times and I think
some of his quotes are quite fitting.
"A lie gets halfway around the world before the truth has a
previously on this list Matthias Urlichs contributed:
> > I don't believe I have said that. «die» is not the same as «crash».
>
> If you're talking about PID1, the end result is the same.
It is not because one is a foreseen issue and the other indicates a
lack of polish on PID1!
--
On Thu, Apr 03, 2014 at 06:23:36PM +0200, Marc Haber wrote:
> >> I'd say the opposite way. Could you please explain in which case you
> >> find it acceptable to *just crash*, and render the system completely
> >> unusable, and possibly even not recoverable?
> >
> >1. If the kernel is configured wit
On Thu, Apr 03, 2014 at 10:26:22AM +0100, Neil McGovern wrote:
> On Thu, Apr 03, 2014 at 11:12:12AM +0900, Norbert Preining wrote:
> > Is this the upstream Debian wants to base its "life" on?
> According to the technical committee, and the lack of support for the
> GR, the answer is yes.
The GR t
On Thu, 03 Apr 2014 16:39:29 +0100, Ben Hutchings
wrote:
>On Thu, 2014-04-03 at 19:55 +0800, Thomas Goirand wrote:
>> On 04/03/2014 05:58 PM, Tollef Fog Heen wrote:
>> > Am I understanding you correctly that you don't think there are any
>> > situations where compiling out features from the kernel
On Thu, 2014-04-03 at 19:55 +0800, Thomas Goirand wrote:
> On 04/03/2014 05:58 PM, Tollef Fog Heen wrote:
> > Am I understanding you correctly that you don't think there are any
> > situations where compiling out features from the kernel can lead to pid1
> > not working would be acceptable?
>
> I'
Hi,
Tollef Fog Heen:
> I don't believe I have said that. «die» is not the same as «crash».
If you're talking about PID1, the end result is the same.
--
-- Matthias Urlichs
signature.asc
Description: Digital signature
]] Thomas Goirand
> On 04/03/2014 05:58 PM, Tollef Fog Heen wrote:
> > Am I understanding you correctly that you don't think there are any
> > situations where compiling out features from the kernel can lead to pid1
> > not working would be acceptable?
>
> I'd say the opposite way. Could you ple
]] Bjørn Mork
> Tollef Fog Heen writes:
> > ]] Norbert Preining
> >
> >> > systemd needs cgroups, that's pretty well established. Arguably, it
> >> > should die with a clearer message.
> >>
> >> No, NO NOO
> >>
> >> *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest th
On 04/03/2014 05:58 PM, Tollef Fog Heen wrote:
> Am I understanding you correctly that you don't think there are any
> situations where compiling out features from the kernel can lead to pid1
> not working would be acceptable?
I'd say the opposite way. Could you please explain in which case you
fi
Tollef Fog Heen writes:
> ]] Norbert Preining
>
>> > systemd needs cgroups, that's pretty well established. Arguably, it
>> > should die with a clearer message.
>>
>> No, NO NOO
>>
>> *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that.
>
> Am I understanding you cor
On Thu, Apr 03, 2014 at 06:33:42PM +0900, Norbert Preining wrote:
> Hi Tollef,
>
> On Thu, 03 Apr 2014, Tollef Fog Heen wrote:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=76935
> >
> > That's being moved to systemd.debug instead of overloading debug.
>
> Good news. And please make Kay e
Hi Norbert et al.,
> * systemd maintainers (Lennart Poettering) does not care for
> segfaults in his code, even if it happens in pid 1.
> https://bugs.freedesktop.org/show_bug.cgi?id=74589
to me his response does not read as if he didn't care. Systemd on
systems without cgroups has never
]] Norbert Preining
> Hi Tollef,
>
> On Thu, 03 Apr 2014, Tollef Fog Heen wrote:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=76935
> >
> > That's being moved to systemd.debug instead of overloading debug.
>
> Good news. And please make Kay excuse for his rudeness and ifgnorance.
Why
Hi,
On Thu, Apr 03, 2014 at 10:41:45AM +0200, Matthias Urlichs wrote:
> Norbert Preining:
> > * several kernel maintainer propose (not completely serious, but
> > it shows the general opinion), to add
> > + BUG_ON(!strcmp(current->comm, "systemd"));
>
> URLs please.
IIRC that's from
Hi,
On Thu, Apr 03, 2014 at 05:41:21AM -0007, Cameron Norman wrote:
> This really is not something suitable for debian-devel, unless you
> are actually proposing a GR to re-choose the init system, which you
> do not seem to be doing.
GRs are also off-topic on -devel.
Michael
--
To UNSUBSCRIB
On Thu, Apr 03, 2014 at 10:41:45AM +0200, Matthias Urlichs wrote:
> Hi,
> [...]
> > * several kernel maintainer propose (not completely serious, but
> > it shows the general opinion), to add
> > + BUG_ON(!strcmp(current->comm, "systemd"));
>
> URLs please.
http://marc.info/?l=linux-ke
Hi,
On Thu, 03 Apr 2014, Matthias Urlichs wrote:
> > https://bugs.freedesktop.org/show_bug.cgi?id=76935
> >
> It's not "an obvious bug", it's primarily an issue of interpreting whether
> a generic boot parameter like "debug" is intended for just the kernel, or
> the whole system.
>
> Linux h
Hi Tollef,
On Thu, 03 Apr 2014, Tollef Fog Heen wrote:
> > https://bugs.freedesktop.org/show_bug.cgi?id=76935
>
> That's being moved to systemd.debug instead of overloading debug.
Good news. And please make Kay excuse for his rudeness and ifgnorance.
Thanks for letting us know.
But why is th
On Thu, Apr 03, 2014 at 11:12:12AM +0900, Norbert Preining wrote:
> Is this the upstream Debian wants to base its "life" on?
>
According to the technical committee, and the lack of support for the
GR, the answer is yes.
If you don't like this answer, please put effort into doing the work to
prov
]] Norbert Preining
> Hi
>
> recent discussions on lkml really made me rethink the systemd
> position.
>
> How is it possible that:
> * systemd maintainers (Kay Sievers) considers an obvious bug in
> his code that locks out users something not in need to be cared
> for?
> https://bugs
Hi,
Norbert Preining:
> How is it possible that:
> * systemd maintainers (Kay Sievers) considers an obvious bug in
> his code that locks out users something not in need to be cared
> for?
> https://bugs.freedesktop.org/show_bug.cgi?id=76935
>
It's not "an obvious bug", it's primarily an
El Wed, 2 de Apr 2014 a las 7:12 PM, Norbert Preining
escribió:
Hi
recent discussions on lkml really made me rethink the systemd
position.
How is it possible that:
* systemd maintainers (Kay Sievers) considers an obvious bug in
his code that locks out users something not in need to be cared
36 matches
Mail list logo
