Re: Intent to NMU mkvmlinuz to fix pending po-debconf l10n bugs

[Sven Luther]

On Tue, Oct 31, 2006 at 08:18:33PM +0100, Christian Perrier wrote:
> Quoting Sven Luther ([EMAIL PROTECTED]):
> > On Tue, Oct 31, 2006 at 09:04:26AM +0100, Christian Perrier wrote:
> > > What I propose for mkvmlinuz is:
> > > 
> > > -fix the po-debconf thing in SVN
> > > -include the Swedish translation
> > > -post a call for updates to -i18n with a 7-days delay
> > > -commit all received updates (I'll receive them directly as this is much 
> > > simpler)
> > > -ping Sven for an upload
> > 
> > Cool,
> > 
> > > If you're OK, please allow "cperrier-guest" and not "bubulle" for commit 
> > > access. I am in too many projects in Alioth now and it causes commit 
> > > problems (see my recent blog post about this).
> > 
> > Done, the mkvmlinuz is in kernel/trunk/utils/mkvmlinuz.
> 
> 
> I have committed the two pending fixes I had.
> 
> I'll now send a call for translation updates to debian-i18n and give a
> 7 days delay

Thanks, i have seen those mails.

Friendly,

Sven Luther


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

Re: Intent to NMU mkvmlinuz to fix pending po-debconf l10n bugs

[Christian Perrier]

Quoting Sven Luther ([EMAIL PROTECTED]):
> On Tue, Oct 31, 2006 at 09:04:26AM +0100, Christian Perrier wrote:
> > What I propose for mkvmlinuz is:
> > 
> > -fix the po-debconf thing in SVN
> > -include the Swedish translation
> > -post a call for updates to -i18n with a 7-days delay
> > -commit all received updates (I'll receive them directly as this is much 
> > simpler)
> > -ping Sven for an upload
> 
> Cool,
> 
> > If you're OK, please allow "cperrier-guest" and not "bubulle" for commit 
> > access. I am in too many projects in Alioth now and it causes commit 
> > problems (see my recent blog post about this).
> 
> Done, the mkvmlinuz is in kernel/trunk/utils/mkvmlinuz.


I have committed the two pending fixes I had.

I'll now send a call for translation updates to debian-i18n and give a
7 days delay




signature.asc
Description: Digital signature

Processed: reassign 396471 to linux-2.6, merging 396471 395110

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 396471 linux-2.6
Bug#396471: linux-image-2.6.18-1-parisc64-smp: fails to install
Bug reassigned from package `linux-image-2.6.18-1-parisc64-smp' to `linux-2.6'.

> merge 396471 395110
Bug#395110: linux-2.6: cannot configure linux-image-2.6.18-1-k7 package: 
Missing Required parameter 'Old' at 
/var/lib/dpkg/info/linux-image-2.6.18-1-k7.postinst
Bug#396471: linux-image-2.6.18-1-parisc64-smp: fails to install
Merged 395110 396471.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Sven Luther]

On Wed, Nov 01, 2006 at 12:55:45AM +0100, Francesco Poli wrote:
> On Tue, 31 Oct 2006 23:59:18 +0100 Sven Luther wrote:
> 
> [...]
> > Nope, because you can ship the source code and the object file if you
> > wanted.
> > 
> > Already now, major parts of debian/main are not cleanly buildable out
> > of the box, due to cyclic bootstraping dependencies.
> 
> But those major parts of debian/main are cleanly buildable using an
> already functioning installation of debian/main, aren't they?

No, not always.

> At least I *hope* those major parts are buildable using only packages
> from debian/main, otherwise they would Build-Depend on out-of-main
> components, which is a Policy violation for a package in main, AFAIK.

Well, It is not so much that you have to depend on out-of-main components, but
that you have to hand-build some of them and stop in the middle and stuff like
that.

> If what I have just said is true and confirmed, then *that* is the
> difference: one thing is having cyclic bootstrapping dependencies that
> make an already compiled and installed system necessary, a completely
> different beast is something that needs an out-of-main compiler in order
> to be compiled...

Well, the cross compiler would be built from the same gcc source in main.
There is just no binary package provided for those.

> Or am I completely off track?!?

Not completely, but a bit yes.

Friendly,

Sven Luther


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

Bug#396471: linux-image-2.6.18-1-parisc64-smp: fails to install

[Sven Luther]

On Tue, Oct 31, 2006 at 03:59:57PM -0800, Steve Langasek wrote:
> On Wed, Nov 01, 2006 at 12:21:56AM +0100, Sven Luther wrote:
> 
> > This bug is closed by the new kernel-package version, and linux-2.6 only 
> > needs
> > to be rebuilt with it, which is scheduled for -4, and amply discussed here
> > previously.
> 
> Is linux-2.6 binNMU-safe?  Could we binNMU linux-2.6 to fix this bug on the
> affected architectures?  (How many archs are known to be affected?)

Why is it so urgent to fix this, that you cannot wait the few days until -4 is
uploaded, which fs announced here earlier, and will have a lot more fixes ? 

There sure seemed no hurry to fix this when it was encountered on powerpc.

Friendly,

Sven Luther


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

Bug#379090: Still no news on 64bit i386 kernels

[Otavio Salvador]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Tue, Oct 31, 2006 at 02:01:22PM +0100, Frederik Schueler wrote:
[...]
>> Adding amd64 as subarch to i386 would mean 3 additional flavors to
>> build, raising the overall build-time of that package by 1.5-2h. 
>
> Which doesn't sound like a blocker to me, FWIW.  Also, what about just
> providing the "amd64" flavor for i386 without the xen/vserver flavors?  In
> particular, I don't see any need for the xen flavor, wouldn't xen work just
> fine with amd64 as the dom0 install and i386 in domX without any kernel
> images installed in the domX?

Yes. It can. I use it exactly this way here.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Francesco Poli]

On Tue, 31 Oct 2006 20:50:19 +0100 Ola Lundqvist wrote:

> Hi Mathew
> 
> (Anyone on debian-legal: please note and maintain the Cc:s)

Again assuming that this means you and Matthew want to be Cc:ed as
well...

[...]
> > That's perfectly acceptable. Upstream can do whatever they want. 
> > However, if upstream do not provide the preferred form for
> > modification  (ie, the unobfuscated version), Debian can not
> > distribute it under the  terms of the GPL.
> 
> True. But do this mean that Nvidia have actually violated the license
> that they have released their software under? Well maybe not as they
> may not need to accept the license to actually use their rights...

A copyright holder cannot violate the license he/she releases his/her
work under: he/she needs *no* copyright license to deal with his/her own
work in any manner.
The only license violation that could possibly happen is on works
someone else holds copyright on.

Hence, nVidia could be in violation, *if* and *as long as* their work is
based on someone else's GPL'ed work.  I don't know if this is the case
here...

> 
> As I understand from this, is that it is not enough to know that the
> software is licensed under GPL, we must also check every single line
> of code (manually) to determine if it is obfuscated or not before we
> include it into Debian? Or should we just do this on a best effort
> basis, that is file serious bugs when we encounter this.

I think the Debian Project should assume that what upstream distributes
as "source code" is actually source code (that is to say, the "preferred
form for making modifications to the work"), *unless* there is a reason
to think otherwise.

Please note that IANADD: my personal opinion does not necessarily
reflect the one of the DDs.

[...]
> > If people define source as "the preferred form for modifications" in
> > all  cases, then there's no place for deliberately obfuscated code
> > in Debian.
> 
> That is what the Open Source Definition tell. The open source
> definition is only applicable on programs though. But we do not
> enforce the usage of the open source definition as far as I know. Or
> do we?
> 
> http://www.opensource.org/docs/definition.php

The OSD is completely off-topic here.
The Debian Social Contract promises that "Debian will remain 100% free"
according to the DFSG.  It never speaks about the OSD.

> 
> > There's also arguably no place for works that are only available 
> > as JPEGs, any flattened image formats, mp3s, PDFs and so on. Right
> > now  there doesn't seem to be a strong opinion in the project about
> > that, but  I expect it's a discussion that needs to be had.
> 
> True. The positional statement that clarified was not the winner in
> one of our votes:
> http://www.debian.org/vote/2006/vote_004

Please note that, according to the proposer of GR-2006-004 (hi Don!),
the text of the resolution "very carefully walks the line that the DFSG
currently walks"[1].  That is to say, this GR (which however did not
pass, as you note) only "restates what is current practice"[1], as far
as non-programmatic works and DFSG#2 are concerned.

The discussion about source code of non-programmatic works is
(unfortunately) still to be had.

[1] see the thread that started with
http://lists.debian.org/debian-vote/2006/10/msg00185.html

-- 
But it is also tradition that times *must* and always
do change, my friend.   -- from _Coming to America_
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4



pgpJTkGyaXSVH.pgp
Description: PGP signature

Bug#396471: linux-image-2.6.18-1-parisc64-smp: fails to install

[Steve Langasek]

On Wed, Nov 01, 2006 at 12:21:56AM +0100, Sven Luther wrote:

> This bug is closed by the new kernel-package version, and linux-2.6 only needs
> to be rebuilt with it, which is scheduled for -4, and amply discussed here
> previously.

Is linux-2.6 binNMU-safe?  Could we binNMU linux-2.6 to fix this bug on the
affected architectures?  (How many archs are known to be affected?)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Bug#379090: Still no news on 64bit i386 kernels

[Steve Langasek]

On Tue, Oct 31, 2006 at 02:01:22PM +0100, Frederik Schueler wrote:

> On Tue, Oct 31, 2006 at 01:30:59AM -0800, Steve Langasek wrote:
> > Can someone from the kernel team comment on whether there are problems with
> > this particular patch that have not yet been noted in the bug report?  If
> > there aren't any known objections, I could review the patch myself and look
> > at committing it.

> Adding amd64 as subarch to i386 would mean 3 additional flavors to
> build, raising the overall build-time of that package by 1.5-2h. 

Which doesn't sound like a blocker to me, FWIW.  Also, what about just
providing the "amd64" flavor for i386 without the xen/vserver flavors?  In
particular, I don't see any need for the xen flavor, wouldn't xen work just
fine with amd64 as the dom0 install and i386 in domX without any kernel
images installed in the domX?

> Additionally, I don't know in what state the current cross-build env for
> i386 is, and building 64bit kernels on i386 might produce
> abi-incompatible kernels causing even more problems.

As noted, it's not cross-building, this is treated as a native 64-bit build
by the compiler and the code path has been well-exercised by other packages.

> IMHO the best solution would be to repackage the amd64 debs into i386
> ones. This can be trivially done and should not cause any regressions.

> The "real" solution for this still is multiarch. I haven't heard much
> of it since a couple of months, is anyone still actively working on it?

Multiarch isn't really going anywhere for etch; HP seems to have thrown its
support behind a proposal for a nex-gen dpkg that munges packages
dynamically to support multiarch, which would be an etch+1 at best, and
momentum has fallen off for anything in the etch timeframe.

Building the i386 kernel debs from the amd64 ones seems to suffer from the
problems outlined in the rest of this thread.

In light of this, is enabling amd64 flavors for i386 an option, or not?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Francesco Poli]

On Tue, 31 Oct 2006 23:59:18 +0100 Sven Luther wrote:

[...]
> Nope, because you can ship the source code and the object file if you
> wanted.
> 
> Already now, major parts of debian/main are not cleanly buildable out
> of the box, due to cyclic bootstraping dependencies.

But those major parts of debian/main are cleanly buildable using an
already functioning installation of debian/main, aren't they?
At least I *hope* those major parts are buildable using only packages
from debian/main, otherwise they would Build-Depend on out-of-main
components, which is a Policy violation for a package in main, AFAIK.

If what I have just said is true and confirmed, then *that* is the
difference: one thing is having cyclic bootstrapping dependencies that
make an already compiled and installed system necessary, a completely
different beast is something that needs an out-of-main compiler in order
to be compiled...


Or am I completely off track?!?


P.S.: I begin to doubt that each recipient still needs to be Cc:ed. 
Anyone who would like to be dropped from the Cc: list, please tell me!

-- 
But it is also tradition that times *must* and always
do change, my friend.   -- from _Coming to America_
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp00V3eej5DU.pgp
Description: PGP signature

Bug#379090: Still no news on 64bit i386 kernels

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow ([EMAIL PROTECTED]) [061031 15:01]:
>> Frederik Schueler <[EMAIL PROTECTED]> writes:
>> I asked this before and haven't yet recieved an answere:
>> 
>> What does w-b do when the amd64 build uploads amd64+i386 64bit kernel
>> debs but not 32bit. Afaik the package should be detected as incomplete
>> and set to "needs-build" for i386. i386 then builds the 32bit kernels
>> only and uploads them.
>
> As soon as there are binary packages for i386, wanna-build marks i386 as
> installed. How should it detect otherwise if e.g. a kernel was dropped?

Because the Binary field in Sources does list the packages and P-a-s
does not specificaly exclude them. (or for your second part, because
the kernel drops from Binary:).

I haven't tested this but that is what the lines listing binaries (not
%source entries) in P-a-s are for or not? To tell w-b that an arch
does not build those debs and it should not miss them.

Did you test it with some dummy packages and source?

>> > The "real" solution for this still is multiarch. I haven't heard much
>> > of it since a couple of months, is anyone still actively working on it?
>> 
>> Which means, at a minimum, changes to debian-cd and D-I to include the
>> amd64 packages on i386 and the linux64 boot option and a wrapper
>> package for apt/aptitude/dpkg to make the amd64 debs appear and
>> installable.
>
> Which won't happen anyways for etch.

Why? A new source can still make it to etch, right? The D-I change is
adding one entry in the isolinux.cfg and debian-cd can still be
modified or not?

Worst case we just have the wrapper and you can only install 64bit
kernel from the network (after installing the wrapper).

> Cheers,
> Andi


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

Re: Schedule for linux-2.6 2.6.18-4

[Otavio Salvador]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

>> I think xen or vserver are the perfect environment to have both worlds
>> live on the same machine. :)
>
> Then try that and make sure the hypervisor has no 32/64 bit
> problems.

I use mixed environment on the company server. We have 32 and 64 bit
environment on same hardware running on Xen 3.0.3 with kernel 2.6.18
with no problem.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

Bug#396471: linux-image-2.6.18-1-parisc64-smp: fails to install

[Sven Luther]

On Tue, Oct 31, 2006 at 11:54:09PM +0100, Frans Pop wrote:
> Package: linux-image-2.6.18-1-parisc64-smp
> Version: 2.6.18-3
> Severity: serious
> 
> This issue has been reported several times before, but I've not yet seen 
> any real response from the kernel team.
> 
> Preconfiguring packages ...
> Selecting previously deselected package linux-image-2.6.18-1-parisc64-smp.
> (Reading database ... 28539 files and directories currently installed.)
> Unpacking linux-image-2.6.18-1-parisc64-smp 
> (from .../linux-image-2.6.18-1-parisc64-smp_2.6.18-3_hppa.deb) ...
> Done.
> Selecting previously deselected package linux-image-2.6-parisc64-smp.
> Unpacking linux-image-2.6-parisc64-smp 
> (from .../linux-image-2.6-parisc64-smp_2.6.18+3_hppa.deb) ...
> Setting up linux-image-2.6.18-1-parisc64-smp (2.6.18-3) ...
> 
>  Hmm. The package shipped with a symbolic 
> link /lib/modules/2.6.18-1-parisc64-smp/source
>  However, I can not read the target: No such file or directory
>  Therefore, I am deleting /lib/modules/2.6.18-1-parisc64-smp/source
> 
> Running depmod.
> Finding valid ramdisk creators.
> Using mkinitramfs-kpkg to build the ramdisk.
> Other valid candidates: mkinitramfs-kpkg mkinitrd.yaird
> Missing Required paramater 'Old' 
> at /var/lib/dpkg/info/linux-image-2.6.18-1-parisc64-smp.postinst line 

