Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

Sandro Tosi-4
On Sat, Jun 27, 2009 at 19:57, Steven Pusser<[hidden email]> wrote:
> Package: wnpp
> Severity: wishlist
>
> KernelCheck is a Python-based GUI that checks kernel.org  and the
> Master Kernel thread on the Ubuntu forums
> for the latest Linux kernel sources and patches, then installs the

is this somehow related to Debian? Can be used on a debian system in a
productive way?

> kernel build tools, installs custom patches
> as requested, brings up xconfig for customization, builds the kernel
> image and header debs using a settable number of threads, then
> optionally installs the debs.  It is released under the GPL 3 license.
>
> Originally developed for use on Ubuntu, we had a request to add it to
> the Mepislovers Community Repository  (Mepis is a Lenny
> based distro) which I managed to do for the older version, Hopestar.

again, what about Debian?

> I was recently contacted by the application's main developer,
> Master Kernel, for assistance in packaging the new 1.2.5 release,
> Lumen, in which we were successful.  Master Kernel encountered some
> potential problems at mentors.debian.net due to his wish to remain
> anonymous, so he asked me to take over as the prospective
> Debian maintainer.  His previous upload of the sources to
> mentors.debian.net was vetted and a few problems were fixed, so he has
> removed his upload.
>
> The URL of my kernelcheck upload is :
> http://mentors.debian.net/debian/pool/main/k/kernelcheck
>
> The respective dsc file can be found at:
> http://mentors.debian.net/debian/pool/main/k/kernelcheck/kernelcheck_1.2.5-1.dsc

