On Thu, 11 Jan 2001, Rafael E. Herrera wrote:
> I have a suggestion, there is a kernel patch to add a config.gz entry in
> the /proc fs. It reflects the configuration used in building the running
> kernel, which may differ from the one you have in /usr/src/linux. It's
> part of the suse
On Wed, 10 Jan 2001, Richard Torkar wrote:
> I do not have any PPP, and no kdb installed on that machine, neither do I
> have procinfo. Shouldn't it say N/A or not found instead of the above? The
> ppp part is not true ;-).
> Other thing I thought about was the Ctrl-D thingy when entering
On Wed, 10 Jan 2001, Richard Torkar wrote:
I do not have any PPP, and no kdb installed on that machine, neither do I
have procinfo. Shouldn't it say N/A or not found instead of the above? The
ppp part is not true ;-).
Other thing I thought about was the Ctrl-D thingy when entering text.
On Thu, 11 Jan 2001, Rafael E. Herrera wrote:
I have a suggestion, there is a kernel patch to add a config.gz entry in
the /proc fs. It reflects the configuration used in building the running
kernel, which may differ from the one you have in /usr/src/linux. It's
part of the suse
On Wed, 10 Jan 2001, Richard Torkar wrote:
> I do not have any PPP, and no kdb installed on that machine, neither do I
> have procinfo. Shouldn't it say N/A or not found instead of the above? The
> ppp part is not true ;-).
Sure. I forgot to convert some function calls... But I'll have to
Hi there.
I rewrote my previous bugreport.pl in bash. I would appreciate it if you
had a look on this one. Run it once and give me feedback if you like.
If the formatting is overloaded please let me know.
If this one is ok, I will probably add the possibility to check
the version
On Tue, 9 Jan 2001, Pavel Machek wrote:
> Hi!
>
> This is horrible bugreport. Kill "keywords". Putting "modules" into
> keywords i not going to help anyone. Having "4. Kernel version" and
> minuses before actuall version is not helpfull, either.
"modules" as keyword, keywords in general: This
On Tue, 9 Jan 2001, Pavel Machek wrote:
Hi!
This is horrible bugreport. Kill "keywords". Putting "modules" into
keywords i not going to help anyone. Having "4. Kernel version" and
minuses before actuall version is not helpfull, either.
"modules" as keyword, keywords in general: This is a
Hi there.
I rewrote my previous bugreport.pl in bash. I would appreciate it if you
had a look on this one. Run it once and give me feedback if you like.
If the formatting is overloaded please let me know.
If this one is ok, I will probably add the possibility to check
the version
On Wed, 10 Jan 2001, Richard Torkar wrote:
I do not have any PPP, and no kdb installed on that machine, neither do I
have procinfo. Shouldn't it say N/A or not found instead of the above? The
ppp part is not true ;-).
Sure. I forgot to convert some function calls... But I'll have to rewrite
Hi Chris,
Comparing the Changes document for 2.4.0 against the one from 2.3.11 one
can see that many requirements were removed. Nine out of 22 are still
there.
Have the removed ones been unnecessary or only less important than the
remaining ones?
Regards,
Matthias
-
To unsubscribe from this
On 7 Jan 2001, Ulrich Drepper wrote:
> Why don't you, as the other script suggested, execute libc.so.6?
> Symlinks can be missing or can be wrong.
I'll have a look at this shell script and take the best out of both to
make a new one.
BTW, lots of version dependencies found in older Changes
On Sun, 7 Jan 2001, David Ford wrote:
> > Why can't I assume that perl is installed? It can be found on every
> > standard Linux/Unix installation.
>
> No it can't. Perl isn't on any of my distributions as part of the standard
> installation.
Ok, I was wrong. I'm used to perl, I've seen perl
On Sun, 7 Jan 2001, Alan Cox wrote:
> None of these are needed for normal build/use/bug reporting work. In fact
> if you look at script_asm you'll see we go to great pains to ship prebuilt
> files too
Well, DocBook documentation isn't need for normal builds either and has
jade as dependency -
On Sun, 7 Jan 2001, Alan Cox wrote:
> The kernel doesnt require perl. I don't want to add a dependancy on perl
Well, I wouldn't be a dependancy as you do not have to use it. Why not add
it as an option. I guess most of the installations have a perl
interpreter.
BTW:
# find . -name \*.pl
On Sun, 7 Jan 2001, Paul Gortmaker wrote:
> BTW, people have a nasty habit of tacking their entire .config file
> onto bug reports to linux-kernel. Can you mention "grep ^C .config"
> somewhere in there (or have the script do it) since the number of
> config options isn't going to decrease
Hi there,
what do you think of this fragment ?
to me, it looks sort of large, but I wanted to cover all cases..
i'm going to optimize it a little bit.
$v_libc5 = '';
$v_libc6 = '';
# first, find the path of the concerning lib with the highest version
if (
On Sun, 7 Jan 2001, Brett wrote:
> Taking a guess here
>
> strings /lib/libc* | grep "release version"
>
> I'm not sure how reliable this method is either :)
>
I guess if you use a development version the above returns nothing. If I'm
right, a pre-release libc was recommended for use with
On 7 Jan 2001, Ulrich Drepper wrote:
> have libc5 out of the way in a separate subdir. Your best bet is to
> use ldconfig:
>
> /sbin/ldconfig -p|grep libc.so.5
>
Hmm, ok. Well, I was reading the Changes document when doing this first
and did not use my head. This document advises to deduct
nel Problem Report Generator v0.2\n";
print "=\n";
print " written by Matthias Juchem \n\n";
@@ -217,12 +217,14 @@
}
# c library 5
-if ( -e "/lib/libc.so.5" ) {
- ( $v_libc5
eport Generator v0.2\n";
print "=\n";
print " written by Matthias Juchem matthias\@brightice.de\n\n";
@@ -217,12 +217,14 @@
}
# c library 5
-if ( -e "/lib/libc.so.5" ) {
-
On 7 Jan 2001, Ulrich Drepper wrote:
have libc5 out of the way in a separate subdir. Your best bet is to
use ldconfig:
/sbin/ldconfig -p|grep libc.so.5
Hmm, ok. Well, I was reading the Changes document when doing this first
and did not use my head. This document advises to deduct the
On Sun, 7 Jan 2001, Brett wrote:
Taking a guess here
strings /lib/libc* | grep "release version"
I'm not sure how reliable this method is either :)
I guess if you use a development version the above returns nothing. If I'm
right, a pre-release libc was recommended for use with 2.2.0
Hi there,
what do you think of this fragment ?
to me, it looks sort of large, but I wanted to cover all cases..
i'm going to optimize it a little bit.
$v_libc5 = '';
$v_libc6 = '';
# first, find the path of the concerning lib with the highest version
if (
On Sun, 7 Jan 2001, Paul Gortmaker wrote:
BTW, people have a nasty habit of tacking their entire .config file
onto bug reports to linux-kernel. Can you mention "grep ^C .config"
somewhere in there (or have the script do it) since the number of
config options isn't going to decrease anytime
On Sun, 7 Jan 2001, Alan Cox wrote:
The kernel doesnt require perl. I don't want to add a dependancy on perl
Well, I wouldn't be a dependancy as you do not have to use it. Why not add
it as an option. I guess most of the installations have a perl
interpreter.
BTW:
# find . -name \*.pl
On Sun, 7 Jan 2001, Alan Cox wrote:
None of these are needed for normal build/use/bug reporting work. In fact
if you look at script_asm you'll see we go to great pains to ship prebuilt
files too
Well, DocBook documentation isn't need for normal builds either and has
jade as dependency -
On Sun, 7 Jan 2001, David Ford wrote:
Why can't I assume that perl is installed? It can be found on every
standard Linux/Unix installation.
No it can't. Perl isn't on any of my distributions as part of the standard
installation.
Ok, I was wrong. I'm used to perl, I've seen perl on every
On 7 Jan 2001, Ulrich Drepper wrote:
Why don't you, as the other script suggested, execute libc.so.6?
Symlinks can be missing or can be wrong.
I'll have a look at this shell script and take the best out of both to
make a new one.
BTW, lots of version dependencies found in older Changes
Hi Chris,
Comparing the Changes document for 2.4.0 against the one from 2.3.11 one
can see that many requirements were removed. Nine out of 22 are still
there.
Have the removed ones been unnecessary or only less important than the
remaining ones?
Regards,
Matthias
-
To unsubscribe from this
On 6 Jan 2001, Ulrich Drepper wrote:
> This is wrong. You cannot execute libc.so.5. This only works with
> glibc.
I already thought of something like that (I was not able to test it...).
Can you tell me a reliable way to get the version other than just looking
for the version appended to the
bugreport.pl
+# created by Matthias Juchem <[EMAIL PROTECTED]> Januar 2001
+#
+# collects system information and tries to help with generating bug
+# reports for linux-kernel
+# - prompts for general information about the problem
+# - acquires system information from various programs and from /pr
On Sat, 6 Jan 2001, Augusto César Radtke wrote:
> About bug reports, isn't a good thing introduce the sgi's lkcd
> (linux kernel crash dump) into the main stream of 2.5? The main problem
> of lkcd in 2.2 was the lack of kiobufs.
(see
On Sat, 6 Jan 2001, Jeremy M. Dolan wrote:
> If ver_linux can take off one of those steps, why not include a script
> which takes care of ALL the leg work? All of the files it asks the
> reporter to include are o+r...
If have started a script that produces the following output. ( some fields
On Sat, 6 Jan 2001, Jeremy M. Dolan wrote:
If ver_linux can take off one of those steps, why not include a script
which takes care of ALL the leg work? All of the files it asks the
reporter to include are o+r...
If have started a script that produces the following output. ( some fields
need
On Sat, 6 Jan 2001, Augusto Csar Radtke wrote:
About bug reports, isn't a good thing introduce the sgi's lkcd
(linux kernel crash dump) into the main stream of 2.5? The main problem
of lkcd in 2.2 was the lack of kiobufs.
(see
report.pl
+# created by Matthias Juchem [EMAIL PROTECTED] Januar 2001
+#
+# collects system information and tries to help with generating bug
+# reports for linux-kernel
+# - prompts for general information about the problem
+# - acquires system information from various programs and from /proc
+# - r
On 6 Jan 2001, Ulrich Drepper wrote:
This is wrong. You cannot execute libc.so.5. This only works with
glibc.
I already thought of something like that (I was not able to test it...).
Can you tell me a reliable way to get the version other than just looking
for the version appended to the
Hi Linus.
Step [7.3] is redundant because it is
already handled by the ver_linux script
This patch is against 2.4.0
Matthias
--- REPORTING-BUGS.orig Sat Jan 6 06:49:12 2001
+++ REPORTING-BUGS Sat Jan 6 06:47:57 2001
@@ -45,11 +45,10 @@
[7.] Environment
[7.1.] Software (add the output
Hi Linus.
Step [7.3] is redundant because it is
already handled by the ver_linux script
This patch is against 2.4.0
Matthias
--- REPORTING-BUGS.orig Sat Jan 6 06:49:12 2001
+++ REPORTING-BUGS Sat Jan 6 06:47:57 2001
@@ -45,11 +45,10 @@
[7.] Environment
[7.1.] Software (add the output
Hello,
this fixes some typos and pathnames in pointers from Configure.help to
files in the Documentation subtree.
Not much, but better than nothing.
Diff is against 2.4.0-test10.
Matthias
--- Documentation/Configure.help.orig Sat Nov 18 00:14:01 2000
+++ Documentation/Configure.help
Hello,
this fixes some typos and pathnames in pointers from Configure.help to
files in the Documentation subtree.
Not much, but better than nothing.
Matthias
--- Documentation/Configure.help.orig Sat Nov 18 00:14:01 2000
+++ Documentation/Configure.helpFri Nov 17 23:35:47 2000
@@
Hello,
this fixes some typos and pathnames in pointers from Configure.help to
files in the Documentation subtree.
Not much, but better than nothing.
Matthias
--- Documentation/Configure.help.orig Sat Nov 18 00:14:01 2000
+++ Documentation/Configure.helpFri Nov 17 23:35:47 2000
@@
Hello,
this fixes some typos and pathnames in pointers from Configure.help to
files in the Documentation subtree.
Not much, but better than nothing.
Diff is against 2.4.0-test10.
Matthias
--- Documentation/Configure.help.orig Sat Nov 18 00:14:01 2000
+++ Documentation/Configure.help
44 matches
Mail list logo