Thanks Frans for pointing out this bug, which is exactly the same we already
had some discussion a few weeks ago when it was discovered in the powerpc
packages, and where i was flammed by you and Manoj. Another occasion where you
do exactly the things you are continuously reproaching me. I hope you remember
that next time you want to write some bashing of me in bug reports.

This bug is closed by the new kernel-package version, and linux-2.6 only needs
to be rebuilt with it, which is scheduled for -4, and amply discussed here
previously.

Friendly,

Sven Luther


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

Bug#298972: Announce of an upcoming l10n update for the mkvmlinuz package

[Christian Perrier]

Dear maintainer of mkvmlinuz and Debian translators,

On 31 oct 2006 I sent a notice to the maintainer of the mkvmlinuz Debian
package, mentioning the status of at least one old po-debconf translation 
update in the BTS (bug #298972).

I announced the intent to build and possibly upload a non-maintainer upload
for this package in order to fix this long-time pending localization
bug as well as all other pending translations.

The package maintainer, Sven Luther (and the kernel team) suggested
that I work in the package SVN and notify him when the package is
ready for upload. Which is what I'll do

The package is currently translated to: sv

The following translations are incomplete: sv
   (even after applying pending l10n bugs, of course)

If you did any of the, currently incomplete, translations you will get a
copy of this announcement BCCd to you. Please review the translation.

Other translators also have the opportunity to create new translations for
this package. Once completed, please send them directly to me so I can
incorporate them into the package being built.

The deadline for receiving updates and new translations is 07 nov 2006. If you
are not in time you can always send your translation to the BTS.

You can download the pot, and any po, files from:

  http://people.debian.org/~lwall/i18n/pots/mkvmlinuz




signature.asc
Description: Digital signature

Processed: Re: Bug#396458: powerpc d-i miboot floppy doesn't boot

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 396458 debian-installer
Bug#396458: powerpc d-i miboot floppy doesn't boot
Bug reassigned from package `linux-2.6' to `debian-installer'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#396458: powerpc d-i miboot floppy doesn't boot

[Sven Luther]

reassign 396458 debian-installer
thanks
On Tue, Oct 31, 2006 at 11:16:24PM +0100, Frans Pop wrote:
> severity 396458 important
> tags 396458 patch
> thanks
> 
> On Tuesday 31 October 2006 22:08, rob rob wrote:
> > While investigating that problem Benjamin Herrenschmidt sent this
> > interesting mail with a patch, which may solve the problem:
> > http://lists.debian.org/debian-powerpc/2006/09/msg00337.html
> 
> That patch looks like it is a patch to the powerpc kernel images, not to 
> debian installer, therefore reassigning.

Frans, with all your lecturing to check a bit before commenting, i would have
hoped you would do so yourself.

The part of the kernel patched by this patch is totally unused in debian, it
is moved into mkvmlinuz, but even then, it is not used in debian-installer,
since the miboot images build code is not using mkvmlinuz since a year or so.

I even commented to this effect in a direct followup to the mail benh wrote
with the patch :

  http://lists.debian.org/debian-powerpc/2006/09/msg00338.html

So you really have no excuse for doing such sloppy work, and i expect you to
be more humble when you comment about similar error i may make in the future.

Friendly,

Sven Luther


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

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Sven Luther]

On Tue, Oct 31, 2006 at 09:06:50PM +0100, Ola Lundqvist wrote:
> Hi Sven
> 
> On Tue, Oct 31, 2006 at 07:32:02PM +0100, Sven Luther wrote:
> ...CUT...
> > > Will all reverse engineered drivers with hardcoded values be considered
> > > as closed source? Must you always release everything that you know
> > > when you release somehting as open source?
> > > Must we release the instructions on how to paint an image, how to
> > > move the arm while painting if we release an image as open source?
> > > 
> > > I think this is worth considering. Personally I think this bug can
> > > be closed.
> > 
> > But your thinking are giving us an excellent way out. We could simply take 
> > all
> > those binary blobs that are in the kernel, and try to take a guess about the
> > instruction set which they are designed for, and disasemble them, and 
> > provide
> > the dissasembled version under the GPL, as well as a instructions to
> > re-assemble them into the actual binary blob.
> > 
> > If we were to achieve that, i would be more than happy to consider these 
> > blobs
> > and their corresponding reverse-engineered asm codes as actual source.
> > 
> > One may argue that in this case, the actual documentation of the registers
> > may be more of a source for such binary blobs, but it would in any case be 
> > no
> > worse than any other reverse-engineering effort out there.
> 
> I fully agree that this kind of work would be a good thing. Such
> improvements would most problably be a benifit for the open source
> community and maybe would give us better functionality in the end.

Patches are welcome :)

> The question is if it is a violation or not to release as is.

I doubt that there is any more sense in (re-)discussing this.

> The other good (or bad?) thing is that we would need cross-compilers
> for most major instruction-sets as reassembling probably mean compiling
> for a different architecture.

Nope, because you can ship the source code and the object file if you wanted.

Already now, major parts of debian/main are not cleanly buildable out of the
box, due to cyclic bootstraping dependencies.

Friendly,

Sven Luther


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

Re: Schedule for linux-2.6 2.6.18-4

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow ([EMAIL PROTECTED]) [061031 17:31]:
>> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> > Andreas Barth <[EMAIL PROTECTED]> writes:
>> >> Can we also have amd64-kernels again on i386?
>> >>
>> >>
>> >> Cheers,
>> >> Andi
>> >
>> > The patch is in the BTS and quite small. About 5 lines of code change
>> > and the obvious ton of .config files.
>> 
>> Replying to myself, juhey. Sorry for breaking the threading.
>> 
>> Could we have one of these compromises?
>> 
>> 1) Apply the patch and set the config but keep the actual images
>> commented out.
>> 
>> 2) Do 1 and enable one generic 64bit image. No xen, no vserver.
>> 
>> Or is even one more images too much?
>
> I think xen or vserver are the perfect environment to have both worlds
> live on the same machine. :)

Then try that and make sure the hypervisor has no 32/64 bit
problems.

> Cheers,
> Andi

MfG
Goswin


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

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Francesco Poli]

On Tue, 31 Oct 2006 16:26:38 + Matthew Garrett wrote:

> On Tue, Oct 31, 2006 at 05:00:15PM +0100, Ola Lundqvist wrote:
> 
> (Anyone on debian-legal: please note and maintain the Cc:s)

Including the From: field (that is you) and the To: field (that is Ola
Lundqvist)?  Let's assume the answer is yes...

[...]
> > The only requirement on the original author (as I can determine) is
> > that you get source code for it, not that it is in preferred form
> > for making modification.
> 
> That's perfectly acceptable. Upstream can do whatever they want. 
> However, if upstream do not provide the preferred form for
> modification  (ie, the unobfuscated version), Debian can not
> distribute it under the  terms of the GPL.

Exactly.

> 
> That's not an issue in this case, since X is not a GPLed application. 
> Debian can distribute the obfuscated code entirely legally, without 
> violating any licenses. The issue is whether "source" in the DFSG
> refers  to the GPL's definition ("the preferred form for
> modification") or not.

IMHO, DFSG#2 refers to source code, as is usually defined, that is to
say, as in the GNU GPL v2.

> An alternative interpretation could be "a form
> amenable to modification  by people sufficiently familiar with the
> work".

I think that this would be too vague a definition.
The term "amenable" could be interpreted in a too broad sense and this
would become a slippery slope: someone sufficiently familiar with a
program could succeed in modifying its binary executable using a hex
editor, but (at least in most cases) he/she would *prefer* to make
modifications to the C code (assuming that the program is actually
written in C).

> 
> If people define source as "the preferred form for modifications" in
> all  cases, then there's no place for deliberately obfuscated code in
> Debian.

Yeah, and that's a feature, not a bug!!
Deliberately obfuscated code is absolutely against the spirit of Free
Software.

> There's also arguably no place for works that are only
> available  as JPEGs, any flattened image formats, mp3s, PDFs and so
> on.

Not necessarily.  It depends on which is the "preferred form for
modifications": this can only be determined on a case-by-case basis.
For some works the "preferred form for modifications" may be in JPEG
format (think of photographs taken with a digital camera); for some
other the "preferred form" may be some other format (from which the JPEG
is generated).

Please note that the same situation holds for programmatic works: for
some programs the "preferred form for modifications" may be assembly
code (or even machine code); for some other the "preferred form" may be,
say, C code; for some other it could be a grammar definition (think
about tools that generate C code for a parser of a given grammar: bison
comes to mind).

> Right now  there doesn't seem to be a strong opinion in the
> project about that, but  I expect it's a discussion that needs to be
> had.

IMO, this discussion desperately needs to be had.  I think the right
time to have it is after etch is out.



-- 
But it is also tradition that times *must* and always
do change, my friend.   -- from _Coming to America_
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpDBvlY1wcPy.pgp
Description: PGP signature

Bug#396471: linux-image-2.6.18-1-parisc64-smp: fails to install

[Frans Pop]

Package: linux-image-2.6.18-1-parisc64-smp
Version: 2.6.18-3
Severity: serious

This issue has been reported several times before, but I've not yet seen 
any real response from the kernel team.

Preconfiguring packages ...
Selecting previously deselected package linux-image-2.6.18-1-parisc64-smp.
(Reading database ... 28539 files and directories currently installed.)
Unpacking linux-image-2.6.18-1-parisc64-smp 
(from .../linux-image-2.6.18-1-parisc64-smp_2.6.18-3_hppa.deb) ...
Done.
Selecting previously deselected package linux-image-2.6-parisc64-smp.
Unpacking linux-image-2.6-parisc64-smp 
(from .../linux-image-2.6-parisc64-smp_2.6.18+3_hppa.deb) ...
Setting up linux-image-2.6.18-1-parisc64-smp (2.6.18-3) ...

 Hmm. The package shipped with a symbolic 
link /lib/modules/2.6.18-1-parisc64-smp/source
 However, I can not read the target: No such file or directory
 Therefore, I am deleting /lib/modules/2.6.18-1-parisc64-smp/source

Running depmod.
Finding valid ramdisk creators.
Using mkinitramfs-kpkg to build the ramdisk.
Other valid candidates: mkinitramfs-kpkg mkinitrd.yaird
Missing Required paramater 'Old' 
at /var/lib/dpkg/info/linux-image-2.6.18-1-parisc64-smp.postinst line 
393.
dpkg: error processing linux-image-2.6.18-1-parisc64-smp (--configure):
 subprocess post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of 
linux-image-2.6-parisc64-smp:
 linux-image-2.6-parisc64-smp depends on 
linux-image-2.6.18-1-parisc64-smp; however:
  Package linux-image-2.6.18-1-parisc64-smp is not configured yet.
dpkg: error processing linux-image-2.6-parisc64-smp (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-2.6.18-1-parisc64-smp
 linux-image-2.6-parisc64-smp
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up linux-image-2.6.18-1-parisc64-smp (2.6.18-3) ...
Running depmod.
Finding valid ramdisk creators.
Using mkinitramfs-kpkg to build the ramdisk.
Other valid candidates: mkinitramfs-kpkg mkinitrd.yaird
Missing Required paramater 'Old' 
at /var/lib/dpkg/info/linux-image-2.6.18-1-parisc64-smp.postinst line 
393.
dpkg: error processing linux-image-2.6.18-1-parisc64-smp (--configure):
 subprocess post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of 
linux-image-2.6-parisc64-smp:
 linux-image-2.6-parisc64-smp depends on 
linux-image-2.6.18-1-parisc64-smp; however:
  Package linux-image-2.6.18-1-parisc64-smp is not configured yet.
dpkg: error processing linux-image-2.6-parisc64-smp (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-2.6.18-1-parisc64-smp
 linux-image-2.6-parisc64-smp
Press return to continue.


pgpDW3ToEhbOH.pgp
Description: PGP signature

Processed: Re: Bug#396458: powerpc d-i miboot floppy doesn't boot

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 396458 linux-2.6
Bug#396458: powerpc d-i miboot floppy doesn't boot
Bug reassigned from package `kernel-image-2.6.17-2-powerpc-miboot-di' to 
`linux-2.6'.

> severity 396458 important
Bug#396458: powerpc d-i miboot floppy doesn't boot
Severity set to `important' from `normal'

> tags 396458 patch
Bug#396458: powerpc d-i miboot floppy doesn't boot
There were no tags set.
Tags added: patch

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Schedule for linux-2.6 2.6.18-4

[Christian T. Steigies]

On Tue, Oct 31, 2006 at 05:26:28PM +0100, Goswin von Brederlow wrote:
> Bastian Blank <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Oct 31, 2006 at 02:13:33PM +0100, Goswin von Brederlow wrote:
> >> So what if it takes a bit longer and takes a bit more disk space? Try
> >> building on m68k. :)
> >
> > Ask cts, it takes less. Especialy as m68k currently builds only two
> > images.
> >
> > Bastian
> 
> He cross-compiles on a fast system.

Yes, "he" does, although "he" would not call it a fast system, unless "he" 
builds
on an amd64...

> Without that I think it is around 6 hours per image.

I think with 2.6 that went up to 8h, it was 6h with 2.4. Cross-building
takes about an hour or so on a PIV, so an insignificant amount of time.

Anyway, there are a few m68k patches out for atari (which we do not build
currently) which are not yet in svn. Also at least my mac could use some
fixes for the network hardware, but those still have to be written, which
will probably take a few more weeks. I would prefer to get that all in in
2.6.19, which makes patch handling easier for me. Plus I have no time to
work on this at least until saturday, and that day is reserved for doubling
the speed of our two fastest m68k buildds.

Christian


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

Re: Bug#396458: powerpc d-i miboot floppy doesn't boot

[Frans Pop]

reassign 396458 linux-2.6
severity 396458 important
tags 396458 patch
thanks

On Tuesday 31 October 2006 22:08, rob rob wrote:
> While investigating that problem Benjamin Herrenschmidt sent this
> interesting mail with a patch, which may solve the problem:
> http://lists.debian.org/debian-powerpc/2006/09/msg00337.html

That patch looks like it is a patch to the powerpc kernel images, not to 
debian installer, therefore reassigning.

Cheers,
FJP


pgpAaZJVnQnDv.pgp
Description: PGP signature

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Ola Lundqvist]

Hi Sven

On Tue, Oct 31, 2006 at 07:32:02PM +0100, Sven Luther wrote:
...CUT...
> > Will all reverse engineered drivers with hardcoded values be considered
> > as closed source? Must you always release everything that you know
> > when you release somehting as open source?
> > Must we release the instructions on how to paint an image, how to
> > move the arm while painting if we release an image as open source?
> > 
> > I think this is worth considering. Personally I think this bug can
> > be closed.
> 
> But your thinking are giving us an excellent way out. We could simply take all
> those binary blobs that are in the kernel, and try to take a guess about the
> instruction set which they are designed for, and disasemble them, and provide
> the dissasembled version under the GPL, as well as a instructions to
> re-assemble them into the actual binary blob.
> 
> If we were to achieve that, i would be more than happy to consider these blobs
> and their corresponding reverse-engineered asm codes as actual source.
> 
> One may argue that in this case, the actual documentation of the registers
> may be more of a source for such binary blobs, but it would in any case be no
> worse than any other reverse-engineering effort out there.

