Re: kernel-xen f9 spec update
Hi Jarod, (Copying fedora-kernel-list so other folks know what we're at) On Sat, 2008-03-29 at 15:19 -0400, Jarod Wilson wrote: We recently tweaked the main kernel package's spec file such that we now include arch in uname -r output, and have standardized a bunch of path names to match. Completely forgot about kernel-xen in the process, until yesterday, when I started porting everything over the the kernel-xen-2.6/devel spec. The attached spec patch has been build-tested, with some manual inspection of the resulting packages, but hasn't yet been run-time tested for possible issues (none expected, but you never know...). I'll happily help out with any possible issues if you guys could give this a spin. Definitely want this in ASAP so the kernel and kernel-xen bits stay mostly in sync (speaking of which, there's also some rpmposttrans stuff -- dkms hooks -- which went into the main kernel spec a bit ago that I don't see in the kernel-xen-2.6 spec Thanks for the heads-up and the patch. I'm planning on rebasing kernel-xen-2.6/devel to the latest kernel/devel sometime this week, so we'll pick up all this stuff. We eventually plan to get rid of the separate kernel-xen RPM altogether, but that will probably have to wait until we get most of the x86_64 and dom0 work upstream. In the meantime, we do intend to keep closely in sync with the latest stock kernel, and we're currently doing that using two git trees: a) http://git.et.redhat.com/?p=linux-2.6-fedora-pvops.git b) http://git.et.redhat.com/?p=kernel-xen-rpm.git If you look at e.g. the kernel-xen-2_6-2_6_25-0_6_rc4_fc9 tag for each of those you'll see a (a) a bunch of commits on top of the fedora kernel source tree and (b) a bunch of commits on top of kernel/devel from CVS. Each time we sync up with a new kernel version, we import a make prep tree into (a) and the corresponding kernel/devel tag from CVS into (b) and then use git to rebase the commits from the last kernel-xen tag for both of these. The easier we can make this rebasing process, the more frequent we'll rebase. Right now, I've got a few lame scripts to: 1) Import the result of make prep into (a) 2) Import a kernel/devel CVS tag into (b) 3) Export the xen patches from (a) and include them into the spec file in (b) 4) Copy everything from (b) to kernel-xen-2.6/devel but it's all still quite manual and error prone. Cheers, Mark. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
On Monday 31 March 2008 03:00:00 am Ananth N Mavinakayanahalli wrote: Hi, Updating my rawhide box, I found: kernel-debuginfo i686 2.6.25-0.172.rc7.git4.fc9 rawhide-debuginfo 47 k kernel-debuginfo-common i686 2.6.25-0.172.rc7.git4.fc9 rawhide-debuginfo 486 M - Did anything in the F9 builds change that lead to this more than two-fold increase in the debuginfo size? - Or is it that the common rpm needs updation once every kernel release with just updates for every update to the same release thereafter? There's a problem with some of the changes I made to add arch to our uname -r output screwing with debuginfo a bit. The size isn't double though. Before -- kernel-debuginfo: ~198M kernel-debuginfo-common: ~32M Now --- kernel-debuginfo: 47k kernel-debuginfo-common: 230M So same size overall, I just haven't got all the bits getting into the right sub-packages. Working on fixing that now. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Add SELinux permissive domains to fedora kernels
I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=32021b669089eb9b264e6b26af4d9a47eb50d4f1 http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=70d212ebfdd5e39a9d4fb0f8f7ea5c38486f6b04 http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=559dbbc87d0a5d2eb88bbbea5f2b66ee2dfd55d6 Only the third patch is truly interesting. A permissive domain is a new concept in which a sysadmin can say that a given domain is free to do anything it wants. Lets say a user seriously customized httpd and they want httpd to just be allowed to run wild while still keeping enforcing for everything else in the system. With the kernel patch I want to commit and the userspace changes dan has already pushed this week they just need a simple policy which says permissive httpd_t and all their httpd_t denials become allows! One of the upstream patches adds a BUG_ON() but I'm still a teensy bit scared of it so in the F9 patch I'll probably make it a WARN_ON since it isn't really deadly to the kernel... anyway. Chances of regression here are very very low. I would just jam this in myself but we are getting really late and I wanted people to be able to tell me no before I did it. If noone strongly objects quickly expect to see a commit message early this week -Eric ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Add SELinux permissive domains to fedora kernels
On Mon, Mar 31, 2008 at 02:07:44PM -0400, Eric Paris wrote: I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=32021b669089eb9b264e6b26af4d9a47eb50d4f1 http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=70d212ebfdd5e39a9d4fb0f8f7ea5c38486f6b04 http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=559dbbc87d0a5d2eb88bbbea5f2b66ee2dfd55d6 Only the third patch is truly interesting. A permissive domain is a new concept in which a sysadmin can say that a given domain is free to do anything it wants. Lets say a user seriously customized httpd and they want httpd to just be allowed to run wild while still keeping enforcing for everything else in the system. With the kernel patch I want to commit and the userspace changes dan has already pushed this week they just need a simple policy which says permissive httpd_t and all their httpd_t denials become allows! One of the upstream patches adds a BUG_ON() but I'm still a teensy bit scared of it so in the F9 patch I'll probably make it a WARN_ON since it isn't really deadly to the kernel... anyway. Chances of regression here are very very low. I would just jam this in myself but we are getting really late and I wanted people to be able to tell me no before I did it. If noone strongly objects quickly expect to see a commit message early this week It is indeed, very late. I'm concerned by just how much busted stuff we have[*], so shovelling in more features after the feature freeze is making me wince. From a quick look at the patches, this is a fairly small amount of code that's changing, that looks harmless. What userspace changes are necessary for this? Are they in place already? We'll pick this up anyway in 2-3 months as an F9 update when we rebase to 2.6.26, so I guess the userspace bits will have to be done at some point, but I'd rather we spent effort beating what we have already into shape than forward planning right now. (That said, selinux is pretty solid from a kernel pov. Still some warts in policy, but Dan is nailing those pretty quickly as usual). I dunno. Dave [*] The top kerneloops.org regressions right now are all in code that's been added to Fedora that isn't upstream (yet). This is not a good sign. -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Add SELinux permissive domains to fedora kernels
On Mon, 2008-03-31 at 14:07 -0400, Eric Paris wrote: I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=32021b669089eb9b264e6b26af4d9a47eb50d4f1 http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=70d212ebfdd5e39a9d4fb0f8f7ea5c38486f6b04 The second patch is effectively a bug fix, as otherwise open(2) with flags 3 will fail ever since the dentry_open hook was added. So that one makes sense regardless of the permissive domains patches. http://git.kernel.org/?p=linux/kernel/git/jmorris/selinux-2.6.git;a=commitdiff;h=559dbbc87d0a5d2eb88bbbea5f2b66ee2dfd55d6 Only the third patch is truly interesting. A permissive domain is a new concept in which a sysadmin can say that a given domain is free to do anything it wants. Lets say a user seriously customized httpd and they want httpd to just be allowed to run wild while still keeping enforcing for everything else in the system. With the kernel patch I want to commit and the userspace changes dan has already pushed this week they just need a simple policy which says permissive httpd_t and all their httpd_t denials become allows! One of the upstream patches adds a BUG_ON() but I'm still a teensy bit scared of it so in the F9 patch I'll probably make it a WARN_ON since it isn't really deadly to the kernel... anyway. Chances of regression here are very very low. I would just jam this in myself but we are getting really late and I wanted people to be able to tell me no before I did it. If noone strongly objects quickly expect to see a commit message early this week -- Stephen Smalley National Security Agency ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: WebCam drivers ...
Greetings ... I have three USB WebCam's myself - 05a9:a511 OmniVision Technologies, Inc. OV511+ WebCam (Creative ) This one has been working for many years now with the ov511 module. It does basically does, but the colours are a little off, but I should try the latest source ... - 05a9:8519 OmniVision Technologies, Inc. OV519 WebCam (D-Link) This one probably works with the out of tree variant of the same driver. (For some reason, the author stopped updating the kernel.org variant) It is strange, but maybe we can pick it up and run with the ball ... http://ovcam.org/ov511/ It currently does not, but again, I will take a look at the source ... (Note it may need some work to run on the latest versions of the kernel) Mmm ... Will see how far I get ... - 046d:08c2 Logitech, Inc. should be supported by the uvcvideo module. Again, I'm out of luck. It picks up the webcam, loads the module, but it does not work ... Even tried the SVN update ... Seems I'm just a little out of luck ... Thanks for the reply ... Mailed LeeT ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Add SELinux permissive domains to fedora kernels
On Mon, 2008-03-31 at 14:07 -0400, Eric Paris wrote: I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream As a cranky release engineering person, no no no no no no We have a feature freeze for a reason, the kernel doesn't get a blank check to get past it. If it was that important, it would have been done in time for the freeze. The next release is in six months, so it's not like it's that long to have to wait Jeremy ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
On Monday 31 March 2008 03:45:25 pm Roland McGrath wrote:
I had a fix for this test-building when I went to watch some schlock TV
last night and forgot to check on it and commit before I went to bed.
This was my .spec diff. The regexp has three chars different from your
version.
+%{expand:%%global debuginfo_args %{?debuginfo_args} -p
'/.*/%%{KVERREL}%{?1:.?%{1}}?/.*|/.*%%{KVERREL}%{?1:.%{1}}(\.debug)?' -o
debuginfo%{?1}.list}\ ^
what's that ? for?
I wondered that myself, but it was already there... Might have been a typo I
inserted earlier. Yanking it works for me.
The other differences are \. instead of . for matching
literal . in two places.
Ah, that's even better. Forgot this is essentially regex passed down to
find-debuginfo.sh... I'll drop the ? and add the \'s.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Self Introduction: Hans de Goede
On 03/28/2008 05:44 PM, Hans de Goede wrote: Hi All, I'm a Linux enthusiast / developer. Lately I'm mainly active doing development for Fedora and writing kernel drivers (and as my day job I'm a lecturer in Computer Science). Fedora has a policy of not shipping a heavily patched kernel, but instead tries to work with upstream to get any needed patches integrated. This policy extends to not shipping any addon drivers, but rather working to get drivers integrated upstream. As such I've decided to start spending my spare time on getting more and better usb webcam support integrated upstream (for non usb video class devices). I wanted to have something to show, so I've gone to the store, bought a couple of webcams and started hacking and learning. There is a partially completed driver for an Acer webcam here: https://sourceforge.net/projects/m560x-driver/ And I have the hardware... ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Add SELinux permissive domains to fedora kernels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Katz wrote: On Mon, 2008-03-31 at 14:07 -0400, Eric Paris wrote: I know its way late but I'd like to add a new SELinux concept to the F9 kernels. Its going to be a backport of a couple of my changesets headed upstream As a cranky release engineering person, no no no no no no We have a feature freeze for a reason, the kernel doesn't get a blank check to get past it. If it was that important, it would have been done in time for the freeze. The next release is in six months, so it's not like it's that long to have to wait Jeremy I can go either way whether this goes in or not. The userspace updates are done, The only change would be to modify some tools to quickly build a policy module to make a domain permissive. Permissive domains is a great new feature though: If gives users the following: 1. Some Wall Street customers originally brought up the idea. They want to be able to build a policy package to confine an application and after testing destribute it to their systems as a permissive domain. Then run it for a couple of months, once they are convinced that it will not break anything, they can turn it to an enforcing domain. We could start doing similar things for new confined domains in Rawhide. 2. We have a regression reported against Fedora since Fedora 7 that complained when we removed *disable_trans booleans. These were removed because disabling a transition in one domain could effect another domain by not setting the file context correctly. So permissive domains would be a great replacement for disable_trans. 3 Finally when a user builds a new policy for a domain, we tell them to use tools to build a framework for policy and install the new domain and setup labeling. Then we tell them to put the machine in permissive mode to run the app, and gather AVCs. This change would allow you to leave your entire machine in enforcing mode while you run your new domain in permissive mode, gathering the AVCs. 4. Some times people are convinced SELinux is causing a application to break, one way we tell them to test whether SELinux is the culprit is put the machine in permissive mode and see if the app still breaks, permissive domains would give us the ability to only put one domain in permissive mode. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfxvT0ACgkQrlYvE4MpobP7GQCghAtXhGE4ivis+KELOhxqYU4t 6bUAn2T1HrtPWTE3ppu80KgCjf46nePW =sjft -END PGP SIGNATURE- ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