ITP bugs must be filed *before* start preparing a package (ideally,
the moment you studied enough the perspective upstream project and
evaluated interesting for Debian) and not after it'sdone (like in this
case). For example: is the ITP closed in the apckage on mentors? (I
didn't check, to be honest)

CCed to -mentors so you can keep the replies there.

Regards,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

Sandro Tosi-4
Hello Steven,
please keep the recipients list, replying in public so this discussion
can interest also other people.

On Sun, Jun 28, 2009 at 02:24, Steven Pusser<[hidden email]> wrote:

> On Sat, Jun 27, 2009 at 3:55 PM, Sandro Tosi<[hidden email]> wrote:
>> On Sat, Jun 27, 2009 at 19:57, Steven Pusser<[hidden email]> wrote:
>>> Package: wnpp
>>> Severity: wishlist
>>>
>>> KernelCheck is a Python-based GUI that checks kernel.org  and the
>>> Master Kernel thread on the Ubuntu forums
>>> for the latest Linux kernel sources and patches, then installs the
>>
>> is this somehow related to Debian? Can be used on a debian system in a
>> productive way?
>
> Thank you for your reply.
>
> It's had quite a bit of testing on the Simply Mepis  8.0.6, which is
> essentially Lenny under the hood.  It depends on Python >= 2.5.
> Unless the kernel building tools in Debian are renamed upstream, it
> should work on all versions except oldstable.

You didn't answer my question: can this package be useful to a Debian user?

> It's mainly a tool for anyone that wants to easily customize their own
> kernel; maybe optimize and strip out unwanted drivers.  I realize

Not from how you introduced it: it takes information from an ubuntu
forum (that's not the most fortunate decision) so it doesn't seem so
general purpose as you're asserting right above.

> Debian maintains an experimental kernel build repository that may
> duplicate much of this package's results.

and so again: what's the point of this package in Debian? I don't care
if Mepis is interested in it, it *must* be useful for Debian in the
first place.

> Master Kernel didn't file an ITP, and I didn't until after I put it up
> in the mentors repository.

and that's wrong, and already axplained

>  Should I pull the sources off there and
> upload them elsewhere?  I realize I'm going about this backwards, but
> we worked on the packaging first to get it into his PPA and the Lenny
> compatible Mepislovers community repo.  Later came the idea to see if
> it was worth trying to get it into Debian.

I think it's not that useful here, but I look forward for other comments.

Regards,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

George Danchev
Hi,

> Hello Steven,
> please keep the recipients list, replying in public so this discussion
> can interest also other people.
>
> On Sun, Jun 28, 2009 at 02:24, Steven Pusser<[hidden email]>
wrote:
> > On Sat, Jun 27, 2009 at 3:55 PM, Sandro Tosi<[hidden email]> wrote:
> >> On Sat, Jun 27, 2009 at 19:57, Steven Pusser<[hidden email]>
wrote:

> >>> Package: wnpp
> >>> Severity: wishlist
> >>>
> >>> KernelCheck is a Python-based GUI that checks kernel.org  and the
> >>> Master Kernel thread on the Ubuntu forums
> >>> for the latest Linux kernel sources and patches, then installs the
> >>
> >> is this somehow related to Debian? Can be used on a debian system in a
> >> productive way?
> >
> > Thank you for your reply.
> >
> > It's had quite a bit of testing on the Simply Mepis  8.0.6, which is
> > essentially Lenny under the hood.  It depends on Python >= 2.5.
> > Unless the kernel building tools in Debian are renamed upstream, it
> > should work on all versions except oldstable.
>
> You didn't answer my question: can this package be useful to a Debian user?

The question could be extended further: ... to be useful to any distro user?
In fact, it could be useful if the user doesn't mind to install kernels on its
own in parallel to the kernels installed by distro provided packages, or want
to bypass the packaging system for any weird reason. That would lead to
unpredictable and unexpected results sooner or later, and since that package
mostly tries to ease the build and installation of new kernels for
unexperienced users, they most probably won't understand the point of conflict
happening between these two parties installing kernel stuff. This might also
lead to spurious bug reports to debian kernel packages and user systems
rendered unbootable. OTOH, I really doubt that any experienced users would use
for such a tool to bring latest kernel for them in place, they just even pull
from git and further take the whole control themselves.

To summarize: this package could be either dangerous or useless depending on
the userbase ;-)

Last, but not least: this package name sounds quite suboptimal to me and
should probably be renamed to linuxcheck, since Debian also distributes other
kernels as well, or to tool could be extended to `check' other kernels
provided in Debian instead, which might be a little nightmare I seriously
doubt worth the effort.

--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>


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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

Master Kernel
In reply to this post by Sandro Tosi-4
I sent an email about 2 hours ago, but I guess it didn't go through. So I'll
have to type up a message all over again. That's the last time I use Google
Groups to post to a Usenet group.

NB: KernelCheck no longer refers to a Ubuntu Forums thread.


On Jun 28, 7:50 am, George Danchev <[hidden email]
<mailto:danchev%40spnet.net>> wrote:

 > > You didn't answer my question: can this package be useful to a
Debian user?
 >
 > The question could be extended further: ... to be useful to any
distro user?

Yes, and no. Yes, it can be useful. No, only to Debian and it's derivatives.

 > In fact, it could be useful if the user doesn't mind to install
kernels on its
 > own in parallel to the kernels installed by distro provided packages,
or want
 > to bypass the packaging system for any weird reason. That would lead to

The reason may not be weird at all. Debian provides generic kernel
packages to
its users. These generic kernels are suited to support the majority of
Debian's
users. But what about the remaining 2-3+%? Are they just supposed to
file a bug
and wait months before a new kernel comes out that supports their
hardware? No,
because they can easily get a new kernel another way. Generic kernels
can provide
either too much, or too little for a user. Too much, in that a user may
not want
to sacrifice boot time because of all the extra modules being loaded. Or
maybe
there's a new boot option called 'fastboot' out there. Maybe the user's
TV tuner
doesn't work with the standard kernel because the option isn't enabled
in the
kernel configuration. What if someone wants their computer to boot in five
seconds, you can't do that with a generic kernel, can you?

Reference: http://lwn.net/Articles/299483/


 > unpredictable and unexpected results sooner or later, and since that
package
 > mostly tries to ease the build and installation of new kernels for
 > unexperienced users, they most probably won't understand the point of
conflict
 > happening between these two parties installing kernel stuff. This
might also

Yes, it could lead to unexpected results. But it's all part of the
process. How
does anyone learn anything if they don't make mistakes? And there
shouldn't be
any point of conflict, given that KernelCheck kernels append -candela to
the end
of each kernel compiled. Unless Debian decides to append -candela to the
end of
its kernels, there shouldn't be a problem. Also, each kernel is
independent of
the other. Just because a problem arises under a KernelCheck kernel doesn't
mean that it would still be there under a generic kernel, and vice versa.


 > lead to spurious bug reports to debian kernel packages and user systems
 > rendered unbootable. OTOH, I really doubt that any experienced users
would use
 > for such a tool to bring latest kernel for them in place, they just
even pull
 > from git and further take the whole control themselves.

How could there be bug reports on debain kernel packages if the kernels
aren't
even named the same? Debian would NOT have a kernel in the repo with
-candela
attached to it, as already explained. And why wouldn't experienced users
use it?
KernelCheck just automates the process, the kernel configuration dialog
is still
there, which is what is used to configure the kernel. It even allows for
custom
patches.


 > To summarize: this package could be either dangerous or useless
depending on
 > the userbase ;-)

Dangerous? Yes, and no. Once again, kernels are independent of each
other. It's
not like compiling a kernel is going to do permanent (or even temporary)
damage
to a system. You could also say that gparted is dangerous if you make that
argument. But KernelCheck can't do any harm to a system. You're just
building
a package. Useless depending on the userbase? Of course, just like every
other
package out there. But it's not entirely useless - The latest version
has only
been out 9 days and there are already 300+ downloads on SourceForge
alone. (And
I haven't downloaded it at all :))

 
 > Last, but not least: this package name sounds quite suboptimal to me and
 > should probably be renamed to linuxcheck, since Debian also
distributes other
 > kernels as well, or to tool could be extended to `check' other kernels
 > provided in Debian instead, which might be a little nightmare I seriously
 > doubt worth the effort.

I have mixed feelings about this. At least when people hear 'KernelCheck',
they'd say "Oh, it must check kernels." (even though that's not really
what it does) But LinuxCheck? Mr. John Doe says, "No, I haven't
heard of LinuxCheck, but it must check Linux distributions or something.
I wish there was a program that could compile kernels for me." :)
I admit KernelCheck isn't the best name, but I have a pretty cool logo
for it. The name fit back when I used it to check to make sure I had the
latest kernel up on the Ubuntu Forums thread. But I'm always open to other
names, as long as it doesn't sound crappy like "KernelBuild" or
"KernelCompiler." And I doubt I would ever develop the program to 'check'
kernels provided with any distribution.