I fully agree that this kind of work would be a good thing. Such
improvements would most problably be a benifit for the open source
community and maybe would give us better functionality in the end.

The question is if it is a violation or not to release as is.

The other good (or bad?) thing is that we would need cross-compilers
for most major instruction-sets as reassembling probably mean compiling
for a different architecture.

Regards,

// Ola

> Friendly,
> 
> Sven Luther
> 

-- 
 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering 
/  [EMAIL PROTECTED]   Annebergsslingan 37\
|  [EMAIL PROTECTED]   654 65 KARLSTAD|
|  http://opalsys.net/   Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---


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

Bug#396375: linux-image-2.6.18-1-k7: 2.6.18 breaks usb-storage for UCR-61S2 device

[Alexandre Pereira Nunes]

Thanks Alexandre,
 Do you have a poitner to where upstream was notified?

 

A description of the problem has been posted on the 
linux-usb-devel@lists.sourceforge.net mailing list, and to Phil Dibowitz 
and Alan Stern, which are supposed to be the maintainers of the 
usb-storage unusual device list.


- Alexandre




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

Bug#396375: linux-image-2.6.18-1-k7: 2.6.18 breaks usb-storage for UCR-61S2 device

[dann frazier]

On Tue, Oct 31, 2006 at 02:09:28PM -0300, Alexandre Pereira Nunes wrote:
> 
> >Thanks Alexandre,
> > Do you have a poitner to where upstream was notified?
> >
> > 
> A description of the problem has been posted on the 
> linux-usb-devel@lists.sourceforge.net mailing list, and to Phil Dibowitz and 
> Alan Stern, which are 
> supposed to be the maintainers of the usb-storage unusual device list.

Do you have a direct link to the archives? I couldn't find anything
when searching for your name or UCR-61S2.

The reason I ask is that we need to have high confidence this is going
upstream before including it:
  http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

-- 
dann frazier



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

Bug#396422: linux-image-2.6.18-1-686: lilo not started on upgrade

[Jens Seidel]

Package: linux-image-2.6.18-1-686
Version: 2.6.18-3
Severity: normal

Hi,

upgrading 2.6.18-2 to 2.6.18-3 results in an unbootable system. Calling
lilo fixes it.

Jens

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.18-1-686 depends on:
ii  initramfs-tools [linux-initra 0.84   tools for generating an initramfs
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo

Versions of packages linux-image-2.6.18-1-686 recommends:
ii  libc6-i686   2.3.6.ds1-4 GNU C Library: Shared libraries [i

-- debconf information:
  linux-image-2.6.18-1-686/postinst/bootloader-error-2.6.18-1-686:
  linux-image-2.6.18-1-686/postinst/depmod-error-initrd-2.6.18-1-686: false
  linux-image-2.6.18-1-686/preinst/initrd-2.6.18-1-686:
  linux-image-2.6.18-1-686/preinst/elilo-initrd-2.6.18-1-686: true
  linux-image-2.6.18-1-686/preinst/abort-overwrite-2.6.18-1-686:
* linux-image-2.6.18-1-686/preinst/already-running-this-2.6.18-1-686:
  linux-image-2.6.18-1-686/postinst/bootloader-test-error-2.6.18-1-686:
  linux-image-2.6.18-1-686/postinst/depmod-error-2.6.18-1-686: false
  linux-image-2.6.18-1-686/preinst/lilo-initrd-2.6.18-1-686: true
  linux-image-2.6.18-1-686/prerm/removing-running-kernel-2.6.18-1-686: true
  linux-image-2.6.18-1-686/postinst/old-system-map-link-2.6.18-1-686: true
  linux-image-2.6.18-1-686/preinst/bootloader-initrd-2.6.18-1-686: true
  linux-image-2.6.18-1-686/preinst/abort-install-2.6.18-1-686:
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.18-1-686/postinst/create-kimage-link-2.6.18-1-686: true
  linux-image-2.6.18-1-686/postinst/old-initrd-link-2.6.18-1-686: true
  linux-image-2.6.18-1-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-1-686/postinst/old-dir-initrd-link-2.6.18-1-686: true
  linux-image-2.6.18-1-686/preinst/overwriting-modules-2.6.18-1-686: true
  linux-image-2.6.18-1-686/preinst/failed-to-move-modules-2.6.18-1-686:
  linux-image-2.6.18-1-686/prerm/would-invalidate-boot-loader-2.6.18-1-686: true
  linux-image-2.6.18-1-686/postinst/kimage-is-a-directory:


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

Bug#396375: linux-image-2.6.18-1-k7: 2.6.18 breaks usb-storage for UCR-61S2 device

[dann frazier]

On Tue, Oct 31, 2006 at 01:34:21PM -0300, Alexandre Pereira Nunes wrote:
> Package: linux-image-2.6.18-1-k7
> Version: 2.6.18-3
> Severity: important
> Tags: patch
> 
> 
> Linux 2.6.18 introduces a conservative change that restricts the UCR-61S2
> initialization fix to only a specific version of the firmware, but older
> versions needs that as well. The supplied patch reverses that behaviour.
> 
> Upstream was notified, but in the meanwhile it would be interesting to
> provide this fix on debian.

Thanks Alexandre,
  Do you have a poitner to where upstream was notified?

-- 
dann frazier



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

Bug#396375: linux-image-2.6.18-1-k7: 2.6.18 breaks usb-storage for UCR-61S2 device

[Alexandre Pereira Nunes]

dann frazier escreveu:


On Tue, Oct 31, 2006 at 02:09:28PM -0300, Alexandre Pereira Nunes wrote:
 


Thanks Alexandre,
Do you have a poitner to where upstream was notified?


 

A description of the problem has been posted on the linux-usb-devel@lists.sourceforge.net mailing list, and to Phil Dibowitz and Alan Stern, which are 
supposed to be the maintainers of the usb-storage unusual device list.
   



Do you have a direct link to the archives? I couldn't find anything
when searching for your name or UCR-61S2.

The reason I ask is that we need to have high confidence this is going
upstream before including it:
 http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

 



It seems like sourceforge archive is lagging behind. The post can be 
read here:


http://marc.theaimsgroup.com/?l=linux-usb-devel&m=116230631107331&w=2

But I do believe we have to wait for maintainer's position before 
proceding. If I have any news about that I'll update this bug report


Thanks!

Alexandre



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

Processed: tagging 394697

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.9.22
> tags 394697 pending
Bug#394697: linux-image-2.6.18-1-sparc32: oops in sysfs file open on boot, root 
mount impossible
There were no tags set.
Tags added: pending

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Matthew Garrett]

On Tue, Oct 31, 2006 at 05:00:15PM +0100, Ola Lundqvist wrote:

(Anyone on debian-legal: please note and maintain the Cc:s)

> As you say you need the prefered form of _modification_, which means
> that if we change things, we are not allowed to obfuscate it. I can not
> see anything that enfoce the original author to actually do such
> obfuscation.

No, the preferred form *for* modification. 

> The only requirement on the original author (as I can determine) is that
> you get source code for it, not that it is in preferred form for making
> modification.

That's perfectly acceptable. Upstream can do whatever they want. 
However, if upstream do not provide the preferred form for modification 
(ie, the unobfuscated version), Debian can not distribute it under the 
terms of the GPL.

That's not an issue in this case, since X is not a GPLed application. 
Debian can distribute the obfuscated code entirely legally, without 
violating any licenses. The issue is whether "source" in the DFSG refers 
to the GPL's definition ("the preferred form for modification") or not. 
An alternative interpretation could be "a form amenable to modification 
by people sufficiently familiar with the work".

If people define source as "the preferred form for modifications" in all 
cases, then there's no place for deliberately obfuscated code in Debian. 
There's also arguably no place for works that are only available 
as JPEGs, any flattened image formats, mp3s, PDFs and so on. Right now 
there doesn't seem to be a strong opinion in the project about that, but 
I expect it's a discussion that needs to be had.

(For anyone doubting that the nvidia code is deliberately obfuscated - 
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/nv4driver.c.diff?r1=1.1.2.3&r2=1.1.2.4&hideattic=0&only_with_tag=xf-3_3_3
 
ought to make it pretty clear)
-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Bug#395069: initramfs-tools: post-installation fails when lilo and grub are both around and grub is configured as bootloader

[marcopar]

Package: initramfs-tools
Followup-For: Bug #395069


update-initramfs exits with code 1 during the update (-u) switch.
this causes failures installing every package that runs it in its
scripts (udev, linux-image-*, initramfs-tools...).

the error code is returned while executing run_bootloader().

my configuration has lilo and grub installed. so configuration files for
both bootloaders are in place. the system was installed with lilo and
then i switched to grub.

i've not deeply debbugged the script but it seems that the error is
caused wither by run_lilo or mbr_check. i did not saw any message from
lilo so probably the incriminated function is the latter.

after saying all these things the workaround is to remove lilo.

the real problem is that no information is given by the script, so it
can be difficult to track down what is causing the error.

HTH
ciao


-- Package-specific info:
-- /proc/cmdline
root=/dev/md2

-- /proc/filesystems
cramfs
ext3

-- lsmod
Module  Size  Used by
ppdev   8228  0 
lp 10432  0 
ipv6  217760  51 
nls_iso8859_1   3936  3 
cifs  181560  3 
nfs   188140  1 
lockd  53672  2 nfs
nfs_acl 3264  1 nfs
sunrpc132612  4 nfs,lockd,nfs_acl
dm_snapshot15324  0 
dm_mirror  17236  0 
dm_mod 47892  2 dm_snapshot,dm_mirror
i810_audio 31028  0 
ac97_codec 17004  1 i810_audio
mousedev   10368  1 
tsdev   7200  0 
snd_intel8x0   29436  0 
snd_ac97_codec 82784  1 snd_intel8x0
snd_ac97_bus2048  1 snd_ac97_codec
evdev   8736  1 
snd_mpu401  7232  0 
snd_mpu401_uart 6592  1 snd_mpu401
shpchp 39200  0 
pci_hotplug24180  1 shpchp
snd_pcm74408  2 snd_intel8x0,snd_ac97_codec
snd_timer  20292  1 snd_pcm
snd_rawmidi22048  1 snd_mpu401_uart
snd_seq_device  8236  1 snd_rawmidi
snd_page_alloc  9800  2 snd_intel8x0,snd_pcm
snd46080  8 
snd_intel8x0,snd_ac97_codec,snd_mpu401,snd_mpu401_uart,snd_pcm,snd_timer,snd_rawmidi,snd_seq_device
soundcore   8672  2 i810_audio,snd
floppy 55628  0 
irtty_sir   7488  0 
sir_dev16908  1 irtty_sir
irda  160956  2 irtty_sir,sir_dev
crc_ccitt   1952  1 irda
usblp  12096  0 
parport_pc 31472  1 
parport31720  3 ppdev,lp,parport_pc
sis_agp 8164  1 
agpgart29232  1 sis_agp
serio_raw   6436  0 
psmouse34248  0 
analog  9792  0 
pcspkr  2948  0 
gameport   13480  1 analog
rtc11252  0 
ext3  116008  2 
jbd46932  1 ext3
mbcache 7652  1 ext3
raid1  19264  3 
md_mod 63956  4 raid1
ide_generic 1120  0 [permanent]
ide_cd 35328  0 
cdrom  31888  1 ide_cd
usbhid 32128  1 
sis551311980  0 [permanent]
ide_disk   14528  8 
generic 4164  0 [permanent]
ehci_hcd   26856  0 
ohci_hcd   17252  0 
usbcore   110560  6 usblp,usbhid,ehci_hcd,ohci_hcd
sis900 20928  0 
mii 5056  1 sis900
hpt366 16544  0 [permanent]
ide_core  111440  6 
ide_generic,ide_cd,sis5513,ide_disk,generic,hpt366
thermal12968  0 
processor  21696  1 thermal
fan 4452  0 

-- kernel-img.conf
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = no


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages initramfs-tools depends on:
ii  busybox   1:1.1.3-3  Tiny utilities for small and embed
ii  cpio  2.6-17 GNU cpio -- a program to manage ar
ii  klibc-utils   1.4.27-1   small statically-linked utilities 
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo
ii  udev  0.100-2.2  /dev/ and hotplug management daemo

initramfs-tools recommends no packages.

-- no debconf information


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

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Ola Lundqvist]

Hi Goswin

Thanks for your response, and interesting new view (option C)
on this matter.

On Tue, Oct 31, 2006 at 02:20:44PM +0100, Goswin von Brederlow wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
...CUT...
> > Let me take two examples:
> > * Person A create a driver by reverse engineering, determine
> >   that by setting a number of memory parts to different values,
> >   the hardware will work as expected. Person A do not know why.
> > * Person B create a driver knowing, that by setting a number of
> >   memory parts to different values, the hardware will work as
> >   expected. Person B knows why.
> 
> * Person C creates a driver knowing with properly names defines and
> comments explaining why he does what and where to easily readable
> structures of the register mappings of the hardware. Person C then
> goes and obfuscates the code into putting seemingly random values into
> seemingly random addresses. Person C still uses his unobfuscated code
> to makes changes but only releases the obfuscated version under GPL.

Yes it is slightly different.

> > Both persons have released their code under the same license
> > and they look (almost at least) the same.
> >
> > Which one will break DFSG?
> >  - Person A?
> >  - Person B?
> >  - None?
> >  - Both?
> 
> Only C. But deciding if B or C applies it quite impossible.

Ok, you are probably right if the person use an automated tool to make
this obfuscation. (Not sure though, see below).

However as it is impossible to know if someone use a obfuscation program
or if the person use a text editor to edit this, I can not see it as
a violation anyway.

At least it is a bit harsh to see it as a policy violation just because
it may be obfuscated.

...CUT...

> > #2 Source Code
> > Source code is available. Not perfectly readable, but this is the
> > source that was released, and licensed away, so yes we have the source.
> 
> Under GPL (as in my example Person C) you need the prefered form of
> modification, which is more than what the DFSG strictly called
> for. But most people might take it as the same (meaning ofuscating is
> so evil it breaks this rule).

The only thing I can find in GPL about this is:
"The source code for a work means the preferred form of the work for making
modifications to it. For an executable work, complete source code means all
the source code for all modules it contains, plus any associated interface
definition files, plus the scripts used to control compilation and
installation of the executable."

But this is only applicable for the ones that distribute and
modify the code as it is listed under chapter 3.

As you say you need the prefered form of _modification_, which means
that if we change things, we are not allowed to obfuscate it. I can not
see anything that enfoce the original author to actually do such
obfuscation.

You can not ship something without source at all as the following
phrase exist in the GPL:

"Our General Public Licenses are designed to make sure that you have
the freedom to distribute copies of free software (and charge for this
service if you wish), that you receive source code or can get it if
you want it, that you can change the software or use pieces of it in
new free programs; and that you know you can do these things."

The only requirement on the original author (as I can determine) is that
you get source code for it, not that it is in preferred form for making
modification.

Or do I misinterpret the GPL?

...CUT...

Regards,

// Ola

-- 
 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering 
