Re: *countable infinities only
On 05/31/2012 05:13 PM, Chris Adams wrote: Please don't spread FUD like this. You are wrong for a couple of reasons: - Secure boot is required to be able to be disabled on x86 (the only platform Fedora will support it). - Users can generate their own keys, enroll them in the secure boot firmware, and use those keys to sign their kernels. I am not sure I fully understand the technical part about UEFI so please make it clear for me: I can generate my own keys, enroll them in the secure boot firmware and then *continue* using the machine in a *dual boot* with Windows 8? The presence on my own boot keys will make Windows 8 unbootable on that machine or not? -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vfsmount mnt_parent element change
On Thu, May 31, 2012 at 10:26 PM, Shelby, James james.she...@nrel.gov wrote: I'm trying to find out the changes in the kernel relating the 3.2 to 3.3 changes in relation to the vfsmount structure change as we use an application that uses the mnt_parent element that no longer exists in the source. I looked at the Documentation directory for the kernel in Fedora 16 but it has references to mnt_parent still (linux-3.3.7/Documentation/filesystems). I saw a bug reference that has this being moved to the mount structure however I don't get any results with grep on the entire source tree for mnt_parent. Can anyone point me to a document that has the structure change so that I can modify this source accordingly? mnt_parent has moved to struct mount (in fs/mount.h), see commit 0714a533 and 3376f34f. Thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
2012/5/31 Adam Williamson awill...@redhat.com Third bug: after preupgrade finished to download fc17 packages, I rebooted, but grub did not have a “upgrade system” entry. So the computer is not upgradable with preupgrade. Need more information. Could it be? https://bugzilla.redhat.com/show_bug.cgi?id=826537#c27 So now, developers say that they need more people to do beta testing, but my question is: if at least 80% userbase had troubles with grub showing old kernels, is it possible that nobody of testers had this problem? I really don't think so. No, that is not the case. See above. The issues with old kernel sticking around after upgrade were already known and reported before release. The #820351 case is fundamentally more or less impossible to solve entirely, outside of sticking Epochs in the kernel package. So there was no point holding up the release for that. The #820340 case is specific to preupgrade and isn't a showstopper, so we didn't hold the release for that one either. There is an upgrade currently in testing that ought to fix it. Please apologize me, but if #820340 was not a showstopper, so which bug should be a showstopper? I am very disappointed with that, because preupgrade is the official supported way to upgrade Fedora versions -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 07:21 PM, Gerry Reno wrote: Not yet. But HDD technology is changing rapidly. Just look at hybrid drives, SSD. No reason they could not add this capability. Not really. Both of these have been in development for years and have only started to look mainstream fairly recently. Look at the time that passed between IDEMA standardising advanced (4KiB) sectoring and the time that that took to actually make it to the market (not to mention that most of those parts are running in compatibility mode today). ATA has some existing security extensions to allow a drive to be locked but these prevent any access until a correct password is presented (and don't appear to be that secure against a well resourced attacker). If read-only support was standardised tomorrow it'd still be a number of years before widespread support became available. About the best you could do today would be to use an external drive with a write-protect switch or to wire up the physical WP jumper on the drive to an external switch on the case (I wouldn't flick it while the system is running ;). Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/Ih3wACgkQ6YSQoMYUY96v7ACfUV2nSsW4iAQDwTXXWz75cpMb fN0AoKHV48bethNR/GKaUdNtnfeNMWlL =mZVJ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/01/2012 10:37 AM, Caterpillar wrote: Please apologize me, but if #820340 was not a showstopper, so which bug should be a showstopper? The bug * does not cause data loss * is easy to recover from * seems to be fixable with an update = Not what I'd call a showstopper. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 08:03 PM, Gregory Maxwell wrote: I wasn't responding to MJG, I was responding to Peter— who said I was wrong in the message where I was stating that a freedom is being lost, and has subsequently spoken more clearly on the position— and Byrn. It seemed to me that they were arguing that the freedom of fedora wasn't being compromised here. My understanding has been refined by further discussion, though I'm still not completely sure if all people actually take the loss of freedom seriously, or if they do but just can't accept the idea that the alternative is actually an option. If you read my posts carefully you might have noticed that I have not actually taken a position on this feature. I was only responding to the tone and content of your message which I still feel was unnecessarily alarmist and not adding anything to the discussion. I am not working on this feature and I'm quite capable of telling my system's firmware to do what I want so there's little practical implication for me. I see the arguments on both sides and I regret that we appear to be between a rock and a hard place here. At the same time I have a lot of trust in the people who are working on this in Fedora and I have faith that the project will try to seek the best compromise between the freedoms we value and the realities of the market and environment we find ourselves in. Invoking the conspiracy card on these discussions and decisions really just takes us further into the mire. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/IlYIACgkQ6YSQoMYUY95jdgCgtG2ZjWfbZ1eFbV7FJLlvvIrQ 6KcAoLY4Vfca42XC7eby578EOpENakaY =1HB5 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: As we develop SELinux we are adding new labels to homedir content
On Thu, 31.05.12 15:44, Daniel J Walsh (dwa...@redhat.com) wrote: Heya, We have added file trans by name rules to policy to fix a lot of files/directories being created with the correct label. We have problems on Distribution updates (F16-F17) though, where there is a files/directories in the homedir that are mislabeled. We have restorecond -u which we run in F15/F16 which examines the homedir and fixes any files directories it finds mislabeled in ~. If it finds a dir which is mislabeled, it will relabel the directory and all of its children. We have turned this tool off by default on the desktop in F17, because filename transition rules are doing a pretty good job of maintaining the labels in the homedir. But this tool never did a great job of fixing mislabeled subdirs, if the top level directory in the homedir was labeled correctly. You can enable this tool with /etc/xdg/autostart/restorecond.desktop One possible fix to this would be to force a system relabel on everything on upgrades, while this would fix the labels, it is considered to time consuming. (restorecon -R -v / or touch /.autorelabel) Another option would be to just relabel /home (# restorecon -R -v /home) at upgrade time. But this would also be time consuming. And would not catch the cases where the homedir is not in /home. I am strongly for this option. Allowing the user to login while the relabel is still in progress (like it would with restorecond, right?) sounds like a really bad idea... I mean, incorrect labels when used just lead to more incorrect labels, no? And incorrect labels also result in access errors? Both sound like something to avoid... To me it appears that preupgrade should really take care of this on all Fedora release updates. If the relabelling is slow, maybe we can do something about that? Do you know why it is slow? Is this more IO bound? Or is the label lookup slow and this is CPU bound? If the latter it might be possible to parallelize the relabelling? (I wouldn't care too much about homedirs outside of /home. A not in the release notes for such cases should suffice) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 05/31/2012 10:24 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:08 -0400, Neal Becker wrote: But we can, and should, at least try to make our systems tolerant of failures. Just because we can't test everything. Defensive programming. Sure. As someone else said, though, that's an issue in rpm if anywhere... Dunno what kind of failures you're referring to here (not saying rpm doesn't have any, just that it's not clear to me in this context), but the vast majority of upgrade-related issues are not so much in rpm but anaconda/preupgrade/yum level of things. (One of) the recurring themes is 1) user has a system with bunch of non-default packages installed 2) user does an anaconda-upgrade with a DVD 3) anaconda blasts through the upgrade ignoring anything it can't upgrade 4) yum barfs on the resulting broken dependency mess Anaconda (and perhaps preupgrade as well, I dont know it well enough to comment) could be stricter and refuse to upgrade unless all dependencies are met, either through user adding/adjusting (3rd party) repositories as necessary or removing all offending packages, but that'd perhaps just create a different kind of PITA. It'd help if yum learned how to fix (at least some) pre-existing problems instead of just complaining and giving up. One thing that might also help is changing anaconda preupgrade to use yum distro-sync equivalent instead of the regular upgrade. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Thu, May 31, 2012 at 01:55:35PM -0500, Chris Adams wrote: Once upon a time, Peter Jones pjo...@redhat.com said: That's why we didn't simply ask vendors to ship our key. That would be /less/ equitable to other distributions than the solution we're looking at right now. Has any thought been given to setting up group between various Open Source distributions (Linux, BSD) to be a Secure Boot signer (with security-oriented rules about what gets signed, probably similar to whatever Microsoft is using today) and then getting vendors to include the master key along site Microsoft's? The last attempt to do something similar I can think of would be cacert. Afaik, they are still being audited to be added to Firefox, and i think they would be happy to explain all the issues they faced on that road. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 10:42 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:07 -0400, Gerry Reno wrote: Yes, all these would currently support what I'm suggesting. Actually, if you're willing to flip a lot of switches, you could probably make your / a raid5 of floppies, but the performance would be suboptimal. -J Ok, now you're just being silly. Behold: http://www.wired.com/gadgetlab/2009/05/five-disk-floppy-raid-4mb-of-blistering-fast-storage/ Hey, you might be joking but I used to demo MD RAID in Red Hat classes using a dinky little 4-port USB1 hub (with a Shadowman logo) and four Red Hat branded USB keys. Worked great :-) Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/ImxUACgkQ6YSQoMYUY96GcgCg0Hl2mIPTJRx4wPUujN4fPVex fL8An1E/1Gd6DQwgzC36hXm2HFk6mCbX =xv75 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Fri, Jun 01, 2012 at 01:18:23PM +0300, Panu Matilainen wrote: On 05/31/2012 10:24 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:08 -0400, Neal Becker wrote: But we can, and should, at least try to make our systems tolerant of failures. Just because we can't test everything. Defensive programming. Sure. As someone else said, though, that's an issue in rpm if anywhere... Dunno what kind of failures you're referring to here (not saying rpm doesn't have any, just that it's not clear to me in this context), but the vast majority of upgrade-related issues are not so much in rpm but anaconda/preupgrade/yum level of things. (One of) the recurring themes is 1) user has a system with bunch of non-default packages installed 2) user does an anaconda-upgrade with a DVD 3) anaconda blasts through the upgrade ignoring anything it can't upgrade 4) yum barfs on the resulting broken dependency mess Anaconda (and perhaps preupgrade as well, I dont know it well enough to comment) could be stricter and refuse to upgrade unless all dependencies are met, either through user adding/adjusting (3rd party) repositories as necessary or removing all offending packages, but that'd perhaps just create a different kind of PITA. It would be much better to refuse to upgrade than to break later in weird way, since users perception would be different. First, they would either ask for help and then someone could explain what is wrong. This would also reduce the number of failed upgrade and therefor the number of bugs that cannot be reproduced, thus making them likely easier to spot and fix. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/01/2012 01:39 PM, Michael scherer wrote: On Fri, Jun 01, 2012 at 01:18:23PM +0300, Panu Matilainen wrote: On 05/31/2012 10:24 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:08 -0400, Neal Becker wrote: But we can, and should, at least try to make our systems tolerant of failures. Just because we can't test everything. Defensive programming. Sure. As someone else said, though, that's an issue in rpm if anywhere... Dunno what kind of failures you're referring to here (not saying rpm doesn't have any, just that it's not clear to me in this context), but the vast majority of upgrade-related issues are not so much in rpm but anaconda/preupgrade/yum level of things. (One of) the recurring themes is 1) user has a system with bunch of non-default packages installed 2) user does an anaconda-upgrade with a DVD 3) anaconda blasts through the upgrade ignoring anything it can't upgrade 4) yum barfs on the resulting broken dependency mess Anaconda (and perhaps preupgrade as well, I dont know it well enough to comment) could be stricter and refuse to upgrade unless all dependencies are met, either through user adding/adjusting (3rd party) repositories as necessary or removing all offending packages, but that'd perhaps just create a different kind of PITA. It would be much better to refuse to upgrade than to break later in weird way, since users perception would be different. First, they would either ask for help and then someone could explain what is wrong. This would also reduce the number of failed upgrade and therefor the number of bugs that cannot be reproduced, thus making them likely easier to spot and fix. Yup. AFAICS anaconda doesn't even so much as warn about broken dependencies on upgrade, giving users a false sense of things being all peaches when in reality it could be creating an enormous mess. Witness eg https://bugzilla.redhat.com/show_bug.cgi?id=826686 and https://bugzilla.redhat.com/show_bug.cgi?id=826621 - a user might think twice before proceeding with an upgrade creating 150-200 broken dependencies, all of which silently ignored atm. - Panu - - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 1, 2012 at 1:15 AM, Sergio Durigan Junior sergi...@redhat.com wrote: On Thursday, May 31 2012, Ralf Corsepius wrote: So I'll patch sort to default to /var/tmp rather than /tmp. Please don't. As many pointed out, there are many disadvantages in doing this, and I really do not think we should be fixing (sic) our apps because of such a controversial feature. `sort' and other programs have been working right like this for *years*; introducing such change would mean please give me more bugs, as Ralf pointed out. To remind everyone about the state of this change: * It was approved by FESCo for Fedora 18 * It was implemented Therefore, it is reasonable to assume that Fedora 18 will ship with this change, and applications need to be updated to handle the change, or we will have a more broken Fedora 18. Advising people not to patch programs won't make Fedora 18 less broken at this point. So, please, if you are a package maintainer, for each package: 1. (fedpkg prep) 2. (grep -irl 'te\?mp' .) 3. Manually review the results for code that could be broken by making /tmp a tmpfs 4. Prepare patches, and either get them accepted upstream, or add them to your Fedora package. If you are anyone: Please suggest improvements to the instructions above to reduce the number of false positives. If you are the feature owners: Please read through all of the previous discussions mentioning specific things that would be broken, and file the bugs yourselves - don't rely on the single person out of thousands to have read the e-mail. If you don't like the change: Sorry. I don't like the change either, but now we need focus on making Fedora 18 less broken. Alternatively, you could ask FESCo to reconsider - but before doing so, please review the FESCo meeting minutes from April 4 and the following devel@ threads, and make sure you have _new_ arguments. Repeating things that were already raised is unlikely to persuade FESCo. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17: wvdial broken
the bug is 45 days old: https://bugzilla.redhat.com/812651 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 09:14 PM, Kevin Kofler wrote: Chris Adams wrote: - Secure boot is required to be able to be disabled on x86 (the only platform Fedora will support it). And this is exactly why we should just require our users to disable it! I don't see any advantage at all from supporting this feature, just problems: * extra restrictions added to GRUB and the kernel to comply with the security (lockout) requirements. Even if they're all conditional on secure boot being enabled (are they really?), that still means extra code which can cause extra breakage even when running in normal mode (the one every Free Software user should be using). * possible GPL violation. Did Red Hat Legal have a look at the plans already? Are they sure they're compliant with the GPL, v2 when it comes to the kernel, v3 when it comes to GRUB 2? (What's sure is that they aren't compliant with the spirit of the GPL, whatever version!) * ineffectiveness of the added restrictions: Can't you still bring up a Blue Pill with a Window$ VM even with only unsigned userspace apps? And if we don't even allow those, where's the freedom? * exercising your freedom to change the kernel (or even just to load an out- of-tree module!) requires you to disable Secure (Restricted) Boot anyway, so why support the restricted mode? (As much as I hate proprietary drivers, you can definitely expect a horde of their users showing up at your door with a pitchfork...) * implicit endorsement of M$ and their signature racket (including a monetary payment to their racketing partner Veri$ign -- was that already made?). It might even lead M$ to drop the requirement to allow disabling Secure Boot (or even invert it into a prohibition as on ARM!), arguing that Linux (sic, should be GNU/Linux) supports it too anyway. * dependence on the racket, which can change its terms at any moment. Just saying disable 'Secure' Boot in the BIOS is the easiest solution to the problem. I remember the days where one had to disable PlugPlay Operating System in the BIOS to get GNU/Linux to boot at all on some machines, it didn't cause any real problems. Kevin Kofler +100 -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: As we develop SELinux we are adding new labels to homedir content
On 06/01/2012 06:14 AM, Lennart Poettering wrote: On Thu, 31.05.12 15:44, Daniel J Walsh (dwa...@redhat.com) wrote: Heya, We have added file trans by name rules to policy to fix a lot of files/directories being created with the correct label. We have problems on Distribution updates (F16-F17) though, where there is a files/directories in the homedir that are mislabeled. We have restorecond -u which we run in F15/F16 which examines the homedir and fixes any files directories it finds mislabeled in ~. If it finds a dir which is mislabeled, it will relabel the directory and all of its children. We have turned this tool off by default on the desktop in F17, because filename transition rules are doing a pretty good job of maintaining the labels in the homedir. But this tool never did a great job of fixing mislabeled subdirs, if the top level directory in the homedir was labeled correctly. You can enable this tool with /etc/xdg/autostart/restorecond.desktop One possible fix to this would be to force a system relabel on everything on upgrades, while this would fix the labels, it is considered to time consuming. (restorecon -R -v / or touch /.autorelabel) Another option would be to just relabel /home (# restorecon -R -v /home) at upgrade time. But this would also be time consuming. And would not catch the cases where the homedir is not in /home. I am strongly for this option. Allowing the user to login while the relabel is still in progress (like it would with restorecond, right?) sounds like a really bad idea... I mean, incorrect labels when used just lead to more incorrect labels, no? And incorrect labels also result in access errors? Both sound like something to avoid... To me it appears that preupgrade should really take care of this on all Fedora release updates. If the relabelling is slow, maybe we can do something about that? Do you know why it is slow? Is this more IO bound? Or is the label lookup slow and this is CPU bound? If the latter it might be possible to parallelize the relabelling? (I wouldn't care too much about homedirs outside of /home. A not in the release notes for such cases should suffice) Lennart How does this affect home dirs which are served over nfs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 01:21:25PM +0200, Miloslav Trmač wrote: Therefore, it is reasonable to assume that Fedora 18 will ship with this change, and applications need to be updated to handle the change, or we will have a more broken Fedora 18. Advising people not to patch programs won't make Fedora 18 less broken at this point. I was using /tmp on tmpfs (with $TMPDIR poining inside of /tmp) for several years in ALT Linux. And by use I mean build packages using mock-like tool that creates chroots in $TMPDIR. During all these years, my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. Having /tmp on tmpfs is not THAT scary, is you ask me... -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:58 PM, Steve Clark wrote: On 05/31/2012 09:14 PM, Kevin Kofler wrote: Chris Adams wrote: - Secure boot is required to be able to be disabled on x86 (the only platform Fedora will support it). And this is exactly why we should just require our users to disable it! I don't see any advantage at all from supporting this feature, just problems: * extra restrictions added to GRUB and the kernel to comply with the security (lockout) requirements. Even if they're all conditional on secure boot being enabled (are they really?), that still means extra code which can cause extra breakage even when running in normal mode (the one every Free Software user should be using). * possible GPL violation. Did Red Hat Legal have a look at the plans already? Are they sure they're compliant with the GPL, v2 when it comes to the kernel, v3 when it comes to GRUB 2? (What's sure is that they aren't compliant with the spirit of the GPL, whatever version!) * ineffectiveness of the added restrictions: Can't you still bring up a Blue Pill with a Window$ VM even with only unsigned userspace apps? And if we don't even allow those, where's the freedom? * exercising your freedom to change the kernel (or even just to load an out- of-tree module!) requires you to disable Secure (Restricted) Boot anyway, so why support the restricted mode? (As much as I hate proprietary drivers, you can definitely expect a horde of their users showing up at your door with a pitchfork…) * implicit endorsement of M$ and their signature racket (including a monetary payment to their racketing partner Veri$ign – was that already made?). It might even lead M$ to drop the requirement to allow disabling Secure Boot (or even invert it into a prohibition as on ARM!), arguing that Linux (sic, should be GNU/Linux) supports it too anyway. * dependence on the racket, which can change its terms at any moment. Just saying disable 'Secure' Boot in the BIOS is the easiest solution to the problem. I remember the days where one had to disable PlugPlay Operating System in the BIOS to get GNU/Linux to boot at all on some machines, it didn't cause any real problems. Kevin Kofler +100 -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com N�n�r)em�h�yhiם�w^�� +100 -- Paul Richardson * p.g.richard...@phantomjinx.co.uk * pgrichard...@linux.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sys/sysctl.h and bits/sysctl.h in rawhide/f18?
On 05/31/2012 02:00 PM, Jim Meyering wrote: Kaleb Keithley wrote: About a week ago I did a scratch build of one of my packages that includessys/sysctl.h and it built successfully. Today I did another scratch build and it broke with: ... Making all in src CC fuse-helpers.lo CC fuse-resolve.lo CC fuse-bridge.lo CC misc.lo In file included from fuse-helpers.c:24:0: /usr/include/sys/sysctl.h:63:25: fatal error: bits/sysctl.h: No such file or directory compilation terminated. ... I noticed that today and reported it: http://bugzilla.redhat.com/827040 I note that a new build of glibc, including glibc-headers occurred late yesterday (2012-05-31), but the fix was not included. Is there an ETA for when this will be fixed? I'm probably not the only one that this is affecting. Thanks, -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CPAN-Meta-Requirements] Skip some tests on bootstrap
commit bd2d1f1502f9db5573f9205af2d6532ad2f3d000
Author: Petr Písař ppi...@redhat.com
Date: Fri Jun 1 14:38:15 2012 +0200
Skip some tests on bootstrap
perl-CPAN-Meta-Requirements.spec | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
---
diff --git a/perl-CPAN-Meta-Requirements.spec b/perl-CPAN-Meta-Requirements.spec
index cea9895..3c92ad3 100644
--- a/perl-CPAN-Meta-Requirements.spec
+++ b/perl-CPAN-Meta-Requirements.spec
@@ -1,6 +1,6 @@
Name: perl-CPAN-Meta-Requirements
Version:2.122
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Set of version requirements for a CPAN dist
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,9 +13,12 @@ BuildRequires: perl(File::Find)
BuildRequires: perl(File::Temp)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Test::More)
+%if !%{defined perl_bootstrap}
BuildRequires: perl(Test::Script)
+%endif
BuildRequires: perl(version) = 0.77
# for author/release tests
+%if !%{defined perl_bootstrap}
BuildRequires:
perl(Perl::Critic::Policy::Lax::ProhibitStringyEval::ExceptForRequire)
BuildRequires: perl(Pod::Coverage::TrustPod)
BuildRequires: perl(Pod::Wordlist::hanekomu)
@@ -27,6 +30,7 @@ BuildRequires: perl(Test::Portability::Files)
BuildRequires: perl(Test::Requires)
BuildRequires: perl(Test::Spelling) aspell-en
BuildRequires: perl(Test::Version)
+%endif
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -59,6 +63,9 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} \;
%{_fixperms} %{buildroot}/*
%check
+%if %{defined perl_bootstrap}
+rm -rf xt
+%endif
make test TEST_FILES=t/*.t xt/*/*.t
%files
@@ -67,6 +74,9 @@ make test TEST_FILES=t/*.t xt/*/*.t
%{_mandir}/man3/*
%changelog
+* Fri Jun 01 2012 Petr Pisar ppi...@redhat.com
+- Skip some tests on bootstrap
+
* Mon May 07 2012 Iain Arnell iarn...@gmail.com 2.122-1
- update to latest upstream version
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: *countable infinities only
On Fri, Jun 1, 2012 at 5:36 AM, Bryn M. Reeves b...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 10:42 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:07 -0400, Gerry Reno wrote: Yes, all these would currently support what I'm suggesting. Actually, if you're willing to flip a lot of switches, you could probably make your / a raid5 of floppies, but the performance would be suboptimal. -J Ok, now you're just being silly. Behold: http://www.wired.com/gadgetlab/2009/05/five-disk-floppy-raid-4mb-of-blistering-fast-storage/ Hey, you might be joking but I used to demo MD RAID in Red Hat classes using a dinky little 4-port USB1 hub (with a Shadowman logo) and four Red Hat branded USB keys. Worked great :-) Actually, with enough PCI USB port cards, USB hubs, and thumb drives, you could use MD RAID and possibly LVM to make a poor-person's SAN. Hot-swappable drives and all. -J Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/ImxUACgkQ6YSQoMYUY96GcgCg0Hl2mIPTJRx4wPUujN4fPVex fL8An1E/1Gd6DQwgzC36hXm2HFk6mCbX =xv75 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 05/31/2012 12:18 PM, Lennart Poettering wrote: On Wed, 30.05.12 19:04, Garrett Holmstrom (gho...@fedoraproject.org) wrote: If you have an explicit /tmp entry in fstab things should continue to work the same as before. If you don't then you will now get a tmpfs on /tmp by default. What does an fstab entry that means, leave /tmp on the / filesystem, look like? See the feature page. To turn this feature off, do: systemctl mask tmp.mount Lennart Is enough to edit /etc/fstab? If not, why? Any benefits to have it directly in systemd? RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/01/2012 01:51 PM, Jon Ciesla wrote: Actually, with enough PCI USB port cards, USB hubs, and thumb drives, you could use MD RAID and possibly LVM to make a poor-person's SAN. Hot-swappable drives and all. And with LIO in the kernel you can even export it over fibre channel or FCoE! Happy days! :) Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/IvrEACgkQ6YSQoMYUY94nOACgszBwn4D4EHl3oWakWXx/XOMH RpMAn2RKxav49G3/pnXx3UqK7rmcaFV8 =ndBc -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: As we develop SELinux we are adding new labels to homedir content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/01/2012 06:14 AM, Lennart Poettering wrote: On Thu, 31.05.12 15:44, Daniel J Walsh (dwa...@redhat.com) wrote: Heya, We have added file trans by name rules to policy to fix a lot of files/directories being created with the correct label. We have problems on Distribution updates (F16-F17) though, where there is a files/directories in the homedir that are mislabeled. We have restorecond -u which we run in F15/F16 which examines the homedir and fixes any files directories it finds mislabeled in ~. If it finds a dir which is mislabeled, it will relabel the directory and all of its children. We have turned this tool off by default on the desktop in F17, because filename transition rules are doing a pretty good job of maintaining the labels in the homedir. But this tool never did a great job of fixing mislabeled subdirs, if the top level directory in the homedir was labeled correctly. You can enable this tool with /etc/xdg/autostart/restorecond.desktop One possible fix to this would be to force a system relabel on everything on upgrades, while this would fix the labels, it is considered to time consuming. (restorecon -R -v / or touch /.autorelabel) Another option would be to just relabel /home (# restorecon -R -v /home) at upgrade time. But this would also be time consuming. And would not catch the cases where the homedir is not in /home. I am strongly for this option. Allowing the user to login while the relabel is still in progress (like it would with restorecond, right?) sounds like a really bad idea... I mean, incorrect labels when used just lead to more incorrect labels, no? And incorrect labels also result in access errors? Both sound like something to avoid... To me it appears that preupgrade should really take care of this on all Fedora release updates. If the relabelling is slow, maybe we can do something about that? Do you know why it is slow? Is this more IO bound? Or is the label lookup slow and this is CPU bound? If the latter it might be possible to parallelize the relabelling? (I wouldn't care too much about homedirs outside of /home. A not in the release notes for such cases should suffice) Lennart Well it is slow in the same sense as find /home would be slow, restorecon is using fts or ntfs to walk the file system and reads in the SELinux Context (getxattr), asks SELinux what it should be labeled (matchpathcon), does a compare, if they are different, does a setxattr on the inode. Depends on the number of inodes in the /home dir. You could time it doing a restorecon -R -v /home right now, my system which has piled up a ton of crap and exploded development pools takes nearly 2 minutes. time restorecon -R /home real1m42.677s user0m41.747s sys 0m39.888s If you had Huge file systems it could take a large amount of time. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/IwAYACgkQrlYvE4MpobPrhwCgtn+VhZimc5uD6xHZoSqHwC/O +KYAoLM0Ahv5PkumbCxT1GBU1oAL2MI7 =Qvnv -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: As we develop SELinux we are adding new labels to homedir content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/01/2012 08:10 AM, Bill Peck wrote: On 06/01/2012 06:14 AM, Lennart Poettering wrote: On Thu, 31.05.12 15:44, Daniel J Walsh (dwa...@redhat.com) wrote: Heya, We have added file trans by name rules to policy to fix a lot of files/directories being created with the correct label. We have problems on Distribution updates (F16-F17) though, where there is a files/directories in the homedir that are mislabeled. We have restorecond -u which we run in F15/F16 which examines the homedir and fixes any files directories it finds mislabeled in ~. If it finds a dir which is mislabeled, it will relabel the directory and all of its children. We have turned this tool off by default on the desktop in F17, because filename transition rules are doing a pretty good job of maintaining the labels in the homedir. But this tool never did a great job of fixing mislabeled subdirs, if the top level directory in the homedir was labeled correctly. You can enable this tool with /etc/xdg/autostart/restorecond.desktop One possible fix to this would be to force a system relabel on everything on upgrades, while this would fix the labels, it is considered to time consuming. (restorecon -R -v / or touch /.autorelabel) Another option would be to just relabel /home (# restorecon -R -v /home) at upgrade time. But this would also be time consuming. And would not catch the cases where the homedir is not in /home. I am strongly for this option. Allowing the user to login while the relabel is still in progress (like it would with restorecond, right?) sounds like a really bad idea... I mean, incorrect labels when used just lead to more incorrect labels, no? And incorrect labels also result in access errors? Both sound like something to avoid... To me it appears that preupgrade should really take care of this on all Fedora release updates. If the relabelling is slow, maybe we can do something about that? Do you know why it is slow? Is this more IO bound? Or is the label lookup slow and this is CPU bound? If the latter it might be possible to parallelize the relabelling? (I wouldn't care too much about homedirs outside of /home. A not in the release notes for such cases should suffice) Lennart How does this affect home dirs which are served over nfs? It would not, restorecon checks to see if the file system supports SELinux labels, if not it exits immediately. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/IwLkACgkQrlYvE4MpobNAAQCfS/CgjBpA/Lpa9Jq5PK836MAw i9EAn1woncYuNKpCP8XILq1FtK3Y+PEq =47g+ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
projectM
Unfortunately, I'm no longer in a position to maintain the projectM packages (libprojectM, libprojectM-qt, projectM-jack, projectM-libvisual, and projectM-pulseaudio), so I will need to orphan these. If anyone would like to pick these up, feel free to come to me with questions, or help. Thanks, =-Jameson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 08:12 AM, Alexey I. Froloff wrote: my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. And how is a random user supposed to know this? So if things start acting up the answer is to add more swap and mess with fstab? WTF? So now any software which uses /tmp for *gasp* temporary space is now potentially broken depending on the size of the temporary data. Sorry guys, this feature sucks. The rationale was and is handwavy at best and none of the legitimate concerns which have been raised have been answered in any meaningful fashion. There have never been any numbers showing the IO/power benefit claims are true. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
drago01 wrote: The advantages is that things just work (tm). They just work as long as you don't try to actually exercise one of the freedoms we stand for. Or even just install an out-of-tree kernel module such as the ones from RPM Fusion. I don't think this is something we should endorse, also because our endorsement may entice M$ to change away from the current situation (Secure Boot optional) which is certainly a compromise in their eyes. No one will stop you (or anyone else) from disabling it. It's as easy as setting an option in the firmware (BIOS) setup, so I don't see why we can't just require it from everyone. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: As we develop SELinux we are adding new labels to homedir content
On Fri, 01.06.12 09:13, Daniel J Walsh (dwa...@redhat.com) wrote: (I wouldn't care too much about homedirs outside of /home. A not in the release notes for such cases should suffice) Lennart Well it is slow in the same sense as find /home would be slow, restorecon is using fts or ntfs to walk the file system and reads in the SELinux Context (getxattr), asks SELinux what it should be labeled (matchpathcon), does a compare, if they are different, does a setxattr on the inode. Depends on the number of inodes in the /home dir. You could time it doing a restorecon -R -v /home right now, my system which has piled up a ton of crap and exploded development pools takes nearly 2 minutes. time restorecon -R /home real 1m42.677s user 0m41.747s sys 0m39.888s If you had Huge file systems it could take a large amount of time. On my system here (with SSD) this appears to be CPU bound, not IO bound. Hence optimizing this to be fully parallelized might be worth a try? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Brian Wheeler wrote: And how is a random user supposed to know this? So if things start acting up the answer is to add more swap and mess with fstab? WTF? So now any software which uses /tmp for gasp temporary space is now potentially broken depending on the size of the temporary data. Sorry guys, this feature sucks. The rationale was and is handwavy at best and none of the legitimate concerns which have been raised have been answered in any meaningful fashion. There have never been any numbers showing the IO/power benefit claims are true. +1, /tmp on tmpfs is NOT helpful. (That said, we have even bigger problems coming up with Restricted (Secure) Boot!) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Thu, May 31, 2012 at 02:59:09PM +0200, Lennart Poettering wrote: Well, not just FHS, but traditional usage within Red Hat and Fedora. For as long as I can remember, /tmp has had a 10-day retention and /var/tmp 30-day. Does that matter? We still have 10d and 30d clean-up for that. With one addition though: /tmp is also flushed on reboot. I know, but if people who want something not-ram-backed are switching to /var/tmp, they're _also_ getting this different clean-up behavior as a side-effect. (Different in that it went from 10 to 30.) -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 02:12 PM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 01:21:25PM +0200, Miloslav Trmač wrote: Therefore, it is reasonable to assume that Fedora 18 will ship with I certainly disagree ... this change is not reasonable. this change, and applications need to be updated to handle the change, or we will have a more broken Fedora 18. Advising people not to patch programs won't make Fedora 18 less broken at this point. I was using /tmp on tmpfs (with $TMPDIR poining inside of /tmp) for several years in ALT Linux. And by use I mean build packages using mock-like tool that creates chroots in $TMPDIR. During all these years, my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. Having /tmp on tmpfs is not THAT scary, is you ask me... If you ask me (I did the same for some time (Fedora 13-14 era) ) the typical symptoms of /tmp on tmpfs are sporatic, non-deterministic malfunctions. I guess is, struggling with these sporadic malfunction will become an FAQ. Finally, using /var/tmp instead of /tmp for temporary files (c.f. the sort case in another thread) contradicts the primary purpose of /tmp on tmpfs: *speed* In other words, moving current /tmp use-cases to /var/tmp will not gain you any speed-wise. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls for everything else they do. That's crazy. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: projectM
On 06/01/2012 03:24 PM, Jameson wrote: Unfortunately, I'm no longer in a position to maintain the projectM packages (libprojectM, libprojectM-qt, projectM-jack, projectM-libvisual, and projectM-pulseaudio), so I will need to orphan these. If anyone would like to pick these up, feel free to come to me with questions, or help. Thanks, =-Jameson I'll take these on. Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 02:47 PM, Ralf Corsepius wrote: On 06/01/2012 02:12 PM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 01:21:25PM +0200, Miloslav Trmač wrote: Therefore, it is reasonable to assume that Fedora 18 will ship with I certainly disagree ... this change is not reasonable. this change, and applications need to be updated to handle the change, or we will have a more broken Fedora 18. Advising people not to patch programs won't make Fedora 18 less broken at this point. I was using /tmp on tmpfs (with $TMPDIR poining inside of /tmp) for several years in ALT Linux. And by use I mean build packages using mock-like tool that creates chroots in $TMPDIR. During all these years, my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. Having /tmp on tmpfs is not THAT scary, is you ask me... If you ask me (I did the same for some time (Fedora 13-14 era) ) the typical symptoms of /tmp on tmpfs are sporatic, non-deterministic malfunctions. I guess is, struggling with these sporadic malfunction will become an FAQ. Finally, using /var/tmp instead of /tmp for temporary files (c.f. the sort case in another thread) contradicts the primary purpose of /tmp on tmpfs: *speed* In other words, moving current /tmp use-cases to /var/tmp will not gain you any speed-wise. Not all /tmp user-cases need to move to /var/tmp sort is special in this regard in that it only uses external files when there isn't enough RAM. I.E. is expects it to be slower (larger). cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Thu, May 31, 2012 at 09:27:03AM -0400, Brian Wheeler wrote: The wiki page lists the features as: [...] * /tmp is automatically flushed at boot. It seems like adding an rm to the startup sequence would do this with less surprises. Wait, hold on a sec. Again, not necessarily a problem but we should be clear on this. With /tmp in RAM, it's not flushed at _boot_, but at _shutdown_ (clean or not). That may be detrimental to fixing problems (like surprise reboots). The benefit may be worth that downside but we should at least document the distinction. I'm going edit the wiki but I'm not sure what exact wording should be. I guess the *benefit* is clean /tmp on boot and discussion of the implication should be elsewhere -- the user experience section, I think. The page says the user experience should barely change -- which I think is really downplaying the scope of this change. Right. I made some edits there. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
supercat anybody working on it?
Hey guys am about to package this app: http://supercat.nosredna.net/ anybody is working on it? just for case. Regards, Adrian.- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 09:27:16AM -0400, Brian Wheeler wrote: my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. And how is a random user supposed to know this? In Soviet ALT Linux we didn't care about random users ;-) In perfect world random user must be smart enough to read the documentation. However, this implies, that such documentation exists and easily accessed (which at first sight is true for Fedora). So if things start acting up the answer is to add more swap and mess with fstab? WTF? This is up to Release Managers. Reasonable defaults in installer, documentation, etc... So now any software which uses /tmp for *gasp* temporary space is now potentially broken depending on the size of the temporary data. Well, no software should use /tmp directly, IMO. There's nice environment variable $TMPDIR. You can always point it to $HOME/tmp for example. And you can always turn it off if you really need to. Sorry guys, this feature sucks. I like this feature, and there should be easy, well documented way to turn it off. I personally don't see a reason why it should be off by default. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd: no device ever becomes pluggable
I've upgraded a few machines to Fedora 17. One of them does not boot anymore. No device ever becomes plugged, thus systemd eventually times out waiting for the disk device (dev-sda1.device) and drops into the emergency shell. The device is there and accessible; udevadm trigger --type=devices --action==add does generate add events (as seen by udevmonitor) Strangely, though, none of the devices have a sysfs path; also, I only have the two disk devices mentioned in fstab, while on working machines I have many more. Can somebody give me a hint on what goes wrong, or on how to debug this further? Thanks, Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mounted external ext4 causes high kworker cpu
Chris Murphy li...@colorremedies.com writes: On Apr 27, 2012, at 9:53 AM, Jeff Moyer wrote: Chris Murphy li...@colorremedies.com writes: Normally top reports CPU line, sy at 0.4% when idle. If I format an external Firewire disk as btrfs and mount it, it remains at 0.4%. If I reformat as XFS and mount it, again top reports sy at 0.4%. However, if I reformat as ext4 and mount it, sy runs at 3.5%. These two processes are now at the top of top's results: kworker/1:2 kworker/0:4 Each uses on average 1.9% CPU. The light on the external drive flashes 4x per second. There are no processes using the disk at all while this is going on. If I umount it, the pulsing stops. If I remount it, the pulsing resumes as does the slightly higher CPU consumption. This doesn't happen with the same hardware mounted XFS or btrfs or HFS+. Odd? Sounds like lazy itable init. Try mkfs -t ext4 -E lazy_itable_init=0. This is happening on internal disks, targeted for Fedora installation. I can hear it once install is complete, still booted from DVD media. Is this a bug? So long as the file system is mounted and the itable initialization is not complete, I would expect the initialization to continue. Does that answer your question? Cheers, Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Hi. Firebird sql or the name it used to have before. Not sure if it was default configuration or still behaves the same. But it used to do similar thing sort does for some queries. Anyone? Current example but shipped with F18 from that area? - Original Message - From: Pádraig Brady p...@draigbrady.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Roberto Ragusa m...@robertoragusa.it Sent: Thursday, May 31, 2012 12:45:36 PM Subject: Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs On 05/31/2012 08:14 AM, Roberto Ragusa wrote: On 05/31/2012 02:40 AM, Lennart Poettering wrote: Heya! Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18. [...] This will most likely lead to a problem or two with software that isn't happy about /tmp being small. For example sort. This is a good example because `sort` algorithmically needs something below RAM in the memory hierarchy (i.e. bigger), but with the same persistence characteristics of /tmp. Currently `sort` defaults to $TMPDIR or if not set '/tmp'. Now /var/tmp should be more persistent which we don't need, but shouldn't be an issue, but should also not be in RAM and so is more appropriate. So I'll patch sort to default to /var/tmp rather than /tmp. I'm a little worried about the general availability of /var/tmp. I know I've created distros without it at least. For my own reference, sort does support a list of tmp dirs, but it'll need to be tweaked to support non existent dirs: $ seq 10 | sort -T /foo -T /tmp -S1M sort: cannot create temporary file in `/foo': No such file or directory `tac` from coreutils also needs a similar patch. cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno gr...@verizon.net wrote: So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls for everything else they do. That's crazy. Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, 1 Jun 2012 12:21:36 +0200 Michael scherer m...@zarb.org wrote: On Thu, May 31, 2012 at 01:55:35PM -0500, Chris Adams wrote: Once upon a time, Peter Jones pjo...@redhat.com said: That's why we didn't simply ask vendors to ship our key. That would be /less/ equitable to other distributions than the solution we're looking at right now. Has any thought been given to setting up group between various Open Source distributions (Linux, BSD) to be a Secure Boot signer (with security-oriented rules about what gets signed, probably similar to whatever Microsoft is using today) and then getting vendors to include the master key along site Microsoft's? The last attempt to do something similar I can think of would be cacert. Afaik, they are still being audited to be added to Firefox, and i think they would be happy to explain all the issues they faced on that road. Well, I'm a bit skeptical there, since they can't even license their ca stuff such that Fedora can actually distribute it. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 10:23 AM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 09:27:16AM -0400, Brian Wheeler wrote: my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. And how is a random user supposed to know this? In Soviet ALT Linux we didn't care about random users ;-) In perfect world random user must be smart enough to read the documentation. However, this implies, that such documentation exists and easily accessed (which at first sight is true for Fedora). So if things start acting up the answer is to add more swap and mess with fstab? WTF? This is up to Release Managers. Reasonable defaults in installer, documentation, etc... So now any software which uses /tmp for *gasp* temporary space is now potentially broken depending on the size of the temporary data. Well, no software should use /tmp directly, IMO. There's nice environment variable $TMPDIR. You can always point it to $HOME/tmp for example. And you can always turn it off if you really need to. Sorry guys, this feature sucks. I like this feature, and there should be easy, well documented way to turn it off. I personally don't see a reason why it should be off by default. Since most user don't know anything about this why not leave it off and the sophisticated power user can turn it on, since It is trivial to do. -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, 2012-06-01 at 03:14 +0200, Kevin Kofler wrote: Chris Adams wrote: - Secure boot is required to be able to be disabled on x86 (the only platform Fedora will support it). And this is exactly why we should just require our users to disable it! I don't want to jump in the technicality of this discussion, but I can only hope any solution that *requires* users to fiddle with BIOS settings in order to install Fedora won't be seriously considered as viable. Regards, Cosimo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 11:05:26AM -0400, Gregory Maxwell wrote: On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno gr...@verizon.net wrote: So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls for everything else they do. That's crazy. Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap. The *default* limit for tmpfs is half of physical RAM (swap is not counted). So *if* tmp-on-tmpfs is left at the defaults then increasing physical RAM might be necessary. I haven't bothered to look at how tmp-on-tmpfs is implemented in systemd though. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/01/2012 11:05 AM, Gregory Maxwell wrote: On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno gr...@verizon.net wrote: So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls for everything else they do. That's crazy. Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap. Wait a minute. Back in this thread it says that half of RAM is allocated to the tmpfs for /tmp. Plus the purported benefit from this is causing less write cycles on SSD. (See Wiki page) That may have been a benefit a few years ago but newer SSD's will gain almost nothing from this because of the enormous number of write cycles they handle. This feature may have some benefits but I think they are infinitesimally small. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 11:18 AM, Cosimo Cecchi wrote: On Fri, 2012-06-01 at 03:14 +0200, Kevin Kofler wrote: Chris Adams wrote: - Secure boot is required to be able to be disabled on x86 (the only platform Fedora will support it). And this is exactly why we should just require our users to disable it! I don't want to jump in the technicality of this discussion, but I can only hope any solution that *requires* users to fiddle with BIOS settings in order to install Fedora won't be seriously considered as viable. Regards, Cosimo The better solution would be for users for want SecureBoot to have to set it in the BIOS. It should be disabled by default. Windows is the OS with all the attack vectors open. Users of every other OS should not be hostage to this SecureBoot by default. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 10:23 AM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 09:27:16AM -0400, Brian Wheeler wrote: my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. And how is a random user supposed to know this? In Soviet ALT Linux we didn't care about random users ;-) So that means that random users care about YOU! In perfect world random user must be smart enough to read the documentation. However, this implies, that such documentation exists and easily accessed (which at first sight is true for Fedora). Sure. When there's mystery problems , who is going to think oh yeah, /tmp is in ram now and chrome just wrote a big temp file...better go look up how to add swap? I'm going to guess 'nearly nobody' So if things start acting up the answer is to add more swap and mess with fstab? WTF? This is up to Release Managers. Reasonable defaults in installer, documentation, etc... The thing is, the amount of reasonable swap is now not a function of just RAM overflow but also /tmp usage -- which is something that can vary dramatically at runtime. So now any software which uses /tmp for *gasp* temporary space is now potentially broken depending on the size of the temporary data. Well, no software should use /tmp directly, IMO. There's nice environment variable $TMPDIR. You can always point it to $HOME/tmp for example. And you can always turn it off if you really need to. Sure, no software _should_ use it directly, but it happens a lot...and not in packages which are in the repo: home grown and third party. Additionally, there's 20+ years of habit to break for a lot of people and that's not something you can easily patch. Running things like grep \\ 404\ apache.log /tmp/404s.log is pretty ingrained for many people. I'll probably turn it off because I've been down this road with Solaris and it sucked. I will grant that the linux implementation is better, but I want RAM to be used for the running software and if its not being used for that, caching what's actively being used. Sorry guys, this feature sucks. I like this feature, and there should be easy, well documented way to turn it off. I personally don't see a reason why it should be off by default. Well, since I'm probably going to turn it off, can someone give me a good reason why it should be turned _on_ by default? For me, the Benefit to Fedora bullets are not compelling. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, Jun 1, 2012 at 11:27 AM, Gerry Reno gr...@verizon.net wrote: Wait a minute. Back in this thread it says that half of RAM is allocated to the tmpfs for /tmp. Plus the purported benefit from this is causing less write cycles on SSD. (See Wiki page) That may have been a benefit a few years ago but newer SSD's will gain almost nothing from this because of the enormous number of write cycles they handle. You're not understanding the word allocate in the same way it actually behaves. It does not reserve memory. The default maximum size (think of it as a quota) of a tmpfs mount is half whatever amount of actual ram you have. You can expand or shrink a tmpfs mount using the size= mount option. Memory is not actually used until things are stored there, and if the result is memory pressure the kernel will intelligently page out the least used pages. (e.g. tmp files that haven't been accessed in a long time, or inactive application memory instead of an actively accessed file on tmp), per the normal vm policy. Because that disk activity only happens when the kernel decides that it wants the memory for something else it doesn't happen at all in a great many cases especially for short lived files. This feature may have some benefits but I think they are infinitesimally small. The feature may be adopted/promoted on the basis of SSD writecycle preservation, but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed— which is the reason that many people have been using tmpfs for /tmp on many systems for much longer than SSDs have existed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Once upon a time, Gerry Reno gr...@verizon.net said: Wait a minute. Back in this thread it says that half of RAM is allocated to the tmpfs for /tmp. Not exactly. The default size limit for a tmpfs mount is half of RAM; the RAM is not allocated exclusively to the tmpfs. The files in a tmpfs mount live in the page cache and can be swapped out if needed. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 08:30 AM, Gerry Reno wrote: The better solution would be for users for want SecureBoot to have to set it in the BIOS. It should be disabled by default. Windows is the OS with all the attack vectors open. Users of every other OS should not be hostage to this SecureBoot by default. You say this as if we have any control over this, whatsoever. The vast majority of PCs on the market are designed to run Windows. They come with Windows pre-installed. In order to come with Windows 8 pre-installed, they will have to enable secure boot at the factory. There is no stopping this. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Cosimo Cecchi wrote: I don't want to jump in the technicality of this discussion, but I can only hope any solution that requires users to fiddle with BIOS settings in order to install Fedora won't be seriously considered as viable. Sorry, but it's the ONLY viable solution. Any solution that removes users' freedom (and that's the case of ANY solution which leaves Secure Boot enabled) cannot be seriously considered as viable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 03:35:45PM +0200, Kevin Kofler wrote: (That said, we have even bigger problems coming up with Restricted (Secure) Boot!) To be fair, this problem is not one of our own doing. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 11:27:01AM -0400, Gerry Reno wrote: Wait a minute. Back in this thread it says that half of RAM is allocated to the tmpfs for /tmp. No-no-no! Default tmpfs size is half of physical RAM, that's all. That doesn't mean that is stays in RAM forever. $ df -h /tmp Filesystem Size Used Avail Use% Mounted on tmpfs24G 1.9M 24G 1% /tmp $ free -m total used free sharedbuffers cached Mem: 15987 14653 1333 0328 8402 -/+ buffers/cache: 5922 10065 Swap:31251 55 31196 $ dd if=/dev/zero of=/tmp/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 9.02507 s, 1.2 GB/s $ df -h /tmp Filesystem Size Used Avail Use% Mounted on tmpfs24G 11G 14G 42% /tmp $ free -m total used free sharedbuffers cached Mem: 15987 15892 95 0 13 10105 -/+ buffers/cache: 5773 10213 Swap:31251 1464 29787 $ dd if=/dev/zero of=/tmp/enother-file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 57.2924 s, 187 MB/s $ free -m total used free sharedbuffers cached Mem: 15987 15886100 0 4 10251 -/+ buffers/cache: 5630 10357 Swap:31251 10482 20769 $ rm -f /tmp/file /tmp/enother-file $ df -h /tmp Filesystem Size Used Avail Use% Mounted on tmpfs24G 1.9M 24G 1% /tmp $ free -m total used free sharedbuffers cached Mem: 15987 5718 10268 0 5146 -/+ buffers/cache: 5566 10420 Swap:31251108 31143 -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/01/2012 11:35 AM, Gregory Maxwell wrote: Because that disk activity only happens when the kernel decides that it wants the memory for something else it doesn't happen at all in a great many cases especially for short lived files. ... The feature may be adopted/promoted on the basis of SSD writecycle preservation, but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed— which is the reason that many people have been using tmpfs for /tmp on many systems for much longer than SSDs have existed. Um, aren't both of those benefits the same as one would get when using ext4's delayed allocation? Does anyone have any actual numbers for the performance increase? I've never seen any numbers, but I've heard the claim repeatedly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Once upon a time, Gerry Reno gr...@verizon.net said: The better solution would be for users for want SecureBoot to have to set it in the BIOS. It should be disabled by default. Windows is the OS with all the attack vectors open. Users of every other OS should not be hostage to this SecureBoot by default. As has been repeatedly shown, Windows is the common attack vector in large part because it is the widest deployed system, and users (of any OS) are idiots that will click Ok if you give them a pop-up that says I'm going to delete all your files right now. Linux gets a high number of attacks as well, but mostly in the server space today (password scanning on SSH, POP3, IMAP, SMTP AUTH, and common web hosting control panels such as Plesk and cPanel). PHP and common PHP packages (such as phpBB) have had vulnerabilities that get leveraged to attack the underlying OS. There's a reason Fedora has things like chkrootkit and rkhunter. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Gerry Reno wrote: The better solution would be for users for want SecureBoot to have to set it in the BIOS. It should be disabled by default. Windows is the OS with all the attack vectors open. Users of every other OS should not be hostage to this SecureBoot by default. While I couldn't agree more, unfortunately, that isn't up to us to decide. The decision is theoretically up to the hardware vendors, and in practice their hands are tied by M$'s logo requirements. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Once upon a time, Brian Wheeler bdwhe...@indiana.edu said: Um, aren't both of those benefits the same as one would get when using ext4's delayed allocation? Delayed allocation still has to flush metadata changes to storage regularly as well as possibly read metadata from storage to find available inodes, while tmpfs only has to touch storage under pressure from high RAM utilization. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, Jun 1, 2012 at 3:30 PM, Kevin Kofler kevin.kof...@chello.at wrote: drago01 wrote: The advantages is that things just work (tm). They just work as long as you don't try to actually exercise one of the freedoms we stand for. Which one? Or even just install an out-of-tree kernel module such as the ones from RPM Fusion. You can disable secure boot (unless we find a better solution) ... adding secure boot support won't make this any harder. I don't think this is something we should endorse, also because our endorsement may entice M$ to change away from the current situation (Secure Boot optional) which is certainly a compromise in their eyes. I doubt that but well we both can't know that beforehand so this point is moot. No one will stop you (or anyone else) from disabling it. It's as easy as setting an option in the firmware (BIOS) setup, so I don't see why we can't just require it from everyone. It is easy for you, for me, for pretty much everyone on this mailing list but there are different types of users out there. And you effectively want to limit those users to a proprietary OS (they cannot even try our live images anymore). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: supercat anybody working on it?
On Fri, Jun 01, 2012 at 11:15:06AM -0300, Adrian Alves wrote: Hey guys am about to package this app: http://supercat.nosredna.net/ anybody is working on it? just for case. No, at least they haven't filed any review bugs in Bugzilla: https://bugzilla.redhat.com/buglist.cgi?quicksearch=ALL+supercat Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 11:31:21AM -0400, Brian Wheeler wrote: Well, since I'm probably going to turn it off, can someone give me a good reason why it should be turned _on_ by default? For me, the Benefit to Fedora bullets are not compelling. One good reason is to separate /tmp from /. When choosing between failed sort and failed passwd (or anything else, that modifies files in /), both because of No space left on device error I prefer failed sort and working passwd. And tmpfs is faster than any other filesystem, and easily resized both ways. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, Jun 1, 2012 at 5:40 PM, Kevin Kofler kevin.kof...@chello.at wrote: Cosimo Cecchi wrote: I don't want to jump in the technicality of this discussion, but I can only hope any solution that requires users to fiddle with BIOS settings in order to install Fedora won't be seriously considered as viable. Sorry, but it's the ONLY viable solution. Any solution that removes users' freedom (and that's the case of ANY solution which leaves Secure Boot enabled) cannot be seriously considered as viable. Secureboot support does *NOT* limit your freedom as long as it is optional (the default setting does not matter). You are either making more complex for everyone or for those that want do develop kernel development, run out of tree drivers etc. In case enabled secureboot is the only option (i.e we somehow refuse to boot with it disabled) then (and only then) you can talk about removed freedom otherwise this is just FUD. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Reminder: Fedora 15 end of life on 2012-06-26
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings. This is a reminder email about the end of life process for Fedora 15. Fedora 15 will reach end of life on 2012-06-26, and no further updates will be pushed out after that time. Additionally, with the recent release of Fedora 17, no new packages will be added to the Fedora 15 collection. Please see http://fedoraproject.org/wiki/DistributionUpgrades for more information on upgrading from Fedora 15 to a newer release. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/Hs9cACgkQkSxm47BaWfdD0ACfe3hnA637Qb+TRFy9pbe3ZekH MxwAnRNKH5/CfWmfTEp4Jd1eltOuQKdQ =NRnZ -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Am 01.06.2012 11:25, schrieb Michal Schmidt: On 06/01/2012 10:37 AM, Caterpillar wrote: Please apologize me, but if #820340 was not a showstopper, so which bug should be a showstopper? The bug * does not cause data loss * is easy to recover from for you and for me not for the majority of users * seems to be fixable with an update how do you do the update if your system does not boot? it is not sure that a kernel from the oldr release boots = Not what I'd call a showstopper depends on the point of view at a minimum it should be granted that the kernel of the new distribution version is the default after dist-upgrade signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Am 01.06.2012 16:23, schrieb Alexey I. Froloff: Sorry guys, this feature sucks. I like this feature, and there should be easy, well documented way to turn it off. I personally don't see a reason why it should be off by default so you can add 1 line to /etc/fstab since many years this feature is another having solution, searching for problem DO NOT SPIT USELESS DATA IN MY RAM PER DEFAULT BECAUSE RAM IS EXPENSIVE STORAGE AND USED FOR BETTER THINGS but why forcing majority of users do the same to get a usefull behavior? it is not smart to waste RAM with temp-data and force every software with large temp-data to get fixed write it somewhere else Well, no software should use /tmp directly, IMO. There's nice environment variable $TMPDIR. what does this change? finally most software will be fixed to not use it at all and spit in /var/tmp and render /tmp useless for many years it was a perfect setup to make a own partition or use in case of virtual machines even a own vdisk for /tmp because there can be large data which you do not want on a 4 GB small / and now the defaults are changed to spit tmp-data in the root-fs yes, powerusers can change this (and will) as also they could use tmpfs all over the time - but it is a wrong DEFAULT signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Am 31.05.2012 12:45, schrieb Pádraig Brady: Currently `sort` defaults to $TMPDIR or if not set '/tmp'. Now /var/tmp should be more persistent which we don't need, but shouldn't be an issue, but should also not be in RAM and so is more appropriate. So I'll patch sort to default to /var/tmp rather than /tmp thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults in such setups the new behavior results in a full rootfs also having many virtual machines on a host means you try to allocate as less as possible RAM for each of them which makes the new defaults unuseable and no swapping is not smart in context of virualization /tmp in RAm is another change for the sake of the change signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Am 01.06.2012 17:05, schrieb Gregory Maxwell: On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno gr...@verizon.net wrote: So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls for everything else they do. That's crazy. Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap well designed machines do NOT swap and have not alligend swap at all - in the case of virtualization you MUST NOT enforce swapping if you really like perofrmance even in 100 years there will be installations of people having 50,80,100 or more vurtual machine son a host and try to allocate only needed ressourcs wasting RAM a a default is only bad in such cases but however, since most packagers starting to move all their temp stuff to /var/tmp we well not noitice any changes except that you have to mount the tmp-vdisk to /var/tmp istead /tmp signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Am 01.06.2012 17:35, schrieb Gregory Maxwell: The feature may be adopted/promoted on the basis of SSD writecycle preservation, but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed— which is the reason that many people have been using tmpfs for /tmp on many systems for much longer than SSDs have existed pff and this is a generic worklaod for MAJORITY of the user-base? no? hmm wait a minute... if it is not why should DEFAULTS are changed and a unknown amount of packages broken/fixed/patched to no longer touch /tmp and blow all temorary stuff to /var/tmp the MINORITY can add the line in /etc/fstab since ten years and be happy as all the time before - the rest does not need it or is even hurted by the change what currently happens is that based on a exotic workload majority of users and packagers are forced to act in a way few people thought may be nice signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Am 01.06.2012 17:44, schrieb Gerry Reno: Well, I don't have any workloads that are doing high-speed create/remove of file in /tmp. And I don't think most people have any of those types of workloads either. Wouldn't it make sense that people with those types of workloads could enable /tmp on tmpfs? Rather than making it the default for everyone. they can since many years, now all others have to learn how fix back the setup for their workloads echo tmpfs /tmp tmpfs defaults,noatime,nodiratime,noexec,size=500m /etc/fstab changes in fedora are often not for the userbase they are often only for the sake of the change signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Am 01.06.2012 17:52, schrieb Alexey I. Froloff: One good reason is to separate /tmp from /. When choosing between failed sort and failed passwd (or anything else, that modifies files in /), both because of No space left on device error I prefer failed sort and working passwd. and exatly the opposite happens for systems which are well designed and have a seperate /tmp because as side-effect of this feature all osrt of applications are patched to spit their stuff to /var/tmp and back to rootfs does nobody of the feautre owners realize that this is not smart nor bring any benefit at all? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 11:52 AM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 11:31:21AM -0400, Brian Wheeler wrote: Well, since I'm probably going to turn it off, can someone give me a good reason why it should be turned _on_ by default? For me, the Benefit to Fedora bullets are not compelling. One good reason is to separate /tmp from /. When choosing between failed sort and failed passwd (or anything else, that modifies files in /), both because of No space left on device error I prefer failed sort and working passwd. And tmpfs is faster than any other filesystem, and easily resized both ways. Has anyone even done any real testing of this across the spectrum of installation types? How is this going to affect VM installations where RAM and swap is usually very minimal levels? 256mb or 512mb in many instances. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Gregory Maxwell wrote: My understanding is that some of the relevant legal minds believe that Microsoft's you can disable it concession forecloses the possibility of a successful legal attack on this— the law may care about the anti-competativeness of this stuff, but not so much as to care about a $99 signing key or some minor install time hurdle. (and the fact that fedora is willing to plan this probably justifies this position). It was arguably a strategic error to blow the whistle in advance and give Microsoft time to compromise. Their first attempt was much more likely to have created a civil cause of action as well as to have run afoul on antitrust grounds. But I can hardly blame anyone for trying. Hindsight 20/20 and all that. If having the option to disable the crap even if it's enabled by default is sufficient to not be anti-competitive, then they would have done just that after being sued. So I don't think letting them go the most restrictive possible way and then sueing would have been any more effective than what actually happened. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Once upon a time, Reindl Harald h.rei...@thelounge.net said: DO NOT SPIT USELESS DATA IN MY RAM PER DEFAULT BECAUSE RAM IS EXPENSIVE STORAGE AND USED FOR BETTER THINGS Actually, the data written to /tmp _always_ goes through the page cache and is held in RAM (at least for a bit). Since many things in /tmp are short-lived, they'll stay in the page cache for life. The difference between /tmp-on-storage and /tmp-on-tmpfs is that tmpfs has no overhead for reading metadata from storage, allocating space, flushing updated metadata, etc.; the files just only exist in the same page cache they would have been in all along. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, 2012-06-01 at 17:54 +0200, drago01 wrote: On Fri, Jun 1, 2012 at 5:40 PM, Kevin Kofler kevin.kof...@chello.at wrote: Cosimo Cecchi wrote: I don't want to jump in the technicality of this discussion, but I can only hope any solution that requires users to fiddle with BIOS settings in order to install Fedora won't be seriously considered as viable. Sorry, but it's the ONLY viable solution. Any solution that removes users' freedom (and that's the case of ANY solution which leaves Secure Boot enabled) cannot be seriously considered as viable. Secureboot support does *NOT* limit your freedom as long as it is optional (the default setting does not matter). The point I'm trying to make is the default setting might actually be the most important thing that matters when it comes to new users that want to install Fedora. - You need to disable SecureBoot in the BIOS settings in order to install Fedora - BIOS settings? What's that? Oh a blueish DOS-like command-line thing? Freaky. Disable SecureBoot? Why on earth would I want to make my system less secure? *screw this Linux thing* Cosimo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Once upon a time, Reindl Harald h.rei...@thelounge.net said: thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and still work exactly as before (if not, that's a bug and should be treated as such). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Peter Jones wrote: Next year if we don't implement some form of Secure Boot support, the majority of Fedora users will not be able to install Fedora on new machines. Nonsense. They will be able to install it very easily, they just need to set a single boolean in their BIOS setup from Enabled to Disabled. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: no device ever becomes pluggable
On Fri, 01.06.12 16:25, Thomas Sailer (sai...@sailer.dynip.lugs.ch) wrote: I've upgraded a few machines to Fedora 17. One of them does not boot anymore. No device ever becomes plugged, thus systemd eventually times out waiting for the disk device (dev-sda1.device) and drops into the emergency shell. The device is there and accessible; udevadm trigger --type=devices --action==add does generate add events (as seen by udevmonitor) Strangely, though, none of the devices have a sysfs path; also, I only have the two disk devices mentioned in fstab, while on working machines I have many more. Can somebody give me a hint on what goes wrong, or on how to debug this further? Does udev properly start up? Do you see the systemd tag in the output of udevadm info -qall -p/sys/class/block/sda1? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Peter Jones wrote: Nothing is being swept under the rug here. You have the same access to the mailing list as I do. We're looking for ideas, and we're putting forth a plan that we're willing to implement. If you can come up with a better idea, that would be wonderful. The better idea is the obvious one: Just have your users disable the crappy feature in their firmware. (It's required to be optional even my M$.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 11:44:12AM -0400, Gerry Reno wrote: Well, I don't have any workloads that are doing high-speed create/remove of file in /tmp. And I don't think most people have any of those types of workloads either. I do, but ext4 handles my workload marvelously. For high-speed create/remove, /tmp appears as though it were a tmpfs without any of the drawbacks. The details of performance probably depend on each individual workload, but it would be nice to see evidence that tmpfs is really a noticeable benefit for a variety of workloads. Wouldn't it make sense that people with those types of workloads could enable /tmp on tmpfs? Rather than making it the default for everyone. That seems like a very reasonable approach, and if tmpfs turns out to be an obvious improvement for most users, then the default could be reconsidered in the future. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 11:30 AM, Gerry Reno wrote: The better solution would be for users for want SecureBoot to have to set it in the BIOS. It should be disabled by default. I do not disagree with you. Microsoft does. They have the influence over the hardware OEMs. We do not. They are forcing the OEMs to enable it by default. Feel free to tell your OEM vendor to disable it by default. They will not get that hardware Windows 8 Certified, won't be able to OEM preload Windows 8 on it, if they disable it by default. Who do you think they are going to go with at the end of the day? Now, let us operate on the assumption that SecureBoot is enabled by default, and that the majority of PCs are going to come with Windows 8 pre-installed. Do we want to support dual-booting with Windows 8? Microsoft describes SecureBoot enablement as Required for Windows 8 client [1]? What does that mean? We're not sure. At best, it means that BitLocker isn't going to work, at worst, big chunks of Windows 8 functionality will simply refuse to function until you turn SecureBoot back on. Microsoft isn't even planning on supporting dual-booting of Windows 7 and Windows 8: If you are dual booting, it depends on whether you are booting into another trusted operating system, van der Hoeven said. One discussion we are having is…[with] this first firmware OK boot manager OK handshake, you can't have a version of that that works with Windows 7. Windows 7 doesn't have the ability to check firmware. The firmware can check and make sure it is assigned a Windows 7 boot loader. Truly, right now today, if you want to have secure boot and you want to dual boot Windows 8 and Windows 7, you need to turn secure boot off in firmware. We are thinking about having a way that you can go ahead and make that work, but that's not POR [plan of record] today. [2] So, if we want to be able to provide a dual-boot configuration with Windows 8 (fully functional) and Fedora, how do we do it? Matthew has come up with a way. And if you don't care about dual-booting or SecureBoot, turn it off in the UEFI Firmware, and Fedora continues to work just as it did before. It's not an all-or-nothing approach. But I think it is short-sighted (and arrogant of us) to simply say to people who have no idea what UEFI stands for, Hey, this Fedora isn't for you, go find someone smart enough to help you. We include wireless device firmware even though it isn't free. And we don't like doing that, but it is the only way to get wireless support out of the box in Fedora. We're proposing providing a signed bootloader to enable Fedora to run in SecureBoot environments, even though it is immensely distasteful and questionably non-free. And we don't like doing that, but it is the only way we've come up with to get Fedora support out of the box on the next generation of hardware. If you can come up with a better way to boot Fedora on SecureBoot enabled hardware, we're all listening. ~tom == Fedora Project [1]: http://video.ch9.ms/build/2011/slides/HW-457T_van_der_Hoeven.pptx [2]: http://redmondmag.com/articles/2011/09/23/windows-8-dual-boot-possible-if-secure-boot-disabled.aspx -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:07 PM, Kevin Kofler wrote: Peter Jones wrote: Next year if we don't implement some form of Secure Boot support, the majority of Fedora users will not be able to install Fedora on new machines. Nonsense. They will be able to install it very easily, they just need to set a single boolean in their BIOS setup from Enabled to Disabled. Kevin Kofler And what happens to all the people who now dual-boot both Linux and Windows. How can you boot Windows w/SecureBoot and Linux w/o SecureBoot? . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Peter Jones wrote: On 05/31/2012 11:47 AM, Gregory Maxwell wrote: Is this all set in stone? No. We've spent some time thinking about all of this and are happy that we can implement it in the Fedora 18 timescale, but there's always the possibility that we've missed something or that a new idea will come up. If we can increase user freedom without making awful compromises somewhere else then we'll do it. This, I believe, is Matthew's way of saying that this is not all set in stone, and that we'd encourage you to come up with better ideas because we don't like this all that much. But why are you making this decision in the first place? This: 1. is a technical decision which affects the entirety of Fedora, and thus MUST go through a FESCo vote to be implemented, AND 2. affects the core values of Fedora, and thus MUST go through a Board vote to be implemented. It is not acceptable that the kernel and GRUB maintainers are trying to sneak this in through the backdoor with no mandate whatsoever from our governance structure. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote: Once upon a time, Reindl Harald h.rei...@thelounge.net said: thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and still work exactly as before (if not, that's a bug and should be treated as such). Chris, the problem is that now you have to add a /tmp filesystem, before /tmp was just a normal directory in root. It means that for fedora 18 upward but not for any other you now have to remember to go and change this default, because honestly /tmp in RAM for a virtual machine is just stupid if you end up using the swap file (btw I disable the swap on my machine often exactly to avoid having the machine trashing and using swap, when I really do not need it to). It may be a good idea for beefy single user laptops but for anything else it is probably more a regression than help as moving stuff from a normal file system to swap is just going to add memory pressure to the kernel and nothing else. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
I'm going to chime in once to add my thoughts... It's already way too late for me to influence the decision (first I heard of it is it's decided) so my only recourse is to add it to the long list of things I have to undo after installing Fedora. Sorry guys, this feature sucks. +1 on this feature sucks. Perhaps not for the same reasons. It's mostly for this one: And how is a random user supposed to know this? I think any time we make a fundamental change without making the user aware of this change and CHOOSING it, we have failed the user. How to fix this? I don't know, but perhaps... * Install should ask the user what they want. Since /tmp needs to be set up early, it needs to be done in initrd anyway. * some post-install GUI/TUI that says the following systematic changes are now available, please decide if you want them * other ideas A note from the About Fedora web page: We also believe in empowering others to . . . These choices are being made without empowering the users at all, since the changes happen without warning them, advising them, or letting them choose beforehand. IMHO this is the wrong way to do it. It seems to me this is part of a larger pattern: Fedora (or upstream) announces that some major change has been decided. There is a heated debate over whether it was a good idea or not. Nothing changes. Is this the new Fedora process? Force change on users then ignore their complaints? That seems to be my Fedora-user experience. Also, anyone who says they should read the documentation is delusional. They don't read it. So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls for everything else they do. My system is already maxxed out on RAM, I can't buy any more, and *yes* I need that RAM to be process RAM: total used free sharedbuffers cached Mem: 24739484 198151804924304 046007521428024 -/+ buffers/cache: 13786404 10953080 Swap: 2056312 8160721240240 With /tmp in RAM, it's not flushed at _boot_, but at _shutdown_ Losing /tmp on system crashes makes it harder to diagnose them, if there's information in /tmp relevent to the crash. There have been *lots* of time I've gone digging through /tmp looking for some interim file that turned out to be not so temporary. Just add the space that you would have used for /tmp to your swap. My /tmp (/) is 1.2TB (It will be 3TB after this weekend's upgrade). It's unrealistic to add that much swap. Yes, I've had times when I need lots of /tmp space, and I don't want to flush my I/O buffers or running programs to get it. I/O buffers are more important to me than /tmp speed. Has anyone even compared the performance of tmpfs-on-swap vs tmp-on-ext? I'm contemplating *removing* my swap because the system slows to a crawl anytime swap is needed. If tmp is on swap, how is process performance affected? The *default* limit for tmpfs is half of physical RAM I.e. the default limit on tmpfs is to make half your RAM unavailable to programs and buffers. Given how bloated software is becoming (Fedora is no exception), this is a step backwards. In conclusion, /tmp on tmpfs is a non-starter for me, and will be changed on my systems as soon as possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Adam Jackson wrote: False. Quoting from Matthew's original post: A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code. Removing the M$ key is not viable because the firmware on some peripheral hardware will be signed only with the M$ key. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, 01.06.12 16:19, Richard W.M. Jones (rjo...@redhat.com) wrote: On Fri, Jun 01, 2012 at 11:05:26AM -0400, Gregory Maxwell wrote: On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno gr...@verizon.net wrote: So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls for everything else they do. That's crazy. Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap. The *default* limit for tmpfs is half of physical RAM (swap is not counted). So *if* tmp-on-tmpfs is left at the defaults then increasing physical RAM might be necessary. I haven't bothered to look at how tmp-on-tmpfs is implemented in systemd though. I think most folks here really misunderstand what tmpfs is. It's not actually strictly RAM that is used for it, it's *pageable* memory after all. tmpfs is basically RAM preferred, and swap it if we are under pressure. ext3 otoh means must be on disk in the end, but cache in RAM as much as you want. The difference here is hence not really whether things go to disk eventually or not, or whether this takes away precious RAM, because both use disk and both can use RAM. The difference is that the kernel is relieved from the requirement to guarantee integrity on disk, and to write everything to disk ultimately at all if it doesn't otherwise need to. And that's what makes things a bit faster, and reduces general IO load and wakeups. Beyond that it's also kind of nice that this way stuff from /tmp is allocated from a different pool as the rest of the OS so that we can easily apply different limits, but that's just a nice side benefit. I think most of the noise in this flame thread is due to a misunderstanding how modern memory management works and the assumption that having an explicit size limit on /tmp was a bad thing, even though it actually is a good thing... In fact, we need much stronger limits than what tmpfs currently provides: per-user limits on the usage of /tmp. But that's something for the future... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, 01 Jun 2012 18:13:32 +0200 Kevin Kofler kevin.kof...@chello.at wrote: But why are you making this decision in the first place? What decision ? They explained the issues and problem and came up with what they would recommend we do. No decision has been made. This: 1. is a technical decision which affects the entirety of Fedora, and thus MUST go through a FESCo vote to be implemented, AND 2. affects the core values of Fedora, and thus MUST go through a Board vote to be implemented. It is not acceptable that the kernel and GRUB maintainers are trying to sneak this in through the backdoor with no mandate whatsoever from our governance structure. I honestly don't know what to say to you here... did you bother to actually read the post? There's no sneaking, no decision, this is just bringing the issue up for feedback. There will be a feature for FESCo, there will be voting, all that stuff. Perhaps someone will come up with a better solution by then. Attacking them for this as sneak this in through the backdoor is insulting. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, Jun 1, 2012 at 11:09 AM, Reindl Harald h.rei...@thelounge.net wrote: well designed machines do NOT swap and have not alligend swap at all - in the case of virtualization you MUST NOT enforce swapping if you really like perofrmance I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-) The dogmatic 'swap is bad for performance' is justified only because writing/reading a slow disk is bad for performance. Tmpfs helps your system avoid disk i/o by giving your system more flexibility in how it manages all of the available temporary space. It's something that people who are very concerned with swap impact on performance should appreciate greatly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Debarshi Ray wrote: By the way, I am assuming that you know that one can't modify Firefox and redistribute it as Firefox without certification. I've been pointing out this issue in several threads. That's exactly why Fedora should finally follow Debian's lead and just rename Firefox. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:10 PM, Gerry Reno wrote: On 06/01/2012 12:07 PM, Kevin Kofler wrote: Peter Jones wrote: Next year if we don't implement some form of Secure Boot support, the majority of Fedora users will not be able to install Fedora on new machines. Nonsense. They will be able to install it very easily, they just need to set a single boolean in their BIOS setup from Enabled to Disabled. Kevin Kofler And what happens to all the people who now dual-boot both Linux and Windows. How can you boot Windows w/SecureBoot and Linux w/o SecureBoot? . How are you going to dual-boot: Windows-8 and Windows-7 Windows-8 and Windows-XP Windows-8 and Windows 2008 Server Windows-8 and Fedora 16 Windows-8 and Fedora 17 Windows-8 and Fedora 18 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:30 PM, Kevin Kofler wrote: Debarshi Ray wrote: By the way, I am assuming that you know that one can't modify Firefox and redistribute it as Firefox without certification. I've been pointing out this issue in several threads. That's exactly why Fedora should finally follow Debian's lead and just rename Firefox. Kevin Kofler It's not going to matter b/c Chrome is eating Firefox lunch as far as market share. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Peter Jones wrote: I can see the loss of freedom, and I find it unfortunate, but despite what you've said above, you *are* distorting it. There's nothing you won't be able to do that you could do before. Doing it the same way will be harder than it was. Then why are we not just requiring those steps from everyone? Steps: 1. Disable Secure Boot (link to FSF explanation on what it really is) 2. Install Fedora Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
2012/6/2 Gregory Maxwell gmaxw...@gmail.com: On Fri, Jun 1, 2012 at 11:09 AM, Reindl Harald h.rei...@thelounge.net wrote: well designed machines do NOT swap and have not alligend swap at all - in the case of virtualization you MUST NOT enforce swapping if you really like perofrmance I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-) The dogmatic 'swap is bad for performance' is justified only because writing/reading a slow disk is bad for performance. Tmpfs helps your system avoid disk i/o by giving your system more flexibility in how it manages all of the available temporary space. It's something that people who are very concerned with swap impact on performance should appreciate greatly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Is all this discussion about performance, optimization and memory management based on some benchmarks as well, or it is only a feels like flame? -- Guido Grazioli guido.grazi...@gmail.com Via Parri 11 48011 - Alfonsine (RA) (Italy) 3 Baltic Circuit - 3030 Point Cook - VIC (Australia) Mobile: +39 347 1017202 (10-18 GMT+12) Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278 Linked in: http://www.linkedin.com/in/guidograzioli -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:10 PM, Gerry Reno wrote: On 06/01/2012 12:07 PM, Kevin Kofler wrote: Peter Jones wrote: Next year if we don't implement some form of Secure Boot support, the majority of Fedora users will not be able to install Fedora on new machines. Nonsense. They will be able to install it very easily, they just need to set a single boolean in their BIOS setup from Enabled to Disabled. Kevin Kofler And what happens to all the people who now dual-boot both Linux and Windows. How can you boot Windows w/SecureBoot and Linux w/o SecureBoot? . How are you going to dual-boot: Windows-8 and Windows-7 Windows-8 and Windows-XP Windows-8 and Windows 2008 Server Windows-8 and Fedora 16 Windows-8 and Fedora 17 Windows-8 and Fedora 18 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
By the way, I am assuming that you know that one can't modify Firefox and redistribute it as Firefox without certification. I've been pointing out this issue in several threads. That's exactly why Fedora should finally follow Debian's lead and just rename Firefox. Cool. Why not? But then, you also know that trademarks have no bearing on software freedom. Right? ;-) Happy hacking, Debarshi -- KR is like the Bible. The fervent read it from end to end, the religious keep a copy. -- Arjun Shankar pgpXt4GEE8zCj.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Gerry Reno wrote: How are you going to dual-boot: Windows-8 and Windows-7 Windows-8 and Windows-XP Windows-8 and Windows 2008 Server Windows-8 and Fedora 16 Windows-8 and Fedora 17 Windows-8 and Fedora 18 You can't without changing the settings each time (or cracking Window$ 8 to remove the Secure Boot requirement, if such a patch comes out). But that's M$'s fault. As you already pointed out, it also affects multi-boots of different versions of their own OS. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, Jun 01, 2012 at 06:16:37PM +0200, Kevin Kofler wrote: Adam Jackson wrote: False. Quoting from Matthew's original post: A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code. Removing the M$ key is not viable because the firmware on some peripheral hardware will be signed only with the M$ key. It may be a little more awkward for desktops because you may have to handle the Microsoft-signed UEFI drivers on your graphics and network cards, but this is also solvable. I'm looking at ways to implement a tool to allow you to automatically whitelist the installed drivers. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Fri, 2012-06-01 at 13:18 +0300, Panu Matilainen wrote: On 05/31/2012 10:24 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:08 -0400, Neal Becker wrote: But we can, and should, at least try to make our systems tolerant of failures. Just because we can't test everything. Defensive programming. Sure. As someone else said, though, that's an issue in rpm if anywhere... Dunno what kind of failures you're referring to here (not saying rpm doesn't have any, just that it's not clear to me in this context), but Read back in the thread. The specific 'disaster' that triggered the thread initially is described thus by the reporter: It seems to have all gone wrong when cpio failed, because a python package had been installed using pip into the (default) system dirs. The conflict IIRC happens because pip installs a dir where cpio expects a file (or vice-versa). AFAIK that's at the rpm level, if we're talking cpio failure. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:45 PM, Matthew Garrett wrote: On Fri, Jun 01, 2012 at 06:16:37PM +0200, Kevin Kofler wrote: Adam Jackson wrote: False. Quoting from Matthew's original post: A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code. Removing the M$ key is not viable because the firmware on some peripheral hardware will be signed only with the M$ key. It may be a little more awkward for desktops because you may have to handle the Microsoft-signed UEFI drivers on your graphics and network cards, but this is also solvable. I'm looking at ways to implement a tool to allow you to automatically whitelist the installed drivers. We are all, Microsoft included, headed for signature-HELL. This is going to gum up the entire x86 hardware ecosystem to such a point and Microsoft will rue the day they ever dreamt up this nonsense. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
