Re: What happens with cvs.fedora.redhat.com
On Tue, 2010-01-05 at 08:40 +0100, Stanislaw Gruszka wrote: What happens with cvs.fedora.redhat.com? If it is shutdown permanently where I can get current fedora kernel sources? cvs.fedoraproject.org -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Installing F12-Beta
On Mon, 2009-11-02 at 15:47 +0800, Steven James Drinnan wrote: David why you are so upset? No need to get nasty. I simply posted a message about my problems installing F12. I did not Hijack any thread (see the subject name). I thought this was a public forum. I sent this to the whole mailing list. My apologies if I offended you. I'm not upset, and wasn't nasty. I was just trying to help you communicate more effectively, and without adding noise to other discussions. You _did_ hijack the thread -- you replied to Adam's message, using your 'reply' button instead of composing a new message to the list. Your mail is clearly marked, in its headers which I quoted, as a reply to that previous message -- as part of that older thread. It should have been a _new_ thread, not a reply to the existing thread. Please don't do that. And, while we're at it, please don't top-post either. And please remember to quote only what you actually need for context rather than repeating the _whole_ of the message to which you're replying. You may find http://david.woodhou.se/email.html to be useful reading. All I can tell you is what happened. Which is I put the DVD in the drive and after a while it came up with a recursive error and said it was fixed but needed to restart the computer. You _still_ didn't actually post the precise text of the error you saw, along with any output leading up to it. It's almost as if you don't _want_ people to be able to help you. Now that you posted the actual bug number rather than just teasing us with I put it in bugzilla but I'm not telling you where as you did in your previous mail, I can see that you didn't post the full error there, either. Please, show us the words you actually see on the screen -- or take a photo, perhaps. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Installing F12-Beta
On Mon, 2009-11-02 at 08:29 +0800, Steven James Drinnan wrote: In-reply-to: 1257111085.2314.154.ca...@adam.local.net References: adf480660910311031h5889985by4fb8d4ac7f342...@mail.gmail.com 1257111085.2314.154.ca...@adam.local.net Steven, please could you explain the relationship between your message on 'Installing F12-Beta' and the message to which you replied, which was about upstream developers becoming co-maintainers. If there is no relationship, then you've just hijacked an existing thread by posting your unrelated query as a reply to it -- please don't do that. You may also find that you'll get more help if you provide a more coherent bug report. You neglected to give any useful details about the error you see. Giving the full error message might have helped. Or even telling us at which stage of the boot it happens might have given a clue. I'd look in the bug you filed to see if you provided that information there... but you didn't even bother to tell us the bug number. My crystal ball isn't working today, so I _couldn't_ help you, even if I _didn't_ have a policy of not helping thread-hijackers until they post their problem politely ;) -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora PPC for oldworld Mac?
On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote: On 09-10-28 18:24:49, Josh Boyer wrote: On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote: Sorry to bug developers, but I didn't get any bites from PPC users on fedora-list. Does Fedora PPC work or install on oldworld PCI Macs, such as a beige G3 desktop? My impression is that no one has tried it on an oldworld No, it doesn't. The ppc specific release notes cover that here: http://docs.fedoraproject.org/release-notes/f11/en-US/ index.html#sect-Release_Notes-Hardware_Requirements I'd looked at the release notes. They says Minimum CPU: PowerPC G3... and Although Old World machines should work, they require a special bootloader which is not included in the Fedora distribution. My question is whether anyone has tried it in any recent Fedora release and knows whether should means do or don't. (FWIW, the special bootloader is BootX, and Debian Lenny is installing now, so /some/ form of Linux works. I just don't know anything but hearsay about Debian. I see it uses apt.) I don't know of anyone who's tried it recently, but in the past we've fixed things in the kernel to make it work properly on OldWorld Macs and it _has_ been known to work fine. It _ought_ to work if you sort out the bootloader. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Cannot rely on /dev being present in %post scripts?
According to bug #517013, %post scripts should not assume that /dev is available -- so we can't do anything that requires the existence of /dev/null, /dev/urandom, etc. Is this a known and expected packaging rule, or is it a bug in the way that the user is attempting to install the packages? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote: As described on the Feature page, but if there's any specific questions about the reasoning on there I'll be happy to answer those questions. I had read the feature page, in which you claim that a three-year cycle disqualifies the distribution(s) as desktop Linux distributions. I didn't see any justification for that assertion, especially given that you're simultaneously claiming that a 13-month lifetime isn't long _enough_ for you. You've conveniently dodged the question of what lifetime you _do_ want to provide, by saying 'yet to be determined'. But you must have _some_ idea, if you're so sure that 13 months is too short and 36 months is too long. So if three years is too long and one year is too short, what _do_ you want? 2 years? 18 months? 18 months would be a single extra Fedora release, and that _might_ be something we could make some progress on. How much work would it take, to make it possible for us to still ship updates for a release which has officially reached EOL? Does the sky fall on our heads if we don't push the 'Kill F-9' button in koji and bodhi precisely 1 month after the F-11 release? As a first step, perhaps we try that -- still officially state that the release is EOL and should not be used, but _allow_ interested people like Jeroen (and the original package owners, _if_ they are so inclined) to continue to build and push updates, instead of forcibly cutting off builds and updates as we do at the moment. That _isn't_ something we would publish as a 'feature' though -- it would strictly _unofficial_, although you'd be permitted to use the Fedora infrastructure for it. If it turns out that there _is_ enough interest and the interested people are _actually_ keeping on top of security fixes etc., then maybe we could consider officially admitting that it happens, and _then_ publishing it as a 'feature'. And/or extending it to more than one extra release. But those are all questions for the future. If it doesn't take too much infrastructure work, I see no reason why we shouldn't let them _try_. It doesn't hurt Fedora at all, does it? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 2009-07-05 at 12:03 +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. Does that make sense? As a standalone observation, perhaps -- some desktop users often don't want old, stagnant code; they'd prefer the latest bells and whistles. But it makes no sense when considered in conjunction with your apparent desire for an old, stagnant version of Fedora. What makes you think it would be any different? It's not exactly difficult or problematic to update from one version of Fedora to the next. I do it on each of my servers at least once a year (I usually skip a release, but not always). And those are mostly headless, remote boxes. If you want new stuff, run Fedora and do a fairly painless update annually. If you want old stuff, run Centos and update less frequently. I don't see any need for a middle ground. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, 2009-07-02 at 16:28 +0100, Peter Robinson wrote: http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 Unrelated to this issue, but please use make V=1 so we see the actual build command lines in the build.log (see the thread about the new automake). With V=1 http://koji.fedoraproject.org/koji/getfile?taskID=1450335name=build.log You know you can have access to a real box to test this on if you want it, right? You don't have to do it all in koji and look at the build logs. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Wed, 2009-06-17 at 02:55 +0200, Kevin Kofler wrote: Bruno Wolff III wrote: Is there going to be a way to tell which binaries actually use sse2 instructions, so that the others can be inherited by a secondary arch? Due to how GCC works, if the compiler flags enable SSE/SSE2, basically all the binaries will be using some SSE/SSE2 instructions. And on the various SSE-capable CPUs, how much benefit does that actually give us? I'm after a system-wide answer, not a microbenchmark for zlib or crypto code. It should take into account any overheads involved in saving/restoring registers on context switch that wouldn't otherwise have to be saved/restored. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: f11 ppc64 woes
On Sat, 2009-06-06 at 16:13 +0100, David Woodhouse wrote: I blame yaboot... Fixed in yaboot-1.3.14-13 (thanks to benh for pointing out the problem). We missed the boat to get that in F11 GA, right? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: f11 ppc64 woes
On Sun, 7 Jun 2009, Josh Boyer wrote: On Sun, Jun 07, 2009 at 09:28:25AM +0100, David Woodhouse wrote: On Sat, 2009-06-06 at 16:13 +0100, David Woodhouse wrote: I blame yaboot... Fixed in yaboot-1.3.14-13 (thanks to benh for pointing out the problem). We missed the boat to get that in F11 GA, right? Pretty sure. Jesse is getting on a plane today, and we release Tuesday. 0-day update it seems. Though that isn't going to help the installer any. We might have to recommend yum updating or pre-upgrade for the machines this impacted. Or 'netboot' with the zImage, which can be done from the CD. Precisely where in the release kernel does the 4MiB corruption happen? -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: f11 ppc64 woes
On Sat, 2009-06-06 at 09:54 -0400, Josh Boyer wrote: ybin isn't needed on the powerstation iirc. Anyway, that is indeed odd. We should have Tony take a look at this if possible. Or if David can remeber how to do a netboot directly from OF (and skipping yaboot), that would be a good test too. /usr/sbin/wrapper -o zImage /boot/vmlinuz-2.6.29.4-167.fc11.ppc64 \ -i /boot/initrd-2.6.29.4-167.fc11.ppc64.img Give resulting zImage to OpenFirmware. Various versions of OF have different bugs with that (image size, etc.) but I think the PowerStation ought to be fine. You could also try using kexec -- that should help eliminate yaboot bugs too. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Maintainer Responsibilities
On Tue, 2009-06-02 at 16:17 -0400, Steve Grubb wrote: I don't want to start a long thread, but just to ask a couple questions for my own clarification. Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? There are _some_ kinds of bug (feature requests, etc.) which it's reasonable for any decent maintainer to punt upstream. There are other kinds of bugs (crashes, security issues -- perhaps even _anything_ that's a real bug rather than an RFE) which the maintainer really _ought_ to deal with directly. Opinions vary on precisely where the boundary between those classes should be, but I'm fairly adamant it should be 'RFE vs. bug'. Any packager who _isn't_ capable of handling the latter class of bug probably shouldn't be maintaining the package without the assistance of a co-packager or their sponsor. Note that you don't _have_ to be able to code to handle a real bug in an acceptable fashion -- decent coordination with upstream can be perfectly sufficient, if upstream are responsive enough. But just closing the bug in our bugzilla as 'upstream' is rarely acceptable for a _real_ bug, IMHO. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: config changes
On Tue, 2009-01-13 at 13:39 -0800, Chris Wright wrote: * Dave Jones (da...@redhat.com) wrote: On Tue, Jan 13, 2009 at 09:55:27PM +0100, Gerd Hoffmann wrote: Bill Nottingham wrote: Here's some proposed config changes. Jumping on the wagon ;) Can we enable CONFIG_DMAR please? This turns on the IOMMU on intel boxes, using VT-d. Called DMA Remapping in intel speak, this is where the config option name comes from. Advantages: (1) 32bit PCI devices can DMA to memory above 4G, thus the need for swiotlb (i.e. bounce buffers) is gone. (2) It allows kvm to pass through PCI devices to guests securely. The last time we tried this, it blew up a lot due to broken BIOSes. Maybe it's been improved enough to tolerate them, so we can probably give it a spin in rawhide for a while to see what happens. Upstream was still broken as recently as Friday for bad BIOSes (x200s in this case). Wonder if opt-in via cmdline would be helpful? This is now believed to be fixed, and I've re-enabled DMAR in rawhide. I see Chuck has applied the fix to F-10 already, and we'll look at the question of re-enabling DMAR there later. For now you still need to boot F-10 with 'intel_iommu=on'. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Mon, 2008-06-09 at 11:04 +0100, David Woodhouse wrote: Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this. The patches have now hit Linus' tree, so I've committed the specfile parts too. As soon as we update to 2.6.26-git1, we'll get a separate kernel-firmware package which is required by the main kernel binary package. I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Done. There are some firmwares which are under GPL, so even the Free Software or nothing! folks can have _some_ form of kernel-firmware package. I don't think there's a problem with requiring it. I'll leave it to Alex to submit for review a kernel-firmware-libre package which Provides: kernel-firmware and which actually builds the various firmware files from source :) Should the package own the /lib/firmware/ directory? Not done. Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. Done. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Firmware
Been playing with how I'd make the kernel package deal with the new
'make firmware_install' stuff. Currently looks something like this.
I suspect that (for now) we should make the kernel binary packages
depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get
that until we start to build it from a separate srpm.
Other comments?
(the patch is from git.infradead.org/users/dwmw2/firmware-2.6.git)
Index: config-generic
===
RCS file: /cvs/pkgs/rpms/kernel/devel/config-generic,v
retrieving revision 1.109
diff -u -p -r1.109 config-generic
--- config-generic 4 Jun 2008 00:22:50 - 1.109
+++ config-generic 9 Jun 2008 09:59:12 -
@@ -2479,9 +2479,9 @@ CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
-CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y
+# CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL is not set
CONFIG_SND_MAESTRO3=m
-CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL=y
+# CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL is not set
CONFIG_SND_MIRO=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
@@ -2502,7 +2502,7 @@ CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
-CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL=y
+# CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL is not set
#
# ALSA USB devices
@@ -3536,3 +3536,14 @@ CONFIG_SOC_CAMERA_MT9M001=m
CONFIG_SOC_CAMERA_MT9V022=m
# MT9V022_PCA9536_SWITCH is not set
+CONFIG_BUILTIN_FIRMWARE=
+# CONFIG_USB_KAWETH_FIRMWARE is not set
+# CONFIG_DVB_TTUSB_BUDGET_FIRMWARE is not set
+# CONFIG_USB_SERIAL_WHITEHEAT_FIRMWARE is not set
+# CONFIG_USB_SERIAL_KEYSPAN_PDA_FIRMWARE is not set
+# CONFIG_USB_SERIAL_TI_3410_FIRMWARE is not set
+# CONFIG_USB_SERIAL_TI_5052_FIRMWARE is not set
+# CONFIG_USB_SERIAL_XIRCOM_FIRMWARE is not set
+# CONFIG_USB_EMI62_FIRMWARE is not set
+# CONFIG_USB_EMI26_FIRMWARE is not set
+
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.679
diff -u -p -r1.679 kernel.spec
--- kernel.spec 7 Jun 2008 01:48:53 - 1.679
+++ kernel.spec 9 Jun 2008 09:59:13 -
@@ -76,6 +76,8 @@ Summary: The Linux kernel (the core of t
%define with_doc %{?_without_doc: 0} %{?!_without_doc: 1}
# kernel-headers
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
+# kernel-firmware
+%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{!?_without_debuginfo: 1}
# kernel-bootwrapper (for creating zImages from kernel + initrd)
@@ -565,6 +567,7 @@ Patch07: linux-2.6-compile-fixes.patch
#Patch08: linux-2.6-compile-fix-gcc-43.patch
%if !%{nopatches}
+Patch5: linux-2.6-firmware.patch
Patch10: linux-2.6-hotfixes.patch
@@ -693,6 +696,14 @@ header files define structures and const
building most standard programs and are also needed for rebuilding the
glibc package.
+%package firmware
+Summary: Firmware files used by the Linux kernel
+Group: Development/System
+License: Redistributable
+%description firmware
+Kernel-firmware includes firmware files required for some devices to
+operate.
+
%package bootwrapper
Summary: Boot wrapper files for generating combined kernel + initrd images
Group: Development/System
@@ -992,6 +1003,7 @@ fi
%if !%{nopatches}
+ApplyPatch linux-2.6-firmware.patch
ApplyPatch linux-2.6-hotfixes.patch
# Roland's utrace ptrace replacement.
@@ -1581,6 +1593,10 @@ rm -f $RPM_BUILD_ROOT/usr/include/asm*/i
rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h
%endif
+%if %{with_firmware}
+make INSTALL_FW_PATH=$RPM_BUILD_ROOT/lib/firmware firmware_install
+%endif
+
%if %{with_bootwrapper}
make DESTDIR=$RPM_BUILD_ROOT bootwrapper_install
WRAPPER_OBJDIR=%{_libdir}/kernel-wrapper
WRAPPER_DTSDIR=%{_libdir}/kernel-wrapper/dts
%endif
@@ -1690,6 +1706,12 @@ fi
/usr/include/*
%endif
+%if %{with_firmware}
+%files firmware
+%defattr(-,root,root)
+/lib/firmware/*
+%endif
+
%if %{with_bootwrapper}
%files bootwrapper
%defattr(-,root,root)
--
dwmw2
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote: Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other. I'm content with requiring udev -- since it's udev which is going to load anything that lives in /lib/firmware anyway, that actually makes some sense. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Mon, 2008-06-09 at 10:46 -0400, Jon Masters wrote: Another issue that we never really solved was that we really need to have one firmware package per firmware (group) so that others can possibly override their firmware without replacing the entire kernel-firmware package and affecting everyone. Opinion? Later. We can't do it now, and it's not a loss. What we're doing makes it _easier_ to do that later, if we want to. But I don't want to try it now. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote: K. I guess I'm just raising it so we're aware of it. It's not exactly a loss, but my fear is that once we make it possible for someone else to replace all the kernel firmware just to update their buggy one, then they'll rush out and do this as soon as possible :) Better option might be another directory which appears first on udev's (and mkinitrd's) search patch. That way you can override firmware without having to split the package. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: enable null pointer hardening by default
On Thu, 2007-12-13 at 10:58 -0500, Eric Paris wrote: -unsigned long mmap_min_addr; /* 0 means no protection */ +unsigned long mmap_min_addr = 65536; /* protect first 64k */ 64kB would be 64000. If you mean 65536, it's 64KiB. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
CONFIG_RTC_HCTOSYS
On Tue, 2007-09-25 at 19:07 -0400, Dave Jones wrote: Author: davej Update of /cvs/pkgs/rpms/kernel/devel In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv27402 Modified Files: config-generic kernel.spec Log Message: * Tue Sep 25 2007 Dave Jones [EMAIL PROTECTED] - Disable RTC_HCTOSYS. The initscripts already do this for us. True, they do (once we fix #409551 and preferably also stop mkinitrd from creating the device node with the old numbers). The installer doesn't though, as far as I know. It would need to do so. Once we've started setting the clock in userspace, it then makes a certain amount of sense to have the RTC drivers as modules instead of building them in. We'd need to make sure the right driver gets autoloaded, but that isn't particularly hard. While we're at it, I'd also quite like to have a sanity check after setting the clock in rc.sysinit -- if it's before 2000 or so, I'd like to set it from the latest timestamp found in /var/log. That's _also_ going to be wrong, but it's not going to be _so_ wrong that it prevents you from even being able to log in as root to a VT :) -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[RFC] Kernel subpackage for zImage wrapper.
In arch/powerpc/boot/ in the kernel, there is wrapper code which lets
you make a combined zImage from fairly much arbitrary kernels and
ramdisks. We use it outside the context of the kernel build, for
building installer images, etc.
For a while we've had a copy -- in fact, two copies of different
vintages -- of this in the ppc64-utils package. This was about as
sensible as glibc-kernheaders was, and while upstream dicked around with
load addresses and other things to try to make sure it's compatible with
as many machines as possible, we lagged behind.
Just as we do now for headers, I'd like to spit out a
'kernel-bootwrapper' subpackage when we build the kernel. It depends on
a patch introducing 'make bootloader_install' which has been sent
upstream and will hopefully be accepted; the resulting bootwrapper
package has been confirmed to work for Efika (ppc32), Electra (the new
PA Semi ppc64 machine) and PS3.
Dave, Chuck -- does this look OK?
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.273
diff -u -p -r1.273 kernel.spec
--- kernel.spec 3 Dec 2007 03:01:18 - 1.273
+++ kernel.spec 3 Dec 2007 04:35:36 -
@@ -80,6 +80,8 @@ Summary: The Linux kernel (the core of t
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{!?_without_debuginfo: 1}
+# kernel-bootwrapper (for creating zImages from kernel + initrd)
+%define with_bootwrapper %{?_without_bootwrapper: 0} %{!?_without_bootwrapper:
1}
# Additional options for user-friendly one-off kernel building:
#
@@ -261,6 +263,11 @@ Summary: The Linux kernel (the core of t
%define all_arch_configs kernel-%{version}-*.config
%endif
+# bootwrapper is only on ppc
+%ifnarch ppc
+%define with_bootwrapper 0
+%endif
+
# sparse blows up on ppc64
%ifarch ppc64 ppc alpha sparc64
%define usesparse 0
@@ -678,6 +686,12 @@ header files define structures and const
building most standard programs and are also needed for rebuilding the
glibc package.
+%package bootwrapper
+Summary: Boot wrapper files for generating combined kernel + initrd images
+Group: Development/System
+%description bootwrapper
+Kernel-bootwrapper contains the wrapper code which makes bootable zImage
+files combining both kernel and initial ramdisk.
%package debuginfo-common
Summary: Kernel source files used by %{name}-debuginfo packages
@@ -1551,6 +1566,10 @@ rm -f $RPM_BUILD_ROOT/usr/include/asm*/i
rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h
%endif
+%if %{with_bootwrapper}
+make DESTDIR=$RPM_BUILD_ROOT bootwrapper_install
+%endif
+
###
### clean
###
@@ -1646,6 +1665,13 @@ fi
/usr/include/*
%endif
+%if %{with_bootwrapper}
+%files bootwrapper
+%defattr(-,root,root)
+/usr/sbin/*
+%{_libdir}/kernel-wrapper
+%endif
+
# only some architecture builds need kernel-doc
%if %{with_doc}
%files doc
--
dwmw2
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC] Kernel subpackage for zImage wrapper.
On Mon, 2007-12-03 at 14:39 -0800, Roland McGrath wrote: +# bootwrapper is only on ppc +%ifnarch ppc Not ppc64 too? It's building a userspace package. There is little benefit to doing it for ppc64, although I suppose I might as well. The wrapper code itself is 32-bit, either way. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide report: 20071201 changes
On Sat, 2007-12-01 at 08:15 -0500, Build System wrote: kernel-2.6.24-0.61.rc3.git5.fc9 --- * Fri Nov 30 2007 Kyle McMartin [EMAIL PROTECTED] - Oops! Local make-build-go-faster kernel.spec patch slipped in, reverted. cat GNUmakefile EOF ppc ppc64 i686: DIST_DEFINES += --without debug --without doc --without headers --without debuginfo include Makefile EOF -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: IRC.
On Fri, 2007-09-21 at 11:35 -0400, Dave Jones wrote: On Fri, Sep 21, 2007 at 04:23:57PM +0100, Christopher Brown wrote: On 21/09/2007, Dave Jones [EMAIL PROTECTED] wrote: I've created a #fedora-kernel channel on freenode in response to the large number of /msg's I continue to get which really should be going to a wider audience. Yay, more channels on $%@! Freenode. Which one shall I quit in order to join the new one, I wonder... :) Also, is it worth setting mailman to change the reply-to address so it goes to the list rather than the poster a-la -devel and -test? http://www.unicom.com/pw/reply-to-harmful.html I try to stay out of that argument as much as possible, as it seems have vocal proponents/opponents on both sides, and tbh, I don't think there's a way that'll please everyone. Indeed. And the failure more one way round is much worse than the failure mode the other way round. Maybe we should start shipping a decent mail client with a proper 'reply to all' button? :) -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
On Thu, 2007-07-26 at 09:57 +0200, Hans de Goede wrote: Another issue I would like FESco to look at is the current somewhat grey state of kmod's I'm considering packaging kmod's for uvc (usb video class driver), lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in rawhide). But before I invest time in these I would first like to have the state of kmod's cleared up. I will try to work with there resp. upstreams to get them in the upstream kernel, and atleast for uvc and islsm upstream merger is planned already. I would still like to see kmod packages entirely deprecated in Fedora. If you want to maintain that kernel code and ship it with the 'Fedora' brand on it, why don't we just give you commit access to the kernel package? We can trust you to limit yourself to just those areas, and we can trivially disable your patch(es) if it gets in the way of progress. We've done precisely that kind of thing before (including for bcm43xx before that got merged). There's just no need for separate packages. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Removing atomic.h from Fedora kernel headers
On Mon, 2007-06-25 at 10:17 -0400, Chuck Ebbert wrote: On 06/24/2007 03:25 PM, David Woodhouse wrote: On Fri, 2007-06-22 at 16:36 -0400, Chuck Ebbert wrote: Why do we explicitly remove atomic.h from our kernel header package? No reason any more. Once upon a time, before the cleanup of the upstream kernel's exports was complete, we needed to remove this unwanted crap. These days, the kernel's standard 'make headers_install' doesn't include it anyway, so we no longer need to strip it out for ourselves. I dug through the makefiles to try and figure out if that was true, but gave up. Where is the list of included and/or excluded files? include/**/Kbuild (but note that include/asm-*/Kbuild all include include/asm-generic/Kbuild.asm). Or just run 'make headers_install' and then look in usr/include/ :) -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kmods poll
On Wed, 2007-06-20 at 10:12 -0500, Josh Boyer wrote: If it's good enough for Fedora to ship and support, we can put it in the main kernel package. Besides; if it's good enough for Fedora to ship and Which is something I suggested later in this thread. And if it isn't good enough for upstream to ship and support, why in $DEITY's name would we want to ship it, again? *cough* squashfs *cough cough* wireless-dev *cough* CFS *cough hack* xen *cough* And a bunch of drivers too. I remember the USB DSL drivers around FC4 timeframe, because the complexity of setting that crap up in FC3 offended me so much. PlayStation 3 support in F7. There's _plenty_ of stuff we've shipped in our main kernel package because it's _almost_ upstream and it's (almost) good enough. There's no need to package them separately¹ -- either we're willing to ship and support them, or we aren't. Ok, out of those really only squashfs and xen aren't immediately headed towards some kind of upstream inclusion. Is squashfs not headed upstream? Obviously Xen was and is a massive fscking abortion, but I don't think anyone's holding that up as a shining example of how we should do stuff -- quite the opposite, in fact. -- dwmw2 ¹ Except for the illegal crap like nVidia and ATI drivers, but those aren't relevant to this particular discussion anyway. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [Fedora-livecd-list] No adsl setup in the F7 live cds?
On Mon, 2007-05-07 at 11:54 -0400, Jeremy Katz wrote: system-config-network seems to be on both live images and is the normal way for setting up xDSL under Fedora afaik It only handles PPPoE though -- not PPPoA (or PPPoEoA). -- dwmw2 -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: Pre-release kernel versioning
On Mon, 2007-04-30 at 20:58 +0200, dragoran dragoran wrote: see http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=1618sid=b96d93357fa5c8f16164a5f64231bd47 they get bugreports which are not bugs but problems caused by fedora's kernel versioning system That's just the rt2x00 maintainer being a muppet. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Pre-release kernel versioning
On Mon, 2007-04-30 at 20:04 +0200, Thorsten Leemhuis wrote: See include/compat.h ; relevant part: #include linux/version.h #if LINUX_VERSION_CODE KERNEL_VERSION(2,6,21) #define ATH_REGISTER_SYSCTL_TABLE(t) register_sysctl_table(t, 1) #else #define ATH_REGISTER_SYSCTL_TABLE(t) register_sysctl_table(t) #endif Compiling it against a recent 2.6.21 kernel from rawhide works just fine: I've spent a _long_ time maintaining modules outside the kernel tree; I know about compatibility hacks like this. Trust me; you have a hybrid thing which is neither 2.6.20 nor 2.6.21. Calling it 2.6.21 instead of calling it 2.6.20 doesn't actually fix any problems; it only moves them around. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[Fedora-livecd-list] PowerPC support.
At http://git.infradead.org/?p=users/dwmw2/livecd-ppc.git
(git://git.infradead.org/~dwmw2/livecd-ppc.git) there's a set of patches
which first introduces a little abstraction for the arch-specific
configureBootloader() and createIso() functions, then implements the PPC
version.
1. Allow mayflower path to be specified, to run from git tree
2, Remove syslinux from package lists; add it dynamically instead.
3. Move x86-specific functions (createIso, configureBootloader) into subclass
4. Only create isolinux/ directory in x86-specific configureBootloader()
5. Add PowerPC support, add pata_mpc52xx module to mayflower.conf
The full patch is as follows...
diff --git a/config/livecd-fedora-desktop.ks b/config/livecd-fedora-desktop.ks
index 1ee6fba..780e201 100644
--- a/config/livecd-fedora-desktop.ks
+++ b/config/livecd-fedora-desktop.ks
@@ -23,7 +23,6 @@ services --enabled=NetworkManager,dhcdbd
--disabled=network,sshd
@dial-up
@hardware-support
@printing
-syslinux
kernel
scim*
diff --git a/config/livecd-fedora-kde.ks b/config/livecd-fedora-kde.ks
index 20413b1..9aeceed 100644
--- a/config/livecd-fedora-kde.ks
+++ b/config/livecd-fedora-kde.ks
@@ -23,7 +23,6 @@ kernel
dejavu-lgc-fonts
setroubleshoot
smolt
-syslinux
system-config-display
xorg-x11-drivers
diff --git a/config/livecd-fedora-minimal.ks b/config/livecd-fedora-minimal.ks
index e8065b6..db52912 100644
--- a/config/livecd-fedora-minimal.ks
+++ b/config/livecd-fedora-minimal.ks
@@ -17,7 +17,6 @@ repo --name=a-extras-dev
--baseurl=http://download.fedora.redhat.com/pub/fedora/
%packages
bash
kernel
-syslinux
passwd
policycoreutils
chkconfig
diff --git a/config/livedvd-fedora-kde.ks b/config/livedvd-fedora-kde.ks
index 1ed2f57..71aa122 100644
--- a/config/livedvd-fedora-kde.ks
+++ b/config/livedvd-fedora-kde.ks
@@ -23,7 +23,6 @@ kernel
dejavu-lgc-fonts
setroubleshoot
smolt
-syslinux
system-config-display
xorg-x11-drivers
diff --git a/creator/livecd-creator b/creator/livecd-creator
index a526b07..755e659 100755
--- a/creator/livecd-creator
+++ b/creator/livecd-creator
@@ -27,6 +27,8 @@ import traceback
import subprocess
import shutil
import yum
+import rpmUtils.arch
+import rhpl
import pykickstart.parser
import pykickstart.version
@@ -277,6 +279,178 @@ class LiveCDYum(yum.YumBase):
cb.filelog = False
return self.runTransaction(cb)
+class InstallationArchPPC:
+def __init__(self):
+# For now we need anaconda-runtime, for bits like ofboot.b and mapping
files.
+# We could generate those ourselves though...
+self.bootldr_package = (yaboot,anaconda-runtime)
+
+def createIso(self, target):
+write out the live CD ISO
+subprocess.call([/usr/bin/mkisofs, -o, %s.iso
%(target.fs_label,),
+ -hfs, -hfs-bless, %s/out/ppc/mac
%(target.build_dir),
+ -hfs-volid, %s %(target.fs_label,), -part,
+ -map, /usr/lib/anaconda-runtime/boot/mapping,
+ -J, -r, -hide-rr-moved, -no-desktop,
+ -V, %s %(target.fs_label,), %s/out
%(target.build_dir)])
+
+def configureBootloader(self, target):
+configure the boot loader
+
+# Copy yaboot and ofboot.b in to mac directory
+os.makedirs(target.build_dir + /out/ppc/mac)
+
shutil.copyfile(%s/install_root/usr/lib/anaconda-runtime/boot/ofboot.b
%(target.build_dir),
+%s/out/ppc/mac/ofboot.b %(target.build_dir,))
+shutil.copyfile(%s/install_root/usr/lib/yaboot/yaboot
%(target.build_dir),
+%s/out/ppc/mac/yaboot %(target.build_dir,))
+
+# Copy yaboot and ofboot.b in to mac directory
+os.makedirs(target.build_dir + /out/ppc/chrp)
+
shutil.copyfile(%s/install_root/usr/lib/anaconda-runtime/boot/bootinfo.txt
%(target.build_dir),
+%s/out/ppc/bootinfo.txt %(target.build_dir,))
+shutil.copyfile(%s/install_root/usr/lib/yaboot/yaboot
%(target.build_dir),
+%s/out/ppc/chrp/yaboot %(target.build_dir,))
+subprocess.call([/usr/sbin/addnote, %s/out/ppc/chrp/yaboot
%(target.build_dir,)])
+
+os.makedirs(target.build_dir + /out/ppc/ppc32)
+shutil.copyfile(%s/install_root/boot/vmlinuz-%s
+%(target.build_dir, target.get_kernel_version()),
+%s/out/ppc/ppc32/vmlinuz %(target.build_dir,))
+shutil.copyfile(%s/install_root/boot/livecd-initramfs.img
+%(target.build_dir,),
+%s/out/ppc/ppc32/initrd.img %(target.build_dir,))
+os.unlink(%s/install_root/boot/livecd-initramfs.img
+ %(target.build_dir,))
+
+os.makedirs(target.build_dir + /out/ppc/ppc64)
+# FIXME: Need 64-bit kernel and initrd
+
+cfg32 =
+init-message = Welcome to the Fedora %(label)s LiveCD
+timeout=6000
+
+ %{label: target.fs_label}
Do not BuildRequires: glibc-kernheaders
The glibc-kernheaders packages provides 'kernel-headers'. If you need to require a specific _version_, you should use that. But if you just need to require that it exists, you don't need to do anything -- the standard gcc development packages depend on it. If there's a file missing from /usr/include/linux or /usr/include/asm when you try to build, that's either a bug in the glibc-kernheaders package, or a bug in the package you're trying to build. If it's a kernel header you _should_ be using from userspace, assume the former and file a bug against glibc-kernheaders. If the latter, fix it not to include kernel headers. Do _NOT_ add 'BuildRequires: glibc-kernheaders' to any packages. That will break. Soon. -- dwmw2 -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
Re: The repository scoring problem - a proposal
On Sun, 2006-03-12 at 18:34 +0100, Nicolas Mailhot wrote: Why do you need a separate header/field/whatever ? You *already* have this field - that's the GPG signature. Assign weights to signing keys and you're done Not always sufficient. Most of the time I want yum to prioritise, it's when it downloads a package from a remote repository which is actually also available from a local one (with a file:// URL). I'd want to priorities my local caches over the remote repositories, which can't be done with the signature (although yum arguably ought to do that one for itself anyway). -- dwmw2
Re: rawhide report: 20060307 changes
On Wed, 2006-03-08 at 09:32 +0100, Igor Jagec wrote: Speaking about NM, are there any plans for supporting static IP addresses? Doesn't NM work with static IP addresses? It obeys static IP addresses in /etc/sysconfig/network-scripts/ifcfg-eth1 for me -- it confused me by doing so a couple of weeks ago. -- dwmw2
Re: Recommended laptop for FC5, was: glxgears
Roberto Ragusa m...@robertoragusa.it wrote: Seth Vidal wrote: And how do you define library? There's no reliable way to distinguish them from applications. This is part of the problem. It would be nice to have all things which are strictly libraries add a provides: Library something and, of course, to have all libs split from all apps. Why should libraries be special? They are not. Libraries dragged as dependencies are candidate for removal when nothing currently installed is depending on them. Libraries installed explicitly by the user must not be removed (maybe I need them for a not-packaged or manually compiled app). s/Libraries/Apps - same rules have to apply Apps dragged as dependencies could be volatile, apps the user decided to install must stay. Please do not limit the issue to lib/not-lib. Things are more complex (well, maybe they are actually simpler...) For example: a) wireshark-gnome (depends on wireshark) b) wireshark (depends on libpcap) c) libpcap (depends on libutilswhichsomedevelopersliketouse) d) libutilswhichsomedevelopersliketouse It makes a lot of difference if a user - has installed a) and dragged b) c) d) for dependencies (removing a) could try to remove everything) or - has installed c) and d) for own use/development, then some day installs a) which drags b) (removing a) should only try to remove b) ) - has installed c) and d) for own use/development, then some day installs b), then some day installs a) (removing a) should not try to remove anything else ) There is only one use case a little tricky: if I have a), which dragged b) c) and d), and now I want to mark b) as wanted, what should I do? maybe: # yum install b) To be installed: none To be updated: none To be marked as user-installed: b) Proceed? (y/n) y Operation complete. This means the overloaded user has to remember to mark as used the stuff she is using so it doesn't get pulled out from under her feet by deleting unrelated packages. What should now happen if, say, (c) gets updated, but nothing else in the stack? What if ethereal gets renamed to wireshark? What if (c) gets replaced upstream by a functionally equivalent, but different code base, package? What if the whole stack gets replaced by functionally equivalent, but API-wise completely different (and even divided into completely different layers), stuff? It seems to me that most of this nonsense is easy to get right with no further effort than just creating your own RPMs and installing those, instead of futzing around installing _systemwide_ from source. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
