sense to try to join forces with these Debian
based distributions and try to comaintain a -rt kernel package together
with these guys to ensure a solit maintenance inside Debian.
A lot of linux audio users build their own patched kernels, because
they can't
get it from the distribution;
S
forces with these Debian
based distributions and try to comaintain a -rt kernel package together
with these guys to ensure a solit maintenance inside Debian.
A lot of linux audio users build their own patched kernels, because they can't
get it from the distribution;
So why don't these peo
> I think 95% of the users of the linuxaudio.org community (LAU mailinglist)
> uses a realtime kernel (CONFIG_HZ_1000 + Mingo patch (!?)). Discussion if
> it is still needed bumps up there once in a while, for example:
>
> http://linuxaudio.org/mailarchive/lau/2009/3/10/153190
>
Giacomo A. Catenazzi wrote:
Raphael Hertzog wrote:
On Tue, 24 Mar 2009, Giacomo A. Catenazzi wrote:
Do you really need real time kernel?
Debian is a technical driven project, but reading the previous two
quotes,
"real time" is used as marketing thing.
It's good to question
On Tue, 24 Mar 2009, Giacomo A. Catenazzi wrote:
>> I do use a real-time kernel on a Debian based system for one of my
>> customers (but I have to recompile the kernel anyway because I do other
>> customizations) and I have good reasons to do so because I can't suffer
>&
Raphael Hertzog wrote:
On Tue, 24 Mar 2009, Giacomo A. Catenazzi wrote:
Do you really need real time kernel?
Debian is a technical driven project, but reading the previous two quotes,
"real time" is used as marketing thing.
It's good to question the use of any feature, but a r
On Tue, 24 Mar 2009, Giacomo A. Catenazzi wrote:
> Do you really need real time kernel?
> Debian is a technical driven project, but reading the previous two quotes,
> "real time" is used as marketing thing.
It's good to question the use of any feature, but a real-time
Grammostola Rosea wrote:
Jim wrote:
Grammostola Rosea,
I want also to direct your attention to the kernel, as it has the
possibility to be more supportive of those specific needs, by having
low latency and real-time extensions patched and enabled. The debian
folks (especially "waldi
On Tue, Mar 24, 2009 at 7:25 PM, Grammostola Rosea
wrote:
> Mmh this is interesting, cause there is an realtime kernel available in the
> ubuntu hardy repo, but not in Debian yet. Would be nice if there was one
> which users could install. But I'm not an rt-kernel expert at all
Jim wrote:
Grammostola Rosea,
I want also to direct your attention to the kernel, as it has the
possibility to be more supportive of those specific needs, by having
low latency and real-time extensions patched and enabled. The debian
folks (especially "waldi" aka Bastien Blank will s
On Thu, Mar 19, 2009 at 09:59:06PM +, Roger Leigh wrote:
> Hi folks,
>
> With respect to #494001, I would like to determine the minimum
> version of the linux kernel we will
>
> a) support and
> b) be physically capable of running
>
> for Squeeze.
>
>
On Fri, 20 Mar 2009, Marco d'Itri wrote:
> On Mar 19, Roger Leigh wrote:
> > With respect to #494001, I would like to determine the minimum
> > version of the linux kernel we will
> For the new udev package[1] I am trying *very* hard to keep it working
> even with 2.6.18
On Mar 19, Roger Leigh wrote:
> With respect to #494001, I would like to determine the minimum
> version of the linux kernel we will
For the new udev package[1] I am trying *very* hard to keep it working
even with 2.6.18 kernels long enough to be able to finish the upgrade,
but I can te
Hi folks,
With respect to #494001, I would like to determine the minimum
version of the linux kernel we will
a) support and
b) be physically capable of running
for Squeeze.
It has been asserted that squeeze will not work with kernels
< 2.6.26 by jcristau on IRC, but I haven't yet f
Roger Leigh writes:
> On Wed, Feb 25, 2009 at 04:16:53PM +0100, Goswin von Brederlow wrote:
>
>> Maybe we need a mass bug filing for programs not using 64bit file
>> offsets.
>
> I think that would be appropriate. At this point, I can't see a
> valid reason for any package to not have LFS enable
On Fri, Feb 20, 2009 at 12:56:30PM -0600, Manoj Srivastava wrote:
> > BTW, I have a set of patches you might want to consider. I'll file
> > them in BTS if you're currently making make-kpkg.
>
> Please. I have been thinking about the request you made for
> debugging symbols being package
On Thu, Feb 26, 2009 at 10:48:35AM +, Roger Leigh wrote:
> Agreed. If we can identify all libraries (perhaps with a simple grep over
> the lintian lab?) containing these types, and make sure LFS is enabled in
> all of them, it should then be possible to switch once all dependencies
> are rebu
On Wed, Feb 25, 2009 at 06:20:50PM -0800, Steve Langasek wrote:
> On Wed, Feb 25, 2009 at 10:52:30PM +, Roger Leigh wrote:
>
> > Personally, I would prefer the glibc headers to just set the LFS
> > macros to the 64 bit versions by default, so that rather than
> > taking extra steps to enable L
On Wed, Feb 25, 2009 at 10:52:30PM +, Roger Leigh wrote:
> Personally, I would prefer the glibc headers to just set the LFS
> macros to the 64 bit versions by default, so that rather than
> taking extra steps to enable LFS, LFS would be the default and you
> would then need to take extra steps
On Wed, Feb 25, 2009 at 04:16:53PM +0100, Goswin von Brederlow wrote:
> Maybe we need a mass bug filing for programs not using 64bit file
> offsets.
I think that would be appropriate. At this point, I can't see a
valid reason for any package to not have LFS enabled.
> Anyone up for hacking libc
On Wed, Feb 25 2009, Goswin von Brederlow wrote:
> Manoj Srivastava writes:
>
>> On Wed, Feb 18 2009, Theodore Tso wrote:
>>
>>> On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote:
>>>> Hi,
>>>>
>>>> This is
Manoj Srivastava writes:
> On Wed, Feb 18 2009, Theodore Tso wrote:
>
>> On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote:
>>> Hi,
>>>
>>> This is a heads up for a major change in kernel-package, the
>>> tool to create use
Goswin von Brederlow, le Wed 25 Feb 2009 16:16:53 +0100, a écrit :
> Anyone up for hacking libc to always fail on the 32bit wrappers for
> seek, stat, ...?
Or looking for binaries with a U lseek ?
Samuel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsub
Ron Johnson writes:
> On 02/09/2009 08:04 AM, Ron Johnson wrote:
>> On 02/09/2009 12:28 AM, Martin Langhoff wrote:
>>> On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings
>>> wrote:
If jed can deal with files that large, sure. But if it expects to be
able to load the entire file into memory
Package: wnpp
Severity: normal
This kernel patch provides exec-shield, a security feature for the
Linux kernel on i386 (it is not relevant for x86_64). The patch is
present in Fedora kernels, which is also the upstream maintainer.
Since I hardly use i386 machines anymore, I need help with any of
On Wed, Feb 18 2009, Theodore Tso wrote:
> On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote:
>> Hi,
>>
>> This is a heads up for a major change in kernel-package, the
>> tool to create user packaged kernel images and headers; which will
>&g
On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote:
> Hi,
>
> This is a heads up for a major change in kernel-package, the
> tool to create user packaged kernel images and headers; which will
> make the make-kpkg script far less error prone, and far more
&
Hi Mano,
> This is a heads up for a major change in kernel-package, the
> tool to create user packaged kernel images and headers; which will
> make the make-kpkg script far less error prone, and far more
> deterministic.
kernel-package works well for me since years now, th
On Mon, Feb 09 2009, Michael Tautschnig wrote:
> [...]
>>c. his means there will be no need for /etc/kernel-img.conf file any
>> more.
>
> [...]
>
> Isn't this file also read in the postinst of the "official" kernels?
> In FAI we had sever
On 02/09/2009 08:04 AM, Ron Johnson wrote:
On 02/09/2009 12:28 AM, Martin Langhoff wrote:
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings
wrote:
If jed can deal with files that large, sure. But if it expects to be
able to load the entire file into memory - as most text editors do -
stat() will
On 02/09/2009 12:28 AM, Martin Langhoff wrote:
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings wrote:
If jed can deal with files that large, sure. But if it expects to be
able to load the entire file into memory - as most text editors do -
stat() will be only the first of its problems.
Old vi
Hi
On Montag, 9. Februar 2009, Michael Tautschnig wrote:
> [...]
> >c. his means there will be no need for /etc/kernel-img.conf file any
> > more.
>
> [...]
>
> Isn't this file also read in the postinst of the "official" kernels? In FAI we
>
[...]
>c. his means there will be no need for /etc/kernel-img.conf file any
> more.
[...]
Isn't this file also read in the postinst of the "official" kernels? In FAI we
had several issues when kernel-img.conf was missing or hadn't had the proper
value
Hi,
This is a heads up for a major change in kernel-package, the
tool to create user packaged kernel images and headers; which will
make the make-kpkg script far less error prone, and far more
deterministic.
a. Every invocation of kernel-package will remove ./debian directory
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings wrote:
> If jed can deal with files that large, sure. But if it expects to be
> able to load the entire file into memory - as most text editors do -
> stat() will be only the first of its problems.
Old vi was able to work with files larger than avail
On Sun, 2009-02-08 at 10:46 +, Jörg Sommer wrote:
> Hi,
>
> I have the bug report #489917 that complains that Jed can't handle
> 64‐bit kernel structures. In this special case, the stat() return with
> EOVERFLOW Value too large to be stored in data type. Jed was compiled f
On 02/08/2009 04:46 AM, Jörg Sommer wrote:
Hi,
I have the bug report #489917 that complains that Jed can't handle
64‐bit kernel structures. In this special case, the stat() return with
EOVERFLOW Value too large to be stored in data type. Jed was compiled for
a 32‐bit kernel and is run with
hi,
On Sun, Feb 08, 2009 at 12:58:43PM +0100, Lionel Elie Mamane wrote:
> I'd think you should enable it for all 32 bit builds; it is, I think,
> a step in having support for large files (files bigger than 2 or 4
> gigabytes), something we wanted to have for... woody.
more specifically, what i th
On Sun, Feb 08, 2009 at 10:46:42AM +, Jörg Sommer wrote:
> I have the bug report #489917 that complains that Jed can't handle
> 64‐bit kernel structures. (...) The error can be fixed by compiling
> Jed with -D_FILE_OFFSET_BITS=64. Should I set this option for all
> 32‐bit
Hi,
I have the bug report #489917 that complains that Jed can't handle
64‐bit kernel structures. In this special case, the stat() return with
EOVERFLOW Value too large to be stored in data type. Jed was compiled for
a 32‐bit kernel and is run with a 64‐bit kernel. The error can be fix
On Sun, 2009-02-01 at 23:31 +0100, Klaus Ethgen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am So den 1. Feb 2009 um 18:57 schrieb Luk Claes:
> > > With lenny the provided glibc seems to be incompatible to kernel 2.4.
> > > There are many system
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am So den 1. Feb 2009 um 18:57 schrieb Luk Claes:
> > With lenny the provided glibc seems to be incompatible to kernel 2.4.
> > There are many systems out there still running with kernel 2.4 cause
> > stability. (My servers which
On Sun, Feb 01, 2009 at 05:26:30PM +0100, Klaus Ethgen wrote:
> With lenny the provided glibc seems to be incompatible to kernel 2.4.
The Linux 2.4 support ended with the Etch release. Even for Etch it is
only supported for upgrades.
> Is there any scenario what happens to such system
Klaus Ethgen wrote:
> Just to bring that back to discussion:
>
> With lenny the provided glibc seems to be incompatible to kernel 2.4.
> There are many systems out there still running with kernel 2.4 cause
> stability. (My servers which needs to be stable all run Kernel 2.4.)
s/le
Klaus Ethgen writes:
> Background: The glibc in lenny is compiled to be incompatible with
> kernels lower than 2.6. I do not know if there are options to use newer
> glibc with older kernels.
There is other software in lenny that isn't built to be compatible with
older kernels as well. For exam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Just to bring that back to discussion:
With lenny the provided glibc seems to be incompatible to kernel 2.4.
There are many systems out there still running with kernel 2.4 cause
stability. (My servers which needs to be stable all run Kernel 2.4
On Sat, Nov 01, 2008 at 07:29:16PM -0400, Filipus Klutiero wrote:
>> | Package: test
>> | Depends: test-modules | test-source
>> |
>> | Package: test-modules
>> | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64
>> |
>> | Package: test-source
>>
>> Both apt and aptitude woul
taking up disk space and bandwidth (e.g., a
kernel containing modules that won't work, even if you install every
package in main and contrib). Worse, software that might give the
user the impression that something is going to work (module is loaded,
reports some progress), but then fail
On Sat, Nov 01, 2008 at 09:37:50PM +0100, Frans Pop wrote:
> For a really neat and complete solution you'd IMO still need something
> like I proposed though to make the vbox ABI visible in package names, but
> that can probably be postponed until after Lenny.
Well it is, namely the upstream vers
On Sat, Nov 01, 2008 at 07:29:16PM -0400, Filipus Klutiero wrote:
>> | Package: test
>> | Depends: test-modules | test-source
>> |
>> | Package: test-modules
>> | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64
>> |
>> | Package: test-source
>>
>> Both apt and aptitude would
Hi folks
Because of some recent events, I thought about the possibility for
packages to depend against kernel module packages. As we don't want to
dictate the usage of Debian provided kernels, we need a last resort
fallback to the modules source.
My first solution was something lik
from lme makes no real sense to me because lme is not
> supposed to be reupped for each new version of virtualbox. On the other hand
> building them with virtualbox-ose makes no sense because vbos is not supposed
> to be reupped for each new kernel.
You are solving problem 2 before
because lme is
> not supposed to be reupped for each new version of virtualbox. On the
> other hand building them with virtualbox-ose makes no sense because vbos
> is not supposed to be reupped for each new kernel.
Sounds like a good plan. Only disadvantage is that for ABI-changing kernel
up
r each new version of virtualbox. On the other hand
building them with virtualbox-ose makes no sense because vbos is not supposed
to be reupped for each new kernel.
How about adding a new package, virtualbox-ose-modules-2.6, mirroring lme only
for the virtualbox modules? This package could be handled
Bastian Blank wrote:
> On Fri, Oct 31, 2008 at 05:07:44PM +0100, Frans Pop wrote:
>> Exactly because of the option of using custom built kernels, virtualbox
>> does not depend on the Debian modules packages, but only recommends
>> them (which IMO is correct: the Debian module package will be instal
On Fri, Oct 31, 2008 at 05:07:44PM +0100, Frans Pop wrote:
> Bastian Blank wrote:
> > Because of some recent events, I thought about the possibility for
> > packages to depend against kernel module packages. As we don't want to
> > dictate the usage of Debian provid
as moving the whole
> package to non-free.
The difference between main and contrib is not at all the same as the
difference between main and non-free.
> > Because the kernel is perfectly usable without the firmwares.
>
> But how about the specific modules that require them, the ones
Bastian Blank wrote:
> Because of some recent events, I thought about the possibility for
> packages to depend against kernel module packages. As we don't want to
> dictate the usage of Debian provided kernels, we need a last resort
> fallback to the modules source.
Exactly beca
On Friday 31 October 2008 22:20:26 Josselin Mouette wrote:
> Le vendredi 31 octobre 2008 à 12:44 +0100, Bastian Blank a écrit :
> > Because of some recent events, I thought about the possibility for
> > packages to depend against kernel module packages. As we don't want to
>
Le vendredi 31 octobre 2008 à 12:44 +0100, Bastian Blank a écrit :
> Because of some recent events, I thought about the possibility for
> packages to depend against kernel module packages. As we don't want to
> dictate the usage of Debian provided kernels, we need a last resort
>
Hi folks
Because of some recent events, I thought about the possibility for
packages to depend against kernel module packages. As we don't want to
dictate the usage of Debian provided kernels, we need a last resort
fallback to the modules source.
My first solution was something lik
Le jeudi 30 octobre 2008 à 17:37 -0200, Alexandre Oliva a écrit :
> It does make a difference when the components don't quite form an
> inseparable unit, but rather they're just put together in a single
> tarball for convenience.
Kernel modules are not really separable from th
bian itself is Free to modify, and quite often does.
It does make a difference when the components don't quite form an
inseparable unit, but rather they're just put together in a single
tarball for convenience.
Say, Debian splits out the kernel documentation and kernel headers
from
Le mercredi 29 octobre 2008 à 22:10 -0200, Alexandre Oliva a écrit :
> > Because the kernel is perfectly usable without the firmwares.
>
> But how about the specific modules that require them, the ones that
> got this sub-thread started in the first place? It doesn't make se
ey were packaged
together just for e.g. convenience of download, and building them
separately would be just as simple.
Kernel modules *are* plugins, and the Linux build machinery is
designed to enable just this kind of convenient separate building.
I understand that, from a maintenance point o
; non-Free portions go to contrib.
I don’t know of such a package, but if there are, that’s fine. Just
unnecessary.
> Why should this cleansing not be applied to the kernel, that's
> arguably far more important than a number of accessory packages that
> undergo this procedure?
at portions that are Free and stand-alone remain in main, while
non-Free portions go to non-free, and those that are Free but require
non-Free portions go to contrib.
Why should this cleansing not be applied to the kernel, that's
arguably far more important than a number of accesso
[Alexandre Oliva]
> Say, if these drivers that require non-Free firmware *were* shipped
> as separate packages (for whatever reason), would they really belong
> in main, rather than in contrib?
Now you've hit on it. If they were packaged _separately_, the drivers
that are non-functional without
mpiler per se, it just
offers a nicer front end for someone who wants the compiler to run, a
driver for a device is just a nice front end for someone who wants the
device to work. If firmware is required by the device, this would
make the driver in the kernel an accessory to the non-Free program
t
man.net/wiki/debirf
* License : GPLv3
Programming Lang: Bash
Description : Build a kernel and initrd to run Debian from RAM
debirf (DEBian on Initial Ram Filesystem) is a set of tools designed
to create and prepare a kernel and initial ram filesystem that can
run a full-blown Debian
On Sat, 2008-10-25 at 18:28 -0200, Alexandre Oliva wrote:
> Hi again,
>
> I've been watching the discussion and the separation of firmware from
> kernel sources with a lot of interest, but today it dawned on me that,
> even if this project is completed, it wouldn't qui
Hi again,
I've been watching the discussion and the separation of firmware from
kernel sources with a lot of interest, but today it dawned on me that,
even if this project is completed, it wouldn't quite address the issue
of compliance with Debian procedures and regulations.
I understa
Le October 19, 2008 04:04:58 am Thomas Viehmann, vous avez écrit :
> Filipus Klutiero wrote:
> > It is, but the first team that should approve a Linux upgrade in lenny
> > is the kernel team. After that the d-i team would be contacted.
>
> Could you just stop handing
Filipus Klutiero wrote:
> It is, but the first team that should approve a Linux upgrade in lenny
> is the kernel team. After that the d-i team would be contacted.
Could you just stop handing out bad advice on the development list, please?
The answer to the kernel question is "No"
On ven, 2008-10-17 at 21:39 -0400, Filipus Klutiero wrote:
> For kernel-related discussions, ask on debian-kernel.
And for lenny-related discussions, isn't the release team concerned? :)
It is, but the first team that should approve a Linux upgrade in lenny
is the kernel team. Af
On ven, 2008-10-17 at 21:39 -0400, Filipus Klutiero wrote:
> For kernel-related discussions, ask on debian-kernel.
And for lenny-related discussions, isn't the release team concerned? :)
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
For kernel-related discussions, ask on debian-kernel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
For kernel-related discussions, ask on debian-kernel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>> not the way upstream recommends to install firmware.
>>
>> All (non-free) Debian firmware packages install the firmware files
>> directly under /lib/firmware, not /lib/firmware/$kernel-version.
>>
>> And Debian's udev does not consider the kernel-vers
On Tue, 14 Oct 2008, Felipe Sateler wrote:
> Please hit me with the cluebat; apparently I'm not understanding anything. Why
> would I want to have more than one firmware installed? AIUI, the firmware is
The firmware has an ABI to the kernel driver. If it changes, both have to
change
On Tue, 14 Oct 2008, Felipe Sateler wrote:
> Please hit me with the cluebat; apparently I'm not understanding
> anything. Why would I want to have more than one firmware installed?
> AIUI, the firmware is meant to be installed into the hardware and as
> such shouldn't be tied
s removed?
>
> It wasn't removed, upstream added that after the version of udev in Debian.
Not Debian. Ubuntu. And it caused quite a fight in LKML, too, which I
won't bother to repeat here.
Basically, there are three choices:
1. Package the firmware as the new kernel-package d
Manoj Srivastava wrote:
>> This means that if you start installing the same firmware file under
>> versioned directories, udev will use the first one it finds. Which
>> will be the one for some $random kernel version and not the one for
>> the currently running kernel.
Hello Manoj and other Kernel-Maintainers,
Thank you for doing this hard job...
I am ongoing to test the new "kernel-package".
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux
Paul Wise wrote:
> In contrast, the latest upstream udev (130) has this:
> FIRMWARE_DIRS="/lib/firmware/$(uname -r) /lib/firmware"
From what I've seen on lkml I suspect this has mainly been added because
some distributions _do_ install firmware is versioned subdirs.
Debian currently does not sup
On Tue, Oct 14, 2008 at 2:38 PM, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>Seems like upstream udev firmware loader does look at
> /lib/firmware/$(uname -r)/, which seems sane.
>
>Why was this removed?
It wasn't removed, upstream added that after the version of udev in Debian.
e. Also,
> it is not the way upstream recommends to install firmware.
I think where Debian looks for firmware could change. Or people
can use hardlinks.
> All (non-free) Debian firmware packages install the firmware files
> directly under /lib/firmware, not /lib/firmware/$kernel-v
t;
> All (non-free) Debian firmware packages install the firmware files
> directly under /lib/firmware, not /lib/firmware/$kernel-version.
>
> And Debian's udev does not consider the kernel-version when looking for
> firmware. /lib/udev/hotplug.functions has:
> FIRMWARE_DIRS='
On mar, 2008-10-14 at 07:59 +0200, Peter Jordan wrote:
> wouldn't it
> be a good idea to take kernel 2.6.27 as the stable kernel in lenny?
If we want to release lenny before 2.6.27 is not supported anymore,
maybe it's not?
--
Yves-Alexis
signature.asc
Description: This is a
Hi,
considering that Adrian Bunk announced long time support for kernel
2.6.27 (http://article.gmane.org/gmane.linux.kernel/743377) wouldn't it
be a good idea to take kernel 2.6.27 as the stable kernel in lenny?
PJ
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "u
.
All (non-free) Debian firmware packages install the firmware files
directly under /lib/firmware, not /lib/firmware/$kernel-version.
And Debian's udev does not consider the kernel-version when looking for
firmware. /lib/udev/hotplug.functions has:
FIRMWARE_DIRS='/lib/firmware /usr/lo
with several roughly identical
> manpages installed, which seems like a waste.
It would be not that usefull as the kernel team wants to split the
complete image maintainer scripts into its own package anyway. And
having one package which just a manpage is not nice for the archive.
Bastian
--
Di
On Fri, 10 Oct 2008, Manoj Srivastava engaged keyboard and shared this with us
all:
>--} Hi folks,
>--}
>--} A new version of kernel-package has made its way to unstable.
>--} This is a extensive change, and addresses most of the problems that
>--} have been plaguing
This one time, at band camp, Manoj Srivastava said:
> I can go either route. Comments?
I'd say a -common package makes the most sense to me. The other way
seems like you could conceivably end up with several roughly identical
manpages installed, which seems like a waste.
--
Hi,
The kernel images produced by kernel package all obey the
directives in /etc/kernel-img.conf, for example, to trigger
lilo/grub. Currently, users only get to see the man page if they happen
to have the 'kernel-package' package installed. As Bug#373872 shows,
even offic
Hi,
Be sure to get kernel-package_11.005_all.deb. The 11.005 fixes a
critical regression, born of a copy&paste error from late night
hacking. Sorry for the inconvenience.
manoj
--
Spence's Admonition: Never stow away on a kamikaze plane.
Manoj Srivastava <[EMA
Hi folks,
A new version of kernel-package has made its way to unstable.
This is a extensive change, and addresses most of the problems that
have been plaguing kernel-package, partially thanks to patches provided
by other folk.
The new version works with the merged x86 code in
On mer, 2008-09-17 at 22:33 +0200, David Paleino wrote:
> Should I continue working on DKMS for Debian, or is that all wasted
> time?
Go ahead, it *will* be useful, and isn't intended to replace
module-assistant anyway. It may have some problems, but they will be
identified, reported and fixed.
C
So, what's the final status of this thread?
Should I continue working on the package? Should I drop it?
I wouldn't want to drop it -- if there's no consensus or, at least, someone
wanting it -- and wanting to *sponsor* it, or someone that will actually
*use* it, I believe I'll put that on my pri
On Wed, 2008-09-17 at 22:33 +0200, David Paleino wrote:
> On Thu, 11 Sep 2008 10:00:38 +0200, David Paleino wrote:
>
> > Hello *,
> > some time ago I filed a RFS [1] for DKMS [2]
>
> So, what's the final status of this thread?
> Should I continue working on the package? Should I drop it?
>
> I w
601 - 700 of 2851 matches
Mail list logo
