Re: prepare 2.6.13
Horms wrote: On Mon, Aug 29, 2005 at 07:05:59PM +0200, Maik Zumstrull wrote: Please evaluate just how broken ATAPI-over-SATA really is right now and consider enabling it. AFAIK other distributions have been running with it since 2.6.9 or something, so it can't be all bad from an end-user POV. And I could finally use my DVD drive without compiling my own kernel (which I'm too lazy to do, anyway, so I just don't use the drive). According to correspondence that I had with Jeff Garzik the other day, distributions enabling that option is regarded as folly by upstream as they believe it is still too green. Oh well. I guess I'll just have to hope that it will go stable for .14, as I have been doing for .12 and .13. Thanks for your efforts. signature.asc Description: OpenPGP digital signature
Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
Here are the patches that I forgot to attatch to my previous post. -- Horms diff --exclude .svn -ruN a/debian/arch/alpha/config a/debian/arch/alpha/config --- a/debian/arch/alpha/config 2005-08-30 11:45:58.0 +0900 +++ a/debian/arch/alpha/config 2005-08-30 13:02:05.0 +0900 @@ -267,7 +267,6 @@ CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y -CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y @@ -298,7 +297,6 @@ CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m -CONFIG_MEGARAID_LEGACY=m CONFIG_SCSI_SATA=y CONFIG_SCSI_SATA_AHCI=m CONFIG_SCSI_SATA_SVW=m @@ -1611,7 +1609,6 @@ CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_EZUSB=y -# CONFIG_USB_EMI26 is not set CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m CONFIG_USB_LEGOTOWER=m @@ -1695,9 +1692,6 @@ CONFIG_ADFS_FS=m # CONFIG_ADFS_FS_RW is not set CONFIG_AFFS_FS=m -CONFIG_ASFS_FS=m -CONFIG_ASFS_DEFAULT_CODEPAGE= -# CONFIG_ASFS_RW is not set CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m CONFIG_BEFS_FS=m diff --exclude .svn -ruN a/debian/arch/amd64/config a/debian/arch/amd64/config --- a/debian/arch/amd64/config 2005-08-30 11:45:59.0 +0900 +++ a/debian/arch/amd64/config 2005-08-30 13:02:05.0 +0900 @@ -313,7 +313,6 @@ CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set -CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y @@ -339,7 +338,6 @@ CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m -CONFIG_MEGARAID_LEGACY=m CONFIG_SCSI_SATA=y CONFIG_SCSI_SATA_AHCI=m CONFIG_SCSI_SATA_SVW=m @@ -1251,7 +1249,6 @@ # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m -CONFIG_FB_VESA=m CONFIG_VIDEO_SELECT=y CONFIG_FB_HGA=m # CONFIG_FB_HGA_ACCEL is not set @@ -1625,9 +1622,6 @@ CONFIG_ADFS_FS=m # CONFIG_ADFS_FS_RW is not set CONFIG_AFFS_FS=m -CONFIG_ASFS_FS=m -CONFIG_ASFS_DEFAULT_CODEPAGE= -# CONFIG_ASFS_RW is not set CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m CONFIG_BEFS_FS=m diff --exclude .svn -ruN a/debian/arch/arm/config.footbridge a/debian/arch/arm/config.footbridge --- a/debian/arch/arm/config.footbridge 2005-08-30 11:45:58.0 +0900 +++ a/debian/arch/arm/config.footbridge 2005-08-30 13:02:05.0 +0900 @@ -1120,7 +1120,6 @@ CONFIG_ADFS_FS=m # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set -# CONFIG_ASFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set diff --exclude .svn -ruN a/debian/arch/arm/config.ixp4xx a/debian/arch/arm/config.ixp4xx --- a/debian/arch/arm/config.ixp4xx 2005-08-30 11:45:58.0 +0900 +++ a/debian/arch/arm/config.ixp4xx 2005-08-30 13:02:05.0 +0900 @@ -1052,7 +1052,6 @@ # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set -# CONFIG_ASFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set diff --exclude .svn -ruN a/debian/arch/arm/config.rpc a/debian/arch/arm/config.rpc --- a/debian/arch/arm/config.rpc2005-08-30 11:45:58.0 +0900 +++ a/debian/arch/arm/config.rpc2005-08-30 13:02:05.0 +0900 @@ -266,7 +266,6 @@ CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y -# CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs @@ -795,7 +794,6 @@ CONFIG_ADFS_FS=y # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set -# CONFIG_ASFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set diff --exclude .svn -ruN a/debian/arch/config a/debian/arch/config --- a/debian/arch/config2005-08-30 11:45:59.0 +0900 +++ a/debian/arch/config2005-08-30 13:02:05.0 +0900 @@ -178,3 +178,6 @@ CONFIG_TCG_NSC=m # CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set CONFIG_6PACK=m +CONFIG_SCSI_QLA2XXX=m +# CONFIG_USB_EMI26 is not set +# CONFIG_FB_VESA is not set diff --exclude .svn -ruN a/debian/arch/hppa/config a/debian/arch/hppa/config --- a/debian/arch/hppa/config 2005-08-30 11:45:59.0 +0900 +++ a/debian/arch/hppa/config 2005-08-30 13:02:05.0 +0900 @@ -275,7 +275,6 @@ CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m -CONFIG_CHR_DEV_SCH=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs @@ -308,7 +307,6 @@ # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_MEGARAID_NEWGEN is not set -CONFIG_MEGARAID_LEGACY=m # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set @@ -1434,7 +1432,6 @@ # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set -# CONFIG_ASFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set diff --exclude .svn -ruN a/debian/arch/hppa/config.parisc
Re: Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
On Tue, Aug 30, 2005 at 04:51:53PM +0900, Horms wrote: Here are the patches that I forgot to attatch to my previous post. You removed the ASFS entries. Did you used non-debian sources? Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, Day of the Dove, stardate unknown signature.asc Description: Digital signature
Re: prepare 2.6.13
On Tuesday 30 August 2005 07:47, you wrote: - initrd-tools needs to loose devfs usage. BTW, isn't it time to switch to initramfs ? I saw that ubuntu use initramfs-tools and in debian we have yaird that I personally use since it hit sid to boot from lvm on a md array. My personal believe is that something like yaird will produce smaller intram filesystems, and thus better suited to arches and subarches who have actually trouble with bigger bloated initrds. This is sure but I think will be a really nice feature to have in etch, with initramfs-tools concept we could change hardware quite a few and expect our beloved debian to boot without problem, recognizing at startup that e.g. we changed the mainboard and cpu so the old sata disc is mounted on a sas controller and change the module to load without leaving a un-bootable sistem like out actual mkinitrd and it seems also yaird. I am also a bit curious how initramfs behaves on the kernel wise, i mean i understand and all that it is just a bunch of cpio archives which are copied at the end of the kernel, but, taking the powerpc case for an example, there is either a bootwrapper, like the arch/ppc/boot/openfirmware stuff, or boot loaders, like yaboot, who know how to put the kernel and initrd in ram, and then pass the right info to the kernel to find the ramdisk back (passed as argument in r3/r4 if i remember well. I remebered booting linux from the destkop gui on in my Amiga times... Now, initramfs is nothing more than a file organisation which is a bit different for the initial ramdisk, or is there more to it, and the above code path, for which i have seen no major change recently, will still work ? The question is : we want to support nice things like EVMS at boot time? A tool for generating bootable initrd for evms is needed, it is targeted for etch evms support I hope. It seems that none our 3 tools supports it right now. -- ESC:wq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Fri, Aug 26, 2005 at 05:53:38PM -0400, Andres Salomon wrote: On Thu, Aug 25, 2005 at 05:53:41PM +0900, Horms wrote: [...] svk may be different, if so, this is a excellent time to discuss that. It just gets crazy if it can't find merge points. Could you elaborate a little. I think you are the only one using svk at this point. So perhaps you are seeing problems that aren't apparent when svn is used. When you say merge point? Does svk dictate that your head is in trunk/ and directories in branch/ are siblings of it? Or is it just a matter of knowing where each tree is in the overall hierachy. If we're going to start catering towards people using the kernel repository with distribution revision control tools, why not just use a proper distributed revision control system? I'm quite tired of dealing w/ SVN; I consider all these discussions about branches, naming, etc to be a complete waste of time brought about by SVN's utterly stupid (lack of) branching and naming policy. When doing offline development, I've tended to work using bazaar; online development usually consists of me flooding #debian-kernel with minor little commits, as well as dealing w/ conflicts as people write changelog entries at the same time I do. It feels a whole lot like SVN wastes a lot more time than it saves. I can deal w/ SVN for the immediate future, but if people start using svk anyways, I suggest we simply switch to something like git(/cogito) or bzr. Bastian seems to have gone ahead and rearanged SVN to his own liking, so I'll close the book on trying to discuss that out on this list. I like your idea of using bzr, for starters, it has branching and merging. For seconds, people can do this however they please, so we don't need these tedious debates. And there are all sorts of other good things, like with ubuntu, which might well make things like security patches less of a burden. Questions 1. How, if at all, do you interface baz/bzr with svn. Is it just a manual process? 2. Who doesn't want to use baz/bzr instead of svn. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
On Tue, Aug 30, 2005 at 10:24:48AM +0200, Bastian Blank wrote: On Tue, Aug 30, 2005 at 04:51:53PM +0900, Horms wrote: Here are the patches that I forgot to attatch to my previous post. You removed the ASFS entries. Did you used non-debian sources? Perhaps there were some patches missing. I was working with source tree from linux-2.6 2.6.12-5 as follows. apt-get source linux-2.6 cd linux-2.6 rsync -av $SVN/branches/dists/sid/kernel/linux-2.6/debian/ debian/ --exclude .svn $SVN/trunk/scripts/split-config quit makemenu diff --exclude .svn -ru $SVN/branches/dists/sid/kernel/linux-2.6/debian/ debian/ How can I make sure all the patches from svn have been applied? I don't think debian/rules apply works the way that it used to. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.1 Sarge kernel 2.4 kernel boots Ok, 2.6 fails to detect IDEs.
G'day, All seems to be working now. Thanks. Last thing to do will be to recompile the kernel to switch on SMP support. Other than that the latest stable 2.6.13 works well. I had to create an initrd with the necessary drivers for the SATA drive and actually built in the CD/DVD driver (I guess that could have been a module too - but eh if it works the way it is...). Cheers. James. On Sat, 2005-08-27 at 12:06 +1000, james wrote: On Fri, 2005-08-26 at 23:33 +0200, Frans Pop wrote: On Friday 26 August 2005 23:03, james wrote: I bought a new PC the other day. P4 3.0G with 64Bit extensions. I tried the install of the 2.6. kernel and the CD/DVD was not detected. Looking back through dmesg there was stuff about ide ports already in use - rubbish. Not rubbish actually, but extremely accurate. Watch out with statements like that when you ask for help... See: http://www.debian.org/releases/sarge/debian-installer/index#errata (the workaround listed there will probably work for you) Ok. Point taken. Rubbish was possibly no the best choice of descriptors - Lets say the message was confusing, until you explain the underlying reason ;-). Have downloaded the latest stable kernel to try. Thanks for the advice, will let you know if it works for me. Cheers, James. Sata support in 2.6.8 kernel is limited. You may want to try the daily builds of the installer using 2.6.12 from: http://www.debian.org/releases/sarge/debian-installer/ I noticed the people who assembled it attached the CD/DVD to IDE0 and the HD to IDE1 - thus the CD/DVD comes out on /dev/hda and the HD on /dev/hdc. With proper Sata drivers the HD should be recognized as /dev/sda (scsi) instead of ide. What more info is needed to track down the root cause and get the 2.6 kernel to work? Use newer version of the kernel. 2.6.8 is unlikely to be fixed. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
#debian-kernel on irc.oftc.net
Due to growing frustrations with the continual changes to the irc infastructure on freenode.net, such as no longer being able to send messages as an unregistered user, many of the people #debian-kernel are now on that channel on irc.oftc.net. I am one of these people. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: #debian-kernel on irc.oftc.net
On Tue, Aug 30, 2005 at 06:08:56PM +0900, Horms wrote: Due to growing frustrations with the continual changes to the irc infastructure on freenode.net, such as no longer being able to send messages as an unregistered user, This is incorrect. User are able to decide if they want messages from unregistered users. Bastian -- Immortality consists largely of boredom. -- Zefrem Cochrane, Metamorphosis, stardate 3219.8 signature.asc Description: Digital signature
Re: #debian-kernel on irc.oftc.net
* Bastian Blank ([EMAIL PROTECTED]) [050830 11:22]: On Tue, Aug 30, 2005 at 06:08:56PM +0900, Horms wrote: Due to growing frustrations with the continual changes to the irc infastructure on freenode.net, such as no longer being able to send messages as an unregistered user, This is incorrect. User are able to decide if they want messages from unregistered users. Well, enough people are unhappy enough to really leave freenode now. For whatever reasons. I'm one of them. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: c2faxsend kernel oops problem
Processing commands for [EMAIL PROTECTED]: reassign 325704 linux-2.6 2.6.12-2 Bug#325704: Kernel oops with c2faxsend Bug reassigned from package `capi4hylafax' to `linux-2.6'. submitter 325704 Carsten Menke [EMAIL PROTECTED] Bug#325704: Kernel oops with c2faxsend Changed Bug submitter from Hanno 'Rince' Wagner [EMAIL PROTECTED] to Carsten Menke [EMAIL PROTECTED]. owner 325704 [EMAIL PROTECTED] Bug#325704: Kernel oops with c2faxsend Owner recorded as [EMAIL PROTECTED] 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: Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
On Tue, Aug 30, 2005 at 06:47:41PM +0900, Horms wrote: I am also still wondering if there is any interest in consolodating the entirel fs configuration, which seems a bit of a mess right now - e.g. compare the EXT2/3 options for different arches and flavours. Yes it is. You can try to use split-config, but you have to check each option against the dependencies and be very carefully. Too make our lives a little bit easier, I currently think about a kconfig like tool which can read more than on config file and aggregate changes in such splitted config. Bastian -- Dammit Jim, I'm an actor, not a doctor. signature.asc Description: Digital signature
Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
On Tue, Aug 30, 2005 at 12:39:27PM +0200, Bastian Blank wrote: On Tue, Aug 30, 2005 at 06:47:41PM +0900, Horms wrote: I am also still wondering if there is any interest in consolodating the entirel fs configuration, which seems a bit of a mess right now - e.g. compare the EXT2/3 options for different arches and flavours. Yes it is. You can try to use split-config, but you have to check each option against the dependencies and be very carefully. Too make our lives a little bit easier, I currently think about a kconfig like tool which can read more than on config file and aggregate changes in such splitted config. I agree that the current split-config is somehat limited with regards to this task. What do you have in mind for a new tool? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH 0/2] Debian mkinitrd: Integrate kdump
On Tue, Aug 30, 2005 at 02:59:15AM -0400, Andres Salomon wrote: On Tue, 2005-08-30 at 12:23 +0530, Rachita Kothiyal wrote: [...] I had sent the patch to Jeff Bailey, Bastian Blank, Steve Langasek and the debian-kernel list. But have not received any comments from them so far. We have been considering porting this solution to the initramfs approach also, but since initrd is more widely used thought it to be a better platform. When in the future do you think this switch to initramfs will happen? Now that 2.6.13 is out (with its dropped devfs support, which initrd-tools requires atm), one of two things will happen; we'll either port initrd-tools to support non-devfs (unlikely), re-add devfs to 2.6.13, or switch to initramfs. I'm going to be playing around w/ it soon, so I have a better idea which would be the best solution. Thanks Andres for the info. kexec/kdump kernel code has been merged with 2.6 mainline since 2.6.13-rc1. I was wondering whom shall I contact for kdump integration on Debian. Having initrd/initramfs support for kdump is just one of things needed for kdump integration. Other stuffs like including the user space kexec-tools with kdump support with Debian distribution, enabling CONFIG_KEXEC in Debian kernel, and packaging dump capture kernel etc. Thanks Rachita PS: Putting debian-kernel again on CC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
On Tue, Aug 30, 2005 at 05:58:35PM +0900, Horms wrote: On Tue, Aug 30, 2005 at 10:24:48AM +0200, Bastian Blank wrote: On Tue, Aug 30, 2005 at 04:51:53PM +0900, Horms wrote: Here are the patches that I forgot to attatch to my previous post. You removed the ASFS entries. Did you used non-debian sources? Perhaps there were some patches missing. I was working with source tree from linux-2.6 2.6.12-5 as follows. apt-get source linux-2.6 cd linux-2.6 rsync -av $SVN/branches/dists/sid/kernel/linux-2.6/debian/ debian/ --exclude .svn $SVN/trunk/scripts/split-config quit makemenu diff --exclude .svn -ru $SVN/branches/dists/sid/kernel/linux-2.6/debian/ debian/ How can I make sure all the patches from svn have been applied? I don't think debian/rules apply works the way that it used to. Ok, I worked out that I need to run the following to get the patches, override_version=2.6.12-6 sh ./debian/bin/apply After I do so I don't get any discrepancies, so the default.patch I posted is bogus, please ignore it. I have attached a replacement reiserfs.patch for consideration. I am also still wondering if there is any interest in consolodating the entirel fs configuration, which seems a bit of a mess right now - e.g. compare the EXT2/3 options for different arches and flavours. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299204: Fixed except for sarge d-i
tags +sarge thanks This bug only remains present in kernel revision -8 as used by sarge's debian-installer. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Fixed except for sarge d-i
Processing commands for [EMAIL PROTECTED]: tags 299204 +sarge Bug#299204: strace: unusable on mipsel Tags were: confirmed Tags added: sarge 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: prepare 2.6.13
On Tue, Aug 30, 2005 at 10:40:12AM +0200, Marco Amadori wrote: On Tuesday 30 August 2005 07:47, you wrote: - initrd-tools needs to loose devfs usage. BTW, isn't it time to switch to initramfs ? I saw that ubuntu use initramfs-tools and in debian we have yaird that I personally use since it hit sid to boot from lvm on a md array. My personal believe is that something like yaird will produce smaller intram filesystems, and thus better suited to arches and subarches who have actually trouble with bigger bloated initrds. This is sure but I think will be a really nice feature to have in etch, with initramfs-tools concept we could change hardware quite a few and expect our beloved debian to boot without problem, recognizing at startup that e.g. we changed the mainboard and cpu so the old sata disc is mounted on a sas controller and change the module to load without leaving a un-bootable sistem like out actual mkinitrd and it seems also yaird. Well, agreed, both have their place. I think some of our supported arches will like a yaird-like situation or at least a more user-controlled initrd situation better over a huge bloated all-encompassing initramfs. I am also a bit curious how initramfs behaves on the kernel wise, i mean i understand and all that it is just a bunch of cpio archives which are copied at the end of the kernel, but, taking the powerpc case for an example, there is either a bootwrapper, like the arch/ppc/boot/openfirmware stuff, or boot loaders, like yaboot, who know how to put the kernel and initrd in ram, and then pass the right info to the kernel to find the ramdisk back (passed as argument in r3/r4 if i remember well. I remebered booting linux from the destkop gui on in my Amiga times... Well, yes, but this is not the question, the question is how the kernel knows about initramfs, beyond the way yaboot, lilo, amiboot or whatever gets this info from the user. Now, initramfs is nothing more than a file organisation which is a bit different for the initial ramdisk, or is there more to it, and the above code path, for which i have seen no major change recently, will still work ? The question is : we want to support nice things like EVMS at boot time? A tool for generating bootable initrd for evms is needed, it is targeted for etch evms support I hope. It seems that none our 3 tools supports it right now. But right now is the time to investigate those issues, and fix the tools if possible, and not 6-12 month down the road, when we will be in late-freeze situation or something. Let's maybe list all the things we want for sucha tool. My personal requisite are : - allow as well for the creation of generic images, as well as minimal ones. - allow for hand selected inclusion list as well as exclusion of modules. - allow to include script as well as mklibs-manipulated binaries and libraries. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Tue, Aug 30, 2005 at 05:41:34PM +0900, Horms wrote: On Fri, Aug 26, 2005 at 05:53:38PM -0400, Andres Salomon wrote: On Thu, Aug 25, 2005 at 05:53:41PM +0900, Horms wrote: [...] svk may be different, if so, this is a excellent time to discuss that. It just gets crazy if it can't find merge points. Could you elaborate a little. I think you are the only one using svk at this point. So perhaps you are seeing problems that aren't apparent when svn is used. When you say merge point? Does svk dictate that your head is in trunk/ and directories in branch/ are siblings of it? Or is it just a matter of knowing where each tree is in the overall hierachy. If we're going to start catering towards people using the kernel repository with distribution revision control tools, why not just use a proper distributed revision control system? I'm quite tired of dealing w/ SVN; I consider all these discussions about branches, naming, etc to be a complete waste of time brought about by SVN's utterly stupid (lack of) branching and naming policy. When doing offline development, I've tended to work using bazaar; online development usually consists of me flooding #debian-kernel with minor little commits, as well as dealing w/ conflicts as people write changelog entries at the same time I do. It feels a whole lot like SVN wastes a lot more time than it saves. I can deal w/ SVN for the immediate future, but if people start using svk anyways, I suggest we simply switch to something like git(/cogito) or bzr. Bastian seems to have gone ahead and rearanged SVN to his own liking, so I'll close the book on trying to discuss that out on this list. I like your idea of using bzr, for starters, it has branching and merging. For seconds, people can do this however they please, so we don't need these tedious debates. And there are all sorts of other good things, like with ubuntu, which might well make things like security patches less of a burden. Questions 1. How, if at all, do you interface baz/bzr with svn. Is it just a manual process? 2. Who doesn't want to use baz/bzr instead of svn. Just a quick question, as i am not familiar with either revision control system, but wouldn't it make more sense to use git, seeing as the kernel is using it, and we could then even handle our own whole kernel tree in it, tracking upstream or whatever. Not sure about the difference between them though, and if this makes sense or not, but as far as learning yet-another-versioning-system, i guess it is easier to learn the one used by upstream kernel developers. And is baz/bzr different or mostly the same as uncomprehensible arch/tla ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325726: kernel-image-2.6.8-11-amd64-generic: kernel panics/hangs (SATA related?)
Package: kernel-image-2.6.8-11-amd64-generic
Version: 2.6.8-14
Severity: critical
Justification: breaks the whole system
Keep getting lockups, in particular whilst trying to sync a RAID5 array across
several SATA drives.
Setting a RAID1 partition across the same drives seems to work OK though. I've
managed to get one set of errors from the syslog:
Aug 30 13:20:18 boromir kernel: ata6: command 0x25 timeout, stat 0x50 host_stat
0x61
Aug 30 13:20:18 boromir kernel: Assertion failed! qc-flags
ATA_QCFLAG_ACTIVE,drivers/scsi/libata-core.c,ata_qc_complete,line=2315
Aug 30 13:20:18 boromir kernel: --- [cut here ] - [please bite
here ] -
Aug 30 13:20:18 boromir kernel: Kernel BUG at scsi:284
Aug 30 13:20:18 kernel: invalid operand: [1]
Aug 30 13:20:18 kernel: CPU 0
Aug 30 13:20:18 kernel: Modules linked in: nls_cp437 isofs evdev 8139cp shpchp
pciehp pci_hotplug forcedeth ide_scsi psmouse genrtc
ext3 jbd raid5 xor raid0 eth1394 8139too mii sr_mod sbp2 sd_mod ide_cd cdrom
ide_disk ide_generic pdc202xx_new aec62xx alim15x3 amd74xx atii
xp cmd64x cs5520 cs5530 cy82c693 generic hpt34x ns87415 opti621 pdc202xx_old
piix rz1000 sc1200 serverworks siimage sis5513 slc90e66 triflex
trm290 via82cxxx floppy usb_storage ide_core ohci1394 ieee1394 fbcon vga16fb
vgastate usbserial usbkbd ehci_hcd ohci_hcd thermal processor
fan sata_sis sata_nv libata scsi_mod raid1 md unix font vesafb cfbcopyarea
cfbimgblt cfbfillrect
Aug 30 13:20:18 kernel: Pid: 221, comm: scsi_eh_5 Not tainted
2.6.8-11-amd64-generic
Aug 30 13:20:18 kernel: RIP: 0010:[_end+533152296/2133114880]
a0028228{:scsi_mod:scsi_put_command+27}
Aug 30 13:20:18 kernel: RSP: 0018:01003f82bd98 EFLAGS: 00010046
Aug 30 13:20:18 kernel: RAX: 01003f9df000 RBX: 01003f9e09b0 RCX:
01003e9b6ae0
Aug 30 13:20:18 kernel: RDX: 01003e9b6ae0 RSI: 01003f9e2000 RDI:
01003e9b6ac0
Aug 30 13:20:18 kernel: RBP: 01003e9b6ac0 R08: R09:
00800150
Aug 30 13:20:18 kernel: R10: 0246 R11: 80146787 R12:
0001
Aug 30 13:20:18 kernel: R13: 0001 R14: 01003f9e09b0 R15:
Aug 30 13:20:18 kernel: FS: 002a958ab640() GS:80391580()
knlGS:
Aug 30 13:20:18 kernel: CS: 0010 DS: ES: CR0: 8005003b
Aug 30 13:20:18 kernel: CR2: 002a955b2000 CR3: 00101000 CR4:
06e0
Aug 30 13:20:18 kernel: Process scsi_eh_5 (pid: 221, threadinfo
01003f82a000, task 01003f8049c0)
Aug 30 13:20:18 kernel: Stack: 0206 a002c739
010039948990 a002c815
Aug 30 13:20:18 kernel:010039948990 0206
0001 01003e9b6ac0
Aug 30 13:20:18 kernel:010039948990
Aug 30 13:20:18 kernel: Call
Trace:a002c739{:scsi_mod:scsi_next_command+14}
Aug 30 13:20:18 kernel:
a002c815{:scsi_mod:scsi_end_request+167}
Aug 30 13:20:18 kernel:
a002ca9a{:scsi_mod:scsi_io_completion+493}
Aug 30 13:20:18 kernel:
a004b8cf{:libata:ata_scsi_qc_complete+63}
Aug 30 13:20:18 kernel:a0049409{:libata:ata_qc_complete+278}
a004b6ad{:libata:ata_scsi_error+16}
Aug 30 13:20:18 kernel:
a002b609{:scsi_mod:scsi_error_handler+284}
Aug 30 13:20:18 kernel:80110687{child_rip+8}
a002b4ed{:scsi_mod:scsi_error_handler+0}
Aug 30 13:20:18 kernel:8011067f{child_rip+0}
Aug 30 13:20:18 kernel:
Aug 30 13:20:18 kernel: Code: 0f 0b 8d 1a 03 a0 ff ff ff ff 1c 01 48 8b 42 08
48 89 41 08
Aug 30 13:20:18 kernel: RIP a0028228{:scsi_mod:scsi_put_command+27}
RSP 01003f82bd98
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-11-amd64-generic
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Versions of packages kernel-image-2.6.8-11-amd64-generic depends on:
ii coreutils [fileutils] 5.2.1-2 The GNU core utilities
ii e2fsprogs 1.37-2sarge1 ext2 file system utilities and lib
ii initrd-tools0.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]
Re: prepare 2.6.13
Sven Luther [EMAIL PROTECTED] writes: On Mon, Aug 29, 2005 at 11:40:47AM +0200, Bastian Blank wrote: Hi folks BTW, was 2.6.13 already released ? Or any idea when it will be ? Yes. Yestarday IIRC. Maybe a good plan would be to get 2.6.12 in testing, and then switch to 2.6.13 and initramfs ? Why not to use experimental to 2.6.13 while the team continue to work on 2.6.12 for testing? -- 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]
kernel htmldocs partialy failed?
Hello all, Just looking to build the kernel doc (htmldoc to be accurate) of the latest parisc-linux cvs kernel 2.6.13-pa0, I fist install xmlto dpkg then after my usual: # make oldconfig # make V=1 vmlinux I play with: # make htmldocs which build the *.xml for the most but failed at the ending: DOCPROC Documentation/DocBook/kernel-api.xml with following warnings and errors: Warning(/CAD/linux-2.6.13-pa0-20050829/kernel/sched.c:1495): No description found for parameter 'rq' Use of uninitialized value in join or string at /CAD/linux-2.6.13-pa0-20050829/scripts/kernel-doc line 369, IN line 698. Warning(/CAD/linux-2.6.13-pa0-20050829/mm/slab.c:2793): No description found for parameter 'unused' Warning(/CAD/linux-2.6.13-pa0-20050829/arch/i386/lib/usercopy.c): no structured comments found Warning(/CAD/linux-2.6.13-pa0-20050829/ipc/util.c:373): No description found for parameter 'head' Warning(/CAD/linux-2.6.13-pa0-20050829/ipc/util.c:390): No description found for parameter 'head' Warning(/CAD/linux-2.6.13-pa0-20050829/kernel/sysctl.c:2012): No description found for parameter 'ppos' Warning(/CAD/linux-2.6.13-pa0-20050829/include/linux/fs.h:1190): No description found for parameter 'find_exported_dentry' Warning(/CAD/linux-2.6.13-pa0-20050829/include/linux/fs.h:1190): No description found for parameter 'find_exported_dentry' Warning(/CAD/linux-2.6.13-pa0-20050829/include/linux/fs.h): no structured comments found Warning(/CAD/linux-2.6.13-pa0-20050829/kernel/irq/manage.c:31): No description found for parameter 'irq' Warning(/CAD/linux-2.6.13-pa0-20050829/kernel/irq/manage.c): no structured comments found Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/pci.c:238): No description found for parameter 'platform_pci_set_power_state' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/pci-driver.c:35): No description found for parameter 'driver' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/pci-driver.c:35): No description found for parameter 'buf' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/pci-driver.c:35): No description found for parameter 'count' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/pci-driver.c:174): No description found for parameter 'drv' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/pci-driver.c:174): No description found for parameter 'pci_dev' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/pci-driver.c:416): No description found for parameter 'drv' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/msi.c:598): No description found for parameter 'entries' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/msi.c:598): No description found for parameter 'nvec' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/hotplug.c): no structured comments found Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/pci/probe.c:663): No description found for parameter 'dev' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/driver.c:39): No description found for parameter 'start' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/driver.c:76): No description found for parameter 'drv' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/core.c:390): No description found for parameter 'parent' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:75): No description found for parameter 'class' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:75): No description found for parameter 'buf' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:75): No description found for parameter 'count' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:136): No description found for parameter 'class_dev' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:136): No description found for parameter 'buf' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:136): No description found for parameter 'count' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:239): No description found for parameter 'kobj' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:239): No description found for parameter 'buffer' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:239): No description found for parameter 'offset' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:239): No description found for parameter 'count' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:404): No description found for parameter 'firmware_p' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:404): No description found for parameter 'name' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:404): No description found for parameter 'device' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:462): No description found for parameter 'fw' Warning(/CAD/linux-2.6.13-pa0-20050829/drivers/base/firmware_class.c:480): No description found for parameter 'name'
Re: SVN layout
On Tue, 2005-08-30 at 15:33 +0200, Sven Luther wrote:
On Tue, Aug 30, 2005 at 05:41:34PM +0900, Horms wrote:
On Fri, Aug 26, 2005 at 05:53:38PM -0400, Andres Salomon wrote:
On Thu, Aug 25, 2005 at 05:53:41PM +0900, Horms wrote:
[...]
svk may be different, if so,
this is a excellent time to discuss that.
It just gets crazy if it can't find merge points.
Could you elaborate a little. I think you are the only one using
svk at this point. So perhaps you are seeing problems that aren't
apparent when svn is used.
When you say merge point? Does svk dictate that your head is
in trunk/ and directories in branch/ are siblings of it?
Or is it just a matter of knowing where each tree is in
the overall hierachy.
If we're going to start catering towards people using the kernel
repository with distribution revision control tools, why not just
use a proper distributed revision control system? I'm quite tired
of dealing w/ SVN; I consider all these discussions about branches,
naming, etc to be a complete waste of time brought about by SVN's
utterly stupid (lack of) branching and naming policy. When doing
offline development, I've tended to work using bazaar; online
development usually consists of me flooding #debian-kernel with minor
little commits, as well as dealing w/ conflicts as people write
changelog entries at the same time I do. It feels a whole lot like
SVN wastes a lot more time than it saves.
I can deal w/ SVN for the immediate future, but if people start using
svk anyways, I suggest we simply switch to something like git(/cogito)
or bzr.
Bastian seems to have gone ahead and rearanged SVN to his own liking,
so I'll close the book on trying to discuss that out on this list.
I like your idea of using bzr, for starters, it has
branching and merging. For seconds, people can do
this however they please, so we don't need these tedious
debates. And there are all sorts of other good things,
like with ubuntu, which might well make things like
security patches less of a burden.
Questions
1. How, if at all, do you interface baz/bzr with svn.
Is it just a manual process?
What do you mean, interface? Do you mean converting the repository?
If there's not already svn2bzr and svn2git tools, I can't imagine they'd
be that difficult to create (there's already various other tools to
convert between the various free RCS's). Or do you mean keeping the
main repository in svn while working locally w/ baz/bzr? For me, it's
been a manual process; I've only recently started using bzr, my offline
debian-kernel stuff has been done using baz.
2. Who doesn't want to use baz/bzr instead of svn.
Well, to clarify; I wouldn't want to use baz. It's inflexible and
difficult to use (thanks to its tla ancestry). However, bzr would
certainly make a fine choice, and it's pretty simple to use.
Just a quick question, as i am not familiar with either revision control
system, but wouldn't it make more sense to use git, seeing as the kernel is
using it, and we could then even handle our own whole kernel tree in it,
tracking upstream or whatever. Not sure about the difference between them
I don't think it would make too much of a difference; both have pros and
cons. However, both are also under heavy development; so, their
downsides are quickly becoming less and less. I don't think upstream's
choice should really affect ours. My main concern w/ using either of
them is their source format changing, breaking things; for example, I
maintain gitweb, and have had problems w/ newer versions of git/cogito
entering sid that completely break gitweb.
though, and if this makes sense or not, but as far as learning
yet-another-versioning-system, i guess it is easier to learn the one used by
upstream kernel developers.
The learning curve for both is pretty minimal.
And is baz/bzr different or mostly the same as uncomprehensible arch/tla ?
baz is pretty incomprehensible. bzr is not; it's about as easy to use,
if not easier, than svn. cogito is pretty easy to use as well; however,
the command line usage takes a bit of getting used to (instead of
{cvs,svn,bzr} command, commands are in the form cg-command for
example). I use both regularly; my worst problem with them tends to be
running bzr commands in a git repository, or vice versa. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
On Tue, Aug 30, 2005 at 01:20:37PM +0900, Horms wrote: Appart from my general feeling that no one should use Reiser FS, Why is that? I mean, certainly every filesystem has its problems, but I don't think there's a consensus that ReiserFS is much worse than the others? I personally find it useful because it doesn't have any limitation on the number of inodes. -- David A. Madore ([EMAIL PROTECTED], http://www.madore.org/~david/ ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325726: kernel-image-2.6.8-11-amd64-generic: kernel panics/hangs (SATA related?)
Hello, 2.6.8 has known issues with software-raid. You can try a newer kernel, preferably linux-image-2.6.12-1-amd64-k8 from unstable - unless you are using udev, then you need to uninstall udev first (or use a backport). is this problem reproducible with a 2.6.12 debian kernel? By the way: you should not use the -generic flavour wich is intended for the debian installer only, but either the amd64-k8(-smp) or em64t-p4(-smp) flavours depending on your box having an amd or intel processor. those kernels are optimized for the respective architecture (cache alignment, compiler options etc). Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#325744: kernel-image-2-686: Symlink lib/modules/2.6.8-2-386/source pointing nowhere
Package: kernel-image-2.6.8-2-386 Version: 2.6.8-16 Priority: minor Tags: sarge sid I have a cron job running Tiger (default installation) and it will complain in a sarge system because of this: $ ls -la /lib/modules/2.6.8-2-386/source lrwxrwxrwx 1 root root 100 2005-06-07 00:09 /lib/modules/2.6.8-2-386/source - /home/horms/tmp/debian-kernel-test/kernel-image-2.6.8-i386/kernel-image-2.6.8-i386-2.6.8/install-386 $ dpkg -S /lib/modules/2.6.8-2-386/source kernel-image-2.6.8-2-386: /lib/modules/2.6.8-2-386/source Obviously, there is no /home/horms/tmp/ directory in my system. Regards Javier signature.asc Description: Digital signature
Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
David Madore wrote: On Tue, Aug 30, 2005 at 01:20:37PM +0900, Horms wrote: Appart from my general feeling that no one should use Reiser FS, Why is that? I mean, certainly every filesystem has its problems, but I don't think there's a consensus that ReiserFS is much worse than the others? I personally find it useful because it doesn't have any limitation on the number of inodes. Exactly those dynamic on-disk structures make it hard to do useful recovery in case of unexpected (e.g. hardware-) errors. More conservatively designed filesystems have better chances to keep the damage to a minimum. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH 0/2] Debian mkinitrd: Integrate kdump
On Tue, 2005-08-30 at 15:18 +0530, Rachita Kothiyal wrote: On Tue, Aug 30, 2005 at 02:59:15AM -0400, Andres Salomon wrote: On Tue, 2005-08-30 at 12:23 +0530, Rachita Kothiyal wrote: [...] I had sent the patch to Jeff Bailey, Bastian Blank, Steve Langasek and the debian-kernel list. But have not received any comments from them so far. We have been considering porting this solution to the initramfs approach also, but since initrd is more widely used thought it to be a better platform. When in the future do you think this switch to initramfs will happen? Now that 2.6.13 is out (with its dropped devfs support, which initrd-tools requires atm), one of two things will happen; we'll either port initrd-tools to support non-devfs (unlikely), re-add devfs to 2.6.13, or switch to initramfs. I'm going to be playing around w/ it soon, so I have a better idea which would be the best solution. Thanks Andres for the info. kexec/kdump kernel code has been merged with 2.6 mainline since 2.6.13-rc1. I was wondering whom shall I contact for kdump integration on Debian. Having initrd/initramfs support for kdump is just one of things needed for kdump integration. Other stuffs like including the user space kexec-tools with kdump support with Debian distribution, enabling CONFIG_KEXEC in Debian kernel, and packaging dump capture kernel etc. fyi, Khalid Aziz has packaged kexec-tools and will be uploading it RSN. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318120: initrd-tools: more info fstab with LABEL
Package: initrd-tools Version: 0.1.82 Severity: normal Followup-For: Bug #318120 I'm also see : /usr/sbin/mkinitrd: /dev/i2o/hda4: Unknown root device Please refer to the manual page. Failed to create initrd image. My fstab: LABEL=/ / ext2defaults,errors=remount-ro 0 1 /dev/i2o/hda2 noneswapsw 0 0 LABEL=/var /varext2rw 0 2 /dev/xfs_vg/xfs_part1 /mnt/xfs1 xfs rw,usrquota 03 /dev/xfs_vg/xfs_part2 /mnt/xfs2 xfs rw,usrquota 03 there is no hda4 -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=C Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii cpio 2.5-1.1GNU cpio -- a program to manage ar ii cramfsprogs 1.1-4 Tools for CramFs (Compressed ROM F ii dash 0.4.24 The Debian Almquist Shell ii fileutils 5.0.91-2 The GNU file management utilities ii util-linux2.12p-4Miscellaneous system utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
On Tue, Aug 30, 2005 at 12:12:59PM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: On Mon, Aug 29, 2005 at 11:40:47AM +0200, Bastian Blank wrote: Hi folks BTW, was 2.6.13 already released ? Or any idea when it will be ? Yes. Yestarday IIRC. Maybe a good plan would be to get 2.6.12 in testing, and then switch to 2.6.13 and initramfs ? Why not to use experimental to 2.6.13 while the team continue to work on 2.6.12 for testing? This is the plan. Bastian messed up all the subversion layout though, so we first need to sort this out and reorganize the team before we do some releasing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dvdrtools fails to work as non-root.
Package: dvdrtools Version: 0.2.1-1 Severity: normal Well, doing anything on DVD-RW media as non root yields : $ dvdrecord -v dev=ATAPI:/dev/hdd blank=fast dvdrtools v0.2.1 Portions (C) 2002-2005 Ark Linux [EMAIL PROTECTED] This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; see the file COPYING. If not, write to the Free Software Foundation, 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. Based on: Cdrecord 1.11a15 (powerpc-unknown-linux-gnu) Copyright (C) 1995-2001 J\urg Schilling TOC Type: 1 = CD-ROM dvdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler dvdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). dvdrecord: WARNING: This causes a high risk for buffer underruns. scsidev: 'ATAPI:/dev/hdd' devname: 'ATAPI:/dev/hdd' scsibus: -2 target: -2 lun: -2 Using libscg version 'bero-0.5a' dvdrecord: Warning: using inofficial version of libscg (bero-0.5a '@(#)scsitransp.c 1.81 01/04/20 Copyright 1988,1995,2000 J. Schilling'). atapi: 1 Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'TSSTcorp' Identifikation : 'CD/DVDW TS-H552U' Revision : 'US04' Device seems to be: Generic mmc2 DVD. Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd). Driver flags : SWABAUDIO BURNFREE Supported modes: Drive buf size : 1376256 = 1344 KB dvdrecord: Operation not permitted. prevent/allow medium removal: scsi sendcmd: no error CDB: 1E 00 00 00 01 00 status: 0x0 (GOOD STATUS) cmd finished after 0.000s timeout 40s Current Secsize: 2048 ATIP start of lead in: -150 (00:00/00) Disk type:unknown dye (reserved id code) Manuf. index: 255 Manufacturer: unknown (not in table) Blocks total: 2297888 Blocks current: 1274320 Blocks remaining: 1274470 dvdrecord: Operation not permitted. mode select g1: scsi sendcmd: no error CDB: 55 10 00 00 00 00 00 00 3C 00 status: 0x0 (GOOD STATUS) cmd finished after 0.000s timeout 40s dvdrecord: Warning: using default CD write parameter data. Mode Select Data 00 41 00 00 05 32 62 04 08 10 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dvdrecord: Cannot set speed/dummy. dvdrecord: Operation not permitted. prevent/allow medium removal: scsi sendcmd: no error CDB: 1E 00 00 00 00 00 status: 0x0 (GOOD STATUS) cmd finished after 0.000s timeout 40s Running sudo to do the same works just fine. I have the device (/dev/hdd symlinked to /dev/dvd) in the group cdrom, which the user is part of, and am able to burn DVDs (but not erase them) just fine as user with growisofs. Friendly, Sven Luther -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages dvdrtools depends on: ii libc6 2.3.5-4GNU C Library: Shared libraries an dvdrtools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
growisofs: rowisofs fails to blank DVD-RW media
Package: growisofs Version: growisofs fails to blank DVD-RW media Severity: important growisofs fails to blank DVD-RW media, while writing is just fine. Here is the log : $ growisofs -Z /dev/dvd -R -J 2005.08.30/ WARNING: /dev/dvd already carries isofs! About to execute 'mkisofs -R -J 2005.08.30/ | builtin_dd of=/dev/dvd obs=32k seek=0' INFO:ingUTF-8 character encoding detected by locale settings. Assuming UTF-8 encoded filenames on source filesystem, use -input-charset to override. /dev/dvd: Current Write Speed is 2.0x1385KBps. :-[ [EMAIL PROTECTED] failed with SK=5h/ASC=21h/ACQ=02h]: Invalid argument :-( attempt to re-run with -dvd-compat -dvd-compat to engage DAO or apply full blanking procedure :-( write failed: Invalid argument using -dvd-compat twice as suggested didn't help at all, as for DAO and full blanking, the man page doesn't provide any usefull hint on what this means. Would be nice to have this finally fixed for etch, as i believe this is still somewhat broken for sarge. Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prepare 2.6.13
On Tue, Aug 30, 2005 at 03:26:29PM +0200, Sven Luther wrote: On Tue, Aug 30, 2005 at 10:40:12AM +0200, Marco Amadori wrote: Now, initramfs is nothing more than a file organisation which is a bit different for the initial ramdisk, or is there more to it, and the above code path, for which i have seen no major change recently, will still work ? From memory: You can feed the kernel a file system in eg cramfs format from grub or another boot loader, and it will be treated like initrd. If the boot loader feeds a cpio file to the kernel, AND it contains a file named /init, it will be treated as initramfs. You can also append a cpio file to the kernel, and it will be treated as initramfs. The kernel treats initrd and initramfs differently: for initrd, the kernel does a complicated two-stage shuffle with mount, chdir, chroot and ramdisks, while initramfs just gets unpacked into rootfs and the kernel hand over control to /init. Oh, and for initrd the kernel will try to mount devfs. To summarise, to the boot loader the difference between initramfs and initrd is not important, but for initrd-tools or yaird the difference is more than just packaging with cpio or mkcramfs; you'll also need to consider what goes on the image. The question is : we want to support nice things like EVMS at boot time? A tool for generating bootable initrd for evms is needed, it is targeted for etch evms support I hope. It seems that none our 3 tools supports it right now. I'll see what can be done about yaird support of EVMS. But right now is the time to investigate those issues, and fix the tools if possible, and not 6-12 month down the road, when we will be in late-freeze situation or something. Agreed. Let's maybe list all the things we want for sucha tool. My personal requisite are : - allow as well for the creation of generic images, as well as minimal ones. - allow for hand selected inclusion list as well as exclusion of modules. - allow to include script as well as mklibs-manipulated binaries and libraries. Hmm, I was not previously aware of mklibs. Just tested it on an unpacked yaird image and found zero size reduction on a sid/i386 box, presumably because none of the included libraries have a _pic.a file. For now I have higher hopes for klibc or uclibc to reduce size, but if you can show how mklibs will pay off, I'm listening. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#325484: udev = 0.060-1 and kernels = 2.6.12
(pruning CC list; AFAIK all will still get the message this way) On Tuesday 30 August 2005 04:56, Steve Langasek wrote: So we're going to have another release with a very elaborate upgrade procedure in the release notes (which a lot of users, especially desktop users, don't read anyway)? 1) upgrade your kernel 2) dist-upgrade That doesn't seem terribly elaborate to me? And if people choose not to read, well, they get a failure on dist-upgrade and get to figure it out for themselves, I guess. Yeah, and that IMHO is exactly the problem. Debian used to be known for relatively trouble free upgrades. For the Woody-Sarge upgrade the upgrade problems (the kernel issues at least) were mostly limited to non-mainstream architectures, but now we're likely to hit 80% of Sarge desktop users. BTW, here's a first example... http://lists.debian.org/debian-boot/2005/08/msg01149.html (the poster works for Intel) pgpLTx0LVqXgX.pgp Description: PGP signature
Re: Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Tue, Aug 30, 2005 at 11:48:17PM +0200, Frans Pop wrote: (pruning CC list; AFAIK all will still get the message this way) On Tuesday 30 August 2005 04:56, Steve Langasek wrote: So we're going to have another release with a very elaborate upgrade procedure in the release notes (which a lot of users, especially desktop users, don't read anyway)? 1) upgrade your kernel 2) dist-upgrade That doesn't seem terribly elaborate to me? And if people choose not to read, well, they get a failure on dist-upgrade and get to figure it out for themselves, I guess. Yeah, and that IMHO is exactly the problem. Debian used to be known for relatively trouble free upgrades. For the Woody-Sarge upgrade the upgrade problems (the kernel issues at least) were mostly limited to non-mainstream architectures, but now we're likely to hit 80% of Sarge desktop users. No, failing to read the release notes for sarge and doing a blind dist-upgrade on a desktop system was also likely to rip out large swaths of packages in the process. I understand that we all want dist-upgrade to Just Work, but I don't see how complaining that the release notes contain important information that users ignore at their peril is different from complaining that the list of packages being removed on apt-get dist-upgrade contains important information that users ignore at their peril. If you aren't satisfied with the current solution, the answer is to figure out a better one rather than lamenting that no one else has. (I do have a vague idea of what this would entail, and I'm not willing to spend a month of my time on trying to make it work.) -- 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/ signature.asc Description: Digital signature
Re: Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Aug 31, Steve Langasek [EMAIL PROTECTED] wrote: If you aren't satisfied with the current solution, the answer is to figure out a better one rather than lamenting that no one else has. (I do have a This is where these threads usually end... -- ciao, Marco signature.asc Description: Digital signature
Bug#100421: from Numbers
it's me Numbers Invite me http://rygalytalogapu.com/view.cgi?s=bbasem=IJJFHI.iPdR,gfibjW,VSd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Tue, Aug 30, 2005 at 12:15:23PM -0400, Andres Salomon wrote: On Tue, 2005-08-30 at 15:33 +0200, Sven Luther wrote: On Tue, Aug 30, 2005 at 05:41:34PM +0900, Horms wrote: On Fri, Aug 26, 2005 at 05:53:38PM -0400, Andres Salomon wrote: On Thu, Aug 25, 2005 at 05:53:41PM +0900, Horms wrote: [...] svk may be different, if so, this is a excellent time to discuss that. It just gets crazy if it can't find merge points. Could you elaborate a little. I think you are the only one using svk at this point. So perhaps you are seeing problems that aren't apparent when svn is used. When you say merge point? Does svk dictate that your head is in trunk/ and directories in branch/ are siblings of it? Or is it just a matter of knowing where each tree is in the overall hierachy. If we're going to start catering towards people using the kernel repository with distribution revision control tools, why not just use a proper distributed revision control system? I'm quite tired of dealing w/ SVN; I consider all these discussions about branches, naming, etc to be a complete waste of time brought about by SVN's utterly stupid (lack of) branching and naming policy. When doing offline development, I've tended to work using bazaar; online development usually consists of me flooding #debian-kernel with minor little commits, as well as dealing w/ conflicts as people write changelog entries at the same time I do. It feels a whole lot like SVN wastes a lot more time than it saves. I can deal w/ SVN for the immediate future, but if people start using svk anyways, I suggest we simply switch to something like git(/cogito) or bzr. Bastian seems to have gone ahead and rearanged SVN to his own liking, so I'll close the book on trying to discuss that out on this list. I like your idea of using bzr, for starters, it has branching and merging. For seconds, people can do this however they please, so we don't need these tedious debates. And there are all sorts of other good things, like with ubuntu, which might well make things like security patches less of a burden. Questions 1. How, if at all, do you interface baz/bzr with svn. Is it just a manual process? What do you mean, interface? Do you mean converting the repository? If there's not already svn2bzr and svn2git tools, I can't imagine they'd be that difficult to create (there's already various other tools to convert between the various free RCS's). Or do you mean keeping the main repository in svn while working locally w/ baz/bzr? For me, it's been a manual process; I've only recently started using bzr, my offline debian-kernel stuff has been done using baz. I was just wondering if you had an automated process to pull changes in from svn and push them back again. 2. Who doesn't want to use baz/bzr instead of svn. Well, to clarify; I wouldn't want to use baz. It's inflexible and difficult to use (thanks to its tla ancestry). However, bzr would certainly make a fine choice, and it's pretty simple to use. I tend to agree, though my experience with them is limited. In any case, I beleive they are compatible. Just a quick question, as i am not familiar with either revision control system, but wouldn't it make more sense to use git, seeing as the kernel is using it, and we could then even handle our own whole kernel tree in it, tracking upstream or whatever. Not sure about the difference between them I don't think it would make too much of a difference; both have pros and cons. However, both are also under heavy development; so, their downsides are quickly becoming less and less. I don't think upstream's choice should really affect ours. My main concern w/ using either of them is their source format changing, breaking things; for example, I maintain gitweb, and have had problems w/ newer versions of git/cogito entering sid that completely break gitweb. Using git seemst to be a matter of tracking it upstream (using git). It breaks from time to time. But its under heavy development, so I don't mind too much. I think that bzr is a more powerful tool, and frankly using git to suck patches out of upstream is painful. It seems to be very much geared to wards information going into the tree, moving forward, not mining it for patches as is a more typical maintenance task. This is partly because of the object files system that git is built on top of, which doesn't keep particularly strong links between information. Bzr is in much the same boat, but I think that it has more support underneath, and thus should be more adept to suiting a wide range of developer needs. though, and if this makes sense or not, but as far as learning yet-another-versioning-system, i guess it is easier to learn the one used by
Re: [PATCH 0/2] Debian mkinitrd: Integrate kdump
On Tue, Aug 30, 2005 at 11:08:59AM -0600, dann frazier wrote: On Tue, 2005-08-30 at 15:18 +0530, Rachita Kothiyal wrote: On Tue, Aug 30, 2005 at 02:59:15AM -0400, Andres Salomon wrote: On Tue, 2005-08-30 at 12:23 +0530, Rachita Kothiyal wrote: [...] I had sent the patch to Jeff Bailey, Bastian Blank, Steve Langasek and the debian-kernel list. But have not received any comments from them so far. We have been considering porting this solution to the initramfs approach also, but since initrd is more widely used thought it to be a better platform. When in the future do you think this switch to initramfs will happen? Now that 2.6.13 is out (with its dropped devfs support, which initrd-tools requires atm), one of two things will happen; we'll either port initrd-tools to support non-devfs (unlikely), re-add devfs to 2.6.13, or switch to initramfs. I'm going to be playing around w/ it soon, so I have a better idea which would be the best solution. Thanks Andres for the info. kexec/kdump kernel code has been merged with 2.6 mainline since 2.6.13-rc1. I was wondering whom shall I contact for kdump integration on Debian. Having initrd/initramfs support for kdump is just one of things needed for kdump integration. Other stuffs like including the user space kexec-tools with kdump support with Debian distribution, enabling CONFIG_KEXEC in Debian kernel, and packaging dump capture kernel etc. fyi, Khalid Aziz has packaged kexec-tools and will be uploading it RSN. Hi Khalid, I was wondering if you have picked up the kdump patches to kexec-tools also. As the kexec-tools-1.101 doesnot support kdump. There is a consolidated patch to kexec-tools-1.101 to support kdump at this link http://lse.sf.net/kdump/patches/kexec-tools-1.101-kdump.patch Please let us know if that works out for you. Thanks Rachita -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