~-mk-~


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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

Master Kernel
In reply to this post by George Danchev
This didn't get attached as a follow-up, so I'll send it again.

NB: KernelCheck no longer refers to a Ubuntu Forums thread.



On Jun 28, 7:50 am, George Danchev <[hidden email]> wrote:
 >> You didn't answer my question: can this package be useful to a
Debian user?

>

 > The question could be extended further: ... to be useful to any
distro user?

Yes, and no. Yes, it can be useful. No, only to Debian and it's derivatives.


 > In fact, it could be useful if the user doesn't mind to install
kernels on its > own in parallel to the kernels installed by distro
provided packages, or want

> to bypass the packaging system for any weird reason. That would lead to


The reason may not be weird at all. Debian provides generic kernel
packages to its users. These generic kernels are suited to support the
majority of Debian's users. But what about the remaining 2-3+%? Are they
just supposed to file a bug and wait months before a new kernel comes
out that supports their hardware? No, because they can easily get a new
kernel another way. Generic kernels can provide either too much, or too
little for a user. Too much, in that a user may not want to sacrifice
boot time because of all the extra modules being loaded. Or maybe
there's a new boot option called 'fastboot' out there. Maybe the user's
TV tuner doesn't work with the standard kernel because the option isn't
enabled in the

kernel configuration. What if someone wants their computer to boot in five
seconds, you can't do that with a generic kernel, can you?

