[ATrpms-users] Seeking sanity check after madwifi stopped working
Folks, I ran yum update late Saturday, and when I re-booted the machine, it couldn't find my Netgear WG311T. The first couple of lines in .../dmesg looked like: Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00 rhgb quiet ) Linux version 2.6.12-1.1456_FC4 ([EMAIL PROTECTED]) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #1 Thu Sep 22 02:11:36 EDT 2005 If I back off to the previous configuration, I get Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00 rhgb quiet ) Linux version 2.6.12-1.1447_FC4 ([EMAIL PROTECTED]) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #1 Fri Aug 26 20:35:25 EDT 2005 Nosing about in Google to try to figure out what had gone wrong, I stumbled upon atrpms.net/dist/fc4/madwifi, which I recognized as the source of the version of madwifi that used to work (I need to take better notes!). IIRC, last time I clicked on the rpm, clicked on the OK for install process, and magically got the driver installed, and working (or nearly so), but then I was running the same kernel version as the rpm. If I install the 2.6.12-1.1456 madwifi rpm while running the 1447 kernel, will I make a worse mess, or is that the solution? Or do I need to fetch the lan cable, and reboot in 1456 to fix the 1456 kernel? I'm pretty new at this. I think I have the original problem figured out, but don't want to add any complexity I don't need. Is it the case that kmdl indicates a patch to a kernal, and that I can run yum as much as I want, until the kernel version changes, and then I have to come back here and install the new patch? At least until madwifi goes GA? Many thanks, Chuck Sardeson ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Re: FC3 mobo upgrade
never mind, I found the network settings command and reconfigured forcedeth. It had lost all settings due to the unconfigure in hardware detection stuff. The swap thing was just how console #1 looked (I can be such a noob at times lol) and the TV card is now working fine so I guess reception was worse than I thought last night. sorry if anyone wasted time coming up with a solution for me :D Andy On 29/09/05, Andrew Herron [EMAIL PROTECTED] wrote: Hi guys, I may be posting this in the wrong place but I need some help with my FC3 MythTV system. I'm using atrpms, last time I ran an update was maybe a week or two ago. Last night I replaced the motherboard. Went from what I think was a standard nforce2 with mcp-t southbridge, to an nforce2 u400 (old mobo crashed a lot). Having done an even bigger leap on my debian firewall last year, I figured it would be fine. So far, it's behaving more like windows does when you replace the mobo :) First boot, hardware detection finds a bunch of stuff removed so I sat there hitting remove config until it stopped, dropped back to text-only mode and was apparently initialising swap space, but just sat there. ctrl+alt+del appeared to do nothing but eventually rebooted - looks like it wasn't updating the screen at all. Second boot, I told it to keep what remained of the old configuration and add the new stuff. It booted - but now doesn't detect the onboard network card, and when I try to watch TV (using a v-stream xpert DVB-T card) I get lots and lots of glitches (looks a bit like a lack of PCI bandwidth so I'll be fiddling with some bios settings when I get home tonight). Sound card and AGP video card work fine. Is there an easy way to force a re-detection of the missing network card? I'd prefer not to install the nvidia drivers. I'll be trying knoppix tonight to make sure it's not a hardware issue, but was hoping someone here had a few ideas I could try. Cheers, Andy ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Re: ntfs + software suspend
Axel Thimm wrote: On Sat, Jun 25, 2005 at 12:51:00PM +0200, Tako Schotanus wrote: Just wondered who I have to bribe^H^H^H^H^Hconvince to get NTFS and Software Suspend included in the ATrpms repo? :-) In fact NTFS is not much of a problem because the site delivers a large amount of precompiled rpms for all(?) the official kernels but being able to just install it with a simpel apt-get/smart install command would be great. The software suspend (http://mhensler.de/swsusp/index_en.php) is what gives me the most problems, I'm running FC3 on a laptop and the suspend to ram works but I really want suspend to disk. Software Suspend seems to have what it takes and they have a lot of ready-tu-use kernels but of course the moment I install one of those I lose all ATrpms goodness (like the nvidia kernel modules). So any chance that any of this might be included some time? And if so, is there any help that I could give to make it happen (sooner)? ntfs may be supported soon, it's quite easy to add the kmdls. software suspend is a different beast. It requires a separate kernel (not a kmdl) and last time I tried (1-2 years?) it was just eating my PC. I wouldn't mind a special myth kernel as Mark suggested that would have such features in. But I think it will be quite an effort to work on this. Ok, it has been a while but in the last couple of days I've been trying out Matthias Hensler's kernels that include software suspend (http://mhensler.de/swsusp/index_en.php) and they work perfectly for me. So... maybe I could convince you to take another look at software suspend support for the AT kernel? :-D The information on the site is quite extensive and there are all kinds of ready-to-install rpms and such so hopefully it wouldn't be too much work for you to include it into ATrpms. Cheers, -Tako *fingers crossed* :-) PS: Suspending and rebooting to another kernel _will_ cause problems with your harddisk as I found out :-) Luckily nothing to serious in my case. I should have used the suggested patch to the init scripts that empties out the suspend information in the swap partition if you boot a kernel that has no software suspend support. ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Re: Seeking sanity check after madwifi stopped working
On Thu, Sep 29, 2005 at 05:17:33AM -0400, Charles Sardeson wrote: Folks, I ran yum update late Saturday, and when I re-booted the machine, it couldn't find my Netgear WG311T. The first couple of lines in .../dmesg looked like: Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00 rhgb quiet ) Linux version 2.6.12-1.1456_FC4 ([EMAIL PROTECTED]) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #1 Thu Sep 22 02:11:36 EDT 2005 If I back off to the previous configuration, I get Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00 rhgb quiet ) Linux version 2.6.12-1.1447_FC4 ([EMAIL PROTECTED]) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #1 Fri Aug 26 20:35:25 EDT 2005 Nosing about in Google to try to figure out what had gone wrong, I stumbled upon atrpms.net/dist/fc4/madwifi, which I recognized as the source of the version of madwifi that used to work (I need to take better notes!). IIRC, last time I clicked on the rpm, clicked on the OK for install process, and magically got the driver installed, and working (or nearly so), but then I was running the same kernel version as the rpm. If I install the 2.6.12-1.1456 madwifi rpm while running the 1447 kernel, will I make a worse mess, or is that the solution? Yes, that's the solution. Use something like apt/yum/smart install madwifi-kmdl-2.6.12-1.1456 And remember to do so on every kernel upgrade. Unfortunately neither depsolver is cleaver enough to update the kernel modules, too. Or do I need to fetch the lan cable, and reboot in 1456 to fix the 1456 kernel? I'm pretty new at this. I think I have the original problem figured out, but don't want to add any complexity I don't need. Is it the case that kmdl indicates a patch to a kernal, You can look at it that way, although it isn't technically. It is an externally built kernel module, that adds functionality to the kernel. and that I can run yum as much as I want, until the kernel version changes, and then I have to come back here and install the new patch? At least until madwifi goes GA? Yes, unfortunately kmdls need special upgrade treatment. -- Axel.Thimm at ATrpms.net pgpfbm7JpkQ66.pgp Description: PGP signature ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Re: X86_64 FC4 Segmentation Fault
On Tue, Sep 27, 2005 at 04:57:48PM -0400, Graham Bowman wrote: Mr Thimm, Would you be able to point me to directions where I can learn about how to install the x86_64 rpms while using the i386 plugins? I don't think that's possible. It is either using i386 myth or x86_64 myth. You can't mix i386 plugins with x86_64 mythtv. On 9/26/05, Axel Thimm [EMAIL PROTECTED] wrote: On Sun, Sep 25, 2005 at 10:09:49AM -0400, Graham Bowman wrote: All the individual themes are noarch, while the mythtv-themes package is x86_64. That's OK. This is the second time I've slicked and reinstalled everything from scratch using Mr. Wilson's FC4 guide, after having stupidly just slicked a (somewhat) perfectly running .17 box. But mythtv 0.17 was not on 64 bits, or was it? At least under FC4 the builds would fail until recently. The issue is that for some reason some mythtv bits want to use /usr/lib/qt-3.3 instead of /usr/lib64/qt-3.3/. On 9/25/05, Axel Thimm [EMAIL PROTECTED] wrote: On Sun, Sep 25, 2005 at 12:37:21AM -0400, Graham Bowman wrote: [EMAIL PROTECTED] ~]$ mythfrontend 2005-09-24 23:09:16.819 New DB connection, total: 1 Total desktop width=1280, height=1024, numscreens=1 2005-09-24 23:09:16.832 Using screen 0, 1280x1024 at 0,0 2005-09-24 23:09:16.836 mythfrontend version: 0.18.1.20050523-1 www.mythtv.org http://www.mythtv.org http://www.mythtv.org http://www.mythtv.org 2005-09-24 23:09:16.837 Enabled verbose msgs : important general Conflict in /usr/lib/qt-3.3/plugins/styles/bluecurve.so: Plugin uses incompatible Qt library! expected build key x86_64 Linux g++-4.* full-config, got i686 Linux g++-4.* full-config. This looks like you are using some i686 plugins on x86_64. You can't mix those, you can choose to use only i386 or only x86_64 myth bits. Try something like rpm -qa --qf '[EMAIL PROTECTED]' myth\* to check what archs the packages have. -- Axel.Thimm at ATrpms.net pgpbzEAAn5bsz.pgp Description: PGP signature ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Re: X86_64 FC4 Segmentation Fault
On Tue, Sep 27, 2005 at 02:20:34PM -0700, Alexandre Parenteau wrote: Axel, Thanks for your response. Yesterday the problem was fixed after I did a svn up. I could use successfully mythtv on my AMD64/Hauppauge350, yeah! That's nice! Was it in HEAD or in fixes? If the latter I would respin packages. alex. Axel Thimm wrote: On Sun, Sep 25, 2005 at 09:07:31PM -0700, Alexandre Parenteau wrote: Hi, I am a new user, and I had the same problem (I used the RPM ar first). I went as far as compiling mythtv directly from svn, and I get the same problem at start-up, something with threads being spawned (?): Yes, that looks like a thread problem, but probably not related to the other reported problems. Since even svn shows this, I would report it to the mythtv lists. Unfortunatley most developers don't use mythtv on 64 bits, so some issues slip in. BTW you can use the 32 bit variant of mythtv until this is fixed. /usr/local/bin/mythfrontend 2005-09-25 20:56:20.149 Using runtime prefix = /usr/local Detaching after fork from child process 7377. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 2005-09-25 20:56:21.617 New DB connection, total: 1 2005-09-25 20:56:21.622 Total desktop dim: 1280x1024, with 1 screen[s]. 2005-09-25 20:56:21.624 Using screen 0, 1280x1024 at 0,0 [New Thread 1084229984 (LWP 7380)] Program received signal SIG33, Real-time event 33. [Switching to Thread 1084229984 (LWP 7380)] 0x2e05e8f2 in clone () from /lib64/libc.so.6 (gdb) thread [Current thread is 2 (Thread 1084229984 (LWP 7380))] (gdb) thread 1 [Switching to thread 1 (Thread 46912561695648 (LWP 7374))]#0 0x2d9f182a in __nptl_setxid () from /lib64/libpthread.so.0 (gdb) bt #0 0x2d9f182a in __nptl_setxid () from /lib64/libpthread.so.0 #1 0x2e028107 in setuid () from /lib64/libc.so.6 #2 0x0042638a in ?? () #3 0x2dfb13cf in __libc_start_main () from /lib64/libc.so.6 #4 0x0041f8b9 in ?? () #5 0x7f804e98 in ?? () #6 0x in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 1084229984 (LWP 7380))]#0 0x2e05e8f2 in clone () from /lib64/libc.so.6 (gdb) bt #0 0x2e05e8f2 in clone () from /lib64/libc.so.6 #1 0x2d9f28f0 in __make_stacks_executable () from /lib64/libpthread.so.0 #2 0x40a00960 in ?? () #3 0x in ?? () Thanks, alex. ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users -- Axel.Thimm at ATrpms.net pgp6eXdjJ1zTY.pgp Description: PGP signature ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Re: ntfs + software suspend
Axel Thimm wrote: On Thu, Sep 29, 2005 at 06:33:14PM +0200, Tako Schotanus wrote: Axel Thimm wrote: On Sat, Jun 25, 2005 at 12:51:00PM +0200, Tako Schotanus wrote: Just wondered who I have to bribe^H^H^H^H^Hconvince to get NTFS and Software Suspend included in the ATrpms repo? :-) In fact NTFS is not much of a problem because the site delivers a large amount of precompiled rpms for all(?) the official kernels but being able to just install it with a simpel apt-get/smart install command would be great. The software suspend (http://mhensler.de/swsusp/index_en.php) is what gives me the most problems, I'm running FC3 on a laptop and the suspend to ram works but I really want suspend to disk. Software Suspend seems to have what it takes and they have a lot of ready-tu-use kernels but of course the moment I install one of those I lose all ATrpms goodness (like the nvidia kernel modules). So any chance that any of this might be included some time? And if so, is there any help that I could give to make it happen (sooner)? ntfs may be supported soon, it's quite easy to add the kmdls. software suspend is a different beast. It requires a separate kernel (not a kmdl) and last time I tried (1-2 years?) it was just eating my PC. I wouldn't mind a special myth kernel as Mark suggested that would have such features in. But I think it will be quite an effort to work on this. Ok, it has been a while but in the last couple of days I've been trying out Matthias Hensler's kernels that include software suspend (http://mhensler.de/swsusp/index_en.php) and they work perfectly for me. So... maybe I could convince you to take another look at software suspend support for the AT kernel? :-D The information on the site is quite extensive and there are all kinds of ready-to-install rpms and such so hopefully it wouldn't be too much work for you to include it into ATrpms. Well, jam with the best, I Cced Matthias, maybe he would be interested in maintaining kernel and other related patched packages within ATrpms. I think that would be the best configuration. Matthias, would that be something you'd like to do? Great! But that would mean another set of kernel modules (alsa, nividia, ati, ntfs etc) for each of those kernels as well wouldn't it? Well I guess your build system will take care of that. Which makes me wonder (like I do again and again in times like this) why there isn't a system that will automatically rebuild any kernel modules you got from sources each time you install a new kernel? Has this been tried but found unworkable? Cheers, -Tako ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Re: ntfs + software suspend
On Thu, Sep 29, 2005 at 06:39:40PM +0200, Tako Schotanus wrote: Axel Thimm wrote: On Thu, Sep 29, 2005 at 06:33:14PM +0200, Tako Schotanus wrote: Axel Thimm wrote: On Sat, Jun 25, 2005 at 12:51:00PM +0200, Tako Schotanus wrote: Just wondered who I have to bribe^H^H^H^H^Hconvince to get NTFS and Software Suspend included in the ATrpms repo? :-) The software suspend (http://mhensler.de/swsusp/index_en.php) is what gives me the most problems, I'm running FC3 on a laptop and the suspend to ram works but I really want suspend to disk. Software Suspend seems to have what it takes and they have a lot of ready-tu-use kernels but of course the moment I install one of those I lose all ATrpms goodness (like the nvidia kernel modules). ntfs may be supported soon, it's quite easy to add the kmdls. software suspend is a different beast. It requires a separate kernel (not a kmdl) and last time I tried (1-2 years?) it was just eating my PC. I wouldn't mind a special myth kernel as Mark suggested that would have such features in. But I think it will be quite an effort to work on this. Ok, it has been a while but in the last couple of days I've been trying out Matthias Hensler's kernels that include software suspend (http://mhensler.de/swsusp/index_en.php) and they work perfectly for me. So... maybe I could convince you to take another look at software suspend support for the AT kernel? :-D The information on the site is quite extensive and there are all kinds of ready-to-install rpms and such so hopefully it wouldn't be too much work for you to include it into ATrpms. Well, jam with the best, I Cced Matthias, maybe he would be interested in maintaining kernel and other related patched packages within ATrpms. I think that would be the best configuration. Matthias, would that be something you'd like to do? Great! But that would mean another set of kernel modules (alsa, nividia, ati, ntfs etc) for each of those kernels as well wouldn't it? Yes. Well I guess your build system will take care of that. :) Which makes me wonder (like I do again and again in times like this) why there isn't a system that will automatically rebuild any kernel modules you got from sources each time you install a new kernel? Has this been tried but found unworkable? There is, it's called dkms, and is written by Gary Lerhaupt, and sponsored by Dell: http://linux.dell.com/projects.shtml#dkms It (re)builds all dkmsified kernel module src installs for every new kernel, just like ATrpms' buildsystem does, only on the client's site. It's a different kind of distribution model, check the docu found at the link. -- Axel.Thimm at ATrpms.net pgprk4dtU0mzo.pgp Description: PGP signature ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Problems with yum
Hello, I used ATRpms to try installing MythTV on Fedora Core 4 and now, I cannot use yum update anymore. Every time I try to use it, it complains about missing dependencies or wants to install undreds of packages. I discovered that by installing mythtv-suite, I also installed a package providing yum repositories configuration. I wanted to uninstall it to get my old yum configuration and now, Yum does not want to start anymore. To summarize, ATRpms completely screwed up my Linux system. I really don't have time to reinstall my whole system and my machine. Reinstalling is very complex because of font configuration problems. Is there any way to repair the system? Thanks ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Re: ntfs + software suspend
On Thu, Sep 29, 2005 at 06:25:26PM +0200, Axel Thimm wrote: On Thu, Sep 29, 2005 at 06:33:14PM +0200, Tako Schotanus wrote: Ok, it has been a while but in the last couple of days I've been trying out Matthias Hensler's kernels that include software suspend (http://mhensler.de/swsusp/index_en.php) and they work perfectly for me. So... maybe I could convince you to take another look at software suspend support for the AT kernel? :-D The information on the site is quite extensive and there are all kinds of ready-to-install rpms and such so hopefully it wouldn't be too much work for you to include it into ATrpms. Well, jam with the best, I Cced Matthias, maybe he would be interested in maintaining kernel and other related patched packages within ATrpms. I think that would be the best configuration. Matthias, would that be something you'd like to do? First of all, since I am not subscribed to the atrmps-Mailinglist I would like if you could keep me in Cc. Regarding your question: I am aware that there are many 3rd party kernel modules which are not part of the Fedora standard kernel and will never be. In fact I have to compile a lot of stuff for myself with each new kernel. The main problem with software suspend is, that it is not modular (in fact it was for some time, but is not any longer), changes a lot in the kernel (although it had not break much lately) and needs several things to get it running (initrd patching, changes in the kernel commandline and several userspace stuff). While swsusp1 is part of the vanilla kernel since 2.6, it is disabled in the Fedora standard kernels (and will be at least for FC3 and FC4). Currently there are some changes regarding this, as rawhide has swsusp1 enabled kernels since August 2005 and some support in recent mkinitrd-packages. However, swsusp2 seems to be much more stable today and is working to get it integrated into the vanilla kernel tree. I suppose that will take some time, and won't likely to show up in the Fedora kernel before FC6. At the moment I try my best to provide stable and working kernels for FC3, FC4 and rawhide, together with a set of needed packages to make setup easier (for most systems it is currently enough to install the swsusp2 enabled kernel RPM, with the hibernate, userui and swsusp2-mkinitrd RPMs and modify the kernel commandline). However, I do not have a build system at the moment which would me allow to build anything besides i686 packages. For all other architectures, as well for features like Xen-support (not sure if anyone ever tested this with swsusp2), the people are on the own to rebuild the RPMs. I would happy to see support for swsusp2-kernels in ATrpms, but that would need some coordination. As explained above I do not see any other possiblity as to spin seperate kernel RPMs at the moment. What I can do, is to rebuild the packages from ATrpms for my kernel versions (at least for i686-up) and either provide them on my page, or directly at ATrpms, whatever the best solution here is. That would lead to the question about the different architectures. Most users are happy with i686-up at the moment, but since there a lot of notebooks with hyper threading and 64bit it could make sense to provide i686-smp, x86_64 and x86_64-smp as well (I am not totally sure about the status of SMP and 64bit, but there were some effords to get it work for the upcoming 2.2 release of swsusp2). I should be able to build everything, including the ATrpms kernel modules, for i686, but would need help for all the rest. I am open for suggestions, so just let me know what you think and how it could be done. Regards, Matthias pgpmE5plxbXHU.pgp Description: PGP signature ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Re: Problems with yum
On Sun, Sep 25, 2005 at 11:43:39AM -0400, Eric Buist wrote: Hello, I used ATRpms to try installing MythTV on Fedora Core 4 and now, I cannot use yum update anymore. Every time I try to use it, it complains about missing dependencies or wants to install undreds of packages. I discovered that by installing mythtv-suite, I also installed a package providing yum repositories configuration. I wanted to uninstall it to get my old yum configuration and now, Yum does not want to start anymore. To summarize, ATRpms completely screwed up my Linux system. Don't blame ATrpms when using rpm -e -nodeps --force :) I really don't have time to reinstall my whole system and my machine. Reinstalling is very complex because of font configuration problems. Is there any way to repair the system? Thanks First you need to get yum running again. What package did you remove? Try to reinstall it manually from http://ATrpms.net/name/ -- Axel.Thimm at ATrpms.net pgptfeTKadZxW.pgp Description: PGP signature ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
[ATrpms-users] Re: ntfs + software suspend
On Thu, Sep 29, 2005 at 07:10:21PM +0200, Matthias Hensler wrote: On Thu, Sep 29, 2005 at 06:25:26PM +0200, Axel Thimm wrote: On Thu, Sep 29, 2005 at 06:33:14PM +0200, Tako Schotanus wrote: Ok, it has been a while but in the last couple of days I've been trying out Matthias Hensler's kernels that include software suspend (http://mhensler.de/swsusp/index_en.php) and they work perfectly for me. So... maybe I could convince you to take another look at software suspend support for the AT kernel? :-D The information on the site is quite extensive and there are all kinds of ready-to-install rpms and such so hopefully it wouldn't be too much work for you to include it into ATrpms. Well, jam with the best, I Cced Matthias, maybe he would be interested in maintaining kernel and other related patched packages within ATrpms. I think that would be the best configuration. Matthias, would that be something you'd like to do? First of all, since I am not subscribed to the atrmps-Mailinglist I would like if you could keep me in Cc. Regarding your question: I am aware that there are many 3rd party kernel modules which are not part of the Fedora standard kernel and will never be. In fact I have to compile a lot of stuff for myself with each new kernel. Yes, your kernel would become a supported kernel at ATrpms which means that all flavour/arch combinations for ia32 and x86_64 would be supported by the kmlds at ATrpms, too. The main problem with software suspend is, that it is not modular (in fact it was for some time, but is not any longer), changes a lot in the kernel (although it had not break much lately) and needs several things to get it running (initrd patching, changes in the kernel commandline and several userspace stuff). While swsusp1 is part of the vanilla kernel since 2.6, it is disabled in the Fedora standard kernels (and will be at least for FC3 and FC4). Currently there are some changes regarding this, as rawhide has swsusp1 enabled kernels since August 2005 and some support in recent mkinitrd-packages. However, swsusp2 seems to be much more stable today and is working to get it integrated into the vanilla kernel tree. I suppose that will take some time, and won't likely to show up in the Fedora kernel before FC6. At the moment I try my best to provide stable and working kernels for FC3, FC4 and rawhide, together with a set of needed packages to make setup easier (for most systems it is currently enough to install the swsusp2 enabled kernel RPM, with the hibernate, userui and swsusp2-mkinitrd RPMs and modify the kernel commandline). However, I do not have a build system at the moment which would me allow to build anything besides i686 packages. For all other architectures, as well for features like Xen-support (not sure if anyone ever tested this with swsusp2), the people are on the own to rebuild the RPMs. I would happy to see support for swsusp2-kernels in ATrpms, but that would need some coordination. As explained above I do not see any other possiblity as to spin seperate kernel RPMs at the moment. Yes, that's the way to go. Some things can't be build externally, then we need to supply a different kernel and also all kmdl that go along with it. ATrpms had such kernels for 2.4 including openswan/xfs/v4l2 etc that could not be built separately. For recent FC released kernels there haven't been many projects that cannot be built externally and that would be of general interest to justify respinning kernel packages. swsusp is one of them. What I can do, is to rebuild the packages from ATrpms for my kernel versions (at least for i686-up) and either provide them on my page, or directly at ATrpms, whatever the best solution here is. Best thing would be at ATrpms, and even by the buildsystem there. That would lead to the question about the different architectures. Most users are happy with i686-up at the moment, but since there a lot of notebooks with hyper threading and 64bit it could make sense to provide i686-smp, x86_64 and x86_64-smp as well (I am not totally sure about the status of SMP and 64bit, but there were some effords to get it work for the upcoming 2.2 release of swsusp2). Even if there are bugs, it would be nice to habe x86_64 and smp, so people can test and report to swsusp upstream. I should be able to build everything, including the ATrpms kernel modules, for i686, but would need help for all the rest. I am open for suggestions, so just let me know what you think and how it could be done. How about the following model: o Development of the packages happen on your box o When you are happy to release a kernel package you upload the src.rpm to the ATrpms build server via rsync+ssh. o You let the buildserver generate kernels for i386/x86_64 on all flavours (including smp and xen) and all subarchs, as well as all supporting kmdls. o Packages get automatically into ATrpms'
[ATrpms-users] Re: ntfs + software suspend
On Thu, Sep 29, 2005 at 07:41:40PM +0200, Axel Thimm wrote: On Thu, Sep 29, 2005 at 07:10:21PM +0200, Matthias Hensler wrote: Regarding your question: I am aware that there are many 3rd party kernel modules which are not part of the Fedora standard kernel and will never be. In fact I have to compile a lot of stuff for myself with each new kernel. Yes, your kernel would become a supported kernel at ATrpms which means that all flavour/arch combinations for ia32 and x86_64 would be supported by the kmlds at ATrpms, too. That sounds quite good. We will have to see if the kernels compile well, since these archs are not really tested. [...] I would happy to see support for swsusp2-kernels in ATrpms, but that would need some coordination. As explained above I do not see any other possiblity as to spin seperate kernel RPMs at the moment. Yes, that's the way to go. Some things can't be build externally, then we need to supply a different kernel and also all kmdl that go along with it. ATrpms had such kernels for 2.4 including openswan/xfs/v4l2 etc that could not be built separately. For recent FC released kernels there haven't been many projects that cannot be built externally and that would be of general interest to justify respinning kernel packages. swsusp is one of them. OK, good. What I can do, is to rebuild the packages from ATrpms for my kernel versions (at least for i686-up) and either provide them on my page, or directly at ATrpms, whatever the best solution here is. Best thing would be at ATrpms, and even by the buildsystem there. Yes, good to hear, that would save me lots of CPU time and the need of an own buildsystem. That would lead to the question about the different architectures. Most users are happy with i686-up at the moment, but since there a lot of notebooks with hyper threading and 64bit it could make sense to provide i686-smp, x86_64 and x86_64-smp as well (I am not totally sure about the status of SMP and 64bit, but there were some effords to get it work for the upcoming 2.2 release of swsusp2). Even if there are bugs, it would be nice to habe x86_64 and smp, so people can test and report to swsusp upstream. Sure. I do not know how good the kernels build and work currently, but I think it is a good time to find out. I am open for suggestions, so just let me know what you think and how it could be done. How about the following model: o Development of the packages happen on your box o When you are happy to release a kernel package you upload the src.rpm to the ATrpms build server via rsync+ssh. o You let the buildserver generate kernels for i386/x86_64 on all flavours (including smp and xen) and all subarchs, as well as all supporting kmdls. o Packages get automatically into ATrpms' repo that way, and are available for apt/yum/smart etc. Nice, that really looks good to me, and I would be happy to help. The packages would have to be labeled testing or even experimental at first, so noone gets burned. Slowly we can increase the stability level as we get more confident with the user feedback (or not, if it is negative, of course). OK, that sounds good too. It will help to enlarge the user basis and provide feedback for the swsusp2-developers. When all goes well, you will get a few envy people from the RHEL4 camp asking you to weave swsusp into RHEL4 kernels, too. :) That would need some work, since RHEL kernels are quite older then the Fedora ones, but why not ;-) Regards, Matthias pgpWglZydEDoQ.pgp Description: PGP signature ___ atrpms-users mailing list atrpms-users@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-users