/  [EMAIL PROTECTED]   Annebergsslingan 37\
|  [EMAIL PROTECTED]   654 65 KARLSTAD|
|  http://opalsys.net/   Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---


signature.asc
Description: Digital signature

Bug#396402: linux-image-2.6.18-1-k7: Problem in USB storage but no active USB storage devices ...

[Francois]

Package: linux-image-2.6.18-1-k7
Version: 2.6.18-3
Severity: important


Hello,

While doing a disk copy from NFS to JFS on a SATA drive (80G worth) I got this 
kernel oops.
I have no USB storage devices present, although I have a USB multi-card reader 
without any card inserted.

Nothing critical but from what I understand Oopses are bad :-)

Regards

Francois

System description : 

Linux athlon 2.6.18-1-k7 #1 SMP Sat Oct 21 18:09:11 UTC 2006 i686 GNU/Linux

lsusb
Bus 004 Device 002: ID 046d:c024 Logitech, Inc.
Bus 004 Device 001: ID :
Bus 006 Device 001: ID :
Bus 005 Device 001: ID :
Bus 003 Device 001: ID :
Bus 002 Device 002: ID 182d:2140
Bus 002 Device 001: ID :
Bus 001 Device 001: ID :

Oct 31 15:06:41 localhost kernel: BUG: unable to handle kernel paging request 
at virtual address 46a6a023
Oct 31 15:06:41 localhost kernel:  printing eip:
Oct 31 15:06:41 localhost kernel: ecf88925
Oct 31 15:06:41 localhost kernel: *pde = 
Oct 31 15:06:41 localhost kernel: Oops:  [#1]
Oct 31 15:06:41 localhost kernel: SMP
Oct 31 15:06:41 localhost kernel: Modules linked in: jfs nfs nfsd exportfs 
lockd nfs_acl sunrpc ppdev lp autofs4 ipv6 dm
Oct 31 15:06:41 localhost kernel: CPU:0
Oct 31 15:06:41 localhost kernel: EIP:0060:[]Not tainted VLI
Oct 31 15:06:41 localhost kernel: EFLAGS: 00010286   (2.6.18-1-k7 #1)
Oct 31 15:06:41 localhost kernel: EIP is at 0xecf88925
Oct 31 15:06:41 localhost kernel: eax: 80118200   ebx: dfc56000   ecx: f88a495d 
  edx: 0010
Oct 31 15:06:41 localhost kernel: esi: c1998240   edi:    ebp: 001f 
  esp: c1953ec8
Oct 31 15:06:41 localhost kernel: ds: 007b   es: 007b   ss: 0068
Oct 31 15:06:41 localhost kernel: Process usb-storage (pid: 726, ti=c1952000 
task=c19af550 task.ti=c1952000)
Oct 31 15:06:41 localhost kernel: Stack: f888f1eb 0010 f88a495d 0003 
dfc56000 dfc8a2d8  001f
Oct 31 15:06:41 localhost kernel:f892f89d  0001 c1953ef4 
c1953ef4 dfc56000 dfc8a2d8 
Oct 31 15:06:41 localhost kernel:f892fc90 c0010200 0001 dfc9d00f 
dfc9c87e dfc9d015 dfc8a2d8 f8930416
Oct 31 15:06:41 localhost kernel: Call Trace:
Oct 31 15:06:41 localhost kernel:  [] usb_submit_urb+0x1c7/0x1eb 
[usbcore]
Oct 31 15:06:41 localhost kernel:  [] usb_stor_msg_common+0x91/0xe8 
[usb_storage]
Oct 31 15:06:41 localhost kernel:  [] 
usb_stor_bulk_transfer_buf+0x4f/0x7d [usb_storage]
Oct 31 15:06:41 localhost kernel:  [] 
usb_stor_Bulk_transport+0xf5/0x240 [usb_storage]
Oct 31 15:06:41 localhost kernel:  [] 
usb_stor_control_thread+0x0/0x189 [usb_storage]
Oct 31 15:06:41 localhost kernel:  [] 
usb_stor_invoke_transport+0x1b/0x296 [usb_storage]
Oct 31 15:06:41 localhost kernel:  [] __down_interruptible+0xff/0x111
Oct 31 15:06:41 localhost kernel:  [] default_wake_function+0x0/0xc
Oct 31 15:06:41 localhost kernel:  [] 
usb_stor_control_thread+0x0/0x189 [usb_storage]
Oct 31 15:06:41 localhost kernel:  [] 
usb_stor_control_thread+0x0/0x189 [usb_storage]
Oct 31 15:06:41 localhost kernel:  [] 
usb_stor_control_thread+0x10f/0x189 [usb_storage]
Oct 31 15:06:41 localhost kernel:  [] complete+0x2b/0x3d
Oct 31 15:06:41 localhost kernel:  [] 
usb_stor_control_thread+0x0/0x189 [usb_storage]
Oct 31 15:06:41 localhost kernel:  [] kthread+0xc2/0xef
Oct 31 15:06:41 localhost kernel:  [] kthread+0x0/0xef
Oct 31 15:06:41 localhost kernel:  [] kernel_thread_helper+0x5/0xb
Oct 31 15:06:41 localhost kernel: Code: 6d d5 9a f9 b7 5d 84 29 15 dd 2c c4 36 
13 69 e9 57 bb 1d 0f c3 e6 8a 02 70 ef c6
Oct 31 15:06:41 localhost kernel: EIP: [] 0xecf88925 SS:ESP 
0068:c1953ec8


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages linux-image-2.6.18-1-k7 depends on:
ii  initramfs-tools [linux-initra 0.84   tools for generating an initramfs
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo

Versions of packages linux-image-2.6.18-1-k7 recommends:
ii  libc6-i686   2.3.6.ds1-7 GNU C Library: Shared libraries [i

-- debconf information:
  linux-image-2.6.18-1-k7/postinst/bootloader-test-error-2.6.18-1-k7:
  linux-image-2.6.18-1-k7/preinst/bootloader-initrd-2.6.18-1-k7: true
  linux-image-2.6.18-1-k7/postinst/create-kimage-link-2.6.18-1-k7: true
  linux-image-2.6.18-1-k7/postinst/depmod-error-initrd-2.6.18-1-k7: false
  linux-image-2.6.18-1-k7/postinst/kimage-is-a-directory:
  linux-image-2.6.18-1-k7/preinst/initrd-2.6.18-1-k7:
  linux-image-2.6.18-1-k7/prerm/would-invalidate-boot-loader-2.6.18-1-k7: true
  linux-image-2.6.18-1-k7/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-1-k7/preinst/abort-overwrite-2.6.18-1-k7:
  linux-image-2.6.18-1-k7/postinst/bootloader-error-2.6.18-1-k7:
  linux-image-2.6.18-1-k7/preinst/elilo-initrd-2.6.18-1-k7: true
  shared/kerne

Bug#394697: Fix for the oops on boot

[Meelis Roos]

Could you please try the kernel from [0]? It incorporates the patch
[1] (which is committed to debian-kernel svn), based on David Miller's
patch [2] for this problem, and boots fine in qemu.

[0] 
http://www.wooyd.org/debian/kernels/linux-image-2.6.18-1-sparc32_2.6.18-4_sparc.deb


This works on real SS5 too, thanks!

--
Meelis Roos ([EMAIL PROTECTED])


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

Bug#379090: Still no news on 64bit i386 kernels

[Goswin von Brederlow]

Frederik Schueler <[EMAIL PROTECTED]> writes:

> Hello,
>
> On Tue, Oct 31, 2006 at 01:30:59AM -0800, Steve Langasek wrote:
>> Can someone from the kernel team comment on whether there are problems with
>> this particular patch that have not yet been noted in the bug report?  If
>> there aren't any known objections, I could review the patch myself and look
>> at committing it.
>
> Adding amd64 as subarch to i386 would mean 3 additional flavors to
> build, raising the overall build-time of that package by 1.5-2h. 

And that is a problem?

> Additionally, I don't know in what state the current cross-build env for
> i386 is, and building 64bit kernels on i386 might produce
> abi-incompatible kernels causing even more problems.

They aren't exactly cross build. Just with -m64. This is supported
upstream in both kernel and gcc and it better not have abi
differences. It is also used in libc6, gcc, fakeroot, zlib1g and a
bunch of other packages during build.

The same method (but much less elegantly) was used in sarge and nobody
has reported problems there, have they? So I guess we can rule that out.

> IMHO the best solution would be to repackage the amd64 debs into i386
> ones. This can be trivially done and should not cause any regressions.

I asked this before and haven't yet recieved an answere:

What does w-b do when the amd64 build uploads amd64+i386 64bit kernel
debs but not 32bit. Afaik the package should be detected as incomplete
and set to "needs-build" for i386. i386 then builds the 32bit kernels
only and uploads them.

Unless someone is willing to test this technical aspect repackaging
seems out of question.

> The "real" solution for this still is multiarch. I haven't heard much
> of it since a couple of months, is anyone still actively working on it?

Which means, at a minimum, changes to debian-cd and D-I to include the
amd64 packages on i386 and the linux64 boot option and a wrapper
package for apt/aptitude/dpkg to make the amd64 debs appear and
installable.

If the patch for 64bit kernel won't get accepted I can upload the
wrapper package.

> Best regards
> Frederik Schueler

MfG
Goswin


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

Bug#396399: kernel-image-2.6.8-3-686: ipt_ULOG gives "error during NLMSG_PUT"

[Voxel User]

Package: kernel-image-2.6.8-3-686
Version: 2.6.8-16sarge5
Severity: normal

In the process of attempting to use the ULOG iptables target and ulogd,
I found that there is a problem with the ipt_ULOG module preventing it
from actually working. Any time a ULOG target rule is reached, the
following messages appear in the kernel message log:

ipt_ULOG: Error building netlink message
ipt_ULOG: error during NLMSG_PUT

After some searching, I found a solution to the problem at:

http://oss.sgi.com/archives/netdev/2004-10/msg01026.html

This includes a patch against net/ipv4/netfilter/ipt_ULOG.c that
correctly calculates the netlink message size, allowing the ULOG target
to function as designed.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-3-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages kernel-image-2.6.8-3-686 depends on:
ii  coreutils [fileutils] 5.2.1-2The GNU core utilities
ii  initrd-tools  0.1.81.1   tools to create initrd image for p
ii  module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo

-- no debconf information


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

Bug#375800: marked as done (linux-image-2.6.17-1-vserver-amd64-k8: gdb freezes system)

[Debian Bug Tracking System]

Your message dated Tue, 31 Oct 2006 15:23:52 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#375800: linux-image-2.6.17-1-vserver-amd64-k8: gdb freezes 
system
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: linux-image-2.6.17-1-vserver-amd64-k8
Severity: normal

When I run gdb, the system freezes immediately after starting the
program being debugged.

I experienced the same bug with an older 2.6.16-2-vserver-amd64-k8
kernel, but in 2.6.16-14 gdb works fine.

Regards,

Milan Zamazal


--- End Message ---
--- Begin Message ---
In linux-image-2.6.17-2-vserver-amd64 2.6.17-9 gdb works fine again.
--- End Message ---

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Goswin von Brederlow]

Ola Lundqvist <[EMAIL PROTECTED]> writes:

> Hi
>
> First I want to tell to you Kyle and Matthew, that this is not a personal
> thing against you, and that I have noted the question mark in the end of the
> subject ("Contains obfuscated source code, DFSG violation?"). I actually want
> to thank you for making me think on what my opinion about open source is.
>
> (I have decided to Cc debian-legal, but I'm not subscribed to that list
> so please CC me if you want me to read it).
>
> Now to the reason why I wrote this mail.
> I have a question about the bugreport (#383481) because I do not
> understand what the problem is. The source code is there, you can
> modify it and release it under the same license. Perfectly legal under GPL.
>
> Let me take two examples:
> * Person A create a driver by reverse engineering, determine
>   that by setting a number of memory parts to different values,
>   the hardware will work as expected. Person A do not know why.
> * Person B create a driver knowing, that by setting a number of
>   memory parts to different values, the hardware will work as
>   expected. Person B knows why.

* Person C creates a driver knowing with properly names defines and
comments explaining why he does what and where to easily readable
structures of the register mappings of the hardware. Person C then
goes and obfuscates the code into putting seemingly random values into
seemingly random addresses. Person C still uses his unobfuscated code
to makes changes but only releases the obfuscated version under GPL.

> Both persons have released their code under the same license
> and they look (almost at least) the same.
>
> Which one will break DFSG?
>  - Person A?
>  - Person B?
>  - None?
>  - Both?

Only C. But deciding if B or C applies it quite impossible.

> I'll take each item in DFSG and determine it from that points:
> -
> #1 Free Redistribution
> No restriction here.
>
> #2 Source Code
> Source code is available. Not perfectly readable, but this is the
> source that was released, and licensed away, so yes we have the source.

Under GPL (as in my example Person C) you need the prefered form of
modification, which is more than what the DFSG strictly called
for. But most people might take it as the same (meaning ofuscating is
so evil it breaks this rule).

> #3 Derived Works
> No restriction.
>
> #4 Integrity of The Author's Source Code
> No restriction, you can change as much as you want.
>
> #5 and 6 No Discrimination ...
> No discrimination on specific groups in the licsense.
>
> #7 Distribution of License
> No problem here.
>
> #8 License Must Not Be Specific to Debian
> No problem here.
>
> #9 License Must Not Contaminate Other Software
> No restriction here.
>
> #10 Example Licenses
> Just examples, and according to the DFSG, GPL is a fully ok license. 
> -

MfG
Goswin


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

Bug#379090: Still no news on 64bit i386 kernels

[Frederik Schueler]

Hello,

On Tue, Oct 31, 2006 at 01:30:59AM -0800, Steve Langasek wrote:
> Can someone from the kernel team comment on whether there are problems with
> this particular patch that have not yet been noted in the bug report?  If
> there aren't any known objections, I could review the patch myself and look
> at committing it.

Adding amd64 as subarch to i386 would mean 3 additional flavors to
build, raising the overall build-time of that package by 1.5-2h. 

Additionally, I don't know in what state the current cross-build env for
i386 is, and building 64bit kernels on i386 might produce
abi-incompatible kernels causing even more problems.

IMHO the best solution would be to repackage the amd64 debs into i386
ones. This can be trivially done and should not cause any regressions.

The "real" solution for this still is multiarch. I haven't heard much
of it since a couple of months, is anyone still actively working on it?

Best regards
Frederik Schueler


signature.asc
Description: Digital signature

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Ola Lundqvist]

Hi Mathew

(Anyone on debian-legal: please note and maintain the Cc:s)

On Tue, Oct 31, 2006 at 04:26:38PM +, Matthew Garrett wrote:
> On Tue, Oct 31, 2006 at 05:00:15PM +0100, Ola Lundqvist wrote:
> 
> (Anyone on debian-legal: please note and maintain the Cc:s)
> 
> > As you say you need the prefered form of _modification_, which means
> > that if we change things, we are not allowed to obfuscate it. I can not
> > see anything that enfoce the original author to actually do such
> > obfuscation.
> 
> No, the preferred form *for* modification. 

Hmm, you may be right.

> > The only requirement on the original author (as I can determine) is that
> > you get source code for it, not that it is in preferred form for making
> > modification.
> 
> That's perfectly acceptable. Upstream can do whatever they want. 
> However, if upstream do not provide the preferred form for modification 
> (ie, the unobfuscated version), Debian can not distribute it under the 
> terms of the GPL.

True. But do this mean that Nvidia have actually violated the license that
they have released their software under? Well maybe not as they may not
need to accept the license to actually use their rights...

As I understand from this, is that it is not enough to know that the software
is licensed under GPL, we must also check every single line of code (manually)
to determine if it is obfuscated or not before we include it into
Debian? Or should we just do this on a best effort basis, that is
file serious bugs when we encounter this.

> That's not an issue in this case, since X is not a GPLed application. 

The bug I'm referring to is actually on linux-2.6 and not on X. :) The
original bug was on X though.

> Debian can distribute the obfuscated code entirely legally, without 
> violating any licenses. The issue is whether "source" in the DFSG refers 
> to the GPL's definition ("the preferred form for modification") or not. 
> An alternative interpretation could be "a form amenable to modification 
> by people sufficiently familiar with the work".
> 
> If people define source as "the preferred form for modifications" in all 
> cases, then there's no place for deliberately obfuscated code in Debian.

That is what the Open Source Definition tell. The open source definition
is only applicable on programs though. But we do not enforce the usage
of the open source definition as far as I know. Or do we?

http://www.opensource.org/docs/definition.php

> There's also arguably no place for works that are only available 
> as JPEGs, any flattened image formats, mp3s, PDFs and so on. Right now 
> there doesn't seem to be a strong opinion in the project about that, but 
> I expect it's a discussion that needs to be had.

True. The positional statement that clarified was not the winner in one
of our votes:
http://www.debian.org/vote/2006/vote_004

> (For anyone doubting that the nvidia code is deliberately obfuscated - 
> http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/nv4driver.c.diff?r1=1.1.2.3&r2=1.1.2.4&hideattic=0&only_with_tag=xf-3_3_3
>  
> ought to make it pretty clear)

I may be stupid ( :) ) but I can only see that the code is not trivially
easy to read (on either sides). I do not know who did this change
and so on. I can see that the older one is slightly easier to read
on some areas, but that is all I can tell (as I'm not that familiar
with this source). :)

Best regards,

// Ola

> -- 
> Matthew Garrett | [EMAIL PROTECTED]
> 

-- 
 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering 
/  [EMAIL PROTECTED]   Annebergsslingan 37\
|  [EMAIL PROTECTED]   654 65 KARLSTAD|
|  http://opalsys.net/   Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---


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

Bug#379090: Still no news on 64bit i386 kernels

[Andreas Barth]

* Goswin von Brederlow ([EMAIL PROTECTED]) [061031 15:01]:
> Frederik Schueler <[EMAIL PROTECTED]> writes:
> I asked this before and haven't yet recieved an answere:
> 
> What does w-b do when the amd64 build uploads amd64+i386 64bit kernel
> debs but not 32bit. Afaik the package should be detected as incomplete
> and set to "needs-build" for i386. i386 then builds the 32bit kernels
> only and uploads them.

As soon as there are binary packages for i386, wanna-build marks i386 as
installed. How should it detect otherwise if e.g. a kernel was dropped?

> > The "real" solution for this still is multiarch. I haven't heard much
> > of it since a couple of months, is anyone still actively working on it?
> 
> Which means, at a minimum, changes to debian-cd and D-I to include the
> amd64 packages on i386 and the linux64 boot option and a wrapper
> package for apt/aptitude/dpkg to make the amd64 debs appear and
> installable.

Which won't happen anyways for etch.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Schedule for linux-2.6 2.6.18-4

[Andreas Barth]

* Goswin von Brederlow ([EMAIL PROTECTED]) [061031 17:31]:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> > Andreas Barth <[EMAIL PROTECTED]> writes:
> >> Can we also have amd64-kernels again on i386?
> >>
> >>
> >> Cheers,
> >> Andi
> >
> > The patch is in the BTS and quite small. About 5 lines of code change
> > and the obvious ton of .config files.
> 
> Replying to myself, juhey. Sorry for breaking the threading.
> 
> Could we have one of these compromises?
> 
> 1) Apply the patch and set the config but keep the actual images
> commented out.
> 
> 2) Do 1 and enable one generic 64bit image. No xen, no vserver.
> 
> Or is even one more images too much?