Reference: http://lwn.net/Articles/299483/


 > unpredictable and unexpected results sooner or later, and since that
package

> mostly tries to ease the build and installation of new kernels for

 > unexperienced users, they most probably won't understand the point of
conflict > happening between these two parties installing kernel stuff.
This might also Yes, it could lead to unexpected results. But it's all
part of the process. How does anyone learn anything if they don't make
mistakes? And there shouldn't be any point of conflict, given that
KernelCheck kernels append -candela to the end of each kernel compiled.
Unless Debian decides to append -candela to the end of its kernels,
there shouldn't be a problem. Also, each kernel is independent of

the other. Just because a problem arises under a KernelCheck kernel doesn't
mean that it would still be there under a generic kernel, and vice versa.


> lead to spurious bug reports to debian kernel packages and user systems

 > rendered unbootable. OTOH, I really doubt that any experienced users
would use > for such a tool to bring latest kernel for them in place,
they just even pull

> from git and further take the whole control themselves.


How could there be bug reports on debain kernel packages if the kernels
aren't even named the same? Debian would NOT have a kernel in the repo
with -candela attached to it, as already explained. And why wouldn't
experienced users use it? KernelCheck just automates the process, the
kernel configuration dialog is still there, which is what is used to
configure the kernel. It even allows for custom

patches.



 > To summarize: this package could be either dangerous or useless
depending on

> the userbase ;-)


Dangerous? Yes, and no. Once again, kernels are independent of each
other. It's not like compiling a kernel is going to do permanent (or
even temporary) damage

to a system. You could also say that gparted is dangerous if you make that

