Bug#298835: New ASFS filesystem driver realase (1.0beta9)
I've realased new version of my ASFS filesystem driver. It contain modiffied NLS patch by Peter Fedin. It is available on project's homepage: http://home.elka.pw.edu.pl/~mszyprow/programy/asfs/ The diffs: http://home.elka.pw.edu.pl/~mszyprow/programy/asfs/asfs-1.0b8_to_1.0b9_patch_2.6.10.diff.gz http://home.elka.pw.edu.pl/~mszyprow/programy/asfs/asfs-1.0b9_patch_2.6.10.diff.gz Regards -- Marek Szyprowski .. GG:2309080 .. mailto:[EMAIL PROTECTED] .. . happy MorphOS, AmigaOS and Debian/Linux user ... ... http://march.home.staszic.waw.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of kernel-source-2.6.11_2.6.11-1_i386.changes
kernel-source-2.6.11_2.6.11-1_i386.changes uploaded successfully to localhost along with the files: kernel-source-2.6.11_2.6.11-1.dsc kernel-source-2.6.11_2.6.11.orig.tar.gz kernel-source-2.6.11_2.6.11-1.diff.gz kernel-patch-debian-2.6.11_2.6.11-1_all.deb kernel-source-2.6.11_2.6.11-1_all.deb kernel-tree-2.6.11_2.6.11-1_all.deb kernel-doc-2.6.11_2.6.11-1_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel-source-2.6.11_2.6.11-1_i386.changes is NEW
(new) kernel-doc-2.6.11_2.6.11-1_all.deb optional doc Linux kernel specific documentation for version 2.6.11 This package provides the various readme's in the 2.6.11 kernel Documentation/ subdirectory: these typically contain kernel-specific installation notes for some drivers for example. See /usr/share/doc/kernel-doc-X.X.XX/Documentation/00-INDEX for a list of what is contained in each file. Please read the Changes file, as it contains information about the problems, which may result by upgrading your kernel. (new) kernel-patch-debian-2.6.11_2.6.11-1_all.deb optional devel Debian patches to Linux 2.6.11 This package includes the patches used to produce the prepackaged kernel-source-2.6.11 package. Note that these patches do NOT apply against a pristine Linux 2.6.11 kernel but only against kernel-source-2.6.11_2.6.11.orig.tar.gz from the Debian archive. (new) kernel-source-2.6.11_2.6.11-1.diff.gz optional devel (new) kernel-source-2.6.11_2.6.11-1.dsc optional devel (new) kernel-source-2.6.11_2.6.11-1_all.deb optional devel Linux kernel source for version 2.6.11 with Debian patches This package provides the source code for the Linux kernel version 2.6.11. . You may configure the kernel to your setup by typing make config and following instructions, but you could get ncursesX.X-dev and try make menuconfig for a jazzier, and easier to use interface. There are options to use QT or GNOME based configuration interfaces, but they need additional packages to be installed. Also, please read the detailed documentation in the file /usr/share/doc/kernel-source-2.6.11/README.headers.gz. . If you wish to use this package to create a custom Linux kernel, then it is suggested that you investigate the package kernel-package, which has been designed to ease the task of creating kernel image packages. (new) kernel-source-2.6.11_2.6.11.orig.tar.gz optional devel (new) kernel-tree-2.6.11_2.6.11-1_all.deb optional devel Linux kernel source tree for building Debian kernel images This meta package is used as a build dependency of Debian kernel-image packages to prevent a version discrepancy between the kernel-image and corresponding kernel-sources packages in the fast-moving unstable archive. The package's dependency relations are structured so that a kernel-image package's build dependencies can always be satisfied, even if the kernel-source package that had been used to compile the image has been superseeded by a newer Debian revision since the last build. . The package provides a list of virtual packages, corresponding to Debian revisions of a kernel-source package. The Debian kernel-patch contains the information needed to roll back the current kernel-source to any of the revisions identified by the provided virtual packages. Therefore, the kernel-tree package ensures the availability of the kernel source tree corresponding to each of the virtual packages listed. . The package serves no purpose outside of the Debian build and archive infrastructure. Changes: kernel-source-2.6.11 (2.6.11-1) unstable; urgency=low . * Initial 2.6.11 kernel-source creation (Sven Luther) . * [powerpc] New pegasos/marvell gigabit ethernet patchs (Sven Luther) . * [powerpc] 750Cxe and tau calibration patch from Nicolas Det (Sven Luther) . * Fix Docbook to allow kernel-doc to build (Maximilian Attems) . * Add newer scsi-changer patch (Maximilian Attems) . * reworked modular-ide-pnp.dpatch, x86-i486_emu.dpatch, modular-ide.dpatch, drivers-ide-__devinit.dpatch(Maximilian Attems) . * [powerpc] Added new powerbook thermal sensor i2c detection patch (Sven Luther) . * 2.6.11.1 Fix keyboards for Dell machines patch (Maximilian Attems) . * 2.6.11.2 [SECURITY] epoll: return proper error on overflow condition (Maximilian Attems) . * [sparc] Added sparc-sunsab-serial-lockup.patch to eliminate the serial console lockup on machines with sunsab serial controller (Jurij Smakov). . * 2.6.11.3 Fix oops on shutdown for older via-rhine. (Maximilian Attems) . * 2.6.11.3 Fix sis900 smp/preemption oops. (Maximilian Attems) . * 2.6.11.3 r8169: receive descriptor length fix. (Maximilian Attems) . * 2.6.11.3 PCI: fix hotplug double free. (Maximilian Attems) . * 2.6.11.3 ppc32: trivial fix for e500 oprofile build. (Maximilian Attems) . * 2.6.11.3 Fix ipv6 modular build. (Maximilian Attems) . * 2.6.11.3 Fix i2c messsage flags in video drivers. (Maximilian Attems) . * 2.6.11.3 ppc32: Compilation fixes Ebony, Luan and Ocotea. CONFIG_SERIAL_TEXT_DEBUG=y (Maximilian Attems) . * 2.6.11.3 drm missing memset can crash X server. (Maximilian Attems) . * 2.6.11.3 cramfs: small stat(2) fix. (Maximilian Attems) . * 2.6.11.3 saa7110 fix amd64 2.6.11 oops on modprobe. (Maximilian Attems) . * [powerpc] Added uninorth-agp suspend support, should help with power/ibook sleep support (Sven Luther) . * [ia64] Forward port generic/non-SMP fix patch. (dann
kernel-source-2.6.11
Hi, I have uploaded kernel-source-2.6.11 2.6.11-1; it is sitting in NEW, and is available from here: http://www.acm.rpi.edu/~dilinger/kernel-source-2.6.11/ There are a few notable changes in this release. First of all, patches are now .patch, not .dpatch; dpatch hadn't actually been used in some time, that was just legacy. Second, prune-non-free was replaced w/ a more generic ruby script (available in SVN, in trunk/scripts). This was used to generate two .orig.tar.gzs: one for kernel-source-2.6.11, and another for kernel-source-nonfree-2.6.11. The standard firmware drivers have been stripped from k-s-2.6.11, and tg3 has been added to that list as well (we used to simply remove the firmware from the tg3 driver; now we remove it completely). All these drivers can be found in k-s-n-2.6.11. This does not affect sarge. We will have k-s-n-2.6.11 in non-free, as well as binary module packages (kernel-nonfree-modules-2.6.11-1-386, for example). This change was brought about due to a thread on debian-legal, in which the consensus seems to be that compiling an ELF binary that includes firmware is aggregation, not a derived work. If that is the case, then the kernel modules we were previously deleting are, in fact, distributable. Thus, we created kernel-source-nonfree, since etch will (probably) require firmware to go in non-free. We should work something out w/ the d-i people for etch, to make life easier for people requiring non-free drivers such as tg3. Also, note that saa7134_dvb.c fails to compile (I noticed this after I built and tagged). I'll fix that in 2.6.11-2; for 2.6.11-1, disable CONFIG_VIDEO_SAA7134_DVB in order to get a build. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
[ Please followup to the right list depending on the contents of your reply. Be aware I'm not subscribed to -kernel, so Cc me if needed ] On Mon, Mar 21, 2005 at 08:14:37AM +0100, Sven Luther wrote: [huge rant about NEW and hurting kernel stuff etc etc] Three remarks: Rejecting those would lead in a pissed kernel maintainer team i would say. Please be aware that NEW processing is human work. There's quite a big backlog (currently still over 300 while I feel a lot got done already), and I at least try to err on the side of caution. This means, and yes, it already happenen, that it will occasionally happen we will reject an upload by mistake. If this happens to you, just reply to the mail (as its footer says, if you don't understand the reject, reply) and it will looked into. Of course, if we decide it was a mistake and your package should be accepted, we'll process it out-of-order (The mistake I rectified yesterday was in NEW for 70 seconds, surely a record). Taking it as offence and acting accordingly could have negative effects on swift reprocessing. I think i would have warranted at least a reply on this case, don't you think ? Maybe, if one would reply to all mails you send out, one wouldn't have time for ANY other Debian work. For example, you contributed 75 mails[1] within 24 hours to the Vancouver thread, consisting (excluding quoted text) of about 7522 words in 43kB of hand-written text[2]. I'm sorry, but you think it's weird people can't resist accidentally hitting the 'd' key when seeing an incoming mail from you? Anyway, regarding kernels: I can imagine sometimes, especially with the backlog we have currently, a swift processing of some kernel package might be warranted and help Sarge. If there is such a case, it would help if someone other than yourself from the kernel team contact the right email address[3] about it, I had a hard time distilling from your mails if and which packages would genuinly benefit sarge if they were processed swiftly, of course together with a short and factual explanation. You can also try to make a release-team-person ask, but they are also busy people, so why bother them? Thanks, --Jeroen [1] http://lists.debian.org/~jeroen/sven-vancouver-24h.mbox [2] wget -qO- http://lists.debian.org/~jeroen/sven-vancouver-24h.body \ grep -v '^' | wc [3] http://www.debian.org/intro/organization -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mon, Mar 21, 2005 at 03:11:06PM +0100, Jeroen van Wolffelaar wrote: [ Please followup to the right list depending on the contents of your reply. Be aware I'm not subscribed to -kernel, so Cc me if needed ] On Mon, Mar 21, 2005 at 08:14:37AM +0100, Sven Luther wrote: [huge rant about NEW and hurting kernel stuff etc etc] Three remarks: Rejecting those would lead in a pissed kernel maintainer team i would say. Please be aware that NEW processing is human work. There's quite a big which is my main grip with the subpart of it which could be automated. For example, kernel-source-2.6.11 was just uploaded today, which means a plethora of uploads all needing NEW processing. Can you give me any reason why this really needs NEW processing, and why you don't thrust the kernel-team on this ? backlog (currently still over 300 while I feel a lot got done already), and I at least try to err on the side of caution. This means, and yes, it already happenen, that it will occasionally happen we will reject an the problem is not the reject, is the no news in weeks and no communication channel open. But again, i think and hope that this will become better now. upload by mistake. If this happens to you, just reply to the mail (as its footer says, if you don't understand the reject, reply) and it will looked into. Of course, if we decide it was a mistake and your package should be accepted, we'll process it out-of-order (The mistake I rectified yesterday was in NEW for 70 seconds, surely a record). Taking it as offence and acting accordingly could have negative effects on swift reprocessing. There was no real swift processing in the past. Also, i believe that if packages are being considered and have some problems, it would be best to include the maintainer having made the upload into this process as early as possible. I think i would have warranted at least a reply on this case, don't you think ? Maybe, if one would reply to all mails you send out, one wouldn't have time for ANY other Debian work. For example, you contributed 75 mails[1] within 24 hours to the Vancouver thread, consisting (excluding quoted text) of about 7522 words in 43kB of hand-written text[2]. I'm sorry, but you think it's weird people can't resist accidentally hitting the 'd' key when seeing an incoming mail from you? Well, sending email to a discussion forum like debian-devel, and sending email to a debian-role like ftp-master is not comparable, and i think it shows a profund lack of responsability on your part even suggesting this. How would you feel about a developer ignoring bug report from a certain person just because he has posted a big amount of emails to debian-devel ? And a falling-in-his-duties DD has at least the QA team and the MIA check to watch over him, while the ftp-masters can have any uncontrolled whim and we have no choice but to abide by them. Furthermore i see a serious failing in your logic, in the fact that the emails you quote are posterior to the failure of reply from the ftp-master's office, and can thus not be used to excuse it. Anyway, regarding kernels: I can imagine sometimes, especially with the backlog we have currently, a swift processing of some kernel package might be warranted and help Sarge. If there is such a case, it would help if someone other than yourself from the kernel team contact the right email address[3] about it, I had a hard time distilling from your Why not me ? I would very much like a reason for that, am i in some way blacklisted ? and if so for what reason ? And is this reason an acceptable one, i seriously doubt so. I am part of the kernel team, and i did work on my other packages which are more or less in good state, as well as actively participated in the debian-installer work. Why should you not threat a question on my part as from any other developer ? And if you do not, would it not be understandable that i feel irritated by this inacceptable behavior that has a blocking effect on my own participation to debian. mails if and which packages would genuinly benefit sarge if they were processed swiftly, of course together with a short and factual explanation. You can also try to make a release-team-person ask, but they are also busy people, so why bother them? Whatever. I believe that your response to email send to ftp-master's role in debian should not be influenced by any personal negative opinion you may have on me, even if it may be warranted. We all work together to make the debian release as great and swift as possible, and this kind of blacklisting of some of our developers is inacceptable, and a severe failure in the ftp-master's role responsability against the project. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mon, Mar 21, 2005 at 03:10:34PM +, Matthew Wilcox wrote: On Mon, Mar 21, 2005 at 03:20:29PM +0100, Sven Luther wrote: Anyway, regarding kernels: I can imagine sometimes, especially with the backlog we have currently, a swift processing of some kernel package might be warranted and help Sarge. If there is such a case, it would help if someone other than yourself from the kernel team contact the right email address[3] about it, I had a hard time distilling from your Why not me ? I would very much like a reason for that, am i in some way Because you are impossible to deal with. I think this mail from you shows all the characteristics which make you such a pain in the fucking arse. See a psychologist. Really. Thanks. Maybe i should resign from my debian duties then since i am not wanted. Do you volunteer to take over my packages ? Please handle parted for which i am searching a co-maintainer since 6 month, and take over the powerpc kernels as well as do my job in the debian kernel team, as well as the support of powerpc issues in d-i and the maintainance of a big part of the ocaml subset. Until you are ready to do that, it is not acceptable to imply that the ftp-masters can be made to fail their job and threat developers like dirt just because they have no counter power to them, and i should support every abuse of them. Not friendly anymore and expecting excuses from you Matthew and the whole ftp-master team for their discrimination of me. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mon, Mar 21, 2005 at 03:20:29PM +0100, Sven Luther wrote: Anyway, regarding kernels: I can imagine sometimes, especially with the backlog we have currently, a swift processing of some kernel package might be warranted and help Sarge. If there is such a case, it would help if someone other than yourself from the kernel team contact the right email address[3] about it, I had a hard time distilling from your Why not me ? I would very much like a reason for that, am i in some way Because you are impossible to deal with. I think this mail from you shows all the characteristics which make you such a pain in the fucking arse. See a psychologist. Really. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
Dear, all, [...] I'm quite unhappy that this thread has turned so bad. Please, all of us who are part of this thread, can we please try to get the heat out. I think we all are happy that ftp-masters and -assistents are currently working on reducing the NEW queue to a reasonable size. This will have some good effect not only on the kernel, but also on every other package in Debian. I also think that we should be thankful for their hard work. Also, I think we all know that keeping the kernel in sync is currently a not too easy job. So, for very similar reasons, we all should be happy with the steady progress we're having on the kernel. If we consider woody's situation, we have by far too many kernel packages - a problem that was solved by the kernel team for sarge. So, we all are doing a hard job, and life is sometimes just stressing. It would be really great if we can manage to keep the heat out, that would help us all to do a better (and more enjoyable) job. Thanks for your attention, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel install script bug, breaking grub /boot/menu.lst
J. Grant wrote: Hello, I have just noticed a bug in the kernel install scripts. I have to manually fix my /boot/menu.lst. Hi. You left out the most important part of menu.lst (the one that has the parameters that update-grub copies into the automagically generated part). Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mon, Mar 21, 2005 at 04:08:19PM +0100, Sven Luther wrote: Thanks. Maybe i should resign from my debian duties then since i am not wanted. Do you volunteer to take over my packages ? Please handle parted for which i am searching a co-maintainer since 6 month, and take over the powerpc kernels as well as do my job in the debian kernel team, as well as the support of powerpc issues in d-i and the maintainance of a big part of the ocaml subset. I think Debian would be better finding someone else to do those tasks, yes. I'm not going to volunteer for them as I intend to leave Debian shortly after sarge releases. I can't believe Debian is so short on skills that it needs you. Not friendly anymore and expecting excuses from you Matthew and the whole ftp-master team for their discrimination of me. Your emails have never had a friendly tone, despite the way you put friendly at the bottom of every one of them. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mon, Mar 21, 2005 at 03:45:10PM +, Matthew Wilcox wrote: On Mon, Mar 21, 2005 at 04:08:19PM +0100, Sven Luther wrote: Thanks. Maybe i should resign from my debian duties then since i am not wanted. Do you volunteer to take over my packages ? Please handle parted for which i am searching a co-maintainer since 6 month, and take over the powerpc kernels as well as do my job in the debian kernel team, as well as the support of powerpc issues in d-i and the maintainance of a big part of the ocaml subset. I think Debian would be better finding someone else to do those tasks, yes. I'm not going to volunteer for them as I intend to leave Debian shortly after sarge releases. I can't believe Debian is so short on skills that it needs you. DON'T EVER ADDRESS ME IN THE FUTUR AND GET YOURSELF LOST. Anyway, i am out of this and you and Jeroen have managed to do it, and all those self-rigtheous ftp-master and other release team, who think someone complaining just whines, and don't care that they do exactly the same, or those who like to complain about being the recipient of flamewars, and then doing the exact same thing to others. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298835: New ASFS filesystem driver realase (1.0beta9)
On Mon, Mar 21, 2005 at 10:17:36AM +0100, Marek Szyprowski wrote: I've realased new version of my ASFS filesystem driver. It contain modiffied NLS patch by Peter Fedin. It is available on project's homepage: http://home.elka.pw.edu.pl/~mszyprow/programy/asfs/ The diffs: http://home.elka.pw.edu.pl/~mszyprow/programy/asfs/asfs-1.0b8_to_1.0b9_patch_2.6.10.diff.gz http://home.elka.pw.edu.pl/~mszyprow/programy/asfs/asfs-1.0b9_patch_2.6.10.diff.gz How goes your effort to bring this upstream ? Would be nice if you where to give it another try. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mon, Mar 21, 2005 at 03:11:06PM +0100, Jeroen van Wolffelaar wrote: Maybe, if one would reply to all mails you send out, one wouldn't have time for ANY other Debian work. For example, you contributed 75 mails[1] within 24 hours to the Vancouver thread, consisting (excluding quoted text) of about 7522 words in 43kB of hand-written text[2]. I'm sorry, but you think it's weird people can't resist accidentally hitting the 'd' key when seeing an incoming mail from you? And what about the email i sent to remove some erroneously ACCEPTED and then REJECTED kernel package from the REJECT queue ? I had to mail twice about this, and nothing ever happened for almost a month of so, all the while you where spamming all of debian-kernel daily with said bogus reject message ? Hurt, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
[Sven Luther] the problem is not the reject, is the no news in weeks and no communication channel open. But again, i think and hope that this will become better now. I agree. Complete silence and no feedback is a real problem when it happen, and only worse if it is an official debian role failing to communicate. But I believe things are improving a lot when it comes to the ftpmaster role, and have great hopes that Jeroen is part of the solution. :) Maybe, if one would reply to all mails you send out, one wouldn't have time for ANY other Debian work. No-one is asking anyone to reply to the wast flod of emails coming from Sven the last few days. But emails sent to the official debian role ftpmaster should get some kind of response. Well, sending email to a discussion forum like debian-devel, and sending email to a debian-role like ftp-master is not comparable, and i think it shows a profund lack of responsability on your part even suggesting this. I believe Joroen tried to express that mistakes do happen, and that the ftpmasters can delete email by mistake when their mailbox is filling up. Perhaps this could be solved with some kind of ticket system handling email to the official roles in debian? I'm not sure if BTS is the best option to handle emails to ftpmaster, leader and others. Perhaps request-tracker is a better option? We use it at work, and it seem to do request handling quite well (at least when we added the email administration interface. :). What surprises me is the energy and hostality Matthew Wilcox demonstrates by attacking you in later private emails. A good thing he isn't part of the ftpmaster team (as far as I can see). The ftpmasters seem to have a professional attitude towards the role they have in the project. I wish we could expect that from all the participants in the project. (But you are right, Sven. No-one should have to accept abuse for the work one does as a volunteer in the Debian project. That applies for both you, the ftpmasters, the release managers, all the debian developers and the users. Those unable to behave sivilised against their fellow volunteers should be ashamed of themselves.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
On Mon, Mar 21, 2005 at 05:40:44PM +0100, Petter Reinholdtsen wrote: [Sven Luther] the problem is not the reject, is the no news in weeks and no communication channel open. But again, i think and hope that this will become better now. I agree. Complete silence and no feedback is a real problem when it happen, and only worse if it is an official debian role failing to communicate. But I believe things are improving a lot when it comes to the ftpmaster role, and have great hopes that Jeroen is part of the solution. :) No, he is not, as far as i am concerned, unless he presents his apologies first. Well, sending email to a discussion forum like debian-devel, and sending email to a debian-role like ftp-master is not comparable, and i think it shows a profund lack of responsability on your part even suggesting this. I believe Joroen tried to express that mistakes do happen, and that the ftpmasters can delete email by mistake when their mailbox is filling up. No, that is not acceptable, and probably not the right reason for this. Until evidence proves otherwise, it is just because they don't care to read those emails, and that that email address is simply forwarded to /dev/null. Perhaps this could be solved with some kind of ticket system handling email to the official roles in debian? I'm not sure if BTS is the best option to handle emails to ftpmaster, leader and others. Perhaps request-tracker is a better option? We use it at work, and it seem to do request handling quite well (at least when we added the email administration interface. :). That would be a solution. But then are the ftp-masters ready to get the problems they receive publicly visible ? What surprises me is the energy and hostality Matthew Wilcox demonstrates by attacking you in later private emails. A good thing he isn't part of the ftpmaster team (as far as I can see). The ftpmasters seem to have a professional attitude towards the role they have in the project. I wish we could expect that from all the participants in the project. No, a professional attitude would have them reply to the people they are working with. (But you are right, Sven. No-one should have to accept abuse for the work one does as a volunteer in the Debian project. That applies for both you, the ftpmasters, the release managers, all the debian developers and the users. Those unable to behave sivilised against their fellow volunteers should be ashamed of themselves.) but this have become the norm these past couple month, and Steve's 'proposal' was the last straw. Hurt, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278887: does not include megaraid2 module on initrd, which makes booting fail after debian install on several Dell machines
I have successfully installed Sarge on an identical machine, (Dell 2850, Perc 4e/Di RAID adapter), using todays daily build[1]. The megaraid2 module is loaded by both the installer, and the installed kernel. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300763 Thanks, [1] http://cdimage.debian.org/pub/cdimage-testing/daily/i386/20050321/sarge-i386-netinst.iso -- Eric Evans [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#298927: ALI IDE problems on sparc
improves the situation. If you could confirm that it fails with 2.4.27-2 currently in the archive, but works with my image, it would be great. Confirmed. % uname -r 2.4.27-2-sparc64 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel-image-2.6.8-ia64_2.6.8-13_ia64.changes ACCEPTED
Accepted: kernel-headers-2.6-itanium-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-itanium-smp_2.6.8-13_ia64.deb kernel-headers-2.6-itanium_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-itanium_2.6.8-13_ia64.deb kernel-headers-2.6-mckinley-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-mckinley-smp_2.6.8-13_ia64.deb kernel-headers-2.6-mckinley_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-mckinley_2.6.8-13_ia64.deb kernel-headers-2.6.8-3-itanium-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-itanium-smp_2.6.8-13_ia64.deb kernel-headers-2.6.8-3-itanium_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-itanium_2.6.8-13_ia64.deb kernel-headers-2.6.8-3-mckinley-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-mckinley-smp_2.6.8-13_ia64.deb kernel-headers-2.6.8-3-mckinley_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-mckinley_2.6.8-13_ia64.deb kernel-headers-2.6.8-3_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3_2.6.8-13_ia64.deb kernel-image-2.6-itanium-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-itanium-smp_2.6.8-13_ia64.deb kernel-image-2.6-itanium_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-itanium_2.6.8-13_ia64.deb kernel-image-2.6-mckinley-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-mckinley-smp_2.6.8-13_ia64.deb kernel-image-2.6-mckinley_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-mckinley_2.6.8-13_ia64.deb kernel-image-2.6.8-3-itanium-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-itanium-smp_2.6.8-13_ia64.deb kernel-image-2.6.8-3-itanium_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-itanium_2.6.8-13_ia64.deb kernel-image-2.6.8-3-mckinley-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-mckinley-smp_2.6.8-13_ia64.deb kernel-image-2.6.8-3-mckinley_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-mckinley_2.6.8-13_ia64.deb kernel-image-2.6.8-ia64_2.6.8-13.dsc to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-ia64_2.6.8-13.dsc kernel-image-2.6.8-ia64_2.6.8-13.tar.gz to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-ia64_2.6.8-13.tar.gz Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300774: kernel-image-2.6.8-powerpc: /lib/modules/2.6.8-powerpc/source is a symlink to non-existing directory
Package: kernel-image-2.6.8-powerpc Version: 2.6.8-11 Severity: normal Hi! Just found an broken symlink in the kernel I got installed on my iBook: /lib/modules/2.6.8-powerpc/source is a (probaly on most systems) broken symlink to /home/luther/debian/build/kernel-patch-powerpc-2.6.8-2.6.8/tmp/kernel-source-2.6.8-powerpc Yours sincerely, Alexander -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.6.8-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages kernel-image-2.6.8-powerpc depends on: ii initrd-tools 0.1.77 tools to create initrd image for p ii mkvmlinuz 13 create a kernel to boot a PowerPC 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: NEW handling: About rejects, and kernels
[Petter Reinholdtsen] in later private emails. This was a misunderstanding on my part, due to the fact that I received the replies from Sven before I received the replies from Matthew. The fact that the replies were done on public lists and not in private email do not change how I react to their content. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
I'm quite unhappy that this thread has turned so bad. Please, all of us who are part of this thread, can we please try to get the heat out. I can't agree more. What I have seen up to now is make me very sad. Seeing Sven considering to resign is sad news for me. I won't play the others started first game, I leave this to my kids (well, probably even the youngest of them wouldn't play this game anymore). Up to now, I have seen very rude and unacceptable mails addressed directly to Sven Luther. There has been other rude mails sent to other people as well which is obviously unacceptable as well (no, Sven, not necessary from you). And I certainly missed a lot of other crap because I have read about 5% of these threads. The most difficult thing to do, especially by mail, is just recognizing that one went too far or just that you are wrong. Several people went too far in this thread. I think all should really consider doing what adult and mature people would do : just apologize, take a break and avoid definitive statementsand continue working in this project, because sometimes our arguments are not only out weakness but our strength. I don't agree with several things written by Sven here or there. I probably agree with a lot of others...and I just don't understand another bunch of such things. I have seen serious attempts to make proposals which seems quite constructive to me. I also have seen probably far too much mails (sorry, Sven, but IMHO you really should have slowed your contribution to all threads but, well, ce qui est fait est fait) But even what I may not agree with does not prevent me to consider that losing his valuable input is not good for this project, just like losing the work of any individual involved here would be bad. OK, people, as far as I have seen we are all supposed to be adult people herenot in a kind of kindergarten. So, who starts and just makes one or two steps backward. And, please no He should do so first answerfor $deity's sake, please be adult. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
[Sven Luther] No, he is not, as far as i am concerned, unless he presents his apologies first. For what? Commenting on your wast amount of email posted the last few days, and his suggestion that the amount of email could make the ftpmasters delete mails by mistake? I can not really believe that is your problem, so please enlighten me. No, that is not acceptable, and probably not the right reason for this. Until evidence proves otherwise, it is just because they don't care to read those emails, and that that email address is simply forwarded to /dev/null. I didn't say it was acceptable. I tried to put it in perspective. I'm well aware of at least some of the communication issues with the ftpmasters, but truly believe these problems are because the ftpmasters are overworked, not because they are evil. And I believe this even though one of the ftpmasters told me on IRC to stop wasting his time when I wanted to discuss making the list of packages in NEW public. I put it on the account of misjudgement during stress, not evil will. I suspect you would be better off if you accepted that misjudgement and mistakes happen also for the ftpmasters. After all, your emails haven't been the perfect examples of rational and clear speek either (though not as hostile as others on the list. :). I do not hold that against you, and wish you didn't hold such miscommunications and and misjudgements against the other volunteers in Debian. That would be a solution. But then are the ftp-masters ready to get the problems they receive publicly visible ? I didn't propose to make it all public. request-tracker is capable of fine grained access control. No, a professional attitude would have them reply to the people they are working with. Again, I agree that the ftpmaster role should reply to all requests. But if the volunteers filling this role are very busy, it does not help to shout at them and send even more email. A different solution must be found, and I hope and believe we are on our way to a solution to the problems the project is facing. but this have become the norm these past couple month, and Steve's 'proposal' was the last straw. I guess I do not read the proposal the way you read it. I read it as a document describing the problems the release team and the ftpmaster experiences with the release process, and their ideas on how to improve the situation. But first and formost, I read the proposal as a good step forward for the release of sarge. After all, the ideas for reorganizing the process for etch wasn't the most important part of the vancouver announcement. The most important part was that the release managers and the ftpmasters are coordinated in their work to release Sarge. Since the meeting 189 packages have been processed from the NEW queue. I believe this is the result of the meeting, where the ftpmasters was able to meet with prospective ftpmaster assistant. I also believe the increased effort to release sarge is a result of this meeting. Well, this email is already getting fairly long. Enough hot air from me this time, I believe. I am truly sorry for loosing you. You have done a good job helping Debian progress the state of free software, and it is sad that you decide to throw in the towel because of hard language from a fellow Debian volunteer. :( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mon, Mar 21, 2005 at 06:34:00PM +0100, Christian Perrier wrote: I'm quite unhappy that this thread has turned so bad. Please, all of us who are part of this thread, can we please try to get the heat out. I can't agree more. What I have seen up to now is make me very sad. Seeing Sven considering to resign is sad news for me. ... Thanks for this, it is hearthening (or however you say that in english). I should really not have participated in that thread (and i resent a bit to Steve for it), and i am probably better of not following debian-devel, as i had not done for ages before. Still i believe i have made some constructive proposals, and even if my first posts may have been a bit too aggressive, for which i apologize, or too many, i think it is also a prove of the passion which lies on this issue. Something which has the potential to affect many of what we believe debian is, and which is handled by utter contempt, at least in the initial posting. Still hurt though, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
On Mon, Mar 21, 2005 at 08:28:44PM +0100, Petter Reinholdtsen wrote: [Sven Luther] No, he is not, as far as i am concerned, unless he presents his apologies first. For what? Commenting on your wast amount of email posted the last few days, and his suggestion that the amount of email could make the ftpmasters delete mails by mistake? I can not really believe that is your problem, so please enlighten me. Sorry, but if they are not able to properly filter mails sent to the canonical ftp-master address from the rest of their personal mail, i don't think they are fit to do the job. Also, his hints that futur mail from me will be ignored is unaceptable as well, and i cannot work with people who don't take their responsabilities seriously. No, that is not acceptable, and probably not the right reason for this. Until evidence proves otherwise, it is just because they don't care to read those emails, and that that email address is simply forwarded to /dev/null. I didn't say it was acceptable. I tried to put it in perspective. I'm well aware of at least some of the communication issues with the ftpmasters, but truly believe these problems are because the ftpmasters are overworked, not because they are evil. And I believe The real problem is that they deny there is a problem, how do you hope to get it fixed then ? this even though one of the ftpmasters told me on IRC to stop wasting his time when I wanted to discuss making the list of packages in NEW public. I put it on the account of misjudgement during stress, not evil will. I suspect you would be better off if you accepted that misjudgement and mistakes happen also for the ftpmasters. After all, your emails So, but then i expect the same courtesy to go both ways, which it does not, and furthermore they have the ultimate power to hinder my work and make my live difficult, while the otherway is not true. With great power comes great responsability, and the lest of them is to be civil, and reply to emails sent by developers to the ftp-master role address. haven't been the perfect examples of rational and clear speek either (though not as hostile as others on the list. :). I do not hold that against you, and wish you didn't hold such miscommunications and and misjudgements against the other volunteers in Debian. No, but they plainly refuse to admit there is a problem, what hope do you see to it ever been fixed then ? That would be a solution. But then are the ftp-masters ready to get the problems they receive publicly visible ? I didn't propose to make it all public. request-tracker is capable of fine grained access control. No, a professional attitude would have them reply to the people they are working with. Again, I agree that the ftpmaster role should reply to all requests. But if the volunteers filling this role are very busy, it does not help to shout at them and send even more email. A different solution I sent perhaps 3-4 or in any case less than 10 emails to them, over the past two years. A couple of those was to have them clean up the reject queue which was spaming debian-kernel daily, this hardly is shouting and sending even more emails, isn't it. I sent one mail, and waited, and in the email spam case a second or third a couple of weeks later if i remember well. Someone who has not the time to reply to 3-4 civil emails in 2 years, well, he should probably reconsider his involvement or whatever. must be found, and I hope and believe we are on our way to a solution to the problems the project is facing. Let's hope so, but i have some doubts. but this have become the norm these past couple month, and Steve's 'proposal' was the last straw. I guess I do not read the proposal the way you read it. I read it as a document describing the problems the release team and the ftpmaster experiences with the release process, and their ideas on how to improve the situation. But first and formost, I read the proposal as a good step forward for the release of sarge. After all, the ideas for reorganizing the process for etch wasn't the most important part of the vancouver announcement. The most important part was that the release managers and the ftpmasters are coordinated in their work to release Sarge. Since the meeting 189 packages have been processed from the NEW queue. I believe this is the result of the meeting, where the ftpmasters was able to meet with prospective ftpmaster assistant. I also believe the increased effort to release sarge is a result of this meeting. What increasing effort, start a giant flamewar by being utterly contemptuous of our porters ? They could have published that part separatedly and post sarge or whatever. And i didn't see a single line of apology or recognition that they may have been wrong. I am truly sorry for loosing you. You have done a good job helping Debian progress the state of free software, and it is sad that you
SATA controller not recognized by sarge
Hello world, I 've just gotten a dell PC with sata controller HD ( model is ata ST3 800 13AS, driver ata_piix ), I tryed to install sarge ( netinstall dowloaded in Dec 2004), but it is not recognized, while SL 3 ( scientific Linux based on RH , downloaded in Feb 2005 ) and Fedora core 3, recogniaed the HD. I want to know if the newest netinstall recognize this type of hardware ? otherwise howto install my sarge, is there a possibility to add such parameter to the boot. thanks in advance best regards bela -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300783: kernel-source-2.6.8: [CAN-2005-0815] Multiple range checking flaws in ISO9660 filesystem handler
Package: kernel-source-2.6.8 Version: 2.6.8-14 Severity: important Tags: security Quoting an advisory by ISS: Linux Kernel versions prior to 2.6.12-rc1 are vulnerable to unspecified vulnerabilities in the ISO9660 filesystem handler, including the Rock Ridge and Juliet extensions. A remote attacker could send a specially-crafted filesystem to cause a denial of service or execute arbitrary code on the system. It's been fixed as of 2.6.12-rc1, according to http://www.securityfocus.com/bid/12837 kernel 2.4 is affected as well. There's a test program at http://www.securityfocus.com/archive/1/393590. Cheers, Moritz -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages kernel-source-2.6.8 depends on: ii binutils 2.15-5 The GNU assembler, linker and bina ii bzip2 1.0.2-5high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel install script bug, breaking grub /boot/menu.lst
Hi Massa, Thank you for your response. Hi. You left out the most important part of menu.lst (the one that has the parameters that update-grub copies into the automagically generated part). Sorry about that. I have attached my current revised /boot/grub/menu.lst and menu.lst~ (Which was a backup before the kernel update I believe). (Please include my email address in any reply) Kind regards JG # menu.lst - See: grub(8), info grub, update-grub(8) #grub-install(8), grub-floppy(8), #grub-md5-crypt, /usr/share/doc/grub #and /usr/share/doc/grub-doc/. ## default num # Set the default entry to the entry number NUM. Numbering starts from 0, and # the entry number 0 is the default if the command is not used. # # You can specify 'saved' instead of a number. In this case, the default entry # is the entry saved with the command 'savedefault'. default 0 ## timeout sec # Set a timeout, in SEC seconds, before automatically booting the default entry # (normally the first entry defined). timeout 5 # Pretty colours color cyan/blue white/blue ## password ['--md5'] passwd # If used in the first section of a menu file, disable all interactive editing # control (menu entry editor and command-line) and entries protected by the # command 'lock' # e.g. password topsecret # password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/ # password topsecret # # examples # # title Windows 95/98/NT/2000 # root (hd0,0) # makeactive # chainloader +1 # # title Linux # root (hd0,1) # kernel/vmlinuz root=/dev/hda2 ro # # # Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST ### BEGIN AUTOMAGIC KERNELS LIST ## lines between the AUTOMAGIC KERNELS LIST markers will be modified ## by the debian update-grub script except for the default optons below ## DO NOT UNCOMMENT THEM, Just edit them to your needs ## ## Start Default Options ## ## default kernel options ## default kernel options for automagic boot options ## If you want special options for specifiv kernels use kopt_x_y_z ## where x.y.z is kernel version. Minor versions can be omitted. ## e.g. kopt=root=/dev/hda1 ro # kopt=root=/dev/sda3 ro ## default grub root device ## e.g. groot=(hd0,0) # groot=(hd0,1) ## should update-grub create alternative automagic boot options ## e.g. alternative=true ## alternative=false # alternative=true ## should update-grub lock alternative automagic boot options ## e.g. lockalternative=true ## lockalternative=false # lockalternative=false ## altoption boot targets option ## multiple altoptions lines are allowed ## e.g. altoptions=(extra menu suffix) extra boot options ## altoptions=(recovery mode) single # altoptions=(recovery mode) single ## controls how many kernels should be put into the menu.lst ## only counts the first occurence of a kernel, not the ## alternative kernel options ## e.g. howmany=all ## howmany=7 # howmany=all ## should update-grub create memtest86 boot option ## e.g. memtest86=true ## memtest86=false # memtest86=true ## ## End Default Options ## title Debian GNU/Linux, kernel 2.6.8-2-k7 root(hd0,1) kernel /vmlinuz-2.6.8-2-k7 root=/dev/sda3 ro hda=ide-scsi profile=1 initrd /initrd.img-2.6.8-2-k7 savedefault boot title Debian GNU/Linux, kernel 2.6.8-2-k7 (recovery mode) root(hd0,1) kernel /vmlinuz-2.6.8-2-k7 root=/dev/sda3 ro single initrd /initrd.img-2.6.8-2-k7 savedefault boot title Debian GNU/Linux, kernel 2.6.8-1-386 root(hd0,1) kernel /vmlinuz-2.6.8-1-386 root=/dev/sda3 ro initrd /initrd.img-2.6.8-1-386 savedefault boot title Debian GNU/Linux, kernel 2.6.8-1-386 (recovery mode) root(hd0,1) kernel /vmlinuz-2.6.8-1-386 root=/dev/sda3 ro single hda=ide-scsi initrd /initrd.img-2.6.8-1-386 savedefault boot title Debian GNU/Linux, kernel memtest86+ root(hd0,1) kernel /memtest86+.bin savedefault boot ### END DEBIAN AUTOMAGIC KERNELS LIST # This is a divider, added to separate the menu items below from the Debian # ones. title Other operating systems: root # This entry automatically added by the Debian installer for a non-linux OS # on /dev/sda1 title Win2k root(hd0,0) savedefault makeactive chainloader +1 # menu.lst - See: grub(8), info grub, update-grub(8) #grub-install(8), grub-floppy(8), #grub-md5-crypt, /usr/share/doc/grub #and /usr/share/doc/grub-doc/. ## default num # Set the default entry to the entry number NUM. Numbering starts from 0, and # the entry number 0 is the default if the command is not used. # # You can specify 'saved' instead of a number. In this case, the default entry # is the entry saved with the command 'savedefault'. default 0 ## timeout sec # Set a timeout, in SEC
Re: SATA controller not recognized by sarge
Bela, I just net-installed Sarge on my new gateway with a sata HD. I had to type linux26 at the boot prompt. Otherwise, sarge would load the default 2.4.xx kernel and would not find the HD. good luck, --Hannuman belahcene wrote: Hello world, I 've just gotten a dell PC with sata controller HD ( model is ata ST3 800 13AS, driver ata_piix ), I tryed to install sarge ( netinstall dowloaded in Dec 2004), but it is not recognized, while SL 3 ( scientific Linux based on RH , downloaded in Feb 2005 ) and Fedora core 3, recogniaed the HD. I want to know if the newest netinstall recognize this type of hardware ? otherwise howto install my sarge, is there a possibility to add such parameter to the boot. thanks in advance best regards bela -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Fwd: k-i-ia64-2.6.8 -3 ABI]
oops; cc'd the wrong address Forwarded Message From: dann frazier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: k-i-ia64-2.6.8 -3 ABI Date: Mon, 21 Mar 2005 13:49:49 -0700 The ia64 2.6.8-3 ABI change has been accepted into unstable. This ABI change was necessary to fix an ia64-specific issue w/ having PREEMPT enabled, and I took the opportunity to do it at the same time as the recent security ABI change(s). What should gate this from entering testing? * Nothing, let it go in - as long as l-k-di-ia64 isn't updated * Current efforts to get all archs using an ABI number? * RC4? Should I go ahead and do a build of l-k-di-ia64-2.6 on trunk (or sarge) upload to sid? email message attachment, Forwarded message - kernel-image-2.6.8-ia64_2.6.8-13_ia64.changes ACCEPTED Forwarded Message From: Debian Installer [EMAIL PROTECTED] To: dann frazier [EMAIL PROTECTED], Debian Kernel Team debian-kernel@lists.debian.org Subject: kernel-image-2.6.8-ia64_2.6.8-13_ia64.changes ACCEPTED Date: Mon, 21 Mar 2005 13:04:38 -0500 Accepted: kernel-headers-2.6-itanium-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-itanium-smp_2.6.8-13_ia64.deb kernel-headers-2.6-itanium_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-itanium_2.6.8-13_ia64.deb kernel-headers-2.6-mckinley-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-mckinley-smp_2.6.8-13_ia64.deb kernel-headers-2.6-mckinley_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-mckinley_2.6.8-13_ia64.deb kernel-headers-2.6.8-3-itanium-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-itanium-smp_2.6.8-13_ia64.deb kernel-headers-2.6.8-3-itanium_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-itanium_2.6.8-13_ia64.deb kernel-headers-2.6.8-3-mckinley-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-mckinley-smp_2.6.8-13_ia64.deb kernel-headers-2.6.8-3-mckinley_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-mckinley_2.6.8-13_ia64.deb kernel-headers-2.6.8-3_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3_2.6.8-13_ia64.deb kernel-image-2.6-itanium-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-itanium-smp_2.6.8-13_ia64.deb kernel-image-2.6-itanium_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-itanium_2.6.8-13_ia64.deb kernel-image-2.6-mckinley-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-mckinley-smp_2.6.8-13_ia64.deb kernel-image-2.6-mckinley_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-mckinley_2.6.8-13_ia64.deb kernel-image-2.6.8-3-itanium-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-itanium-smp_2.6.8-13_ia64.deb kernel-image-2.6.8-3-itanium_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-itanium_2.6.8-13_ia64.deb kernel-image-2.6.8-3-mckinley-smp_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-mckinley-smp_2.6.8-13_ia64.deb kernel-image-2.6.8-3-mckinley_2.6.8-13_ia64.deb to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-mckinley_2.6.8-13_ia64.deb kernel-image-2.6.8-ia64_2.6.8-13.dsc to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-ia64_2.6.8-13.dsc kernel-image-2.6.8-ia64_2.6.8-13.tar.gz to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-ia64_2.6.8-13.tar.gz Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