I think xen or vserver are the perfect environment to have both worlds
live on the same machine. :)


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: What to do with the very old bugs? [Was: Re: Bug#265831: Obsolete bugreports for 2.4]

[dann frazier]

On Tue, Oct 31, 2006 at 08:36:03AM +0100, Sven Luther wrote:
> I think it is right to ping the submitter, and give him, let's say a month or
> so to come back, before completely dismissing him. I have been doing so with
> the older powerpc bugs. And i got a reply or two if i remember well.

And make sure to e-mail [EMAIL PROTECTED] and not just
the bug report itself to make sure a message hits the filer.

-- 
dann frazier


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

Bug#396375: linux-image-2.6.18-1-k7: 2.6.18 breaks usb-storage for UCR-61S2 device

[dann frazier]

forwarded 396375 
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=116230631107331&w=2
tag 396375 + upstream
stop

On Tue, Oct 31, 2006 at 03:06:36PM -0300, Alexandre Pereira Nunes wrote:
> It seems like sourceforge archive is lagging behind. 

No surprise there :(

> The post can be read here:
> 
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=116230631107331&w=2
> 
> But I do believe we have to wait for maintainer's position before proceding. 
> If I have any news about that I'll update this bug report
> 
> Thanks!

Thank you, tagging the bug appropriately.

-- 
dann frazier



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

Processed: Re: Bug#396375: linux-image-2.6.18-1-k7: 2.6.18 breaks usb-storage for UCR-61S2 device

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> forwarded 396375 
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=116230631107331&w=2
Bug#396375: linux-image-2.6.18-1-k7: 2.6.18 breaks usb-storage for UCR-61S2 
device
Noted your statement that Bug has been forwarded to 
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=116230631107331&w=2.

> tag 396375 + upstream
Bug#396375: linux-image-2.6.18-1-k7: 2.6.18 breaks usb-storage for UCR-61S2 
device
Tags were: patch
Tags added: upstream

> stop
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Sven Luther]

On Mon, Oct 30, 2006 at 04:52:13PM +0100, Ola Lundqvist wrote:
> The only thing is #2 above. The question is if someone must release
> all it knows when it release open source software (according to DFSG)
> or if you can release only enough to make something work. I can also
> put it as if you want to make good software, when you release something
> as open source?
> 
> What I want to tell with this message is that we should stick to
> what the license tell. The important thing is that we do not
> build something binary that do not contain the code that can
> produce that binary.
> 
> If we consider this as a violation of the DFSG (because of #2 above),
> then where do we draw the line between closed and open source?

Notice that in the GPL case, the definition of free software (to use the
FSF/GNU terminology, which is more fiting here) is pretty clear about the
what is source, namely "the prefered form of modification".

> Must software be easy to understand, or should we consider all software
> that have hardcoded values as closed source?
> 
> Will all reverse engineered drivers with hardcoded values be considered
> as closed source? Must you always release everything that you know
> when you release somehting as open source?
> Must we release the instructions on how to paint an image, how to
> move the arm while painting if we release an image as open source?
> 
> I think this is worth considering. Personally I think this bug can
> be closed.

But your thinking are giving us an excellent way out. We could simply take all
those binary blobs that are in the kernel, and try to take a guess about the
instruction set which they are designed for, and disasemble them, and provide
the dissasembled version under the GPL, as well as a instructions to
re-assemble them into the actual binary blob.

If we were to achieve that, i would be more than happy to consider these blobs
and their corresponding reverse-engineered asm codes as actual source.

One may argue that in this case, the actual documentation of the registers
may be more of a source for such binary blobs, but it would in any case be no
worse than any other reverse-engineering effort out there.

Friendly,

Sven Luther


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

Bug#396388: should allow hooks to abort build

[Joey Hess]

Package: initramfs-tools
Version: 0.84
Severity: normal

mkinitramfs is not a set -x script, and so when call_scripts runs a hook
script, any error is ignored.

In some cases, a hook script needs to abort the initramfs build. For
example, then nslu2-tools hook script can detect issues, like a missing
ixp ethernet driver, that will make the box unusable, and needs to be
able to abort the initramfs build in these situations.

Currently the only way for a hook script to abort the build is a nasty
hack. Since call_scripts sources /conf/param.conf, a hook script could
create that file, and make it exit 1. Of course, that's beyond gross,
and I won't do it. :-)

Please provide a mechanism for hook scripts to abort a build. Note that
in the past, if a hook script exited nonzero, the build did abort, so my
guess is that there are few hook scripts that exit nonzero in cases
where the build would continue. However, if you don't feel that's safe
now, an alternative would be to check for a flag file in the initramfs
tree, which a hook script could create to indicate that the build needs
to be aborted.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Goswin von Brederlow]

Ola Lundqvist <[EMAIL PROTECTED]> writes:

> Ok, you are probably right if the person use an automated tool to make
> this obfuscation. (Not sure though, see below).
>
> However as it is impossible to know if someone use a obfuscation program
> or if the person use a text editor to edit this, I can not see it as
> a violation anyway.
>
> At least it is a bit harsh to see it as a policy violation just because
> it may be obfuscated.

If you have 'char data[] = { 0xef, 0x45, ... };' and from running a
disassembler it is clear that this was produced with gcc for arm (yes,
that is not too wilde an idea) or some other compiler I think then it
is at least suspect.

Personaly I rather have such a char array under GPL than no driver or
a binary only driver. At least you can perfectly legaly dissasemble
the data and, comment the code and make it readable again.


Ultimately I think the decision is with ftp-master and then you have
to fight hard to reverse that. They usualy make good calls there.

MfG
Goswin


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

Bug#395247: (fwd) Bug#395247: [s390] System clock runs wild (in hercules emulator)

[Heiko Carstens]

This a known bug and is already fixed in the current git tree. AFAIK the patch
is accepted for 2.6.18.2. If you need it earlier, here it is:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d9f7a745d55527d0d41684b22506a86c4381f7f1

On Tue, Oct 31, 2006 at 11:15:54AM +0100, maximilian attems wrote:
> could you please have a look at this bug?
> thanks
> 
> - Forwarded message from Frans Pop <[EMAIL PROTECTED]> -
> 
> X-Original-To: [EMAIL PROTECTED]
> X-Original-To: debian-kernel@lists.debian.org
> Subject: Bug#395247: [s390] System clock runs wild (in hercules emulator)
> Date: Tue, 24 Oct 2006 22:31:54 +0200
> From: Frans Pop <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> 
> Package: linux-2.6
> Version: 2.6.18-2
> Severity: grave
> 
> After booting my hercules emulator with 2.6.18, I noticed some errors during 
> a packages upgrade, like:
> tar: ./config: time stamp 2006-10-27 10:52:22.00126 is 4290.653417 s in the 
> future
> 
> Further investigation showed that the system clock in running wild:
> $ date
> Fri Oct 27 05:36:58 CEST 2006
> $ date
> Fri Oct 27 05:41:40 CEST 2006
> $ date
> Fri Oct 27 06:25:24 CEST 2006
> $ date
> Fri Oct 27 09:01:09 CEST 2006
> $ date
> Fri Oct 27 18:19:04 CEST 2006
> 
> These 'date' commands were given within 15-20 minutes or so. Actual time 
> when the emulator was started was around 2006-10-24 17:30.
> 
> After rebooting the emulator with 2.6.17-9, the problem was gone.
> 
> This series from a later boot with 2.6.18, taken within 2 minutes, is even 
> crazier.
> It shows the clock jumping all over the place (real time Oct 24, 22:30):
> $ date
> Wed Oct 25 09:10:10 CEST 2006
> $ date
> Wed Oct 25 08:06:19 CEST 2006
> $ date
> Wed Oct 25 09:26:43 CEST 2006
> $ date
> Wed Oct 25 09:32:17 CEST 2006
> $ date
> Wed Oct 25 09:35:45 CEST 2006
> $ date
> Wed Oct 25 09:40:40 CEST 2006
> $ date
> Wed Oct 25 08:32:08 CEST 2006
> $ date
> Wed Oct 25 09:49:38 CEST 2006
> $ date
> Wed Oct 25 09:51:44 CEST 2006
> $ date
> Wed Oct 25 08:41:32 CEST 2006
> $ date
> Wed Oct 25 08:42:45 CEST 2006
> $ date
> Wed Oct 25 08:43:59 CEST 2006
> 
> I'm running hercules 3.04.1 on an EM64T host system. The system clock on the 
> host runs normally.
> 
> 
> 
> - End forwarded message -
> -- 
> maks


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

Bug#396375: linux-image-2.6.18-1-k7: 2.6.18 breaks usb-storage for UCR-61S2 device

[Alexandre Pereira Nunes]

Package: linux-image-2.6.18-1-k7
Version: 2.6.18-3
Severity: important
Tags: patch


Linux 2.6.18 introduces a conservative change that restricts the UCR-61S2
initialization fix to only a specific version of the firmware, but older
versions needs that as well. The supplied patch reverses that behaviour.

Upstream was notified, but in the meanwhile it would be interesting to
provide this fix on debian.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-k7
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1)

