Compose started at Tue Oct 19 08:15:14 UTC 2010
Broken deps for x86_64 ---------------------------------------------------------- R-RScaLAPACK-0.6.1-4.fc14.x86_64 requires libmpi.so.0()(64bit) R-RScaLAPACK-0.6.1-4.fc14.x86_64 requires libopen-rte.so.0()(64bit) R-RScaLAPACK-0.6.1-4.fc14.x86_64 requires libopen-pal.so.0()(64bit) ScientificPython-2.8-11.fc14.x86_64 requires libmpi.so.0()(64bit) ScientificPython-2.8-11.fc14.x86_64 requires libopen-rte.so.0()(64bit) ScientificPython-2.8-11.fc14.x86_64 requires libopen-pal.so.0()(64bit) blacs-openmpi-1.1-39.fc14.x86_64 requires libmpi.so.0()(64bit) blacs-openmpi-1.1-39.fc14.x86_64 requires libopen-rte.so.0()(64bit) blacs-openmpi-1.1-39.fc14.x86_64 requires libmpi_f77.so.0()(64bit) blacs-openmpi-1.1-39.fc14.x86_64 requires libopen-pal.so.0()(64bit) boost-graph-openmpi-1.44.0-1.fc15.x86_64 requires libmpi.so.0()(64bit) boost-graph-openmpi-1.44.0-1.fc15.x86_64 requires libopen-rte.so.0()(64bit) boost-graph-openmpi-1.44.0-1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) boost-graph-openmpi-1.44.0-1.fc15.x86_64 requires libopen-pal.so.0()(64bit) boost-openmpi-1.44.0-1.fc15.x86_64 requires libmpi.so.0()(64bit) boost-openmpi-1.44.0-1.fc15.x86_64 requires libopen-rte.so.0()(64bit) boost-openmpi-1.44.0-1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) boost-openmpi-1.44.0-1.fc15.x86_64 requires libopen-pal.so.0()(64bit) boost-openmpi-python-1.44.0-1.fc15.x86_64 requires libmpi.so.0()(64bit) boost-openmpi-python-1.44.0-1.fc15.x86_64 requires libopen-rte.so.0()(64bit) boost-openmpi-python-1.44.0-1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) boost-openmpi-python-1.44.0-1.fc15.x86_64 requires libopen-pal.so.0()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 0:1.3.0 dreampie-python3-1.1-5.fc14.noarch requires python(abi) = 0:3.1 empathy-2.32.0-1.fc15.x86_64 requires libcamel-1.2.so.19()(64bit) eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libopen-rte.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libmpi.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libopen-pal.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libmpi.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libopen-rte.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libopen-pal.so.0()(64bit) 1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel >= 0:2.91 1:gedit-devel-2.91.0-4.fc15.x86_64 requires gtksourceview2-devel >= 0:2.91 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gromacs-openmpi-4.5.1-1.fc15.i686 requires libmpi_cxx.so.0 gromacs-openmpi-4.5.1-1.fc15.i686 requires libopen-pal.so.0 gromacs-openmpi-4.5.1-1.fc15.i686 requires libmpi.so.0 gromacs-openmpi-4.5.1-1.fc15.i686 requires libopen-rte.so.0 gromacs-openmpi-4.5.1-1.fc15.x86_64 requires libopen-pal.so.0()(64bit) gromacs-openmpi-4.5.1-1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) gromacs-openmpi-4.5.1-1.fc15.x86_64 requires libmpi.so.0()(64bit) gromacs-openmpi-4.5.1-1.fc15.x86_64 requires libopen-rte.so.0()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mpi4py-openmpi-1.2.2-2.fc15.x86_64 requires libopen-pal.so.0()(64bit) mpi4py-openmpi-1.2.2-2.fc15.x86_64 requires libmpi.so.0()(64bit) mpi4py-openmpi-1.2.2-2.fc15.x86_64 requires libopen-rte.so.0()(64bit) orsa-openmpi-0.7.0-12.fc13.x86_64 requires libmpi.so.0()(64bit) orsa-openmpi-0.7.0-12.fc13.x86_64 requires libopen-rte.so.0()(64bit) orsa-openmpi-0.7.0-12.fc13.x86_64 requires libmpi_cxx.so.0()(64bit) orsa-openmpi-0.7.0-12.fc13.x86_64 requires libopen-pal.so.0()(64bit) paraview-openmpi-3.8.0-4.fc15.x86_64 requires libmpi.so.0()(64bit) paraview-openmpi-3.8.0-4.fc15.x86_64 requires libopen-rte.so.0()(64bit) paraview-openmpi-3.8.0-4.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) paraview-openmpi-3.8.0-4.fc15.x86_64 requires libopen-pal.so.0()(64bit) pypar-openmpi-2.1.4_94-2.fc14.x86_64 requires libmpi.so.0()(64bit) pypar-openmpi-2.1.4_94-2.fc14.x86_64 requires libopen-rte.so.0()(64bit) pypar-openmpi-2.1.4_94-2.fc14.x86_64 requires libopen-pal.so.0()(64bit) python3-mpi4py-openmpi-1.2.2-2.fc15.x86_64 requires libopen-pal.so.0()(64bit) python3-mpi4py-openmpi-1.2.2-2.fc15.x86_64 requires libmpi.so.0()(64bit) python3-mpi4py-openmpi-1.2.2-2.fc15.x86_64 requires libopen-rte.so.0()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires libparrot.so.2.7.0()(64bit) scalapack-openmpi-1.7.5-10.fc14.x86_64 requires libopen-rte.so.0()(64bit) scalapack-openmpi-1.7.5-10.fc14.x86_64 requires libmpi.so.0()(64bit) scalapack-openmpi-1.7.5-10.fc14.x86_64 requires libopen-pal.so.0()(64bit) stardict-3.0.1-21.fc13.x86_64 requires libgucharmap.so.7()(64bit) totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0 totem-2.90.5-5.fc15.x86_64 requires libpeasui-1.0.so.0()(64bit) totem-youtube-2.90.5-5.fc15.x86_64 requires libgdata.so.7()(64bit) towhee-openmpi-6.2.12-1.fc15.x86_64 requires libmpi.so.0()(64bit) towhee-openmpi-6.2.12-1.fc15.x86_64 requires libopen-rte.so.0()(64bit) towhee-openmpi-6.2.12-1.fc15.x86_64 requires libmpi_f77.so.0()(64bit) towhee-openmpi-6.2.12-1.fc15.x86_64 requires libopen-pal.so.0()(64bit) 1:valgrind-openmpi-3.5.0-18.fc14.x86_64 requires libopen-rte.so.0()(64bit) 1:valgrind-openmpi-3.5.0-18.fc14.x86_64 requires libmpi.so.0()(64bit) 1:valgrind-openmpi-3.5.0-18.fc14.x86_64 requires libopen-pal.so.0()(64bit)
Broken deps for i386 ---------------------------------------------------------- R-RScaLAPACK-0.6.1-4.fc14.i686 requires libopen-pal.so.0 R-RScaLAPACK-0.6.1-4.fc14.i686 requires libopen-rte.so.0 R-RScaLAPACK-0.6.1-4.fc14.i686 requires libmpi.so.0 ScientificPython-2.8-11.fc14.i686 requires libopen-pal.so.0 ScientificPython-2.8-11.fc14.i686 requires libmpi.so.0 ScientificPython-2.8-11.fc14.i686 requires libopen-rte.so.0 blacs-openmpi-1.1-39.fc14.i686 requires libopen-pal.so.0 blacs-openmpi-1.1-39.fc14.i686 requires libmpi.so.0 blacs-openmpi-1.1-39.fc14.i686 requires libopen-rte.so.0 blacs-openmpi-1.1-39.fc14.i686 requires libmpi_f77.so.0 boost-graph-openmpi-1.44.0-1.fc15.i686 requires libopen-pal.so.0 boost-graph-openmpi-1.44.0-1.fc15.i686 requires libopen-rte.so.0 boost-graph-openmpi-1.44.0-1.fc15.i686 requires libmpi.so.0 boost-graph-openmpi-1.44.0-1.fc15.i686 requires libmpi_cxx.so.0 boost-openmpi-1.44.0-1.fc15.i686 requires libopen-pal.so.0 boost-openmpi-1.44.0-1.fc15.i686 requires libopen-rte.so.0 boost-openmpi-1.44.0-1.fc15.i686 requires libmpi.so.0 boost-openmpi-1.44.0-1.fc15.i686 requires libmpi_cxx.so.0 boost-openmpi-python-1.44.0-1.fc15.i686 requires libopen-pal.so.0 boost-openmpi-python-1.44.0-1.fc15.i686 requires libmpi.so.0 boost-openmpi-python-1.44.0-1.fc15.i686 requires libopen-rte.so.0 boost-openmpi-python-1.44.0-1.fc15.i686 requires libmpi_cxx.so.0 clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 0:1.3.0 dreampie-python3-1.1-5.fc14.noarch requires python(abi) = 0:3.1 empathy-2.32.0-1.fc15.i686 requires libcamel-1.2.so.19 eog-plugins-2.30.0-2.fc14.i686 requires libgdata.so.7 freefem++-3.9-2.1.fc15.i686 requires libopen-pal.so.0 freefem++-3.9-2.1.fc15.i686 requires libmpi.so.0 freefem++-3.9-2.1.fc15.i686 requires libopen-rte.so.0 freefem++-3.9-2.1.fc15.i686 requires libmpi_cxx.so.0 freefem++-mpi-3.9-2.1.fc15.i686 requires libopen-pal.so.0 freefem++-mpi-3.9-2.1.fc15.i686 requires libmpi.so.0 freefem++-mpi-3.9-2.1.fc15.i686 requires libopen-rte.so.0 freefem++-mpi-3.9-2.1.fc15.i686 requires libmpi_cxx.so.0 1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel >= 0:2.91 1:gnome-games-extra-2.31.91.1-1.fc15.i686 requires libclutter-gtk-0.10.so.0 gnome-pilot-eds-2.32.0-1.fc14.i686 requires libcamel-1.2.so.19 gnome-python2-brasero-2.32.0-1.fc14.i686 requires libbrasero-burn.so.1 gnome-python2-brasero-2.32.0-1.fc14.i686 requires libbrasero-media.so.1 gnome-python2-evince-2.32.0-1.fc14.i686 requires libevdocument.so.3 gnome-python2-evince-2.32.0-1.fc14.i686 requires libevview.so.3 gnome-python2-evolution-2.32.0-1.fc14.i686 requires libcamel-1.2.so.19 gnome-python2-totem-2.32.0-1.fc14.i686 requires libgnome-media-profiles.so.0 gpx-viewer-0.2.0-3.fc14.i686 requires libclutter-gtk-0.10.so.0 gpx-viewer-0.2.0-3.fc14.i686 requires libchamplain-0.6.so.0 gpx-viewer-0.2.0-3.fc14.i686 requires libchamplain-gtk-0.6.so.0 gromacs-openmpi-4.5.1-1.fc15.i686 requires libmpi_cxx.so.0 gromacs-openmpi-4.5.1-1.fc15.i686 requires libopen-pal.so.0 gromacs-openmpi-4.5.1-1.fc15.i686 requires libmpi.so.0 gromacs-openmpi-4.5.1-1.fc15.i686 requires libopen-rte.so.0 hornsey-1.5.2-0.3.fc15.i686 requires libclutter-gtk-0.10.so.0 moblin-panel-status-0.1.21-6.fc14.i686 requires libsocialweb-client.so.1 moblin-panel-status-0.1.21-6.fc14.i686 requires libclutter-gtk-0.10.so.0 moblin-panel-status-0.1.21-6.fc14.i686 requires libchamplain-0.6.so.0 mpi4py-openmpi-1.2.2-2.fc15.i686 requires libopen-pal.so.0 mpi4py-openmpi-1.2.2-2.fc15.i686 requires libmpi.so.0 mpi4py-openmpi-1.2.2-2.fc15.i686 requires libopen-rte.so.0 orsa-openmpi-0.7.0-12.fc13.i686 requires libopen-pal.so.0 orsa-openmpi-0.7.0-12.fc13.i686 requires libopen-rte.so.0 orsa-openmpi-0.7.0-12.fc13.i686 requires libmpi.so.0 orsa-openmpi-0.7.0-12.fc13.i686 requires libmpi_cxx.so.0 paraview-openmpi-3.8.0-4.fc15.i686 requires libopen-pal.so.0 paraview-openmpi-3.8.0-4.fc15.i686 requires libmpi.so.0 paraview-openmpi-3.8.0-4.fc15.i686 requires libmpi_cxx.so.0 paraview-openmpi-3.8.0-4.fc15.i686 requires libopen-rte.so.0 pypar-openmpi-2.1.4_94-2.fc14.i686 requires libopen-pal.so.0 pypar-openmpi-2.1.4_94-2.fc14.i686 requires libmpi.so.0 pypar-openmpi-2.1.4_94-2.fc14.i686 requires libopen-rte.so.0 python3-mpi4py-openmpi-1.2.2-2.fc15.i686 requires libopen-pal.so.0 python3-mpi4py-openmpi-1.2.2-2.fc15.i686 requires libmpi.so.0 python3-mpi4py-openmpi-1.2.2-2.fc15.i686 requires libopen-rte.so.0 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rakudo-0.0.2010.08_2.7.0-1.fc14.i686 requires libparrot.so.2.7.0 scalapack-openmpi-1.7.5-10.fc14.i686 requires libopen-pal.so.0 scalapack-openmpi-1.7.5-10.fc14.i686 requires libmpi.so.0 scalapack-openmpi-1.7.5-10.fc14.i686 requires libopen-rte.so.0 stardict-3.0.1-21.fc13.i686 requires libgucharmap.so.7 totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0 totem-youtube-2.90.5-5.fc15.i686 requires libgdata.so.7 towhee-openmpi-6.2.12-1.fc15.i686 requires libopen-pal.so.0 towhee-openmpi-6.2.12-1.fc15.i686 requires libmpi.so.0 towhee-openmpi-6.2.12-1.fc15.i686 requires libopen-rte.so.0 towhee-openmpi-6.2.12-1.fc15.i686 requires libmpi_f77.so.0 1:valgrind-openmpi-3.5.0-18.fc14.i686 requires libopen-pal.so.0 1:valgrind-openmpi-3.5.0-18.fc14.i686 requires libmpi.so.0 1:valgrind-openmpi-3.5.0-18.fc14.i686 requires libopen-rte.so.0
New package: ding-libs-0.1.2-3.fc15 "Ding is not GLib" assorted utility libraries
New package: rubygem-rack-accept-0.4.3-5.fc15 HTTP Accept* for Ruby/Rack
New package: sisu-1.4.2-2.fc15 Sonatype dependency injection framework
Updated Packages:
TurboGears2-2.1-0.4.rc1.fc15 ---------------------------- * Mon Oct 18 2010 Luke Macken lmacken@redhat.com - 2.1-0.4.rc1 - Add a patch to fix a helpers import issue - This brings our package up to speed with the latest RC1 release
anaconda-15.3-1.fc15 -------------------- * Mon Oct 18 2010 Chris Lumens clumens@redhat.com - 15.3-1 - Don't recommend /usr as a mount point anymore (#643640). (clumens) - Add some debugging prints. (clumens) - Don't prompt for kbd, lang, or network on CD/DVD installs. (clumens) - We no longer need to copy the install.img over and lochangefd to it. (clumens) - Also rework image loading for CD/DVD installs. (clumens) - Remove a bunch of unused support functions. (clumens) - Use parseDeviceAndDir instead of reimplementing the same things two more times. (clumens) - Rework how image loading works for HD installs. (clumens) - Remove the unused mountNfsImage and all code that was only called by it. (clumens) - Rework how image loading works for NFS installs. (clumens) - Remove the unused iurlinfo, urlInstallData, and fix up URL kickstarts. (clumens) - Initialize loaderData->method. (clumens) - Remove the unused mountUrlImage function. (clumens) - Rework how loading images works for URL installs. (clumens) - urlinstTransfer and support functions do not operate on iurlinfo anymore. (clumens) - urlMainSetupPanel no longer takes an iurlinfo. (clumens) - Deprecate stage2=, keep method= as it's been for a long time now. (clumens) - migrate_runtime_directory no longer does anything useful. (clumens) - Remove the method selection block from the beginning of doLoaderMain. (clumens) - Fix up copying of firmware. (clumens) - Correct paths of things started by loader/init that have moved. (clumens) - Step 3 of merging installer images: No longer create install.img. (clumens) - makeinstimage is no longer used. (clumens) - instbin is no longer used. (clumens) - A couple minor changes to mk-images. (clumens) - Step 2 of merging installer images: Move most everything out of makeinitrd. (clumens) - Step 1 of merging installer images: Don't copy files into a new root. (clumens) - No longer do the bin -> usr/bin copy song and dance. (clumens) - Fix typo in examine_gui.py (bcl) - Clean up tabs in examine_gui.py (bcl) - Rework proxy handling so that .treeinfo also uses proxy (#634655) (bcl) - Translate task and repo names based on the product.img (#622064). (clumens) - Use baseurl instead of methodstr to get .treeinfo (#604246) (rvykydal) - Be more resilient to config files missing sections and options (#590591). (clumens) - Add repos for all addons in all enabled repositories (#580697). (clumens) - Add a method that fetches and returns the .treeinfo file. (clumens) - All uses of perl must die. (clumens)
apache-commons-configuration-1.6-3.fc15 --------------------------------------- * Thu Oct 14 2010 Stanislav Ochotnicky sochotnicky@redhat.com - 1.6-3 - tomcat5 -> tomcat6 BRs/Rs - jakarta -> apache BRs/Rs
archivemail-0.8.2-1.fc15 ------------------------ * Mon Oct 18 2010 Jon Ciesla limb@jcomserv.net 0.8.2-1 - New upstream release.
asterisk-sounds-core-1.4.20-1.fc15 ---------------------------------- * Mon Oct 18 2010 Jeffrey C. Ollie jeff@ocjtech.us - 1.4.20-1 - Update to 1.4.20 - Add en_AU sounds
bash-4.1.9-2.fc15 ----------------- * Fri Oct 15 2010 Ville Skyttä ville.skytta@iki.fi - 4.1.9-2 - Move doc dir ownership to main package. - Preserve doc timestamps. - Add --without tests option for building without running the test suite.
bit-0.4.90-11.fc14.1 -------------------- * Fri Oct 08 2010 Jesse Keating jkeating@redhat.com - 0.4.90-11.1 - Rebuild for gcc bug 634757
* Thu Sep 16 2010 Rick L Vinyard Jr rvinyard@cs.nmsu.edu - 0.4.90-11 - Patch for changes to g++ C++0x in f14 - Fix obsoletes by lowering version to 0.4.90 from 0.5.0
bogl-0.1.18-18.fc15 ------------------- * Mon Oct 18 2010 Vitezslav Crhonek vcrhonek@redhat.com - 0:0.1.18-18 - Remove bterm terminfo entry (it's shipped already in ncurses-base) Resolves: #622160 - Fix source URL, add dist tag
cdrkit-1.1.11-1.fc15 -------------------- * Mon Oct 18 2010 Nikola Pajkovsky npajkovs@redhat.com 1.1.11-1 - new upstream version 1.1.11
clipsmm-0.1.0-4.fc14.1 ---------------------- * Fri Oct 08 2010 Jesse Keating jkeating@redhat.com - 0.1.0-4.1 - Rebuild for gcc bug 634757
* Thu Sep 16 2010 Rick L Vinyard Jr rvinyard@cs.nmsu.edu - 0.1.0-4 - Patch for changes to g++ C++0x in f14
* Tue Mar 09 2010 Rick L Vinyard Jr rvinyard@cs.nmsu.edu - 0.1.0-3 - Add libtermcap dependency for Fedora <= 9 and EL <= 5
cobbler-2.0.7-1.fc15 -------------------- * Mon Oct 18 2010 Scott Henson shenson@redhat.com - 2.0.7-1 - Bug fix relase, see Changelog for details
dbus-cxx-0.7.0-2.fc14.1 ----------------------- * Fri Oct 08 2010 Jesse Keating jkeating@redhat.com - 0.7.0-2.1 - Rebuild for gcc bug 634757
* Thu Sep 16 2010 Rick L Vinyard Jr rvinyard@cs.nmsu.edu - 0.7.0-2 - Patch for changes to g++ C++0x in f14
desktopcouch-0.6.9b-1.fc15 -------------------------- * Mon Oct 18 2010 Jeffrey C. Ollie jeff@ocjtech.us - 0.6.9b-1 - Update to 0.6.9b
eclipse-changelog-2.6.7-5.fc15 ------------------------------ * Fri Oct 15 2010 Chris Aniszczyk zx@redhat.com 1:2.6.7-6 - Update to Linux Tools 0.6.1 release.
evolution-2.91.1-1.fc15 ----------------------- * Mon Oct 18 2010 Milan Crha mcrha@redhat.com - 2.91.1-1 - Update to 2.91.1
evolution-data-server-2.91.1-1.fc15 ----------------------------------- * Mon Oct 18 2010 Milan Crha mcrha@redhat.com - 2.91.1-1 - Update to 2.91.1
evolution-exchange-2.91.1-1.fc15 -------------------------------- * Mon Oct 18 2010 Milan Crha mcrha@redhat.com - 2.91.1-1 - Update to 2.91.1
evolution-mapi-2.91.1-1.fc15 ---------------------------- * Mon Oct 18 2010 Milan Crha mcrha@redhat.com - 2.91.1-1 - Update to 2.91.1
fedora-packager-0.5.1.4-7.fc15 ------------------------------ * Mon Oct 18 2010 Dan Horák <dan[at]danny.cz> - 0.5.1.4-7 - revert the last change as %ifarch doesn't work with noarch packages and I also got ykpers built on s390(x)
* Mon Oct 18 2010 Dan Horák <dan[at]danny.cz> - 0.5.1.4-6 - don't Require ykpers and don't install fedora-burn-yubikey on s390(x)
fonttools-2.3-2.fc15 -------------------- * Tue Oct 19 2010 Akira TAGOH tagoh@redhat.com - 2.3-2 - Rebuild.
* Fri Jul 23 2010 Akira TAGOH tagoh@redhat.com - 2.3-1 - New upstream release. (Paul Williams, #599281) - drop upstreamed patch. - correct man page location. - Update the spec file to keep consistensy of usage in the macro as far as possible.
fpaste-0.3.5-1.fc15 ------------------- * Mon Oct 18 2010 Ankur Sinha <ankursinha AT fedoraproject DOT org> - 0.3.5-1 - New maintenance release - --sysinfo: detect running and installed Desktop Environment(s) - --sysinfo: Show filesystem type in df -hT output - --sysinfo: Smolt fixed, GL and other additions. by Francois Cami - --sysinfo: Optimized: rpm -qa --list --nodigest --nosignature. by Dave Riches
gnupg-1.4.11-1.fc15 ------------------- * Mon Oct 18 2010 Brian C. Lane bcl@redhat.com 1.4.11-1 - New upstream v1.4.11 - Dropped patch gnupg-1.4.6-dir.patch, now in upstream
gpm-1.20.6-12.fc15 ------------------ * Mon Oct 18 2010 Nikola Pajkovsky npajkovs@redhat.com 2.20.6-12 - disable debuging mode in gpm.service
gtk-vnc-0.4.1-9.fc15 -------------------- * Mon Oct 18 2010 Colin Walters walters@verbum.org - 0.4.1-9 - Rebuild to use old pygobject2-python2 API again: https://bugzilla.redhat.com/show_bug.cgi?id=638457
gtkhtml3-3.91.1-1.fc15 ---------------------- * Mon Oct 18 2010 Milan Crha mcrha@redhat.com - 3.91.1-1 - Update to 3.91.1
hplip-3.10.9-3.fc15 ------------------- * Mon Oct 18 2010 Tim Waugh twaugh@redhat.com - 3.10.9-3 - Fixed traceback on error condition in device.py (bug #628125). - Fixed bogus low ink warnings from hpijs driver (bug #643643).
ibus-anthy-1.2.3-2.fc15 ----------------------- * Mon Oct 18 2010 Takao Fujiwara tfujiwar@redhat.com - 1.2.3-2 - Fixed thumb-shift key table customization.
* Sat Oct 16 2010 Takao Fujiwara tfujiwar@redhat.com - 1.2.3-1 - Updated to 1.2.3 - Updated translations.
ipmiutil-2.7.1-1.fc15 --------------------- * Fri Oct 15 2010 Andrew Cress <arcress at users.sourceforge.net> 2.7.1-1 skip chkconfig --add if not Red Hat
* Mon Sep 27 2010 Andrew Cress <arcress at users.sourceforge.net> 2.7.0-1 added fwum, hpm, sunoem, ekanalyzer man pages
ipython-0.10.1-2.fc15 --------------------- * Mon Oct 18 2010 Thomas Spura tomspur@fedoraproject.org - 0.10.1-2 - argparse is in python 2.7 and 3.2
kernel-2.6.36-0.40.rc8.git0.fc15 -------------------------------- * Mon Oct 18 2010 Kyle McMartin kyle@redhat.com 2.6.36-0.40.rc8.git0 - Backport xHCI suspend/resume code from linux-next.
* Mon Oct 18 2010 Kyle McMartin kyle@redhat.com - ima: Default it to off, pass ima=on to enable. Reduce impact of the option when disabled.
* Mon Oct 18 2010 Kyle McMartin kyle@redhat.com - Quirk to disable DMAR with Ricoh card reader/firewire. (rhbz#605888)
* Fri Oct 15 2010 Kyle McMartin kyle@redhat.com - Switched to pci=use_crs by default (it should have been fixed since cebbert sucked in the patches anyway.)
* Fri Oct 15 2010 Kyle McMartin kyle@redhat.com - backport pnpacpi-cope-with-invalid-device-ids from linux-next. (rhbz#641468)
konversation-1.3.1-2.fc15 ------------------------- * Mon Oct 18 2010 Thomas Janssen thomasj@fedoraproject.org 1.3.1-2 - added patch to fix scrolling background
ktorrent-4.0.4-1.fc15 --------------------- * Mon Oct 18 2010 Rex Dieter rdieter@fedoraproject.org - 4.0.4-1 - ktorrent-4.0.4
libgdata-0.7.0-1.fc15 --------------------- * Mon Oct 18 2010 Bastien Nocera bnocera@redhat.com 0.7.0-1 - Update to 0.7.0
* Wed Sep 29 2010 jkeating - 0.6.4-6 - Rebuilt for gcc bug 634757
libktorrent-1.0.4-1.fc15 ------------------------ * Mon Oct 18 2010 Rex Dieter rdieter@fedoraproject.org - 1.0.4-1 - libktorrent-1.0.4
libmusicbrainz3-3.0.3-2.fc15 ---------------------------- * Mon Oct 18 2010 Rex Dieter rdieter@fedoraproject.rog 3.0.3-2 - libmusicbrainz3-devel multilib conflict (#480378) - drop extraneous pkgconfig dep baggage
* Mon Oct 18 2010 Bastien Nocera bnocera@redhat.com 3.0.3-1 - Update to 3.0.3 (#643789)
libwmf-0.2.8.4-27.fc15 ---------------------- * Mon Oct 18 2010 Parag Nemade <paragn AT fedoraproject.org> - 0.2.8.4-27 - Merge-review cleanup (#226058)
lohit-kannada-fonts-2.4.5-3.fc15 -------------------------------- * Mon Oct 18 2010 Pravin Satpute psatpute@redhat.com - 2.4.5-3 - fixed bug 576105
man-pages-ja-20100415-6.fc15 ---------------------------- * Mon Oct 18 2010 Akira TAGOH tagoh@redhat.com - 20100415-6 - Get rid of man.1 again. (#643803)
mingw32-qt-qmake-4.7.0-3.fc15 ----------------------------- * Mon Oct 18 2010 Erik van Pienbroek epienbro@fedoraproject.org - 4.7.0-3 - Use the name 'win32-g++-cross' instead of 'win32-g++-fedora-cross' as mkspecs platform name as was decided on the mailing list. The previous rename was invalid
mozilla-noscript-2.0.3.5-1.fc15 ------------------------------- * Mon Oct 18 2010 Thomas Spura tomspur@fedoraproject.org - 2.0.3.5-1 - update to new version - renew patch
nss-3.12.8-6.fc15 ----------------- * Mon Oct 18 2010 Elio Maldonado emaldona@redhat.com - 3.12.8-6 - Fix certificates trust order (#643134) - Apply nss-sysinit-userdb-first.patch last
numactl-2.0.5-1.fc15 -------------------- * Mon Oct 18 2010 Neil Horman nhorman@redhat.com - 2.0.5-1 - Update to latest stable upstream source
openmpi-1.5-1.fc15 ------------------ * Mon Oct 18 2010 Jay Fenlason fenlason@redhat.com 1.5-1 - set MANPATH in openmpi module file - Upgrade to 1.5 - Workaround for rhbz#617766 appears to no longer be needed for 1.5 - remove pkgconfig files in instal - Remove orteCC.1 dangling symlink - Adjust the files entries for share/openmpi/help* and share/openmpi/mca* - Adjust the files entries for share/openmpi/mpi* - Add files entry for share/openmpi/orte*.txt
pam_yubico-2.4-1.fc15 --------------------- * Mon Oct 18 2010 Dennis Gilmore dennis@ausil.us - 2.4-1 - update to 2.4 - fixes crashing bug
papyrus-0.13.3-2.fc14.1 ----------------------- * Fri Oct 08 2010 Jesse Keating jkeating@redhat.com - 0.13.3-2.1 - Rebuild for gcc bug 634757
* Tue Sep 14 2010 Rick L Vinyard Jr rvinyard@cs.nmsu.edu - 0.13.3-2 - Patch for changes to g++ C++0x in f14
perl-Date-Manip-6.13-1.fc15 --------------------------- * Mon Oct 18 2010 Petr Sabata psabata@redhat.com - 6.13-1 - 6.13 bump
perl-HTML-Tree-4.00-1.fc15 -------------------------- * Mon Oct 18 2010 Marcela Mašláňová mmaslano@redhat.com - 1:3.40-1 - update, adjust specfile to use Build.PL
perl-PPIx-Regexp-0.014-1.fc15 ----------------------------- * Mon Oct 18 2010 Petr Pisar ppisar@redhat.com - 0.014-1 - 0.014 bump
perl-Package-DeprecationManager-0.09-1.fc15 ------------------------------------------- * Mon Oct 18 2010 Paul Howarth paul@city-fan.org - 0.09-1 - Update to 0.09: - Added a compilation test
perl-Test-EOL-0.9-2.fc15 ------------------------ * Mon Oct 18 2010 Paul Howarth paul@city-fan.org 0.9-2 - Don't assume tested files are UTF-8 encoded (CPAN RT#59877)
perl-Text-CSV_XS-0.76-1.fc15 ---------------------------- * Mon Oct 18 2010 Petr Sabata psabata@redhat.com - 0.76-1 - 0.76 version bump
procps-3.2.8-14.fc15 -------------------- * Tue Oct 19 2010 Jan Görig jgorig@redhat.com 3.2.8-14 - added devel package (Hicham HAOUARI hicham.haouari@gmail.com)
python-cheetah-2.4.3-1.fc15 --------------------------- * Mon Oct 18 2010 Mike Bonnet mikeb@redhat.com - 2.4.3-1 - update to the 2.4.3 release
* Mon Oct 18 2010 Mike Bonnet mikeb@redhat.com - 2.4.2.1-3 - Fix compatibility with Python 2.7
qbittorrent-2.4.6-1.fc15 ------------------------ * Mon Oct 18 2010 leigh scott leigh123linux@googlemail.com - 1:2.4.6-1 - update to 2.4.6
rygel-0.9.1-1.fc15 ------------------ * Mon Oct 18 2010 Peter Robinson pbrobinson@gmail.com 0.9.1-1 - New 0.9.1 dev release
seahorse-2.91.1-1.fc15 ---------------------- * Mon Oct 18 2010 Tomas Bzatek tbzatek@redhat.com 2.91.1-1 - Update to 2.91.1
selinux-policy-3.9.7-4.fc15 --------------------------- * Fri Oct 15 2010 Dan Walsh dwalsh@redhat.com 3.9.7-4 - Allow sandbox_x_domains to work with nfs/cifs/fusefs home dirs.
setroubleshoot-2.2.102-1.fc15 ----------------------------- * Mon Oct 04 2010 Dan Walsh dwalsh@redhat.com - 2.2.102-1 - Remove default width request so that the app can expand with different langs.
* Mon Oct 04 2010 Dan Walsh dwalsh@redhat.com - 2.2.101-1 - Fix date presentation for 24 hour clock to display correctly in sv_SE locale. - Add translations for seapplet patch from Ville-Pekka Vainio
* Wed Sep 29 2010 Dan Walsh dwalsh@redhat.com - 2.2.100-1 - Stop crash on checking open_with_write
* Wed Sep 22 2010 Dan Walsh dwalsh@redhat.com - 2.2.99-1 - Fix plugin.py error
* Tue Sep 14 2010 Dan Walsh dwalsh@redhat.com - 2.2.98-1 - Do not blow up on bad /etc/sysconfig/i18n
* Thu Aug 26 2010 Dan Walsh dwalsh@redhat.com - 2.2.97-1 - Make sure all python scripts have #! /usr/bin/python -Es
* Thu Aug 26 2010 Dan Walsh dwalsh@redhat.com - 2.2.96-1 - Check in sealert if selinux is disabled and display message box informing user
* Thu Aug 26 2010 Dan Walsh dwalsh@redhat.com - 2.2.95-1 - Check in seapplet if selinux is disabled and exit cleanly
spice-0.6.3-1.fc15 ------------------ * Mon Oct 18 2010 Hans de Goede hdegoede@redhat.com - 0.6.3-1 - Update to 0.6.3 - Enable GUI
spice-protocol-0.6.3-1.fc15 --------------------------- * Mon Oct 18 2010 Hans de Goede hdegoede@redhat.com - 0.6.3-1 - Update to 0.6.3
sssd-1.4.0-2.fc15 ----------------- * Mon Oct 18 2010 Stephen Gallagher sgallagh@redhat.com - 1.4.0-2 - Fix incorrect tarball URL
* Mon Oct 18 2010 Stephen Gallagher sgallagh@redhat.com - 1.4.0-1 - New upstream release 1.4.0 - Added support for netgroups to the LDAP provider - Performance improvements made to group processing of RFC2307 LDAP servers - Fixed nested group issues with RFC2307bis LDAP servers without a memberOf plugin - Build-system improvements to support Gentoo - Split out several libraries into the ding-libs tarball - Manpage reviewed and updated
totem-pl-parser-2.32.1-1.fc15 ----------------------------- * Mon Oct 18 2010 Bastien Nocera bnocera@redhat.com 2.32.1-1 - Update to 2.32.1
upx-3.07-1.fc15 --------------- * Mon Oct 18 2010 Jon Ciesla limb@jcomserv.net - 3.07-1 - New upstream.
vdr-1.6.0-34.fc15 ----------------- * Mon Oct 18 2010 Ville Skyttä ville.skytta@iki.fi - 1.6.0-34 - Add vdr user to the cdrom (for optical drives) and dialout (for serial port remote controls) groups. - Drop no longer needed pam_console configuration. - Make vdr-i18n-to-gettext more likely to work out of the box. - Update MainMenuHooks patch to 1.0.1. - Update VDR_PLUGIN_ORDER in sysconfig. - Various minor vdr.pc improvements.
volume_key-0.3.4-4.fc15 ----------------------- * Mon Oct 18 2010 Miloslav Trmač mitr@redhat.com - 0.3.4-4 - Tell the user if asking for the same passphrase again Resolves: #641111 - Check certificate file before interacting with the user Resolves: #643897
wine-1.3.5-1.fc15 ----------------- * Mon Oct 18 2010 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de> - 1.3.5-1 - version upgrade
xterm-264-1.fc15 ---------------- * Mon Oct 18 2010 Miroslav Lichvar mlichvar@redhat.com 264-1 - update to 264
Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 67
On 19/10/10 14:11, Rawhide Report wrote:
anaconda-15.3-1.fc15
- Mon Oct 18 2010 Chris Lumensclumens@redhat.com - 15.3-1
- Don't recommend /usr as a mount point anymore (#643640). (clumens)
This despite the FHS says (right at the top of Chapter 3, the Root Filesystem):
/usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.
Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this?
Paul.
On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote:
This despite the FHS says (right at the top of Chapter 3, the Root Filesystem):
/usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.
Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this?
What's the benefit in having /usr or /opt as separate filesystems?
Once upon a time, Matthew Garrett mjg59@srcf.ucam.org said:
On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote:
This despite the FHS says (right at the top of Chapter 3, the Root Filesystem):
/usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.
Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this?
What's the benefit in having /usr or /opt as separate filesystems?
A smaller / that is written to less often is less susceptible to errors. If you don't allocate enough space for / up front, you can move /usr and /opt to separate filesystems later. /opt can be completely unpredictable in space usage, due to vendor RPMs dumping stuff in /opt (see Dell's OMSA, that puts everything, including logs, under /opt).
When disk was expensive, /usr was often the biggest consumer of space, so it would be shared across the network, but that's not a big issue anymore (and RPM doesn't really support shared /usr IIRC).
I personally don't use a separate /usr on desktops, only on servers. On my servers, /usr is mounted read-only, as an extra protection against accidental (or even intentional) screw-ups. It also means that I don't waste I/O cycles on updating atimes on often-used binaries and libraries (which of course could also be done with noatime).
I've seen some boot-from-flash setups with /usr on a hard drive.
Basically, if Fedora is going to follow the FHS at all, bugs like 626007 should be fixed, not ignored because somebody doesn't like a separate /usr.
On Tue, Oct 19, 2010 at 09:24:10AM -0500, Chris Adams wrote:
A smaller / that is written to less often is less susceptible to errors. If you don't allocate enough space for / up front, you can move /usr and /opt to separate filesystems later. /opt can be completely unpredictable in space usage, due to vendor RPMs dumping stuff in /opt (see Dell's OMSA, that puts everything, including logs, under /opt).
So, LVM?
I personally don't use a separate /usr on desktops, only on servers. On my servers, /usr is mounted read-only, as an extra protection against accidental (or even intentional) screw-ups. It also means that I don't waste I/O cycles on updating atimes on often-used binaries and libraries (which of course could also be done with noatime).
mount --bind /usr /usr mount -o ro,remount /usr
I've seen some boot-from-flash setups with /usr on a hard drive.
The rational thing there is for the flash to be /boot, not /.
Basically, if Fedora is going to follow the FHS at all, bugs like 626007 should be fixed, not ignored because somebody doesn't like a separate /usr.
I don't think we gain anything from following the FHS on this point other than the ability to have /usr as a separate partition, and think that's a pretty circular argument.
On Tue, 2010-10-19 at 14:56 +0100, Matthew Garrett wrote:
On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote:
This despite the FHS says (right at the top of Chapter 3, the Root Filesystem):
/usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.
Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this?
What's the benefit in having /usr or /opt as separate filesystems?
/opt is a location filled with vendor detritus on a lot of systems - sometimes managed by rpms, sometimes not. It's not uncommon to have /opt automounted via nfs. Additionally, on some workstastion systems /opt is a separate drive managed by the 'local admin' of the machine and filled with whatever 3rd party software they need for their instance.
/usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system.
Additionally, since our software in fedora has a trickle down impact on users in rhel-land I think you'll find that this will have to be done, eventually for them.
Finally, I'm more than a little concerned by the tone of comments in that bug report. It's troubling.
-sv
On Tue, Oct 19, 2010 at 10:38:13AM -0400, seth vidal wrote:
/opt is a location filled with vendor detritus on a lot of systems - sometimes managed by rpms, sometimes not. It's not uncommon to have /opt automounted via nfs. Additionally, on some workstastion systems /opt is a separate drive managed by the 'local admin' of the machine and filled with whatever 3rd party software they need for their instance.
/opt being network shared seems like a reasonable thing to support.
/usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system.
That doesn't require it to be a separate partition.
Additionally, since our software in fedora has a trickle down impact on users in rhel-land I think you'll find that this will have to be done, eventually for them.
"We have to support it because users want it" is a poor argument. We have to understand why people want it to be a separate partition and then decide whether the simplest way (in terms of overall engineering effort) to support those desires is by supporting it as a separate partition. So far nobody's come up with a terribly plausible reason for why /usr should be separate.
On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote:
/usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system.
That doesn't require it to be a separate partition.
Mounting the location meaningfully as a readonly does. If you're doing it for security reasons.
Additionally, since our software in fedora has a trickle down impact on users in rhel-land I think you'll find that this will have to be done, eventually for them.
"We have to support it because users want it" is a poor argument. We have to understand why people want it to be a separate partition and then decide whether the simplest way (in terms of overall engineering effort) to support those desires is by supporting it as a separate partition. So far nobody's come up with a terribly plausible reason for why /usr should be separate.
I'm confused here - why is it we have to come up with a plausible reason? Why is the burden of proof on KEEPING /usr as a separatable partition?
If I said tomorrow "yum will not support feature foo or bar" that have been in rpm and yum since the dawn of time I'd have to defend my rationale for that change.
So it seems like you need to explain why you think /usr should NOT be on a separate partition.
-sv
On Tue, Oct 19, 2010 at 11:03:50AM -0400, seth vidal wrote:
On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote:
/usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system.
That doesn't require it to be a separate partition.
Mounting the location meaningfully as a readonly does. If you're doing it for security reasons.
It doesn't. You can make it a read-only bind mount.
"We have to support it because users want it" is a poor argument. We have to understand why people want it to be a separate partition and then decide whether the simplest way (in terms of overall engineering effort) to support those desires is by supporting it as a separate partition. So far nobody's come up with a terribly plausible reason for why /usr should be separate.
I'm confused here - why is it we have to come up with a plausible reason? Why is the burden of proof on KEEPING /usr as a separatable partition?
Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase.
If I said tomorrow "yum will not support feature foo or bar" that have been in rpm and yum since the dawn of time I'd have to defend my rationale for that change.
If yum removed features that provided functionality that could be achieved via other means, and in return various other features worked better, I'd be fine with that.
So it seems like you need to explain why you think /usr should NOT be on a separate partition.
Because it adds additional complexity for no obvious gain.
On Tue, 2010-10-19 at 16:08 +0100, Matthew Garrett wrote:
On Tue, Oct 19, 2010 at 11:03:50AM -0400, seth vidal wrote:
On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote:
/usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system.
That doesn't require it to be a separate partition.
Mounting the location meaningfully as a readonly does. If you're doing it for security reasons.
It doesn't. You can make it a read-only bind mount.
If the files are still read-write at another location then something iterating over disks/locations can still find it.
That's what I meant by meaningfully.
I'm confused here - why is it we have to come up with a plausible reason? Why is the burden of proof on KEEPING /usr as a separatable partition?
Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase.
Hmm, So when this was broken a lot of bugs were triggered?
Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase.
You can't have it both ways.
If I said tomorrow "yum will not support feature foo or bar" that have been in rpm and yum since the dawn of time I'd have to defend my rationale for that change.
If yum removed features that provided functionality that could be achieved via other means, and in return various other features worked better, I'd be fine with that.
It's not clear to me that other features work better in the case you're describing and it will mean retooling for what sounds like a good number of users.
So it seems like you need to explain why you think /usr should NOT be on a separate partition.
Because it adds additional complexity for no obvious gain.
that's not plausible enough, imo. There is clear gain to enough users to file a 'number of bugs'.
-sv
On 10/19/2010 11:15 AM, seth vidal wrote:
On Tue, 2010-10-19 at 16:08 +0100, Matthew Garrett wrote:
On Tue, Oct 19, 2010 at 11:03:50AM -0400, seth vidal wrote:
On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote:
/usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system.
That doesn't require it to be a separate partition.
Mounting the location meaningfully as a readonly does. If you're doing it for security reasons.
It doesn't. You can make it a read-only bind mount.
If the files are still read-write at another location then something iterating over disks/locations can still find it.
That's what I meant by meaningfully.
And it's entirely wrong, Seth. They're not at another location in this example.
So it seems like you need to explain why you think /usr should NOT be on a separate partition.
Because it adds additional complexity for no obvious gain.
that's not plausible enough, imo. There is clear gain to enough users to file a 'number of bugs'.
Presumably because they don't know about the other ways to accomplish the same goal that aren't as painful to support?
On Tue, 2010-10-19 at 11:18 -0400, Peter Jones wrote:
So it seems like you need to explain why you think /usr should NOT be on a separate partition.
Because it adds additional complexity for no obvious gain.
that's not plausible enough, imo. There is clear gain to enough users to file a 'number of bugs'.
Presumably because they don't know about the other ways to accomplish the same goal that aren't as painful to support?
Failure to document and explain to our users the virtues of the changes and the different ways of accomplishing those goals then squarely falls on our shoulders, Peter.
-sv
On 10/19/2010 11:22 AM, seth vidal wrote:
On Tue, 2010-10-19 at 11:18 -0400, Peter Jones wrote:
So it seems like you need to explain why you think /usr should NOT be on a separate partition.
Because it adds additional complexity for no obvious gain.
that's not plausible enough, imo. There is clear gain to enough users to file a 'number of bugs'.
Presumably because they don't know about the other ways to accomplish the same goal that aren't as painful to support?
Failure to document and explain to our users the virtues of the changes and the different ways of accomplishing those goals then squarely falls on our shoulders, Peter.
Absolutely.
On Tue, Oct 19, 2010 at 11:15:02AM -0400, seth vidal wrote:
On Tue, 2010-10-19 at 16:08 +0100, Matthew Garrett wrote:
It doesn't. You can make it a read-only bind mount.
If the files are still read-write at another location then something iterating over disks/locations can still find it.
That's what I meant by meaningfully.
So do this at the top of init. It's still better than having /usr be entirely separate.
Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase.
Hmm, So when this was broken a lot of bugs were triggered?
Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase.
You can't have it both ways.
Very few people do it. When they do, lots of things break. It's kind of like trying to run Fedora under the NetBSD Linux emulation. Nobody does it, but if they did they'd find that a surprising quantity of code wouldn't work.
If yum removed features that provided functionality that could be achieved via other means, and in return various other features worked better, I'd be fine with that.
It's not clear to me that other features work better in the case you're describing and it will mean retooling for what sounds like a good number of users.
Every Fedora update requires significant retooling. The fact that these bugs exist indicates that there would be advantages to not supporting this, providing that in return we can satisfy all the existing user requirements. "/usr is a separate partition" is *not* a meaningful user requirement, any more than "Fedora release names must start with a consonant". If we can provide better and more generalisable solutions for their requirements then that's a win for everyone.
On Tue, 2010-10-19 at 16:22 +0100, Matthew Garrett wrote:
Hmm, So when this was broken a lot of bugs were triggered?
Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase.
You can't have it both ways.
Very few people do it. When they do, lots of things break. It's kind of like trying to run Fedora under the NetBSD Linux emulation. Nobody does it, but if they did they'd find that a surprising quantity of code wouldn't work.
you keep asserting this claim - and yet all the evidence in terms of concerned users comes to the contrary.
Can you document or backup your assertion?
Every Fedora update requires significant retooling. The fact that these bugs exist indicates that there would be advantages to not supporting this, providing that in return we can satisfy all the existing user requirements. "/usr is a separate partition" is *not* a meaningful user requirement, any more than "Fedora release names must start with a consonant". If we can provide better and more generalisable solutions for their requirements then that's a win for everyone.
Again - I'm going to ask you to stop making that assertion. You're stating it as an established fact when it is CLEARLY the point in contention.
-sv
On 10/19/2010 11:25 AM, seth vidal wrote:
On Tue, 2010-10-19 at 16:22 +0100, Matthew Garrett wrote:
Hmm, So when this was broken a lot of bugs were triggered?
Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase.
You can't have it both ways.
Very few people do it. When they do, lots of things break. It's kind of like trying to run Fedora under the NetBSD Linux emulation. Nobody does it, but if they did they'd find that a surprising quantity of code wouldn't work.
you keep asserting this claim - and yet all the evidence in terms of concerned users comes to the contrary.
Can you document or backup your assertion?
This seems like a question smolt should be able to answer...
Nathaniel
On Tue, 19 Oct 2010, Nathaniel McCallum wrote:
On 10/19/2010 11:25 AM, seth vidal wrote:
On Tue, 2010-10-19 at 16:22 +0100, Matthew Garrett wrote:
Hmm, So when this was broken a lot of bugs were triggered?
Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase.
You can't have it both ways.
Very few people do it. When they do, lots of things break. It's kind of like trying to run Fedora under the NetBSD Linux emulation. Nobody does it, but if they did they'd find that a surprising quantity of code wouldn't work.
you keep asserting this claim - and yet all the evidence in terms of concerned users comes to the contrary.
Can you document or backup your assertion?
This seems like a question smolt should be able to answer...
This is what is currently in the wild for /usr:
mysql> select mnt_pnt,count(*) as cnt from file_systems where mnt_pnt like '/usr%' group by mnt_pnt order by cnt; +-------------------+-------+ | mnt_pnt | cnt | +-------------------+-------+ | /usr/share/dict | 1 | | /usr/src/debug | 1 | | /usr/tmp | 1 | | /usr/share/icons | 1 | | /usr/local/sbin | 1 | | /usr/sbin | 2 | | /usr/include | 2 | | /usr/src/packages | 3 | | /usr/local/bin | 5 | | /usr/X11R6 | 6 | | /usr/local/share | 9 | | /usr/bin | 11 | | /usr/share/doc | 14 | | /usr/games | 16 | | /usr/lib64 | 30 | | /usr/local/src | 33 | | /usr/lib | 41 | | /usr/local/games | 43 | | /usr/share | 163 | | /usr/src | 329 | | /usr/local | 12814 | | /usr | 37171 | +-------------------+-------+ 22 rows in set (3.25 sec)
This is out of 1,702,459 submissions of profiles that included filesystem data. So about 3% of users have something mounted in /usr and about 2.2% have /usr mounted directly.
-Mike
On Tue, Oct 19, 2010 at 11:43:49AM -0500, Mike McGrath wrote:
This is out of 1,702,459 submissions of profiles that included filesystem data. So about 3% of users have something mounted in /usr and about 2.2% have /usr mounted directly.
Given that you have to go out of your way to do it, that's a pretty significant number.
On 10/19/2010 01:01 PM, Matthew Miller wrote:
On Tue, Oct 19, 2010 at 11:43:49AM -0500, Mike McGrath wrote:
This is out of 1,702,459 submissions of profiles that included filesystem data. So about 3% of users have something mounted in /usr and about 2.2% have /usr mounted directly.
Given that you have to go out of your way to do it, that's a pretty significant number.
Yes and no - I'm curious as to how this number will change without anaconda recommending that it's a thing you might want to do. I think there's a sizeable contention that creates mountpoints out of habbit, not any specific need or requirement, and it only stands to reason that some people must be choosing which ones to create based on the list in front of them. It'll be interesting to see how that number changes once we no longer have it on anaconda's list - that should show us how many people actually have a specific desire for /usr to be separate.
That is - Chris's anaconda change may allow us to collect data on just how many people /usr being separate is *actually* important to. We still won't know why, though.
Once upon a time, Matthew Garrett mjg59@srcf.ucam.org said:
Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase.
And how many of those bugs are exclusively a /usr-is-separate problem vs. how many of them are didn't-anticipate-alternate-partitioning problems? I don't understand how separate /usr can be the sole trigger for all these many bugs. The only type of bug I can see attributed only to separate /usr are bootup requiring things in /usr before non-root filesystems are mounted.
I expect other bugs attributed to separate /usr are really problems handling non-default partitioning schemes of many kinds.
On 10/19/2010 11:28 AM, Chris Adams wrote:
Once upon a time, Matthew Garrett mjg59@srcf.ucam.org said:
Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase.
And how many of those bugs are exclusively a /usr-is-separate problem vs. how many of them are didn't-anticipate-alternate-partitioning problems?
If I understand your distinction correctly, then the overwhelming majority of them are the former.
I don't understand how separate /usr can be the sole trigger for all these many bugs. The only type of bug I can see attributed only to separate /usr are bootup requiring things in /usr before non-root filesystems are mounted.
And that's exactly what gets hit over and over.
I expect other bugs attributed to separate /usr are really problems handling non-default partitioning schemes of many kinds.
There aren't a lot of other bugs about it.
Once upon a time, Peter Jones pjones@redhat.com said:
On 10/19/2010 11:28 AM, Chris Adams wrote:
And how many of those bugs are exclusively a /usr-is-separate problem vs. how many of them are didn't-anticipate-alternate-partitioning problems?
If I understand your distinction correctly, then the overwhelming majority of them are the former.
The one that led to this discussion (626007) doesn't seem to be.
The "/usr/sbin/foo is needed before FSes are mounted" is a fairly trivial problem to solve in the majority of cases; I don't see that as a big deal.
If separate /usr isn't considered a valid configuration, why do we have separate /bin, /sbin, /lib{,64}?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/19/2010 11:25 AM, Chris Adams wrote:
If separate /usr isn't considered a valid configuration, why do we have separate /bin, /sbin, /lib{,64}?
Today it isn't necessarily valid. Things do progress, and the reasons for separate /usr back in the day may be more easily solvable without an actual separate /usr. As for /bin vs /usr/bin and lib vs /usr/lib these are all "fallout" from making /usr/ a separate system, fallout that can be removed and complexity that can be reduced.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On 10/19/2010 02:25 PM, Chris Adams wrote:
Once upon a time, Peter Jones pjones@redhat.com said:
On 10/19/2010 11:28 AM, Chris Adams wrote:
And how many of those bugs are exclusively a /usr-is-separate problem vs. how many of them are didn't-anticipate-alternate-partitioning problems?
If I understand your distinction correctly, then the overwhelming majority of them are the former.
The one that led to this discussion (626007) doesn't seem to be.
Indeed.
The "/usr/sbin/foo is needed before FSes are mounted" is a fairly trivial problem to solve in the majority of cases; I don't see that as a big deal.
If separate /usr isn't considered a valid configuration, why do we have separate /bin, /sbin, /lib{,64}?
Because we haven't decided to merge those together. That's really the only reason - there's no over-arching technical reason they need to be separate. It's entirely a historical consideration.
Peter Jones (pjones@redhat.com) said:
Because we haven't decided to merge those together. That's really the only reason - there's no over-arching technical reason they need to be separate. It's entirely a historical consideration.
Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, and so on were just symlinks to /usr/bin, /usr/lib, and so on.
Bill
Once upon a time, Bill Nottingham notting@redhat.com said:
Peter Jones (pjones@redhat.com) said:
Because we haven't decided to merge those together. That's really the only reason - there's no over-arching technical reason they need to be separate. It's entirely a historical consideration.
Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, and so on were just symlinks to /usr/bin, /usr/lib, and so on.
On Tru64 (aka Digital Unix aka OSF/1 aka ...), /bin is a symlink to /usr/bin, and /lib to /usr/lib (but shared libraries are in /shlib and /usr/shlib, and they are separate; the lib directory is primarily for compiling). All the stuff needed for early booting is in /sbin (separate from /usr/sbin).
I don't even think you can install with /usr (or /var) on the same filesystem as /. However, with AdvFS, the root file domain is special (with extra restrictions due to the bootloader and other things), so you really don't want anything else in there.
On Tue, Oct 19, 2010 at 19:58, Bill Nottingham notting@redhat.com wrote:
Peter Jones (pjones@redhat.com) said:
Because we haven't decided to merge those together. That's really the only reason - there's no over-arching technical reason they need to be separate. It's entirely a historical consideration.
Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, and so on were just symlinks to /usr/bin, /usr/lib, and so on.
There were several depending on how it was implemented. The Convex I remember having a minimal /etc and /bin and then mounting the real ones later in the boot but really in /usr/etc, /usr/bin etc. The OSF/1 systems I think did it with symlinks.
But out of the weeds.. the big areas I know were using separate /usr with Fedora were disk-less systems. The /usr , /opt and some other items were NFS mounted from a central system. It was mostly a relic of how Sun had done it in the good old days but no one had come up with a better 'supported' way and so it was still in use til quite recently.
/usr ends up being mounted separate mostly for business case reasons. The compliance documents say /usr on all systems in some place must be a seperate partition and until they get updated that is how it will be. On other areas it is separated out because the business software requires it or it won't install. [Yes brain dead but it is what it is.] Neither of those are really in Fedora's sphere since it is more of a cutting edge versus practical OS. [Yes that is a dig.. I am allowed one per year.]
If we are going to 'break' FHS, let us do it in a large way versus a death by a thousand cuts. Change the directory names to something like:
/configurations /vendor-binaries /vendor-data /user-stuff
or any of the other proposals over the years to make things more intuitive in a 21st century way :).
Bill Nottingham wrote:
Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, and so on were just symlinks to /usr/bin, /usr/lib, and so on.
Tru64 (Yes, it's still supported!) does:
gholms@seraph ~ % uname -a OSF1 seraph.tetraforge.com V5.1 2650 alpha
gholms@seraph ~ % ls -l /bin /lib lrwxr-xr-x 1 root system 7 Apr 21 2010 /bin@ -> usr/bin/ lrwxr-xr-x 1 root system 7 Apr 21 2010 /lib@ -> usr/lib/
On Tuesday, October 19, 2010 15:56:54 Matthew Garrett wrote:
On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote:
This despite the FHS says (right at the top of Chapter 3, the Root
Filesystem): /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.
Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this?
What's the benefit in having /usr or /opt as separate filesystems?
another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop)
On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote:
another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop)
I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc?
On Tue, 2010-10-19 at 16:05 +0100, Matthew Garrett wrote:
On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote:
another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop)
I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc?
Yes to both of those.
-sv
On Tue, Oct 19, 2010 at 11:07:24AM -0400, seth vidal wrote:
On Tue, 2010-10-19 at 16:05 +0100, Matthew Garrett wrote:
On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote:
another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop)
I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc?
Yes to both of those.
Well, I don't think people have suggested removing /var as a separate mountpoint. The stuff in /etc is a much more interesting case. Do you have some examples?
On Tue, 2010-10-19 at 16:11 +0100, Matthew Garrett wrote:
On Tue, Oct 19, 2010 at 11:07:24AM -0400, seth vidal wrote:
On Tue, 2010-10-19 at 16:05 +0100, Matthew Garrett wrote:
On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote:
another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop)
I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc?
Yes to both of those.
Well, I don't think people have suggested removing /var as a separate mountpoint. The stuff in /etc is a much more interesting case. Do you have some examples?
Password/Shadow files? SSL Certs/SSL Keys for various kinds of daemons or clients.
RHN ssl certificates and auth keys?
-sv
On Tue, 2010-10-19 at 11:12 -0400, seth vidal wrote:
Well, I don't think people have suggested removing /var as a separate mountpoint. The stuff in /etc is a much more interesting case. Do you have some examples?
Password/Shadow files? SSL Certs/SSL Keys for various kinds of daemons or clients.
RHN ssl certificates and auth keys?
wifi keys, VPN passwords...
On Tue, 2010-10-19 at 16:11 +0100, Matthew Garrett wrote:
Well, I don't think people have suggested removing /var as a separate mountpoint. The stuff in /etc is a much more interesting case. Do you have some examples?
So first off, I personally don't care if /usr is allowed to be separate or not (though breaking the FHS on a whim seems a tad excessive) ... but I don't see how /var is significantly different. udisks (why I'm reading this thread at all) certainly looks like it needs /var to be mounted.
Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that?
Also, are we sure that people don't want to change any options other than "ro" (the only thing you can tweak with the bind trick, AIUI)? I thought someone mentioned noatime...
Once upon a time, James Antill james@fedoraproject.org said:
Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that?
On a multi-user server (and that includes web access like PHP or CGI), you really don't want user-writable directories on a filesystem with anything important, especially security-sensitive things like setuid binaries. Hard-link tricks are evil. I run with a separate /tmp (usually tmpfs now) and bind mount it to /var/tmp as well.
You generally don't want logs (which are indirectly user-writable) on a filesystem with other system-critical things, as it leaves you open to DoS.
This is really separate from / vs. /usr though, as neither should have directly or indirectly user-writable files (assuming separate /tmp and /var).
On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote:
Once upon a time, James Antill james@fedoraproject.org said:
Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that?
On a multi-user server (and that includes web access like PHP or CGI), you really don't want user-writable directories on a filesystem with anything important, especially security-sensitive things like setuid binaries. Hard-link tricks are evil. I run with a separate /tmp (usually tmpfs now) and bind mount it to /var/tmp as well.
Not to get too far off into the weeds but Polyinstantianed tmpdir (pam_namespace) are a good idea here. Everyone gets their on /tmp and /var/tmp and no one else can see them.
-sv
On Tue, Oct 19, 2010 at 04:50:43PM -0400, seth vidal wrote:
On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote:
Once upon a time, James Antill james@fedoraproject.org said:
Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that?
On a multi-user server (and that includes web access like PHP or CGI), you really don't want user-writable directories on a filesystem with anything important, especially security-sensitive things like setuid binaries. Hard-link tricks are evil. I run with a separate /tmp (usually tmpfs now) and bind mount it to /var/tmp as well.
Not to get too far off into the weeds but Polyinstantianed tmpdir (pam_namespace) are a good idea here. Everyone gets their on /tmp and /var/tmp and no one else can see them.
+1 ... we should have had this a long time ago.
Rich.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/20/2010 07:52 AM, Richard W.M. Jones wrote:
On Tue, Oct 19, 2010 at 04:50:43PM -0400, seth vidal wrote:
On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote:
Once upon a time, James Antill james@fedoraproject.org said:
Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that?
On a multi-user server (and that includes web access like PHP or CGI), you really don't want user-writable directories on a filesystem with anything important, especially security-sensitive things like setuid binaries. Hard-link tricks are evil. I run with a separate /tmp (usually tmpfs now) and bind mount it to /var/tmp as well.
Not to get too far off into the weeds but Polyinstantianed tmpdir (pam_namespace) are a good idea here. Everyone gets their on /tmp and /var/tmp and no one else can see them.
+1 ... we should have had this a long time ago.
Rich.
I have been trying to get system processes to stop using /tmp for years.
http://danwalsh.livejournal.com/11467.html
As some one who lives with polyinstatiated namespace /tmp, The only problem I know of now is handing of kerberos tickets. Whenever a system process (root) needs to communicate with a user via /tmp. namespace /tmp breaks it. sssd can not create kerberos tickets in my /tmp and gssd can not find my kerberos tickets in /tmp. I believe the solution to both is to move the tickets to be managed by sssd and leave /tmp to users.
BTW, X has solved this problem a couple of years ago by using virtual namespace for its sockets.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/20/2010 08:13 AM, Daniel J Walsh wrote:
On 10/20/2010 07:52 AM, Richard W.M. Jones wrote:
On Tue, Oct 19, 2010 at 04:50:43PM -0400, seth vidal wrote:
On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote:
Once upon a time, James Antill james@fedoraproject.org said:
Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that?
On a multi-user server (and that includes web access like PHP or CGI), you really don't want user-writable directories on a filesystem with anything important, especially security-sensitive things like setuid binaries. Hard-link tricks are evil. I run with a separate /tmp (usually tmpfs now) and bind mount it to /var/tmp as well.
Not to get too far off into the weeds but Polyinstantianed tmpdir (pam_namespace) are a good idea here. Everyone gets their on /tmp and /var/tmp and no one else can see them.
+1 ... we should have had this a long time ago.
Rich.
I have been trying to get system processes to stop using /tmp for years.
http://danwalsh.livejournal.com/11467.html
As some one who lives with polyinstatiated namespace /tmp, The only problem I know of now is handing of kerberos tickets. Whenever a system process (root) needs to communicate with a user via /tmp. namespace /tmp breaks it. sssd can not create kerberos tickets in my /tmp and gssd can not find my kerberos tickets in /tmp. I believe the solution to both is to move the tickets to be managed by sssd and leave /tmp to users.
BTW, X has solved this problem a couple of years ago by using virtual namespace for its sockets.
https://fedorahosted.org/sssd/ticket/652 has been opened upstream with SSSD to add this functionality.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Wed, 2010-10-20 at 08:13 -0400, Daniel J Walsh wrote:
I have been trying to get system processes to stop using /tmp for years.
http://danwalsh.livejournal.com/11467.html
As some one who lives with polyinstatiated namespace /tmp, The only problem I know of now is handing of kerberos tickets. Whenever a system process (root) needs to communicate with a user via /tmp. namespace /tmp breaks it. sssd can not create kerberos tickets in my /tmp and gssd can not find my kerberos tickets in /tmp. I believe the solution to both is to move the tickets to be managed by sssd and leave /tmp to users.
BTW, X has solved this problem a couple of years ago by using virtual namespace for its sockets.
In the abstract namespace, don't you have the same problem where if the real X server dies for any reason, other users can create a socket at the same path and mess with your applications?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/31/2010 03:07 PM, Matt McCutchen wrote:
On Wed, 2010-10-20 at 08:13 -0400, Daniel J Walsh wrote:
I have been trying to get system processes to stop using /tmp for years.
http://danwalsh.livejournal.com/11467.html
As some one who lives with polyinstatiated namespace /tmp, The only problem I know of now is handing of kerberos tickets. Whenever a system process (root) needs to communicate with a user via /tmp. namespace /tmp breaks it. sssd can not create kerberos tickets in my /tmp and gssd can not find my kerberos tickets in /tmp. I believe the solution to both is to move the tickets to be managed by sssd and leave /tmp to users.
BTW, X has solved this problem a couple of years ago by using virtual namespace for its sockets.
In the abstract namespace, don't you have the same problem where if the real X server dies for any reason, other users can create a socket at the same path and mess with your applications?
Yes although there, you can only create sockets.
On Sun, 2010-10-31 at 15:07 -0400, Matt McCutchen wrote:
On Wed, 2010-10-20 at 08:13 -0400, Daniel J Walsh wrote:
I have been trying to get system processes to stop using /tmp for years.
http://danwalsh.livejournal.com/11467.html
As some one who lives with polyinstatiated namespace /tmp, The only problem I know of now is handing of kerberos tickets. Whenever a system process (root) needs to communicate with a user via /tmp. namespace /tmp breaks it. sssd can not create kerberos tickets in my /tmp and gssd can not find my kerberos tickets in /tmp. I believe the solution to both is to move the tickets to be managed by sssd and leave /tmp to users.
BTW, X has solved this problem a couple of years ago by using virtual namespace for its sockets.
In the abstract namespace, don't you have the same problem where if the real X server dies for any reason, other users can create a socket at the same path and mess with your applications?
There are multiple "problems" ... the one that using the abstract socket namespace solves is that you can have a per. user /tmp and still communicate between users. Much like if you have a per. user /tmp but /tmp/global was shared among all users, and kerberos/X/whatever all used that (IMNSHO much better than using the abstract namespace ... but meh).
On 10/19/2010 04:13 PM, James Antill wrote:
Also, are we sure that people don't want to change any options other than "ro" (the only thing you can tweak with the bind trick, AIUI)? I thought someone mentioned noatime...
I don't really think noatime is as big of a consideration any more, now that we're normally mounting with relatime.
On Tue, Oct 19, 2010 at 04:05:19PM +0100, Matthew Garrett wrote:
On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote:
another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop)
I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc?
There is also /root and if you do not have /var on a separate partition, there might be application data on /var or temporary files in /var/tmp or /tmp.
Regards Till
Le mardi 19 octobre 2010 à 14:56 +0100, Matthew Garrett a écrit :
On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote:
This despite the FHS says (right at the top of Chapter 3, the Root Filesystem):
/usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.
Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this?
What's the benefit in having /usr or /opt as separate filesystems?
When one actually uses /opt, it really wants to be on a separate filesystem, so you can dump huge (gigs of binaries and other data) proprietary software there without polluting the (sane) base system
It matters a lot when you have simple backup procedures for the base system that explode if you accidentally scope Oracle/SAP/IBM bloatware.
Regards,
2010/10/19 Paul Howarth paul@city-fan.org:
Comments are worth reading, I'm sure.
This despite the FHS says (right at the top of Chapter 3, the Root Filesystem):
/usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.
Neat.
Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this?
If you read the entire commit message, you'll see:
commit 1ae53648c9e3460eb63837b4c20bc860018979f0 Author: Chris Lumens clumens@redhat.com Date: Mon Oct 18 11:09:36 2010 -0400
Don't recommend /usr as a mount point anymore (#643640).
You can still use it if you really want (by inputting it manually), but the Installation Guide recommends against its use.
In other words, you can still use any mount point you want.
- Chris
On 19/10/10 15:01, Chris Lumens wrote:
This despite the FHS says (right at the top of Chapter 3, the Root Filesystem):
/usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.Neat.
Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this?
If you read the entire commit message, you'll see:
commit 1ae53648c9e3460eb63837b4c20bc860018979f0 Author: Chris Lumensclumens@redhat.com Date: Mon Oct 18 11:09:36 2010 -0400
Don't recommend /usr as a mount point anymore (#643640). You can still use it if you really want (by inputting it manually), but the Installation Guide recommends against its use.In other words, you can still use any mount point you want.
I did read that, which is why I added the reference to Bug #626007 (trimmed from your reply), which is where this change originated from; that is a bug that is being ignored on the basis that /usr is on a separate partition.
I'm fine with setting up my own partitioning arrangements but I'd rather not see a system that doesn't work once installed this way.
Paul.
On Tue, 19.10.10 14:43, Paul Howarth (paul@city-fan.org) wrote:
On 19/10/10 14:11, Rawhide Report wrote:
anaconda-15.3-1.fc15
- Mon Oct 18 2010 Chris Lumensclumens@redhat.com - 15.3-1
- Don't recommend /usr as a mount point anymore (#643640). (clumens)
This despite the FHS says (right at the top of Chapter 3, the Root Filesystem):
/usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.
Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this?
During my experimenting with readahead I noticed how many files are actually accessed during early boot that are in /usr. It's a lot more than udisks. It's also everything related to i18n, and a lot other stuff. Already if you run things this way you'll thus have serious functionality limitations. And I see little value in making this work again.
Note that many other distributions gave up on seperate /usr already (for example, Gentoo do this, and even refers to Fedora that it wasn't supported here, which is technically true, but so far not officially).
I think the whole approach of seperate /usr (which iiuc is done to make /usr r/o during normal runtime) is wrong anyway. It aims too low. If people want to make something r/o it should be the entirety of / read-only, and we probably should make that the default even eventually. That'd be a worthy goal. However, right now there's still a handful of programs that write around in /etc during runtime, such as NM, and stuff related to /etc/nologin, /forcefsck, /etc/mtab, /etc/securetty and similar files. (a couple of which will hopefully go away soonishly. i.e. /etc/nologin is being migrated to /var/run/nologin now, and /forcefsck has a kernel cmdline option "forcefsck" which is a lot more useful. util-linux-ng is working on getting rid of /etc/mtab and already works mostly when you link it to /proc/mounts. For the securetty hacks I sent a patch last week to PAM.)
Debian in fact has been making great progress to make their OS work with read-only root by default: http://wiki.debian.org/ReadonlyRoot
Also note that a number of commercial unixes symlink / and /usr these days, going one step further even.
Lennart
On 10/19/2010 04:37 PM, Lennart Poettering wrote:
Note that many other distributions gave up on seperate /usr already (for example, Gentoo do this, and even refers to Fedora that it wasn't supported here, which is technically true, but so far not officially).
Where did you get that idea? From Gentoo installation handbook:
"The number of partitions is highly dependent on your environment. For instance, if you have lots of users, you will most likely want to have your /home separate as it increases security and makes backups easier. If you are installing Gentoo to perform as a mailserver, your /var should be separate as all mails are stored inside /var. A good choice of filesystem will then maximise your performance. Gameservers will have a separate /opt as most gaming servers are installed there. The reason is similar for /home: security and backups. *You will definitely want to keep /usr big*: not only will it contain the majority of applications, the Portage tree alone takes around 500 Mbyte excluding the various sources that are stored in it."
Before replying and saying that "is just says /usr has to be big". Please read whole http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=4 (part "How Many and How Big?")
I won't even comment on whole idea of not supporting separate /usr in Fedora...makes me sad.
On Tue, 19.10.10 16:51, Stanislav Ochotnicky (sochotnicky@redhat.com) wrote:
On 10/19/2010 04:37 PM, Lennart Poettering wrote:
Note that many other distributions gave up on seperate /usr already (for example, Gentoo do this, and even refers to Fedora that it wasn't supported here, which is technically true, but so far not officially).
Where did you get that idea? From Gentoo installation handbook:
Well, some Gentoo devs involved with integrating systemd on gentoo pointed this out to me. The context was that the systemd tool to initialize the console expects "loadkeys" to be in /bin, while on Gentoo it is in /usr/bin. And I asked them to unify the location to /bin so that we have less ugly glue code in the systemd build system, and the gentoo folks ultimately refused, saying that seperate /usr wasn't supported anyway.
Basically, on gentoo you don't get a correct keymapping before /usr is around, which means you cannot even type your hdd password in properly unless you are a lucky american.
There's even a Gentoo bug about this somewhere.
Lennart
-----Original Message----- From: devel-bounces@lists.fedoraproject.org [mailto:devel-bounces@lists.fedoraproject.org] On Behalf Of Lennart Poettering Sent: Tuesday, October 19, 2010 7:38 AM To: Development discussions related to Fedora Subject: Re: rawhide report: 20101019 changes
I think the whole approach of seperate /usr (which iiuc is done to make /usr r/o during normal runtime) is wrong anyway. It aims too low. If people want to make something r/o it should be the entirety of / read-only, and we probably should make that the default even eventually. That'd be a worthy goal. However, right now there's still a handful of programs that write around in /etc during runtime, such as NM, and stuff related to /etc/nologin, /forcefsck, /etc/mtab, /etc/securetty and similar files. (a couple of which will hopefully go away soonishly. i.e. /etc/nologin is being migrated to /var/run/nologin now, and /forcefsck has a kernel cmdline option "forcefsck" which is a lot more useful. util-linux-ng is working on getting rid of /etc/mtab and already works mostly when you link it to /proc/mounts. For the securetty hacks I sent a patch last week to PAM.)
Debian in fact has been making great progress to make their OS work with read-only root by default: http://wiki.debian.org/ReadonlyRoot
Also note that a number of commercial unixes symlink / and /usr these days, going one step further even.
Lennart
A ton of this work was already done in initscripts through the use of the /etc/sysconfig/readonly-root hooks. Isn't that already working well enough now for that purpose, future systemd changes aside?
-jc
Cleaver, Japheth (jcleaver@soe.sony.com) said:
A ton of this work was already done in initscripts through the use of the /etc/sysconfig/readonly-root hooks. Isn't that already working well enough now for that purpose, future systemd changes aside?
Given that it involves bind-mounting *files* in some cases (which imparts some truly odd semantics that confuse programs), it's not quite enough for generalizing to any use. It certainly can be made to work, though.
Bill
On Tuesday 19 October 2010, Cleaver, Japheth wrote:
A ton of this work was already done in initscripts through the use of the /etc/sysconfig/readonly-root hooks. Isn't that already working well enough now for that purpose, future systemd changes aside?
Not sure if it's directly related to this discussion, but for what I'd like to use it for [0] there's one essential piece missing, persisting temporary state back to disk: https://bugzilla.redhat.com/show_bug.cgi?id=223722
[0] To keep rotational disks spun down as much as possible and avoiding writes on cheap flash devices that can't take that much writing in the long run.
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Bill Nottingham -
Chris Adams -
Chris Lumens -
Cleaver, Japheth -
Daniel J Walsh -
Fedora compose checker -
Garrett Holmstrom -
James Antill -
Jesse Keating -
Lennart Poettering -
Matt McCutchen -
Matthew Garrett -
Matthew Miller -
Michal Hlavinka -
Mike McGrath -
Nathaniel McCallum -
Nicolas Mailhot -
Paul Howarth -
Peter Jones -
Peter Lemenkov -
Richard W.M. Jones -
Seth Vidal -
Stanislav Ochotnicky -
Stephen Gallagher -
Stephen John Smoogen -
Till Maas -
Ville Skyttä