Re: Xfce 4.10pre1 in rawhide
On Sun, Apr 1, 2012 at 11:12 PM, Kevin Fenzi ke...@scrye.com wrote: greetings. Xfce 4.10pre1 is out... and I am going to look at landing it in rawhide in the next few days. Hopefully there won't be too much disruption caused by this (it's 17 packages), just wanted to give rawhide Xfce users a heads up. Also, any comments, help, edits with the Xfce 4.10 feature page are most welcome: https://fedoraproject.org/wiki/Features/Xfce-4.10 kevin Hi, Any chance of building a personal repository for F17 or better yet, F16? - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Xfce 4.10pre1 in rawhide
On 03/04/12 07:52, Gilboa Davara wrote: Any chance of building a personal repository for F17 or better yet, F16? - Gilboa https://lists.fedoraproject.org/pipermail/xfce/2012-April/001082.html -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Xfce 4.10pre1 in rawhide
On Tue, Apr 3, 2012 at 9:55 AM, Frank Murphy frankl...@gmail.com wrote: On 03/04/12 07:52, Gilboa Davara wrote: Any chance of building a personal repository for F17 or better yet, F16? - Gilboa https://lists.fedoraproject.org/pipermail/xfce/2012-April/001082.html The feature page doesn't include any information about F17 or F18, hence my question. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On Tue, Apr 3, 2012 at 3:28 AM, Brian Wheeler bdwhe...@indiana.edu wrote: I can't say that as a user (and sysadmin) I'm really thrilled with this. /tmp doesn't go away on reboots now so this is a biggish change from my point of view. That's what /tmp has always meant to be i.e a temporary filesystem that is not persistent across reboot. Relying on that has always been wrong it is perfectly fine to do delete everything in /tmp on reboot. There are a lot of places to store files that survive a reboot so not seeing what your problem here is. Is there a reason why a symlink from /tmp - /var/tmp and leaving /var/tmp on a real disk isn't sufficient for whatever is trying to be solved here? That's broken /tmp should be cleaned up after reboots while /var/tmp should *not. So mixing them up is a bad idea. I don't really get why people make so much fuss about a non issue really. 99,99% of the users won't even notice that anything changed at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Tue, Apr 3, 2012 at 5:10 AM, Kevin Kofler kevin.kof...@chello.at wrote: Richard W.M. Jones wrote: Actually I think this is a good feature, but ... I'm unsure about whether this makes sense for new installs or not, but I feel my objection in https://fedoraproject.org/wiki/Talk:Features/tmp-on-tmpfs was not taken into account at all. :-/ Forcing this change on upgrades will leave users with wasted disk space they cannot easily reclaim. (For us technical users, reclaiming it will be complicated, for non-technical users, it will be impossible.) We could just make anaconda remove everything in /tmp ... done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Xfce 4.10pre1 in rawhide
On 03/04/12 08:13, Gilboa Davara wrote: On Tue, Apr 3, 2012 at 9:55 AM, Frank Murphyfrankl...@gmail.com wrote: On 03/04/12 07:52, Gilboa Davara wrote: Any chance of building a personal repository for F17 or better yet, F16? - Gilboa https://lists.fedoraproject.org/pipermail/xfce/2012-April/001082.html The feature page doesn't include any information about F17 or F18, hence my question. - Gilboa Hence my reply. -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 03:10 AM, Brendan Conoboy wrote: As long as the RE and QE requirements are similarly defined that's fine. It would be good to get a clarification from fesco what they are referring to when they speak of QE ( Depending on it's meaning it might fall under the QA community ) and what they think those requirements are... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 03:10 AM, Brendan Conoboy wrote: Let's make the list exhaustive; there needs to be a path to sure success. This means establishing a complete procedure where when an SA formally applies to become PA, acceptance means there is a definitive set of steps needed to get there. This is one of the major reasons for developing these criteria. Put another way: FESCo and affected groups should have the ability to review whether or not the SA has in-fact fulfilled the requirements for PA, as agreed to by all parties at the time of application. If those requirements are deemed to have been met, promotion is automatic. There could be a deadline on application acceptance: EG, 12 months from acceptance of application to fulfillment of criteria. This protects against criteria becoming stale. This sound like the most reasonable approach. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
Daniel J Walsh wrote: ... I have been running with a tmpfs /tmp for years, without a problem. I have found the having /tmp be anything else that a tmpfs has caused me pain over the years with mislabeled files or files with the wrong UID. Change to use a confined user or change the UID of a user suddenly X will not allow you to login, reboot does not fix the problem. With tmpfs I get a nice clean /tmp on every boot. I too have been pointing TMPDIR at a tmpfs directory (per-shell-distinct, even). The per-shell-distinct bit has exposed a few problems, where tools have expected $TMPDIR in one shell to be the same as $TMPDIR in another one, but nothing insurmountable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
Brendan Conoboy wrote: If those requirements are deemed to have been met, promotion is automatic. I still don't agree that this approach makes any sense whatsoever. Promotion must be an exceptional event decided on a case-by-case basis or we may end up with an unmaintainable skyrocketing of primary architectures. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Xfce 4.10pre1 in rawhide
On Tue, Apr 3, 2012 at 10:31 AM, Frank Murphy frankl...@gmail.com wrote: Hence my reply. *Sigh* - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Xfce 4.10pre1 in rawhide
On Tue, Apr 3, 2012 at 12:50 PM, Gilboa Davara gilb...@gmail.com wrote: On Tue, Apr 3, 2012 at 10:31 AM, Frank Murphy frankl...@gmail.com wrote: Hence my reply. *Sigh* Then better look here: http://lists.fedoraproject.org/pipermail/xfce/2012-April/001082.html :) Greetings, Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-17 Branched report: 20120403 changes
Compose started at Tue Apr 3 08:15:09 UTC 2012 Broken deps for x86_64 -- [HippoDraw] HippoDraw-devel-1.21.3-2.fc17.i686 requires python-numarray HippoDraw-devel-1.21.3-2.fc17.x86_64 requires python-numarray HippoDraw-python-1.21.3-2.fc17.x86_64 requires python-numarray [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.1-5.fc17.noarch requires ruby-nokogiri [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [catfish] catfish-engines-0.3.2-4.fc17.1.noarch requires pinot [comoonics-cdsl-py] comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py [comoonics-cluster-py] comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py [contextkit] contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) [converseen] converseen-0.4.9-3.fc17.x86_64 requires libMagickWand.so.5()(64bit) converseen-0.4.9-3.fc17.x86_64 requires libMagickCore.so.5()(64bit) converseen-0.4.9-3.fc17.x86_64 requires libMagick++.so.5()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [eruby] eruby-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) eruby-libs-1.0.5-17.fc17.i686 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.i686 requires libruby.so.1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gearmand] gearmand-0.23-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) gearmand-0.23-2.fc17.x86_64 requires libmemcached.so.8()(64bit) gearmand-0.23-2.fc17.x86_64 requires libboost_program_options-mt.so.1.47.0()(64bit) [genius] genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) [gnome-phone-manager] gnome-phone-manager-0.66-9.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gnome-user-share] gnome-user-share-3.0.1-3.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [gscribble] gscribble-0.1.2-2.fc17.noarch requires gnome-python2-gtkhtml2 [i3] i3-4.0.1-2.fc17.x86_64 requires libxcb-property.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-keysyms.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-icccm.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-event.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-aux.so.0()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-atom.so.1()(64bit) [ibus-fep] ibus-fep-1.4.3-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-gucharmap] ibus-gucharmap-1.4.0-3.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-panel-extensions] ibus-panel-extensions-1.4.99.20111207-1.fc17.i686 requires libibus-1.0.so.0 ibus-panel-extensions-1.4.99.20111207-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-unikey] ibus-unikey-0.6.1-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [jboss-jaxrpc-1.1-api] jboss-jaxrpc-1.1-api-1.0.1-0.1.20120309gita3c227.fc17.noarch requires jboss-servlet-3.0-api [kazehakase] kazehakase-ruby-0.5.8-11.svn3873_trunk.fc17.x86_64 requires ruby(abi) = 0:1.8 kazehakase-ruby-0.5.8-11.svn3873_trunk.fc17.x86_64 requires libruby.so.1.8()(64bit) [libprelude] 1:libprelude-ruby-1.0.0-11.fc17.x86_64 requires ruby(abi) = 0:1.8 1:libprelude-ruby-1.0.0-11.fc17.x86_64 requires libruby.so.1.8()(64bit) [libteam] libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-route-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-nf-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-genl-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-cli-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.x86_64
Re: httpd 2.4 is coming, RFC on module packaging draft
On 04/02/2012 09:08 PM, Miloslav Trmač wrote: 2012/3/27 Jóhann B. Guðmundsson johan...@gmail.com: On 03/27/2012 05:15 PM, Kevin Kofler wrote: I assume that that mod_access_compat module only requires a few bytes, so I don't see why it should not be loaded by default forever (or at least as long as upstream supports it, which hopefully will be for the whole 2.4 cycle). Few bytes for mod_access_compat here, few bytes for something else there I suppose this needs repeating from time to time. One byte of disk space costs .008065817067$ on the best-selling hard drive around here. Even if there were 100 million Fedora users (which is a huge overestimate AFAIK), that is $0.008 for all Fedora users together. Compare to a tens of minutes, or hours, per affected user that needs to update their system. Disk space at this scale just cannot be a reason to drop legacy interfaces. (There might be other arguments, such as maintenance manpower.) Of course, web app packages in Fedora itself SHOULD be updated to the new directives, but that's not a reason to gratuitously break the old ones. It's my experience that things dont seem to get fixed unless they are broken Is that another way of saying that only broken things need fixing? :) Mirek Upstream apparently wants to establish a new interface for this so I think it would be a good idea to promote this too if possible. Is there a way to only pull in mod_access_compat only on updates but not on new installs? That would be the best option I think as it would not break existing installations that get updated but allows new setups to either not have to deal with the legacy stuff at all or at least see that there are some changes going on there. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Xfce 4.10pre1 in rawhide
On 03/04/12 11:57, Thomas Spura wrote: On Tue, Apr 3, 2012 at 12:50 PM, Gilboa Davaragilb...@gmail.com wrote: On Tue, Apr 3, 2012 at 10:31 AM, Frank Murphyfrankl...@gmail.com wrote: Hence my reply. *Sigh* Then better look here: http://lists.fedoraproject.org/pipermail/xfce/2012-April/001082.html :) Greetings, Tom If he didn't click the link, I supplied. The exact same link as your The Xfce list being sort of fundamental to keep up with Fedora Xfce. -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com wrote: All builds must occur on Fedora-maintained build servers. FYI, this will require an additional koji-hub for each architecture trying to move to PA. Generally agree, though. No. The additional hub is only needed while an arch is secondary. Once it is PA it is driven from the single koji hub. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves b...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 08:10 AM, Joel Rees wrote: On Tue, Apr 3, 2012 at 3:27 PM, Tim ignored_mail...@yahoo.com.au wrote: s/some/a lot of/ if you set it up right. It can still do a fair amount of nasty stuff. xhost local:subuser-id; sudo -u subuser-id does pretty well with current applications. You're allowing the local sandbox user to connect to the local X server so any process running in one of your sandboxes can start a connection to X and start looking for vulnerabilities to exploit. Of which X11 still has its share, we are told. Humor me. Does running firefox this way, as a different user on the same machine, increase risks, as compared to running firefox as the user you are logged in as? If so, how? Due to the elevated privilege with which X runs this could include privilege escalations. Okay, so why doesn't Fedora drop privileges on Xorg like a certain BSD does? There have been vulnerabilities of this kind in the past that allowed an attacker to quickly gain a root shell given the ability to connect to the X server. Well, sure. That's going to happen when you run a server as root. But does it open holes to run the application accessing X as a different user? ergo, holes that wouldn't be open when running the same application as the user you logged in as? Now, if I'm going to my bank site, I do log out and log in as a different user, just to be extra safe. Now, I want to make it clear that I recognize that, if the bad guys have succeeded in taking over the bank site, restricting my internet banking access to an account that I do nothing else with doesn't protect me, relative to that bank. It may keep up some speed bumps and low walls relative to attacks on my machine, of course. I think you'd be better off taking a look at Daniel Walsh's blog posts on confining X applications with the SELinux sandbox. The first post introduces and explains the general sandbox concept: I am familiar with the sandbox principle, in several versions, thank you. Not that one more point of view or version ever hurt. http://danwalsh.livejournal.com/28545.html This blog could help me figure out SELinux's ACL tools, which, if I continue to use Fedora, it looks like I'll have to learn to use. In self-defense, if for no other reason. And the follow up looks at extending this to untrusted X applications using a temporary xguest account (with dynamic $HOME and $TMP) and the Xephyr X-on-X server to provide much stronger separation between the sandbox and the rest of the system: http://danwalsh.livejournal.com/31146.html I notice that he is using mount-over tricks to augment the protections. Fancy or funky? I'll have to re-read that when I have time. Fedora already provides contexts to use with the sandbox such as sandbox_x_t, sandbox_web_t, sandbox_net_t etc. depending on the particular resources you want to allow the sandbox to access. You know, one of the problems with ACLs (and capabilities) is getting them set up right. And you know how it ends up? Well, as you say, and as Walsh acknowledges, The post discusses future improvements to simplify retrieving files from the sandbox when the application exits but I'm not sure of the current status of that work. I've been trying to avoid what I'm sure amounts to blasphemy in the eyes of some on these lists, but I am not particularly fond of SELinux. Way too many convolutions to hide bugs in. If X11 must be assumed to have bugs, so much more, the more recent and more complicated SELinux, especially in the patterns by which the tools to set policy are run. I'm going to prefer to trust tools I can understand. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Tue, 2012-04-03 at 05:10 +0200, Kevin Kofler wrote: Richard W.M. Jones wrote: Actually I think this is a good feature, but ... I'm unsure about whether this makes sense for new installs or not, but I feel my objection in https://fedoraproject.org/wiki/Talk:Features/tmp-on-tmpfs was not taken into account at all. :-/ Forcing this change on upgrades will leave users with wasted disk space they cannot easily reclaim. (For us technical users, reclaiming it will be complicated, for non-technical users, it will be impossible.) Can't this be easily resolved by renaming /tmp -/old-tmp at upgrade time ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 809427] perl-DateTime-TimeZone-1.46 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=809427 --- Comment #1 from Fedora Update System upda...@fedoraproject.org 2012-04-03 08:44:32 EDT --- perl-DateTime-TimeZone-1.46-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.46-1.fc16 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
[Bug 809427] perl-DateTime-TimeZone-1.46 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=809427 --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2012-04-03 08:45:22 EDT --- perl-DateTime-TimeZone-1.46-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.46-1.fc15 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
[Bug 809427] perl-DateTime-TimeZone-1.46 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=809427 --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2012-04-03 08:45:31 EDT --- perl-DateTime-TimeZone-1.46-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.46-1.fc17 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 01:15 PM, Joel Rees wrote: On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves b...@redhat.com wrote: You're allowing the local sandbox user to connect to the local X server so any process running in one of your sandboxes can start a connection to X and start looking for vulnerabilities to exploit. Of which X11 still has its share, we are told. Humor me. Does running firefox this way, as a different user on the same machine, increase risks, as compared to running firefox as the user you are logged in as? If so, how? If the reason you are running the separate browser is to visit sites that you do not trust sufficiently to visit from your main user session then yes because the browser (and in turn X) is now exposed to those sites. If your choice is or do nothing and run them in the normal session then of course there is no difference. Due to the elevated privilege with which X runs this could include privilege escalations. Okay, so why doesn't Fedora drop privileges on Xorg like a certain BSD does? I'm no X expert but historically the X server needed root privileges to use vm86 mode to interact with the video BIOS and to access the IO ports for the card so KMS for all drivers at least is required to be able to support this. OpenBSD modifies the Xorg source to allow privilege separation and this work has not made its way upstream (which is a problem for Fedora to include it). There are also legitimate questions about how useful all of this is; although OpenBSD provides their aperture driver to minimize the address space the X server can access Theo de Raadt has said this is just the best we can do. OpenBSD also provides a vesafb driver that permits an unprivileged X server with no aperture driver but acceleration is not supported and performance suffers as a consequence. Well, sure. That's going to happen when you run a server as root. But does it open holes to run the application accessing X as a different user? ergo, holes that wouldn't be open when running the same application as the user you logged in as? Yes; if you don't trust those applications or the data (sites) they operate on then you have a possible avenue for attacks. This is the point of sandbox -X. This blog could help me figure out SELinux's ACL tools, which, if I continue to use Fedora, it looks like I'll have to learn to use. In self-defense, if for no other reason. SELinux doesn't provide ACLs (Linux ACLs are primarily a file system feature that's independent of other security frameworks in use). I notice that he is using mount-over tricks to augment the protections. Fancy or funky? I'll have to re-read that when I have time. Just sane. Linux has supported per-process mount namespaces for a very long time. They provide far stronger isolation than other methods. They're also worth getting to know as they are useful for many other tasks too. You know, one of the problems with ACLs (and capabilities) is getting them set up right. And you know how it ends up? Well, as you say, and as Walsh acknowledges, Use it/don't use it - it's up to you. I've used SELinux sandboxes and I find them very easy to use and considerably less maintenance effort than roll-your-own. YMMV of course but I prefer not to invent my own solutions to security problems when there are off the shelf answers that were developed by people who work on this stuff every day. There's also a tonne of good documentation for SELinux these days from basic administration to troubleshooting and advanced policy development: http://fedoraproject.org/wiki/SELinux I've been trying to avoid what I'm sure amounts to blasphemy in the eyes of some on these lists, but I am not particularly fond of SELinux. Way too many convolutions to hide bugs in. If X11 must be assumed to have bugs, so much more, the more recent and It's been around for well over a decade now and is pretty mature. Bugs still happen but I think they're no more troublesome than bugs in any other complex subsystem these days. The SELinux folks I know are also very responsive and helpful when dealing with user problems. more complicated SELinux, especially in the patterns by which the tools to set policy are run. Not sure which X sources you've looked at but this certainly isn't my impression of the two projects. The xorg-x11 sources weigh in at over 500,000 loc just for the server. Adding libX11 and a few other libraries quickly takes you over 750k. Adding up security/selinux from the kernel sources along with policycoreutils and libselinux you come to about 68,000 (and that's including all the pcu python stuff - without that you can take another 20,000 off). Even if you include the reference policy specs it's less than a quarter million lines. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 5:10 AM, Brendan Conoboy b...@redhat.com wrote: as such there are various expectations that the overall Fedora experience will be consistent over all primary architectures. Can we quantify what the overall experience is that must be consistent? I understand Anaconda installations is considered a part of this... except when it's not for EC2 images. What I'm looking for is These 10 things are partof the Fedora experience- any PA needs to provide at least 7 of them or something like that. All architectures are built from the same SRPMs, so the overall experience is sort of consistent by default. 7/10 is certainly not enough, I'd assume 98% - only a few named exceptions, and the ARM team probably knows what these are better than I do :) This could be construed to mean the secondary architecture will have a comparable 3D support to the primary so that gnome-shell performs comparably, but that's way out of scope I think. In any case, the true requirements start with the bullet list. There must be adequate representation for the architecture on the Fedora infrastructure and release engineering teams. This makes sense, but what is adequate? I think this is left to be decided by the infrastructure and rel-eng teams. The architecture must meet appropriate formal release criteria As long as the release criteria are applicable to the architecture. I actually think this requirement is too strict most of the time - the primary architectures need weeks of bug fixing to meet the release criteria :) I'm not sure about a better way to word it, though. Perhaps this just means that the PA promotion decision would have take place at the same time that the next beta release meets release criteria. This list is not intended to be exhaustive - promotion to primary architecture status will require agreement from the Fedora infrastructure, release engineering, kernel and installer teams and is subject to overall approval by the Fedora Engineering Steering Committee, and additional criteria may be imposed if felt to be necessary. Let's make the list exhaustive; there needs to be a path to sure success. This means establishing a complete procedure where when an SA formally applies to become PA, acceptance means there is a definitive set of steps needed to get there. This is one of the major reasons for developing these criteria. Put another way: FESCo and affected groups should have the ability to review whether or not the SA has in-fact fulfilled the requirements for PA, as agreed to by all parties at the time of application. If those requirements are deemed to have been met, promotion is automatic. AFAICT there is a clear FESCo consensus that the list can not be exhaustive. Essentially, asking for a promise to promote automatically if a checklist is met is equivalent to asking for permission to promote even if the software is known to be broken and/or unfixable. There _are_ unknowns and risks in this process. We can only shift the place where they manifest, and asking for an exhaustive list essentially shifts the risks to Fedora users and other Fedora maintainers. And again, the current discussions didn't suggest that there is any communication breakdown between FESCo and the ARM team, or that FESCo knows much more about ARM than the ARM team. I don't at all expect a situation in which the ARM team thinks everything is working fine and FESCo doesn't. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Install Fedora Button for LiveCD
I was quite depressed how hard it can be for a layman to find a way to install Fedora from LiveCD environment. If you don't recognize the icon in Gnome Shell Overview mode, it can give you quite some work to find it. Since OSS philosophy is if you don't like it, fix it, I did. In the last two days I have created a Gnome Shell extension that puts a button on the top bar that says Install to Hard Drive. It has an icon attached, so it's very visible. The graphics and the text is taken from anaconda's .desktop file, so localization should work OOTB. When you click the button, the installation process starts the same way as if you had run it from the overview. You can see it here: http://kparal.fedorapeople.org/misc/InstallFedoraButton.png What do you think? Better than default? I personally think it's definitely better than default. I'm sure it can be improved in many ways, but this was my first GS extension ever and I'm really lame, so bear with me (patches welcome). The source code is here: http://kparal.fedorapeople.org/misc/InstallFedoraButton.7z How to try out: 1. boot F17 Beta RC2 Live 2. extract the extension to /usr/share/gnome-shell/extensions/ 3. restart gnome-shell (Alt+F2 - r) 4. install gnome-tweak-tool and enable this extension Future steps if people like it: a) find out how to include this just on the livecd, but not on the installed system b) modify gsettings to have this extension automatically enabled c) ask anaconda team to include it into their project and maintain it Comments welcome. Thanks, Kamil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Data-Dump-Streamer/f17] update to 2.33
Summary of changes: 9c1a8c0... update to 2.33 (*) (*) This commit already existed in another branch; no separate mail sent -- 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
File Devel-PatchPerl-0.68.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Devel-PatchPerl: 7d2ba4ae9a3e0f24e196afa63c8ddc20 Devel-PatchPerl-0.68.tar.gz -- 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: /tmp on tmpfs
On 04/02/2012 05:30 PM, M A Young wrote: On Mon, 2 Apr 2012, Lennart Poettering wrote: On Mon, 02.04.12 16:55, Steve Grubb (sgr...@redhat.com) wrote: What about forensics? Any reboot erases information that might have been needed to see what happened during a break in. /tmp is already volatile and cleaned up in regular intervals. The new clean-up on boot is just one tiny bit of additional clean-up. there is a big difference however with files in /tmp being around for 30 days, and the files being cleaned on a reboot, which might be necessary to get the system in a reliable enough state to do any forensics. This also means a big change in user experience as many will be expecting things in /tmp to remain there for a while before being deleted even if the system is restarted or crashes. Michael Young I agree why does this have to be forced on everyone. Admins have the ability to do this now if they want to. -- 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: Feedback on secondary architecute promotion requirements draft
On Mon, Apr 2, 2012 at 10:10 PM, Brendan Conoboy b...@redhat.com wrote: This is feedback vs the current version of the following web page: http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29 FESCo and affected groups should have the ability to review whether or not the SA has in-fact fulfilled the requirements for PA, as agreed to by all parties at the time of application. If those requirements are deemed to have been met, promotion is automatic. I think a lot of the above boils down to providing goals for the SA team while leaving discretion in FESCO's hands. And in that light, I think once requirements are met, promotion should be approved, but certainly not automatic. There could be a deadline on application acceptance: EG, 12 months from acceptance of application to fulfillment of criteria. This protects against criteria becoming stale. I like this idea, modulo the exact time value. If you apply and are approved for F18, and aren't ready until F25, I think all would agree that reassessment is sorely needed. -J -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- 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: httpd 2.4 is coming, RFC on module packaging draft
Le 03/04/2012 13:50, Dennis Jacobfeuerborn a écrit : Is there a way to only pull in mod_access_compat only on updates but not on new installs? That would be the best option I think as it would not break existing installations that get updated but allows new setups to either not have to deal with the legacy stuff at all or at least see that there are some changes going on there. Once again : mod_access_compat is not the solution. mod_access_compat doesn't work as expected, see my other posts in this thread. Remi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer jwbo...@gmail.com wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com wrote: All builds must occur on Fedora-maintained build servers. FYI, this will require an additional koji-hub for each architecture trying to move to PA. Generally agree, though. No. The additional hub is only needed while an arch is secondary. Once it is PA it is driven from the single koji hub. That's my understanding but the bullet reads as if there's going to be a Fedora maintained hub for the secondary arches. At the moment the hubs for the secondary arches are maintained by the secondary arches. So the point needs to be clarified. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On Apr 3, 2012, at 7:26 AM, Kamil Paral wrote: You can see it here: http://kparal.fedorapeople.org/misc/InstallFedoraButton.png What do you think? Better than default? How about Install Fedora since it could be installed to SSD or iSCSI etc. I personally think it's definitely better than default. The problem is nothing shows up on Gnome 3's desktop, even items in the Desktop folder (which is just...it's asinine there's no polite way to say it.) The present behavior is obscure, especially for new users. And the install icon in the activities drawer, or whatever it's called, doesn't have any text description unless the user mouses over. It's like the installer is an easter egg that the user has to go on a hunt for, and hopefully find it before it rots. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
2012/4/3 Miloslav Trmač m...@volny.cz: On Tue, Apr 3, 2012 at 5:10 AM, Brendan Conoboy b...@redhat.com wrote: as such there are various expectations that the overall Fedora experience will be consistent over all primary architectures. Can we quantify what the overall experience is that must be consistent? I understand Anaconda installations is considered a part of this... except when it's not for EC2 images. What I'm looking for is These 10 things are partof the Fedora experience- any PA needs to provide at least 7 of them or something like that. All architectures are built from the same SRPMs, so the overall experience is sort of consistent by default. 7/10 is certainly not enough, I'd assume 98% - only a few named exceptions, and the ARM team probably knows what these are better than I do :) This could be construed to mean the secondary architecture will have a comparable 3D support to the primary so that gnome-shell performs comparably, but that's way out of scope I think. In any case, the true requirements start with the bullet list. It's already been stated that 3D isn't a blocker for PA, but that the needs to be reasonable GUI support similar to that of the mainline project. There must be adequate representation for the architecture on the Fedora infrastructure and release engineering teams. This makes sense, but what is adequate? I think this is left to be decided by the infrastructure and rel-eng teams. Yes. The architecture must meet appropriate formal release criteria As long as the release criteria are applicable to the architecture. I actually think this requirement is too strict most of the time - the primary architectures need weeks of bug fixing to meet the release criteria :) I'm not sure about a better way to word it, though. Perhaps this just means that the PA promotion decision would have take place at the same time that the next beta release meets release criteria. As long as it's reasonable, if it's too strict on primary at the moment that is a completely separate discussion and not really related to this one and is likely very much a matter of opinion :) This list is not intended to be exhaustive - promotion to primary architecture status will require agreement from the Fedora infrastructure, release engineering, kernel and installer teams and is subject to overall approval by the Fedora Engineering Steering Committee, and additional criteria may be imposed if felt to be necessary. Let's make the list exhaustive; there needs to be a path to sure success. This means establishing a complete procedure where when an SA formally applies to become PA, acceptance means there is a definitive set of steps needed to get there. This is one of the major reasons for developing these criteria. Put another way: FESCo and affected groups should have the ability to review whether or not the SA has in-fact fulfilled the requirements for PA, as agreed to by all parties at the time of application. If those requirements are deemed to have been met, promotion is automatic. AFAICT there is a clear FESCo consensus that the list can not be exhaustive. I agree it's hard to make it exhaustive but ultimately it can't be a moving target with extra items added and the goal posts moved every time it's reached. Essentially, asking for a promise to promote automatically if a checklist is met is equivalent to asking for permission to promote even if the software is known to be broken and/or unfixable. We're not asking for that what so ever. What we're asking for is a pre decided and agreed point we need to reach that doesn't keep on moving. Ultimately there's a lot of packages that are broken on x86 mainline at the moment (just look at the list of FTBFS that still exist from the gcc 4.7 mass rebuild) so we're not asking for instant promotion if stuff is known to be broken, it's never been bought up so I'm not sure where you get that idea from. There _are_ unknowns and risks in this process. We can only shift the place where they manifest, and asking for an exhaustive list essentially shifts the risks to Fedora users and other Fedora maintainers. And again, the current discussions didn't suggest that there is any communication breakdown between FESCo and the ARM team, or that FESCo knows much more about ARM than the ARM team. I don't at all expect a situation in which the ARM team thinks everything is working fine and FESCo doesn't. Of course there are unknown risks, there's also unknown risks every time a core package is bumped, or each time infra/rel-eng change something, but there's benefits to those changes as well. Just like that there are unknown risks and possible issues with promotion of a new architecture but there are also known benefits which is ultimately why we've asked FESCo to create these criteria, different people put different benefits to the criteria but ultimately personally I believe it will be a net gain for
[perl-Wx] 0.9906
commit ec7f4f9fb0f91d4370a8a8f3f3109a664e850bd4
Author: Tom Callaway s...@fedoraproject.org
Date: Tue Apr 3 10:28:21 2012 -0400
0.9906
.gitignore |1 +
perl-Wx.spec |6 +-
sources |2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ceb260f..6d9290c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Wx-0.92.tar.gz
/Wx-0.9903.tar.gz
/Wx-0.9904.tar.gz
/Wx-0.9905.tar.gz
+/Wx-0.9906.tar.gz
diff --git a/perl-Wx.spec b/perl-Wx.spec
index 43f2d9e..e10514b 100644
--- a/perl-Wx.spec
+++ b/perl-Wx.spec
@@ -9,7 +9,7 @@
# for i in `grep -r PACKAGE= * | cut -d -f 2 | sed 's|PACKAGE=|perl(|g'
| grep Wx:: | sort -n |uniq`; do printf Provides: $i)\\n; done
Name: perl-Wx
-Version:0.9905
+Version:0.9906
Release:1%{?dist}
Summary:Interface to the wxWidgets cross-platform GUI toolkit
Group: Development/Libraries
@@ -321,6 +321,7 @@ Provides: perl(Wx::URLDataObject)
Provides: perl(Wx::Validator)
Provides: perl(Wx::View)
Provides: perl(Wx::Wave)
+Provides: perl(Wx::WebView)
Provides: perl(Wx::Window)
Provides: perl(Wx::WindowCreateEvent)
Provides: perl(Wx::WindowDC)
@@ -387,6 +388,9 @@ chmod -R u+w $RPM_BUILD_ROOT/*
%{_mandir}/man3/*.3pm*
%changelog
+* Tue Apr 3 2012 Tom Callaway s...@fedoraproject.org - 0.9906-1
+- update to 0.9906
+
* Wed Mar 21 2012 Tom Callaway s...@fedoraproject.org - 0.9905-1
- update to 0.9905
diff --git a/sources b/sources
index 266d560..2b86575 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-757f337a14869a3fdfa8ebd3444159b1 Wx-0.9905.tar.gz
+7f53841be9a9896e2f15d16a549013f9 Wx-0.9906.tar.gz
--
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: Install Fedora Button for LiveCD
On Tue, 2012-04-03 at 09:26 -0400, Kamil Paral wrote: I was quite depressed how hard it can be for a layman to find a way to install Fedora from LiveCD environment. If you don't recognize the icon in Gnome Shell Overview mode, it can give you quite some work to find it. Since OSS philosophy is if you don't like it, fix it, I did. In the last two days I have created a Gnome Shell extension that puts a button on the top bar that says Install to Hard Drive. It has an icon attached, so it's very visible. The graphics and the text is taken from anaconda's .desktop file, so localization should work OOTB. When you click the button, the installation process starts the same way as if you had run it from the overview. You can see it here: http://kparal.fedorapeople.org/misc/InstallFedoraButton.png What do you think? Better than default? I personally think it's definitely better than default. I'm sure it can be improved in many ways, but this was my first GS extension ever and I'm really lame, so bear with me (patches welcome). The source code is here: http://kparal.fedorapeople.org/misc/InstallFedoraButton.7z How to try out: 1. boot F17 Beta RC2 Live 2. extract the extension to /usr/share/gnome-shell/extensions/ 3. restart gnome-shell (Alt+F2 - r) 4. install gnome-tweak-tool and enable this extension Future steps if people like it: a) find out how to include this just on the livecd, but not on the installed system b) modify gsettings to have this extension automatically enabled c) ask anaconda team to include it into their project and maintain it So, we decided for F16 that we don't want to add extensions like that to the shell that we ship on the live cd. It should be the default experience. For the 'make installing obvious' problem, what we really want is to just autostart the installer. Unfortunately, the current live installer does not really work well for that... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
/tmp is a like a litter box. From a user perspective, I'm happy to have it emptied regularly, because clearly the cats don't clean up their own doodles. That one of the cats might think he's deposited something valuable that he'll come back for someday, is hilarious to me, as well as ridiculous. My only concern about it being on tmpfs instead of on disk, is how big it could get, how much memory could be held hostage, until there's a reboot. I'd rather see it be both size and age limited (each item has a decay rate or something), so that it's evacuated more regularly than just between reboots - which could be months. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Xfce 4.10pre1 in rawhide
Yes, I am planning for sure a f17 repo... and possibly a f16 side repo as well. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On Apr 3, 2012, at 7:26 AM, Kamil Paral wrote: You can see it here: http://kparal.fedorapeople.org/misc/InstallFedoraButton.png What do you think? Better than default? How about Install Fedora since it could be installed to SSD or iSCSI etc. I pull that string from default anaconda launcher. If they change it, it will change also in the button. I proposed it here: https://bugzilla.redhat.com/show_bug.cgi?id=809499 The problem is nothing shows up on Gnome 3's desktop, even items in the Desktop folder (which is just...it's asinine there's no polite way to say it.) The present behavior is obscure, especially for new users. And the install icon in the activities drawer, or whatever it's called, Dash doesn't have any text description unless the user mouses over. It's like the installer is an easter egg that the user has to go on a hunt for, and hopefully find it before it rots. Right, that's exactly what annoyed me. Of course other approaches are possible. I could force Shell to display desktop icons and put the launcher there. But then the livecd environment would be substantially different from installed environment and that's a bad approach. The install button can also be put into the user menu in the upper right corner, it's just not as visible there. Overall the button on the top bar was easy enough to implement and also the best idea I was able to come up with. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
So, we decided for F16 that we don't want to add extensions like that to the shell that we ship on the live cd. It should be the default experience. Can't be 100% default, because installer is a slightly different use case, isn't it. For the 'make installing obvious' problem, what we really want is to just autostart the installer. Unfortunately, the current live installer does not really work well for that... If you try to close anaconda, it shuts down the whole machine. A lot of users could assume that they just can't use the livecd environment for standard work, to try it out. Also if you start an application fullscreen, it's not really obvious that don't have to use it. If you don't know Gnome Shell and don't click on the top bar, you won't even know you're in a livecd environment. I think some adjustments are necessary. I wonder, have you looked at Ubuntu? First of all, there are two separate menu items in the CD boot menu, Try without installing and Install ubuntu. Second, if you don't choose any item, this is what you get after boot: http://i.imgur.com/I26vS.png Try Ubuntu will run the default livecd environment, Install Ubuntu will run the installer in fullscreen mode. That seems like great usability solution to me. Not that I would require the same for Fedora. It would be nice, yes, but my small button is definitely easier to implement and serves the purpose as well, I believe. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On 04/03/2012 10:31 AM, Chris Murphy wrote: /tmp is a like a litter box. From a user perspective, I'm happy to have it emptied regularly, because clearly the cats don't clean up their own doodles. That one of the cats might think he's deposited something valuable that he'll come back for someday, is hilarious to me, as well as ridiculous. My only concern about it being on tmpfs instead of on disk, is how big it could get, how much memory could be held hostage, until there's a reboot. I'd rather see it be both size and age limited (each item has a decay rate or something), so that it's evacuated more regularly than just between reboots - which could be months. Indeed. I don't mind the cleaning of /tmp on reboots although I'm going to have to warn my users. I've got two concerns about this change: * The (user|program) has to decide the location for temporary data based on its size. There have been arguments that everyone should have been using /var/tmp for ages but I'm not buying it. I suppose that made sense when there were separate /var and / partitions, but that hasn't been the case _ever_ for me on Linux and its been a long time since I did that on other platforms. * The competition for space between things in /tmp and VM. When someone abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross. Maybe I'm overreacting, but I've not seen a convincing case on why this has to be made the default rather than an opt-in situation. I certainly can't see this being a configuration I'd choose for my servers or any machine which may be memory limited. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
Kamil Paral píše v Út 03. 04. 2012 v 09:26 -0400: I was quite depressed how hard it can be for a layman to find a way to install Fedora from LiveCD environment. If you don't recognize the icon in Gnome Shell Overview mode, it can give you quite some work to find it. Since OSS philosophy is if you don't like it, fix it, I did. In the last two days I have created a Gnome Shell extension that puts a button on the top bar that says Install to Hard Drive. It has an icon attached, so it's very visible. The graphics and the text is taken from anaconda's .desktop file, so localization should work OOTB. When you click the button, the installation process starts the same way as if you had run it from the overview. You can see it here: http://kparal.fedorapeople.org/misc/InstallFedoraButton.png What do you think? Better than default? I personally think it's definitely better than default. I'm sure it can be improved in many ways, but this was my first GS extension ever and I'm really lame, so bear with me (patches welcome). The source code is here: http://kparal.fedorapeople.org/misc/InstallFedoraButton.7z How to try out: 1. boot F17 Beta RC2 Live 2. extract the extension to /usr/share/gnome-shell/extensions/ 3. restart gnome-shell (Alt+F2 - r) 4. install gnome-tweak-tool and enable this extension Future steps if people like it: a) find out how to include this just on the livecd, but not on the installed system b) modify gsettings to have this extension automatically enabled c) ask anaconda team to include it into their project and maintain it Comments welcome. Thanks, Kamil I think this is definitely something we should fix. I don't even remember how many times I've been asked how to install Fedora from the liveCD. The solution proposed by Kamil is definitely better and more obvious than the one we've had so far. If we want to have as default look as possible we might want to change the icon in the dash. Something like adding text in the icon Install Fedora. I know it probably breaks all icon guidelines, but I don't know any picture that would obviously stand for installation. The way it is now is really more like an easter egg or a contest who will find a way to install Fedora first. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/02/2012 11:10 PM, Brendan Conoboy wrote: This is feedback vs the current version of the following web page: http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29 It would be nice if the bullet points were numbers so they could be referenced numerically. Done (but btw it is a wiki - you could easily have done this.) Promoting an architecture to primary architecture status is a significant responsibility. It implies that the port is sufficiently mature that little in the way of further architecture-specific changes or rebuilds will be required, and also that it has enough development effort to avoid it delaying the development of other primary architectures. What is ...enough development effort to avoid...? Perhaps this could be restated for clarity as a development effort is not a unit of measurement. as such there are various expectations that the overall Fedora experience will be consistent over all primary architectures. Can we quantify what the overall experience is that must be consistent? I understand Anaconda installations is considered a part of this... except when it's not for EC2 images. What I'm looking for is These 10 things are partof the Fedora experience- any PA needs to provide at least 7 of them or something like that. I think this whole process is going to work a whole lot better if we *don't* focus on having very precise and all encompassing criteria. General criteria will suit us much better. The process for each of the items needs to be more like: SA Maintainer: Here's what we plan to do to satisfy #3. Comments or concerns? FESCo: Well, tweak $THIS and $THAT, and it's looking pretty good SAM: Okay, well that's a little problematic because $ARCH has a feature that makes $THAT weird. FESCo: Okay, just tweak $THIS then. We're trying to make a general process; being two precise won't help for a couple of reasons. First, it leads to doing something you think is right because of an error in the process document where we didn't consider something. There's no way we're going to get this right thinking about it in abstract, and also no way that everything we come up with while thinking of ARM is necessarily going to apply when the next architecture comes along. So we know we're going to be wrong about some things, and there will be some accidental omissions. That has to be part of the process, and the process has to be built around knowing that. Which leads me to the other reason - it discourages you from talking to us along the way, and encourages you to go away, do something and come back. While that's good in some situations, it's really *not* for this, because it will lead to even more cases where a SAM implements something because of following rules closely instead of what should happen. We need to make the whole process one with continuous feedback, or it's never going to work. So I'd expect that we don't want to specify anything all that precisely - I'd rather you come up with an implementation plan to satisfy each point, and then we (SA Maintainer and FESCo) decide together if it's satisfactory, and later decide that it has or hasn't yet been met, and if not what remedial steps should be taken. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 04:03 AM, Jóhann B. Guðmundsson wrote: On 04/03/2012 03:10 AM, Brendan Conoboy wrote: Let's make the list exhaustive; there needs to be a path to sure success. This means establishing a complete procedure where when an SA formally applies to become PA, acceptance means there is a definitive set of steps needed to get there. This is one of the major reasons for developing these criteria. Put another way: FESCo and affected groups should have the ability to review whether or not the SA has in-fact fulfilled the requirements for PA, as agreed to by all parties at the time of application. If those requirements are deemed to have been met, promotion is automatic. There could be a deadline on application acceptance: EG, 12 months from acceptance of application to fulfillment of criteria. This protects against criteria becoming stale. This sound like the most reasonable approach. I actually have a pretty strong disagreement here. If we need sunset clauses, it means that there's really not enough interaction. Look at it this way - if an arch is following the process to become primary, but during that process actually becomes *less* viable, or for whatever reason farther from being reasonable as a PA, the process needs to be such that that's something people see and discuss. If it doesn't come up, it's because it's completely fallen off the deep end. So I'd much rather just say that an arch that's attempting to transition from secondary to primary needs to regularly keep FESCo and f-d-l informed as to the status than have something like formal sunsetting. If they don't keep us up to date, they have de facto stopped trying. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
Once upon a time, Brian Wheeler bdwhe...@indiana.edu said: * The competition for space between things in /tmp and VM. When someone abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross. First, tmpfs can be swapped. If you are swapping tmpfs files, how is that any worse than having /tmp on a disk? Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case). I've been running with /tmp on tmpfs for several years, including on a number of servers, and I've never had any unusual problem related to it. I typically provision a little more swap on such systems, so that there's some room for spill-over. Also, on servers where there are users with shell access, I'll typically limit the size of /tmp with an option in fstab (the default is RAM/2, which can be larger than I'd like). However, reading the feature page, this would be harder to do, since somebody's irrational fear of /etc/fstab is extending to /tmp. I think that's a bad idea, especially since the proposed feature creates yet another way to mount filesystems (systemd-auto, /etc/fstab, and now a service for /tmp). Really? Two wasn't enough? -- 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: Install Fedora Button for LiveCD
On Apr 3, 2012, at 8:29 AM, Matthias Clasen wrote: So, we decided for F16 that we don't want to add extensions like that to the shell that we ship on the live cd. It should be the default experience. For the 'make installing obvious' problem, what we really want is to just autostart the installer. Unfortunately, the current live installer does not really work well for that... Is it a default experience to autostart apps? If I'm using the LiveCD for troubleshooting, from actual media, do I really want to persistently experience the additional delays resulting from 2-3 minutes of lag while autostarting an installer I have no intention of using? Doesn't this seem like additional hostility to mask over prior user hostile UI? I think the original premise is what needs to be challenged here. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 10:16 AM, Peter Robinson wrote: On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer jwbo...@gmail.com wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com wrote: All builds must occur on Fedora-maintained build servers. FYI, this will require an additional koji-hub for each architecture trying to move to PA. Generally agree, though. No. The additional hub is only needed while an arch is secondary. Once it is PA it is driven from the single koji hub. That's my understanding but the bullet reads as if there's going to be a Fedora maintained hub for the secondary arches. At the moment the hubs for the secondary arches are maintained by the secondary arches. So the point needs to be clarified. I think there are probably 3 steps here, but obviously I don't speak for rel-eng, so I'd like to hear what they have to say. I could be wrong about any of this due to insufficient knowledge of how koji is set up. 1) SA has its own koji hub and builders 2) rel-eng has a staging koji hub for arches under transition, which is really just a temporary thing where we're setting up builders to work with step 3 3) when we decide that it *is* a PA, transition builders from step #2 to the primary koji hub. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 4:31 PM, Peter Jones pjo...@redhat.com wrote: On 04/03/2012 04:03 AM, Jóhann B. Guðmundsson wrote: On 04/03/2012 03:10 AM, Brendan Conoboy wrote: Let's make the list exhaustive; there needs to be a path to sure success. This means establishing a complete procedure where when an SA formally applies to become PA, acceptance means there is a definitive set of steps needed to get there. This is one of the major reasons for developing these criteria. Put another way: FESCo and affected groups should have the ability to review whether or not the SA has in-fact fulfilled the requirements for PA, as agreed to by all parties at the time of application. If those requirements are deemed to have been met, promotion is automatic. There could be a deadline on application acceptance: EG, 12 months from acceptance of application to fulfillment of criteria. This protects against criteria becoming stale. This sound like the most reasonable approach. I actually have a pretty strong disagreement here. If we need sunset clauses, it means that there's really not enough interaction. Look at it this way - if an arch is following the process to become primary, but during that process actually becomes *less* viable, or for whatever reason farther from being reasonable as a PA, the process needs to be such that that's something people see and discuss. If it doesn't come up, it's because it's completely fallen off the deep end. So I'd much rather just say that an arch that's attempting to transition from secondary to primary needs to regularly keep FESCo and f-d-l informed as to the status than have something like formal sunsetting. If they don't keep us up to date, they have de facto stopped trying. I agree, anything that is going to take that length of time is still really a secondary arch. Ultimately with a set of reasonably defined criteria the request shouldn't really be made until the architecture in question is fairly confident that they meet the criteria and then there should be a relatively quick move one way or the other. Obviously there's going to be some time regarding things like infra/rel-eng etc eg for HW procurement if necessary but the overall process side of it should be active. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
Dne 3.4.2012 16:31, Chris Murphy napsal(a): My only concern about it being on tmpfs instead of on disk, is how big it could get, how much memory could be held hostage, until there's a reboot. I'd rather see it be both size and age limited (each item has a decay rate or something), so that it's evacuated more regularly than just between reboots - which could be months. Cleanup of old files is already done, by systemd-tmpfiles. See /usr/lib/tmpfiles.d/tmp.conf. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On Tue, 3 Apr 2012, Chris Adams wrote: Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case). That assumes your system is still functional enough to allow you to do that. In a low memory/high swap situation, which this could easily trigger, logging in and clearing the files could be very slow, and the login process could time out before you get logged in. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
On Tue, Apr 3, 2012 at 10:24 PM, Bryn M. Reeves b...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 01:15 PM, Joel Rees wrote: On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves b...@redhat.com wrote: You're allowing the local sandbox user to connect to the local X server so any process running in one of your sandboxes can start a connection to X and start looking for vulnerabilities to exploit. Of which X11 still has its share, we are told. Humor me. Does running firefox this way, as a different user on the same machine, increase risks, as compared to running firefox as the user you are logged in as? If so, how? If the reason you are running the separate browser is to visit sites that you do not trust sufficiently to visit from your main user session then yes because the browser (and in turn X) is now exposed to those sites. Good point. I don't visit those sites, and it's important for me to mention that. No p0rn, period, and many of the moral reasons are in fact parallels of the technical reasons. Well, sometimes I have to go to some sites that I don't really trust that much, and I have a user I have dedicated to such uses. For example, Kickstarter. When I'm logged in there, I'll be on one of my work users. (Stupid Flash.) But when I'm browsing other projects, many of the links are offsite, so I shift to the subuser to browse projects, and if I need to link off-site, I'll log out and log in to the dedicated play user. Still not as good as having a separate machine, but better than nothing. If your choice is or do nothing and run them in the normal session then of course there is no difference. I think there is some difference. If I hit a drive-by when I'm browsing via a sub-user, for instance, the malicious payload will be in the subuser's directory tree. Again not perfect, but a bit of a higher wall than a speed bump. Due to the elevated privilege with which X runs this could include privilege escalations. Okay, so why doesn't Fedora drop privileges on Xorg like a certain BSD does? I'm no X expert but historically the X server needed root privileges to use vm86 mode to interact with the video BIOS and to access the IO ports for the card so KMS for all drivers at least is required to be able to support this. Yeah. OpenBSD modifies the Xorg source to allow privilege separation and this work has not made its way upstream (which is a problem for Fedora to include it). License issues? Getting the source should be now problem. There are also legitimate questions about how useful all of this is; although OpenBSD provides their aperture driver to minimize the address space the X server can access Theo de Raadt has said this is just the best we can do. What he means by that is a bit different from what you would mean by that. True, there are ways through that aperture, or around, but it's a bit of a higher wall than a speedbump. Would take some serious programming to defeat, enough so that social engineering or bruteforcing tend to be preferred. Unless you have someone specifically targeting your network, in which case, you really have to restrict what you do on your workstations. OpenBSD also provides a vesafb driver that permits an unprivileged X server with no aperture driver but acceleration is not supported and performance suffers as a consequence. Yeah, it's going to be relatively slow. But it would be nice to have that as an option. (Most of what I do would not suffer significantly.) Well, sure. That's going to happen when you run a server as root. But does it open holes to run the application accessing X as a different user? ergo, holes that wouldn't be open when running the same application as the user you logged in as? Yes; if you don't trust those applications or the data (sites) they operate on then you have a possible avenue for attacks. Kind of like seatbelts. You have to regularly ask yourself if they encourage dangerous driving, and check your habits if you're getting sloppy. This is the point of sandbox -X. Which would be nice if I trusted ACLs. This blog could help me figure out SELinux's ACL tools, which, if I continue to use Fedora, it looks like I'll have to learn to use. In self-defense, if for no other reason. SELinux doesn't provide ACLs (Linux ACLs are primarily a file system feature that's independent of other security frameworks in use). Wait. Doesn't provide or doesn't use? If neither, how does it implement those policies that I never can get right? I thought those policies were just a way to compile those lousy ACLs so you wouldn't be spending more time setting the ACLs than doing actual work. I notice that he is using mount-over tricks to augment the protections. Fancy or funky? I'll have to re-read that when I have time. Just sane. Linux has supported per-process mount namespaces for a very long time. They provide far stronger isolation than other methods. They're
Re: /tmp on tmpfs
On Apr 3, 2012, at 9:35 AM, Chris Adams wrote: Once upon a time, Brian Wheeler bdwhe...@indiana.edu said: * The competition for space between things in /tmp and VM. When someone abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross. First, tmpfs can be swapped. If you are swapping tmpfs files, how is that any worse than having /tmp on a disk? As long as it's swapped well before it starts to be a significant (i.e. not necessarily majority) contributor to a low-memory situation, fine. Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case). Using RAM, I'd be comfortable for /tmp using around 100MB, whereas for disk it might be 1GB. So, an order of magnitude difference in my tolerance level. Or on mobile, 1MB and 100MB, two orders of magnitude. Just depends. Also, on servers where there are users with shell access, I'll typically limit the size of /tmp with an option in fstab (the default is RAM/2, which can be larger than I'd like). 1/2 of installed RAM? That just seems really, really excessive. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On Apr 3, 2012, at 9:48 AM, M A Young wrote: On Tue, 3 Apr 2012, Chris Adams wrote: Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case). That assumes your system is still functional enough to allow you to do that. In a low memory/high swap situation, which this could easily trigger, logging in and clearing the files could be very slow, and the login process could time out before you get logged in. If it's limited to 1/2 RAM*, even if it's the primary cause of a low memory situation it shouldn't cause thrashing. If it does cause thrashing, it's the source of it, and would happen if /tmp were on disk. * I still think that default is excessive. But that's more impression than based on merit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On Tue, 03.04.12 08:31, Chris Murphy (li...@colorremedies.com) wrote: My only concern about it being on tmpfs instead of on disk, is how big it could get, how much memory could be held hostage, until there's a reboot. I'd rather see it be both size and age limited (each item has a decay rate or something), so that it's evacuated more regularly than just between reboots - which could be months. tmpfs by default are limited to 50% of the host RAM in size. Debian lowered this to 30% for /tmp. Whether it is 30% or 50% doesn't really matter too much, what does matter however is that tmpfs always comes with an enforced limit on size. Since about always on Fedora /tmp has been cleaned up in regular intervals. Originally by tmpwatch, but these days by the tmpfiles logic. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
Once upon a time, M A Young m.a.yo...@durham.ac.uk said: On Tue, 3 Apr 2012, Chris Adams wrote: Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case). That assumes your system is still functional enough to allow you to do that. In a low memory/high swap situation, which this could easily trigger, logging in and clearing the files could be very slow, and the login process could time out before you get logged in. Again, if some file in /tmp is the problem, _that_ is liable to be what gets pushed to swap. At that point, you are back to something more or less equivalent to the current situation, with /tmp on disk. If a user can cause problems with that, they can already cause problems today. -- 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
KDE and Evolution
Did a F17 install yesterday (has happened last couple test installs), with KDE as my desktop. Fired up evolution for first time, did the restore as always do. When it finally came up to enter my password for my imap server, after entering it, a menu came up (KDE DaemonSecret service?) to enter password. So I did, then another menu comes up and asks to always allow or just this session. So I answer, then the menus go away, and my evolution is still sitting there with the password menu there as well, but the OK button greyed out, like it's thinking but doesn't do anything. On F16 as I am now, there is a menu that comes up after doing evolution for the first time, but soon as I do passwords, it goes away and evolution goes on as normal. Anyone run into this already or anything? Hope that made sense LOL. -- Mike Chambers Madisonville, KY Best little town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 11:35 AM, Peter Jones pjo...@redhat.com wrote: On 04/03/2012 10:16 AM, Peter Robinson wrote: On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer jwbo...@gmail.com wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com wrote: All builds must occur on Fedora-maintained build servers. FYI, this will require an additional koji-hub for each architecture trying to move to PA. Generally agree, though. No. The additional hub is only needed while an arch is secondary. Once it is PA it is driven from the single koji hub. That's my understanding but the bullet reads as if there's going to be a Fedora maintained hub for the secondary arches. At the moment the hubs for the secondary arches are maintained by the secondary arches. So the point needs to be clarified. I think there are probably 3 steps here, but obviously I don't speak for rel-eng, so I'd like to hear what they have to say. I could be wrong about any of this due to insufficient knowledge of how koji is set up. 1) SA has its own koji hub and builders 2) rel-eng has a staging koji hub for arches under transition, which is really just a temporary thing where we're setting up builders to work with step 3 3) when we decide that it *is* a PA, transition builders from step #2 to the primary koji hub. From a koji perspective, there really isn't much benefit to step 2. What needs to happen is the RPMs from the secondary hub need to be copied to the primary in the correct NVR directories in the hub's storage. That can happen in the background for quite a bit, but at some point the hub would need to be taken offline to sync up the last few builds, and then switch the builders over. Having a staging hub just means you have to copy and move the builders twice. This is mostly due to how koji builders can only talk to one hub at a time and one hub only. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
Michal Schmidt wrote: Cleanup of old files is already done, by systemd-tmpfiles. See /usr/lib/tmpfiles.d/tmp.conf. Files, yes. Directories, no. Due to a bug[1] in gvfs, I had over 100 old, empty directories in /tmp. Other apps may fill /tmp with directories, too, that will not be cleaned by any automatic process at this time. [1] https://bugzilla.redhat.com/show_bug.cgi?id=496177 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 12:07 PM, Josh Boyer wrote: On Tue, Apr 3, 2012 at 11:35 AM, Peter Jones pjo...@redhat.com wrote: On 04/03/2012 10:16 AM, Peter Robinson wrote: On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer jwbo...@gmail.com wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com wrote: All builds must occur on Fedora-maintained build servers. FYI, this will require an additional koji-hub for each architecture trying to move to PA. Generally agree, though. No. The additional hub is only needed while an arch is secondary. Once it is PA it is driven from the single koji hub. That's my understanding but the bullet reads as if there's going to be a Fedora maintained hub for the secondary arches. At the moment the hubs for the secondary arches are maintained by the secondary arches. So the point needs to be clarified. I think there are probably 3 steps here, but obviously I don't speak for rel-eng, so I'd like to hear what they have to say. I could be wrong about any of this due to insufficient knowledge of how koji is set up. 1) SA has its own koji hub and builders 2) rel-eng has a staging koji hub for arches under transition, which is really just a temporary thing where we're setting up builders to work with step 3 3) when we decide that it *is* a PA, transition builders from step #2 to the primary koji hub. From a koji perspective, there really isn't much benefit to step 2. What needs to happen is the RPMs from the secondary hub need to be copied to the primary in the correct NVR directories in the hub's storage. That can happen in the background for quite a bit, but at some point the hub would need to be taken offline to sync up the last few builds, and then switch the builders over. Having a staging hub just means you have to copy and move the builders twice. This is mostly due to how koji builders can only talk to one hub at a time and one hub only. Right, okay, that's a good enough description of what needs to happen for me. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On 04/03/2012 11:35 AM, Chris Adams wrote: Once upon a time, Brian Wheelerbdwhe...@indiana.edu said: * The competition for space between things in /tmp and VM. When someone abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross. First, tmpfs can be swapped. If you are swapping tmpfs files, how is that any worse than having /tmp on a disk? Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case). I've been running with /tmp on tmpfs for several years, including on a number of servers, and I've never had any unusual problem related to it. I typically provision a little more swap on such systems, so that there's some room for spill-over. Also, on servers where there are users with shell access, I'll typically limit the size of /tmp with an option in fstab (the default is RAM/2, which can be larger than I'd like). However, reading the feature page, this would be harder to do, since somebody's irrational fear of /etc/fstab is extending to /tmp. I think that's a bad idea, especially since the proposed feature creates yet another way to mount filesystems (systemd-auto, /etc/fstab, and now a service for /tmp). Really? Two wasn't enough? I have been doing this also but limiting how much space can be used in /etc/fstab with the size= option. To do away with being able to control this seems dumb. -- 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: Install Fedora Button for LiveCD
On Tue, Apr 03, 2012 at 10:29:27 -0400, Matthias Clasen mcla...@redhat.com wrote: For the 'make installing obvious' problem, what we really want is to just autostart the installer. Unfortunately, the current live installer does not really work well for that... I don't think that is a good idea. This imposes a penatly on every boot for people who aren't planning to do install. I think just making it easy to figure out how to start an install is what we want. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On Tue, 2012-04-03 at 10:35 -0500, Chris Adams wrote: Once upon a time, Brian Wheeler bdwhe...@indiana.edu said: * The competition for space between things in /tmp and VM. When someone abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross. First, tmpfs can be swapped. If you are swapping tmpfs files, how is that any worse than having /tmp on a disk? On my current desktop I have over a TB of /tmp disk, and ~3GB of free swap (~5GB is being used by web browsers/etc.). And I'm not dying to make swap any bigger so I can start swapping to death, instead of desktop apps. just crashing (this is bad enough already). Saying that my /tmp is currently only about ~500MB. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On Tue, 2012-04-03 at 11:30 -0500, Bruno Wolff III wrote: On Tue, Apr 03, 2012 at 10:29:27 -0400, Matthias Clasen mcla...@redhat.com wrote: For the 'make installing obvious' problem, what we really want is to just autostart the installer. Unfortunately, the current live installer does not really work well for that... I don't think that is a good idea. This imposes a penatly on every boot for people who aren't planning to do install. I think just making it easy to figure out how to start an install is what we want. That really depends on what use cases we see for our live cds. In my view, there's really only two: The primary use for a live cd is to install. And then, there is a secondary use where you want to review or test without the intention to keep a permanent install. Anyway, we can easily arrange things so that the installer does not get autostarted anymore once you tick the 'No thanks, just playing' checkbox. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
Am 03.04.2012 09:17, schrieb drago01: I don't really get why people make so much fuss about a non issue really. 99,99% of the users won't even notice that anything changed at all. for this 99.9% the current behavior is also good enough if they do not notice any change the other 0.1% are servers where /tmp is a own partition or for virtual machines often even a own virtual disk where as example mysqld writes temp-files for many operations require a temp-table or vmware put memory mapped files these are actions often require a lot of disk space and /tmp was set up as own virtual disk to NOT use rootfs signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On 04/03/2012 04:50 AM, Reindl Harald wrote: Am 03.04.2012 09:17, schrieb drago01: I don't really get why people make so much fuss about a non issue really. 99,99% of the users won't even notice that anything changed at all. for this 99.9% the current behavior is also good enough if they do not notice any change the other 0.1% are servers where /tmp is a own partition or for virtual machines often even a own virtual disk where as example mysqld writes temp-files for many operations require a temp-table or vmware put memory mapped files these are actions often require a lot of disk space and /tmp was set up as own virtual disk to NOT use rootfs There's nothing stopping you from setting things up this way if that's what you need. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 787888] CVE-2012-0839 ocaml: hash table collisions CPU usage DoS (oCERT-2011-003)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=787888 --- Comment #5 from Kurt Seifried kseifr...@redhat.com 2012-04-03 12:47:04 EDT --- According to Xavier Leroy xavier.le...@inria.fr: We decided to skip the 3.13 release entirely and go straight to 4.00. The 4.00 release is scheduled for June 2012. http://caml.inria.fr/mantis/view.php?id=5572 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Install Fedora Button for LiveCD
On Apr 3, 2012, at 10:44 AM, Matthias Clasen wrote: Anyway, we can easily arrange things so that the installer does not get autostarted anymore once you tick the 'No thanks, just playing' checkbox. How about two user logins listed? One is a user named Install Fedora which autostarts the installer, and Live User does not. That's discoverable and concise. Even the checkbox idea is not nearly as discoverable, nor is it concise. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 04:56 PM, Joel Rees wrote: Good point. I don't visit those sites, and it's important for me to mention that. No p0rn, period, and many of the moral reasons are in There are a lot of perfectly family-friendly websites whose administrators I do not trust as far as I could throw them (even if I knew where they were). in the subuser's directory tree. Again not perfect, but a bit of a higher wall than a speed bump. If the payload targets an X vulnerability there is no difference. License issues? Getting the source should be now problem. Upstream first - Fedora goes out of its way to get new features into the distribution by getting them into the projects it packages upstream (often by doing the work upstream). There are occasional exceptions but it's very unusual for Fedora to take a large set of changes from another downstream packager before they get merged. address space the X server can access Theo de Raadt has said this is just the best we can do. What he means by that is a bit different from what you would mean by that. Thank you for enlightening as to what I meant (although what you assume I mean by that may not be the same as what I actually meant when I wrote it). to defeat, enough so that social engineering or bruteforcing tend to be preferred. Unless you have someone specifically targeting your network, in which case, you really have to restrict what you do on That's not the case at all. It's just a more constrained interface to the same thing (and Linux is fairly restrictive about that these days too). A smaller attack surface doesn't mean that you need targeted attacks; almost certainly if someone discovered an exploitable flaw in this it could be developed into an easily deployed local exploit just like any other. What I understood from Theo's statement is that while it tightens some avenues for exploit development the basic model of exposing hardware to a userspace process (privileged or not) is broken. Not everybody agrees but there is a lack of a usable alternative right now. He also goes on to state that X: violates all the security models you will hear of in a university class. due to the exposure of the device registers, memory space and I/O ports to userspace (drivers in userspace model) and that the X developers are a bunch of shameless vendor-loving lapdogs who sure are taking their time at solving this 10 year old problem. I am sure such words would motivate me to help him if I worked on X. Yeah, it's going to be relatively slow. But it would be nice to have that as an option. (Most of what I do would not suffer significantly.) There are vesa drivers in Fedora. I have no idea how difficult it would be to coax them into running unprivileged but if it interests you you might want to look into it. Kind of like seatbelts. You have to regularly ask yourself if they encourage dangerous driving, and check your habits if you're getting sloppy. The evidence base disagrees here. Multiple studies find large declines in casualty figures following introduction of mandatory seatbelt laws: http://jech.highwire.org/content/43/3/218.full.pdf http://tinyurl.com/bu6ymdn [jstor] Which would be nice if I trusted ACLs. But you trust the kernel, Xorg and Firefox which are considerably larger and more complex beasts? Ok... I thought those policies were just a way to compile those lousy ACLs so you wouldn't be spending more time setting the ACLs than doing actual work. Not quite: SELinux provides a framework for defining access control policies based on users, roles and types (aka domains). The policy defines what actions a given user/role/type combination is permitted to carry out. Daemons and other confined processes are placed in a specific domain to limit their access to system resources according to the policy: http://en.wikipedia.org/wiki/Security-Enhanced_Linux You can use this to implement RBAC, MCS, MLS etc. SELinux contexts are stored along side files in the file system as extended attributes (xattrs) - i.e. it's label-based rather than path-based security. Xattrs are also used for ACLs in many file systems so that may be where the confusion arises. ACLs usually refer to access control lists - most often file system ACLs although there are many other uses of the term e.g. BIND DNS ACLs or Microsoft Windows fs ACLs mapped through Samba/CIFS. An ACL is just a list of identities and the level of access they are permitted. Fs ACLs are available with any modern Linux file system and operate independently from any LSM security framework in use. Per-process could be an interesting, might be able to combine that with other things I do. Check out pam_namespace which does per-session namespaces (and probably more now, it's been a while). There's a post from Russell Coker discussing it here: http://etbe.coker.com.au/2008/12/13/per-process-namespaces-pam-namespace/ Well, if I were inventing,
File Class-Load-0.19.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Class-Load: 1a81421fda749d36952e7ada7876bcc7 Class-Load-0.19.tar.gz -- 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
[perl-Class-Load] Update to 0.19
commit 4cc39dbb88898c28851c44d785832a496c8fd960
Author: Paul Howarth p...@city-fan.org
Date: Tue Apr 3 18:26:16 2012 +0100
Update to 0.19
- New upstream release 0.19 (no functional changes)
- This release by DOY - update source URL
- BR: perl(Exporter)
- Don't need to remove empty directories from buildroot
perl-Class-Load.spec | 10 --
sources |2 +-
2 files changed, 9 insertions(+), 3 deletions(-)
---
diff --git a/perl-Class-Load.spec b/perl-Class-Load.spec
index b0deacd..0bd6a35 100644
--- a/perl-Class-Load.spec
+++ b/perl-Class-Load.spec
@@ -1,5 +1,5 @@
Name: perl-Class-Load
-Version: 0.18
+Version: 0.19
Release: 1%{?dist}
Summary: A working (require Class::Name) and more
Group: Development/Libraries
@@ -17,6 +17,7 @@ BuildRequires:perl(ExtUtils::MakeMaker)
BuildRequires: perl(base)
BuildRequires: perl(Carp)
BuildRequires: perl(Data::OptList)
+BuildRequires: perl(Exporter)
BuildRequires: perl(Module::Implementation) = 0.04
BuildRequires: perl(Module::Runtime) = 0.012
BuildRequires: perl(Package::Stash) = 0.14
@@ -77,7 +78,6 @@ make %{?_smp_mflags}
%install
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} ';' 2/dev/null
%{_fixperms} %{buildroot}
%check
@@ -89,6 +89,12 @@ make test %{!?perl_bootstrap:RELEASE_TESTING=1}
%{_mandir}/man3/Class::Load.3pm*
%changelog
+* Tue Apr 3 2012 Paul Howarth p...@city-fan.org - 0.19-1
+- Update to 0.19 (no functional changes)
+- This release by DOY - update source URL
+- BR: perl(Exporter)
+- Don't need to remove empty directories from buildroot
+
* Sat Feb 18 2012 Paul Howarth p...@city-fan.org - 0.18-1
- Update to 0.18:
- Require Package::Stash ≥ 0.14 (CPAN RT#75095)
diff --git a/sources b/sources
index acf002b..5cc2511 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-da9ec57dd0199f6393702f2273ad6442 Class-Load-0.18.tar.gz
+1a81421fda749d36952e7ada7876bcc7 Class-Load-0.19.tar.gz
--
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: Install Fedora Button for LiveCD
On Tue, Apr 3, 2012 at 12:20 PM, Jesse Keating jkeat...@j2solutions.net wrote: On 4/3/12 9:44 AM, Matthias Clasen wrote: Anyway, we can easily arrange things so that the installer does not get autostarted anymore once you tick the 'No thanks, just playing' checkbox. Instead of autolaunching the installer, why not autolaunch a very light window that has two buttons: Install Fedora and Evaluate Fedora. Hell, could just be one button, Install Fedora but the window/app itself can be dismissed. So basically every time you boot and log into a live CD you get a popup offering you the ability to install, that can be easily dismissed. Thoughts? As someone who often uses live media but who almost never uses it to install Fedora this would be extremely annoying compared to just booting to the live media and having some obvious way to do an installation if that is what the user wants to do without repeatedly bothering those who don't. My experience may not be ordinary, but I really think the install from live media use case isn't all that common compared to other uses of live media. I could be wrong, I certainly know people who do install from the live media as well. From the options I've seen put on the table so far I would lean toward either the original just make it easy somehow to do it from the desktop or having it be an optional boot choice that is not the default but that has an obvious label. Making it simple to do and making it not a bother to those who don't want to install Fedora from the live media would be a win for all use cases I think. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On 04/03/2012 11:36 AM, inode0 wrote: As someone who often uses live media but who almost never uses it to install Fedora this would be extremely annoying compared to just booting to the live media and having some obvious way to do an installation if that is what the user wants to do without repeatedly bothering those who don't. My experience may not be ordinary, but I really think the install from live media use case isn't all that common compared to other uses of live media. I could be wrong, I certainly know people who do install from the live media as well. From the options I've seen put on the table so far I would lean toward either the original just make it easy somehow to do it from the desktop or having it be an optional boot choice that is not the default but that has an obvious label. Making it simple to do and making it not a bother to those who don't want to install Fedora from the live media would be a win for all use cases I think. How bout adding/changing the icon for installing? Can we not include some text in the icon? Install Fedora somehow?? -- Nathanael d. Noblet t 403.875.4613 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
Once upon a time, Matthias Clasen mcla...@redhat.com said: That really depends on what use cases we see for our live cds. In my view, there's really only two: The primary use for a live cd is to install. That's the primary use of the install media. The primary use of the live media is to boot a live system. -- 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: Install Fedora Button for LiveCD
On Tue, Apr 3, 2012 at 9:51 AM, Nathanael D. Noblet nathan...@gnat.ca wrote: How bout adding/changing the icon for installing? Can we not include some text in the icon? Install Fedora somehow?? Actually... would it make sense to force a notification event about the install option on live CD login? It pops up for a few seconds in the message tray telling you this media can be used for a full install..and then the message lives in the message tray until dismissed. Seems like the point of the message tray to me. Or am I missing the point? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
To summarize, I see two major paths: a) Make installer launcher more visible: e.g. http://kparal.fedorapeople.org/misc/InstallFedoraButton.png -or- b) Use a proxy window asking which use case is relevant for you: e.g. http://i.imgur.com/I26vS.png Both approaches are fine in my view and certainly improve the current state. The implementation of each approach can very a lot, especially for the first one. One more comment to we want to provide the default experience: Gnome Shell is quite intuitive *once you know it*. But if you see it for the first time, it is not, it brings a lot of new concepts. And it lacks any options to make an important launcher really visible. For this reason the stock/default experience is not suitable for the LiveCD installer use case. It is not a fault, because it targets something else. We just need to adjust it accordingly in this case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On Apr 3, 2012, at 11:55 AM, Jef Spaleta wrote: Actually... would it make sense to force a notification event about the install option on live CD login? It pops up for a few seconds in the message tray telling you this media can be used for a full install..and then the message lives in the message tray until dismissed. Eminently plausible. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SPDY in F18 (was Re: F17 httpd 2.4?)
Hi, 2012/3/29 Dennis Jacobfeuerborn denni...@conversis.de: On 03/28/2012 07:39 PM, Michał Piotrowski wrote: Hi, 2012/3/28 Dennis Jacobfeuerborn denni...@conversis.de: On 03/27/2012 09:46 PM, Michał Piotrowski wrote: W dniu 21 marca 2012 15:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: 2012/3/21 Peter Robinson pbrobin...@gmail.com: [..] There's nothing stopping you from packaging up mod_spdy or any other modules that add support for the protocol. I will try tomorrow - I've got mod_fcgid package sources for reference. Who can mod_spdy if I make the spec file for this? I wanted to write Who can adopt mod_spdy :) I created a feature page https://fedoraproject.org/wiki/Features/F18SPDY If someone accidentally did not know what SPDY is - there is a link to interesting video from GoogleTechTalks on this page. I also created an initial version of spec file for mod_spdy that can be found at this repo https://github.com/eventhorizonpl/mod_spdy That mod_ssl_with_npn.so hack looks pretty dodgy to me. Does that even work? Have you tested this together with the regular mod_ssl that comes with the httpd package? I've got some problems with getting it to work. I cannot see how both modules can coexist. I think that it is not possible. As far as I can tell the patch required to mod_ssl is fairly simple and it looks like it will be committed to upstream soon: https://issues.apache.org/bugzilla/show_bug.cgi?id=52210 You could ask the maintainer of the httpd package what he thinks about adding this patch to the package so the modified mod_ssl is no longer required. I asked for inclusion of this patch https://bugzilla.redhat.com/show_bug.cgi?id=809599 I hope the request will be positively considered :) Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
Actually... would it make sense to force a notification event about the install option on live CD login? It pops up for a few seconds in the message tray telling you this media can be used for a full install..and then the message lives in the message tray until dismissed. That is a good idea that can be probably implemented very easily. However, what is the benefit over a persistent button in the top panel? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On Tue, Apr 3, 2012 at 10:23 AM, Kamil Paral kpa...@redhat.com wrote: That is a good idea that can be probably implemented very easily. However, what is the benefit over a persistent button in the top panel? I believe its adequately provides a solution to meet all constraints so far expressed in this discussion. 1) Notice on login with buttons! 2) Automatically hides itself after a few seconds and gets the hell out of the way if you don't want to do an install and really do want to use this live environment. 3) Does not change the delivered UI by adding a new static element that is Fedora install specific. 4) Available in the overview as a reminder until dismissed..allowing for delayed install action. This makes the install bubble equivalent UI to the current selinux avc notices. They pop up (on login) you can either deal with them or not. The reality is Gnome 3 is trying very very hard to remove the swamp that was the notification tray along the top bar. Good or bad, right or wrong, that is clearly one of the design goals. The button in the top panel works directly against that goal. So instead of digging our heels into an implementation that is clearly not aligned with upstream design decisions, lets find something that works and meets the constraints. I'm not going to bash my head against the brickwall supporting an implementation that is out of step with the over all design in what has become a design led UI. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 04:58 AM, Josh Boyer wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com mailto:b...@redhat.com wrote: All builds must occur on Fedora-maintained build servers. FYI, this will require an additional koji-hub for each architecture trying to move to PA. Generally agree, though. No. The additional hub is only needed while an arch is secondary. Once it is PA it is driven from the single koji hub. Exactly. And if there were two unrelated arches in transition it would mean 2 hubs would be needed. The point here is that a piece of hardware is needed so SA's making the transition will need to ensure this hardware is available. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SPDY in F18 (was Re: F17 httpd 2.4?)
Hi, W dniu 28 marca 2012 19:39 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: Hi, 2012/3/28 Dennis Jacobfeuerborn denni...@conversis.de: On 03/27/2012 09:46 PM, Michał Piotrowski wrote: W dniu 21 marca 2012 15:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: 2012/3/21 Peter Robinson pbrobin...@gmail.com: [..] There's nothing stopping you from packaging up mod_spdy or any other modules that add support for the protocol. I will try tomorrow - I've got mod_fcgid package sources for reference. Who can mod_spdy if I make the spec file for this? I wanted to write Who can adopt mod_spdy :) I created a feature page https://fedoraproject.org/wiki/Features/F18SPDY If someone accidentally did not know what SPDY is - there is a link to interesting video from GoogleTechTalks on this page. I also created an initial version of spec file for mod_spdy that can be found at this repo https://github.com/eventhorizonpl/mod_spdy That mod_ssl_with_npn.so hack looks pretty dodgy to me. Does that even work? Have you tested this together with the regular mod_ssl that comes with the httpd package? I've got some problems with getting it to work. I am pleased to announce that Fedora has working mod_spdy :) https://github.com/eventhorizonpl/mod_spdy -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide not resolving %{_libdir} properly ?
On 04/03/2012 09:07 AM, Krzysztof Daniel wrote:
On Mon, 2012-04-02 at 15:00 -0400, Roland Grunberg wrote:
Is anyone else getting similar issues?
Cheers,
--
Roland Grunberg
I have the same problem, see bug
808983: pdebuild script fails
https://bugzilla.redhat.com/show_bug.cgi?id=808983
I have found http://rpm.org/wiki/PackagerDocs/ArchDependencies,
which advises using ISA Dependencies, but have not tried that yet.
ISA-macros are just as non-meaningful in noarch packages as %{_lib} and
%{_libdir} are.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 09:07 AM, Josh Boyer wrote: From a koji perspective, there really isn't much benefit to step 2. What needs to happen is the RPMs from the secondary hub need to be copied to the primary in the correct NVR directories in the hub's storage. That can happen in the background for quite a bit, but at some point the hub would need to be taken offline to sync up the last few builds, and then switch the builders over. Having a staging hub just means you have to copy and move the builders twice. This is mostly due to how koji builders can only talk to one hub at a time and one hub only. Where do you envision the builders being in this scenario? I see the steps being something like this: 1. SA builders and/or hub are located outside PHX. 2 option a. Builders come up in PHX, hub stays in original location. 2 option b. Staging hub comes up in PHX, builders stay in original location. 3. Both staging hub and builders come up in PHX 4. When appropriate move from staging hub to primary hub. Having everything take place in PHX prior to the switchover has numerous benefits. These 3 come to mind immediately: 1. Fast local network will represent true build times (vs transfering rpms across the external network). 2. Realistic load assessment. If, hypothetically primary koji and staging koji are both virtual machines on the same underlying hardware you'll know if the hardware can handle the load. Also network, disk, etc. 3. Comparable infrastructure reliability. Switching koji hubs twice does incur a bit more work, but it may also provide better results. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 2:45 PM, Brendan Conoboy b...@redhat.com wrote: On 04/03/2012 04:58 AM, Josh Boyer wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com mailto:b...@redhat.com wrote: All builds must occur on Fedora-maintained build servers. FYI, this will require an additional koji-hub for each architecture trying to move to PA. Generally agree, though. No. The additional hub is only needed while an arch is secondary. Once it is PA it is driven from the single koji hub. Exactly. And if there were two unrelated arches in transition it would mean 2 hubs would be needed. The point here is that a piece of hardware is needed so SA's making the transition will need to ensure this hardware is available. Erm... you already have this. So will any SA making a transition. I don't see a problem. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 12:02 PM, Josh Boyer wrote: Erm... you already have this. So will any SA making a transition. I don't see a problem. Outside PHX, yes. Inside, no. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Apr 2012 11:58:11 -0700 Brendan Conoboy b...@redhat.com wrote: On 04/03/2012 09:07 AM, Josh Boyer wrote: From a koji perspective, there really isn't much benefit to step 2. What needs to happen is the RPMs from the secondary hub need to be copied to the primary in the correct NVR directories in the hub's storage. That can happen in the background for quite a bit, but at some point the hub would need to be taken offline to sync up the last few builds, and then switch the builders over. Having a staging hub just means you have to copy and move the builders twice. This is mostly due to how koji builders can only talk to one hub at a time and one hub only. Where do you envision the builders being in this scenario? I see the steps being something like this: 1. SA builders and/or hub are located outside PHX. 2 option a. Builders come up in PHX, hub stays in original location. 2 option b. Staging hub comes up in PHX, builders stay in original location. 3. Both staging hub and builders come up in PHX 4. When appropriate move from staging hub to primary hub. As i see it the Secondary arch will continue to run as normal. we will get new build hardware for use in PHX, it will be brught up and added to koji behind the scenes we will be importing the matching latest secondary arch builds to primary koji, and signing if appropriate At cutover date we will take a outage to make sure we have full matching content imported. we would add the new arches to the tags and enable building again. at this point in time then the secondary arch koji would be considered legacy and used only to maintain the older stable releases Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk97ShAACgkQkSxm47BaWffPRACgtlC0buQ066+CHlM1STb7rj0g /1UAoLDyHFa4SWwK7b2MyMMZdnzTRBLf =pdRh -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 2:58 PM, Brendan Conoboy b...@redhat.com wrote: On 04/03/2012 09:07 AM, Josh Boyer wrote: From a koji perspective, there really isn't much benefit to step 2. What needs to happen is the RPMs from the secondary hub need to be copied to the primary in the correct NVR directories in the hub's storage. That can happen in the background for quite a bit, but at some point the hub would need to be taken offline to sync up the last few builds, and then switch the builders over. Having a staging hub just means you have to copy and move the builders twice. This is mostly due to how koji builders can only talk to one hub at a time and one hub only. Where do you envision the builders being in this scenario? I see the steps being something like this: 1. SA builders and/or hub are located outside PHX. 2 option a. Builders come up in PHX, hub stays in original location. 2 option b. Staging hub comes up in PHX, builders stay in original location. 3. Both staging hub and builders come up in PHX 4. When appropriate move from staging hub to primary hub. I hope when you refer to staging hub you mean the hub being used as the SA hub. Having everything take place in PHX prior to the switchover has numerous benefits. These 3 come to mind immediately: 1. Fast local network will represent true build times (vs transfering rpms across the external network). Yes. Which is why you ship the SA hub to PHX. I'm not saying this is a _requirement_, but it is the most expedient option. Otherwise you have a hell of a lot of data to get to PHX anyway. 2. Realistic load assessment. If, hypothetically primary koji and staging koji are both virtual machines on the same underlying hardware you'll know if the hardware can handle the load. Also network, disk, etc. 3. Comparable infrastructure reliability. Switching koji hubs twice does incur a bit more work, but it may also provide better results. I don't see how. The hub characteristics are the least of the worries in this entire scenario. The builders are going to dominate the time spent, and you aren't going to get exactly comparable statistics by using a staging hub on identical hardware/VM config because that staging hub isn't going to be building both PA and the soon-to-be PA SA. Really, staging hubs seem like a waste of time to me. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting minutes FESCo (2012-03-26)
On Fri, 2012-03-30 at 14:29 +0200, David Tardon wrote: On Tue, Mar 27, 2012 at 11:16:30AM -0700, Adam Williamson wrote: On Mon, 2012-03-26 at 21:17 +0200, Marcela Mašláňová wrote: Could I suggest that, if FESCo is going to have a different chair each week, you at least have an SOP for arranging the meetings, so that this kind of thing is done consistently? Just in the last two weeks we've had a FESCo meeting announcement with an empty topic, and now a minutes post with a different subject from all the previous minutes posts (the 'standard' appears to be Summary minutes for today's FESCo meeting (-XX-XX)) and with no text but an *attachment* of the meetbot summary. Sorry, but I really do not understand your problem. I have never had a problem recognizing the meeting notes email. The same for parsing its content. (Actually, I haven't even noticed that the subject is not always the same...) If it is really so important that the structure of that email is always the same, without a sligthest variation, it should be sent directly by the bot, without any human intervention. Period. If I want to quickly look through the results of all the FESCo meetings, I just search for some word which should always show up in the topic of those mails but rarely shows up in the topic of other mails. If there's no process for sending the mail, I've no guarantee or reasonable expectation I'll actually *find* all the mails this way. It's not about 'slightest variation(s)'. Remember one of the cases I cited was that an announce got sent with no topic *at all*. How's anyone ever going to find that one again? Doing everything by bot is not always possible, if you want the summary to have some kind of vaguely intelligent hand-editing. But if all you do is copy/paste the bot summary, then sure, it would make sense just to automate the process. Less chance of mistakes, saves everyone time. Or do we really need a policy/process/guideline for _everything_? I tend to find it's a good idea. It has lots of benefits and virtually no drawbacks, except that someone has to find time to write it. -- 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: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 3:04 PM, Brendan Conoboy b...@redhat.com wrote: On 04/03/2012 12:02 PM, Josh Boyer wrote: Erm... you already have this. So will any SA making a transition. I don't see a problem. Outside PHX, yes. Inside, no. If an SA wants to go off and do a staging hub instead of just planning on shipping their hub they've built with from inception to PHX that's fine. It seeems like a waste of time to purchase/create a new hub instance that will basically be thrown away once it migrates to a PA but if the SA team wants to do that then I doubt anyone will complain. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, 03 Apr 2012 12:04:07 -0700 Brendan Conoboy b...@redhat.com wrote: On 04/03/2012 12:02 PM, Josh Boyer wrote: Erm... you already have this. So will any SA making a transition. I don't see a problem. Outside PHX, yes. Inside, no. I'll note again that the ppc and s390 secondary arch hubs are in fact in phx2. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 12:10 PM, Kevin Fenzi wrote: I'll note again that the ppc and s390 secondary arch hubs are in fact in phx2. ;) You're already one step ahead of ARM ;-) -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 3:05 PM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Apr 2012 11:58:11 -0700 Brendan Conoboy b...@redhat.com wrote: On 04/03/2012 09:07 AM, Josh Boyer wrote: From a koji perspective, there really isn't much benefit to step 2. What needs to happen is the RPMs from the secondary hub need to be copied to the primary in the correct NVR directories in the hub's storage. That can happen in the background for quite a bit, but at some point the hub would need to be taken offline to sync up the last few builds, and then switch the builders over. Having a staging hub just means you have to copy and move the builders twice. This is mostly due to how koji builders can only talk to one hub at a time and one hub only. Where do you envision the builders being in this scenario? I see the steps being something like this: 1. SA builders and/or hub are located outside PHX. 2 option a. Builders come up in PHX, hub stays in original location. 2 option b. Staging hub comes up in PHX, builders stay in original location. 3. Both staging hub and builders come up in PHX 4. When appropriate move from staging hub to primary hub. As i see it the Secondary arch will continue to run as normal. we will get new build hardware for use in PHX, it will be brught up and added to koji behind the scenes we will be importing the matching Who is we in this scenario. It's the responsibility of the SA team to provide hardware for builders, and I don't see promotion to PA as grounds for someone other than the SA team purchasing it. Basically, we here should not be the Fedora project. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecture promotion requirements draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Apr 2012 15:13:51 -0400 Josh Boyer jwbo...@gmail.com wrote: On Tue, Apr 3, 2012 at 3:05 PM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Apr 2012 11:58:11 -0700 Brendan Conoboy b...@redhat.com wrote: On 04/03/2012 09:07 AM, Josh Boyer wrote: From a koji perspective, there really isn't much benefit to step 2. What needs to happen is the RPMs from the secondary hub need to be copied to the primary in the correct NVR directories in the hub's storage. That can happen in the background for quite a bit, but at some point the hub would need to be taken offline to sync up the last few builds, and then switch the builders over. Having a staging hub just means you have to copy and move the builders twice. This is mostly due to how koji builders can only talk to one hub at a time and one hub only. Where do you envision the builders being in this scenario? I see the steps being something like this: 1. SA builders and/or hub are located outside PHX. 2 option a. Builders come up in PHX, hub stays in original location. 2 option b. Staging hub comes up in PHX, builders stay in original location. 3. Both staging hub and builders come up in PHX 4. When appropriate move from staging hub to primary hub. As i see it the Secondary arch will continue to run as normal. we will get new build hardware for use in PHX, it will be brught up and added to koji behind the scenes we will be importing the matching Who is we in this scenario. It's the responsibility of the SA team to provide hardware for builders, and I don't see promotion to PA as grounds for someone other than the SA team purchasing it. Basically, we here should not be the Fedora project. josh We would be releng importing the binaries into the primary koji. Hardware procurement would be done to infrastructure specifications. with support contracts, remote management etc. as to who buys it? I would hope that the secondary arch team could negotiate donations from vendors. since the arch would be growing and the vendors would want it to be used as a selling point. Builder hardware today is all provided by purchases by Red Hat, the last builder hardware was purchased by Red Hat IT and the koji storage was a mixture of Release Engineering and Red Hat IT. I really don't care who pays for the hardware, just that we have hardware that meets the requirements for being in the colo. ongoing hardware costs will likely be from one of Fedora engineering, Release engineering or Red Hat IT's budget. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk97T6UACgkQkSxm47BaWffFXwCfVrrnAG9tt6KAif/9cv3VtDys aZQAn1CyzOVjqiPr/Kd46rVPtZXecEW6 =/1J2 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Apr 2012 11:45:09 -0700 Brendan Conoboy b...@redhat.com wrote: On 04/03/2012 04:58 AM, Josh Boyer wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com mailto:b...@redhat.com wrote: All builds must occur on Fedora-maintained build servers. FYI, this will require an additional koji-hub for each architecture trying to move to PA. Generally agree, though. No. The additional hub is only needed while an arch is secondary. Once it is PA it is driven from the single koji hub. Exactly. And if there were two unrelated arches in transition it would mean 2 hubs would be needed. The point here is that a piece of hardware is needed so SA's making the transition will need to ensure this hardware is available. there should be no transition of hubs from one location to another. that is really just silly and wasteful. any transition from secondary to primary would only ever occur in rawhide only. the existing hub will need to remain up and working for at least the life of currently released stable releases. we would add builders into phx, we could add them to the existing staging koji to do soem testing if desired. there would eb a flag day that is a cutover from the arch being secondary to primary, but that transition would only be adding the new arches to rawhide only. we would only be importing the most recent rawhide builds for the secondary arch, or alternatively we would add the secondary arch as a external repo and do a mass rebuild to add the secondary arch. but it would only be a transition for rawhide. if an arch was to become primary for f18 it would need to complete the transition before we branch rawhide to f18, if it misses that date it could only be considered for f19. once we branch we start looking at alpha, the new arch would debut with Alpha. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk97UcwACgkQkSxm47BaWfcq0ACfbJn0W2GtdBy+YOEgWYv0VCrw p1EAnijZyWFNPWfQqUkrO5REoHXHRkcp =W2R8 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On Tue, Apr 03, 2012 at 12:44:17 -0400, Matthias Clasen mcla...@redhat.com wrote: That really depends on what use cases we see for our live cds. In my view, there's really only two: The primary use for a live cd is to install. And then, there is a secondary use where you want to review or test without the intention to keep a permanent install. You can use it as a rescue image, which is similar to the the latter case. You can also use it as a way to have trusted image to run on machines you don't get to install software on. Anyway, we can easily arrange things so that the installer does not get autostarted anymore once you tick the 'No thanks, just playing' checkbox. That won't work on write once media. Even on a USB you need to have added an overlay or home area when you put the image on the USB or you aren't going to be able to change things. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 809427] perl-DateTime-TimeZone-1.46 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=809427 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2012-04-03 15:52:34 EDT --- Package perl-DateTime-TimeZone-1.46-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-DateTime-TimeZone-1.46-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-5258/perl-DateTime-TimeZone-1.46-1.fc16 then log in and leave karma (feedback). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: KDE and Evolution
Mike Chambers wrote: Did a F17 install yesterday (has happened last couple test installs), with KDE as my desktop. Fired up evolution for first time, did the restore as always do. When it finally came up to enter my password for my imap server, after entering it, a menu came up (KDE DaemonSecret service?) to enter password. So I did, then another menu comes up and asks to always allow or just this session. Sounds like you may have had your first experience with ksecrets, and that it didn't work. As a matter of fact, we've found that it fails to function properly in many scendarios, and have opted to not install it by default anymore. Your easiest fix is probably: yum remove ksecrets -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: KDE and Evolution
Il 03/04/2012 23:04, Rex Dieter ha scritto: Mike Chambers wrote: Did a F17 install yesterday (has happened last couple test installs), with KDE as my desktop. Fired up evolution for first time, did the restore as always do. When it finally came up to enter my password for my imap server, after entering it, a menu came up (KDE DaemonSecret service?) to enter password. So I did, then another menu comes up and asks to always allow or just this session. Sounds like you may have had your first experience with ksecrets, and that it didn't work. As a matter of fact, we've found that it fails to function properly in many scendarios, and have opted to not install it by default anymore. Your easiest fix is probably: yum remove ksecrets -- rex is KSecret, the KDE wallet? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecture promotion requirements draft
2012/4/3 Jóhann B. Guðmundsson johan...@gmail.com: On 04/03/2012 07:29 PM, Dennis Gilmore wrote: I really don't care who pays for the hardware, just that we have hardware that meets the requirements for being in the colo. ongoing hardware costs will likely be from one of Fedora engineering, Release engineering or Red Hat IT's budget. Just out of curiosity what's the procedure for the community to provide releng/infrastructure with hw if it's needed? Does there exist an paypal account or something similar to gather funds for needed hw? Long story put short what can we do and what cant we do in that regard? I believe it depends, in the case of ARM I believe it's going to be a combination of working with vendors and possibly some budget from with in Red Hat (no idea of the department or where) based on discussions had at FUDCon. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 695589] Providing native systemd file for amavisd-new
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=695589 Jóhann B. Guðmundsson johan...@gmail.com changed: What|Removed |Added CC||johan...@gmail.com --- Comment #14 from Jóhann B. Guðmundsson johan...@gmail.com 2012-04-03 17:20:04 EDT --- You dont need rpms to be able to test submitted units against various components. It's enough for you to copy the relevant unit(s) to the /etc/systemd/system directory and run systemctl daemon-reload. Those units will then take precedence over the legacy sysv init scripts that bears the same name as the unit... -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Feedback on secondary architecture promotion requirements draft
2012/4/3 Jóhann B. Guðmundsson johan...@gmail.com: On 04/03/2012 07:29 PM, Dennis Gilmore wrote: I really don't care who pays for the hardware, just that we have hardware that meets the requirements for being in the colo. ongoing hardware costs will likely be from one of Fedora engineering, Release engineering or Red Hat IT's budget. Just out of curiosity what's the procedure for the community to provide releng/infrastructure with hw if it's needed? The rules are, it has to be rack mountable hardware that comes with full warranty support. I believe it needs to also have some form of remote management. If it meets those rules, you can file a ticket with infrastructure and ship it to the PHX2 datacenter. They'll let you know if there is space and power drops in the datacenter, etc. Does there exist an paypal account or something similar to gather funds for needed hw? No Fedora sponsored PayPal account. There are various reasons that one can't be created, similar to how you cannot donate financially to the Fedora Project. SA teams could possibly create one themselves I guess. Long story put short what can we do and what cant we do in that regard? The need for a full warranty is usually enough of a hurdle to limit what the community as a bunch of individuals can do. Your idea of a community started funding account is new though I think. It might be worth exploring. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Xfce 4.10pre1 in rawhide
On 03/04/12 20:47, Gilboa Davara wrote: You somehow assume that I was too lazy to read the supplied link Why the *Sigh* then? giving you some god-given-right to police this ML by spamming my You did, by Sighing mailbox with repeated useless (and rude) comments. For the record: 1. I read the supplied link. Certainly have fooled me. 2. The question was in place (hence MR. Kevin replay) Hence two previous legitimate replies, with links. 3. If you continue I'll be forced to contact the ML admins. Go ahead, and maybe you will explain to all, your reasoning as to the ignoring of two previous replies, just an *ignorant sigh* Apologies for spamming, Sigh -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