Versions of packages linux-image-2.6.18-1-k7 depends on:
ii  initramfs-tools [linux-initra 0.84   tools for generating an initramfs
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo
ii  yaird [linux-initramfs-tool]  0.0.12-18  Yet Another mkInitRD

Versions of packages linux-image-2.6.18-1-k7 recommends:
ii  libc6-i686   2.3.6.ds1-7 GNU C Library: Shared libraries [i

-- debconf-show failed
--- linux-source-2.6.18/drivers/usb/storage/unusual_devs.h~ 2006-10-31 
11:27:17.0 -0300
+++ linux-source-2.6.18/drivers/usb/storage/unusual_devs.h  2006-10-31 
11:27:17.0 -0300
@@ -1265,7 +1265,7 @@ UNUSUAL_DEV(  0x0fce, 0xe031, 0x, 0x
  * Tested on hardware version 1.10.
  * Entry is needed only for the initializer function override.
  */
-UNUSUAL_DEV(  0x1019, 0x0c55, 0x0110, 0x0110,
+UNUSUAL_DEV(  0x1019, 0x0c55, 0x, 0x,
"Desknote",
"UCR-61S2B",
US_SC_DEVICE, US_PR_DEVICE, usb_stor_ucr61s2b_init,

Re: Schedule for linux-2.6 2.6.18-4

[Sven Luther]

On Tue, Oct 31, 2006 at 05:30:57PM +0100, Goswin von Brederlow wrote:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> 
> > Andreas Barth <[EMAIL PROTECTED]> writes:
> >> Can we also have amd64-kernels again on i386?
> >>
> >>
> >> Cheers,
> >> Andi
> >
> > The patch is in the BTS and quite small. About 5 lines of code change
> > and the obvious ton of .config files.
> 
> Replying to myself, juhey. Sorry for breaking the threading.
> 
> Could we have one of these compromises?
> 
> 1) Apply the patch and set the config but keep the actual images
> commented out.
> 
> 2) Do 1 and enable one generic 64bit image. No xen, no vserver.
> 
> Or is even one more images too much?

What about :

 3) get ourselves a more powerfull buildd on x86

Friendly,

Sven Luther


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

Bug#395907: marked as done (initramfs-tools: sata_sil24 not added)

[Debian Bug Tracking System]

Your message dated Tue, 31 Oct 2006 07:19:44 -0800
with message-id <[EMAIL PROTECTED]>
and subject line Bug#395907: fixed in initramfs-tools 0.85
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: initramfs-tools
Version: 0.84
Tags: patch

Hi, initramfs-tools fails to add sata_sil24 module for Silicon Image 
3124/3132 SATA controllers in hooks.

-- 
Vadim Solomin <[EMAIL PROTECTED]>
GnuPG keyID: 0x35FA78FF
Linux: It's now safe to turn on your computer
--- hook-functions.orig	2006-10-14 15:03:29.0 +0400
+++ hook-functions	2006-10-28 19:15:03.0 +0400
@@ -179,7 +179,7 @@
 		mesh mptfc mptscsih mptsas mptspi nsp32 \
 		osst qla1280 qla2100 qla2200 qla2300 qla2322 qla2xxx \
 		qla4xxx qla6312 qlogicfas408 qlogicfc sata_mv sata_nv \
-		sata_promise sata_qstor sata_sil sata_sis sata_svw \
+		sata_promise sata_qstor sata_sil sata_sil24 sata_sis sata_svw \
 		sata_sx4 sata_uli sata_via sata_vsc scsi_mod \
 		scsi_transport_fc scsi_transport_iscsi scsi_transport_spi \
 		sd_mod stex sym53c8xx tmscsim zfcp; do


pgpnnblHuABFU.pgp
Description: PGP signature
--- End Message ---
--- Begin Message ---
Source: initramfs-tools
Source-Version: 0.85

We believe that the bug you reported is fixed in the latest version of
initramfs-tools, which is due to be installed in the Debian FTP archive:

initramfs-tools_0.85.dsc
  to pool/main/i/initramfs-tools/initramfs-tools_0.85.dsc
initramfs-tools_0.85.tar.gz
  to pool/main/i/initramfs-tools/initramfs-tools_0.85.tar.gz
initramfs-tools_0.85_all.deb
  to pool/main/i/initramfs-tools/initramfs-tools_0.85_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
maximilian attems <[EMAIL PROTECTED]> (supplier of updated initramfs-tools 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 30 Oct 2006 10:12:58 +0100
Source: initramfs-tools
Binary: initramfs-tools
Architecture: source all
Version: 0.85
Distribution: unstable
Urgency: high
Maintainer: Debian kernel team 
Changed-By: maximilian attems <[EMAIL PROTECTED]>
Description: 
 initramfs-tools - tools for generating an initramfs
Closes: 393890 393906 394559 395907
Changes: 
 initramfs-tools (0.85) unstable; urgency=high
 .
   Release "Nichts ist getan, wenn noch etwas zu tun übrig ist."
 .
   * update-initramfs: Fix ro /boot check to not trigger on other mounts
 having a /boot string. (closes: 393906) Thanks for the patch
 Olli Helenius <[EMAIL PROTECTED]>
 .
   * init-top/framebuffer: Fix duplicate fbno0 device creation. Merge the
 0.69ubuntu10 solution. Thanks Benjamin Leipold <[EMAIL PROTECTED]>
 for the report. (closes: 393890)
 .
   * update-initramfs: Fix mbr_check() for installed lilo and used grub. Thanks
 for the patch by Michel Casabona <[EMAIL PROTECTED]>. Also be
 stricter about do_bootloader match, use negative info and add check for
 grub on mbr before throwing error. (closes: 394559) urgency high.
 .
   * hook-functions: Add sata_sil24 to scsi modules. (closes: 395907)
 Thanks Vadim S. Solomi" <[EMAIL PROTECTED]> for the patch.
 .
   * update-initramfs: Fix lilo detection in mbr_check() for rootraid.
 Based on a patch by Michael Prokop <[EMAIL PROTECTED]>. Suppress lilo 
warning
 messages on test run.
Files: 
 b3ee42c6f0edd6bf8efc031d7122e7d4 623 utils optional initramfs-tools_0.85.dsc
 5d2453349ac6fb4c20ceebc6560b20ff 54416 utils optional 
initramfs-tools_0.85.tar.gz
 ec9b711f011c15cde0c4c3ee586a072e 61164 utils optional 
initramfs-tools_0.85_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFR2Wu6n7So0GVSSARAkGXAJ4yZkbVX+WCUflDrkWQryHTvEMWfQCfUTkR
LvFmcDKbu6nO10aRDlgIwAI=
=EwLl
-END PGP SIGNATURE-

--- End Message ---

Re: Schedule for linux-2.6 2.6.18-4

[Goswin von Brederlow]

Bastian Blank <[EMAIL PROTECTED]> writes:

> On Tue, Oct 31, 2006 at 02:13:33PM +0100, Goswin von Brederlow wrote:
>> So what if it takes a bit longer and takes a bit more disk space? Try
>> building on m68k. :)
>
> Ask cts, it takes less. Especialy as m68k currently builds only two
> images.
>
> Bastian

He cross-compiles on a fast system.

Without that I think it is around 6 hours per image.

MfG
Goswin


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

Bug#394559: marked as done (initramfs-tools: postinst script exit status 1, testing for LILO in update-initramfs)

[Debian Bug Tracking System]

Your message dated Tue, 31 Oct 2006 07:19:44 -0800
with message-id <[EMAIL PROTECTED]>
and subject line Bug#394559: fixed in initramfs-tools 0.85
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: initramfs-tools
Version: 0.83
Severity: normal
Tags: patch

Hi, 

update-initramfs exits with status 1 from function mbr_check() if the
boot record doesn't contain the string "LILO". Indeed grep returns
status 1 and the script runs with "set -e".

The small patch attached below solved the problem for me (using grub,
but lilo still installed and lilo.conf no longer current).

Thanks

-- Package-specific info:
-- /proc/cmdline
root=/dev/hda10 ro vga=0x317

-- /proc/filesystems
ext3
ext2
cramfs
vfat

-- lsmod
Module  Size  Used by
ipv6  212544  12 
nls_iso8859_15  4608  5 
nls_cp850   4864  5 
vfat   11200  5 
fat44956  1 vfat
dm_snapshot14268  0 
dm_mirror  16784  0 
dm_mod 47544  2 dm_snapshot,dm_mirror
snd_sbawe  32512  0 
snd_opl3_lib9312  1 snd_sbawe
snd_sb16_dsp8896  1 snd_sbawe
snd_sb16_csp   17504  1 snd_sbawe
snd_sb_common  15232  3 snd_sbawe,snd_sb16_dsp,snd_sb16_csp
snd_hwdep   8580  2 snd_opl3_lib,snd_sb16_csp
snd_mpu401_uart 7232  1 snd_sbawe
snd_rawmidi21728  1 snd_mpu401_uart
snd_seq_device  7596  3 snd_sbawe,snd_opl3_lib,snd_rawmidi
snd_pcm_oss37760  0 
snd_mixer_oss  14944  1 snd_pcm_oss
snd_pcm65608  3 snd_sbawe,snd_sb16_dsp,snd_pcm_oss
snd_timer  19620  2 snd_opl3_lib,snd_pcm
snd45156  13 
snd_sbawe,snd_opl3_lib,snd_sb16_dsp,snd_sb16_csp,snd_sb_common,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore   8704  1 snd
snd_page_alloc  9416  1 snd_pcm
mousedev   10304  1 
tsdev   7296  0 
evdev   8800  0 
parport_pc 31268  0 
parport33928  1 parport_pc
rtc11220  0 
8250_pnp8608  0 
ns558   4608  0 
gameport   13480  2 ns558
floppy 50500  0 
psmouse34312  0 
serio_raw   6212  0 
pcspkr  2560  0 
ide_cd 34944  0 
cdrom  32192  1 ide_cd
ide_disk   14272  12 
piix8964  0 [permanent]
8139too23808  0 
mii 5056  1 8139too
generic 4804  0 [permanent]
ide_core  105668  4 ide_cd,ide_disk,piix,generic
ohci_hcd   17316  0 
ehci_hcd   26632  0 
usbcore   109092  3 ohci_hcd,ehci_hcd

-- kernel-img.conf
# Do not create symbolic links in /
do_symlinks = Yes

postinst_hook = /sbin/update-grub
postrm_hook = /sbin/update-grub
do_bootloader = no

do_initrd = Yes



-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (100, 'testing'), (10, 'stable'), (1, 'experimental')
Architecture: i386 (i486)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages initramfs-tools depends on:
ii  busybox   1:1.1.3-3  Tiny utilities for small and embed
ii  cpio  2.6-17 GNU cpio -- a program to manage ar
ii  klibc-utils   1.4.27-1   small statically-linked utilities 
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo
ii  udev  0.100-2/dev/ and hotplug management daemo

initramfs-tools recommends no packages.

-- no debconf information
--- update-initramfs-0.83   2006-10-13 09:37:34.0 +0200
+++ update-initramfs2006-10-21 22:39:01.0 +0200
@@ -139,8 +139,7 @@
boot=$(awk -F = '/^boot=/{ print $2}' /etc/lilo.conf)
[ -z "${boot}" ] && return 0
[ ! -r "${boot}" ] && return 0
-   dd if="${boot}" bs=512 skip=0 count=1 2> /dev/null | grep -q LILO
-   [ $? -eq 0  ] && run_lilo && return 0
+   dd if="${boot}" bs=512 skip=0 count=1 2> /dev/null | grep -q LILO && 
run_lilo && return 0
echo
echo "WARNING: grub and lilo installed."
echo "If you use grub as bootloader everything is fine."
--- End Message --

Bug#393906: marked as done (initramfs-tools: update-initramfs incorrectly detects read-only /boot)

[Debian Bug Tracking System]

Your message dated Tue, 31 Oct 2006 07:19:44 -0800
with message-id <[EMAIL PROTECTED]>
and subject line Bug#393906: fixed in initramfs-tools 0.85
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: initramfs-tools
Version: 0.83
Severity: normal
Tags: patch


update-initramfs checks /proc/mounts for a read-only /boot but the check 
does not take into account the possibility of some other ro mount (NFS, 
for example) having the string "boot" in its name.

Here's a small patch that attempts to fix the problem:

- S N I P -
--- update-initramfs.orig   2006-10-18 13:42:26.0 +0300
+++ update-initramfs2006-10-18 13:42:42.0 +0300
@@ -194,7 +194,7 @@
 ro_boot_check()
 {
[ -r /proc/mounts ] || return 0
-   boot_opts=$(awk '/boot/{if (match($4, /ro/)) print "ro"}' /proc/mounts)
+   boot_opts=$(awk '/boot/{if (match($4, /ro/) && $2 == "/boot") print 
"ro"}' /proc/mounts)
if [ -n "${boot_opts}" ]; then
echo "WARNING: /boot is ro mounted."
echo "update-initramfs: Not updating ${initramfs}"
- S N I P -


-- Package-specific info:
-- /proc/cmdline
root=/dev/sda1 ro 

-- /proc/filesystems
cramfs
ext3
jfs

-- lsmod
Module  Size  Used by
ipmi_msghandler25088  0 
w83627hf   22416  0 
w83781d29156  0 
hwmon_vid   2336  2 w83627hf,w83781d
i2c_isa 4512  2 w83627hf,w83781d
i2c_dev 7968  0 
crc32c  1856  0 
libcrc32c   2528  1 crc32c
iscsi_trgt 53340  4 
nfsd  199524  17 
exportfs5024  1 nfsd
nfs   188140  21 
lockd  53672  3 nfsd,nfs
nfs_acl 3264  2 nfsd,nfs
sunrpc132612  13 nfsd,nfs,lockd,nfs_acl
jfs   157180  3 
ipv6  217760  30 
button  6320  0 
ac  4612  0 
battery 9252  0 
loop   14472  0 
mousedev   10368  0 
tsdev   7200  0 
evdev   8736  0 
i2c_i8017884  0 
i2c_core   19312  5 w83627hf,w83781d,i2c_isa,i2c_dev,i2c_i801
pcspkr  2948  0 
psmouse34248  0 
floppy 55628  0 
rtc11252  0 
shpchp 39200  0 
pci_hotplug24180  1 shpchp
serio_raw   6436  0 
ext3  116008  1 
jbd46932  1 ext3
mbcache 7652  1 ext3
dm_mirror  17236  0 
dm_snapshot15324  0 
dm_mod 47892  7 dm_mirror,dm_snapshot
piix8932  0 [permanent]
sd_mod 16208  4 
generic 4164  0 [permanent]
ide_core  111440  2 piix,generic
ehci_hcd   26856  0 
uhci_hcd   26640  0 
usbcore   110560  3 ehci_hcd,uhci_hcd
e100   31044  0 
mii 5056  1 e100
megaraid_mbox  24784  3 
scsi_mod  10  2 sd_mod,megaraid_mbox
megaraid_mm 9948  3 megaraid_mbox
thermal12968  0 
processor  21696  1 thermal
fan 4452  0 

-- kernel-img.conf
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = no
postinst_hook = update-grub
postrm_hook   = update-grub


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages initramfs-tools depends on:
ii  busybox   1:1.1.3-3  Tiny utilities for small and embed
ii  cpio  2.6-17 GNU cpio -- a program to manage ar
ii  klibc-utils   1.4.27-1   small statically-linked utilities 
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo
ii  udev  0.100-2/dev/ and hotplug management daemo

initramfs-tools recommends no packages.

-- no debconf information

--- End Message ---
--- Begin Message ---
Source: initramfs-tools
Source-Version: 0.85

We believe that the bug you reported is fixed in the latest version of
i

Re: Scheduling linux-2.6 2.6.18-3

[Oleg Verych]

On 2006-10-31, maximilian attems wrote:
[]
>> May i ask, what is general rules to accept changes?
> you didn't look at the wiki heh
> http://wiki.debian.org/DebianKernel
> http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

Thanks.

>> For example .19-rc linux kernel has some valuable changes in drivers,
>> that can support more hardware (in my case Realtek gigabit ethernet and
>> Intel SATA, all in one box ;) Is it possible to accept some backports ?
>
> the r8169 fixes are all backported afaik.
> what sata fixes are you pointing too, be more precise?

OK, it's all seems OK now. (i've used .19-rcX on the new machine, to bring it
up; now i've installed 2.6.18-3, rebooted)



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

Re: Bug#396185: sky2 network driver freezes

[Oleg Verych]

On 2006-10-30, Adrian Johnson wrote:
[]
> Package: linux-image-2.6.18-1-amd64
> Version: 2.6.18-4~snapshot.7648
>
> I have experienced a network freeze of the sky2 network driver
> The console error message is:
> NETDEV WATCHDOG   : eth0: transmit timed out
> sky2 eth0: tx timeout
> sky2 hardware hung? flushing
[]

OK. Thread on LKML has ended with this
(you can browse down it a bit also).


I don't know if pci mmconfig patch was reverted in 2.6.18.1 (it wasn't
according to kernel.org's changelog) debian tree (also didn't see that).

If you can, please revert it and try to get bug or more info.
2.6.19-rcX has that patch reverted, see commit:
7bd656d12119708b37414bf909ab2995473da818

If this will solve your problem, this should go to 2.6.18-4.

Thanks.



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

initramfs-tools_0.85_amd64.changes ACCEPTED

[Debian Installer]

Accepted:
initramfs-tools_0.85.dsc
  to pool/main/i/initramfs-tools/initramfs-tools_0.85.dsc
initramfs-tools_0.85.tar.gz
  to pool/main/i/initramfs-tools/initramfs-tools_0.85.tar.gz
initramfs-tools_0.85_all.deb
  to pool/main/i/initramfs-tools/initramfs-tools_0.85_all.deb


Override entries for your package:
initramfs-tools_0.85.dsc - source utils
initramfs-tools_0.85_all.deb - optional utils

Announcing to debian-devel-changes@lists.debian.org
Closing bugs: 393890 393906 394559 395907 


Thank you for your contribution to Debian.


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

Re: Schedule for linux-2.6 2.6.18-4

[Jurij Smakov]

On Mon, Oct 30, 2006 at 04:29:21PM +0100, Frederik Schueler wrote:
> I personally have somewhat lost the overview on on open issues being 
> busy with RL work the past 2 weeks, so I would like everyone of you to
> compile a short list of things you have on your agenda for 2.6.18-4, 
> and generally before the release.

I have one important fix in the pipe (boot failure on SunBlade1000). A 
patch for it was posted recently, and I've just received a 
confirmation that it fixes the problem. I'll build a test kernel 
tonight and make sure that it boots fine on my boxes, after that it 
can go in. Please don't upload before I committed it.

Best regards,
-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC


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

Re: Schedule for linux-2.6 2.6.18-4

[Goswin von Brederlow]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Andreas Barth <[EMAIL PROTECTED]> writes:
>> Can we also have amd64-kernels again on i386?
>>
>>
>> Cheers,
>> Andi
>
> The patch is in the BTS and quite small. About 5 lines of code change
> and the obvious ton of .config files.

Replying to myself, juhey. Sorry for breaking the threading.

Could we have one of these compromises?

1) Apply the patch and set the config but keep the actual images
commented out.

2) Do 1 and enable one generic 64bit image. No xen, no vserver.