argument. But KernelCheck can't do any harm to a system. You're just
building a package. Useless depending on the userbase? Of course, just
like every other package out there. But it's not entirely useless - The
latest version has only been out 9 days and there are already 300+
downloads on SourceForge alone. (And

I haven't downloaded it at all :))


> Last, but not least: this package name sounds quite suboptimal to me and

 > should probably be renamed to linuxcheck, since Debian also
distributes other

> kernels as well, or to tool could be extended to `check' other kernels
> provided in Debian instead, which might be a little nightmare I seriously
> doubt worth the effort.

I have mixed feelings about this. At least when people hear 'KernelCheck',
they'd say "Oh, it must check kernels." (even though that's not really
what it does) But LinuxCheck? Mr. John Doe says, "No, I haven't
heard of LinuxCheck, but it must check Linux distributions or something.
I wish there was a program that could compile kernels for me." :)
I admit KernelCheck isn't the best name, but I have a pretty cool logo
for it. The name fit back when I used it to check to make sure I had the
latest kernel up on the Ubuntu Forums thread. But I'm always open to other
names, as long as it doesn't sound crappy like "KernelBuild" or
"KernelCompiler." And I doubt I would ever develop the program to 'check'
kernels provided with any distribution.


~-mk-~



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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

Master Kernel
In reply to this post by Master Kernel
On Mon, 29 Jun 2009 12:52:51 -0400, Master Kernel wrote:

> I sent an email about 2 hours ago, but I guess it didn't go through. So
> I'll have to type up a message all over again. That's the last time I
> use Google Groups to post to a Usenet group.

Sorry. This should have been a followup to another thread.

--
  . -o. Master Kernel <[hidden email]>
o(      GPG: 918AF52D .:.|.:. Ubuntu User # 27963
  ' -o' gpg --recv-keys --keyserver pgp.mit.edu 918AF52D
Fingerprint: 89A4 F2B5 D895 523A 4EED  BBA1 3711 DF03 918A F52D


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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

Jeff Carr-3
In reply to this post by George Danchev
On Sun, Jun 28, 2009 at 04:47, George Danchev<[hidden email]> wrote:

>> >> is this somehow related to Debian? Can be used on a debian system in a
>> >> productive way?

>> You didn't answer my question: can this package be useful to a Debian user?
>
> The question could be extended further: ... to be useful to any distro user?

Having a common tool for this (especially since it makes real .deb
files) would be useful to me. When I want to make kernel .deb files
it's always a PITA. I usually don't even bother anymore. If there was
a simple tool that would be convenient.


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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

Sandro Tosi-4
On Thu, Jul 2, 2009 at 04:12, Jeff Carr<[hidden email]> wrote:

> On Sun, Jun 28, 2009 at 04:47, George Danchev<[hidden email]> wrote:
>
>>> >> is this somehow related to Debian? Can be used on a debian system in a
>>> >> productive way?
>
>>> You didn't answer my question: can this package be useful to a Debian user?
>>
>> The question could be extended further: ... to be useful to any distro user?
>
> Having a common tool for this (especially since it makes real .deb
> files) would be useful to me. When I want to make kernel .deb files
> it's always a PITA. I usually don't even bother anymore. If there was
> a simple tool that would be convenient.

What's that make-kpkg (from kernel-package) missing? have you ever
reported usability bugs against kernel-package to make it more
suitable (if it isn't already) for users? would it be better to
concentrate on just one standard tool an make it the best?

Regards,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

Manoj Srivastava
On Thu, Jul 02 2009, Sandro Tosi wrote:

> On Thu, Jul 2, 2009 at 04:12, Jeff Carr<[hidden email]> wrote:
>> On Sun, Jun 28, 2009 at 04:47, George Danchev<[hidden email]> wrote:
>>
>>>> >> is this somehow related to Debian? Can be used on a debian system in a
>>>> >> productive way?
>>
>>>> You didn't answer my question: can this package be useful to a Debian user?
>>>
>>> The question could be extended further: ... to be useful to any distro user?
>>
>> Having a common tool for this (especially since it makes real .deb
>> files) would be useful to me. When I want to make kernel .deb files
>> it's always a PITA. I usually don't even bother anymore. If there was
>> a simple tool that would be convenient.
>
> What's that make-kpkg (from kernel-package) missing? have you ever
> reported usability bugs against kernel-package to make it more
> suitable (if it isn't already) for users? would it be better to
> concentrate on just one standard tool an make it the best?

        I'll be happy to add on to the kernel-package tool set, and am
 happier still to take patches.

        manoj
--
May a hundred thousand midgets invade your home singing cheesy
lounge-lizard versions of songs from The Wizard of Oz.
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source

Master Kernel
In reply to this post by Jeff Carr-3
On Wed, 01 Jul 2009 19:12:42 -0700, Jeff Carr wrote:

> On Sun, Jun 28, 2009 at 04:47, George Danchev<[hidden email]> wrote:
>
>>> >> is this somehow related to Debian? Can be used on a debian system
>>> >> in a productive way?
>
>>> You didn't answer my question: can this package be useful to a Debian
>>> user?
>>
>> The question could be extended further: ... to be useful to any distro
>> user?
>
> Having a common tool for this (especially since it makes real .deb
> files) would be useful to me. When I want to make kernel .deb files it's
> always a PITA. I usually don't even bother anymore. If there was a
> simple tool that would be convenient.

Can you clarify this? I'm not sure the other people who replied understood
what you meant. Do you mean you would like a tool that goes through all
the steps of configuring, compiling, and packaging a kernel in a
systematic way, or that you would like make-kpkg (kernel-package, which
creates the deb file from the configured kernel source) to be easier to
use?

Regards,
MK


--
  . -o. | Master Kernel <master.kernel.contact at gmail dot com>
o(      | GPG: 918AF52D .:.|.:. Ubuntu User # 27963
  ' -o' | 89A4 F2B5 D895 523A 4EED  BBA1 3711 DF03 918A F52D


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