Re: how to detect a debian kernel from `uname -r`
On Sun, Jan 08, 2006 at 08:31:50AM +0100, Sven Luther wrote: You are not interested in recordying the debian abi number, or the flavour as a subset of the architecture used ? This seems like interesting info. KLive wasn't originally designed to track distro packages, but mainline or/and self-built kernels. So at the moment there's simply no place to store this debian info in the db. I store the uname -m which provides some interesting info too. I could of course add abi and flavour, but I'd prefer to try to add stuff that can work for other distro too, so it needs more thoughts. Right now your /proc/version allows to reliably identify the branch (i.e. Debian) and the package version, so it's already very useful (and I already fixed the server code to parse it correctly ;). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346345: linux-source-2.6.15: radeonfb has inverted frequencies for core/memory?
On Sun, Jan 08, 2006 at 08:25:46AM +0100, Sven Luther wrote: On Sat, Jan 07, 2006 at 05:43:47PM -0800, obi wrote: radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=252.00 Mhz, System=200.00 MHz and this is what rovclock -i ells Reference clock from BIOS: 27.0 MHz XTAL: 27.0 MHz, RefDiv: 6 Core: 252.0 MHz, Mem: 200.25 MHz Sounds like a rovclock bug, since radeonfb has it right ? Well, the ati command (what was that atitool?) when I tested fglrx reported the same as rovclock. And Xorg repors (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=2 max=35000; xclk=2 but I'm not sure how to parse them ... If those are indeed the right values, that would definetely explain why I didn't have any problems so far :). thanks, graziano Friendly, Sven Luther -- +---+--+ | Graziano Obertelli| CS Dept. Rm 102 | | [EMAIL PROTECTED] | University of California | | (805) 893-5212| Santa Barbara, CA 93106 | +---+--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sun, Jan 08, 2006 at 08:48:20AM +0100, Sven Luther wrote: You could simply add the two distro-specific information, the full package name (2.6.14-2-amd64-k8) and the distro version number (2.6.14-7). I guess in additional often-intrusive patches, and will probably use a meaningful name. it will be embedded in the uname -r name too, probably as version-abi-subarch-flavour. I already store the 'uname -r' as `kernel_release` and the debian package version is now stored as `kernel_group`, and 'Debian' string is the `branch`. I simply don't yet split the info in the kernel_release into abi/flavour, but thinking about it I can make it visible in the local column (still not splitted but that's ok). The place where to put it was more a problem in the visualization than in the storage (since I store /proc/version so no useful info can get lost ;). The local column is what I use to show the git tag for example with mainline. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
non-free firmware
Hi, at least I lost track a bit, so this mail is basically a question to bring me up to speed. In 2004, there was a GR that decided to put everything in main under the DFSG. We had some discussions, but in the end, the result was that all the non-free firmware bits have to be removed from main before we can release etch. Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346345: linux-source-2.6.15: radeonfb has inverted frequencies for core/memory?
On Sun, Jan 08, 2006 at 12:15:45AM -0800, obi wrote: On Sun, Jan 08, 2006 at 08:25:46AM +0100, Sven Luther wrote: On Sat, Jan 07, 2006 at 05:43:47PM -0800, obi wrote: radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=252.00 Mhz, System=200.00 MHz and this is what rovclock -i ells Reference clock from BIOS: 27.0 MHz XTAL: 27.0 MHz, RefDiv: 6 Core: 252.0 MHz, Mem: 200.25 MHz Sounds like a rovclock bug, since radeonfb has it right ? Well, the ati command (what was that atitool?) when I tested fglrx reported the same as rovclock. And Xorg repors (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=2 max=35000; xclk=2 These are probably the output parameters, for the screen or something. but I'm not sure how to parse them ... Can you check what the real values are, maybe by using some windows tool on the box, or by hunting the specs of your model on the manufacturer's site or on various review sites ? If those are indeed the right values, that would definetely explain why I didn't have any problems so far :). Well, the other possibility is that the kernel gets it right, but fails to export it correctly to userland, thus confusing rovclock. The 200Mhz core clock and 252Mhz ram clock sounds fine and logical. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346345: linux-source-2.6.15: radeonfb has inverted frequencies for core/memory?
On Sun, Jan 08, 2006 at 10:12:12AM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 12:15:45AM -0800, obi wrote: On Sun, Jan 08, 2006 at 08:25:46AM +0100, Sven Luther wrote: On Sat, Jan 07, 2006 at 05:43:47PM -0800, obi wrote: radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=252.00 Mhz, System=200.00 MHz and this is what rovclock -i ells Reference clock from BIOS: 27.0 MHz XTAL: 27.0 MHz, RefDiv: 6 Core: 252.0 MHz, Mem: 200.25 MHz Sounds like a rovclock bug, since radeonfb has it right ? Well, the ati command (what was that atitool?) when I tested fglrx reported the same as rovclock. And Xorg repors (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=2 max=35000; xclk=2 These are probably the output parameters, for the screen or something. but I'm not sure how to parse them ... Can you check what the real values are, maybe by using some windows tool on the box, or by hunting the specs of your model on the manufacturer's site or on various review sites ? I don't have windows installed, but I was searching on line these information. I found an article on http://www.anandtech.com/mobile/showdoc.aspx?i=1692p=7 where they claim that M9 (mobility radeon 9000) will have maximum core clock of 250 and maximum memory speed of 230 (that will be effectively doubled been DDR). And these number are somewhat in line with the normal Radeon 900 that comes with a core speed of 250 and memory 200. And the article states that it's likely that on-chip memory will be clocked at 200. If those are indeed the right values, that would definetely explain why I didn't have any problems so far :). Well, the other possibility is that the kernel gets it right, but fails to export it correctly to userland, thus confusing rovclock. I'm not sure how things works there. Does rovclock rely on the kernel, or does it read directly from the video card? I'm not quite sure. If I can help in any way, please let me know. The 200Mhz core clock and 252Mhz ram clock sounds fine and logical. Indeed, the values are so close after all, that I could read them both either way. I guess that's why it took me so long to notice this discrepancy. thanks graziano Friendly, Sven Luther -- +---+--+ | Graziano Obertelli| CS Dept. Rm 102 | | [EMAIL PROTECTED] | University of California | | (805) 893-5212| Santa Barbara, CA 93106 | +---+--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: Hi, at least I lost track a bit, so this mail is basically a question to bring me up to speed. In 2004, there was a GR that decided to put everything in main under the DFSG. We had some discussions, but in the end, the result was that all the non-free firmware bits have to be removed from main before we can release etch. Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? There where two fully independent issues here : 1) some (many) of those firmware using modules had a sloppy licencing situation, which meant the compiled kernels where indeed non-distributable. 2) those firmware blurbs come without source, and are thus non-free. We where working to solve 1), since without that, it was not even possible to distribute these non-free firmwares from even non-free. I think once this is solved the plan was to : 1) either make those drivers be able to load the firmware from an external file, which we could then include in the initramfs from a non-free source. 2) remove those drivers entirely from the main linux-2.6, and have them distributed from the linux-nonfree-2.6 package from our non-free section. Currently neither is done, and we have just reincorporated those modules, in part because our external-module framework and linux-nonfree-2.6 packages where not yet technically ready to handle this, and we chose to concentrate on the other steps first, leaving this aside for later, when the infrastructure would be ready. Now, there is a current of thinking who doesn't agree that those modules require sources and that we should not worry about this, this could be in part true (it is said that some of those firmwares where written directly with an hex-editor, but i believe not all are done such), but it is rather unlikely we will be able to determine that or not. In any case, there are always those, like with the GFDL situation, who would not want to worry about this and let it slip in silently, or hope for another derogation, or simply believe it is not an issue. So, basically, we have postponed the issue until later, when our infrastructure is up to handling this, knowing that the removal of modules and the build of non-free modules in non-free will probably not be such a time-consuming issue that it will be causing major problems. I suppose the right way to solve this (doing 1) is another matter and more of the area of upstream work than debian work, it is the better solution though, not sure if it would be ready for the etch timeframe though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
* Sven Luther ([EMAIL PROTECTED]) [060108 11:12]: There where two fully independent issues here : 1) some (many) of those firmware using modules had a sloppy licencing situation, which meant the compiled kernels where indeed non-distributable. 2) those firmware blurbs come without source, and are thus non-free. We where working to solve 1), since without that, it was not even possible to distribute these non-free firmwares from even non-free. I think once this is solved the plan was to : 1) either make those drivers be able to load the firmware from an external file, which we could then include in the initramfs from a non-free source. 2) remove those drivers entirely from the main linux-2.6, and have them distributed from the linux-nonfree-2.6 package from our non-free section. This matches with what I remember. Currently neither is done, and we have just reincorporated those modules, in With neither, you mean: neither the sloppy licensed modules nor the non-free firmware? part because our external-module framework and linux-nonfree-2.6 packages where not yet technically ready to handle this, and we chose to concentrate on the other steps first, leaving this aside for later, when the infrastructure would be ready. What needs to be done to get the infrastructure ready? Do you think it might make sense to try to get it done e.g. at a BSP? Now, there is a current of thinking who doesn't agree that those modules require sources and that we should not worry about this, this could be in part true (it is said that some of those firmwares where written directly with an hex-editor, but i believe not all are done such), but it is rather unlikely we will be able to determine that or not. Well, there might be cases where the binary blob is enough, but I think we agree that a) this is probably the exception and not the rule, and b) this requires a case-per-case-inspection. In any case, there are always those, like with the GFDL situation, who would not want to worry about this and let it slip in silently, or hope for another derogation, or simply believe it is not an issue. Well, we as release managers have the task to make sure it doesn't slip away (that's one of the reasons there are cheat lis^W^Wtracking lists). If people think it's a non-issues, they can try to change the DFSG - for the release team, the current valid DFSG is part of the RC check list. I suppose the right way to solve this (doing 1) is another matter and more of the area of upstream work than debian work, it is the better solution though, not sure if it would be ready for the etch timeframe though. The question of sloppy licenses is indeed an upstream issue - however, that doesn't mean we can shut our eyes when we come over such an issue. The DFSG-freeness is our own issue. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
On Sun, Jan 08, 2006 at 11:52:20AM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060108 11:12]: There where two fully independent issues here : 1) some (many) of those firmware using modules had a sloppy licencing situation, which meant the compiled kernels where indeed non-distributable. 2) those firmware blurbs come without source, and are thus non-free. We where working to solve 1), since without that, it was not even possible to distribute these non-free firmwares from even non-free. I think once this is solved the plan was to : 1) either make those drivers be able to load the firmware from an external file, which we could then include in the initramfs from a non-free source. 2) remove those drivers entirely from the main linux-2.6, and have them distributed from the linux-nonfree-2.6 package from our non-free section. This matches with what I remember. Currently neither is done, and we have just reincorporated those modules, in With neither, you mean: neither the sloppy licensed modules nor the non-free firmware? Nope, the sloppy licencing is being solved, but none of the solution to 2). part because our external-module framework and linux-nonfree-2.6 packages where not yet technically ready to handle this, and we chose to concentrate on the other steps first, leaving this aside for later, when the infrastructure would be ready. What needs to be done to get the infrastructure ready? Do you think it might make sense to try to get it done e.g. at a BSP? waldi is working on it, and it is on our todo list, i am not sure it is something which can be fixed in a BSP, altough maybe some brainstorm session would be of benefit. Still i think there are other issues of bigger priority right now, and my focus is on the .udeb integration in linux-2.6, as well as some automated config file checking and a better split-config implementation. Once the .udeb integration is done, the next step on my TODO list is indeed the out-of-tree module thingy, which once finalized, would make the linux-non-free-2.6 package easier. We would need to re-remove those drivers though. Now, there is a current of thinking who doesn't agree that those modules require sources and that we should not worry about this, this could be in part true (it is said that some of those firmwares where written directly with an hex-editor, but i believe not all are done such), but it is rather unlikely we will be able to determine that or not. Well, there might be cases where the binary blob is enough, but I think we agree that a) this is probably the exception and not the rule, and b) this requires a case-per-case-inspection. And how exactly can you guarantee this is the case without being the guy who wrote the code, and even so, how could we be sure to thrust such a guy claiming that it is the ultimate source code ? In any case, there are always those, like with the GFDL situation, who would not want to worry about this and let it slip in silently, or hope for another derogation, or simply believe it is not an issue. Well, we as release managers have the task to make sure it doesn't slip away (that's one of the reasons there are cheat lis^W^Wtracking lists). If people think it's a non-issues, they can try to change the DFSG - for the release team, the current valid DFSG is part of the RC check list. But as you said, it is highly unlikely that you will be removing the kernel package, so you need to work with the kernel maintainers :) The main problem is one of ressources, and we need a single person who can devote time and effort to follow up on all those drivers, and see if the firmware can be removed from them or not. Right now everyone is focused on other stuff. I suppose the right way to solve this (doing 1) is another matter and more of the area of upstream work than debian work, it is the better solution though, not sure if it would be ready for the etch timeframe though. The question of sloppy licenses is indeed an upstream issue - however, that doesn't mean we can shut our eyes when we come over such an issue. The DFSG-freeness is our own issue. Nope, upstream didn't care about sloppy licence, the upstream issue is to have the firmware removed from the driver and provide infrastructure to load it from initramfs. But the real problem is we are all volunteers, and if nobody has the will to work on this, what can you do ? And if those more likely to work on this are not convinced by the non-freeness or do not care ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
module packages and linux-nonfree-2.6 infrastructure
Hi folks I implemented an infrastructure for module packages (including linux-nonfree-2.6). It is similar to the gencontrol[1] mechanism used in linux-2.6, in fact it reuses most of the code. It provides currently the following (in the linux-headers-2.6.15 package): - A copy of debian/arch, e.g. the kernel and package config. - A copy of debian/lib. The missing parts are: - A script which does the module package specific tasks. - A makefile snippet. Most of the how to use it-code is already in /people/waldi/linux-nonfree-2.6. Bastian [1] gencontrol builds two files, debian/control and debian/rules.gen. debian/rules.gen is a large makefile, which calls debian/rules.real for any target with a bunch pregenerated data. -- It is more rational to sacrifice one life than six. -- Spock, The Galileo Seven, stardate 2822.3 signature.asc Description: Digital signature
Re: non-free firmware
Hi, * Sven Luther ([EMAIL PROTECTED]) [060108 14:00]: On Sun, Jan 08, 2006 at 11:52:20AM +0100, Andreas Barth wrote: What needs to be done to get the infrastructure ready? Do you think it might make sense to try to get it done e.g. at a BSP? waldi is working on it, and it is on our todo list, i am not sure it is something which can be fixed in a BSP, altough maybe some brainstorm session would be of benefit. Well, if there is anything I can do to help you (including writing mails to d-d-a :), please tell me. Well, there might be cases where the binary blob is enough, but I think we agree that a) this is probably the exception and not the rule, and b) this requires a case-per-case-inspection. And how exactly can you guarantee this is the case without being the guy who wrote the code, and even so, how could we be sure to thrust such a guy claiming that it is the ultimate source code ? Well, in most cases, we cannot make ultimate guarantees. But for example, if you package any software for inclusion in Debian, you normally read through the accompying files. Usually, you can of course take it for granted what is written therein - however, if you notice they look like some GPLed-software, and is now something with an GPL-incompatible license, some more checks are required. The same is true here: One can usually make pretty much progress with some basic common sanity and with looking a bit around. Of course, some corner cases will stay to continue. What we as release team really need is some statement from the maintainers team like we have done some thorough search through the sources, and are sure that the reminder is now DFSG-free (according to the changed DFSG). We usually trust the maintainers about correctly summarizing issues, and also about judging correct whether some software is DFSG-free or not. Of course, we all (and that includes of course also me) sometimes make mistakes, that is just human. Well, we as release managers have the task to make sure it doesn't slip away (that's one of the reasons there are cheat lis^W^Wtracking lists). If people think it's a non-issues, they can try to change the DFSG - for the release team, the current valid DFSG is part of the RC check list. But as you said, it is highly unlikely that you will be removing the kernel package, so you need to work with the kernel maintainers :) The main problem is one of ressources, and we need a single person who can devote time and effort to follow up on all those drivers, and see if the firmware can be removed from them or not. Right now everyone is focused on other stuff. Hm. I have some mean ideas, but let's wait if someone comes up on his own. Thanks for this frank status update for me. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
On Sun, Jan 08, 2006 at 04:04:33PM +0100, Andreas Barth wrote: What we as release team really need is some statement from the maintainers team like we have done some thorough search through the sources, and are sure that the reminder is now DFSG-free (according to the changed DFSG). We usually trust the maintainers about correctly summarizing issues, and also about judging correct whether some software is DFSG-free or not. Of course, we all (and that includes of course also me) sometimes make mistakes, that is just human. Sure, i can make you a statement that there still are non-DFSG free firmware in the current debian kernel package, and i don't know when we will be able to solve the issues, and i heard statement of a few members of the kernel team stating that those binary-only blurbs are the source of themselves, and thus not an issue. So, now, what are you going to do about it, remove the kernel from main and into non-free :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346511: ext3 online resizing doesn't work
Package: linux-2.6 Version: 2.6.15-1 I can't get online resizing of ext3 to work. The kernel spits out EXT3-fs: Unrecognized mount option resize=1572864 or missing value when I try to remount the filesystem, supplying the resize option. Documentation/filesystems/ext3.txt says it should be there, and from what I can understand of fs/ext3/super.c and its parse_options() the resize option is supposed to be understood by the kernel. Am I doing something wrong? I have created the file system using mkfs -E resize. Resizing JFS (using the exact same procedure) works just fine. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
* Sven Luther ([EMAIL PROTECTED]) [060108 17:00]: So, now, what are you going to do about it, remove the kernel from main and into non-free :) As this is a release blocker, not release until this is fixed? (And try to search for someone who can work on this issue, perhaps also say something in the next release update.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
On Sun, Jan 08, 2006 at 05:14:02PM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060108 17:00]: So, now, what are you going to do about it, remove the kernel from main and into non-free :) As this is a release blocker, not release until this is fixed? (And try to search for someone who can work on this issue, perhaps also say something in the next release update.) I believe in 2 month or so it will be the right moment to tackle this. I feel that, as i said on d-r, the work needing done on the packaging infrastructure goes like this : - prepare the kernel so it builds the module .udeb in a way satisfying to the d-i people. - get the out-of-tree module policy up, and make sure each such package respect it. This include triggering a binNMU on the buildds for a new ABI version for those module package, and having them build binary modules for each kernel flavour. - get the third-party patches situation solved neatly I believe we can tackle the non-free modules just after the out-of-tree situation is solved neatly, but i am working on the .udeb situation right now, or more exactly on a newer better split-config handling which will make .udeb generation easier. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340752: linux-source-2.6.14: switches networkdevices unpredictable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I got the same error with 2.6.14. The kernel was assigning network devices randomly on boot despite hard coding them in /etc/modutils/local with: alias eth0 via-rhine alias eth1 8139too Upgrading to 2.6.15 fixed the error, however I also upgraded several other system components, so I am not sure what exactly fixed the bug. But it works now for me. Regards, Bastian - -- ,''`. Bastian Kleineidam : :' :GnuPG Schlüssel `. `'gpg --keyserver wwwkeys.pgp.net --recv-keys 32EC6F3E `- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDwWOpeBwlBDLsbz4RAuY7AJ9l7bK7DeJDuhlxQsYd3/+uY7dmlwCgpt+M 4RxhDtJ1XiRvwFvHJAFZUD0= =lduH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346511: ext3 online resizing doesn't work
* Tore Anderson
I can't get online resizing of ext3 to work.
After some more debugging it seems that the resize option isn't
correctly parsed by fs/ext3/super.c. Patch attached. However, I'm not
too sure if it is correct, right now my mount process is hanging in
blocking I/O state, and there's almost no disk activity. I started it
two and a half hour ago... The only thing the kernel had to say about
it was:
EXT3-fs warning (device dm-3): ext3_group_extend: will only finish group
(4194305 blocks, 1 new)
I suspect ext2online(8) is the only supported way of doing online
resizing, and that the resize= mount option is intentionally broken
because of that. Perhaps it's a relic from the early days of the code
in question... But I don't know.
--
Tore Anderson
Fix parsing of the resize=nblocks ext3 (re)mount option.
Signed-off-by: Tore Anderson [EMAIL PROTECTED]
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 4e67306..1eb16f5 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -681,8 +681,8 @@ static match_table_t tokens = {
{Opt_quota, quota},
{Opt_usrquota, usrquota},
{Opt_barrier, barrier=%u},
+ {Opt_resize, resize=%u},
{Opt_err, NULL},
- {Opt_resize, resize},
};
static unsigned long get_sb_block(void **data)
Re: non-free firmware
Hallo, On Sun, Jan 08, 2006 at 11:10:46AM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? From my point of view, the situation currently looks like this: 1. tg3 and qla2xxx driver status has been solved: upstream has relicensed the drivers - the sourcecode is licensed under the GPL, the firmware data is freely distributable as an aggregate work. 2. Some other drivers permit free distribution, but the license is too restrictive for Debian main. Among these drivers we find acenic, dgrs, smctr and keyspan. These are currently waiting for an updated license or will not likely be relicensed at all (like the acenic driver), thus they are put together in the linux-nonfree-2.6 package. 3. Some drivers still need to be checked, a somewhat outdated status is to be found here: http://wiki.debian.org/KernelFirmwareLicensing So there might still be some drivers we have to relocate from the main package to the non-free one, and possibly some drivers we might not distribute at all. Now, there is a current of thinking who doesn't agree that those modules require sources and that we should not worry about this, this could be in part true (it is said that some of those firmwares where written directly with an hex-editor, but i believe not all are done such), but it is rather unlikely we will be able to determine that or not. In any case, there are always those, like with the GFDL situation, who would not want to worry about this and let it slip in silently, or hope for another derogation, or simply believe it is not an issue. I think the firmware is a data part of the driver, and the driver _as a whole_ is - in the social contract terms - the component we have to look at. If the driver source is available and the license is DFSG-free, it can be distributed in main. What we call firmware is a hexdump of data not executed on the host CPU but uploaded to the hardware during initialization, thus plain simple data from the CPU point of view, and a hexdump is the preferred format of redistribution of this part of the source. In the end, trying to solve this issue, we might find an agreement on the following question: Is the firmware the component which source has to be available in a different format, or is the driver as a whole - including the FW - the component, which we already have the sources from? Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Preparing 2.5.15-2
Hello, I would like to propose a schedule for the next upload of linux-2.6 version 2.6.15-2: I would like to make the dinstall run on tuesday, so everything should be committed and tested until tuesday noontime UTC. Looking at the changelog, there are quiet a few bugs this upload will close, and some changes are pretty important - take alone initramfs-tools becoming the default dependency among initrd tools. If someone needs more time to implement changes which must go into -2, please reply accordingly. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Preparing 2.5.15-2
On Sun, Jan 08, 2006 at 10:03:17PM +0100, Frederik Schueler wrote: If someone needs more time to implement changes which must go into -2, please reply accordingly. I have a few changes I need to make for parisc configs (DISCONTIGMEM didn't get enabled on the 64-bit configs for some reason). I'll try to have this done either tonight, or by midnight EST Monday. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346511: ext3 online resizing doesn't work
* Bastian Blank Stock linux does not support online resizing of ext3. It does (since 2.6.10). I've successfully extended mounted ext3 file systems using ext2online from ext2resize 1.1.19-3 on an unmodified 2.6.15-1-k7. However the more I've looked into it, the more certain I've become that it is Documentation/filesystems/ext3.txt that is incorrect - the resize=nblocks mount option is probably disabled due to the fact that it's not working properly; using ext2online(8) is currently the only way to do it. Or so it seems to me. I just submitted a patch upstream that corrects the documentation, so it's probably going to be fixed in the next upstream release, but it's fine by me to close the bug already now anyway. Kind regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346511: marked as done (ext3 online resizing doesn't work)
Your message dated Sun, 8 Jan 2006 22:18:58 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#346511: ext3 online resizing doesn't work has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 8 Jan 2006 15:56:20 + From [EMAIL PROTECTED] Sun Jan 08 07:56:20 2006 Return-path: [EMAIL PROTECTED] Received: from lust.fud.no ([213.145.167.25]) by spohr.debian.org with esmtp (Exim 4.50) id 1Evcu4-0001aQ-1U for [EMAIL PROTECTED]; Sun, 08 Jan 2006 07:56:20 -0800 Received: from pride.fud.no ([213.145.167.26]) by lust.fud.no with esmtp (Exim 4.50) id 1Evcu1-0005i2-Kr; Sun, 08 Jan 2006 16:56:17 +0100 Received: from localhost ([127.0.0.1]) by pride.fud.no with esmtp (Exim 4.60) (envelope-from [EMAIL PROTECTED]) id 1Evcu1-0001dp-FF; Sun, 08 Jan 2006 16:56:17 +0100 Subject: ext3 online resizing doesn't work From: Tore Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain Date: Sun, 08 Jan 2006 16:56:17 +0100 Message-Id: [EMAIL PROTECTED] Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 Package: linux-2.6 Version: 2.6.15-1 I can't get online resizing of ext3 to work. The kernel spits out EXT3-fs: Unrecognized mount option resize=1572864 or missing value when I try to remount the filesystem, supplying the resize option. Documentation/filesystems/ext3.txt says it should be there, and from what I can understand of fs/ext3/super.c and its parse_options() the resize option is supposed to be understood by the kernel. Am I doing something wrong? I have created the file system using mkfs -E resize. Resizing JFS (using the exact same procedure) works just fine. -- Tore Anderson --- Received: (at 346511-done) by bugs.debian.org; 8 Jan 2006 21:19:01 + From [EMAIL PROTECTED] Sun Jan 08 13:19:01 2006 Return-path: [EMAIL PROTECTED] Received: from wavehammer.waldi.eu.org ([82.139.196.55]) by spohr.debian.org with esmtp (Exim 4.50) id 1EvhwK-0005iP-VC for [EMAIL PROTECTED]; Sun, 08 Jan 2006 13:19:01 -0800 Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000) id 0B4563C028; Sun, 8 Jan 2006 22:18:58 +0100 (CET) Date: Sun, 8 Jan 2006 22:18:58 +0100 From: Bastian Blank [EMAIL PROTECTED] To: Tore Anderson [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#346511: ext3 online resizing doesn't work Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=AhhlLboLdkugWU4S Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.5.11 X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 08, 2006 at 04:56:17PM +0100, Tore Anderson wrote: I can't get online resizing of ext3 to work. The kernel spits out Stock linux does not support online resizing of ext3. Bastian --=20 All your people must learn before you can reach for the stars. -- Kirk, The Gamesters of Triskelion, stardate 3259.2 --AhhlLboLdkugWU4S Content-Type: application/pgp-signature; name=signature.asc Content-Description: Digital signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iEYEARECAAYFAkPBgcIACgkQnw66O/MvCNHcBQCgmpCjtREiqx9jFtnPmoI6pY35 Xe0AoJekTLu86aProY7BovJR6PLLWzUm =h9CW -END PGP SIGNATURE- --AhhlLboLdkugWU4S-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.5.15-2
On Sun, Jan 08, 2006 at 10:03:17PM +0100, Frederik Schueler wrote: I would like to make the dinstall run on tuesday, so everything should be committed and tested until tuesday noontime UTC. will fix the buslogic patch till then. and expect an klibc upload tommorrow. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.5.15-2
On Sunday 08 January 2006 21:03, Frederik Schueler wrote: Hello, I would like to propose a schedule for the next upload of linux-2.6 version 2.6.15-2: I would like to make the dinstall run on tuesday, so everything should be committed and tested until tuesday noontime UTC. Looking at the changelog, there are quiet a few bugs this upload will close, and some changes are pretty important - take alone initramfs-tools becoming the default dependency among initrd tools. If someone needs more time to implement changes which must go into -2, please reply accordingly. Best regards Frederik Schueler Could you put in the change that was in the hostap-source since 2003 and is not in the in kernel version of hostap. Line 31 (a #define) is commented in hostap_config.h. If it is uncommented then hostap will be able to flash new firmware. Please see my earlier post on the subject. Ta David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.5.15-2
Hallo, On Sun, Jan 08, 2006 at 10:23:54PM +, David Goodenough wrote: Could you put in the change that was in the hostap-source since 2003 and is not in the in kernel version of hostap. Line 31 (a #define) is commented in hostap_config.h. If it is uncommented then hostap will be able to flash new firmware. Please see my earlier post on the subject. Can you please file a bug against linux-2.6 on this and possibly add a patch for 2.6.15? Is this change likely to be included upstream, or was it already rejected? Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: non-free firmware
On Sun, Jan 08, 2006 at 09:50:47PM +0100, Frederik Schueler wrote: Hallo, On Sun, Jan 08, 2006 at 11:10:46AM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? From my point of view, the situation currently looks like this: 1. tg3 and qla2xxx driver status has been solved: upstream has relicensed the drivers - the sourcecode is licensed under the GPL, the firmware data is freely distributable as an aggregate work. The firmware is still source-less, and it is not data, as it represents microcode destined to be run on the controller it is uploaded to. They are now distributable at least though, which means we can stick them in non-free. I think the firmware is a data part of the driver, and the driver _as a whole_ is - in the social contract terms - the component we have to look at. If the driver source is available and the license is DFSG-free, it can be distributed in main. Even though i would like it if you were right, and it would make our task easier, this is clearly contrary to what was voted in the last GR, which considered all manner of things as software, and thus needing source, documentation, fonts and naturally firmware. What we call firmware is a hexdump of data not executed on the host CPU but uploaded to the hardware during initialization, thus plain simple data from the CPU point of view, and a hexdump is the preferred format of redistribution of this part of the source. You are trying to ignore the real point though, what we consider code or source or whatever is fully independent of if it runs on the main CPU or on a secondary controller like it is here. It remains code, and it remains binary-only, and thus non-DFSG-free. There is no amount of playing with words which will allow us to ignore that fact, and i am sure that deep inside yourself you also understand this. And no, the hexdump is not the prefered way of modifying this one, at least they run it through a bin2c kind of program, and they have at least some kind of assembler transforming some keywords and such into this binary. In the end, trying to solve this issue, we might find an agreement on the following question: Is the firmware the component which source has to be available in a different format, or is the driver as a whole - including the FW - the component, which we already have the sources from? Each part has to be free on its own, naturally. Imagine if i distributed a non-free binary, which i bin2c'ed into a hexdump, and then i wrote a free program to load it, or even better, which loaded it onto a remote system and executed it there. Would then providing the source code for the loader program mean my binary-only executable becomes free all of a sudden ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268583: marked as done (hotplug failure with shpchp and pciehp)
Your message dated Sun, 8 Jan 2006 23:53:13 +0100 with message-id [EMAIL PROTECTED] and subject line Fwd: Re: Bug#268583: hotplug failure with shpchp and pciehp has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 28 Aug 2004 08:54:06 + From [EMAIL PROTECTED] Sat Aug 28 01:54:06 2004 Return-path: [EMAIL PROTECTED] Received: from p50917c19.dip.t-dialin.net (charlotte.highx.de) [80.145.124.25] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1C0yyM-0001Nt-00; Sat, 28 Aug 2004 01:54:06 -0700 Received: from jsa by charlotte.highx.de with local (Exim 3.36 #1 (Debian)) id 1C0yu3-q1-00 for [EMAIL PROTECTED]; Sat, 28 Aug 2004 10:49:39 +0200 Date: Sat, 28 Aug 2004 10:49:39 +0200 From: Juergen Salk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: hotplug failure with shpchp and pciehp Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: hotplug Version: 0.0.20040329-1 Severity: normal On startup hotplug spews error messages for shpchp and pciehp modules. This is from /var/log/boot: modprobe: FATAL: Error inserting shpchp \ (/lib/modules/2.6.7-1-686/kernel/drivers/pci/hotplug/shpchp.ko): \ Operation not permitted shpchp: can't be loaded missing kernel or user mode driver shpchp Same with pciehp. These are my PCI devices in case it matters: $ lspci :00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 03) :00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 03) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 12) :00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 12) :00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 12) :00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 12) :00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 12) :00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 12) :00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio (rev 12) :01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro Ultra TF :02:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) I'm on Debian 3.1 with kernel-image-2.6.7-1-68 (PIII) and module-init-tools 3.1-pre5-6. Regards - Juergen -- GPG A997BA7A | 87FC DA31 5F00 C885 0DC3 E28F BD0D 4B33 A997 BA7A --- Received: (at 268583-done) by bugs.debian.org; 8 Jan 2006 22:53:43 + From [EMAIL PROTECTED] Sun Jan 08 14:53:43 2006 Return-path: [EMAIL PROTECTED] Received: from poseidon.uni-ak.ac.at ([193.170.188.104] ident=Debian-exim) by spohr.debian.org with esmtp (Exim 4.50) id 1EvjPy-0005MA-Ho for [EMAIL PROTECTED]; Sun, 08 Jan 2006 14:53:42 -0800 Received: from chello062178045213.16.11.tuwien.teleweb.at ([62.178.45.213] helo=[10.1.0.3]) by poseidon.uni-ak.ac.at with esmtpa (Exim 4.50) id 1EvjPs-dT-Av for [EMAIL PROTECTED]; Sun, 08 Jan 2006 23:53:39 +0100 From: David Schmitt [EMAIL PROTECTED] Organization: EDV-BeratungService To: [EMAIL PROTECTED] Subject: Fwd: Re: Bug#268583: hotplug failure with shpchp and pciehp Date: Sun, 8 Jan 2006 23:53:13 +0100 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary=Boundary-00=_afZwDhsAnjejERB Message-Id: [EMAIL PROTECTED] X-test-SpamScore: + X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-5.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER, RCVD_IN_SORBS autolearn=no version=2.60-bugs.debian.org_2005_01_02 --Boundary-00=_afZwDhsAnjejERB Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Version: 2.6.15-1 Mike Gilbert reports this as fixed. Regards, D. =2D-=20 =2D hallo... wie gehts heute? =2D *hust* gut *rotz* *keuch* =2D gott sei dank kommunizieren wir =FCber ein septisches medium ;) -- Matthias Leeb,
Bug#269451: marked as done (hotplug: pciehp / shpchp can't be loaded)
Your message dated Sun, 8 Jan 2006 23:53:13 +0100 with message-id [EMAIL PROTECTED] and subject line Fwd: Re: Bug#268583: hotplug failure with shpchp and pciehp has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 1 Sep 2004 15:29:09 + From [EMAIL PROTECTED] Wed Sep 01 08:29:09 2004 Return-path: [EMAIL PROTECTED] Received: from zivlnx01.uni-muenster.de [128.176.188.24] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1C2X2q-0003Jd-00; Wed, 01 Sep 2004 08:29:09 -0700 Received: from localhost (unknown [127.0.0.1]) by ZIVLNX01.uni-muenster.de (Postfix) with ESMTP id 9CA3C367CC for [EMAIL PROTECTED]; Wed, 1 Sep 2004 17:29:07 +0200 (CEST) Received: from ZIVLNX01.uni-muenster.de ([127.0.0.1]) by localhost (ZIVLNX01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19979-07 for [EMAIL PROTECTED]; Wed, 1 Sep 2004 17:29:07 +0200 (CEST) Received: from EBBALANIN.UNI-MUENSTER.DE (EBBALANIN.UNI-MUENSTER.DE [128.176.122.184]) by ZIVLNX01.uni-muenster.de (Postfix) with ESMTP id F3F24367CA for [EMAIL PROTECTED]; Wed, 1 Sep 2004 17:29:06 +0200 (CEST) Date: Wed, 1 Sep 2004 17:28:42 +0200 (CEST) From: January Weiner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: hotplug: pciehp / shpchp can't be loaded Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at uni-muenster.de Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: hotplug Version: 0.0.20040329-14 Severity: normal During boot time, hotplug gives me the following errors: Sep 1 16:52:58 ebbjw isapnp.rc[6340]: parport_pc: loaded sucessfully Sep 1 16:52:59 ebbjw pci.agent[6431]: intel-agp: already loaded Sep 1 16:53:01 ebbjw pci.agent[6459]: pciehp: can't be loaded Sep 1 16:53:01 ebbjw pci.agent[6459]: missing kernel or user mode driver pciehp Sep 1 16:53:01 ebbjw pci.agent[6459]: shpchp: can't be loaded Sep 1 16:53:01 ebbjw pci.agent[6459]: missing kernel or user mode driver shpchp I do not know how serious is that. I did not observe any adverse effects in my system. The corresponding modules cannot be loaded manually: ebbjw:/home/january# modprobe pciehp FATAL: Error inserting pciehp (/lib/modules/2.6.7-1-386/kernel/drivers/pci/hotplug/pciehp.ko): Operation not permitted ebbjw:/home/january# modprobe shpchp FATAL: Error inserting shpchp (/lib/modules/2.6.7-1-386/kernel/drivers/pci/hotplug/shpchp.ko): Operation not permitted I have a Thinkpad X20 laptop. Could it be somehow related to the fact that hotplug does not load all necessary modules to have a working PS/2 mouse? I need to put psmouse in /etc/modules, otherwise it is not loaded correctly (see bug 247126). Regards, January -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-386 Locale: LANG=pl_PL, LC_CTYPE=pl_PL Versions of packages hotplug depends on: ii debconf 1.4.30 Debian configuration management sy ii grep 2.5.1.ds1-3 GNU grep, egrep and fgrep ii module-init-tools3.1-pre5-6 tools for managing Linux kernel mo ii modutils 2.4.26-1Linux module utilities ii procps 1:3.2.1-2 The /proc file system utilities -- debconf information: hotplug/ignore_pci_class_display: true hotplug/net_agent_policy: hotplug * hotplug/usb_keyboard: hotplug/static_module_list: hotplug/x11_usbmice_hack: false --- Received: (at 268583-done) by bugs.debian.org; 8 Jan 2006 22:53:43 + From [EMAIL PROTECTED] Sun Jan 08 14:53:43 2006 Return-path: [EMAIL PROTECTED] Received: from poseidon.uni-ak.ac.at ([193.170.188.104] ident=Debian-exim) by spohr.debian.org with esmtp (Exim 4.50) id 1EvjPy-0005MA-Ho for [EMAIL PROTECTED]; Sun, 08 Jan 2006 14:53:42 -0800 Received: from chello062178045213.16.11.tuwien.teleweb.at ([62.178.45.213] helo=[10.1.0.3]) by poseidon.uni-ak.ac.at with esmtpa (Exim 4.50) id 1EvjPs-dT-Av for [EMAIL PROTECTED]; Sun, 08 Jan 2006 23:53:39 +0100 From:
Re: Bug#346281: linux-image-2.6.15-1-686: debconf question about /lib/modules/2.6.15-1-686 even if no kernel is installed
reassign 346281 linux-image-2.6.15-1-686 thanks Hi On Fri, 06 Jan 2006 20:23:33 +0100, Ludovic Rousseau [EMAIL PROTECTED] said: Package: linux-image-2.6.15-1-686 Version: 2.6.15-1 Severity: normal I installed linux-headers-2.6.15-1-686 and then linux-image-2.6.15-1-686 and I get the debconf question about You are attempting to install a kernel image (version 2.6.15-1-686). However, the directory /lib/modules/2.6.15-1-686 still exists. The directory /lib/modules/2.6.15-1-686 exists but only contains (because linux-headers-2.6.15-1-686 is already installed): $ ls -al /lib/modules/2.6.15-1-686 total 8 drwxr-xr-x 2 root root 4096 2006-01-06 19:04 . drwxr-xr-x 14 root root 4096 2006-01-06 19:04 .. lrwxrwxrwx 1 root root 35 2006-01-06 19:04 build - /usr/src/linux-headers-2.6.15-1-686 Why is the kernel headers package still installing a build link? The Wiki article at http://wiki.debian.org/KernelModulesPackaging states that we shall use /usr/src/linux-headers-foo as KSRC, and when you install a kernel headers _and a kernel image (in any order), the build link shall be correctly set. Still shipping a build link in the headers package is a bug, and is not supported. kernel-package by itself does not ship a link in the headers package, but handles the link in the postinsts, so that the image and header packages do not have to conflict. manoj -- Living in LA is like not having a date on Saturday night. Candice Bergen Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: err, send to right address
Processing commands for [EMAIL PROTECTED]: reassign 346281 linux-image-2.6.15-1-686 Bug#346281: linux-image-2.6.15-1-686: debconf question about /lib/modules/2.6.15-1-686 even if no kernel is installed Bug reassigned from package `kernel-package' to `linux-image-2.6.15-1-686'. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346604: kernel errors after reboot
Package: linux-image-2.6.14-2-686 Version: 2.6.14-7 I have ALC880. When turn on machine it works fine. kern.log: Jan 9 03:20:07 newarrow kernel: hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... Jan 9 03:20:07 newarrow kernel: hda_codec: Cannot set up configuration from BIOS. Using 3-stack mode... After reboot i have no sound. kern.log: Jan 9 03:04:36 newarrow kernel: hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... Jan 9 03:04:36 newarrow kernel: hda_codec: num_steps = 0 for NID=0x8 Jan 9 03:04:36 newarrow last message repeated 3 times Jan 9 03:04:36 newarrow kernel: hda_codec: num_steps = 0 for NID=0xb Jan 9 03:04:36 newarrow last message repeated 19 times If i reboot again, i have same probs. this happens untill i halt machine. Then, it works fine again till next reboot. I am using Debian GNU/Linux 3.1 with few upgrades from testing: alsa-base 1.0.10-3, libc6 2.3.5-6 (and its dependences) and linux-image-2.6.14-2-686 from unstable. Sergey Nivarov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345864: I've experienced this bug.
IJYTS that I've expereinced this bug and that it corrupted my root file system. However, it only happened under some very unique circumstances. I reinstalled from sarge DVD's, then upgraded to etch pacakges. I then restored my original /etc (which I backed up to a separate partition) and rebooted, which recorrupted my root FS. (This was mid December, right around the 15th). However, if I just went forward with the new udev configuration and restored my hdparm paramters, the problem did not resurface. So I'm not sure if the problem was with one specific version of udev, or perhaps local modifications of the config files, but it was not pleasant. :( This happened with by 2.6.12 and 2.6.13 (and maybe 2.6.8?), so I don't think it's a problem with a specific kernel version but (at least for) a problem with a specific version of udev. I believe I still have my ole /etc and can supply you with lspci output or other information if you feel it would be useful. -- Itai Itai Seggev, University of Mississippi, Department of Physics and Astronomy In 1997 a group of programmers started writing a desktop environment to fix a travesty they didn't create. Their program promptly found its way onto un*x systems everywhere. Today, still opposed by a software monopolist, they survive as soldiers of fortune. If you share their vision, if you know you can help, and if you can connect to internet, maybe you can join... the K-Team. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347147: kernel-headers-2.6: asm/param.h includes linux/autoconf.h
Package: kernel-headers-2.6 Severity: minor With this package installed, when you include sys/params.h in your program, you will get a severe namespace pollution since linux/autoconf.h indirectly gets included and it #undefs all sort of CONFIG_ preprocessor macros (e.g. ELinks using CONFIG_IPV6 macro internally was affected). This is not a major bug; Gentoo and Debian Woody don't have the problem (asm/params.h doesn't include anything), but sys/params.h is probably not standardized anywhere so it's not really specified what exactly happens when you include it. Still, such a wide collateral damage is quite unexpected and wastes some time until it gets discovered what went on... Possible solution would be to grab CONFIG_HZ information at the package build time. -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.5-kam Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Room/Apartment
Hello, I am interested in room.I am based in UK but temporarily in France on a contract job with a MISSIONARY group as a humanitarian.I will be having some seminars coming up soon in the canada and My next programme/seminars will be in the Canada.I will be needing a room to stay for this and I need to secure a room before my arrival to Canada.I am involved in projects that includes orphans,orphanage,heart related diseases in children b/w the ages of 4-10yrs.I will also like to see pics and to know the move in price.Pls do get back to me if this is okay. goodmans. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Strace is broken for kernels 2.6.13 and newer on sparc
Processing commands for [EMAIL PROTECTED]: reassign 339562 linux-2.6 Bug#339562: Strace is broken for kernels 2.6.13 and newer on sparc Bug reassigned from package `strace' to `linux-2.6'. tags 339562 pending Bug#339562: Strace is broken for kernels 2.6.13 and newer on sparc There were no tags set. Tags added: pending thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347178: System Hang on Dialup connection
Package: linux-image-2.6.15-1-k7 Version: 2.6.15-1-k7-1 System hangs on send/revc data with dialup connection. Simply connect with a dialup connection (configured with pppconfig, connected with pon), open a Firefox browser window and open few tabs. System hangs. Sometimes I have the same problem when receiving data in gnome-terminal aith apt-get. There is no problem with kernel: 2.6.14-2-k7-6. Kernel: 2.6.15-1-k7-1 libc6: 2.3.5-11 Same problem with 2 different machines: PC#1: AMD athlon thunderbird 1333MHz Gigabyte 7ZXE M/B 256 MB SD-RAM PC133 Gforce2 MX440 DDR 64MB G/C PC#2: AMD athlon thunderbird 1333MHz Gigabyte 7VM M/B 512 MB DDR 400 RAM ATI Radeon 7000 64 MB Regards, Alan
Bug#317756: marked as done (kernel-image-2.6.11-1-sparc64: console and mouse breakage)
Your message dated Sun, 8 Jan 2006 23:40:50 -0800 (PST) with message-id [EMAIL PROTECTED] and subject line Fixed version is in sid, closing has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 11 Jul 2005 11:10:31 + From [EMAIL PROTECTED] Mon Jul 11 04:10:31 2005 Return-path: [EMAIL PROTECTED] Received: from mail.dl.ac.uk (mserv7.dl.ac.uk) [148.79.80.138] ([9Jw5LosTryUY0DyB3paZgKWvwji7Ljdd]) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DrwBD-0007AR-00; Mon, 11 Jul 2005 04:10:31 -0700 X-DL-MFrom: [EMAIL PROTECTED] X-DL-Connect: albion.dl.ac.uk [148.79.80.39] Received: from albion.dl.ac.uk (albion.dl.ac.uk [148.79.80.39]) by mserv7.dl.ac.uk (8.12.10/8.12.8/[ref [EMAIL PROTECTED]) with ESMTP id j6BBAHQA013988 for [EMAIL PROTECTED]; Mon, 11 Jul 2005 12:10:23 +0100 Received: from fx by albion.dl.ac.uk with local (Exim 4.50) id 1DrwAy-00013A-Ma for [EMAIL PROTECTED]; Mon, 11 Jul 2005 12:10:16 +0100 From: Dave Love [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: kernel-image-2.6.11-1-sparc64: console and mouse breakage X-Debbugs-CC: Dave Love [EMAIL PROTECTED] Date: Mon, 11 Jul 2005 12:10:16 +0100 Message-ID: [EMAIL PROTECTED] User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-CCLRC-SPAM-report: 0 : X-Scanned-By: MIMEDefang 2.37 Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-11.0 required=4.0 tests=BAYES_00,HAS_PACKAGE, X_DEBBUGS_CC autolearn=ham version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: kernel-image-2.6.11-1-sparc64 Version: 2.6.11-5 Severity: normal I have this kernel running OK on a headless system, but it seems to be non-useful on the console. This is on a Blade 100 running OBP 4.15.7, in case that's relevant. The console output is messed up. The first column is missing and a fraction of characters are duplicated/overprinted or replaced by non-ASCII ones. It looks rather as though there's an off-by-one error in assembling bits of a buffer. When I started X, the mouse didn't work -- no pointer appeared -- but there wasn't any obvious error in the server log. I tried unplugging the mouse with no effect. All was OK when I reverted to the stable kernel. -- System Information: Debian Release: 3.1 APT prefers stable APT policy: (900, 'stable') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-sparc64 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages kernel-image-2.6.11-1-sparc64 depends on: ii initrd-tools 0.1.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo kernel-image-2.6.11-1-sparc64 recommends no packages. -- no debconf information --- Received: (at 317756-done) by bugs.debian.org; 9 Jan 2006 07:40:53 + From [EMAIL PROTECTED] Sun Jan 08 23:40:53 2006 Return-path: [EMAIL PROTECTED] Received: from mouth.voxel.net ([69.9.180.118] helo=mail.squishy.cc ident=postfix) by spohr.debian.org with esmtp (Exim 4.50) id 1Evre9-0004u0-NO for [EMAIL PROTECTED]; Sun, 08 Jan 2006 23:40:53 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.squishy.cc (Postfix) with ESMTP id B84AE4C30AAC for [EMAIL PROTECTED]; Mon, 9 Jan 2006 02:40:53 -0500 (EST) Date: Sun, 8 Jan 2006 23:40:50 -0800 (PST) From: Jurij Smakov [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Fixed version is in sid, closing Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no version=2.60-bugs.debian.org_2005_01_02 Version: 2.6.15-1 This was supposed to be closed by the next upload of 2.6.14 which never happened. Fix is now contained in 2.6.15-1 which is now in sid, so closing accordingly. Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To