Or is even one more images too much?

MfG
Goswin


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

Bug#396022: marked as done (initramfs-tools: Tries to create the /dev/fb0 device multiple times, causing harmless but confusing error messages)

[Debian Bug Tracking System]

Your message dated Tue, 31 Oct 2006 07:19:44 -0800
with message-id <[EMAIL PROTECTED]>
and subject line Bug#393890: fixed in initramfs-tools 0.85
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---

Package: initramfs-tools
Version: 0.84
Severity: minor
Tags: patch

The init-top/framebuffer script has the following lines (83 - 92):

if [ -e /proc/fb ]; then
while read fbno desc; do
mknod /dev/fb$fbno c 29 $fbno
done < /proc/fb

mknod /dev/fb0 c 29 0
for i in 0 1 2 3 4 5 6 7 8; do
mknod /dev/tty$i c 4 $i
done
fi

The problem is that the "mknod /dev/fb0" will be executed twice if fb0 
has already been found in /proc/fb. The fix would be to change it to:


if [ -e /proc/fb ]; then
while read fbno desc; do
mknod /dev/fb$fbno c 29 $fbno
done < /proc/fb

if [ ! -e /dev/fb0 ]; then
mknod /dev/fb0 c 29 0
fi

for i in 0 1 2 3 4 5 6 7 8; do
mknod /dev/tty$i c 4 $i
done
fi

--
David Härdeman

--- End Message ---
--- Begin Message ---
Source: initramfs-tools
Source-Version: 0.85

We believe that the bug you reported is fixed in the latest version of
initramfs-tools, which is due to be installed in the Debian FTP archive:

initramfs-tools_0.85.dsc
  to pool/main/i/initramfs-tools/initramfs-tools_0.85.dsc
initramfs-tools_0.85.tar.gz
  to pool/main/i/initramfs-tools/initramfs-tools_0.85.tar.gz
initramfs-tools_0.85_all.deb
  to pool/main/i/initramfs-tools/initramfs-tools_0.85_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
maximilian attems <[EMAIL PROTECTED]> (supplier of updated initramfs-tools 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 30 Oct 2006 10:12:58 +0100
Source: initramfs-tools
Binary: initramfs-tools
Architecture: source all
Version: 0.85
Distribution: unstable
Urgency: high
Maintainer: Debian kernel team 
Changed-By: maximilian attems <[EMAIL PROTECTED]>
Description: 
 initramfs-tools - tools for generating an initramfs
Closes: 393890 393906 394559 395907
Changes: 
 initramfs-tools (0.85) unstable; urgency=high
 .
   Release "Nichts ist getan, wenn noch etwas zu tun übrig ist."
 .
   * update-initramfs: Fix ro /boot check to not trigger on other mounts
 having a /boot string. (closes: 393906) Thanks for the patch
 Olli Helenius <[EMAIL PROTECTED]>
 .
   * init-top/framebuffer: Fix duplicate fbno0 device creation. Merge the
 0.69ubuntu10 solution. Thanks Benjamin Leipold <[EMAIL PROTECTED]>
 for the report. (closes: 393890)
 .
   * update-initramfs: Fix mbr_check() for installed lilo and used grub. Thanks
 for the patch by Michel Casabona <[EMAIL PROTECTED]>. Also be
 stricter about do_bootloader match, use negative info and add check for
 grub on mbr before throwing error. (closes: 394559) urgency high.
 .
   * hook-functions: Add sata_sil24 to scsi modules. (closes: 395907)
 Thanks Vadim S. Solomi" <[EMAIL PROTECTED]> for the patch.
 .
   * update-initramfs: Fix lilo detection in mbr_check() for rootraid.
 Based on a patch by Michael Prokop <[EMAIL PROTECTED]>. Suppress lilo 
warning
 messages on test run.
Files: 
 b3ee42c6f0edd6bf8efc031d7122e7d4 623 utils optional initramfs-tools_0.85.dsc
 5d2453349ac6fb4c20ceebc6560b20ff 54416 utils optional 
initramfs-tools_0.85.tar.gz
 ec9b711f011c15cde0c4c3ee586a072e 61164 utils optional 
initramfs-tools_0.85_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFR2Wu6n7So0GVSSARAkGXAJ4yZkbVX+WCUflDrkWQryHTvEMWfQCfUTkR
LvFmcDKbu6nO10aRDlgIwAI=
=EwLl
-END PGP SIGNATURE-

--- End Message ---

Bug#393890: marked as done (initramfs-tools: wrong mknod syntax in init-top/framebuffer)

[Debian Bug Tracking System]

Your message dated Tue, 31 Oct 2006 07:19:44 -0800
with message-id <[EMAIL PROTECTED]>
and subject line Bug#393890: fixed in initramfs-tools 0.85
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: initramfs-tools
Version: 0.83
Severity: normal

1. The device type for mknod is missing at line 85 in init-top/framebuffer.
2. Why is the framebuffer device for fbno 0 created twice (line 85 and 88)?


-- Package-specific info:
-- /proc/cmdline
root=/dev/sda7 ro vga=794 quiet 

-- /proc/filesystems
xfs
ext3

-- lsmod
Module  Size  Used by
fglrx 401196  8 
rfcomm 38300  0 
hidp   16064  2 
l2cap  24068  10 rfcomm,hidp
bluetooth  51812  5 rfcomm,hidp,l2cap
ppdev   9860  0 
lp 11972  0 
capability  4936  0 
ipv6  258144  14 
ipt_TOS 2240  34 
xt_tcpudp   3264  34 
iptable_mangle  2816  1 
iptable_nat 7556  0 
ip_nat 17644  1 iptable_nat
ip_conntrack   52788  2 iptable_nat,ip_nat
nfnetlink   6872  2 ip_nat,ip_conntrack
iptable_filter  3008  1 
ip_tables  13640  3 iptable_mangle,iptable_nat,iptable_filter
x_tables   14276  4 ipt_TOS,xt_tcpudp,iptable_nat,ip_tables
ext3  134216  1 
jbd59240  1 ext3
mbcache 8836  1 ext3
aes27776  1 
dm_crypt   11976  1 
dm_mod 55160  3 dm_crypt
dazuko 57152  2 
commoncap   7232  2 capability,dazuko
fuse   44436  0 
asb100 21012  0 
hwmon_vid   3200  1 asb100
hwmon   3348  1 asb100
binfmt_misc11528  1 
snd_intel8x0   32284  3 
snd_ac97_codec 90528  1 snd_intel8x0
snd_ac97_bus2240  1 snd_ac97_codec
nvidia_agp  8220  1 
agpgart32112  2 fglrx,nvidia_agp
i2c_nforce2 7168  0 
snd_pcm73096  3 snd_intel8x0,snd_ac97_codec
snd_timer  23428  2 snd_pcm
psmouse37960  0 
i2c_core   21648  2 asb100,i2c_nforce2
8250_pnp8896  0 
8250   22564  1 8250_pnp
serial_core21888  1 8250
evdev   9792  2 
sk98lin   157536  0 
eth139419716  0 
rtc 9104  0 
parport_pc 39716  1 
parport38472  3 ppdev,lp,parport_pc
floppy 58020  0 
snd45528  8 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
soundcore  10016  1 snd
snd_page_alloc  9992  2 snd_intel8x0,snd_pcm
xfs   546292  2 
usbhid 41760  0 
ide_cd 39456  0 
cdrom  37024  1 ide_cd
sd_mod 18704  5 
forcedeth  42500  0 
ohci_hcd   20612  0 
ehci_hcd   32392  0 
usbcore   126340  4 usbhid,ohci_hcd,ehci_hcd
amd74xx13916  0 [permanent]
ide_core  119364  2 ide_cd,amd74xx
ohci1394   34992  0 
ieee1394   98360  2 eth1394,ohci1394
sata_sil   11912  5 
libata101972  1 sata_sil
scsi_mod   96712  2 sd_mod,libata
thermal13384  0 
processor  23724  1 thermal
fan 4740  0 
unix   28528  759 

-- kernel-img.conf
do_symlinks = yes
link_in_boot = no
relative_links = yes
reverse_symlinks = no
do_bootloader = no
do_initrd = yes

postinst_hook = /usr/sbin/update-grub
postrm_hook   = /usr/sbin/update-grub


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages initramfs-tools depends on:
ii  busybox   1:1.1.3-3  Tiny utilities for small and embed
ii  cpio  2.6-17 GNU cpio -- a program to manage ar
ii  klibc-utils   1.4.29-1   small statically-linked utilities 
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo
ii  udev  0.100-2.1  /dev/ and hotplug management daemo

initramfs-tools recommends no packages.

--

Processing of initramfs-tools_0.85_amd64.changes

[Archive Administrator]

initramfs-tools_0.85_amd64.changes uploaded successfully to localhost
along with the files:
  initramfs-tools_0.85.dsc
  initramfs-tools_0.85.tar.gz
  initramfs-tools_0.85_all.deb

Greetings,

Your Debian queue daemon


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

Bug#343440: Resuming from suspend to RAM with 2.6.14-5 fails significantly more often than with 2.6.14-4

[Thomas Maier]

Am Montag, den 30.10.2006, 14:38 +0100 schrieb maximilian attems:
> On Mon, Oct 30, 2006 at 10:42:25AM +0100, Thomas Maier wrote:
> > Hi David,
> > 
> > thought nobody's going to look at this, it's almost a year :).  
> 
> swsusp bugs are low priority and there is still lots of work going
> on upstream to make it more stable driver wise.

Yeah, frustrating from a user's point of view, but absolutely
understandable.


> > Last week I switched to Edgy (Ubuntu).  While I was still with Debian,
> > I stopped using suspend to RAM (months ago) and used suspend to disk
> > instead.  The in-kernel implementation is quite stable on my notebook
> > but sucks in all other aspects (e.g. it is _annoyingly_ slow).  Being
> > extra careful when hibernating (old habit from the days when things
> > tended to freeze), my last uptime was 72 days.  As a side note I'd
> > suggest (or, rather _beg_) offering suspend2-enabled kernels (see
> > suspend2.net), which works amazingly fast and has a couple of other nice
> > characteristics (better concept, nice community, nice developer
> > (especially in contrast to the in-kernel suspend), etc.).  In short:
> > in-kernel suspend works but sucks, suspend2 works and is nice.  Easy
> > choice, I'd think :).  Should I file a wishlist-bug?
> 
> suspend2 adds a gif decoder and is not even included in the bloated
> ubuntu kernel, see the debian kernel policy
> the only sucess of suspend2 is to unload a bunch of drivers and
> reoload them, that's most of the difference for the user.

You obviously never used it and don't know what you are talking about.

FYI, suspend2 does not unload a bunch of drivers.  That's the job of a
userspace application called hibernate (there is a Debian package with
the same name), which I think originates from the suspend2 community but
is not specific to it, i.e. it can be used with other suspend methods,
too.

And the real difference to me as a user is the time it takes to suspend
the machine.  It is really seconds with suspend2 (say, 20 seconds)
compared to a few _minutes_ with swsusp.  When trying it yourself, be
sure to suspend a real-life session (i.e. use a substantial part of your
RAM).  And then resume your machine and feel the difference. With swsusp
it runs like a pig, because everything needs to be paged back in.  With
suspend2, you get your machine back like it was when you suspended it
(with the file system caches still as hot as before).


> you really want to use uswsusp as it has the advantages
> of suspend2

Again, this is wrong.


> , while not having akward not mergeable code.
>
> so no your wishlist bug is not welcome, but would be useless
> see http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

Thanks for the pointer, that is a clear statement.


> as you didn't tell if you tested the 2.6.18 linux-images and
> switched distribution the bug can most probably be closed.

Yes.  I stopped using suspend to RAM a few versions before and now I can
no longer test.  Again, all the best for the release,

-- 
Thomas Maier - Research Assistant - University of Kassel, Germany



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

Re: Schedule for linux-2.6 2.6.18-4

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Frederik Schueler ([EMAIL PROTECTED]) [061030 16:30]:
>> Fellow kernel-team members,
>> 
>> it has been a while since our last upload, and the issues are
>> cumulating. We have a total of 8 RC bugs we need to take care before the
>> release, and another dozen of driver issues we should try to sort out.
>> 
>> IMHO, the most pressing issues are: 
>> - the ext3 corruption (#392818)
>> - the need to rebuild using a newer kernel-package (#395110)
>> - the broken ABI
>> - renaming the orig.tar.gz in order to remove the 8 firmwares as
>>   discussed with the release managers
>> - alpha gcc-4.1 migration
>
> Can we also have amd64-kernels again on i386?
>
>
> Cheers,
> Andi

The patch is in the BTS and quite small. About 5 lines of code change
and the obvious ton of .config files.

The latest statement on this issue is still that adding any more
kernel images to the build would exhaust the resources of the build
process for the linux team.

So what if it takes a bit longer and takes a bit more disk space? Try
building on m68k. :)

MfG
Goswin


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

Re: Schedule for linux-2.6 2.6.18-4

[Bastian Blank]

On Tue, Oct 31, 2006 at 02:13:33PM +0100, Goswin von Brederlow wrote:
> So what if it takes a bit longer and takes a bit more disk space? Try
> building on m68k. :)

Ask cts, it takes less. Especialy as m68k currently builds only two
images.

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3


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

Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)

[Csillag Kristóf]

Hi David,

Sorry for the slow response; since I quitted my previous job,
it's a bit more difficult to get physical access to the computer in question.
(On the other hand, I don't really care about it any more.)

Anyway, I tested it with 2.6.18-3, and without acpi=off, the system is still
screwed up. (Now the hard disks are controlled by a PCI raid controller,
and even that was not detected, so I could not even boot.)

I don't have time to try the mentioned workaround.

Best wishes:

   Kristof


On Fri, 27 Oct 2006 17:27:34 +0200
David Schmitt <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Kristof!
> 
> 
> In preparation of the upcoming etch release, would you please
> test if either 2.6.17-9 from testing or 2.6.18-3 from unstable
> fixes your problem with your NIC?
> 
> Additionally, there seems to be a workaround to be found in the kernel.or 
> bugzilla:
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=4773#c17 and following comments
> 
> 
> Please report your findings by sending "found" or "close" followed by
> the bug number and the respective version to [EMAIL PROTECTED] as
> detailed on http://www.debian.org/Bugs/server-control or by sending
> additional information to the bug report (reply to this mail)
> 
> 
> Thank you for your cooperation!
> 
> 
> Regards, David
> 
> 
> - -- 
> - - hallo... wie gehts heute?
> - - *hust* gut *rotz* *keuch*
> - - gott sei dank kommunizieren wir über ein septisches medium ;)
>  -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.5 (GNU/Linux)
> 
> iD8DBQFFQiVn/Pp1N6Uzh0URAkAdAKCXEn8vKKGTERtvouo97vEV5QArpwCfcD2m
> eVNm4vpEp+BvyjtFaK+8f9k=
> =QZup
> -END PGP SIGNATURE-
> 

Re: Scheduling linux-2.6 2.6.18-3

[maximilian attems]

On Sun, 15 Oct 2006, Oleg Verych wrote:

> Hallo, Frederik.
> 
> On 2006-10-10, Frederik Schueler wrote:
> []
> >
> > As usual, if someone needs more time for pending changes, drop a line.
> 
> May i ask, what is general rules to accept changes?
you didn't look at the wiki heh
http://wiki.debian.org/DebianKernel
http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

> For example .19-rc linux kernel has some valuable changes in drivers,
> that can support more hardware (in my case Realtek gigabit ethernet and
> Intel SATA, all in one box ;) Is it possible to accept some backports ?

the r8169 fixes are all backported afaik.
what sata fixes are you pointing too, be more precise?
 
-- 
maks


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

Re: Schedule for linux-2.6 2.6.18-4

[maximilian attems]

On Mon, 30 Oct 2006, Frederik Schueler wrote:

> - the ext3 corruption (#392818)

fixed in 2.6.18.1
jan kara's patch fixes this issue that showed up on 1k bs
and stress testing with fsx.

i'll close the bug later.

-- 
maks


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

Bug#395247: (fwd) Bug#395247: [s390] System clock runs wild (in hercules emulator)

[maximilian attems]

could you please have a look at this bug?
thanks

- Forwarded message from Frans Pop <[EMAIL PROTECTED]> -

X-Original-To: [EMAIL PROTECTED]
X-Original-To: debian-kernel@lists.debian.org
Subject: Bug#395247: [s390] System clock runs wild (in hercules emulator)
Date: Tue, 24 Oct 2006 22:31:54 +0200
From: Frans Pop <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

Package: linux-2.6
Version: 2.6.18-2
Severity: grave

After booting my hercules emulator with 2.6.18, I noticed some errors during 
a packages upgrade, like:
tar: ./config: time stamp 2006-10-27 10:52:22.00126 is 4290.653417 s in the 
future

Further investigation showed that the system clock in running wild:
$ date
Fri Oct 27 05:36:58 CEST 2006
$ date
Fri Oct 27 05:41:40 CEST 2006
$ date
Fri Oct 27 06:25:24 CEST 2006
$ date
Fri Oct 27 09:01:09 CEST 2006
$ date
Fri Oct 27 18:19:04 CEST 2006

These 'date' commands were given within 15-20 minutes or so. Actual time 
when the emulator was started was around 2006-10-24 17:30.

After rebooting the emulator with 2.6.17-9, the problem was gone.

This series from a later boot with 2.6.18, taken within 2 minutes, is even 
crazier.
It shows the clock jumping all over the place (real time Oct 24, 22:30):
$ date
Wed Oct 25 09:10:10 CEST 2006
$ date
Wed Oct 25 08:06:19 CEST 2006
$ date
Wed Oct 25 09:26:43 CEST 2006
$ date
Wed Oct 25 09:32:17 CEST 2006
$ date
Wed Oct 25 09:35:45 CEST 2006
$ date
Wed Oct 25 09:40:40 CEST 2006
$ date
Wed Oct 25 08:32:08 CEST 2006
$ date
Wed Oct 25 09:49:38 CEST 2006
$ date
Wed Oct 25 09:51:44 CEST 2006
$ date
Wed Oct 25 08:41:32 CEST 2006
$ date
Wed Oct 25 08:42:45 CEST 2006
$ date
Wed Oct 25 08:43:59 CEST 2006

I'm running hercules 3.04.1 on an EM64T host system. The system clock on the 
host runs normally.



- End forwarded message -
-- 
maks


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

Bug#396185: sky2 freezes in 2.6.17-2-686. Maintainer confirms that it should be fixed in 2.6.19-git tree.

[maximilian attems]

On Tue, Oct 31, 2006 at 12:44:25PM +0300, Evgeniy Polyakov wrote:
> 
> I'm installing it right now, although package is called 2.6.18-1, but
> actual version is 2.6.18-3, so if it was based on 2.6.18.2+ then bug
> should be fixed. I will add more details if this situation appeares
> again, since I can not say that it is easily reproducible.

there is no 2.6.18.2 yet, although it is in the pipe.
of course 2.6.18.1 + other fixes is there.

-- 
maks
 


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

Re: Intent to NMU mkvmlinuz to fix pending po-debconf l10n bugs

[Christian Perrier]

Done, the mkvmlinuz is in kernel/trunk/utils/mkvmlinuz.

I would prefer to have added bubulle though, i don't know where your blog is,
but i guess this would be an alioth bug, no ? 

 



No, this is a glibc bug (32 groups limit in some conditions) in sarge.


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

Bug#379090: Still no news on 64bit i386 kernels

[Steve Langasek]

On Wed, Oct 25, 2006 at 01:59:29PM +0200, Goswin von Brederlow wrote:

> just a small reminder that etch still has no 64bit kernels for
> i386. This is a regression from sarge which has them. The bug
> (#379090) has a simple patch to reintroduce those kernel images (+5/-1
> lines code change and the rest is config) for nearly 100 days without
> a comment so far.

> Would it be possible for the release team to make this a release issue
> and raise the severity of the bug accordingly?

Raise the severity to what level?  Supporting 64-bit kernels for i386 is not
a release-critical issue.  They would be nice to have, but I'm not going to
try to force the kernel team to support them as there may be reasons they
don't wish to.

Can someone from the kernel team comment on whether there are problems with
this particular patch that have not yet been noted in the bug report?  If
there aren't any known objections, I could review the patch myself and look
at committing it.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Bug#396185: sky2 freezes in 2.6.17-2-686. Maintainer confirms that it should be fixed in 2.6.19-git tree.

[Evgeniy Polyakov]

On Tue, Oct 31, 2006 at 09:57:16AM +0100, maximilian attems ([EMAIL PROTECTED]) 
wrote:
> On Tue, Oct 31, 2006 at 10:30:30AM +0300, Evgeniy Polyakov wrote:
> > Package: linux-image-2.6.17-2-686
> > Version: 2.6.17-9
> > Followup-For: Bug #396185
> > 
> > Bug was filled against 2.6.17-9, but was fixed in recent git (2.6.19-rc3), 
> > probably also
> > fixed in 2.6.18.1
> > 
> > Here is link to discussion:
> > http://marc.theaimsgroup.com/?l=linux-netdev&m=116227512815783&w=2
> > 
> 
> can you try the linux-image 2.6.18, they are in unstable
> and the etch release images.

apt-get can not find them in 'deb http://ftp.debian.org/debian/ etch main'
Only kernel headers with 2.6.18-3 version can be found.

> thanks
> 
> --
> maks

-- 
Evgeniy Polyakov


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

Bug#396185: sky2 freezes in 2.6.17-2-686. Maintainer confirms that it should be fixed in 2.6.19-git tree.

[maximilian attems]

On Tue, Oct 31, 2006 at 12:30:55PM +0300, Evgeniy Polyakov wrote:
> On Tue, Oct 31, 2006 at 09:57:16AM +0100, maximilian attems ([EMAIL 
> PROTECTED]) wrote:
> > On Tue, Oct 31, 2006 at 10:30:30AM +0300, Evgeniy Polyakov wrote:
> > > Package: linux-image-2.6.17-2-686
> > > Version: 2.6.17-9
> > > Followup-For: Bug #396185
> > > 
> > > Bug was filled against 2.6.17-9, but was fixed in recent git 
> > > (2.6.19-rc3), probably also
> > > fixed in 2.6.18.1
> > > 
> > > Here is link to discussion:
> > > http://marc.theaimsgroup.com/?l=linux-netdev&m=116227512815783&w=2
> > > 
> > 
> > can you try the linux-image 2.6.18, they are in unstable
> > and the etch release images.
> 
> apt-get can not find them in 'deb http://ftp.debian.org/debian/ etch main'
> Only kernel headers with 2.6.18-3 version can be found.
> 

sure they are still in unstable, but will just install fine in testing.
just add unstable for them on your sources and remove them afterwards.

--
maks


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

Bug#396185: sky2 freezes in 2.6.17-2-686. Maintainer confirms that it should be fixed in 2.6.19-git tree.

[Evgeniy Polyakov]

On Tue, Oct 31, 2006 at 10:34:55AM +0100, maximilian attems ([EMAIL PROTECTED]) 
wrote:
> On Tue, Oct 31, 2006 at 12:30:55PM +0300, Evgeniy Polyakov wrote:
> > On Tue, Oct 31, 2006 at 09:57:16AM +0100, maximilian attems ([EMAIL 
> > PROTECTED]) wrote:
> > > On Tue, Oct 31, 2006 at 10:30:30AM +0300, Evgeniy Polyakov wrote:
> > > > Package: linux-image-2.6.17-2-686
> > > > Version: 2.6.17-9
> > > > Followup-For: Bug #396185
> > > > 
> > > > Bug was filled against 2.6.17-9, but was fixed in recent git 
> > > > (2.6.19-rc3), probably also
> > > > fixed in 2.6.18.1
> > > > 
> > > > Here is link to discussion:
> > > > http://marc.theaimsgroup.com/?l=linux-netdev&m=116227512815783&w=2
> > > > 
> > > 
> > > can you try the linux-image 2.6.18, they are in unstable
> > > and the etch release images.
> > 
> > apt-get can not find them in 'deb http://ftp.debian.org/debian/ etch main'
> > Only kernel headers with 2.6.18-3 version can be found.
> > 
> 
> sure they are still in unstable, but will just install fine in testing.
> just add unstable for them on your sources and remove them afterwards.

I'm installing it right now, although package is called 2.6.18-1, but
actual version is 2.6.18-3, so if it was based on 2.6.18.2+ then bug
should be fixed. I will add more details if this situation appeares
again, since I can not say that it is easily reproducible.

P.S. I removed [EMAIL PROTECTED] e-mail from Cc, since I
received bounce about unexistent domain bug.debian.org and MX record
absence for it.

Thanks.

> --
> maks

-- 
Evgeniy Polyakov


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

Re: Intent to NMU mkvmlinuz to fix pending po-debconf l10n bugs

[Sven Luther]

On Tue, Oct 31, 2006 at 09:04:26AM +0100, Christian Perrier wrote:
> What I propose for mkvmlinuz is:
> 
> -fix the po-debconf thing in SVN
> -include the Swedish translation
> -post a call for updates to -i18n with a 7-days delay
> -commit all received updates (I'll receive them directly as this is much 
> simpler)
> -ping Sven for an upload

Cool,

> If you're OK, please allow "cperrier-guest" and not "bubulle" for commit 
> access. I am in too many projects in Alioth now and it causes commit 
> problems (see my recent blog post about this).

Done, the mkvmlinuz is in kernel/trunk/utils/mkvmlinuz.

I would prefer to have added bubulle though, i don't know where your blog is,
but i guess this would be an alioth bug, no ? 

Friendly,

Sven Luther


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

Bug#396185: sky2 freezes in 2.6.17-2-686. Maintainer confirms that it should be fixed in 2.6.19-git tree.

[maximilian attems]

On Tue, Oct 31, 2006 at 10:30:30AM +0300, Evgeniy Polyakov wrote:
> Package: linux-image-2.6.17-2-686
> Version: 2.6.17-9
> Followup-For: Bug #396185
> 
> Bug was filled against 2.6.17-9, but was fixed in recent git (2.6.19-rc3), 
> probably also
> fixed in 2.6.18.1
> 
> Here is link to discussion:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=116227512815783&w=2
> 

can you try the linux-image 2.6.18, they are in unstable
and the etch release images.

thanks

--
maks


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

Bug#324823: SATA and IDE CDROM Drive still not working on IBM ThinkCentre

[Michael Bierenfeld]

close. Its working

ata1.00: ATA-6, max UDMA/133, 156312576 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
  Vendor: ATA   Model: WDC WD800JD-08JN  Rev: 06.0
  Type:   Direct-Access  ANSI SCSI revision: 05
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1888 irq 15
scsi1 : ata_piix
ata2.00: ATAPI, max UDMA/33
ata2.00: configured for UDMA/33
  Vendor: TSSTcorp  Model: CDW/DVD TS-H492B  Rev: IB00
  Type:   CD-ROM



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

Re: Intent to NMU mkvmlinuz to fix pending po-debconf l10n bugs

[Christian Perrier]

Sven Luther a écrit :



The mkvmlinuz Debian package, which you are the maintainer of, has
longstanding bug report(s) which include translation updates or fixes
for po-debconf.  At least one of these is older than 100 days, namely
bug number 298972 (it is pretty likely that several other translation
bug reports are pending).
   



I remember some problem with some of these translations, and i was waiting for
a return from you guys. Now, the package is maintained in the kernel svn
repository, and i think we would gladly give you access to it to upgrade the
translations yourself.

 



OK, so it seems that everyone was waiting everybody..:-). No problem.



Well, i know nothing about translations, and the patches did not apply cleanly
or there where some issues.

 



So far, the main patch to apply is the "switch to po-debconf" thing. It 
applies nearly cleanly.


The pending Swedish translation needs review as it was made against the 
old-style debconf l10n.





I have the intention, as part of a more general action of the Debian
i18n Task Force to build and possibly upload a non-maintainer upload
for mkvmlinuz in order to fix this as well as all pending translations
for the debconf templates.
   



Please don't do that. In place, i would appreciate you to check in the
translations directly into the svn repository, and ping me for an upload once
you are done, or if you don't want to do this, to send me a clean and uptodate
patch.
 



No problem for this at all, Sven. If the kernel team agrees, I can 
update things in the SVN and maybe look for possible other kernel-team 
maintained things that cuold require l10n (though, as Sven mentions, 
most of the l10n is kernel-package job.which unfortunately seems to 
be pretty difficult to localize properly, at least last time I looked at 
it).


What I propose for mkvmlinuz is:

-fix the po-debconf thing in SVN
-include the Swedish translation
-post a call for updates to -i18n with a 7-days delay
-commit all received updates (I'll receive them directly as this is much 
simpler)

-ping Sven for an upload

If you're OK, please allow "cperrier-guest" and not "bubulle" for commit 
access. I am in too many projects in Alioth now and it causes commit 
problems (see my recent blog post about this).




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