From tibbs at math.uh.edu Wed Sep 1 00:26:11 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 31 Aug 2004 19:26:11 -0500 Subject: State of Unichrome support In-Reply-To: <20040831180713.GB22376@devserv.devel.redhat.com> (Alan Cox's message of "Tue, 31 Aug 2004 14:07:13 -0400") References: <20040831180713.GB22376@devserv.devel.redhat.com> Message-ID: >>>>> "AC" == Alan Cox writes: >> Should I open a bug for this? AC> Yes. I've opened #131403: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131403 [Unichrome DRM] AC> It's not 2.6 merged and there is some essential work to be done AC> there for the 3D before it goes in. I guess that's the "user can write and maybe read anywhere in system RAM" problem. Personally I don't care if the user at the console can crash the system (since they could just pull the power) but I can see why it's being kept out of the kernel. Any suggestions on how I can help test? I'm on the xorg list but I don't think that's deep enough into it. AC> The analogue side is all off chip on these things. They are used AC> for cheap boards so you get cheap analogue parts too I'd hope a $115 Intel D865GLC board would have reasonable output, but I have a $40 MSI board with a ProSavage chipset that looks better. I think everyone just ships crap these days. Maybe I'll have better luck with one of the Radeon IGP chipset boards. - J< From skvidal at phy.duke.edu Wed Sep 1 00:34:42 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 31 Aug 2004 20:34:42 -0400 Subject: yum 2.1.0 In-Reply-To: <4134AD7A.2070109@lanl.gov> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> Message-ID: <1093998882.3817.0.camel@binkley> On Tue, 2004-08-31 at 10:55 -0600, Stephen J Smoogen wrote: > seth vidal wrote: > >>GYUM is a UI abomination, but otherwise, it works. I sent in a big list > >>of UI suggestions and reasoning to the GYUM devs and never got a > >>response - no idea if they plan on fixing the UI to be sane or leaving > >>it the ugly, unusable mess that it is. > >> > >>It'd probably be easier to just write a fresh GUI from scratch using the > >>proper tools, especially if yum 2.1.0 is as easy to wrap as Seth is > >>indicating. > > > > > > Here's a wacky idea, What about using system-config-packages as the > > front end? > > > > You are definately thinking way outside of the box there my friend. > > > The standard operating method for any OpenSource project is to.. look at > existing products, think their code is crap and only a rewrite will fix > it, start a new project on SourceForge/Freshmeat with your complete > rewrite of code, start an IRC channel, and wait for developers to send > you patches. > > After 6 months, either send out a flaming email about how the OpenSource > community was too jealous of your code to help you out OR have a little > community of users that worship your code and they will send out regular > emails to any other project that they should tow the line and join your > project or fear the Jihad. > > Trying to work with existing code is almost revolutionary in concept. You forgot to close your sarcasm tag. here. I'll do it for you. you know. re-reading - it might be a tag. :) -sv From buildsys at redhat.com Wed Sep 1 00:41:04 2004 From: buildsys at redhat.com (Build System) Date: Tue, 31 Aug 2004 20:41:04 -0400 Subject: rawhide report: 20040831 changes Message-ID: <200409010041.i810f4R24475@porkchop.devel.redhat.com> Updated Packages: GConf2-2.7.92-1 --------------- * Mon Aug 30 2004 Mark McLoughlin 2.7.92-1 - Update to 2.7.92 ORBit2-2.11.2-1 --------------- * Mon Aug 30 2004 Mark McLoughlin 2.11.2-1 - Update to 2.11.2 - Remove gcc on pcc workaround patch alsa-lib-1.0.6-1 ---------------- * Mon Aug 30 2004 Bill Nottingham 1.0.6-1 - update to 1.0.6 alsa-utils-1.0.6-1 ------------------ * Mon Aug 30 2004 Bill Nottingham 1.0.6-1 - update to 1.0.6 anaconda-10.0.2-0.20040830132523 -------------------------------- * Mon Aug 30 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode balsa-2.2.4-1.FC3.1 ------------------- * Mon Aug 30 2004 John Dennis 2.2.4-1,FC3,1 - bring up to latest upstream bash-3.0-9 ---------- * Tue Aug 31 2004 Tim Waugh 3.0-9 - Fix ulimits patch from Ulrich Drepper (bug #129800). bind-9.2.4rc7-10 ---------------- * Mon Aug 30 2004 Jason Vas Dias - 10:9.2.7-rc7-10 - Fix bug 130121: add '%ghost' entries for files included in previous - bind-chroot & not in current - ie. named.conf, rndc.key, dev/* - - that RPM removed after upgrade . * Thu Aug 26 2004 Jason Vas Dias - Fix bug 130981: add '-t' option to named-checkconf invocation in - named.init if chroot installed. checkpolicy-1.17.2-1 -------------------- * Mon Aug 30 2004 Dan Walsh 1.17.2-1 - Latest from NSA cryptsetup-0.1-3 ---------------- * Tue Aug 31 2004 Bill Nottingham 0.1-3 - link some things static, move to /sbin (#129926) dhcpv6-0.10-2 ------------- * Mon Aug 30 2004 Jason Vas Dias - 0.10-2 - Split into two packages: dhcpv6-*, containing server only, - and dhcpv6_client-*, containing client only. * Thu Aug 26 2004 Jason Vas Dias - 0.10-1 - Initial build. eel2-2.7.92-1 ------------- * Tue Aug 31 2004 Alex Larsson 2.7.92-1 - update to 2.7.92 evolution-webcal-1.0.9-2 ------------------------ * Mon Aug 30 2004 David Malcolm - 1.0.9-2 - Converted dashes to underscores in version defines; usage should now match up with definition file-roller-2.7.5-1 ------------------- * Mon Aug 30 2004 Christopher Aillon 2.7.5-0 - Update to 2.7.5 foomatic-3.0.1-11 ----------------- * Tue Aug 31 2004 Tim Waugh 3.0.1-11 - Add autodetect information for Brother HL-5050 (bug #131220). fsh-1.2-4 --------- * Tue Aug 31 2004 David Woodhouse 1.2-4 - Fix Group: tag, install info file correctly. Fixes #131271 gawk-3.1.4-1 ------------ * Tue Aug 31 2004 Thomas Woerner 3.1.4-1 - new version 3.1.4 gconf-editor-2.7.91-1 --------------------- * Mon Aug 30 2004 Mark McLoughlin 2.7.91-1 - Update to 2.7.91 gdb-6.1post-1.20040607.26 ------------------------- * Mon Aug 30 2004 Jeff Johnston 1.200400607.26 - Add java inferior call support * Mon Aug 30 2004 Andrew Cagney 1.200400607.25 - Convert "main" the function descriptor, into an address. * Mon Aug 30 2004 Andrew Cagney 1.200400607.24 - Fix single-stepping when a signal is pending, was exiting program. -- needs kernel fix so that ptrace(PT_STEP,SIG) doesn't do a PT_CONT. -- sigstep.exp tests pass with this fix applied. gedit-2.7.92-1 -------------- * Tue Aug 31 2004 Alex Larsson 1:2.7.92-1 - update to 2.7.92 glibc-kernheaders-2.4-9.1.87 ---------------------------- * Tue Aug 31 2004 Ajran van de Ven - update input.h gnome-applets-2.7.3-1 --------------------- * Mon Aug 30 2004 Mark McLoughlin 2.7.3-1 - Update to 2.7.3 gnome-desktop-2.7.92-1 ---------------------- * Mon Aug 30 2004 Mark McLoughlin 2.7.92-1 - Update to 2.7.92 gnome-icon-theme-2.7.90-1 ------------------------- * Tue Aug 31 2004 Alex Larsson 2.7.90-1 - update to 2.7.90 gnome-keyring-0.3.3-1 --------------------- * Tue Aug 31 2004 Alex Larsson 0.3.3-1 - update to 0.3.3 * Thu Aug 12 2004 Alexander Larsson - 0.3.2-1 - update to 0.3.2 * Tue Jun 15 2004 Elliot Lee - rebuilt gnome-mag-0.11.5-1 ------------------ * Tue Aug 31 2004 Colin Walters 0.11.5-1 - Update to 0.11.5 - Add missing ldconfig calls (bz #131273) gnome-media-2.7.92-1 -------------------- * Tue Aug 31 2004 Colin Walters 2.7.92-1 - Update to 2.7.92 gnome-netstatus-2.7.92-1 ------------------------ * Mon Aug 30 2004 Mark McLoughlin 2.7.92-1 - Update to 2.7.92 gnome-panel-2.7.92.1-1 ---------------------- * Tue Aug 31 2004 Mark McLoughlin 2.7.92.1-1 - Update to 2.7.92.1 * Mon Aug 30 2004 Mark McLoughlin 2.7.92-1 - Update to 2.7.92 gnome-session-2.7.91-1 ---------------------- * Tue Aug 31 2004 Ray Strode 2.7.91-1 - Update to 2.7.91 gnome-speech-0.3.5-1 -------------------- * Tue Aug 31 2004 Colin Walters 0.3.5-1 - Update to 0.3.5 - Add missing ldconfig calls (bz #123268) gnome-themes-2.7.92-1 --------------------- * Tue Aug 31 2004 Alex Larsson 2.7.92-1 - update to 2.7.92 - remove autogenerated files from hidden patch gnome-utils-2.7.91-1 -------------------- * Tue Aug 31 2004 Alex Larsson 1:2.7.91-1 - update to 2.7.91 and zenity 2.7.91 gnome-vfs2-2.7.92-1 ------------------- * Tue Aug 31 2004 Alex Larsson 2.7.92-1 - update to 2.7.92 gnopernicus-0.9.10-1 -------------------- * Tue Aug 31 2004 Colin Walters 0.9.10-1 - Update to 0.9.10 gok-0.11.7-1 ------------ * Tue Aug 31 2004 Colin Walters 0.11.7-1 - Update to 0.11.7 gpdf-2.7.91-1 ------------- * Tue Aug 31 2004 Alex Larsson 2.7.91-1 - update to 2.7.92 - removed gpdf-2.7.90-uri-fix.patch, as that was in upstream gtkspell-2.0.7-2 ---------------- * Mon Aug 30 2004 David Malcolm - 2.0.7-2 - rerun ldconfig upon uninstall; thanks to Matthias Saou (#131277) iiimf-le-xcin-0.1.7-4 --------------------- * Mon Aug 30 2004 Leon Ho 0.1.7-4 - added /usr/lib64/im - autogen call clean up - added libdir patch * Sun Aug 29 2004 Warren Togami 0.1.7-3 - minor spec cleanup initscripts-7.74-1 ------------------ * Mon Aug 30 2004 Karsten Hopp 7.74-1 - fix support for LCS portnumbers (mainframe) kde-i18n-3.3.0-2 ---------------- * Tue Aug 31 2004 Than Ngo 3.3.0-2 - fix rpm file list * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 - add Bulgarian kernel-2.6.8-1.535 ------------------ * Mon Aug 30 2004 Arjan van de Ven - 2.6.9-rc1-bk6 kudzu-1.1.83-1 -------------- * Mon Aug 30 2004 Karsten Hopp 1.1.83-1 - fix detection of ESCON devices (mainframe) - change QETH and Hipersockets detection to use /sys/class/net (mainframe) - add detection of lcs(osa) and lcs(tokenring) (mainframe) libcroco-0.6.0-2 ---------------- * Tue Aug 31 2004 Matthias Clasen - 0.6-2 - Add missing ldconfig calls (#131279) libgnome-2.7.92-1 ----------------- * Tue Aug 31 2004 Alex Larsson 2.7.92-1 - update to 2.7.92 * Wed Aug 11 2004 Alexander Larsson - 2.7.2-2 - Update default fixes to patch schemas.in files * Wed Aug 04 2004 Mark McLoughlin 2.7.2-1 - Update to 2.7.2 - Remove sound properties patches and desktop_gnome_accessibility_startup schemas - all seem to be upstream now libgnomecanvas-2.7.92-1 ----------------------- * Tue Aug 31 2004 Alex Larsson 2.7.92-1 - update to 2.7.92 libgnomeui-2.7.92-1 ------------------- * Tue Aug 31 2004 Alex Larsson 2.7.92-1 - update to 2.7.92 libgpg-error-1.0-1 ------------------ * Tue Aug 31 2004 Bill Nottingham - 1.0-1 - update to 1.0 libgsf-1.10.1-1 --------------- * Tue Aug 31 2004 Caolan McNamara 1.10.1-1 - upgrade to 1.10.1 libgtop2-2.7.92-1 ----------------- * Tue Aug 31 2004 Alex Larsson 2.7.92-1 - update to 2.7.92 libmusicbrainz-2.0.2-9 ---------------------- * Tue Aug 31 2004 Colin Walters 2.0.2-9 - Add ldconfig calls (bz #131281) libselinux-1.17.5-1 ------------------- * Mon Aug 30 2004 Dan Walsh 1.17.5-1 - Update from NSA * Merged second optimization patch from Ulrich Drepper. * Changed matchpathcon to skip invalid file_contexts entries. * Made string tables private to libselinux. * Merged strcat->stpcpy patch from Ulrich Drepper. * Merged matchpathcon man page from Dan Walsh. * Merged patch to eliminate PLTs for local syms from Ulrich Drepper. * Autobind netlink socket. * Dropped compatibility code from security_compute_user. * Merged fix for context_range_set from Chad Hanson. * Merged allocation failure checking patch from Chad Hanson. * Merged avc netlink error message patch from Colin Walters. * Mon Aug 30 2004 Dan Walsh 1.17.4-1 - Update from NSA - Add optflags libsepol-1.1.1-2 ---------------- * Mon Aug 30 2004 Dan Walsh 1.1.1-2 - Add optargs for build libwnck-2.7.92-1 ---------------- * Mon Aug 30 2004 Mark McLoughlin 2.7.92-1 - Update to 2.7.92 - Include API docs libxml2-2.6.13-1 ---------------- * Tue Aug 31 2004 Daniel Veillard - upstream release 2.6.13 see http://xmlsoft.org/news.html * Thu Jan 02 2003 Daniel Veillard - integrated drv_libxml2 xml.sax driver from St?phane Bidoul - provides the new XmlTextReader interfaces based on C# XML APIs * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems libxslt-1.1.10-1 ---------------- * Tue Aug 31 2004 Daniel Veillard - upstream release 1.1.10 see http://xmlsoft.org/XSLT/news.html * Sun Nov 02 2003 Daniel Veillard - cleanup, removal of the deprecated breakpoint library and automated libxml2 dependancy level in the generated spec file. * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems mailman-2.1.5-11 ---------------- * Mon Aug 30 2004 John Dennis 3:2.1.5-11 - remove all editing of aliases file in %pre and %post, fixes #bug 125651 metacity-2.8.4-1 ---------------- * Tue Aug 31 2004 Alex Larsson 2.8.4-1 - update to 2.8.4 mozplugger-1.6.1-1 ------------------ * Tue Aug 31 2004 Than Ngo 1.6.1-1 - update to 1.6.1 nautilus-2.7.92-1 ----------------- * Tue Aug 31 2004 Alex Larsson 2.7.92-1 - update to 2.7.92 net-tools-1.60-34 ----------------- * Mon Aug 30 2004 Radek Vokal 1.60-34 - Trunc patch added (#128359) * Mon Aug 30 2004 Radek Vokal 1.60-33 - Added patch for SI units by Tom "spot" Callaway #118006 nfs-utils-1.0.6-34 ------------------ * Mon Aug 30 2004 Steve Dickson - Major clean up. - Removed all unused/old patches - Rename and condensed a number of patches - Updated to CITI's nfs-utils-1.0.6-13 patches ntp-4.2.0.a.20040616-4 ---------------------- * Tue Aug 17 2004 Harald Hoyer - 4.2.0.a.20040616-4 - added ntp-4.2.0-sbinpath.patch (bug 130536) openhbci-0.9.17-1 ----------------- * Mon Aug 30 2004 Bill Nottingham 0.9.17-1 - update to 0.9.17 openmotif-2.2.3-4.3 ------------------- * Mon Aug 30 2004 Thomas Woerner 2.2.3-4.3 - devel package: added requires for XFree86-devel (#131202) openssh-3.9p1-2 --------------- * Tue Aug 31 2004 Daniel Walsh 3.9p1-2 - Fix TTY handling for SELinux pam-0.77-55 ----------- * Mon Aug 30 2004 Warren Togami 0.77-55 - #126024 /dev/pmu console perms * Wed Aug 04 2004 Dan Walsh 0.77-54 - Move pam_console.lock to /var/run/console/ * Thu Jul 29 2004 Dan Walsh 0.77-53 - Close fd[1] before pam_modutilread so that unix_verify will complete pciutils-2.1.99.test8-1 ----------------------- * Tue Aug 31 2004 Bill Nottingham 2.1.99.test8-1 - update to test8 perl-Crypt-SSLeay-0.51-5 ------------------------ * Tue Aug 31 2004 Chip Turner 0.51-5 - build for FC3 * Tue Aug 31 2004 Chip Turner 0.51-4 - build for RHEL3 U4 policycoreutils-1.17.5-1 ------------------------ * Mon Aug 30 2004 Dan Walsh 1.17.5-1 - Add optargs - Update to match NSA postgresql-7.4.5-2 ------------------ * Mon Aug 30 2004 Tom Lane 7.4.5-2 - Update to PyGreSQL 3.5. procps-3.2.3-3 -------------- * Mon Aug 30 2004 Dan Walsh 3.2.3-3 - Fix batch mode to use dumb terminal python-2.3.4-10 --------------- * Tue Aug 31 2004 Mihai Ibanescu 2.3.4-10 - Fixed bug #77418 (Demo dir not packaged) - More tweaking on #19347 (Moved Tools/ under /usr/lib/python2.3/Tools) * Fri Aug 13 2004 Mihai Ibanescu 2.3.4-8 - Fixed bug #129769: Makefile in new python conflicts with older version found in old python-devel - Reorganized the spec file to get rid of the aspython2 define; __python_ver is more powerful. * Tue Aug 03 2004 Mihai Ibanescu 2.3.4-7 - Including html documentation for non-i386 arches - Fixed #125362 (python-doc html files have japanese character encoding) - Fixed #128923 (missing dependency between python and python-devel) python-ldap-2.0.1-2 ------------------- * Mon Aug 30 2004 David Malcolm - 0:2.0.1-2 - Rewrote description; added requirement for openldap rpmdb-fedora-3-0.20040831 ------------------------- selinux-policy-strict-1.17.8-1 ------------------------------ * Tue Aug 31 2004 Dan Walsh 1.17.8-1 - Update from NSA * Added reserved_port_t type and portcon entries to map all other reserved ports to this type. * Added distro_ prefix to distro tunables to avoid conflicts. * Merged diffs from Russell Coker. * Mon Aug 30 2004 Dan Walsh 1.17.7-1 - Update with uli's fixes * Mon Aug 30 2004 Dan Walsh 1.17.6-1 - Update for NSA - Add ssh policy fixes selinux-policy-targeted-1.17.8-1 -------------------------------- * Tue Aug 31 2004 Dan Walsh 1.17.8-1 - Update from NSA * Added reserved_port_t type and portcon entries to map all other reserved ports to this type. * Added distro_ prefix to distro tunables to avoid conflicts. * Merged diffs from Russell Coker. * Mon Aug 30 2004 Dan Walsh 1.17.7-1 - Update with uli's fixes * Mon Aug 30 2004 Dan Walsh 1.17.6-1 - Update for NSA - Add ssh policy fixes shared-mime-info-0.15-1 ----------------------- * Mon Aug 30 2004 Jonathan Blandford 0.15-1 - bump version strace-4.5.7-2 -------------- * Tue Aug 31 2004 Roland McGrath - 4.5.7-2 - new upstream version, misc fixes and updates (#128091, #129166, #128391, #129378, #130965, #131177) system-config-printer-0.6.110-1 ------------------------------- * Tue Aug 31 2004 Tim Waugh 0.6.110-1 - 0.6.110: - Avoid deprecated interface (bug #130811). up2date-4.3.29-6 ---------------- * Mon Aug 30 2004 Adrian Likins 4.3.29 - fedora doesnt need/want the registration modules for firstboot so make there conclusion optional * Fri Aug 20 2004 Adrian Likins 4.3.27 - #130476 (firstboot/up2date incompatabilities) * Thu Aug 19 2004 Adrian Likins 4.3.25 - #130391 (applet errors when ran for root) - #130389 (typo in wrapper.py) vino-2.7.92-1 ------------- * Mon Aug 30 2004 Mark McLoughlin 2.7.92-1 - Update to 2.7.92 vnc-4.0-6 --------- * Tue Aug 31 2004 Tim Waugh 4.0-6 - Upgraded base package to xorg-x11-6.7.99.903-1. * Fri Aug 27 2004 Tim Waugh 4.0-5 - Built for Fedora Core 2. wget-1.9.1-11 ------------- * Tue Aug 31 2004 Karsten Hopp 1.9.1-11 - rebuild * Tue Aug 31 2004 Karsten Hopp 1.9.1-10 - fix patch wireless-tools-27-0.pre25.1 --------------------------- * Tue Aug 31 2004 Bill Nottingham 27-0.pre25.1 - update to 27.pre25 wvdial-1.54.0-2 --------------- * Tue Aug 31 2004 Harald Hoyer 1.54.0-2 - added empty wvdial.conf file (bug 130622) yelp-2.6.2-1 ------------ * Tue Aug 31 2004 Alex Larsson 2.6.2-1 - update to 2.6.2 yum-2.1.0-1 ----------- * Tue Aug 31 2004 Jeremy Katz - 2.1.0-1 - update to 2.1.0 From naoki at valuecommerce.com Wed Sep 1 01:15:08 2004 From: naoki at valuecommerce.com (Naoki) Date: Wed, 01 Sep 2004 10:15:08 +0900 Subject: USB Mouse stops working. Message-ID: <1094001308.3868.3.camel@dragon.valuecommerce.ne.jp> Hi all, With kernel 2.6.8-1.533 my USB mouse will stop working any where between half an hour and a couple of hours after a boot. Can't quite remember which module is handling it (uhci_hcd?). How do I reload this without losing the keyboard as well ? The mouse is a logitech MX500 and the light stays on. -n. -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoki at valuecommerce.com Wed Sep 1 02:48:10 2004 From: naoki at valuecommerce.com (Naoki) Date: Wed, 01 Sep 2004 11:48:10 +0900 Subject: USB Mouse stops working. In-Reply-To: <1094001308.3868.3.camel@dragon.valuecommerce.ne.jp> References: <1094001308.3868.3.camel@dragon.valuecommerce.ne.jp> Message-ID: <1094006890.3993.4.camel@dragon.valuecommerce.ne.jp> Happened again, I did this "modprobe -r uhci_hcd ; modprobe uhci_hcd". The mouse came back to life but the PS/2 keyboard died. Great :( On Wed, 2004-09-01 at 10:15 +0900, Naoki wrote: > Hi all, > > With kernel 2.6.8-1.533 my USB mouse will stop working any where > between half an hour and a couple of hours after a boot. > Can't quite remember which module is handling it (uhci_hcd?). How do > I reload this without losing the keyboard as well ? > > The mouse is a logitech MX500 and the light stays on. > > -n. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragoran at feuerpokemon.de Wed Sep 1 04:57:59 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 01 Sep 2004 06:57:59 +0200 Subject: USB Mouse stops working. In-Reply-To: <1094006890.3993.4.camel@dragon.valuecommerce.ne.jp> References: <1094001308.3868.3.camel@dragon.valuecommerce.ne.jp> <1094006890.3993.4.camel@dragon.valuecommerce.ne.jp> Message-ID: <413556D7.1080202@feuerpokemon.de> Naoki schrieb: > Happened again, I did this "modprobe -r uhci_hcd ; modprobe > uhci_hcd". The mouse came back to life but the PS/2 keyboard died. > > Great :( > > On Wed, 2004-09-01 at 10:15 +0900, Naoki wrote: > >> Hi all, >> >> With kernel 2.6.8-1.533 my USB mouse will stop working any where >> between half an hour and a couple of hours after a boot. >> Can't quite remember which module is handling it (uhci_hcd?). How do >> I reload this without losing the keyboard as well ? >> >> The mouse is a logitech MX500 and the light stays on. >> >> -n. > maybe its the same problem as this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130748 From naoki at valuecommerce.com Wed Sep 1 05:33:31 2004 From: naoki at valuecommerce.com (Naoki) Date: Wed, 01 Sep 2004 14:33:31 +0900 Subject: htt_server will not run. Failed to create unix domain socket. Message-ID: <1094016811.3993.25.camel@dragon.valuecommerce.ne.jp> Any idea why this would be? Sep 1 14:19:23 host su(pam_unix)[4356]: session opened for user htt by (uid=0) Sep 1 14:19:23 host htt_server[4372]: Failed to create a unix domain socket for /tmp/.iiimp-unix:9010 ... exit. Sep 1 14:23:23 host htt[4371]: give up trying to run htt_server. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragoran at feuerpokemon.de Wed Sep 1 08:19:10 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 01 Sep 2004 10:19:10 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <20040831155210.GA30573@devserv.devel.redhat.com> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <20040831162557.249198f3@localhost> <1093964131.3882.298.camel@greebo.homeip.net> <20040831173831.267e9b1e@localhost> <20040831155210.GA30573@devserv.devel.redhat.com> Message-ID: <413585FE.9010904@feuerpokemon.de> Jakub Jelinek schrieb: >On Tue, Aug 31, 2004 at 05:38:31PM +0200, Matthias Saou wrote: > > >>Is then having the same library twice, the regular one in /usr/lib and the >>SSE2 optimized one in /usr/lib/sse2, expected to "just work" at runtime? If >> >> > >Yes, it will just work. >Both the dynamic linker and ldconfig know how to handle it. > > > >>so, I didn't know the existence of this, and will definitely look into it. >>What about MMX? Should one just simplify with SSE vs. non-SSE instead and >>put (non runtime) MMX optimized libs there too? >> >> > >ATM sse2 is the only "important" feature ld.so on IA-32 handles. >Previously it used to be mmx, but as every added feature slows down >library loading when not using ld.so.cache (e.g. when LD_LIBRARY_PATH >is used or DT_RPATH; every feature doubles the number of stat'ed >directories before the non-existing directory cache is filled), >it was just changed to sse2 instead of adding sse2 to mmx. >SSE2 was chosen because you can get quite a big speedup already >by recompiling with -msse2 -mfpmath=sse. > > Jakub > > > > and what about -m3dnow on amd systems ? From rc040203 at freenet.de Wed Sep 1 09:23:01 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Sep 2004 11:23:01 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <20040831083605.GV11465@devserv.devel.redhat.com> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> Message-ID: <1094030580.25156.32326.camel@mccallum.corsepiu.local> On Tue, 2004-08-31 at 10:36, Jakub Jelinek wrote: > On Tue, Aug 31, 2004 at 10:30:33AM +0200, Arjan van de Ven wrote: > > On Tue, 2004-08-31 at 10:21, Ralf Corsepius wrote: > > > Hi, > > > > > > Question: Shall Fedora Extras support ix86 optimized packages but > > > i386-compiled packages rsp. under shall circumstances shall Fedora > > > Extras support such packages? > > > > > > Background: Some folks have started to add i686-built application > > > packages in addition to i386-built packages to Fedora Extras, claiming > > > these i686-built, "optimized packages" would result into much better > > > performance of these packages ("up to factor 2"). > > > > those optimized packages aren't faster; at least I find it hard to > > believe.... esp on p4 and athlon cpus where cmov is no gain again ;) > > Well, SSE/SSE2 can help for graphic/video/audio applications. If you say so, I don't have any reason for not believing you :-) > But there .i686.rpm doesn't help you, Can you explain? It's the same approach RH applies to glibc and many 3rd party packagers apply to their package. My actual concern is less the technical side, but the "policy side" of shipping "optimized packages" and its impact on "packaging"/"upgrading". > either the application > selects whether to use SSE/SSE2 or not at runtime, or the packages can > have separate sse2 and normal libs in one package: > /usr/lib/libfoo.so.1 > /usr/lib/sse2/libfoo.so.1 i.e. a partial multilib implementation. Packing-wise, this has several disadvantages. 1. You'd have to compile library packages twice. 2. Many packages contain both libraries and applications, so you'd have to apply special measures to assure that applications still get -march=i386 compiled. 3. It would almost double the size of i386.rpms (These sse2 libs would have to be part of i386.rpms) - Is it worth it? However, I agree, it's a nice work-around suitable for libraries where special optimizations can be proven to have a "significant/noticeable" impact. Finally, this doesn't cover applications - The initial sparc to ignite this discussion was folks having entered "optimized applications" in FE (cf. https://bugzilla.fedora.us/show_bug.cgi?id=2033) Ralf From jakub at redhat.com Wed Sep 1 09:41:56 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 1 Sep 2004 05:41:56 -0400 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <1094030580.25156.32326.camel@mccallum.corsepiu.local> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <1094030580.25156.32326.camel@mccallum.corsepiu.local> Message-ID: <20040901094156.GI30573@devserv.devel.redhat.com> On Wed, Sep 01, 2004 at 11:23:01AM +0200, Ralf Corsepius wrote: > > But there .i686.rpm doesn't help you, > Can you explain? Because you can install .i686.rpm on CPUs that don't have SSE or SSE2. > Packing-wise, this has several disadvantages. > 1. You'd have to compile library packages twice. > 2. Many packages contain both libraries and applications, so you'd have > to apply special measures to assure that applications still get > -march=i386 compiled. > 3. It would almost double the size of i386.rpms (These sse2 libs would > have to be part of i386.rpms) - Is it worth it? If it is worth to have the SSE/SSE2 versions at all (i.e. the gains are big enough), then yes, it is worth it. You certainly can't put binaries/libraries requiring SSE or even SSE2 without any fallback for earlier CPUs into neither i386.rpm nor i686.rpm. Jakub From wtogami at redhat.com Wed Sep 1 09:48:05 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 31 Aug 2004 23:48:05 -1000 Subject: firefox and thunderbird for rawhide Message-ID: <41359AD5.60009@redhat.com> According to Havoc, firefox and thunderbird must be added for FC3/RHEL4 target. I am now rushing to build them into rawhide. Your assistance in testing and analysis would be greatly appreciated. http://people.redhat.com/wtogami/temp/firefox/ https://bugzilla.fedora.us/show_bug.cgi?id=2032 Adrian's latest Extras firefox package seems to be working on rawhide after a freetype patch from NetBSD. Please help in testing this. Report problems in the above report. https://bugzilla.fedora.us/show_bug.cgi?id=1765 Thunderbird seems to have trouble building in beehive while it worked fine on my local test build. I may have found a workaround and testing it now. See the above report for latest status. (Don't worry, the ugly Xvfb hack during rpmbuild will disappear with thunderbird-0.8 next week.) Warren Togami wtogami at redhat.com From strepsil at gmail.com Wed Sep 1 09:55:51 2004 From: strepsil at gmail.com (Mike Barnes) Date: Wed, 1 Sep 2004 19:55:51 +1000 Subject: firefox and thunderbird for rawhide In-Reply-To: <41359AD5.60009@redhat.com> References: <41359AD5.60009@redhat.com> Message-ID: <6879f22b04090102555f3d5faf@mail.gmail.com> On Tue, 31 Aug 2004 23:48:05 -1000, Warren Togami wrote: > According to Havoc, firefox and thunderbird must be added for FC3/RHEL4 > target. I am now rushing to build them into rawhide. Your assistance > in testing and analysis would be greatly appreciated. What would you rate the chances of an Alpha-specific build patch making its way into the mainstream release are, at this point? It doesn't affect any files used by other platforms (won't need to be %ifarch-ed). Core 3 for the Alpha's looking pretty achievable at this point, but I know Mozilla and Firefox will need one patch that hasn't been merged in upstream. From warren at togami.com Wed Sep 1 09:59:28 2004 From: warren at togami.com (Warren Togami) Date: Tue, 31 Aug 2004 23:59:28 -1000 Subject: firefox and thunderbird for rawhide In-Reply-To: <6879f22b04090102555f3d5faf@mail.gmail.com> References: <41359AD5.60009@redhat.com> <6879f22b04090102555f3d5faf@mail.gmail.com> Message-ID: <41359D80.9070001@togami.com> Mike Barnes wrote: > On Tue, 31 Aug 2004 23:48:05 -1000, Warren Togami wrote: > >>According to Havoc, firefox and thunderbird must be added for FC3/RHEL4 >>target. I am now rushing to build them into rawhide. Your assistance >>in testing and analysis would be greatly appreciated. > > > What would you rate the chances of an Alpha-specific build patch > making its way into the mainstream release are, at this point? It > doesn't affect any files used by other platforms (won't need to be > %ifarch-ed). Core 3 for the Alpha's looking pretty achievable at this > point, but I know Mozilla and Firefox will need one patch that hasn't > been merged in upstream. Getting firefox and thunderbird built and into test2 is my priority now. Make sure your alpha specific patch is upstream for firefox and thunderbird to be released next week, as that will be the next update that I will make for rawhide. Warren Togami wtogami at redhat.com From mike at netlyncs.com Wed Sep 1 10:17:20 2004 From: mike at netlyncs.com (Mike Chambers) Date: Wed, 01 Sep 2004 05:17:20 -0500 Subject: firefox and thunderbird for rawhide In-Reply-To: <41359AD5.60009@redhat.com> References: <41359AD5.60009@redhat.com> Message-ID: <1094033840.5030.0.camel@scrappy.netlyncs.com> On Tue, 2004-08-31 at 23:48 -1000, Warren Togami wrote: > According to Havoc, firefox and thunderbird must be added for FC3/RHEL4 > target. I am now rushing to build them into rawhide. Your assistance > in testing and analysis would be greatly appreciated. Does this create an icon anywhere and if not, what is needed to start it? Will it conflict with mozilla itself if it's installed? -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt...Then it's hilarious!" From Silke.Reimer at intevation.de Wed Sep 1 10:18:06 2004 From: Silke.Reimer at intevation.de (Silke Reimer) Date: Wed, 1 Sep 2004 12:18:06 +0200 Subject: Help on bug reports for gdal (bug 1964) Message-ID: <20040901101806.GK16620@intevation.de> Hallo! I announced gdal on fedora.us and last week I got some comments on my package[1]. Some of them are quite clear and will be fixed when I prepared my new package but I didn't understand all of them. Perhaps you can comment on them: > Minor: > * Permissions on files in *.src.rpm: > W: gdal strange-permission gdal-1.2.1.tar.gz 0600 > W: gdal strange-permission gdal.spec 0664 > W: gdal strange-permission gdal-install.patch 0664 What are the permission supposed to be? > > * Poor quality of the configure script and makefile systems. > > Severe: > * Package does not honor $RPM_OPT_FLAGS Can you please give me a pointer where I find more information on $RPM_OPT_FLAGS? I did have a look at http://fedora.redhat.com/participate/developers-guide/ but couldn't find anything. > * Partially low coding quality: > ... > gdal_wrap.c:1136: warning: dereferencing type-punned pointer will > break > strict-aliasing rules > gdal_wrap.c: In function `py_StringListToList': > gdal_wrap.c:1205: warning: dereferencing type-punned pointer will > break > strict-aliasing rules > gdal_wrap.c: In function `ptrptrset': > [Dozens of similar warnings more.] > > As the package is reported to work on ia32, these warnings are > unlikely to break > the package, but they very likely cause the package to be > non-functional with > future GCCs and on other architectures. OK. I will inform the upstream author of the package. Do you have other suggestions what can be done regarding this issue? > Critical: > * The rpm does not build: > ... > RPM build errors: > File not found: /usr/src/redhat/BUILD/gdal-root/usr/lib/debug > * Has "make %{?_smp_mflags}" instead of "make" been tried? No it hasn't but I will add it to my specfile. > * rpmlint is right about these two errors: > > E: gdal configure-without-libdir-spec > E: gdal hardcoded-library-path in > %{buildroot}/usr/lib/python%{PYTHON_VERSION}/site-packages > > * A lot of the explicit "Requires: proj, xerces-j, libjpeg, > shapelib, libungif, > zlib, libpng, postgresql-libs" ought to be dropped. Explicit > dependencies on > library package names ask for trouble. Most of the libraries surely > are > automatic dependencies already. Check output of "rpm --query > --requires > PACKAGENAME". OK. But how can I get the information about the package that has to be installed to fulfill the various dependencies. This is the reason why you must provide the names of all packages that have to be installed when you prepare a debian package. In my opinion this is also useful for an RPM based package. There shouldn't be trouble with explicityl asking for a specific package since gdal is explicitly build for Fedora. Thus all necessary packages should be available and if there are two different packages that can fulfill the dependencies I can specify both with '|'. Of course if there is an official policy or an agreement that explicit dependencies shouldn't be used I will delete them. A last issue: You mentioned to have used rpmlint on my package. So I did this as well and got lots of new warnings and errors among them E: gdal executable-in-library-package /usr/bin/gdalwarp E: gdal non-versioned-file-in-library-package /usr/share/gdal/esri_extra.wkt E: gdal non-versioned-file-in-library-package /usr/share/man/man1/ogrtindex.1.gz W: gdal devel-file-in-non-devel-package /usr/lib/python2.3/site-packages/_gdalmodule.a rpmlint is right: These package should rather be in gdal-bin, python-gdal etc. My question: How shall I define subpackage in the specfile so that the package names will not be libgdal-bin but gdal-bin etc. Is this possible? BTW: Is there a reason why rpmlint is not mentioned on http://www.fedora.us/wiki/PackageSubmissionQAPolicy? IMHO it helps to avoid lots of problems when packaging. Thus the packages will probably be of better quality when they are announced on fedora.us. Cheers, Silke [1] https://bugzilla.fedora.us/show_bug.cgi?id=1964 -- Silke Reimer Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Wed Sep 1 10:23:36 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 01 Sep 2004 00:23:36 -1000 Subject: firefox and thunderbird for rawhide In-Reply-To: <1094033840.5030.0.camel@scrappy.netlyncs.com> References: <41359AD5.60009@redhat.com> <1094033840.5030.0.camel@scrappy.netlyncs.com> Message-ID: <4135A328.1070407@redhat.com> Mike Chambers wrote: > On Tue, 2004-08-31 at 23:48 -1000, Warren Togami wrote: > >>According to Havoc, firefox and thunderbird must be added for FC3/RHEL4 >>target. I am now rushing to build them into rawhide. Your assistance >>in testing and analysis would be greatly appreciated. > > > > > Does this create an icon anywhere and if not, what is needed to start > it? Will it conflict with mozilla itself if it's installed? > If you are running FC1 or FC2, install firefox or thunderbird from Extras stable. Those show you exactly how it would work in FC3. Nice looking icons for firefox and thunderbird are dropped into the Internet menu. And you can use the Preferred Applications dialog to choose firefox and thunderbird as your chosen apps. The Preferred Application thing works very well on FC2 and FC3, but FC1 has problems. Legacy may want to consider doing simple changes to control-center and gnome-vfs2 to bring FC1's Preferred Applications capability to par with FC2 and FC3. That would be their call. Warren From dragoran at feuerpokemon.de Wed Sep 1 11:03:07 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 01 Sep 2004 13:03:07 +0200 Subject: firefox and thunderbird for rawhide In-Reply-To: <4135A328.1070407@redhat.com> References: <41359AD5.60009@redhat.com> <1094033840.5030.0.camel@scrappy.netlyncs.com> <4135A328.1070407@redhat.com> Message-ID: <4135AC6B.1010708@feuerpokemon.de> Warren Togami schrieb: > Mike Chambers wrote: > >> On Tue, 2004-08-31 at 23:48 -1000, Warren Togami wrote: >> >>> According to Havoc, firefox and thunderbird must be added for >>> FC3/RHEL4 target. I am now rushing to build them into rawhide. >>> Your assistance in testing and analysis would be greatly appreciated. >> >> >> >> >> >> Does this create an icon anywhere and if not, what is needed to start >> it? Will it conflict with mozilla itself if it's installed? >> > > If you are running FC1 or FC2, install firefox or thunderbird from > Extras stable. Those show you exactly how it would work in FC3. Nice > looking icons for firefox and thunderbird are dropped into the > Internet menu. And you can use the Preferred Applications dialog to > choose firefox and thunderbird as your chosen apps. The Preferred > Application thing works very well on FC2 and FC3, but FC1 has > problems. Legacy may want to consider doing simple changes to > control-center and gnome-vfs2 to bring FC1's Preferred Applications > capability to par with FC2 and FC3. That would be their call. > > Warren > > i don't know if this is abug or not but all system-config-* tools open mozilla when pressing help even if firefox is set in prefered applications From wtogami at redhat.com Wed Sep 1 11:06:34 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 01 Sep 2004 01:06:34 -1000 Subject: firefox and thunderbird for rawhide In-Reply-To: <4135AC6B.1010708@feuerpokemon.de> References: <41359AD5.60009@redhat.com> <1094033840.5030.0.camel@scrappy.netlyncs.com> <4135A328.1070407@redhat.com> <4135AC6B.1010708@feuerpokemon.de> Message-ID: <4135AD3A.3030604@redhat.com> dragoran wrote: > i don't know if this is abug or not but all system-config-* tools open > mozilla when pressing help even if firefox is set in prefered applications Even in FC3 latest? If so, please file a bug against 'distribution' and assign it to me. I will investigate next week. Warren From dragoran at feuerpokemon.de Wed Sep 1 11:09:04 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 01 Sep 2004 13:09:04 +0200 Subject: firefox and thunderbird for rawhide In-Reply-To: <4135AD3A.3030604@redhat.com> References: <41359AD5.60009@redhat.com> <1094033840.5030.0.camel@scrappy.netlyncs.com> <4135A328.1070407@redhat.com> <4135AC6B.1010708@feuerpokemon.de> <4135AD3A.3030604@redhat.com> Message-ID: <4135ADD0.8040009@feuerpokemon.de> Warren Togami schrieb: > dragoran wrote: > >> i don't know if this is abug or not but all system-config-* tools >> open mozilla when pressing help even if firefox is set in prefered >> applications > > > Even in FC3 latest? If so, please file a bug against 'distribution' > and assign it to me. I will investigate next week. > > Warren > > no in FC2 I haven't tested FC3 now From che666 at uni.de Wed Sep 1 10:06:35 2004 From: che666 at uni.de (Rudolf Kastl) Date: Wed, 01 Sep 2004 12:06:35 +0200 Subject: Feature request regarding modularity of DISPLAYMANAGERS in the upcoming fc3 Message-ID: <1094033195.31864.4.camel@localhost.localdomain> Hello to you. As you all know the current way of selecting DISPLAYMANAGERS (such as kdm gdm...) is rather nonmodular. Instead id suggest to use a system similar to the session entrys (.desktop files) and push an expansion of the freedesktop.org menu standard regardings DMs. The selection of the dm could happen via a command line utility that does symlinks. With above solution one could easly write a dynamic gui for that system that could also be used as switchdesktop-gui replacement if 2 vars are exchanged... the dir to look for .desktop files and the symlink to create ;). We need a modular system here. if its not going to happen i will have to override stock packages here with the upcoming fc3 release. regards, rudolf kastl http://newrpms.sunsite.dk From warren at togami.com Wed Sep 1 11:09:46 2004 From: warren at togami.com (Warren Togami) Date: Wed, 01 Sep 2004 01:09:46 -1000 Subject: firefox and thunderbird for rawhide In-Reply-To: <4135ADD0.8040009@feuerpokemon.de> References: <41359AD5.60009@redhat.com> <1094033840.5030.0.camel@scrappy.netlyncs.com> <4135A328.1070407@redhat.com> <4135AC6B.1010708@feuerpokemon.de> <4135AD3A.3030604@redhat.com> <4135ADD0.8040009@feuerpokemon.de> Message-ID: <4135ADFA.6080406@togami.com> dragoran wrote: > Warren Togami schrieb: > >> dragoran wrote: >> >>> i don't know if this is abug or not but all system-config-* tools >>> open mozilla when pressing help even if firefox is set in prefered >>> applications >> >> >> >> Even in FC3 latest? If so, please file a bug against 'distribution' >> and assign it to me. I will investigate next week. >> >> Warren >> >> > no in FC2 I haven't tested FC3 now > > Ok please file anyway, so I remember to investigate that. Warren From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Sep 1 11:14:45 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 1 Sep 2004 13:14:45 +0200 Subject: Why aren't aspell-XX packages noarch? Message-ID: <20040901131445.63e26551@localhost> Hi, I was wondering why the numerous aspell-XX packages were built for each arch instead of being noarch. It seems to me that they don't contain any kind of arch specific files, and the total amount of disk space they currently occupy for each arch in the Fedora Core Development tree is about 75MB. Should I bugzilla this or are there strong arguments against it (other than "most tools don't update packages when they change arch", *sigh*)? Which raises another point : I really hope Seth implements a kind of "ExactArchPkgs=kernel kernel-smp glibc" configuration quickly to yum "TNG" :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.75 0.40 0.31 From dragoran at feuerpokemon.de Wed Sep 1 11:19:59 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 01 Sep 2004 13:19:59 +0200 Subject: firefox and thunderbird for rawhide In-Reply-To: <4135ADFA.6080406@togami.com> References: <41359AD5.60009@redhat.com> <1094033840.5030.0.camel@scrappy.netlyncs.com> <4135A328.1070407@redhat.com> <4135AC6B.1010708@feuerpokemon.de> <4135AD3A.3030604@redhat.com> <4135ADD0.8040009@feuerpokemon.de> <4135ADFA.6080406@togami.com> Message-ID: <4135B05F.2070400@feuerpokemon.de> Warren Togami schrieb: > dragoran wrote: > >> Warren Togami schrieb: >> >>> dragoran wrote: >>> >>>> i don't know if this is abug or not but all system-config-* tools >>>> open mozilla when pressing help even if firefox is set in prefered >>>> applications >>> >>> >>> >>> >>> Even in FC3 latest? If so, please file a bug against 'distribution' >>> and assign it to me. I will investigate next week. >>> >>> Warren >>> >>> >> no in FC2 I haven't tested FC3 now >> >> > > Ok please file anyway, so I remember to investigate that. > > Warren > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131426 it seems that the config tools ignore this settings at all and just starts mozilla .... From buildsys at redhat.com Wed Sep 1 11:30:26 2004 From: buildsys at redhat.com (Build System) Date: Wed, 1 Sep 2004 07:30:26 -0400 Subject: rawhide report: 20040901 changes Message-ID: <200409011130.i81BUQv00550@porkchop.devel.redhat.com> New package arptables_jf Userspace control program for the arptables network filter. New package dasher GNOME Accesibility method New package gnome-nettool A GNOME interface for various networking tools Updated Packages: MAKEDEV-3.9.2-1 --------------- * Tue Aug 31 2004 Nalin Dahyabhai 3.9.2-1 - remove the MAKEDEV symlink from /dev, which allows removal of the %pre scriptlet (#131075) - make storage devices group-read-only (#110197) * Mon Aug 30 2004 Nalin Dahyabhai - update to 30 August 2004 devices.txt: - give ttySMX callout devices non-conflicting names - point man page to /sbin instead of /dev am-utils-6.0.9-8 ---------------- * Tue Aug 31 2004 Nalin Dahyabhai 6.0.9-8 - rebuild anaconda-10.0.2-0.20040831180702 -------------------------------- * Tue Aug 31 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode autofs-4.1.3-17 --------------- * Tue Aug 31 2004 Jeff Moyer - 1:4.1.3-17 - Add patch to support parsing nsswitch.conf to determine map sources. - Disable this patch, and Ian's map expiry patch for a FC build. * Tue Aug 24 2004 Jeff Moyer - 1:4.1.3-16 - Version 3 of Ian's map expiry changes. * Wed Aug 18 2004 Jeff Moyer - 1:4.1.3-15 - Fix a socket leak in the rpc_subs, causing mounts to fail since we are running out of port space fairly quickly. desktop-printing-0.10.2-1 ------------------------- * Tue Aug 31 2004 Colin Walters 0.10.2-1 - Update to 0.10.2 - Require cups. * Tue Aug 31 2004 Colin Walters 0.10-1 - Update to 0.10.1 - Enable session CUPS daemon - Require hal-cups-utils per j5 request - Nuke eggcups_version variable, just use version - Remove unneeded deps on perl, gnome-utils, file - Remove upstreamed dbus-header-fix patch distcache-1.4.5-6 ----------------- * Tue Aug 31 2004 Joe Orton 1.4.5-6 - move ldconfig from preun to postun (#131289) firstboot-1.3.19-1 ------------------ * Tue Aug 31 2004 Adrian Likins - 1.3.19-1 * #131308 (system-config-date changed, working to not traceback, still needs more fixing) gdb-6.1post-1.20040607.28 ------------------------- * Tue Aug 31 2004 Jeff Johnston 1.200400607.28 - Add test case for bugzilla 128618 fix. * Mon Aug 30 2004 Jeff Johnston 1.200400607.27 - Add support for breakpoints in manually loaded/unloaded shared libs. (bugzilla 128618) glibc-2.3.3-47 -------------- * Tue Aug 31 2004 Jakub Jelinek 2.3.3-47 - update from CVS - persistent nscd caching - ppc64 32-bit atomicity fix - fix x86-64 nptl-devel headers for -m32 compilation - %ghost /etc/ld.so.cache (#130597) - edit /etc/ld.so.conf in glibc_post_upgrade if include ld.so.conf.d/*.conf line is missing (#120588) - ugly hacks for the IA-64 /emul braindamage (#124996, #128267) * Sat Aug 21 2004 Jakub Jelinek 2.3.3-46 - update from CVS * Thu Aug 19 2004 Jakub Jelinek 2.3.3-45 - update from CVS - fix nss_compat's initgroups handling (#130363) - fix getaddrinfo ai_canonname setting gnome-applets-2.7.3-2 --------------------- * Wed Sep 01 2004 Mark McLoughlin 2.7.3-2 - Rebuild gnome-media-2.7.92-2 -------------------- * Tue Aug 31 2004 Colin Walters 2.7.92-2 - Add patch to use correct sink for gnome-cd gnome-system-monitor-2.7.0-2 ---------------------------- * Wed Sep 01 2004 Florian La Roche - rebuild gnome-volume-manager-0.9.10-2 ----------------------------- * Wed Sep 01 2004 Davidz Zeuthen - Fix a few issues to keep up with hal * Tue Aug 31 2004 John (J5) Palmieri - Update to upstream release 0.9.10 - Add gthumb-import wrapper to import photos correctly - Add patch to set gthumb-import as the default photo importer - Add patch to put desktop file in the X-Red-Hat-Base Catagory - Fixes RH Bug 130866 gnopernicus-0.9.10-2 -------------------- * Tue Aug 31 2004 Colin Walters 0.9.10-2 - Fix license field to be LGPL - Change description to "GNOME Screen reader" gphoto2-2.1.4-6 --------------- * Tue Aug 31 2004 Tim Waugh 2.1.4-6 - Fixed mis-applied patch (bug #130755). gstreamer-plugins-0.8.4-1 ------------------------- * Tue Aug 31 2004 Colin Walters - 0.8.4-1 - Update to 0.8.4 - Add gstglimagesink hal-0.2.97.cvs20040901-1 ------------------------ * Wed Sep 01 2004 David Zeuthen 0.2.97.cvs20040901-1 - Update to upstream CVS HEAD * Tue Aug 31 2004 David Zeuthen 0.2.97.cvs20040831-3 - Add UID for haldaemon user * Tue Aug 31 2004 David Zeuthen 0.2.97.cvs20040831-2 - Rebuilt with a newer snapshot. hal-cups-utils-0.5.1-2 ---------------------- * Tue Aug 31 2004 John (J5) Palmieri - Add build requirement on dbus-devel and system-config-printer * Tue Aug 31 2004 John (J5) Palmieri - Update to 0.5.1 * Fri Aug 27 2004 John (J5) Palmieri - Update to 0.5.0 im-sdk-12.0.1-2.svn1891 ----------------------- * Tue Aug 31 2004 Akira TAGOH 1:12.0.1-2.svn1891 - im-sdk-12.0.1-iiimsf-xmlconf.patch: applied to use the xml configuration files for all of configuration stuff. htt.conf will be replaced by htt.xml.conf then. NOTE: since htt.conf isn't marked as %config, it's always replaced with new one. for people who modified it manually, old htt.conf will be stored as /etc/htt.conf.old. and /etc/iiim/htt.xml.conf is now marked as %config. please modify it manually if you like. and please feel free to remove /etc/htt.conf.old after that. - im-sdk-11.4-sysconfdir.patch: removed so that no longer need. - im-sdk-11.4-htt-local-permit.patch: removed so that no longer need. - im-sdk-11.4-iiimsf-xmlconf.patch: removed so that no longer need. * Tue Aug 31 2004 Jens Petersen - drop fc2 compatibility symlink in /etc/init.d/ since it breaks chkconfig (Wes Shull, 129829) - buildrequire FreeWnn-devel and flex if building -le-freewnn (Warren Togami) - iiimf-emacs now requires emacs - do not remove install root in %prep * Mon Aug 30 2004 Akira TAGOH - im-sdk-11.4-canna-aux.patch: applied to enable the aux window for Canna LE. (#122165) kernel-2.6.8-1.538 ------------------ * Tue Aug 31 2004 Arjan van de Ven - fix execshield buglet with legacy binaries - 2.6.9-rc1-bk7 krb5-1.3.4-7 ------------ * Tue Aug 31 2004 Nalin Dahyabhai 1.3.4-7 - rebuild * Tue Aug 24 2004 Nalin Dahyabhai 1.3.4-6 - rebuild * Tue Aug 24 2004 Nalin Dahyabhai 1.3.4-5 - incorporate revised fixes from Tom Yu for CAN-2004-0642, CAN-2004-0644, CAN-2004-0772 krbafs-1.2.2-5 -------------- * Tue Aug 31 2004 Nalin Dahyabhai 1.2.2-5 - add a preliminary patch for using ioctl interfaces * Fri Jun 25 2004 Nalin Dahyabhai 1.2.2-4 - link libkrbafs.so directly against the libraries on which it depends kudzu-1.1.84-1 -------------- * Tue Aug 31 2004 Bill Nottingham 1.1.84-1 - fix loader segfault (#131375) - updated i2o probing () libcap-1.10-20 -------------- * Tue Aug 31 2004 Phil Knirsch 1.10-20 - Fix wrong typedef in userland patch (#98801) libgal2-2.2.0-2 --------------- * Tue Aug 31 2004 David Malcolm - rebuilt * Tue Aug 31 2004 David Malcolm - 2:2.2.0-1 - update from 2.1.14 to 2.2.0 libgnomecups-0.1.11-3 --------------------- * Tue Aug 31 2004 Matthias Clasen 0.1.11-3 - Fix some issues with the async ppd patch libgnomeprintui22-2.7.1-5 ------------------------- * Tue Aug 31 2004 Matthias Clasen 2.7.1-5 - Fix the initial selection of the default printer. libidn-0.5.4-2 -------------- * Tue Aug 31 2004 Joe Orton 0.5.4-2 - move ldconfig from preun to postun (#131280) libselinux-1.17.6-1 ------------------- * Tue Aug 31 2004 Dan Walsh 1.17.6-1 - Add strcasecmp in selinux_config - Update from NSA * Changed avc_has_perm_noaudit to not fail on netlink errors. * Changed avc netlink code to check pid based on patch by Steve Grubb. * Merged second optimization patch from Ulrich Drepper. * Changed matchpathcon to skip invalid file_contexts entries. * Made string tables private to libselinux. * Merged strcat->stpcpy patch from Ulrich Drepper. * Merged matchpathcon man page from Dan Walsh. * Merged patch to eliminate PLTs for local syms from Ulrich Drepper. * Autobind netlink socket. * Dropped compatibility code from security_compute_user. * Merged fix for context_range_set from Chad Hanson. * Merged allocation failure checking patch from Chad Hanson. * Merged avc netlink error message patch from Colin Walters. libsoup-2.2.0-1 --------------- * Tue Aug 31 2004 David Malcolm - 2.2.0-1 - update from 2.1.13 to 2.2.0 logwatch-5.2.2-1 ---------------- * Wed Jul 14 2004 Elliot Lee 5.2.2-1 - Update to 5.2.2 - Patch for #126558, #101744 * Wed Jul 07 2004 Elliot Lee 5.1-6 - Extra patch from #80496 * Tue Jun 15 2004 Elliot Lee - rebuilt mailman-2.1.5-12 ---------------- * Tue Aug 31 2004 John Dennis 3:2.1.5-12 - fix bug #129920, cron jobs execute under wrong SELinux policy mkinitrd-4.1.9-1 ---------------- * Tue Aug 31 2004 Jeremy Katz - 4.1.9-1 - mkinitrd: use tmpfs instead of ramfs for udev stuff module-init-tools-3.1-0.pre5.1 ------------------------------ * Tue Aug 31 2004 Bill Nottingham 3.1-0.pre5.1 - update to 3.1-pre5 ncurses-5.4-13 -------------- * Tue Aug 31 2004 Adrian Havill 5.4-13 - term.sh can't detect CJK environment; revert - gt 2.7 behaves better with xterm-new * Tue Aug 03 2004 Adrian Havill 5.4-12 - make xterm same as xterm-r6 - detect for "dumb" in term.sh nss_ldap-220-3 -------------- * Tue Aug 31 2004 Nalin Dahyabhai 220-3 - rebuild pam_krb5-2.1.2-1 ---------------- * Mon Aug 30 2004 Nalin Dahyabhai - 2.1.2-1 - update to 2.1.2 pciutils-2.1.99.test8-2 ----------------------- * Tue Aug 31 2004 Bill Nottingham 2.1.99.test8-2 - update to test8 - fix headers * Fri Jul 09 2004 Bill Nottingham 2.1.99.test7-1 - update to test7 - fix segfault on some x86-64 boxen * Tue Jun 15 2004 Elliot Lee - rebuilt planner-0.12-3 -------------- * Tue Aug 31 2004 Warren Togami 0.12-3 - #131285 proper find_lang usage rpmdb-fedora-3-0.20040901 ------------------------- s390utils-1.3.1-5 ----------------- * Tue Aug 31 2004 Karsten Hopp 2:1.3.1-5 - install zfcpconf.sh into /sbin squirrelmail-1.4.3-2 -------------------- * Tue Aug 31 2004 Warren Togami 1.4.3-2 - #125638 config_local.php and default_pref in /etc/squirrelmail/ to match upstream RPM. This should allow smoother drop-in replacements and upgrades. - other spec cleanup system-config-bind-2.0.3-1 -------------------------- * Tue Jul 13 2004 Dan Walsh 2.0.3-1 - Add IPV6 support - Add modifications supplied by Ivan Gyurdiev udev-030-11 ----------- * Tue Aug 31 2004 Jeremy Katz - 030-11 - use tmpfs instead of ramfs (it has xattr support now) - change variables appropriately to TMPFS intead of RAMFS in udev.conf - create loopN, not just loop in start_udev vino-2.7.92-2 ------------- * Wed Sep 01 2004 Mark McLoughlin 2.7.92-2 - Add patch to fix hang without GNU TLS (bug #131354) vixie-cron-4.1-11 ----------------- * Tue Aug 31 2004 Jason Vas Dias - 4.1-10 - Fixed SIGSEGV in free_user when !is_selinux_enabled() and crontab - has no valid jobs (bug 131390). * Wed Aug 11 2004 Jason Vas Dias - 4.1.9 - Removed 0600 mode enforcement as per Florian La Roche's request * Tue Aug 10 2004 Jason Vas Dias - 4.1.8 - Allowed editors such as 'gedit' which do not modify original - file, but which rename(2) a temp file to original, to be used - by crontab -e (bug 129170). vte-0.11.11-2 ------------- * Tue Aug 31 2004 Warren Togami 0.11.11-2 - #111012 BuildReq gettext, ncurses-devel - remove large and not useful doc xmlsec1-1.2.6-3 --------------- * Wed Sep 01 2004 Daniel Veillard 1.2.6-3 - adding missing ldconfig calls * Thu Aug 26 2004 Daniel Veillard 1.2.6-2 - updated with upstream release from Aleksey * Mon Jun 21 2004 Daniel Veillard 1.2.5-2 - rebuilt xorg-x11-6.7.99.903-2 --------------------- * Tue Aug 31 2004 Mike A. Harris 6.7.99.903-2 - Remove "xtt" module line from config file on upgrades, as X.Org no longer supplies that module, since the "freetype" module now includes the functionality that was only available in the "xtt" module before. ypserv-2.13-4 ------------- * Tue Aug 31 2004 Steve Dickson - Zeroed out the ypxfr response buffer so allocated memory is not freed with the transfer fails * Sat Jun 19 2004 Steve Dickson - Closed a memory leak in GDBM database routines (bz 120980) From wtogami at redhat.com Wed Sep 1 11:54:59 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 01 Sep 2004 01:54:59 -1000 Subject: Why aren't aspell-XX packages noarch? In-Reply-To: <20040901131445.63e26551@localhost> References: <20040901131445.63e26551@localhost> Message-ID: <4135B893.5080404@redhat.com> Matthias Saou wrote: > Hi, > > I was wondering why the numerous aspell-XX packages were built for each > arch instead of being noarch. It seems to me that they don't contain any > kind of arch specific files, and the total amount of disk space they > currently occupy for each arch in the Fedora Core Development tree is about > 75MB. Should I bugzilla this or are there strong arguments against it > (other than "most tools don't update packages when they change arch", > *sigh*)? Simple solution, rename everything to aspellcode-XX. =) /me runs. > > Which raises another point : I really hope Seth implements a kind of > "ExactArchPkgs=kernel kernel-smp glibc" configuration quickly to yum "TNG" > :-) Note that apt doens't have this problem... Warren From rdieter at math.unl.edu Wed Sep 1 12:08:55 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 1 Sep 2004 07:08:55 -0500 (CDT) Subject: Feature request regarding modularity of DISPLAYMANAGERS in the upcoming fc3 In-Reply-To: <1094033195.31864.4.camel@localhost.localdomain> References: <1094033195.31864.4.camel@localhost.localdomain> Message-ID: On Wed, 1 Sep 2004, Rudolf Kastl wrote: > As you all know the current way of selecting DISPLAYMANAGERS (such as > kdm gdm...) is rather nonmodular. What's lacking in simply modifying /etc/sysconfig/desktop as it is now? -- Rex From fedora at wir-sind-cool.org Wed Sep 1 12:54:50 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 1 Sep 2004 14:54:50 +0200 Subject: Help on bug reports for gdal (bug 1964) In-Reply-To: <20040901101806.GK16620@intevation.de> References: <20040901101806.GK16620@intevation.de> Message-ID: <20040901145450.12ef0ea4.fedora@wir-sind-cool.org> On Wed, 1 Sep 2004 12:18:06 +0200, Silke Reimer wrote: > I announced gdal on fedora.us and last week I got some comments on > my package[1]. Some of them are quite clear and will be fixed when I > prepared my new package but I didn't understand all of them. Perhaps > you can comment on them: > > > Minor: > > * Permissions on files in *.src.rpm: > > W: gdal strange-permission gdal-1.2.1.tar.gz 0600 > > W: gdal strange-permission gdal.spec 0664 > > W: gdal strange-permission gdal-install.patch 0664 > > What are the permission supposed to be? Not group-writable, but 0644. But as the comment says, a minor issue and not a blocker criterion. [A user, who would extract the src.rpm to /tmp, should not get group-/world-writable files.] > > Severe: > > * Package does not honor $RPM_OPT_FLAGS > > Can you please give me a pointer where I find more information on > $RPM_OPT_FLAGS? I did have a look at > http://fedora.redhat.com/participate/developers-guide/ but couldn't > find anything. $RPM_OPT_FLAGS are defined below /usr/lib/rpm and used by rpmbuild, see beginning of an rpmbuild session log: + CFLAGS=-O2 -g -pipe -march=i386 -mcpu=i686 + export CFLAGS + CXXFLAGS=-O2 -g -pipe -march=i386 -mcpu=i686 + export CXXFLAGS + FFLAGS=-O2 -g -pipe -march=i386 -mcpu=i686 + export FFLAGS A package should accept these flags. If it doesn't, the reason could be that it has other CFLAGS hardcoded. It may be necessary to patch the sources (Makefiles) somehow, e.g. hack it with sed. > > * A lot of the explicit "Requires: proj, xerces-j, libjpeg, > > shapelib, libungif, > > zlib, libpng, postgresql-libs" ought to be dropped. Explicit > > dependencies on > > library package names ask for trouble. Most of the libraries surely > > are > > automatic dependencies already. Check output of "rpm --query > > --requires > > PACKAGENAME". > > OK. But how can I get the information about the package that has to > be installed to fulfill the various dependencies. Let tools like up2date/yum/apt-get do that. Or if you insist on installing packages with plain rpm, use "rpm --redhatprovides" queries, e.g. $ rpm --redhatprovides /usr/lib/libgdk-1.2.so.0 gtk+-1.2.10-28.1 and "rpm --aid -Uvh ...". The rpmdb-fedora package must be installed for that to work. > This is the reason > why you must provide the names of all packages that have to be > installed when you prepare a debian package. This is Fedora Core, not Debian. Hardcoding library package names is error-prone, because when the package is renamed or a library is moved into a sub-package, the hardcoded dependency breaks and increases the maintenance efforts. Explicit "Requires:" also make it impossible to replace packages with alternatives. http://www.fedora.us/wiki/HOWTOUseRequires > A last issue: You mentioned to have used rpmlint on my package. So I > did this as well and got lots of new warnings and errors among them > > E: gdal executable-in-library-package /usr/bin/gdalwarp > E: gdal non-versioned-file-in-library-package /usr/share/gdal/esri_extra.wkt > E: gdal non-versioned-file-in-library-package /usr/share/man/man1/ogrtindex.1.gz > W: gdal devel-file-in-non-devel-package /usr/lib/python2.3/site-packages/_gdalmodule.a > > rpmlint is right: These package should rather be in gdal-bin, > python-gdal etc. My question: How shall I define subpackage in the > specfile so that the package names will not be libgdal-bin but gdal-bin > etc. Is this possible? Yes. But rpmlint's suggestions are not mandatory. rpmlint in fedora.us is customized a bit, but also catches many "false positives". It is not uncommon to have tools in library packages, e.g. /usr/bin/foo-config style programs or tools in the -devel package. rpmlint is right about the static library, though. To create sub-packages, you would need additional spec file sections: %package SUBPACKAGENAME Summary: Buildrequires: [other tags] %description SUBPACKAGENAME %files SUBPACKAGENAME > BTW: Is there a reason why rpmlint is not mentioned on > http://www.fedora.us/wiki/PackageSubmissionQAPolicy? IMHO it helps > to avoid lots of problems when packaging. Thus the packages will > probably be of better quality when they are announced on fedora.us. http://www.fedora.us/wiki/PackagingHints From rc040203 at freenet.de Wed Sep 1 13:45:52 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Sep 2004 15:45:52 +0200 Subject: Help on bug reports for gdal (bug 1964) In-Reply-To: <20040901101806.GK16620@intevation.de> References: <20040901101806.GK16620@intevation.de> Message-ID: <1094046352.25156.32900.camel@mccallum.corsepiu.local> On Wed, 2004-09-01 at 12:18, Silke Reimer wrote: > Hallo! > > I announced gdal on fedora.us and last week I got some comments on > my package[1]. Some of them are quite clear and will be fixed when I > prepared my new package but I didn't understand all of them. Perhaps > you can comment on them: > > > Minor: > > * Permissions on files in *.src.rpm: > > W: gdal strange-permission gdal-1.2.1.tar.gz 0600 > > W: gdal strange-permission gdal.spec 0664 > > W: gdal strange-permission gdal-install.patch 0664 > > What are the permission supposed to be? Standard permissions for all files in an src.rpm would be 0644. Besides from what Michael wrote, 0664 is considered to be a security risk for automated build systems, 0600 is too restrictive for some chroot-based build-systems (e.g. mach). > > * Partially low coding quality: > > ... > > gdal_wrap.c:1136: warning: dereferencing type-punned pointer will > > break > > strict-aliasing rules > > gdal_wrap.c: In function `py_StringListToList': > > gdal_wrap.c:1205: warning: dereferencing type-punned pointer will > > break > > strict-aliasing rules > > gdal_wrap.c: In function `ptrptrset': > > [Dozens of similar warnings more.] > > > > As the package is reported to work on ia32, these warnings are > > unlikely to break > > the package, but they very likely cause the package to be > > non-functional with > > future GCCs and on other architectures. > > OK. I will inform the upstream author of the package. Do you have > other suggestions what can be done regarding this issue? Fix the code ;) Such cases typically are nasty typecasts, which are incompatible to newer C/C++ standards and which newer gcc's (gcc >= 3.3) started to complain about. Ralf From che666 at uni.de Wed Sep 1 14:05:07 2004 From: che666 at uni.de (Rudolf Kastl) Date: Wed, 01 Sep 2004 16:05:07 +0200 Subject: Feature request regarding modularity of DISPLAYMANAGERS in the upcoming fc3 In-Reply-To: References: <1094033195.31864.4.camel@localhost.localdomain> Message-ID: <1094047507.7292.2.camel@localhost.localdomain> hello how would you package a new displaymanager properly without replacing sysinternals? i dont want to hack in other packages files. and also theres no point in expanding the bash script while there could be work invested in a real fix. the current solution isnt a solution at all. its nonmodular etc my above solution would be a proper fix and well also the switchdesk problem if properly solved would produce a gui for it aswell. regards, rudolf kastl Am Mi, den 01.09.2004 um 7:08 Uhr -0500 schrieb Rex Dieter: > On Wed, 1 Sep 2004, Rudolf Kastl wrote: > > > As you all know the current way of selecting DISPLAYMANAGERS (such as > > kdm gdm...) is rather nonmodular. > > What's lacking in simply modifying > /etc/sysconfig/desktop > as it is now? > > -- Rex > > From rdieter at math.unl.edu Wed Sep 1 14:17:05 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 01 Sep 2004 09:17:05 -0500 Subject: modularity of DISPLAYMANAGERS In-Reply-To: <1094047507.7292.2.camel@localhost.localdomain> References: <1094033195.31864.4.camel@localhost.localdomain> <1094047507.7292.2.camel@localhost.localdomain> Message-ID: <4135D9E1.70506@math.unl.edu> Rudolf Kastl wrote: > how would you package a new displaymanager properly without replacing > sysinternals? To run your new/fancy foodm, set in /etc/sysconfig/desktop: DISPLAYMANAGER=foodm How is that insufficient? -- Rex From skvidal at phy.duke.edu Wed Sep 1 14:25:16 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Sep 2004 10:25:16 -0400 Subject: yum 2.1.0 In-Reply-To: <1093975532.3676.20.camel@support02.civic.twp.ypsilanti.mi.us> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <1093975532.3676.20.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1094048715.14127.10.camel@opus.phy.duke.edu> > It'd also be nice if yum supported 'temporary' repositories that were > passed to it on the command line or through library calls, so, for > example, an application RPM could include some meta-data pointing toa > repository containing dependencies, so users don't have to a) manually > add the repository to their yum.conf or b) manually download all the > dependencies. It seems to me that a 'temporary' repository is a root kit waiting to happen. -sv From che666 at uni.de Wed Sep 1 14:30:37 2004 From: che666 at uni.de (Rudolf Kastl) Date: Wed, 01 Sep 2004 16:30:37 +0200 Subject: modularity of DISPLAYMANAGERS In-Reply-To: <4135D9E1.70506@math.unl.edu> References: <1094033195.31864.4.camel@localhost.localdomain> <1094047507.7292.2.camel@localhost.localdomain> <4135D9E1.70506@math.unl.edu> Message-ID: <1094049037.7292.6.camel@localhost.localdomain> The file is present. should i just sed around in a file that doesent belong to the package? i think you miss a bit the point here. regards, rudolf kastl Am Mi, den 01.09.2004 um 9:17 Uhr -0500 schrieb Rex Dieter: > Rudolf Kastl wrote: > > > how would you package a new displaymanager properly without replacing > > sysinternals? > > To run your new/fancy foodm, set in /etc/sysconfig/desktop: > DISPLAYMANAGER=foodm > > How is that insufficient? > > -- Rex > > From rdieter at math.unl.edu Wed Sep 1 14:37:07 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 01 Sep 2004 09:37:07 -0500 Subject: modularity of DISPLAYMANAGERS In-Reply-To: <1094049037.7292.6.camel@localhost.localdomain> References: <1094033195.31864.4.camel@localhost.localdomain> <1094047507.7292.2.camel@localhost.localdomain> <4135D9E1.70506@math.unl.edu> <1094049037.7292.6.camel@localhost.localdomain> Message-ID: <4135DE93.8010303@math.unl.edu> Rudolf Kastl wrote: > The file is present. should i just sed around in a file that doesent > belong to the package? > > i think you miss a bit the point here. Clearly I am missing the point. I thought you wanted to be able to specify alternative DISPLAYMANAGERs. So what *is* the point? -- Rex From elanthis at awesomeplay.com Wed Sep 1 14:40:10 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 01 Sep 2004 10:40:10 -0400 Subject: yum 2.1.0 In-Reply-To: <1094048715.14127.10.camel@opus.phy.duke.edu> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <1093975532.3676.20.camel@support02.civic.twp.ypsilanti.mi.us> <1094048715.14127.10.camel@opus.phy.duke.edu> Message-ID: <1094049610.16114.2.camel@support02.civic.twp.ypsilanti.mi.us> On Wed, 2004-09-01 at 10:25 -0400, seth vidal wrote: > > It'd also be nice if yum supported 'temporary' repositories that were > > passed to it on the command line or through library calls, so, for > > example, an application RPM could include some meta-data pointing toa > > repository containing dependencies, so users don't have to a) manually > > add the repository to their yum.conf or b) manually download all the > > dependencies. > > It seems to me that a 'temporary' repository is a root kit waiting to > happen. It's no worse than users installing any other RPM. If you don't trust the source, don't use it. Certainly with signed RPMs and a little bit of clue on the part of the user unintentional installation of untrusted packages can be avoided. So long as you have someone who doesn't know or doesn't care about good security, you're not going to stop them from installing something malicious. The temporary repository in this example would only be ever referenced during the initial installation of the application RPM - if the vendor of the RPM wanted to install malicious code, there is no reason for them to put it in a separate package instead of just putting the code directly in the app RPM. > > -sv > > > > -- Sean Middleditch AwesomePlay Productions, Inc. From havill at redhat.com Wed Sep 1 14:41:55 2004 From: havill at redhat.com (Adrian Havill) Date: Wed, 01 Sep 2004 10:41:55 -0400 Subject: Why aren't aspell-XX packages noarch? In-Reply-To: <20040901131445.63e26551@localhost> References: <20040901131445.63e26551@localhost> Message-ID: <4135DFB3.3090902@redhat.com> Matthias Saou wrote: >I was wondering why the numerous aspell-XX packages were built for each >arch instead of being noarch. > They're not noarch (despite the packaging of some other distros)-- we found this out the hard way when they were briefly noarch for a period of time until we noticed the dictionaries failing on big endian and/or 64bit platforms (forget which) like the ppc. If this has changed with very recent versions of the 0.50 series, it will require retesting. From che666 at uni.de Wed Sep 1 14:45:15 2004 From: che666 at uni.de (Rudolf Kastl) Date: Wed, 01 Sep 2004 16:45:15 +0200 Subject: modularity of DISPLAYMANAGERS In-Reply-To: <4135DE93.8010303@math.unl.edu> References: <1094033195.31864.4.camel@localhost.localdomain> <1094047507.7292.2.camel@localhost.localdomain> <4135D9E1.70506@math.unl.edu> <1094049037.7292.6.camel@localhost.localdomain> <4135DE93.8010303@math.unl.edu> Message-ID: <1094049915.7292.13.camel@localhost.localdomain> Am Mi, den 01.09.2004 um 9:37 Uhr -0500 schrieb Rex Dieter: > Rudolf Kastl wrote: > > The file is present. should i just sed around in a file that doesent > > belong to the package? > > > > i think you miss a bit the point here. > > Clearly I am missing the point. I thought you wanted to be able to > specify alternative DISPLAYMANAGERs. > > So what *is* the point? I want to be able to package alternative displaymanagers in a way it can work "out of the box" the current way requires the user to hack some config files and since SWITCHDESK needs a replacement anyways and the freedesktop.org standard seems to be yet missing the DISPLAYMANAGER part its a pretty sucky solution imho. The switchdesk guis need a rewrite. so if theres just a bit sanity there could be change in the way DMs are handled too and you could even reuse the same gui. its work that has to be done anyways so i dont see your stance here. Do you think the way it currently is great? I dont need help with my personal setup. thats not the problem and that would be the wrong list. But anyways if you dont agree on the other parts either like getting that stuff standardized oh well... then i am not sure if we have a common base of interests. regards, rudolf kastl > > -- Rex > > From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Sep 1 14:52:56 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 1 Sep 2004 16:52:56 +0200 Subject: Why aren't aspell-XX packages noarch? In-Reply-To: <4135DFB3.3090902@redhat.com> References: <20040901131445.63e26551@localhost> <4135DFB3.3090902@redhat.com> Message-ID: <20040901165256.003bf848@localhost> Adrian Havill wrote : > Matthias Saou wrote: > > >I was wondering why the numerous aspell-XX packages were built for each > >arch instead of being noarch. > > They're not noarch (despite the packaging of some other distros)-- we > found this out the hard way when they were briefly noarch for a period > of time until we noticed the dictionaries failing on big endian and/or > 64bit platforms (forget which) like the ppc. If this has changed with > very recent versions of the 0.50 series, it will require retesting. Thanks for the answer. Maybe the problems are indeed solved, especially since lots of issues have gone away when the {a,i,p}spell confusion got sorted out. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.04 0.33 0.42 From jspaleta at gmail.com Wed Sep 1 15:10:02 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 1 Sep 2004 11:10:02 -0400 Subject: modularity of DISPLAYMANAGERS In-Reply-To: <1094049915.7292.13.camel@localhost.localdomain> References: <1094033195.31864.4.camel@localhost.localdomain> <1094047507.7292.2.camel@localhost.localdomain> <4135D9E1.70506@math.unl.edu> <1094049037.7292.6.camel@localhost.localdomain> <4135DE93.8010303@math.unl.edu> <1094049915.7292.13.camel@localhost.localdomain> Message-ID: <604aa79104090108107fc93d52@mail.gmail.com> On Wed, 01 Sep 2004 16:45:15 +0200, Rudolf Kastl wrote: > The switchdesk guis need a rewrite. so if theres just a bit sanity there > could be change in the way DMs are handled too and you could even reuse > the same gui. First of all.. switchdesk i think is aimed primarily at being a tool for individual users to set their prefered desktop environment inside a user's home directory. Changing which DM is used is system-wide and would need administration privs to work. Personally I do not think its a good idea to add this feature to the switchdesk interface. You are thinking one user, one system. I think its very important when thinking about gui's to think multi-user, and make sure there is a distinction between what non-admin users see in terms of tools and what admin users see as tools, becuase I certaintly don't want end-user seeing or interacting with the gui for DM selection, i want to lock that down so only users with admin privs see that. But yeah the script logic controlling how prefdm works is mighty... crusty. But its just script logic. I'm sure if you wanted to try your hand at rebuilding the /etc/X11/prefdm script to make it easier to allow for additional DM's that would not be unwelcomed coding work. Once you have an example script replacement or patch to the current prefdm submitted to bugzilla, there might be more to talk about in terms of a gui. My guess is the lack of more generalized prefdm logic is partly if not mostly manpower/priority constraints related. So volunteering to rebuild the prefdm script and submit it for review might move this discussion forward. -jef From rdieter at math.unl.edu Wed Sep 1 15:10:23 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 01 Sep 2004 10:10:23 -0500 Subject: modularity of DISPLAYMANAGERS In-Reply-To: <1094049915.7292.13.camel@localhost.localdomain> References: <1094033195.31864.4.camel@localhost.localdomain> <1094047507.7292.2.camel@localhost.localdomain> <4135D9E1.70506@math.unl.edu> <1094049037.7292.6.camel@localhost.localdomain> <4135DE93.8010303@math.unl.edu> <1094049915.7292.13.camel@localhost.localdomain> Message-ID: <4135E65F.1070900@math.unl.edu> Rudolf Kastl wrote: >>So what *is* the point? > I want to be able to package alternative displaymanagers in a way it can > work "out of the box" the current way requires the user to hack some > config files I don't consider editing /etc/sysconfig/desktop a hack, but that's just me. > and since SWITCHDESK needs a replacement anyways and the > freedesktop.org standard seems to be yet missing the DISPLAYMANAGER part > its a pretty sucky solution imho. I will say here that it seems you're tackling several different problems/issues here (though your intention sounds to unify the setup for these): 1. What DISPLAYMANAGER (ie, login manger) to use by default. 2. What DESKTOP to use by default 3. Installing/using *new* DISPLAYMANGERs 4. Installing *new* DESKTOPs complete with full support from a. switchdesk. b. all/existing (standard-compliant) DISPLAYMANAGERs Now, if you want more than what I mentioned here, please elaborate. As I've said (and won't again), I think (1),(2),(3) are handled nicely already via /etc/sysconfig/desktop For (4a), I agree switchdesk could use improvement: Offhand, it appeared to me at first as though dropping a new Xclients.foodm into /usr/share/switchdesk would be enough to make it work, but alas, there's a bunch of stuff hard-coded into /usr/bin/switchdesk-helper For (4b), DISPLAYMANGER support for new desktops, I agree that needs standardization. At least in the case of gdm and kdm, they seem quasi standardized, but don't look in the same place for options (/usr/share/xsessions for gdm, and /usr/share/apps/kdm/sessions for kdm). It would appear gdm is doing the better thing here. IMO, kdm (or any DISPLAYMANAGER) should follow suit and use /usr/share/xsessions (or some other agreed-upon, shared location). -- Rex From michael at insitesinc.com Wed Sep 1 15:16:13 2004 From: michael at insitesinc.com (Michael Favia) Date: Wed, 01 Sep 2004 10:16:13 -0500 Subject: firefox and thunderbird for rawhide In-Reply-To: <41359AD5.60009@redhat.com> References: <41359AD5.60009@redhat.com> Message-ID: <4135E7BD.6030107@insitesinc.com> Warren Togami wrote: > According to Havoc, firefox and thunderbird must be added for > FC3/RHEL4 target. I am now rushing to build them into rawhide. Your > assistance in testing and analysis would be greatly appreciated. > While there are a number of issues currently affecting proper operation of Firefox and thunderbird in FC at this time I for one will be happy to analyze and test these two components in particular. Ive been looking forward to this inclusion for some time now. My hope is that the new availability will further increase the install base for both applications and more importantly the larger install base will consist of those individuals most likely to file useful bugfixes and issues for the quick and betterment of both apps. Thank you for the efforts Warren. -- Michael Favia michael at insitesinc dot com Insites Incorporated http://michael.insitesinc.com From che666 at uni.de Wed Sep 1 15:32:41 2004 From: che666 at uni.de (Rudolf Kastl) Date: Wed, 01 Sep 2004 17:32:41 +0200 Subject: modularity of DISPLAYMANAGERS In-Reply-To: <4135E65F.1070900@math.unl.edu> References: <1094033195.31864.4.camel@localhost.localdomain> <1094047507.7292.2.camel@localhost.localdomain> <4135D9E1.70506@math.unl.edu> <1094049037.7292.6.camel@localhost.localdomain> <4135DE93.8010303@math.unl.edu> <1094049915.7292.13.camel@localhost.localdomain> <4135E65F.1070900@math.unl.edu> Message-ID: <1094052761.7292.30.camel@localhost.localdomain> you missed one of the most important points the extension of the freedesktop.org menu standard. Am Mi, den 01.09.2004 um 10:10 Uhr -0500 schrieb Rex Dieter: > Rudolf Kastl wrote: > > >>So what *is* the point? > > > I want to be able to package alternative displaymanagers in a way it can > > work "out of the box" the current way requires the user to hack some > > config files > > I don't consider editing /etc/sysconfig/desktop a hack, but that's just me. > > > and since SWITCHDESK needs a replacement anyways and the > > freedesktop.org standard seems to be yet missing the DISPLAYMANAGER part > > its a pretty sucky solution imho. > > I will say here that it seems you're tackling several different > problems/issues here (though your intention sounds to unify the setup > for these): > 1. What DISPLAYMANAGER (ie, login manger) to use by default. > 2. What DESKTOP to use by default > 3. Installing/using *new* DISPLAYMANGERs > 4. Installing *new* DESKTOPs complete with full support from > a. switchdesk. > b. all/existing (standard-compliant) DISPLAYMANAGERs > > Now, if you want more than what I mentioned here, please elaborate. > > As I've said (and won't again), I think (1),(2),(3) are handled nicely > already via /etc/sysconfig/desktop > > For (4a), I agree switchdesk could use improvement: > Offhand, it appeared to me at first as though dropping a new > Xclients.foodm into > /usr/share/switchdesk > would be enough to make it work, but alas, there's a bunch of stuff > hard-coded into > /usr/bin/switchdesk-helper > > For (4b), DISPLAYMANGER support for new desktops, I agree that needs > standardization. At least in the case of gdm and kdm, they seem quasi > standardized, but don't look in the same place for options > (/usr/share/xsessions for gdm, and /usr/share/apps/kdm/sessions for > kdm). It would appear gdm is doing the better thing here. IMO, kdm (or > any DISPLAYMANAGER) should follow suit and use /usr/share/xsessions (or > some other agreed-upon, shared location). > > -- Rex > > From rdieter at math.unl.edu Wed Sep 1 15:36:42 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 01 Sep 2004 10:36:42 -0500 Subject: modularity of DISPLAYMANAGERS In-Reply-To: <1094052761.7292.30.camel@localhost.localdomain> References: <1094033195.31864.4.camel@localhost.localdomain> <1094047507.7292.2.camel@localhost.localdomain> <4135D9E1.70506@math.unl.edu> <1094049037.7292.6.camel@localhost.localdomain> <4135DE93.8010303@math.unl.edu> <1094049915.7292.13.camel@localhost.localdomain> <4135E65F.1070900@math.unl.edu> <1094052761.7292.30.camel@localhost.localdomain> Message-ID: <4135EC8A.8060501@math.unl.edu> Rudolf Kastl wrote: > you missed one of the most important points > > the extension of the freedesktop.org menu standard. What extension? I would argue standardizing on dm file locations (like /usr/share/xsessions) would be sufficient, or at least a good starting point. I don't think fdo should get into "standardizing" switchdesk (or a better working equivalent), or is that what you're after? -- Rex From che666 at uni.de Wed Sep 1 15:41:45 2004 From: che666 at uni.de (Rudolf Kastl) Date: Wed, 01 Sep 2004 17:41:45 +0200 Subject: modularity of DISPLAYMANAGERS In-Reply-To: <4135EC8A.8060501@math.unl.edu> References: <1094033195.31864.4.camel@localhost.localdomain> <1094047507.7292.2.camel@localhost.localdomain> <4135D9E1.70506@math.unl.edu> <1094049037.7292.6.camel@localhost.localdomain> <4135DE93.8010303@math.unl.edu> <1094049915.7292.13.camel@localhost.localdomain> <4135E65F.1070900@math.unl.edu> <1094052761.7292.30.camel@localhost.localdomain> <4135EC8A.8060501@math.unl.edu> Message-ID: <1094053305.7292.36.camel@localhost.localdomain> i dont see much more point in continueing to talk theorie... you think its fine as it is according to 80% of your mails and turned a trivial fix for a while bunch of problems down from start. Read the menu standards of fd.o and then figure what is missing besides the dir. regards, rudolf kastl p.s. just a bit bored of talking hot air ;) if you wanna help me implement it your welcome just email me. For productive ideas either but i dont want to waste time to explain basics. Am Mi, den 01.09.2004 um 10:36 Uhr -0500 schrieb Rex Dieter: > Rudolf Kastl wrote: > > you missed one of the most important points > > > > the extension of the freedesktop.org menu standard. > > What extension? I would argue standardizing on dm file locations (like > /usr/share/xsessions) would be sufficient, or at least a good starting > point. > > I don't think fdo should get into "standardizing" switchdesk (or a > better working equivalent), or is that what you're after? > > -- Rex > > From che666 at uni.de Wed Sep 1 15:30:28 2004 From: che666 at uni.de (Rudolf Kastl) Date: Wed, 01 Sep 2004 17:30:28 +0200 Subject: modularity of DISPLAYMANAGERS In-Reply-To: <604aa79104090108107fc93d52@mail.gmail.com> References: <1094033195.31864.4.camel@localhost.localdomain> <1094047507.7292.2.camel@localhost.localdomain> <4135D9E1.70506@math.unl.edu> <1094049037.7292.6.camel@localhost.localdomain> <4135DE93.8010303@math.unl.edu> <1094049915.7292.13.camel@localhost.localdomain> <604aa79104090108107fc93d52@mail.gmail.com> Message-ID: <1094052629.7292.28.camel@localhost.localdomain> Am Mi, den 01.09.2004 um 11:10 Uhr -0400 schrieb Jeff Spaleta: > On Wed, 01 Sep 2004 16:45:15 +0200, Rudolf Kastl wrote: > > The switchdesk guis need a rewrite. so if theres just a bit sanity there > > could be change in the way DMs are handled too and you could even reuse > > the same gui. > > First of all.. switchdesk i think is aimed primarily at being a tool > for individual users to set their prefered desktop environment inside > a user's home directory. Changing which DM is used is system-wide and > would need administration privs to work. right and we could use the regular means like pam auth to solve that problem. > Personally I do not think its > a good idea to add this feature to the switchdesk interface. you understood that wrong. i say you build one gui and use the same gui for both tasks (as 2 different tools) with a minimal change. thats why my above solution solves not only one "problem". if youd use .desktop entrys for the DMs too you could use a dynamical gui for both tasks (every gui scans a dir for .desktop files and sets a default symlink. one does it for windowmanager and one for the displaymanager) > You are > thinking one user, one system. I think its very important when > thinking about gui's to think multi-user, and make sure there is a > distinction between what non-admin users see in terms of tools and > what admin users see as tools, becuase I certaintly don't want > end-user seeing or interacting with the gui for DM selection, i want > to lock that down so only users with admin privs see that. perhaps we need to get the fd.org menu standard in this way expanded too --show-only-in-root ;) /sbin fine for me. ;) > But yeah the script logic controlling how prefdm works is mighty... crusty. yup its thats what i thought. i never said it doesent work. but no one can really convince me that the current solution is good. > But its just script logic. I'm sure if you wanted to try your hand at > rebuilding the /etc/X11/prefdm script to make it easier to allow for > additional DM's that would not be unwelcomed coding work. well if i find enough spare time i will for sure look into it. i just thought that i would throw up a discussion and perhaps other people would recognize the needs here too. It would need a bit help to get the standards forward here. > Once you > have an example script replacement or patch to the current prefdm > submitted to bugzilla, there might be more to talk about in terms of a > gui. yes right. for start a console tool that plain does a symlink would be enough. > My guess is the lack of more generalized prefdm logic is partly > if not mostly manpower/priority constraints related. So volunteering > to rebuild the prefdm script and submit it for review might move this > discussion forward. Well as always. do it yourself ;) but of course as always a productive answer. thanks! I am well aware that my short email contains enough material to write a few pages about details but even after reading it myself it seems to be that the ideas are reflected rather short but still straightforward. > > -jef > > From shockwave at clan-tf20.com Wed Sep 1 16:16:26 2004 From: shockwave at clan-tf20.com (Shockwave) Date: Wed, 01 Sep 2004 12:16:26 -0400 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <4134C176.8050301@lanl.gov> References: <1093964289.20756.101.camel@aries> <20040831150306.GY11465@devserv.devel.redhat.com> <1093974587.20756.139.camel@aries> <4134C176.8050301@lanl.gov> Message-ID: <1094055385.20756.252.camel@aries> On Tue, 2004-08-31 at 14:20, Stephen J Smoogen wrote: > Looking at the other libraries you are going to need the ncurses rpm > also installed in that tree. > > I would also check via lsof that the program is running with just those > libraries. I would also try the last FC1 2.4.x kernel. > > > -- > Stephen John Smoogen smoogen at lanl.gov > Los Alamos National Lab CCN-5 | PH: 4-0645 > Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 Here is the relevant output from lsof when the dynamic version of the game executable is running: /lib/ld-2.3.3.so /lib/libdl-2.3.3.so /lib/libgcc_s-3.3.3-20040413.so.1 /lib/libnss_dns-2.3.3.so /lib/libnss_files-2.3.3.so /lib/libresolv-2.3.3.so /lib/tls/libc-2.3.3.so /lib/tls/libm-2.3.3.so /lib/tls/libpthread-0.61.so /usr/lib/libncurses.so.5.4 /usr/lib/libstdc++.so.5.0.5 Here is the output when the static build is running: /lib/ld-2.3.3.so /lib/libdl-2.3.3.so /lib/libnss_dns-2.3.3.so /lib/libnss_files-2.3.3.so /lib/libresolv-2.3.3.so /lib/tls/libc-2.3.3.so /lib/tls/libm-2.3.3.so /lib/tls/libpthread-0.61.so /usr/lib/libncurses.so.5.4 The only difference between the two are the following lines: /lib/libgcc_s-3.3.3-20040413.so.1 /usr/lib/libstdc++.so.5.0.5 Using the FC1 glibc libraries with the dynamic build yields this: /usr/lib/libncurses.so.5.4 /usr/lib/libstdc++.so.5.0.5 /usr/local/games/bf1942/bf1942_lnxded.dynamic /usr/local/games/fc1glibc/lib/ld-2.3.2.so /usr/local/games/fc1glibc/lib/libdl-2.3.2.so /usr/local/games/fc1glibc/lib/libnss_dns-2.3.2.so /usr/local/games/fc1glibc/lib/libnss_files-2.3.2.so /usr/local/games/fc1glibc/lib/libresolv-2.3.2.so /usr/local/games/fc1glibc/lib/tls/libc-2.3.2.so /usr/local/games/fc1glibc/lib/tls/libm-2.3.2.so /usr/local/games/fc1glibc/lib/tls/libpthread-0.60.so And using the FC1 glibc libraries with the static build shows this: /usr/lib/libncurses.so.5.4 /usr/local/games/bf1942/bf1942_lnxded.static /usr/local/games/fc1glibc/lib/ld-2.3.2.so /usr/local/games/fc1glibc/lib/libdl-2.3.2.so /usr/local/games/fc1glibc/lib/libnss_dns-2.3.2.so /usr/local/games/fc1glibc/lib/libnss_files-2.3.2.so /usr/local/games/fc1glibc/lib/libresolv-2.3.2.so /usr/local/games/fc1glibc/lib/tls/libc-2.3.2.so /usr/local/games/fc1glibc/lib/tls/libm-2.3.2.so /usr/local/games/fc1glibc/lib/tls/libpthread-0.60.so This time, the only difference is this line: /usr/lib/libstdc++.so.5.0.5 Aside from ncurses in the case of the static build using FC1 libraries, there don't appear to be any additional open files that have been missed. With respect to ncurses, I believe it is only used to create the status display of the server output in the shell from which it was launched. I matched all this against the output from ldd and I couldn't find a smoking gun. It looks as if Jakub's trick worked flawlessly and everything that would've been FC1 specific has been captured and put to work. Could this indicate that the kernel is the problem or more specifically the implementation of the FPU as you have suggested Alan? I did try to install the most recent FC1 kernel rpms for 2.4.22-1.2199.nptl as well, but it told me a newer kernel version is already installed and subsequently aborted the installation. Does anyone have any suggestions? -- |TF20|Shockwave http://www.clan-tf20.com/ ICQ# 57671167 #taskforce20 irc.gamesurge.net From drepper at redhat.com Wed Sep 1 16:17:41 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 01 Sep 2004 09:17:41 -0700 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <1094030580.25156.32326.camel@mccallum.corsepiu.local> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <1094030580.25156.32326.camel@mccallum.corsepiu.local> Message-ID: <4135F625.8060904@redhat.com> Ralf Corsepius wrote: >>But there .i686.rpm doesn't help you, > > Can you explain? > > It's the same approach RH applies to glibc and many 3rd party packagers > apply to their package. It is proved that a .i686 package for glibc has benefits. If you find some other package where this makes a real measurable difference, I doubt that you'll find resistance. But you have to prove it first. > My actual concern is less the technical side, but the "policy side" of > shipping "optimized packages" and its impact on "packaging"/"upgrading". .i686 are not "optimized packages" if you cannot prove they are real improvements. Until then they are just doubling the QA efforts without any benefits. > Packing-wise, this has several disadvantages. > 1. You'd have to compile library packages twice. And for a separate .i686 this isn't the case? > 2. Many packages contain both libraries and applications, so you'd have > to apply special measures to assure that applications still get > -march=i386 compiled. Most of the time this is no problem. The application side is small, the majority of the code is in the DSOs. > 3. It would almost double the size of i386.rpms (These sse2 libs would > have to be part of i386.rpms) - Is it worth it? The size of the actual DSOs is not the only factor in the RPM size. This means that two RPMs are bigger then one RPM with two DSO versions. > However, I agree, it's a nice work-around suitable for libraries where > special optimizations can be proven to have a "significant/noticeable" > impact. This is no work-around, this is the preferred solution. And once again: provide us some data about packages where special DSOs or even i686 versions are of benefit. Make this analysis based on modern hardware. For instance, the Northwood cores and earlier benefit more from special i686 rules than prescott and nocona. And the latter are the main targets very soon so adding something just for the benefit of "legacy hardware" is not very attractive. You can believe me, we are looking for possible ways to improve the quality of the shipped code. But the processor makers really do a good job in having the processors execute plain i386 code as good as possible on the processors. Code generation changes have little effects. Except when it comes to using SSE2 etc, and there we already ship code using it. Look at the gmp RPM. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From smoogen at lanl.gov Wed Sep 1 16:46:39 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Wed, 01 Sep 2004 10:46:39 -0600 Subject: yum 2.1.0 In-Reply-To: <1093998882.3817.0.camel@binkley> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> Message-ID: <4135FCEF.6070003@lanl.gov> seth vidal wrote: > On Tue, 2004-08-31 at 10:55 -0600, Stephen J Smoogen wrote: > >>Trying to work with existing code is almost revolutionary in concept. > > > You forgot to close your sarcasm tag. > > here. I'll do it for you. > > > you know. re-reading - it might be a tag. > Sorry > :) > > -sv > > > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From smoogen at lanl.gov Wed Sep 1 16:58:04 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Wed, 01 Sep 2004 10:58:04 -0600 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <1094055385.20756.252.camel@aries> References: <1093964289.20756.101.camel@aries> <20040831150306.GY11465@devserv.devel.redhat.com> <1093974587.20756.139.camel@aries> <4134C176.8050301@lanl.gov> <1094055385.20756.252.camel@aries> Message-ID: <4135FF9C.9000703@lanl.gov> Shockwave wrote: > On Tue, 2004-08-31 at 14:20, Stephen J Smoogen wrote: > > > /usr/lib/libstdc++.so.5.0.5 > I would add the c++ and the ncurses from FC1 'just-in-case' to your /usr/local/games/fc1glibc tree also. use the directions jakub gave in the previous email using rpm2cpio. I am guessing that these will NOT fix the problem.. but it would be best to get those out of the way right now. Nothing better to avoid a glibc/kernel finger pointing match as quickly as possible. ;). > Aside from ncurses in the case of the static build using FC1 libraries, > there don't appear to be any additional open files that have been > missed. With respect to ncurses, I believe it is only used to create > the status display of the server output in the shell from which it was > launched. > > I matched all this against the output from ldd and I couldn't find a > smoking gun. It looks as if Jakub's trick worked flawlessly and > everything that would've been FC1 specific has been captured and put to > work. Could this indicate that the kernel is the problem or more > specifically the implementation of the FPU as you have suggested Alan? > I am heading towards that in my case. My view will be that the server code is written expecting something that 2.4.xx gives FPU wise and 2.6.xx gives differently. The code is closed sourced? If it isnt it would be interesting to find out where it is goofy now.. because it might affect other people doing scientific code who assume that their code works on 2.4 it will work smae on 2.6 > I did try to install the most recent FC1 kernel rpms for > 2.4.22-1.2199.nptl as well, but it told me a newer kernel version is > already installed and subsequently aborted the installation. Does > anyone have any suggestions? > rpm -ivh --force Check grub.conf to make sure it didnt break anything. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From florin.malita at glenayre.com Wed Sep 1 17:13:18 2004 From: florin.malita at glenayre.com (Malita, Florin) Date: Wed, 1 Sep 2004 13:13:18 -0400 Subject: [PATCH] net-tools 1.60: deferred ifconfig netmask Message-ID: <1094058798.4939.8.camel@scox.glenatl.glenayre.com> This has been around for too long: [root at scox root]# ifconfig eth0:1 192.168.120.12/22 SIOCSIFNETMASK: Cannot assign requested address [root at scox root]# ifconfig eth0:1 192.168.120.12/22 [root at scox root]# First time it fails to assign the specified netmask apparently because it is attempting to do so _before_ assigning the address. Second time it succeeds as the interface already has an address. OTOH: [root at scox root]# ifconfig eth0:1 192.168.120.12 netmask 255.255.252.0 [root at scox root]# succeeds the first time since the actions are executed in the right order: SIOCSIFADDR _then_ SIOCSIFNETMASK. This patch against net-tools-1.60 defers the netmask ioctl when using implicit/CIDR notation till after the address has been assigned. IOW, it makes the 2 commands equivalent (as some of us might expect ;). -- Florin Malita diff -aur net-tools-1.60.orig/ifconfig.c net-tools-1.60.new/ifconfig.c --- net-tools-1.60.orig/ifconfig.c 2001-04-13 14:25:18.000000000 -0400 +++ net-tools-1.60.new/ifconfig.c 2004-08-31 17:07:38.362758712 -0400 @@ -23,6 +23,7 @@ * 20001008 - Bernd Eckenfels, Patch from RH for setting mtu * (default AF was wrong) * 20010404 - Arnaldo Carvalho de Melo, use setlocale + * 20040831 - Florin Malita delayed CIDR netmask */ #define DFLT_AF "inet" @@ -227,13 +228,13 @@ int main(int argc, char **argv) { - struct sockaddr sa; + struct sockaddr sa, sa_netmask; struct sockaddr_in sin; char host[128]; struct aftype *ap; struct hwtype *hw; struct ifreq ifr; - int goterr = 0, didnetmask = 0; + int goterr = 0, didnetmask = 0, donetmask = 0; char **spp; int fd; #if HAVE_AFINET6 @@ -903,16 +904,16 @@ /* FIXME: sa is too small for INET6 addresses, inet6 should use that too, broadcast is unexpected */ if (ap->getmask) { - switch (ap->getmask(host, &sa, NULL)) { + switch (ap->getmask(host, &sa_netmask, NULL)) { case -1: usage(); break; case 1: if (didnetmask) usage(); - - goterr = set_netmask(skfd, &ifr, &sa); - didnetmask++; + + /* delay setting the CIDR netmask till after setting the addr */ + donetmask = 1; break; } } @@ -960,6 +961,13 @@ } } + /* set CIDR netmask */ + if (donetmask){ + donetmask = 0; + goterr = set_netmask(skfd, &ifr, &sa_netmask); + didnetmask++; + } + /* * Don't do the set_flag() if the address is an alias with a - at the * end, since it's deleted already! - Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: ifconfig-netmask.patch Type: text/x-patch Size: 1775 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ed at eh3.com Wed Sep 1 17:18:14 2004 From: ed at eh3.com (Ed Hill) Date: Wed, 01 Sep 2004 13:18:14 -0400 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <20040831145350.GA5866@devserv.devel.redhat.com> References: <1093923084.13662.369.camel@localhost.localdomain> <1093936126.2797.3.camel@laptop.fenrus.com> <1093963334.13662.1045.camel@localhost.localdomain> <20040831145350.GA5866@devserv.devel.redhat.com> Message-ID: <1094059093.13662.1409.camel@localhost.localdomain> On Tue, 2004-08-31 at 10:53, Alan Cox wrote: > On Tue, Aug 31, 2004 at 10:42:14AM -0400, Ed Hill wrote: > > I guess it was just a coincidence that some of the kernels worked with > > mem=12G and others didn't. I've moved the machine to a new location and > > now *none* of the kernels I have (neither mine nor the Fedora ones) will > > boot with "mem=12G". The best I can get to work is "mem=3950M". > > If you don't specify mem= does it find all your RAM. ALso what chipset ? Hi folks, Since the K8D_Master-F MB would no longer POST, we swapped in a Tyan 2885 with the below HW. The good news is that we're not having any memory recognition problems. The bad news is that we now have an annoying but otherwise harmless boot situation which is: - the initial boot always fails very early in the boot process and causes a system reset - a warm reboot commences - this second attempt (and any further warm reboots) work just fine - any complete power-down will cause the first boot attempt to fail And I've seen this with both my own kernels (built from the FC2 SRPMS) and the following FC2 kernels: title Fedora Core (2.6.8-1.533.edhillsmp) root (hd0,0) kernel /boot/vmlinuz-2.6.8-1.533.edhillsmp ro root=LABEL=/ initrd /boot/initrd-2.6.8-1.533.edhillsmp.img title Fedora Core (2.6.7-1.515smp) root (hd0,0) kernel /boot/vmlinuz-2.6.7-1.515smp ro root=LABEL=/ initrd /boot/initrd-2.6.7-1.515smp.img title Fedora Core (2.6.6-1.435.2.3smp) root (hd0,0) kernel /boot/vmlinuz-2.6.6-1.435.2.3smp ro root=LABEL=/ initrd /boot/initrd-2.6.6-1.435.2.3smp.img Any ideas what may be causing these first boots to fail? Ed $ uname -a Linux XXX 2.6.8-1.533.edhillsmp #1 SMP Mon Aug 30 23:18:09 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux $ /sbin/lspci 00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05) 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03) 00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02) 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05) 00:07.5 Multimedia audio controller: Advanced Micro Devices [AMD] AMD-8111 AC97 Audio (rev 03) 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) 00:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 02:07.0 RAID bus controller: 3ware Inc 3ware ATA-RAID 02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02) 03:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) 03:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) 03:0b.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc) Silicon Image SiI 3114 SATARaid Controller (rev 02) 03:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) 04:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-8151 System Controller (rev 13) 04:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8151 AGP Bridge (rev 13) 05:00.0 VGA compatible controller: nVidia Corporation NV28GL [Quadro4 980 XGL] (rev a1) -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From smoogen at lanl.gov Wed Sep 1 18:28:39 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Wed, 01 Sep 2004 12:28:39 -0600 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <1094059093.13662.1409.camel@localhost.localdomain> References: <1093923084.13662.369.camel@localhost.localdomain> <1093936126.2797.3.camel@laptop.fenrus.com> <1093963334.13662.1045.camel@localhost.localdomain> <20040831145350.GA5866@devserv.devel.redhat.com> <1094059093.13662.1409.camel@localhost.localdomain> Message-ID: <413614D7.7050001@lanl.gov> Ed Hill wrote: > On Tue, 2004-08-31 at 10:53, Alan Cox wrote: > >>On Tue, Aug 31, 2004 at 10:42:14AM -0400, Ed Hill wrote: >> >>>I guess it was just a coincidence that some of the kernels worked with >>>mem=12G and others didn't. I've moved the machine to a new location and >>>now *none* of the kernels I have (neither mine nor the Fedora ones) will >>>boot with "mem=12G". The best I can get to work is "mem=3950M". >> >>If you don't specify mem= does it find all your RAM. ALso what chipset ? > > > > Hi folks, > > Since the K8D_Master-F MB would no longer POST, we swapped in a Tyan > 2885 with the below HW. The good news is that we're not having any > memory recognition problems. The bad news is that we now have an > annoying but otherwise harmless boot situation which is: > > - the initial boot always fails very early in the boot process > and causes a system reset > - a warm reboot commences > - this second attempt (and any further warm reboots) work just > fine > - any complete power-down will cause the first boot attempt > to fail > Sounds like crap hardware. I heard of something like that before.. it was 'fixed' with a 'BIOS' update.. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From bobgus at rcn.com Wed Sep 1 19:00:33 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 1 Sep 2004 14:00:33 -0500 Subject: One update too far - help In-Reply-To: <1094058798.4939.8.camel@scox.glenatl.glenayre.com> Message-ID: I managed to download and yum update this morning, however: When I boot: I see lots of mod_ins segment faults. Seems to be that the arguments to mod_ins are illformed. My network is not ifup after the boot. Moreover, when I do the little trick: /etc/sysconfig/network-scripts/ifup eth0 there is a complaint that eth0 does not exist. if I do /sbin/ifconfig I only see the lo device. ---- To get more updates, I need a network. What is the best way to proceed manually to bring up eth0 so I can contact the outside world. (My inside world too - cannot contact this machine either). System is i686 smp scsi ipv4 - smp538 kernel. BobG From bobgus at rcn.com Wed Sep 1 19:10:44 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 1 Sep 2004 14:10:44 -0500 Subject: One update too far - help 2 Message-ID: That was modprobe that Segv'ed, not mod_ins BobG >I managed to download and yum update this morning, however: > >When I boot: > I see lots of mod_ins segment faults. Seems to be that the arguments to >mod_ins are illformed. > >My network is not ifup after the boot. Moreover, when I do the little trick: > >/etc/sysconfig/network-scripts/ifup eth0 > >there is a complaint that eth0 does not exist. > >if I do /sbin/ifconfig I only see the lo device. > >---- > >To get more updates, I need a network. > >What is the best way to proceed manually to bring up eth0 so I can contact >the outside world. (My inside world too - cannot contact this machine >either). > >System is i686 smp scsi ipv4 - smp538 kernel. > >BobG From notting at redhat.com Wed Sep 1 19:48:13 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Sep 2004 15:48:13 -0400 Subject: One update too far - help 2 In-Reply-To: References: Message-ID: <20040901194813.GB5068@nostromo.devel.redhat.com> Bob Gustafson (bobgus at rcn.com) said: > That was modprobe that Segv'ed, not mod_ins Fixed in 3.1-0.pre5.2. Bill From jeff at ollie.clive.ia.us Wed Sep 1 19:51:34 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Wed, 01 Sep 2004 14:51:34 -0500 Subject: One update too far - help In-Reply-To: References: Message-ID: <1094068294.3445.5.camel@pc05987.campus.dmacc.edu> On Wed, 2004-09-01 at 14:00 -0500, Bob Gustafson wrote: > I managed to download and yum update this morning, however: > > [...] > > What is the best way to proceed manually to bring up eth0 so I can contact > the outside world. (My inside world too - cannot contact this machine > either). Look in "/var/cache/yum/development/packages/". If you are lucky you should find an older version of module-init-tools that you can downgrade to. Once you've downgraded module-init-tools you should be able to reboot and get your networking back. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jeff at ollie.clive.ia.us Wed Sep 1 19:54:48 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Wed, 01 Sep 2004 14:54:48 -0500 Subject: One update too far - help 2 In-Reply-To: <20040901194813.GB5068@nostromo.devel.redhat.com> References: <20040901194813.GB5068@nostromo.devel.redhat.com> Message-ID: <1094068488.3445.8.camel@pc05987.campus.dmacc.edu> On Wed, 2004-09-01 at 15:48 -0400, Bill Nottingham wrote: > Bob Gustafson (bobgus at rcn.com) said: > > That was modprobe that Segv'ed, not mod_ins > > Fixed in 3.1-0.pre5.2. Yes, but without a network, it'll be darn hard to upgrade to 3.1-0.pre5.2. What I did was to look in "/var/cache/yum/development/packages/" and found an older version of module-init-tools that I could downgrade to. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed Sep 1 19:59:30 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Sep 2004 15:59:30 -0400 Subject: One update too far - help 2 In-Reply-To: <1094068488.3445.8.camel@pc05987.campus.dmacc.edu> References: <20040901194813.GB5068@nostromo.devel.redhat.com> <1094068488.3445.8.camel@pc05987.campus.dmacc.edu> Message-ID: <20040901195930.GC5068@nostromo.devel.redhat.com> Jeffrey C. Ollie (jeff at ollie.clive.ia.us) said: > Yes, but without a network, it'll be darn hard to upgrade to > 3.1-0.pre5.2. What I did was to look in > "/var/cache/yum/development/packages/" and found an older version of > module-init-tools that I could downgrade to. Moving modprobe.conf.dist out of the way will work, modulo breaking some other (less critical) things. Bill From michael at insitesinc.com Wed Sep 1 20:06:23 2004 From: michael at insitesinc.com (Michael Favia) Date: Wed, 01 Sep 2004 15:06:23 -0500 Subject: One update too far - help 2 In-Reply-To: <1094068488.3445.8.camel@pc05987.campus.dmacc.edu> References: <20040901194813.GB5068@nostromo.devel.redhat.com> <1094068488.3445.8.camel@pc05987.campus.dmacc.edu> Message-ID: <41362BBF.4030205@insitesinc.com> Jeffrey C. Ollie wrote: >Yes, but without a network, it'll be darn hard to upgrade to >3.1-0.pre5.2. > I figured if you can ask on this list you can get to the network well enough to transfer what need be transfered. -- Michael Favia michael at insitesinc dot com Insites Incorporated http://michael.insitesinc.com From dima at snaiper.no-ip.com Wed Sep 1 21:24:57 2004 From: dima at snaiper.no-ip.com (dima) Date: Wed, 01 Sep 2004 23:24:57 +0200 Subject: Why fedora have not splitted packages? Message-ID: Why fedora have not splitted packages? For example in Debian some packages, such as kde-games, kde-network and etc are splitted into small packages. It`s very good idea. End-user may select only needed packages or install virtual global package. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at silug.org Wed Sep 1 20:24:39 2004 From: steve at silug.org (Steven Pritchard) Date: Wed, 1 Sep 2004 15:24:39 -0500 Subject: postfix bug? kernel bug? Message-ID: <20040901202439.GA20260@osiris.silug.org> Sorry for reposting this (I sent it to fedora-list earlier), but I'm running out of ideas... I'm having a weird problem... I'm trying to set up a mail server for a client. It's a dual Opteron box with 4GB RAM running FC2/x86_64. I'm setting it up with amavisd-new, which requires setting up postfix to listen on a port (so postfix relays to amavisd which relays to postfix). The initial connection to postfix (port 25) is fine. The mail is processed by amavisd fine. When amavisd tries to connect to postfix again, I get this: ==> /var/log/messages <== Aug 31 23:33:20 foo kernel: smtpd[1665]: segfault at 00000030bf300e20 rip 00000030bf206294 rsp 0000007fbfffd8b0 error 7 ==> /var/log/maillog <== Aug 31 23:33:20 foo postfix/master[1394]: warning: process /usr/libexec/postfix/smtpd pid 1665 killed by signal 11 Aug 31 23:33:20 foo postfix/master[1394]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling I've tried upgrading and downgrading the kernel to every FC2 errata kernel-smp, plus I've tried kernel-smp-2.6.8-1.533 from rawhide. I've also tried upgrading postfix to 2.1.4-1 from rawhide. Nothing seems to change the behavior. It's entirely possible that I've screwed something up somewhere that explains all this, but I'm inclined to think not... I've basically cloned a working config from another (i386) box. Any ideas would be very welcome... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From rdieter at math.unl.edu Wed Sep 1 20:30:02 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 1 Sep 2004 15:30:02 -0500 (CDT) Subject: Why fedora have not splitted packages? In-Reply-To: References: Message-ID: On Wed, 1 Sep 2004, dima wrote: > Why fedora have not splitted packages? For example in Debian some packages, > such as kde-games, kde-network and etc are splitted into small packages. > It`s very good idea. End-user may select only needed packages or install > virtual global package. Because it's a whole lot of work for relatively little gain (disk space mainly) IMO, In general, if upstream developers package their software/tarballs (e.g. kdegames, kdenetwork) monolitically, so should the rpm packaging. -- Rex From jeff at ollie.clive.ia.us Wed Sep 1 20:34:27 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Wed, 01 Sep 2004 15:34:27 -0500 Subject: One update too far - help 2 In-Reply-To: <41362BBF.4030205@insitesinc.com> References: <20040901194813.GB5068@nostromo.devel.redhat.com> <1094068488.3445.8.camel@pc05987.campus.dmacc.edu> <41362BBF.4030205@insitesinc.com> Message-ID: <1094070867.3445.14.camel@pc05987.campus.dmacc.edu> On Wed, 2004-09-01 at 15:06 -0500, Michael Favia wrote: > Jeffrey C. Ollie wrote: > > >Yes, but without a network, it'll be darn hard to upgrade to > >3.1-0.pre5.2. > > > I figured if you can ask on this list you can get to the network well > enough to transfer what need be transfered. Maybe, maybe not. My first attempt was to boot into the Windows XP partition and download an older RPM there. When I rebooted back into Linux I found that I couldn't mount the Windows (FAT32) partition because modprobe kept segfaulting. A *LOT* of functionality in the Fedora/Redhat kernels is in modules. I'm not even sure that you could mount a CDROM or a floppy. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pp at ee.oulu.fi Wed Sep 1 20:39:33 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Wed, 1 Sep 2004 23:39:33 +0300 Subject: One update too far - help 2 In-Reply-To: <1094070867.3445.14.camel@pc05987.campus.dmacc.edu> References: <20040901194813.GB5068@nostromo.devel.redhat.com> <1094068488.3445.8.camel@pc05987.campus.dmacc.edu> <41362BBF.4030205@insitesinc.com> <1094070867.3445.14.camel@pc05987.campus.dmacc.edu> Message-ID: <20040901203933.GA7338@ee.oulu.fi> On Wed, Sep 01, 2004 at 03:34:27PM -0500, Jeffrey C. Ollie wrote: > Maybe, maybe not. My first attempt was to boot into the Windows XP > partition and download an older RPM there. When I rebooted back into > Linux I found that I couldn't mount the Windows (FAT32) partition > because modprobe kept segfaulting. A *LOT* of functionality in the > Fedora/Redhat kernels is in modules. I'm not even sure that you could > mount a CDROM or a floppy. insmod still should work btw., just use that :-) -- Pekka Pietikainen From kaboom at gatech.edu Wed Sep 1 20:43:54 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 1 Sep 2004 16:43:54 -0400 (EDT) Subject: postfix bug? kernel bug? In-Reply-To: <20040901202439.GA20260@osiris.silug.org> References: <20040901202439.GA20260@osiris.silug.org> Message-ID: On Wed, 1 Sep 2004, Steven Pritchard wrote: > I'm setting it up with amavisd-new, which requires setting up postfix > to listen on a port (so postfix relays to amavisd which relays to > postfix). The initial connection to postfix (port 25) is fine. The > mail is processed by amavisd fine. When amavisd tries to connect to > postfix again, I get this: > > ==> /var/log/messages <== > Aug 31 23:33:20 foo kernel: smtpd[1665]: segfault at 00000030bf300e20 rip 00000030bf206294 rsp 0000007fbfffd8b0 error 7 > > ==> /var/log/maillog <== > Aug 31 23:33:20 foo postfix/master[1394]: warning: process /usr/libexec/postfix/smtpd pid 1665 killed by signal 11 > Aug 31 23:33:20 foo postfix/master[1394]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling Does this happen every time, or sporadically? Back out the IPv6 and TLS / AUTH patches and see if you can reproduce it. If you can, follow the steps in /usr/share/doc/postfix-mumble/README-FILES/DEBUG_README (Wietse won't support either patch until he merges them for 2.2, so don't waste his time sending in reports produced with them applied) I've been having the same sorts of sporadic stability issues when I apply the IPv6 patch on recentish RHEL / Fedora boxes with Postfix 2.1.x. later, chris From skvidal at phy.duke.edu Wed Sep 1 20:51:41 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Sep 2004 16:51:41 -0400 Subject: Why aren't aspell-XX packages noarch? In-Reply-To: <20040901131445.63e26551@localhost> References: <20040901131445.63e26551@localhost> Message-ID: <1094071901.20288.29.camel@opus.phy.duke.edu> > Which raises another point : I really hope Seth implements a kind of > "ExactArchPkgs=kernel kernel-smp glibc" configuration quickly to yum "TNG" > :-) > So, a good question came up today on discussion about this option. How do we add new items to this list. let's say in the middle of fc3 an updated packages come out and .i386 and .i686 packages are made. for some misc reason - I'm sure we can all make one up. and that package is not listed in ExactArchPackages So it migrates up to .i686 now, what if that is NOT the desired behavior? How do we update that config field for that contingency? We're still talking about manual intervention, either way. I'm just trying to sort out a situation where I'm not fixing one problem and making another one. Thanks! -sv From shockwave at clan-tf20.com Wed Sep 1 21:36:24 2004 From: shockwave at clan-tf20.com (Shockwave) Date: Wed, 01 Sep 2004 17:36:24 -0400 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <4135FF9C.9000703@lanl.gov> References: <1093964289.20756.101.camel@aries> <20040831150306.GY11465@devserv.devel.redhat.com> <1093974587.20756.139.camel@aries> <4134C176.8050301@lanl.gov> <1094055385.20756.252.camel@aries> <4135FF9C.9000703@lanl.gov> Message-ID: <1094074583.20756.293.camel@aries> On Wed, 2004-09-01 at 12:58, Stephen J Smoogen wrote: > I would add the c++ and the ncurses from FC1 'just-in-case' to your > /usr/local/games/fc1glibc tree also. use the directions jakub gave in > the previous email using rpm2cpio. > > I am guessing that these will NOT fix the problem.. but it would be best > to get those out of the way right now. Nothing better to avoid a > glibc/kernel finger pointing match as quickly as possible. ;). > Done. Now all libraries in use are the ones in my special directory. Unfortunately, you were right. The problem remains. > I am heading towards that in my case. My view will be that the server > code is written expecting something that 2.4.xx gives FPU wise and > 2.6.xx gives differently. The code is closed sourced? If it isnt it > would be interesting to find out where it is goofy now.. because it > might affect other people doing scientific code who assume that their > code works on 2.4 it will work smae on 2.6 > I agree that this has implications in areas other than this game server code, but the game engine code is closed sourced. I could write Electronic Arts and ask them, however I don't expect they will care to listen. They never replied to any of my email when I wrote them asking for non-proprietary information to develop some anti-cheat code to help the gaming community so I don't expect them to care now when their proprietary code is involved. I can try, but I think I would need some fairly strong arguments and perhaps the backing of someone else who isn't the leader of a competitive gaming team. If it had an impact on homeland security...maybe they'd help...maybe. ;) > rpm -ivh --force > > Check grub.conf to make sure it didnt break anything. > Since the server is co-located in a downtown facility, I'm going to wait until tomorrow morning to mess with the kernel. If I do something that hoses the system, it will not only take down the game server but our TeamSpeak server as well. Considering we have a practice tonight, I don't think I should risk it. In the meantime, if anyone is interested in seeing what I am talking about with the F-16, here are some links to a few images: http://www.clan-tf20.com/uploads/ps/F-16_bug1.JPG http://www.clan-tf20.com/uploads/ps/F-16_bug2.JPG http://www.clan-tf20.com/uploads/ps/F-16_bug3.JPG When the plane spawns, the entire wheel is underground. If you jump in and hit the thrusters, it will level itself as you gain speed and start to act normally. However, as soon as you land and start to come to a halt, the strut under the right wing sinks down again. If you look closely, you'll see the strut isn't connected to the wheel on the right as it is on the left. It's as if the calculation that places the strut in the center of the wheel is wrong. By the way, I just want to take a moment to thank everyone who has taken the time to weigh in on this issue. I know it's not very important to anyone outside of our gaming community, but I've received some top-notch help regardless from some very cool people. The Fedora community is truly a wonderful group of individuals that don't get nearly the amount of praise they deserve. Thanks again! As soon as I install the kernel files tomorrow, I'll post my results. -- |TF20|Shockwave http://www.clan-tf20.com/ ICQ# 57671167 #taskforce20 irc.gamesurge.net From perbj at stanford.edu Wed Sep 1 21:46:55 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 01 Sep 2004 14:46:55 -0700 Subject: firefox and thunderbird for rawhide In-Reply-To: <4135AD3A.3030604@redhat.com> References: <41359AD5.60009@redhat.com> <1094033840.5030.0.camel@scrappy.netlyncs.com> <4135A328.1070407@redhat.com> <4135AC6B.1010708@feuerpokemon.de> <4135AD3A.3030604@redhat.com> Message-ID: <1094075215.4265.1.camel@localhost.localdomain> On Wed, 2004-09-01 at 04:06, Warren Togami wrote: > dragoran wrote: > > i don't know if this is abug or not but all system-config-* tools open > > mozilla when pressing help even if firefox is set in prefered applications > > Even in FC3 latest? If so, please file a bug against 'distribution' and > assign it to me. I will investigate next week. I don't have a Rawhide install handy here to check unfortunately, but the system-config-* tools are all run as root, right? Definitely in FC2 they follow root's preferred applications and not the current logged in console user's. (This means that they default to Mozilla, but by changing root's preferences I can e.g. get Firefox instead.) /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From toshio at tiki-lounge.com Wed Sep 1 22:20:40 2004 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 01 Sep 2004 18:20:40 -0400 Subject: i486 targetted glibc Message-ID: <1094077238.15726.7.camel@Madison.badger.com> What's the status of targetting i486 as a minimum for glibc as per http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00617.html I looked in the devel and test trees and saw i386 and i686 builds. Looking in the SRPM's spec seems to show NPTL would still be disabled for an i486 build even though the discussions on this list indicate NPTL should run on i486 and above (could be wrong about that, though.) Just curious because I'm rebuilding the FC2 glibc for my K6 so it'll run subversion and was reminded of how much of a pain it is. Don't want to repeat for FC3 if I don't have to. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Sep 1 22:23:55 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 2 Sep 2004 00:23:55 +0200 Subject: Better ExactArch in yum (was: Re: Why aren't aspell-XX packages noarch?) In-Reply-To: <1094071901.20288.29.camel@opus.phy.duke.edu> References: <20040901131445.63e26551@localhost> <1094071901.20288.29.camel@opus.phy.duke.edu> Message-ID: <20040902002355.31098308@localhost> seth vidal wrote : > > Which raises another point : I really hope Seth implements a kind of > > "ExactArchPkgs=kernel kernel-smp glibc" configuration quickly to yum > > "TNG":-) > > So, a good question came up today on discussion about this option. > > How do we add new items to this list. > > let's say in the middle of fc3 an updated packages come out and .i386 > and .i686 packages are made. > > for some misc reason - I'm sure we can all make one up. > > and that package is not listed in ExactArchPackages > > So it migrates up to .i686 > now, what if that is NOT the desired behavior? > > How do we update that config field for that contingency? > > We're still talking about manual intervention, either way. > > I'm just trying to sort out a situation where I'm not fixing one problem > and making another one. Well, if that's not the desired behavior, but doesn't render the system impossible to boot, it's not such a big deal IMHO, since in the vast majority of cases, having the "highest possible compatible arch" will be what is wanted, and in the case of "both i386 and i686 were available... we realized that the i686 specific version brought nothing more, so we only provide i386 from now on", we will also want to update from the older i686 to the newer i386, no? Not to mention the arch to noarch case because it makes more sense for the package (typically the aspell-XX dicts), or the other way around. The only reason the whole ExactArch thingy was brought in the first place was because repositories where the i686 glibc update wasn't included but the i386 one was badly broke clients updating from there (IIRC my server suffered from that, but because you had a mirror problem on at dulug from where I was syncing ;-)). Apart from glibc, I don't think there are other packages that can badly break a system (from the top of my head) if "downgraded" arch-wise, not even the kernel. And from my experience, ExactArch has been a blocker in quite a few situations, like the "filesystem" package which once was noarch and is now arch specific, or multimedia libs initially packaged as i386 _and_ i686 with the i686 build later dropped. Anyway, just my point of view : Having a short simple default for some kind of ExactArchPackages should suit the vast majority of users. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Red Hat Enterprise Linux AS release 3 (Taroon) - Linux kernel 2.6.8-1.521 Load : 0.14 0.20 0.14 From rhallyx at mindspring.com Wed Sep 1 22:31:36 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Wed, 01 Sep 2004 18:31:36 -0400 Subject: Yum traceback Message-ID: <41364DC8.4040600@mindspring.com> This happened at the end of todays update from rawhide: ________________________________________ Completing update for kudzu-devel - 579/579 Kernel Updated/Installed, checking for bootloader Traceback (most recent call last): File "/usr/bin/yum", line 30, in ? File "/usr/share/yum/yummain.py", line 375, in main File "/usr/share/yum/pkgaction.py", line 588, in kernelupdate ImportError: No module named checkbootloader [root at old1 ~]# _____________________________________________ Richard Hally From skvidal at phy.duke.edu Wed Sep 1 22:32:54 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Sep 2004 18:32:54 -0400 Subject: Yum traceback In-Reply-To: <41364DC8.4040600@mindspring.com> References: <41364DC8.4040600@mindspring.com> Message-ID: <1094077974.28699.5.camel@opus.phy.duke.edu> On Wed, 2004-09-01 at 18:31, Richard Hally wrote: > This happened at the end of todays update from rawhide: > ________________________________________ > > Completing update for kudzu-devel - 579/579 > Kernel Updated/Installed, checking for bootloader > Traceback (most recent call last): > File "/usr/bin/yum", line 30, in ? > > File "/usr/share/yum/yummain.py", line 375, in main > > File "/usr/share/yum/pkgaction.py", line 588, in kernelupdate > ImportError: No module named checkbootloader > [root at old1 ~]# > _____________________________________________ > Richard Hally Known. Should be fixed in cvs, now or 2.1.1 I'll probably be releasing lots of updates over the next week or so. :) -sv From perbj at stanford.edu Wed Sep 1 22:36:51 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 01 Sep 2004 15:36:51 -0700 Subject: firefox and thunderbird for rawhide In-Reply-To: <41359AD5.60009@redhat.com> References: <41359AD5.60009@redhat.com> Message-ID: <1094078211.2782.26.camel@localhost.localdomain> On Wed, 2004-09-01 at 02:48, Warren Togami wrote: > According to Havoc, firefox and thunderbird must be added for FC3/RHEL4 > target. I am now rushing to build them into rawhide. Your assistance > in testing and analysis would be greatly appreciated. Cool! Unfortunately I have no rawhide easily accessible at the moment but I did dump an FC2 rebuild of xorg-x11 6.7.99.903 (RC3 of 6.7.8) from Rawhide onto my FC2 install since it gives me nice 3D acceleration on my Radeon IGP, plus apparently clock scaling (although I haven't checked to see if it actually improves the notebook battery life). I had to muck around with the split-out of the Xprint libs into xorg-x11-deprecated-libs and discovered this: [perbj at minicooper perbj]$ rpm -ql xorg-x11-deprecated-libs /usr/X11R6/lib/libXp.so.6 /usr/X11R6/lib/libXp.so.6.2 [perbj at minicooper perbj]$ sudo rpm -e xorg-x11-deprecated-libs Password: error: Failed dependencies: libXp.so.6 is needed by (installed) openmotif-2.2.3-4.1 libXp.so.6 is needed by (installed) openmotif-devel-2.2.3-4.1 libXp.so.6 is needed by (installed) xpdf-3.00-3 libXp.so.6 is needed by (installed) xorg-x11-6.7.99.903-1 libXp.so.6 is needed by (installed) xorg-x11-tools-6.7.99.903-1 libXp.so.6 is needed by (installed) firefox-0.9.3-0.fdr.4 (I just did that to get a listing of what depends on libXp...) So it seems that firefox somehow picked up a direct dependency on Xprint which is considered deprecated by Red Hat. I'm not really sure how the dependency ended up there though, since Firefox doesn't seem to link directly to libXp: [perbj at minicooper perbj]$ ldd /usr/lib/firefox-0.9.3/firefox-bin | grep Xp [perbj at minicooper perbj]$ What's going on here? Anyone have a clue, or is it worth digging into? Since Red Hat people have clearly indicated that Xprint is considered deprecated it seems somewhat useful to try to avoid dependencies on it, especially in stuff added to the distro now... As you can see from the listing above, Mozilla doesn't have this dep (the Fedora build doesn't support Xprint) so it seems pretty strange that it should be a hard requirement for Firefox, although I haven't really checked yet. Cheers, Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From rhally at mindspring.com Wed Sep 1 22:58:55 2004 From: rhally at mindspring.com (Richard Hally) Date: Wed, 01 Sep 2004 18:58:55 -0400 Subject: Yum traceback In-Reply-To: <1094077974.28699.5.camel@opus.phy.duke.edu> References: <41364DC8.4040600@mindspring.com> <1094077974.28699.5.camel@opus.phy.duke.edu> Message-ID: <4136542F.4000408@mindspring.com> seth vidal wrote: >On Wed, 2004-09-01 at 18:31, Richard Hally wrote: > > >>This happened at the end of todays update from rawhide: >>________________________________________ >> >>Completing update for kudzu-devel - 579/579 >>Kernel Updated/Installed, checking for bootloader >>Traceback (most recent call last): >> File "/usr/bin/yum", line 30, in ? >> >> File "/usr/share/yum/yummain.py", line 375, in main >> >> File "/usr/share/yum/pkgaction.py", line 588, in kernelupdate >>ImportError: No module named checkbootloader >>[root at old1 ~]# >>_____________________________________________ >>Richard Hally >> >> > >Known. Should be fixed in cvs, now or 2.1.1 > >I'll probably be releasing lots of updates over the next week or so. > >:) >-sv > > > Ok, great. Thanks for the improvements to yum, I'm looking forward to using the new version. From eric at brouhaha.com Wed Sep 1 23:41:41 2004 From: eric at brouhaha.com (Eric Smith) Date: Wed, 1 Sep 2004 16:41:41 -0700 (PDT) Subject: RPM debuginfo problems Message-ID: <34574.4.20.168.123.1094082101.squirrel@4.20.168.123> When I try to rebuild Fedora RPMs, I routinely complaints like: error: Could not open %files file /home/esmith/rpmbuild/BUILD/kernel-utils-2.4/debugfiles.list: No such file or directory Google shows that many other people encounter this as well. The conventional wisdom seems to be that the solution is to edit the spec file to add: %define debug_package %{nil} Or (better) add to ~/.rpmmacros: %debug_package %{nil} While this does allow the RPM to be built, it is not a particularly satisfying solution. It seems unlikely that these SRPMS are being distributed in a broken state, so surely there must be some intent that they build correctly WITH a debug package as output. The Fedora download server does offer debuginfo RPMs for all of the packages for which I've seen this problem, so obviously it can be done. So my question is, how is this SUPPOSED to work? Why doesn't building these packages work correctly "out-of-the-box", and what is required to get it to do so? Thanks, Eric Smith From bobgus at rcn.com Wed Sep 1 23:54:07 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Wed, 1 Sep 2004 18:54:07 -0500 Subject: One update too far - help 2 In-Reply-To: <20040901203933.GA7338@ee.oulu.fi> References: <1094070867.3445.14.camel@pc05987.campus.dmacc.edu> <20040901194813.GB5068@nostromo.devel.redhat.com> <1094068488.3445.8.camel@pc05987.campus.dmacc.edu> <41362BBF.4030205@insitesinc.com> <1094070867.3445.14.camel@pc05987.campus.dmacc.edu> Message-ID: >On Wed, Sep 01, 2004 at 03:34:27PM -0500, Jeffrey C. Ollie wrote: >> Maybe, maybe not. My first attempt was to boot into the Windows XP >> partition and download an older RPM there. When I rebooted back into >> Linux I found that I couldn't mount the Windows (FAT32) partition >> because modprobe kept segfaulting. A *LOT* of functionality in the >> Fedora/Redhat kernels is in modules. I'm not even sure that you could >> mount a CDROM or a floppy. >insmod still should work btw., just use that :-) > >-- >Pekka Pietikainen Thanks for all your hints. I haven't had the time to get back to it - probably tonight before bedtime.. If I use insmod, what arguments are appropriate? I can move modprobe.conf out of the way, but don't know if I can get anything longer than 10 minutes of keystrokes into the box. I have a few computers here, but only one CDROM burner (on the afflicted). Maybe floppys.. Until later - thanks much. BobG From mark at talios.com Thu Sep 2 00:11:39 2004 From: mark at talios.com (Mark Derricutt) Date: Thu, 02 Sep 2004 12:11:39 +1200 Subject: yum 2.1.0 In-Reply-To: <4135FCEF.6070003@lanl.gov> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> Message-ID: <4136653B.7000807@talios.com> Stephen J Smoogen wrote: > > ..... From naoki at valuecommerce.com Thu Sep 2 00:32:01 2004 From: naoki at valuecommerce.com (Naoki) Date: Thu, 02 Sep 2004 09:32:01 +0900 Subject: yum error on Kernel install Message-ID: <41366A01.9040601@valuecommerce.com> Kernel Updated/Installed, checking for bootloader Traceback (most recent call last): File "/usr/bin/yum", line 30, in ? File "/usr/share/yum/yummain.py", line 375, in main File "/usr/share/yum/pkgaction.py", line 588, in kernelupdate ImportError: No module named checkbootloader Any ideas? From strepsil at gmail.com Thu Sep 2 03:05:44 2004 From: strepsil at gmail.com (Mike Barnes) Date: Thu, 2 Sep 2004 13:05:44 +1000 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <4135F625.8060904@redhat.com> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <1094030580.25156.32326.camel@mccallum.corsepiu.local> <4135F625.8060904@redhat.com> Message-ID: <6879f22b040901200520930d4a@mail.gmail.com> On Wed, 01 Sep 2004 09:17:41 -0700, Ulrich Drepper wrote: > > 3. It would almost double the size of i386.rpms (These sse2 libs would > > have to be part of i386.rpms) - Is it worth it? > > The size of the actual DSOs is not the only factor in the RPM size. > This means that two RPMs are bigger then one RPM with two DSO versions. Just playing Devil's Advocate here, but if the extra optimised libraries are in a separate directory, wouldn't it be trivial to define a subpackage for them? Say we have libinfinite, which is a special library for executing infinite loops. There's an option to have an SSE2 optimised version of the library, which executes them even faster. libinfinite-0.1-1.i386.rpm contains /usr/lib/libinfinite.so.0 (and other common docs, utils, etc) A subpackage, libinfinite-sse2-0.1-1.i386.rpm, contains /usr/lib/sse2/libinfinite.so.0 (just the optimised version, depends on libinfinite) No doubling up, installable easily at any time, and removable by users who need the disk space (without breaking anything). From rhally at mindspring.com Thu Sep 2 03:12:10 2004 From: rhally at mindspring.com (Richard Hally) Date: Wed, 01 Sep 2004 23:12:10 -0400 Subject: yum error on Kernel install In-Reply-To: <41366A01.9040601@valuecommerce.com> References: <41366A01.9040601@valuecommerce.com> Message-ID: <41368F8A.8030504@mindspring.com> Naoki wrote: > Kernel Updated/Installed, checking for bootloader > Traceback (most recent call last): > File "/usr/bin/yum", line 30, in ? > > File "/usr/share/yum/yummain.py", line 375, in main > > File "/usr/share/yum/pkgaction.py", line 588, in kernelupdate > ImportError: No module named checkbootloader > > > Any ideas? > > On Wed, 2004-09-01 at 18:31, Richard Hally wrote: >> This happened at the end of todays update from rawhide: >> ________________________________________ >> >> Completing update for kudzu-devel - 579/579 >> Kernel Updated/Installed, checking for bootloader >> Traceback (most recent call last): >> File "/usr/bin/yum", line 30, in ? >> >> File "/usr/share/yum/yummain.py", line 375, in main >> >> File "/usr/share/yum/pkgaction.py", line 588, in kernelupdate >> ImportError: No module named checkbootloader >> [root at old1 ~]# >> _____________________________________________ >> Richard Hally > > Known. Should be fixed in cvs, now or 2.1.1 I'll probably be releasing lots of updates over the next week or so. :) -sv From feliciano.matias at free.fr Thu Sep 2 03:13:10 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 02 Sep 2004 05:13:10 +0200 Subject: firefox and thunderbird for rawhide In-Reply-To: <1094078211.2782.26.camel@localhost.localdomain> References: <41359AD5.60009@redhat.com> <1094078211.2782.26.camel@localhost.localdomain> Message-ID: <1094094787.20649.47.camel@one.myworld> Le jeu 02/09/2004 ? 00:36, Per Bjornsson a ?crit : > On Wed, 2004-09-01 at 02:48, Warren Togami wrote: > > According to Havoc, firefox and thunderbird must be added for FC3/RHEL4 > > target. I am now rushing to build them into rawhide. Your assistance > > in testing and analysis would be greatly appreciated. > > Cool! Unfortunately I have no rawhide easily accessible at the moment > but I did dump an FC2 rebuild of xorg-x11 6.7.99.903 (RC3 of 6.7.8) from > Rawhide onto my FC2 install since it gives me nice 3D acceleration on my > Radeon IGP, plus apparently clock scaling (although I haven't checked to > see if it actually improves the notebook battery life). I had to muck > around with the split-out of the Xprint libs into > xorg-x11-deprecated-libs and discovered this: > > [perbj at minicooper perbj]$ rpm -ql xorg-x11-deprecated-libs > /usr/X11R6/lib/libXp.so.6 > /usr/X11R6/lib/libXp.so.6.2 > [perbj at minicooper perbj]$ sudo rpm -e xorg-x11-deprecated-libs > Password: > error: Failed dependencies: > libXp.so.6 is needed by (installed) openmotif-2.2.3-4.1 > libXp.so.6 is needed by (installed) openmotif-devel-2.2.3-4.1 > libXp.so.6 is needed by (installed) xpdf-3.00-3 > libXp.so.6 is needed by (installed) xorg-x11-6.7.99.903-1 > libXp.so.6 is needed by (installed) xorg-x11-tools-6.7.99.903-1 > libXp.so.6 is needed by (installed) firefox-0.9.3-0.fdr.4 > Nedit and ddd also. > (I just did that to get a listing of what depends on libXp...) So it > seems that firefox somehow picked up a direct dependency on Xprint which > is considered deprecated by Red Hat. I'm not really sure how the > dependency ended up there though, since Firefox doesn't seem to link > directly to libXp: > > [perbj at minicooper perbj]$ ldd /usr/lib/firefox-0.9.3/firefox-bin | grep Xp > [perbj at minicooper perbj]$ $ cd /usr/lib/firefox-0.9.3/components $ ldd libgfx_gtk.so libgfxxprint.so | grep Xp libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x00be2000) libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x00d06000) > > What's going on here? Anyone have a clue, or is it worth digging into? > Since Red Hat people have clearly indicated that Xprint is considered > deprecated it seems somewhat useful to try to avoid dependencies on it, > especially in stuff added to the distro now... As you can see from the > listing above, Mozilla doesn't have this dep (the Fedora build doesn't > support Xprint) so it seems pretty strange that it should be a hard > requirement for Firefox, although I haven't really checked yet. > > Cheers, > Per > > -- > Per Bjornsson > Ph.D. Candidate, Department of Applied Physics, Stanford University > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From loony at loonybin.org Wed Sep 1 22:38:16 2004 From: loony at loonybin.org (Peter Arremann) Date: Wed, 1 Sep 2004 18:38:16 -0400 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <413614D7.7050001@lanl.gov> References: <1093923084.13662.369.camel@localhost.localdomain> <1094059093.13662.1409.camel@localhost.localdomain> <413614D7.7050001@lanl.gov> Message-ID: <200409011838.16620.loony@loonybin.org> On Wednesday 01 September 2004 14:28, Stephen J Smoogen wrote: > > Since the K8D_Master-F MB would no longer POST, we swapped in a Tyan > > 2885 with the below HW. The good news is that we're not having any > > memory recognition problems. The bad news is that we now have an > > annoying but otherwise harmless boot situation which is: > > Sounds like crap hardware. I heard of something like that before.. it > was 'fixed' with a 'BIOS' update.. A friend of mine is running 2 systems with that board without issues. So its either a outdated/buggy bios as previously suggested or you got yet another bad board in front of you... Either way, does it do anything different if you turn off ACPI on bootup? Peter. -- http://www.dealrover.com From rc040203 at freenet.de Thu Sep 2 04:17:36 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 02 Sep 2004 06:17:36 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <6879f22b040901200520930d4a@mail.gmail.com> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <1094030580.25156.32326.camel@mccallum.corsepiu.local> <4135F625.8060904@redhat.com> <6879f22b040901200520930d4a@mail.gmail.com> Message-ID: <1094098656.20622.879.camel@mccallum.corsepiu.local> On Thu, 2004-09-02 at 05:05, Mike Barnes wrote: > On Wed, 01 Sep 2004 09:17:41 -0700, Ulrich Drepper wrote: > > > 3. It would almost double the size of i386.rpms (These sse2 libs would > > > have to be part of i386.rpms) - Is it worth it? > > > > The size of the actual DSOs is not the only factor in the RPM size. > > This means that two RPMs are bigger then one RPM with two DSO versions. > > Just playing Devil's Advocate here, but if the extra optimised > libraries are in a separate directory, wouldn't it be trivial to > define a subpackage for them? > Say we have libinfinite, which is a special library for executing > infinite loops. There's an option to have an SSE2 optimised version of > the library, which executes them even faster. > > libinfinite-0.1-1.i386.rpm contains > /usr/lib/libinfinite.so.0 > (and other common docs, utils, etc) > > A subpackage, libinfinite-sse2-0.1-1.i386.rpm, contains > /usr/lib/sse2/libinfinite.so.0 > (just the optimised version, depends on libinfinite) There is one major drawback of this approach: The libinfinite-sse2*.rpm would not get automatically installed by apt/yum etc. If /usr/lib/sse2/*.so.* were part of i386-rpms, they would get automatically installed on all ix86 systems and the dynamical linker would have to decide on which library to use at run-time. Ralf From drepper at redhat.com Thu Sep 2 04:45:09 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 01 Sep 2004 21:45:09 -0700 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <1094098656.20622.879.camel@mccallum.corsepiu.local> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <1094030580.25156.32326.camel@mccallum.corsepiu.local> <4135F625.8060904@redhat.com> <6879f22b040901200520930d4a@mail.gmail.com> <1094098656.20622.879.camel@mccallum.corsepiu.local> Message-ID: <4136A555.6060203@redhat.com> Ralf Corsepius wrote: > If /usr/lib/sse2/*.so.* were part of i386-rpms, they would get > automatically installed on all ix86 systems and the dynamical linker > would have to decide on which library to use at run-time. ldconfig normally makes the decisions, but yes. Using sub-packages would mean the installer has to know which of the subpackages to use and install them without the user requesting it since otherwise it would never happen, which user has enough knowledge to explicitly request this. And then there are the people who change motherboards or simply move the disks from one machine to another. For them the selection might be wrong. It's best to use multiple DSOs in one RPM. Exceptions are huge packages like glibc. If there ever should be i686/P4 variants for the gnome/kde libs the'd probably also fall into the "huge package" category. But we are here talking about packages like gmp or video/autdio encoders etc. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From pekkas at netcore.fi Thu Sep 2 05:32:33 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 2 Sep 2004 08:32:33 +0300 (EEST) Subject: [PATCH] net-tools 1.60: deferred ifconfig netmask In-Reply-To: <1094058798.4939.8.camel@scox.glenatl.glenayre.com> Message-ID: On Wed, 1 Sep 2004, Malita, Florin wrote: > OTOH: > [root at scox root]# ifconfig eth0:1 192.168.120.12 netmask > 255.255.252.0 > [root at scox root]# > > succeeds the first time since the actions are executed in the right > order: SIOCSIFADDR _then_ SIOCSIFNETMASK. > > This patch against net-tools-1.60 defers the netmask ioctl when using > implicit/CIDR notation till after the address has been assigned. IOW, it > makes the 2 commands equivalent (as some of us might expect ;). Shouldn't we rather be removing ifconfig or making it ready-only instead, as /sbin/ip seems to be vastly superior ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rc040203 at freenet.de Thu Sep 2 05:45:43 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 02 Sep 2004 07:45:43 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <4135F625.8060904@redhat.com> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <1094030580.25156.32326.camel@mccallum.corsepiu.local> <4135F625.8060904@redhat.com> Message-ID: <1094103943.20622.1115.camel@mccallum.corsepiu.local> On Wed, 2004-09-01 at 18:17, Ulrich Drepper wrote: > Ralf Corsepius wrote: > > >>But there .i686.rpm doesn't help you, > > > > Can you explain? > > > > My actual concern is less the technical side, but the "policy side" of > > shipping "optimized packages" and its impact on "packaging"/"upgrading". > > .i686 are not "optimized packages" if you cannot prove they are real > improvements. Until then they are just doubling the QA efforts without > any benefits. Exactly, that's my point and intention (cf. below). > > Packing-wise, this has several disadvantages. > > 1. You'd have to compile library packages twice. > > And for a separate .i686 this isn't the case? There is a subtile difference: * twice within the same rpm.spec vs. * building a package twice. The former is more complicated and error-prone than the latter, e.g. in the latter case you can pickup RPM_OPT_FLAGS and apply rpm's standard %_*dir macros, in the former case you'd have to setup most *FLAGS and dirs manually. > > 2. Many packages contain both libraries and applications, so you'd have > > to apply special measures to assure that applications still get > > -march=i386 compiled. > > Most of the time this is no problem. The application side is small, the > majority of the code is in the DSOs. This isn't necessarily true for normal packages. For normal packages, you'd have to configure/make/install the package twice, using different --libdirs and CFLAGS, etc. etc. and to sort out those files which have been built and installed twice. > > 3. It would almost double the size of i386.rpms (These sse2 libs would > > have to be part of i386.rpms) - Is it worth it? > > The size of the actual DSOs is not the only factor in the RPM size. > This means that two RPMs are bigger then one RPM with two DSO versions. Right, nevertheless it doubles the size of the rpms and doubles the size of required disk-space. Instead of having to install one DSO, you'd have to install two. It's the classical multilib dilemma known from embedded toolchains: Packaging simplicity and flexibility vs. space and bandwidth. > > However, I agree, it's a nice work-around suitable for libraries where > > special optimizations can be proven to have a "significant/noticeable" > > impact. > > This is no work-around, this is the preferred solution. Uhh? I considered Jacub's remark to be a proposal and recommendation, and not to be a dictate. > And once again: provide us some data about packages where special DSOs > or even i686 versions are of benefit. Sorry, you are barking up the wrong tree - I fully agree with you that shipping and building "optimized packages" in most cases probably does not result into performance gains. The cause for me starting this thread is people already doing so in FE and me questioning their procedures. I did ask and received this in return: https://bugzilla.fedora.us/show_bug.cgi?id=2033#c8 The developers for scribus and inkscape believe that 686 optimization is a plus for their apps (requested 686 packages for their sites), due largely to mmx. The inkscape package disables mmx if built for 386, enables for 686. ... https://bugzilla.fedora.us/show_bug.cgi?id=2033#c9 ... One of the Scribus devels has did quite a bit of optimization during the 1.1.x series, specifically some of these are helped by i686. This resulted in 50% speed ups in user visible functions like screen redraws. e.g 5 seconds, instead of 10 seconds to view a complex page. ... Does this qualify as "proof of gain in performance"? I really don't know. I.e. I am asking for FE's packaging policy to be changed to not shipping "optimized packages" unless compelling facts about the influence of "optimization" on a particular package can be provided and reproduced. Ralf From bobgus at rcn.com Thu Sep 2 05:53:09 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Thu, 2 Sep 2004 00:53:09 -0500 Subject: One update too far - help - OK fixed In-Reply-To: <20040901203933.GA7338@ee.oulu.fi> References: <1094070867.3445.14.camel@pc05987.campus.dmacc.edu> <20040901194813.GB5068@nostromo.devel.redhat.com> <1094068488.3445.8.camel@pc05987.campus.dmacc.edu> <41362BBF.4030205@insitesinc.com> <1094070867.3445.14.camel@pc05987.campus.dmacc.edu> Message-ID: On Wed, 1 Sep 2004 23:39:33 +0300 Pekka Pietikainen wrote: >On Wed, Sep 01, 2004 at 03:34:27PM -0500, Jeffrey C. Ollie wrote: >> Maybe, maybe not. My first attempt was to boot into the Windows XP >> partition and download an older RPM there. When I rebooted back into >> Linux I found that I couldn't mount the Windows (FAT32) partition >> because modprobe kept segfaulting. A *LOT* of functionality in the >> Fedora/Redhat kernels is in modules. I'm not even sure that you could >> mount a CDROM or a floppy. >insmod still should work btw., just use that :-) > >-- >Pekka Pietikainen > I looked for an older version of mod tools, but only the last broken version was in the /var/cache/yum/development area. But, insmod did the trick. /sbin/insmod /lib/modules/2.6.8-1.538smp/kernel/drivers/net/e1000/e1000.ko and then, to bring up the network /sbin/ifconfig eth0 up It is up. I looked for the .2 version of mod tools on fedora.redhat.com and all I could find in rpm form was the .1 broken version. I think I will wait for tomorrow when the good stuff trickles into the download area. Thanks much BobG From tomo.vuckovic at nis.yu Thu Sep 2 06:31:49 2004 From: tomo.vuckovic at nis.yu (Tomo Vuckovic) Date: Thu, 02 Sep 2004 08:31:49 +0200 Subject: yum 2.1.0 In-Reply-To: <4135FCEF.6070003@lanl.gov> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> Message-ID: <4136BE55.80602@nis.yu> Where is yum-arch ? Regards, Tomo -------------- next part -------------- A non-text attachment was scrubbed... Name: tomo.vuckovic.vcf Type: text/x-vcard Size: 416 bytes Desc: not available URL: From fedora at wir-sind-cool.org Thu Sep 2 06:43:00 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 2 Sep 2004 08:43:00 +0200 Subject: RPM debuginfo problems In-Reply-To: <34574.4.20.168.123.1094082101.squirrel@4.20.168.123> References: <34574.4.20.168.123.1094082101.squirrel@4.20.168.123> Message-ID: <20040902084300.632cd7d6.fedora@wir-sind-cool.org> On Wed, 1 Sep 2004 16:41:41 -0700 (PDT), Eric Smith wrote: > When I try to rebuild Fedora RPMs, I routinely complaints like: > error: Could not open %files file > /home/esmith/rpmbuild/BUILD/kernel-utils-2.4/debugfiles.list: No such > file or directory > > Google shows that many other people encounter this as well. The > conventional wisdom seems to be that the solution is to edit the > spec file to add: > %define debug_package %{nil} > Or (better) add to ~/.rpmmacros: > %debug_package %{nil} > > While this does allow the RPM to be built, it is not a particularly > satisfying solution. It seems unlikely that these SRPMS are being > distributed in a broken state, so surely there must be some intent that > they build correctly WITH a debug package as output. The Fedora > download server does offer debuginfo RPMs for all of the packages for > which I've seen this problem, so obviously it can be done. > > So my question is, how is this SUPPOSED to work? Why doesn't building > these packages work correctly "out-of-the-box", and what is required to > get it to do so? Never heard about this problem before nor seen it myself. $ cat ~/.rpmrc include: /usr/lib/rpm/redhat/rpmrc $ rpm -q redhat-rpm-config redhat-rpm-config-8.0.28-1.1.1 What else does your ~/.rpmmacros contain? From hk at isphuset.no Wed Sep 1 15:35:02 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Wed, 01 Sep 2004 17:35:02 +0200 Subject: FC2 Problem possibly related to selinux Message-ID: <1094052902.5669.3.camel@linux.local> I did a fresh install of FC2 w/selinux enabled. I chose custom packages and removed all optionals. Then I removed sendmail and installed postfix. Then yum update. The interesting problem now is that I can no longer get a login prompt on the consoles. SSH works just fine, but the console is stuck at starting Postfix. Never seems to finish. Any ideas? -HK From hk at isphuset.no Wed Sep 1 15:38:15 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Wed, 01 Sep 2004 17:38:15 +0200 Subject: FC2 Problem possibly related to selinux In-Reply-To: <1094052902.5669.3.camel@linux.local> References: <1094052902.5669.3.camel@linux.local> Message-ID: <1094053095.5669.6.camel@linux.local> > The interesting problem now is that I can no longer > get a login prompt on the consoles. SSH works just > fine, but the console is stuck at starting Postfix. > Never seems to finish. Forgot to paste this: # ps ax -snip- 1562 ? S 0:00 /bin/sh /etc/rc3.d/S80postfix start 1565 ? R 1311:00 /usr/sbin/postalias /etc/postfix/aliases -snip- "audit2allow -l -i /var/log/messages" no longer gives me any more rules to apply. -HK From barryn at pobox.com Thu Sep 2 08:24:25 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 2 Sep 2004 01:24:25 -0700 Subject: yum 2.1.0 In-Reply-To: <4136BE55.80602@nis.yu> References: <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> <4136BE55.80602@nis.yu> Message-ID: <20040902082425.GA8799@ip68-4-98-123.oc.oc.cox.net> On Thu, Sep 02, 2004 at 08:31:49AM +0200, Tomo Vuckovic wrote: > Where is yum-arch ? I guess this isn't a direct answer to your question, but it may be better than nothing... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131415 -Barry K. Nathan From tomo.vuckovic at nis.yu Thu Sep 2 08:58:02 2004 From: tomo.vuckovic at nis.yu (Tomo Vuckovic) Date: Thu, 02 Sep 2004 10:58:02 +0200 Subject: yum 2.1.0 In-Reply-To: <20040902082425.GA8799@ip68-4-98-123.oc.oc.cox.net> References: <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> <4136BE55.80602@nis.yu> <20040902082425.GA8799@ip68-4-98-123.oc.oc.cox.net> Message-ID: <4136E09A.6060608@nis.yu> Barry K. Nathan wrote: >On Thu, Sep 02, 2004 at 08:31:49AM +0200, Tomo Vuckovic wrote: > > >>Where is yum-arch ? >> >> > >I guess this isn't a direct answer to your question, but it may be >better than nothing... >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131415 > >-Barry K. Nathan > > > > Thanks. Regards, Tomo -------------- next part -------------- A non-text attachment was scrubbed... Name: tomo.vuckovic.vcf Type: text/x-vcard Size: 416 bytes Desc: not available URL: From alan at redhat.com Thu Sep 2 09:34:52 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 2 Sep 2004 05:34:52 -0400 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <200409011838.16620.loony@loonybin.org> References: <1093923084.13662.369.camel@localhost.localdomain> <1094059093.13662.1409.camel@localhost.localdomain> <413614D7.7050001@lanl.gov> <200409011838.16620.loony@loonybin.org> Message-ID: <20040902093452.GA19117@devserv.devel.redhat.com> On Wed, Sep 01, 2004 at 06:38:16PM -0400, Peter Arremann wrote: > On Wednesday 01 September 2004 14:28, Stephen J Smoogen wrote: > > > Since the K8D_Master-F MB would no longer POST, we swapped in a Tyan > > > 2885 with the below HW. The good news is that we're not having any > > > memory recognition problems. The bad news is that we now have an > > > annoying but otherwise harmless boot situation which is: > > > > Sounds like crap hardware. I heard of something like that before.. it > > was 'fixed' with a 'BIOS' update.. > A friend of mine is running 2 systems with that board without issues. > So its either a outdated/buggy bios as previously suggested or you got yet > another bad board in front of you... Likewise my 2885 is rock solid out of the box with FC2 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Sep 2 10:01:21 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 2 Sep 2004 12:01:21 +0200 Subject: Segfault in update-desktop-database Message-ID: <20040902120121.5531f2f8@localhost> Hi, I'm not quite sure what the problem might be exactly, so I'm sending the backtrace I get from an update-desktop-database segfaut with the latest FC Devel before bugzilla'ing it. # gdb update-desktop-database [...] (gdb) set args /usr/share/applications (gdb) run Starting program: /usr/bin/update-desktop-database /usr/share/applications ** (process:16018): CRITICAL **: file eggdesktopentries.c: line 1044 (egg_desktop_entries_get_string): assertion `group != NULL' failed Program received signal SIGSEGV, Segmentation fault. 0x08049a55 in process_desktop_files ( desktop_dir=0xfef48c15 "/usr/share/applications", prefix=0x804d0b3 "", error=0x0) at update-desktop-database.c:121 121 for (i = 0; mime_types[i] != NULL; i++) (gdb) bt #0 0x08049a55 in process_desktop_files ( desktop_dir=0xfef48c15 "/usr/share/applications", prefix=0x804d0b3 "", error=0x0) at update-desktop-database.c:121 #1 0x08049e8b in main (argc=0, argv=0x0) at update-desktop-database.c:356 #2 0x00adea93 in __libc_start_main () from /lib/tls/libc.so.6 #3 0x08049841 in _start () (gdb) I think I've been seeing this segfault from %post scriplets for over a week already. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Red Hat Enterprise Linux AS release 3 (Taroon) - Linux kernel 2.6.8-1.521 Load : 0.34 0.55 0.52 From skvidal at phy.duke.edu Thu Sep 2 13:05:32 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Sep 2004 09:05:32 -0400 Subject: yum 2.1.0 In-Reply-To: <4136BE55.80602@nis.yu> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> <4136BE55.80602@nis.yu> Message-ID: <1094130332.11651.5.camel@binkley> On Thu, 2004-09-02 at 08:31 +0200, Tomo Vuckovic wrote: > Where is yum-arch ? > yum-arch will be returning to yum for people who want to use the new yum but have to maintain old repos. it's in the works now. -sv From florin.malita at glenayre.com Thu Sep 2 13:35:00 2004 From: florin.malita at glenayre.com (Malita, Florin) Date: Thu, 2 Sep 2004 09:35:00 -0400 Subject: [PATCH] net-tools 1.60: deferred ifconfig netmask Message-ID: <1094132100.4939.31.camel@scox.glenatl.glenayre.com> On Thu, 2004-09-02 at 01:32, Pekka Savola wrote: > Shouldn't we rather be removing ifconfig or making it ready-only > instead, as /sbin/ip seems to be vastly superior ? While I agree that ip is superior, I think lots of people still use ifconfig for basic network configuration. Removing it will confuse some users and break many scripts: grep ifconfig /etc/sysconfig/network-scripts/* Regards, -- Florin Malita From smoogen at lanl.gov Thu Sep 2 13:53:55 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Thu, 02 Sep 2004 07:53:55 -0600 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <1094074583.20756.293.camel@aries> References: <1093964289.20756.101.camel@aries> <20040831150306.GY11465@devserv.devel.redhat.com> <1093974587.20756.139.camel@aries> <4134C176.8050301@lanl.gov> <1094055385.20756.252.camel@aries> <4135FF9C.9000703@lanl.gov> <1094074583.20756.293.camel@aries> Message-ID: <413725F3.5040903@lanl.gov> Shockwave wrote: >>I am heading towards that in my case. My view will be that the server >>code is written expecting something that 2.4.xx gives FPU wise and >>2.6.xx gives differently. The code is closed sourced? If it isnt it >>would be interesting to find out where it is goofy now.. because it >>might affect other people doing scientific code who assume that their >>code works on 2.4 it will work smae on 2.6 >> > > > I agree that this has implications in areas other than this game server > code, but the game engine code is closed sourced. I could write > Electronic Arts and ask them, however I don't expect they will care to > listen. They never replied to any of my email when I wrote them asking > for non-proprietary information to develop some anti-cheat code to help > the gaming community so I don't expect them to care now when their > proprietary code is involved. I can try, but I think I would need some > fairly strong arguments and perhaps the backing of someone else who > isn't the leader of a competitive gaming team. If it had an impact on > homeland security...maybe they'd help...maybe. ;) I think that in that case, you will be wanting to maintain a FC1/ 2.4.xx box until EA decides that a 2.6.xx version is needed. I would drop them an email letting them know about it anyway. > In the meantime, if anyone is interested in seeing what I am talking > about with the F-16, here are some links to a few images: > > http://www.clan-tf20.com/uploads/ps/F-16_bug1.JPG > http://www.clan-tf20.com/uploads/ps/F-16_bug2.JPG > http://www.clan-tf20.com/uploads/ps/F-16_bug3.JPG > Looks like soft sand to me ;). The F-16 was never known to deal with anything but hard-top. = -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From hk at isphuset.no Thu Sep 2 14:06:00 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Thu, 02 Sep 2004 16:06:00 +0200 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <413725F3.5040903@lanl.gov> References: <1093964289.20756.101.camel@aries> <20040831150306.GY11465@devserv.devel.redhat.com> <1093974587.20756.139.camel@aries> <4134C176.8050301@lanl.gov> <1094055385.20756.252.camel@aries> <4135FF9C.9000703@lanl.gov> <1094074583.20756.293.camel@aries> <413725F3.5040903@lanl.gov> Message-ID: <1094133960.5691.15.camel@linux.local> > > In the meantime, if anyone is interested in seeing what I am talking > > about with the F-16, here are some links to a few images: > > > > http://www.clan-tf20.com/uploads/ps/F-16_bug1.JPG > > http://www.clan-tf20.com/uploads/ps/F-16_bug2.JPG > > http://www.clan-tf20.com/uploads/ps/F-16_bug3.JPG > > > > Looks like soft sand to me ;). The F-16 was never known to deal with > anything but hard-top. Looks more like a feature than a bug then, 2.6 offers a more realistic gaming experience =) -HK From shockwave at clan-tf20.com Thu Sep 2 15:53:07 2004 From: shockwave at clan-tf20.com (Shockwave) Date: Thu, 02 Sep 2004 11:53:07 -0400 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <413725F3.5040903@lanl.gov> References: <1093964289.20756.101.camel@aries> <20040831150306.GY11465@devserv.devel.redhat.com> <1093974587.20756.139.camel@aries> <4134C176.8050301@lanl.gov> <1094055385.20756.252.camel@aries> <4135FF9C.9000703@lanl.gov> <1094074583.20756.293.camel@aries> <413725F3.5040903@lanl.gov> Message-ID: <1094140386.20756.361.camel@aries> On Thu, 2004-09-02 at 09:53, Stephen J Smoogen wrote: > I think that in that case, you will be wanting to maintain a FC1/ 2.4.xx > box until EA decides that a 2.6.xx version is needed. I would drop them > an email letting them know about it anyway. > > I really hate the idea of reloading the box with FC1 although it would certainly fix this problem. I was really hoping that I could make the FC1 kernel work. Unfortunately, my attempt to force the install met with disaster. I installed it this morning, rebooted, then found out it wouldn't respond to my pings. I drove into the city and hooked up a monitor to it and noticed that it was running but the network didn't start. After I started the network manually, I noticed that the routing table was hosed. I then did a quick check of the system log and found that there were some serious problems during boot. I'm not sure I know enough about the kernel to go messing around with trying to make the 2.4.x one work on FC2 and I don't want to be any more of a burden than I already have been. I want to be sure I don't become someone who keeps sucking resources from the great people who post on this list. I feel bad enough for taking up so much of everyone's time as it is. One thing I think I'm going to do is research what it takes to mod the BattleField 1942 engine so I can hopefully take a peek at the code used to model the F-16. It might be a dead end, but it's worth a shot. The way I look at it is if the left rear wheel works, perhaps there is a way to "borrow" the code and modify it for use with the right rear wheel. There must be something about the right rear wheel that is causing this. With any luck, I'll find it. I've already taken the liberty of posting on the official BF1942 server administrator list and in the forums where the developers visit from time to time. So far I haven't heard a peep from anyone about this but I'm going to try to remain optimistic. In the meantime, I'm going to go hit some of those modding web sites. If anyone comes up with anything else I can try, I'm all for it. Thanks again for all the excellent help! You guys are the best! -- |TF20|Shockwave http://www.clan-tf20.com/ ICQ# 57671167 #taskforce20 irc.gamesurge.net From ed at eh3.com Thu Sep 2 15:58:30 2004 From: ed at eh3.com (Ed Hill) Date: Thu, 02 Sep 2004 11:58:30 -0400 Subject: Tyan 2885 w/ 3w-9xxx oopses [was: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels] In-Reply-To: <20040902093452.GA19117@devserv.devel.redhat.com> References: <1093923084.13662.369.camel@localhost.localdomain> <1094059093.13662.1409.camel@localhost.localdomain> <413614D7.7050001@lanl.gov> <200409011838.16620.loony@loonybin.org> <20040902093452.GA19117@devserv.devel.redhat.com> Message-ID: <1094140710.13662.1562.camel@localhost.localdomain> On Thu, 2004-09-02 at 05:34, Alan Cox wrote: > > Likewise my 2885 is rock solid out of the box with FC2 I wish we could say the same. Our new Tyan 2885 MB seems to be fine as long as we don't create a lot of writes to the 3ware 9xxx controller. When we do, the machine oopses within ~15--30min. The 3rd oops I was not able to find in /var/log/messages but it looked similar to the second. Can someone please suggest whats causing these oopses and how we might fix it? We're willing to try just about anything including new kernels, fresh installs, etc. And many thanks for all the help so far! Ed ===== 2 oopses writing to 3ware 9xxx RAID array ===== Sep 1 16:05:20 adams kernel: general protection fault: 0000 [1] SMP Sep 1 16:05:20 adams kernel: CPU 1 Sep 1 16:05:20 adams kernel: Modules linked in: sata_sil(U) libata(U) floppy(U) sg(U) nfsd(U) exportfs(U) md5(U) ipv6(U) parport_pc(U) lp(U) parport(U) autofs4(U) nfs(U) lockd(U) sunrpc(U) iptable_filter(U) ip_tables(U) tg3(U) ohci1394(U) ieee1394(U) dm_mod(U) ohci_hcd(U) button(U) battery(U) asus_acpi(U) ac(U) ext3(U) jbd(U) 3w_9xxx(U) sd_mod(U) scsi_mod(U) Sep 1 16:05:20 adams kernel: Pid: 20158, comm: rsync Not tainted 2.6.8-1.533.edhillsmp Sep 1 16:05:20 adams kernel: RIP: 0010:[] {do_page_fault+1340} Sep 1 16:05:20 adams kernel: RSP: 0018:0000010031e619d8 EFLAGS: 00010002 Sep 1 16:05:20 adams kernel: RAX: 0000e987f000f0e0 RBX: 0000000000000001 RCX: 000ffffffffff000 Sep 1 16:05:20 adams kernel: RDX: 0000e987f000f000 RSI: 0000010000000000 RDI: 0000010031e61a98 Sep 1 16:05:20 adams kernel: RBP: 000003010383a4b0 R08: 000003010383a4b0 R09: 0000000300000000 Sep 1 16:05:20 adams kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 00000100b7720e90 Sep 1 16:05:20 adams kernel: R13: 0000000000000000 R14: 0000010031e61a98 R15: 00000100d2990940 Sep 1 16:05:20 adams kernel: FS: 0000002a9557bd40(0000) GS:ffffffff804ee280(0000) knlGS:000000000082e560 Sep 1 16:05:20 adams kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Sep 1 16:05:20 adams kernel: CR2: 000003010383a4b0 CR3: 0000000004862000 CR4: 00000000000006e0 Sep 1 16:05:20 adams kernel: Process rsync (pid: 20158, threadinfo 0000010031e60000, task 00000100b7720e90) Sep 1 16:05:20 adams kernel: Stack: 00000101050d4e00 0000000000030001 0000010031e61a78 000001002831d130 Sep 1 16:05:20 adams kernel: 000001002831d240 0000000000000246 00000100d79b7ea0 ffffffff801801b0 Sep 1 16:05:20 adams kernel: 0000000000000246 0000000000000246 Sep 1 16:05:20 adams kernel: Call Trace:{__find_get_block+181} {__getblk+43} Sep 1 16:05:20 adams kernel: {error_exit+0} {__wake_up_common+40} Sep 1 16:05:20 adams kernel: {__mark_inode_dirty+40} {__wake_up+102} Sep 1 16:05:20 adams kernel: {generic_file_buffered_write+1085} Sep 1 16:05:20 adams kernel: {generic_file_aio_write_nolock+741} Sep 1 16:05:20 adams kernel: {generic_file_aio_write+126} {:ext3:ext3_file_write+22} Sep 1 16:05:20 adams kernel: {do_sync_write+173} {__pollwait+0} Sep 1 16:05:20 adams kernel: {autoremove_wake_function+0} {sys_select+1177} Sep 1 16:05:20 adams kernel: {vfs_write+208} {sys_write+69} Sep 1 16:05:20 adams kernel: {system_call+126} Sep 1 16:05:20 adams kernel: Sep 1 16:05:20 adams kernel: Code: 48 8b 14 06 f6 c2 01 0f 84 9c fc ff ff 48 89 e8 48 21 ca 48 Sep 1 16:05:20 adams kernel: RIP {do_page_fault+1340} RSP <0000010031e619d8> Sep 1 18:04:34 adams kernel: Unable to handle kernel paging request at 000003010383aff0 RIP: Sep 1 18:04:34 adams kernel: {__wake_up_common+37} Sep 1 18:04:34 adams kernel: PML4 0 Sep 1 18:04:34 adams kernel: Oops: 0000 [1] SMP Sep 1 18:04:34 adams kernel: CPU 1 Sep 1 18:04:34 adams kernel: Modules linked in: 3w_9xxx nfsd exportfs md5 ipv6 parport_pc lp parport autofs4 nfs lockd sunrpc iptable_filter ip_tables tg3 ohci1394 ieee1394 dm_mod ohci_hcd button battery asus_acpi ac ext3 jbd sd_mod scsi_mod Sep 1 18:04:34 adams kernel: Pid: 62, comm: kswapd1 Not tainted 2.6.7-1.515smp Sep 1 18:04:34 adams kernel: RIP: 0010:[] {__wake_up_common+37} Sep 1 18:04:34 adams kernel: RSP: 0018:00000101ffef7ae8 EFLAGS: 00010046 Sep 1 18:04:34 adams kernel: RAX: 000001010383aff0 RBX: 0000000000000001 RCX: 0000000000000000 Sep 1 18:04:34 adams kernel: RDX: 0000000000000001 RSI: 0000000000000003 RDI: 000001010383afe8 Sep 1 18:04:34 adams kernel: RBP: 00000101ffef7b18 R08: 000003010383aff0 R09: 00000101ffef7a30 Sep 1 18:04:34 adams kernel: R10: 0000000000000206 R11: 0000010102bedb80 R12: 000001010383afe8 Sep 1 18:04:34 adams kernel: R13: 00000100d4ea2e50 R14: 00000100d4ea2e50 R15: 0000010102bedb80 Sep 1 18:04:34 adams kernel: FS: 0000002a9557e800(0000) GS:ffffffff8047b600(0000) knlGS:0000000000000000 Sep 1 18:04:34 adams kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Sep 1 18:04:34 adams kernel: CR2: 000003010383aff0 CR3: 0000000004862000 CR4: 00000000000006e0 Sep 1 18:04:34 adams kernel: Process kswapd1 (pid: 62, threadinfo 00000101ffef6000, task 00000100d9eb9210) Sep 1 18:04:34 adams kernel: Stack: 0000000300000000 000001010383afe8 0000010100000780 00000100d4ea2e50 Sep 1 18:04:34 adams kernel: 00000100d4ea2e50 00000101ffef7e58 00000101ffef7b38 ffffffff80130afb Sep 1 18:04:34 adams kernel: 0000000000000206 0000000000000001 Sep 1 18:04:34 adams kernel: Call Trace:{__wake_up+33} {shrink_zone+3713} Sep 1 18:04:34 adams kernel: {__down_failed_trylock+53} {shrink_slab+119} Sep 1 18:04:34 adams kernel: {balance_pgdat+468} {balance_pgdat+2} Sep 1 18:04:34 adams kernel: {kswapd+257} {autoremove_wake_function+0} Sep 1 18:04:34 adams kernel: {autoremove_wake_function+0} {schedule_tail+11} Sep 1 18:04:34 adams kernel: {child_rip+8} {kswapd+0} Sep 1 18:04:34 adams kernel: {child_rip+0} Sep 1 18:04:34 adams kernel: Sep 1 18:04:34 adams kernel: Code: 4d 8b 30 49 39 c0 74 28 49 8d 78 e8 45 8b 68 e8 4c 89 f9 8b Sep 1 18:04:34 adams kernel: RIP {__wake_up_common+37} RSP <00000101ffef7ae8> Sep 1 18:04:34 adams kernel: CR2: 000003010383aff0 ===== 2 oopses writing to 3ware 9xxx RAID array ===== -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 -------------- next part -------------- Sep 1 16:05:20 adams kernel: general protection fault: 0000 [1] SMP Sep 1 16:05:20 adams kernel: CPU 1 Sep 1 16:05:20 adams kernel: Modules linked in: sata_sil(U) libata(U) floppy(U) sg(U) nfsd(U) exportfs(U) md5(U) ipv6(U) parport_pc(U) lp(U) parport(U) autofs4(U) nfs(U) lockd(U) sunrpc(U) iptable_filter(U) ip_tables(U) tg3(U) ohci1394(U) ieee1394(U) dm_mod(U) ohci_hcd(U) button(U) battery(U) asus_acpi(U) ac(U) ext3(U) jbd(U) 3w_9xxx(U) sd_mod(U) scsi_mod(U) Sep 1 16:05:20 adams kernel: Pid: 20158, comm: rsync Not tainted 2.6.8-1.533.edhillsmp Sep 1 16:05:20 adams kernel: RIP: 0010:[] {do_page_fault+1340} Sep 1 16:05:20 adams kernel: RSP: 0018:0000010031e619d8 EFLAGS: 00010002 Sep 1 16:05:20 adams kernel: RAX: 0000e987f000f0e0 RBX: 0000000000000001 RCX: 000ffffffffff000 Sep 1 16:05:20 adams kernel: RDX: 0000e987f000f000 RSI: 0000010000000000 RDI: 0000010031e61a98 Sep 1 16:05:20 adams kernel: RBP: 000003010383a4b0 R08: 000003010383a4b0 R09: 0000000300000000 Sep 1 16:05:20 adams kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 00000100b7720e90 Sep 1 16:05:20 adams kernel: R13: 0000000000000000 R14: 0000010031e61a98 R15: 00000100d2990940 Sep 1 16:05:20 adams kernel: FS: 0000002a9557bd40(0000) GS:ffffffff804ee280(0000) knlGS:000000000082e560 Sep 1 16:05:20 adams kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Sep 1 16:05:20 adams kernel: CR2: 000003010383a4b0 CR3: 0000000004862000 CR4: 00000000000006e0 Sep 1 16:05:20 adams kernel: Process rsync (pid: 20158, threadinfo 0000010031e60000, task 00000100b7720e90) Sep 1 16:05:20 adams kernel: Stack: 00000101050d4e00 0000000000030001 0000010031e61a78 000001002831d130 Sep 1 16:05:20 adams kernel: 000001002831d240 0000000000000246 00000100d79b7ea0 ffffffff801801b0 Sep 1 16:05:20 adams kernel: 0000000000000246 0000000000000246 Sep 1 16:05:20 adams kernel: Call Trace:{__find_get_block+181} {__getblk+43} Sep 1 16:05:20 adams kernel: {error_exit+0} {__wake_up_common+40} Sep 1 16:05:20 adams kernel: {__mark_inode_dirty+40} {__wake_up+102} Sep 1 16:05:20 adams kernel: {generic_file_buffered_write+1085} Sep 1 16:05:20 adams kernel: {generic_file_aio_write_nolock+741} Sep 1 16:05:20 adams kernel: {generic_file_aio_write+126} {:ext3:ext3_file_write+22} Sep 1 16:05:20 adams kernel: {do_sync_write+173} {__pollwait+0} Sep 1 16:05:20 adams kernel: {autoremove_wake_function+0} {sys_select+1177} Sep 1 16:05:20 adams kernel: {vfs_write+208} {sys_write+69} Sep 1 16:05:20 adams kernel: {system_call+126} Sep 1 16:05:20 adams kernel: Sep 1 16:05:20 adams kernel: Code: 48 8b 14 06 f6 c2 01 0f 84 9c fc ff ff 48 89 e8 48 21 ca 48 Sep 1 16:05:20 adams kernel: RIP {do_page_fault+1340} RSP <0000010031e619d8> Sep 1 18:04:34 adams kernel: Unable to handle kernel paging request at 000003010383aff0 RIP: Sep 1 18:04:34 adams kernel: {__wake_up_common+37} Sep 1 18:04:34 adams kernel: PML4 0 Sep 1 18:04:34 adams kernel: Oops: 0000 [1] SMP Sep 1 18:04:34 adams kernel: CPU 1 Sep 1 18:04:34 adams kernel: Modules linked in: 3w_9xxx nfsd exportfs md5 ipv6 parport_pc lp parport autofs4 nfs lockd sunrpc iptable_filter ip_tables tg3 ohci1394 ieee1394 dm_mod ohci_hcd button battery asus_acpi ac ext3 jbd sd_mod scsi_mod Sep 1 18:04:34 adams kernel: Pid: 62, comm: kswapd1 Not tainted 2.6.7-1.515smp Sep 1 18:04:34 adams kernel: RIP: 0010:[] {__wake_up_common+37} Sep 1 18:04:34 adams kernel: RSP: 0018:00000101ffef7ae8 EFLAGS: 00010046 Sep 1 18:04:34 adams kernel: RAX: 000001010383aff0 RBX: 0000000000000001 RCX: 0000000000000000 Sep 1 18:04:34 adams kernel: RDX: 0000000000000001 RSI: 0000000000000003 RDI: 000001010383afe8 Sep 1 18:04:34 adams kernel: RBP: 00000101ffef7b18 R08: 000003010383aff0 R09: 00000101ffef7a30 Sep 1 18:04:34 adams kernel: R10: 0000000000000206 R11: 0000010102bedb80 R12: 000001010383afe8 Sep 1 18:04:34 adams kernel: R13: 00000100d4ea2e50 R14: 00000100d4ea2e50 R15: 0000010102bedb80 Sep 1 18:04:34 adams kernel: FS: 0000002a9557e800(0000) GS:ffffffff8047b600(0000) knlGS:0000000000000000 Sep 1 18:04:34 adams kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Sep 1 18:04:34 adams kernel: CR2: 000003010383aff0 CR3: 0000000004862000 CR4: 00000000000006e0 Sep 1 18:04:34 adams kernel: Process kswapd1 (pid: 62, threadinfo 00000101ffef6000, task 00000100d9eb9210) Sep 1 18:04:34 adams kernel: Stack: 0000000300000000 000001010383afe8 0000010100000780 00000100d4ea2e50 Sep 1 18:04:34 adams kernel: 00000100d4ea2e50 00000101ffef7e58 00000101ffef7b38 ffffffff80130afb Sep 1 18:04:34 adams kernel: 0000000000000206 0000000000000001 Sep 1 18:04:34 adams kernel: Call Trace:{__wake_up+33} {shrink_zone+3713} Sep 1 18:04:34 adams kernel: {__down_failed_trylock+53} {shrink_slab+119} Sep 1 18:04:34 adams kernel: {balance_pgdat+468} {balance_pgdat+2} Sep 1 18:04:34 adams kernel: {kswapd+257} {autoremove_wake_function+0} Sep 1 18:04:34 adams kernel: {autoremove_wake_function+0} {schedule_tail+11} Sep 1 18:04:34 adams kernel: {child_rip+8} {kswapd+0} Sep 1 18:04:34 adams kernel: {child_rip+0} Sep 1 18:04:34 adams kernel: Sep 1 18:04:34 adams kernel: Code: 4d 8b 30 49 39 c0 74 28 49 8d 78 e8 45 8b 68 e8 4c 89 f9 8b Sep 1 18:04:34 adams kernel: RIP {__wake_up_common+37} RSP <00000101ffef7ae8> Sep 1 18:04:34 adams kernel: CR2: 000003010383aff0 From alan at redhat.com Thu Sep 2 16:12:59 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 2 Sep 2004 12:12:59 -0400 Subject: Tyan 2885 w/ 3w-9xxx oopses [was: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels] In-Reply-To: <1094140710.13662.1562.camel@localhost.localdomain> References: <1093923084.13662.369.camel@localhost.localdomain> <1094059093.13662.1409.camel@localhost.localdomain> <413614D7.7050001@lanl.gov> <200409011838.16620.loony@loonybin.org> <20040902093452.GA19117@devserv.devel.redhat.com> <1094140710.13662.1562.camel@localhost.localdomain> Message-ID: <20040902161259.GA1931@devserv.devel.redhat.com> On Thu, Sep 02, 2004 at 11:58:30AM -0400, Ed Hill wrote: > long as we don't create a lot of writes to the 3ware 9xxx controller. > When we do, the machine oopses within ~15--30min. The 3rd oops I was > not able to find in /var/log/messages but it looked similar to the > second. First guess would be the 3w-9xxx then. I've got adaptec scsi in mine and even under high load that is behaving. Nothing much useful in the traces From fedora at rooker.dyndns.org Thu Sep 2 17:18:38 2004 From: fedora at rooker.dyndns.org (Peter Maas) Date: Thu, 2 Sep 2004 12:18:38 -0500 Subject: Tyan 2885 w/ 3w-9xxx oopses [was: CONFIG_HIGHMEM64G=y forx86_64 SMP kernels] References: <1093923084.13662.369.camel@localhost.localdomain><1094059093.13662.1409.camel@localhost.localdomain><413614D7.7050001@lanl.gov> <200409011838.16620.loony@loonybin.org><20040902093452.GA19117@devserv.devel.redhat.com><1094140710.13662.1562.camel@localhost.localdomain> <20040902161259.GA1931@devserv.devel.redhat.com> Message-ID: <002301c49110$e307a5d0$6505a8c0@pixl> I would recommend compiling a vanilla kernel, with only the components you need and see if you have the same problem occurs. I am currently running vanilla 2.6.8 and have written many gigabytes of data on a terabyte 9500S-12 raid setup without fault, but I use the XFS filesystem instead of ext3. I personally believe, but with no evidence to back it up, that compiling ext3 into the kernel, and not running it as a module, gives a more stable system. I would suggest trying the latest kernel, with only the hardware you use compiled in (if you dont use the parallel port, seral ata, ipv6, dont add it in) and see if it works any better. If it doesnt you may have a hardware problem of some sort. Peter Maas > On Thu, Sep 02, 2004 at 11:58:30AM -0400, Ed Hill wrote: > > long as we don't create a lot of writes to the 3ware 9xxx controller. > > When we do, the machine oopses within ~15--30min. The 3rd oops I was > > not able to find in /var/log/messages but it looked similar to the > > second. From jfontain at free.fr Thu Sep 2 18:38:35 2004 From: jfontain at free.fr (Jean-Luc FONTAINE) Date: Thu, 02 Sep 2004 20:38:35 +0200 Subject: Fedora on DVD-RW? Message-ID: <413768AB.2020209@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just had a (possibly stupid) thought: Would it be possible to make a live Fedora DVD-RW, a fully operational system with write access, enabling the user to carry his OS and data at the same time? Myabe it has been done already? Cheers, - -- Jean-Luc Fontaine mailto:jfontain at free.fr http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBN2iokG/MMvcT1qQRAs5BAKCpbdJ2SVdbNGRhK1/I7VM7lCUmXACfXBrL lSMeLNhu+lJz669P9fBwnFA= =SDAN -----END PGP SIGNATURE----- From johnp at redhat.com Thu Sep 2 18:45:01 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 02 Sep 2004 14:45:01 -0400 Subject: Fedora on DVD-RW? In-Reply-To: <413768AB.2020209@free.fr> References: <413768AB.2020209@free.fr> Message-ID: <1094150701.6199.18.camel@remedyz.boston.redhat.com> On Thu, 2004-09-02 at 20:38 +0200, Jean-Luc FONTAINE wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I just had a (possibly stupid) thought: > Would it be possible to make a live Fedora DVD-RW, a fully operational > system with write access, enabling the user to carry his OS and data at > the same time? > > Myabe it has been done already? I don't think you can write to a disk you are reading from. It is either mounted or being written to, but not both. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From loony at loonybin.org Thu Sep 2 18:56:44 2004 From: loony at loonybin.org (Peter Arremann) Date: Thu, 2 Sep 2004 14:56:44 -0400 Subject: Tyan 2885 w/ 3w-9xxx oopses [was: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels] In-Reply-To: <20040902161259.GA1931@devserv.devel.redhat.com> References: <1093923084.13662.369.camel@localhost.localdomain> <1094059093.13662.1409.camel@localhost.localdomain> <413614D7.7050001@lanl.gov> <200409011838.16620.loony@loonybin.org> <20040902093452.GA19117@devserv.devel.redhat.com> <1094140710.13662.1562.camel@localhost.localdomain> <20040902161259.GA1931@devserv.devel.redhat.com> Message-ID: <20040902185644.GA17374@loonybin.org> On Thu, Sep 02, 2004 at 12:12:59PM -0400, Alan Cox wrote: > On Thu, Sep 02, 2004 at 11:58:30AM -0400, Ed Hill wrote: > > long as we don't create a lot of writes to the 3ware 9xxx controller. > > When we do, the machine oopses within ~15--30min. The 3rd oops I was > > not able to find in /var/log/messages but it looked similar to the > > second. > > First guess would be the 3w-9xxx then. I've got adaptec scsi in mine and > even under high load that is behaving. More specifically, a 9xxx thing... Checked with my friend, he's running 8xxx fine... Peter. From notting at redhat.com Thu Sep 2 19:04:14 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Sep 2004 15:04:14 -0400 Subject: yum 2.1.0 In-Reply-To: <1094130332.11651.5.camel@binkley> References: <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> <4136BE55.80602@nis.yu> <1094130332.11651.5.camel@binkley> Message-ID: <20040902190414.GA2414@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > yum-arch will be returning to yum for people who want to use the new yum > but have to maintain old repos. > > it's in the works now. I could have sworn Paul was just going to patch it into createrepo. Bill From notting at redhat.com Thu Sep 2 19:04:54 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Sep 2004 15:04:54 -0400 Subject: [PATCH] net-tools 1.60: deferred ifconfig netmask In-Reply-To: <1094132100.4939.31.camel@scox.glenatl.glenayre.com> References: <1094132100.4939.31.camel@scox.glenatl.glenayre.com> Message-ID: <20040902190454.GB2414@nostromo.devel.redhat.com> Malita, Florin (florin.malita at glenayre.com) said: > While I agree that ip is superior, I think lots of people still use > ifconfig for basic network configuration. Removing it will confuse some > users and break many scripts: > > grep ifconfig /etc/sysconfig/network-scripts/* Hey, file a bug on that, please. :) Bill From skvidal at phy.duke.edu Thu Sep 2 19:06:55 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Sep 2004 15:06:55 -0400 Subject: yum 2.1.0 In-Reply-To: <20040902190414.GA2414@nostromo.devel.redhat.com> References: <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> <4136BE55.80602@nis.yu> <1094130332.11651.5.camel@binkley> <20040902190414.GA2414@nostromo.devel.redhat.com> Message-ID: <1094152015.11651.27.camel@binkley> On Thu, 2004-09-02 at 15:04 -0400, Bill Nottingham wrote: > seth vidal (skvidal at phy.duke.edu) said: > > yum-arch will be returning to yum for people who want to use the new yum > > but have to maintain old repos. > > > > it's in the works now. > > I could have sworn Paul was just going to patch it into createrepo. > no, not into createrepo. That would be bad. putting into yum would be better. -sv From linux_4ever at yahoo.com Thu Sep 2 20:01:19 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 2 Sep 2004 13:01:19 -0700 (PDT) Subject: Fedora on DVD-RW? In-Reply-To: <413768AB.2020209@free.fr> Message-ID: <20040902200119.45157.qmail@web50601.mail.yahoo.com> >Would it be possible to make a live Fedora DVD-RW, a fully operational >system with write access, enabling the user to carry his OS and data at >the same time? You might be able to do this, but its not the common technique for live systems. Generally the livecd uses tempfs for /var, /etc, and other writeable directories. Another program exports or imports session data from a usb memory stick. I suspect if you work on it and get it working, it will sound very abusive. The noises coming from the drive will be terrible. >Maybe it has been done already? There is already a Fedora Live CD (not DVD) that you can get from here: http://www.linux4all.de/livecd/ I build custom LiveCD's of Fedora and it works fine. -Steve Grubb _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From jkeating at j2solutions.net Thu Sep 2 20:36:29 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 2 Sep 2004 13:36:29 -0700 Subject: Tyan 2885 w/ 3w-9xxx oopses [was: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels] In-Reply-To: <20040902185644.GA17374@loonybin.org> References: <1093923084.13662.369.camel@localhost.localdomain> <20040902161259.GA1931@devserv.devel.redhat.com> <20040902185644.GA17374@loonybin.org> Message-ID: <200409021336.35971.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 02 September 2004 11:56, Peter Arremann wrote: > More specifically, a 9xxx thing... Checked with my friend, he's > running 8xxx fine... 9xxx is a pretty significant upgrade from 3ware, and it requires the use of a complete new driver. Unfortunately 3ware hasn't been too smart in writing this driver and they still use a lot of deprecated header files in the driver compile. I haven't checked recently, but I'm not even sure if the 9xxx driver has made kernel mainstream yet. I am still working with 3ware to clean up their driver code a bit. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBN4RS4v2HLvE71NURAn/bAJ9V9qwkgNwtr01Kow6xKCvjCySKiwCgtN+b UsvfeeU750ZXMTqMYt2iOzk= =aV/f -----END PGP SIGNATURE----- From naoki at valuecommerce.com Fri Sep 3 03:02:24 2004 From: naoki at valuecommerce.com (Naoki) Date: Fri, 03 Sep 2004 12:02:24 +0900 Subject: libsoup / evolution broken dependencies? Message-ID: <4137DEC0.6070207@valuecommerce.com> .......Unable to satisfy dependencies Package evolution-data-server needs libsoup-2.2.so.6, this is not available. Package evolution needs libgal-2.2.so.0, this is not available. Package evolution needs libgal-a11y-2.2.so.0, this is not available. Package evolution needs libsoup-2.2.so.6, this is not available. # rpm -q libsoup libgal libgal-a11y libsoup-2.2.0-1 package libgal is not installed package libgal-a11y is not installed Is this my brokenness? From skvidal at phy.duke.edu Fri Sep 3 03:03:14 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Sep 2004 23:03:14 -0400 Subject: libsoup / evolution broken dependencies? In-Reply-To: <4137DEC0.6070207@valuecommerce.com> References: <4137DEC0.6070207@valuecommerce.com> Message-ID: <1094180594.11651.42.camel@binkley> On Fri, 2004-09-03 at 12:02 +0900, Naoki wrote: > .......Unable to satisfy dependencies > Package evolution-data-server needs libsoup-2.2.so.6, this is not available. > Package evolution needs libgal-2.2.so.0, this is not available. > Package evolution needs libgal-a11y-2.2.so.0, this is not available. > Package evolution needs libsoup-2.2.so.6, this is not available. > > # rpm -q libsoup libgal libgal-a11y > libsoup-2.2.0-1 > package libgal is not installed > package libgal-a11y is not installed > > Is this my brokenness? no, broken in rawhide. -sv From rms at 1407.org Fri Sep 3 06:52:59 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 03 Sep 2004 07:52:59 +0100 Subject: libsoup / evolution broken dependencies? In-Reply-To: <4137DEC0.6070207@valuecommerce.com> References: <4137DEC0.6070207@valuecommerce.com> Message-ID: <1094194379.2782.3.camel@roque> On Fri, 2004-09-03 at 12:02 +0900, Naoki wrote: > .......Unable to satisfy dependencies > Package evolution-data-server needs libsoup-2.2.so.6, this is not available. > Package evolution needs libgal-2.2.so.0, this is not available. > Package evolution needs libgal-a11y-2.2.so.0, this is not available. > Package evolution needs libsoup-2.2.so.6, this is not available. > > # rpm -q libsoup libgal libgal-a11y > libsoup-2.2.0-1 > package libgal is not installed > package libgal-a11y is not installed > > Is this my brokenness? Like Seth said, in rawhide. A possible work around is ln -s libgal-2.2.so.1 libgal-2.2.so.0 ln -s libgal-a11y-2.2.so.1 libgal-a11y-2.2.so.0 ln -s libsoup-2.2.so.7 libsoup-2.2.so.6 Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Fri Sep 3 09:22:20 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Sep 2004 05:22:20 -0400 Subject: yum 2.1.3 Message-ID: <1094203340.11651.65.camel@binkley> Hey folks, I just posted yum 2.1.3 to: http://linux.duke.edu/projects/yum/download/2.1/ This one needs some abusing. I made a bunch of changes to the depsolver to resolve some problems that testing against rawhide has shown. I think I've gotten most of them ironed out but I need more people to do more and bizarre things with it to tell, completely. If you find some behavior on an update/install/erase that you think is incorrect run the same command with -d 5 and post the output to either: http://devel.linux.duke.edu/bugzilla/ or http://bugzilla.redhat.com so I can get debugging info to solve the problems. I especially want more tests on multilib machines. I've tested it on my x86 and x86_64 boxes quite a bit but there is always someone whose configuration is significantly more weird. :) Thanks! -sv From Axel.Thimm at ATrpms.net Fri Sep 3 09:58:10 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 3 Sep 2004 11:58:10 +0200 Subject: Tyan 2885 w/ 3w-9xxx oopses [was: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels] In-Reply-To: <200409021336.35971.jkeating@j2solutions.net> References: <1093923084.13662.369.camel@localhost.localdomain> <20040902161259.GA1931@devserv.devel.redhat.com> <20040902185644.GA17374@loonybin.org> <200409021336.35971.jkeating@j2solutions.net> Message-ID: <20040903095810.GD26676@neu.physik.fu-berlin.de> On Thu, Sep 02, 2004 at 01:36:29PM -0700, Jesse Keating wrote: > Hash: SHA1 > > On Thursday 02 September 2004 11:56, Peter Arremann wrote: > > More specifically, a 9xxx thing... Checked with my friend, he's > > running 8xxx fine... > > 9xxx is a pretty significant upgrade from 3ware, and it requires the use > of a complete new driver. Unfortunately 3ware hasn't been too smart in > writing this driver and they still use a lot of deprecated header files > in the driver compile. I haven't checked recently, but I'm not even > sure if the 9xxx driver has made kernel mainstream yet. I am still > working with 3ware to clean up their driver code a bit. At least it is part of the latest Fedora Core 2 updates, so probably it was introduced in 2.6.8. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Sep 3 10:01:17 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 3 Sep 2004 12:01:17 +0200 Subject: yum 2.1.0 In-Reply-To: <1093936591.28867.14.camel@binkley> References: <1093936591.28867.14.camel@binkley> Message-ID: <20040903100117.GE26676@neu.physik.fu-berlin.de> On Tue, Aug 31, 2004 at 03:16:31AM -0400, seth vidal wrote: > I'm pleased(sorta) to announce yum 2.1.0. This is using the new xml- > based repository metadata (http://linux.duke.edu/metadata). > > NB: THIS CAN ONLY BE USED WITH REPOSITORIES THAT ARE USING THE NEW > METADATA FORMAT. THIS WILL NOT WORK WITH OLD-STYLE YUM-ARCH > REPOSITORIES. will a future yum support both legacy yum repos and new-metadata repos (I hope it will)? If not could new-yum and old-yum be rearranged in such a way as to allow concurrent installs? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From strange at nsk.no-ip.org Fri Sep 3 11:05:58 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 3 Sep 2004 12:05:58 +0100 Subject: Fedora on DVD-RW? In-Reply-To: <413768AB.2020209@free.fr> References: <413768AB.2020209@free.fr> Message-ID: <20040903110558.GA2474@nsk.no-ip.org> On Thu, Sep 02, 2004 at 08:38:35PM +0200, Jean-Luc FONTAINE wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I just had a (possibly stupid) thought: > Would it be possible to make a live Fedora DVD-RW, a fully operational > system with write access, enabling the user to carry his OS and data at > the same time? > http://fy.chalmers.se/~appro/linux/DVD+RW/ It's possible. As should be with udf+(DVD[+-]R|CD-RW), but performance would be awful for normal operation, and care should be put into constructing the live cd if it is to boot on non-writable drives. Regards, Luciano Rocha From gardnerbiggs at houston.rr.com Fri Sep 3 11:55:25 2004 From: gardnerbiggs at houston.rr.com (J. Gardner Biggs) Date: Fri, 03 Sep 2004 06:55:25 -0500 Subject: yum 2.1.0 In-Reply-To: <20040903100117.GE26676@neu.physik.fu-berlin.de> References: <1093936591.28867.14.camel@binkley> <20040903100117.GE26676@neu.physik.fu-berlin.de> Message-ID: <1094212525.8940.7.camel@gort> On Fri, 2004-09-03 at 12:01 +0200, Axel Thimm wrote: > On Tue, Aug 31, 2004 at 03:16:31AM -0400, seth vidal wrote: > > I'm pleased(sorta) to announce yum 2.1.0. This is using the new xml- > > based repository metadata (http://linux.duke.edu/metadata). > > > > NB: THIS CAN ONLY BE USED WITH REPOSITORIES THAT ARE USING THE NEW > > METADATA FORMAT. THIS WILL NOT WORK WITH OLD-STYLE YUM-ARCH > > REPOSITORIES. > > will a future yum support both legacy yum repos and new-metadata > repos (I hope it will)? If not could new-yum and old-yum be rearranged > in such a way as to allow concurrent installs? -- Where can we find info on the new style repos? And is there a primer/FAQ on how to set up yum 2.1.x to use them? I would love to give this a test! From buildsys at redhat.com Fri Sep 3 12:17:49 2004 From: buildsys at redhat.com (Build System) Date: Fri, 3 Sep 2004 08:17:49 -0400 Subject: rawhide report: 20040903 changes Message-ID: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> New package openmotif21 Compatibility libraries for Open Motif 2.1. Updated Packages: MAKEDEV-3.11-1 -------------- * Thu Sep 02 2004 Nalin Dahyabhai 3.11-1 - add an exact (-x) flag, for creating exactly one device at a time * Wed Sep 01 2004 Nalin Dahyabhai 3.10-1 - set SELinux contexts when creating device nodes, sockets, and intermediate directories - turn on SELinux support at build-time anaconda-10.0.2-0.20040901235037.1 ---------------------------------- * Thu Sep 02 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode bash-3.0-11 ----------- * Thu Sep 02 2004 Tim Waugh 3.0-11 - Fixed multibyte parameter length expansion. control-center-2.7.1-2 ---------------------- * Thu Sep 02 2004 GNOME - 1:2.7.1-2 - fix help dhcpv6-0.10-4 ------------- * Thu Sep 02 2004 Jason Vas Dias - 0.10-3/4 - fixed missing %defattr for dhcpv6_client - bug 131638 dia-0.94-4 ---------- * Fri Sep 03 2004 Matthias Clasen - Update to final 0.94 tarball - Make the help button work (#131622) * Wed Aug 18 2004 Dan Williams - Update to 0.94-pre6 - Fix RH #110738 * Thu Jul 22 2004 Dan Williams - Update to 0.94-pre1 - Add BuildRequires: libpng-devel (RH #125287) firstboot-1.3.20-1 ------------------ * Wed Sep 01 2004 Adrian Likins - 1.3.20-1 - better fix for #131308 (works now, but needs some screen resizing) fonts-xorg-6.7.99.903-5 ----------------------- * Thu Sep 02 2004 Mike A. Harris 6.7.99.903-5 - Remove xorg-x11-base-fonts virtual provide as it hoses upgrades with yum due to a complex provide/conflict problem * Thu Sep 02 2004 Mike A. Harris 6.7.99.903-4 - Version the virtual provides of "Provides: xorg-x11-base-fonts = 6.7.99.903-1" and "Provides: base-fonts = 6.8.0-1" to try and resolve weird yum upgrade conflict issue. * Thu Sep 02 2004 Mike A. Harris 6.7.99.903-3 - Added "Provides: xorg-x11-base-fonts" to fonts-xorg-base subpackage for compatitiliby with prior packaging. - Remove the fonts/util directory, as it does not include fonts. It has been moved to the xorg-x11-font-utils subpackage of xorg-x11 where it probably should have been all along. - Change fonts-xorg-truetype file list glob to luxi*.ttf so we can detect font additions better in the future, and avoid accidentally including things like Vera which we ship in external packaging already. gdb-6.1post-1.20040607.29 ------------------------- * Thu Sep 02 2004 Jeff Johnston 1.200400607.29 - Fix low-level lin-lwp code to wait specifically for any stepping LWP (bugzilla 130896) gedit-2.7.92-2 -------------- ghostscript-fonts-5.50-13 ------------------------- * Fri Sep 03 2004 Tim Waugh 5.50-13 - Own /usr/share/fonts/default (bug #131650). * Tue Jun 15 2004 Elliot Lee - rebuilt gnome-pilot-2.0.11-2 -------------------- * Thu Sep 02 2004 David Malcolm - 2.0.11-2 - added patch to fix bz #131560 gnuplot-4.0.0-2 --------------- * Thu Sep 02 2004 Bill Nottingham 4.0.0-2 - %defattr fixes (#131640) iproute-2.4.7-16 ---------------- * Wed May 26 2004 Phil Knirsch 2.4.7-16 - Took tons of manpages from debian, much more complete (#123952). * Thu May 06 2004 Phil Knirsch 2.4.7-15 - rebuilt * Thu May 06 2004 Phil Knirsch 2.4.7-13.2 - Built security errata version for FC1. kdebindings-3.3.0-2 ------------------- * Thu Sep 02 2004 Than Ngo 3.3.0-2 - get rid of pyqt/sip, separates packages * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 release * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 kdevelop-3.1.0-2 ---------------- * Thu Sep 02 2004 Than Ngo 3.1.0-2 - remove kdevelop-gdb_shared_library.patch, it's include in new upstream - cleanup specfile * Wed Sep 01 2004 Than Ngo 3.1.0-1 - update to 3.1.0 * Tue Aug 10 2004 Than Ngo 3.1.0-0.1.rc2 - update to 3.1.0 rc2 kudzu-1.1.85-1 -------------- * Thu Sep 02 2004 Bill Nottingham 1.1.85-1 - use new pci bits for getting device info (#115522) libselinux-1.17.8-2 ------------------- * Thu Sep 02 2004 Dan Walsh 1.17.8-2 - Clean up spec file * Patch from Matthias Saou * Thu Sep 02 2004 Dan Walsh 1.17.8-1 - Update from NSA * Added set_matchpathcon_printf. * Wed Sep 01 2004 Dan Walsh 1.17.7-1 - Update from NSA * Reworked av_inherit.h to allow easier re-use by kernel. libuser-0.51.10-1 ----------------- * Fri Sep 03 2004 Miloslav Trmac - 0.51.10-1 - Don't attempt to lookup using original entity name after entity modification (rename in particular) (#78376, #121252) - Fix copying of symlinks from /etc/skel (#87572, original patch from gLaNDix) - Make --enable-quota work, and fix the quota code to at least compile (#89114) - Fix several bugs (#120168, original patch from Steve Grubb) - Don't hardcode python version in spec file (#130952, from Robert Scheck) - Properly integrate the SELinux patch, it should actually be used now, even though it was "enabled" since 0.51.7-6 * Tue Aug 31 2004 Miloslav Trmac - 0.51.9-1 - Fix various typos - Document library interfaces - Build all shared libraries with -fPIC (#72536) * Wed Aug 25 2004 Miloslav Trmac - 0.51.8-1 - Update to build with latest autotools and gtk-doc - Update ALL_LINGUAS and POTFILES.in - Rebuild to depend on newer openldap lvm2-2.00.21-2 -------------- * Thu Sep 02 2004 Jeremy Katz - 2.00.21-2 - fix permissions on vg dirs mailman-2.1.5-13 ---------------- * Wed Sep 01 2004 John Dennis 3:2.1.5-13 - fix bug #124208, enable mailman cron jobs from init.d rather than during installation mc-4.6.1-0.1 ------------ * Thu Sep 02 2004 Jakub Jelinek 4.6.1-0.1 - update from CVS - handle INFO/LICENSE and INFO/OBSOLETES in rpm vfs (#67341) - remove mc-cvs-unzip (#85073) - fix hotkey handling when not UTF-8 (Leonard den Ottolander, #120735) - allow terminal aliases for keys in mc.lib and ~/mc/ini, add gnome, xterm-new and rxvt aliases for xterm (#128163) memtest86+-1.25-1 ----------------- * Sat Aug 28 2004 Warren Togami 1.25-1 - update to 1.25 * Mon Jun 28 2004 Warren Togami - update to 1.20 * Tue Jun 15 2004 Elliot Lee - rebuilt net-tools-1.60-35 ----------------- * Fri Sep 03 2004 Radek Vokal 1.60-35 - The return value of nameif was wrong (#129032) - patch from Fujitsu QA openssh-3.9p1-3 --------------- * Thu Sep 02 2004 Daniel Walsh 3.9p1-3 - Modify Colin Walter's patch to allow specifying rule during connection pciutils-2.1.99.test8-3 ----------------------- * Thu Sep 02 2004 Bill Nottingham 2.1.99.test8-3 - change sysfs access for detecting devices who get fixed up in the kernel (#115522, #123802) readline-4.3-13 --------------- * Thu Sep 02 2004 Jeremy Katz - 4.3-13 - rebuild so that static linking against readline will work on ppc64 without dot symbols rpmdb-fedora-2.91-0.20040903 ---------------------------- rwall-0.17-22 ------------- * Thu Sep 02 2004 Phil Knirsch 0.17-22 - Add netgroup feature (#62868) - Fix garbage character at end of output (#62868) * Tue Jun 15 2004 Elliot Lee 0.17-21 - rebuilt * Wed May 12 2004 Phil Knirsch 0.17-20 - Enabled PIE for server and application. - Switch from Copyright to License. selinux-policy-strict-1.17.9-2 ------------------------------ * Wed Sep 01 2004 Dan Walsh 1.17.9-2 - Clean up patch * Wed Sep 01 2004 Dan Walsh 1.17.9-1 - Latest from NSA - Merge in Russell Changes selinux-policy-targeted-1.17.9-2 -------------------------------- * Wed Sep 01 2004 Dan Walsh 1.17.9-2 - Clean up patch * Wed Sep 01 2004 Dan Walsh 1.17.9-1 - Latest from NSA - Merge in Russell Changes sysfsutils-1.1.0-2 ------------------ * Wed Sep 01 2004 AJ Lewis 1.1.0-2 - Fix permissions on -devel files system-config-date-1.7.5-1 -------------------------- * Fri Sep 03 2004 Nils Philippsen 1.7.5-1 - actually display time zone map (#131641) - put NTP stuff into own tab to better accommodate firstboot (#131314) - add accelerators to Date & Time tab udev-030-18 ----------- * Thu Sep 02 2004 Jeremy Katz - 030-18 - make the exact device in start_udev (and thus, require new MAKEDEV) * Thu Sep 02 2004 Jeremy Katz - 030-17 - make sure file contexts of everything in the tmpfs /dev are set right when start_udev runs * Thu Sep 02 2004 Harald Hoyer - 030-16 - moved /etc/hotplug.d/default/udev.hotplug to /etc/hotplug.d/default/10-udev.hotplug valgrind-2.2.0-1 ---------------- * Thu Sep 02 2004 Jakub Jelinek 2.2.0-1 - update to 2.2.0 * Thu Jul 22 2004 Jakub Jelinek 2.1.2-3 - fix packaging of documentation * Tue Jul 20 2004 Jakub Jelinek 2.1.2-2 - allow tracing of 32-bit binaries on x86-64 valgrind-callgrind-0.9.8-2 -------------------------- * Thu Sep 02 2004 Jakub Jelinek 0.9.8-2 - rebuild with valgrind 2.2.0 vte-0.11.11-2 ------------- * Tue Aug 31 2004 Warren Togami 0.11.11-2 - #111012 BuildReq gettext, ncurses-devel - remove large and not useful doc * Tue Aug 24 2004 Ray Strode 0.11.11-1 - update to 0.11.11 * Tue Aug 24 2004 Ray Strode 0.11.10-8 - Stick bottom row to bottom of terminal when resizing. (fixes #130204) xfce-mcs-plugins-4.0.6-2 ------------------------ * Thu Sep 02 2004 Than Ngo 4.0.6-2 - use find_lang macro - cleanup specfile xffm-icons-4.0.6-2 ------------------ * Thu Sep 02 2004 Than Ngo 1:4.0.6-2 - add noarch xorg-x11-6.7.99.2-2 ------------------- * Thu Aug 12 2004 Mike A. Harris 6.7.99.2-2 - Added code to the rpm pre script to munge the config file to change the "keyboard" driver to "kbd" driver on upgrades, as XOrg no longer supports the old "keyboard" driver. - Use perl -p -i -e in pre rpm script for all config file munging instead of grep and temporary files. * Wed Aug 11 2004 Mike A. Harris 6.7.99.2-1 - Update main tarball to CVS export of CVS tag XORG-6_7_99_2 snapshot - Removed patches that are now included in upstream sources: - xorg-x11-6.8.0-ppc64-support-updates.patch - xorg-x11-6.8.0-fix-xprint-install.patch - xorg-x11-6.8.0-build-fix-for-non-dri-builds.patch - Remove /etc/init.d/xprint, as we do not ship/support Xprint - Set "#define BuildXprint NO" in host.def - Add xorg-x11-6.8.0-fix-BuildXprint.patch to fix "BuildXprint NO" - Add xorg-x11-6.8.0-ppc64-XorgServer-not-XF86Server-fix.patch to fix ppc64 build issue due to upstream renaming of XF86Server to XorgServer - Added "XorgServer NO" to host.def for non-server builds * Tue Aug 10 2004 Mike A. Harris 6.7.99.1-1 - Update main tarball to CVS export of CVS tag XORG-6_7_99_1 snapshot - Removed patches that are now included in upstream sources: - xorg-x11-6.7.0-xkb-sysreq.patch - xorg-x11-6.7.0-mga-enable-video-rom-before-using.patch - xorg-x11-6.7.0-xset-man-update.patch - xorg-libX11-zh_CN.UTF8-crash-fix.patch - xorg-x11-6.8.0-i810-remove-stale-sdk-header.patch - Update xorg-x11-6.8.0-redhat-custom-startup.patch due to Imakefile change - Fix glitch in macro that disables DRI on ppc builds for fc3/rhel4 - Implemented xorg-x11-6.8.0-build-fix-for-non-dri-builds.patch patch to fix a compile time bug in the Radeon driver render acceleration on non-DRI builds, where the driver tests if CPStarted is set before calling RADEONInit3DEngineForRender(), however CPStarted is not available in non-DRI builds. Also, RADEONInit3DEngineForRender() already correctly handles both the DRI and non-DRI cases both at compile and runtime, and checks if CPStarted is set internally. (xorg #1033) yum-2.1.2-1 ----------- * Thu Sep 02 2004 Jeremy Katz - 2.1.2-1 - 2.1.2 From rdieter at math.unl.edu Fri Sep 3 12:30:04 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Sep 2004 07:30:04 -0500 Subject: rawhide report: 20040903 changes In-Reply-To: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> Message-ID: <413863CC.9030106@math.unl.edu> Build System wrote: > valgrind-callgrind-0.9.8-2 > -------------------------- > * Thu Sep 02 2004 Jakub Jelinek 0.9.8-2 > - rebuild with valgrind 2.2.0 Why is this pkg not just called "callgrind"? It's not really a subpackage of valgrind (though it depends on it). (Pet-peave of mine... IMO, rpm package names should mirror upstream tarball names when reasonably possible). -- Rex From jakub at redhat.com Fri Sep 3 12:37:38 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 3 Sep 2004 08:37:38 -0400 Subject: rawhide report: 20040903 changes In-Reply-To: <413863CC.9030106@math.unl.edu> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <413863CC.9030106@math.unl.edu> Message-ID: <20040903123738.GO30573@devserv.devel.redhat.com> On Fri, Sep 03, 2004 at 07:30:04AM -0500, Rex Dieter wrote: > Build System wrote: > > >valgrind-callgrind-0.9.8-2 > >-------------------------- > >* Thu Sep 02 2004 Jakub Jelinek 0.9.8-2 > >- rebuild with valgrind 2.2.0 > > Why is this pkg not just called "callgrind"? It's not really a > subpackage of valgrind (though it depends on it). It is a valgrind plugin. Jakub From skvidal at phy.duke.edu Fri Sep 3 12:49:08 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Sep 2004 08:49:08 -0400 Subject: rawhide report: 20040903 changes In-Reply-To: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> Message-ID: <1094215748.11651.66.camel@binkley> > yum-2.1.2-1 > ----------- > * Thu Sep 02 2004 Jeremy Katz - 2.1.2-1 > > - 2.1.2 If you have the option, don't use 2.1.2 - it's got a couple of outstanding bugs. Nothing that will break anything it just sucks. :) -sv From hk at isphuset.no Fri Sep 3 13:16:37 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 03 Sep 2004 15:16:37 +0200 Subject: FC2 Grub raid problem, long standing.. Message-ID: <1094217396.8146.19.camel@linux.local> One of our newly installed boxes had a diskcrash today, luckily it was in a 2-disk softraid mirror. Both disks are sata, and I have successfully exchanged the defective drive with a new one. Raid has been resynced ok. BUT, I cannot boot from any of the two disks since the boot disk is the one that died. "grub-install /dev/sda" tells me this: "/dev/md0 does not have any corresponding BIOS drive" /dev/md0 is /boot This bug shows that this is a LONG TIME standing bug: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484 -HK From stfn at gmx.net Fri Sep 3 13:21:11 2004 From: stfn at gmx.net (Stefan Hoelldampf) Date: Fri, 03 Sep 2004 15:21:11 +0200 Subject: rawhide report: 20040903 changes In-Reply-To: <413863CC.9030106@math.unl.edu> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <413863CC.9030106@math.unl.edu> Message-ID: <41386FC7.6000205@gmx.net> Rex Dieter wrote: >>valgrind-callgrind-0.9.8-2 >>-------------------------- >>* Thu Sep 02 2004 Jakub Jelinek 0.9.8-2 >>- rebuild with valgrind 2.2.0 > > Why is this pkg not just called "callgrind"? It's not really a > subpackage of valgrind (though it depends on it). Trying to rebuild valgrind-callgrind-0.9.8-2.src.rpm on FC2 fails if the valgrind-2.2.0 is installed: checking for valgrind installation... in /usr checking if vg_skin.h is available... Yes checking for valgrind version... valgrind-2.2.0 checking if skin version is supported... configure: error: The installed stable Valgrind is too new for this package. Please update this package! Regards, Stefan From mk at crc.dk Fri Sep 3 13:28:49 2004 From: mk at crc.dk (Mogens Kjaer) Date: Fri, 03 Sep 2004 15:28:49 +0200 Subject: FC2 Grub raid problem, long standing.. In-Reply-To: <1094217396.8146.19.camel@linux.local> References: <1094217396.8146.19.camel@linux.local> Message-ID: <41387191.9090206@crc.dk> Hans Kristian Rosbach wrote: ... > This bug shows that this is a LONG TIME standing bug: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484 I would use lilo instead of grub on a software RAID system. Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From hk at isphuset.no Fri Sep 3 13:52:37 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 03 Sep 2004 15:52:37 +0200 Subject: FC2 Grub raid problem, long standing.. In-Reply-To: <41387191.9090206@crc.dk> References: <1094217396.8146.19.camel@linux.local> <41387191.9090206@crc.dk> Message-ID: <1094219557.8143.24.camel@linux.local> > > This bug shows that this is a LONG TIME standing bug: > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484 > > I would use lilo instead of grub on a software RAID system. I too would like to use lilo, but unfortunately lilo does not boot on these computers at all. I think it stops at LI, but not sure.. Long time since I tried it last. But why has grub not been fixed for 3+ years? And what do I do to manually do the grub-install to the disks? Currently I have no way to boot the box without using the defective disk to boot into grub menu, then switch sata cable over to new disk, then boot. It works, but it isn't very nice in a rack environment =/ -HK From jgorny at aurox.org Fri Sep 3 14:18:09 2004 From: jgorny at aurox.org (Jaroslaw Gorny) Date: Fri, 3 Sep 2004 16:18:09 +0200 Subject: FC2 Grub raid problem, long standing.. In-Reply-To: <41387191.9090206@crc.dk> References: <1094217396.8146.19.camel@linux.local> <41387191.9090206@crc.dk> Message-ID: <20040903161809.7fa891cd@pro8000x.aurox.org> On Fri, 03 Sep 2004 15:28:49 +0200 Mogens Kjaer wrote: > Hans Kristian Rosbach wrote: > ... > > This bug shows that this is a LONG TIME standing bug: > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484 > > I would use lilo instead of grub on a software RAID system. With all respect: it's a little bit weird advice because Lilo is not supported very well (You cannot choose lilo during install) and we/you are promoting grub as default. Besides, bug is bug, and should be fixed :) It's not the best idea to advise somebody who found a bug in mozilla to use konqueror ;) regards, Jarek From buytenh at wantstofly.org Fri Sep 3 14:49:29 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Fri, 3 Sep 2004 16:49:29 +0200 Subject: problems running qemu-arm under Fedora Core 2. Message-ID: <20040903144929.GA23497@xi.wantstofly.org> Hi all, qemu (http://www.bellard.org/qemu) is a "FAST! processor emulator using dynamic translation to achieve good emulation speed", according to its web site. qemu contains a program called 'qemu-arm', which will let you run ARM binaries under an x86 or any other linux host. This program works fine most of the time, but it doesn't quite work very well with Fedora 2 and its kernels. First of all, I need 'setarch i686' to get qemu-arm to run at all under Fedora 2. Second, since the 2.6.7-1.494.2.2 kernel update, qemu doesn't work anymore even when using setarch. Has anyone else seen this? Any idea where I should look? cheers, Lennert ----- Forwarded message from Lennert Buytenhek ----- Date: Fri, 3 Sep 2004 16:42:23 +0200 From: Lennert Buytenhek To: yangh at coretek.com.cn, qemu-devel at nongnu.org Subject: Re: cause found for qemu-arm problems on fedora 2 (Re: [Qemu-devel] Problem with running machine code specified in the program) In-Reply-To: <20040903133400.GA22817 at xi.wantstofly.org> User-Agent: Mutt/1.4.1i On Fri, Sep 03, 2004 at 03:34:00PM +0200, Lennert Buytenhek wrote: > > I got "qemu: uncaught target signal 11 (Segmentation fault) - exiting" when > > running program like that: > > I was running into this too, and just checked it out. You should do: > > 1. Run 'setarch i686 qemu-arm' instead of 'qemu-arm'. > 2. Downgrade to the original 2.6.5 kernel that came with FC2. > > It seems that qemu-arm broke somewhere between fedora's version of > 2.6.6 and 2.6.8, their current kernel. I'm trying the intermediate > releases right now. OK, here are my findings. I tried qemu-arm from qemu 0.5.5 and from all daily qemu CVS snapshots between 20040504 and 20040901. Of those, there are actually only 16 different qemu-arm binaries (with a distinct md5 sum), so I only used those. I tried the Fedora Core 2 kernels 2.6.5-1.358 (original), 2.6.6-1.427, 2.6.6-1.435, 2.6.6-1.435.2.1, 2.6.6-1.435.2.3, 2.6.7-1.494.2.2 and 2.6.8-1.521 (the latest.) On all kernels, you get a sig11 if you run without 'setarch i686'. If you run with 'setarch i686', kernel 2.6.6-1.435.2.3 still runs everything fine, but 2.6.7-1.494.2.2 breaks all qemu versions except for the 20040519 CVS snapshot. And on the kernel after that, 2.6.8-1.521, all qemu versions are broken. If I then try to set vm.legacy_vm_layout to 1, 20040519 starts working again, but all other snapshots before and after remain broken. Puzzled. --L ----- End forwarded message ----- From anousak at muanglao.com Fri Sep 3 15:29:03 2004 From: anousak at muanglao.com (Anousak) Date: Fri, 3 Sep 2004 11:29:03 -0400 Subject: Lao TTf OT fonts Message-ID: <200409031529.i83FT3S0022142@mx1.redhat.com> Dear all, (Forgive me if this list is not the right one to be asking) After successful install Fedora Core 2, and love it, I then try to install Lao TTF OT fonts. Two years ago, I have got Lao KDE working on Mandrake and Redthat 7.0, which involved the following steps. However, some of the things I do might have been changed or may have not needed anymore, especially with new Xfree86. Please help me out and thanks in advance. What I have done: Font installation (Lao ttf OT) copy *ttf to /usr/X11R6/lib/X11/fonts/TTF run 'ttmkfdir > fonts.scale' run 'mkfontdir' run 'xset ft rehash' I wasn't able to run 'xftcache' run 'setxkbmap -v lo -option grp:alt_toggle_shift ' After finished these steps, I then checked to see if the keyboard layout for Lao is selected, it was. I also checked to see if my ttf fonts I installed were being selected or not, there weren't any. 1) Any other file(s) or anything I need to tweak? 2) Where are default fonts? Cheers, Anousak Souphavanh Malcolm Gladwell's "Tipping Point: How small things can make a big difference" -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdieter at math.unl.edu Fri Sep 3 15:34:25 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 3 Sep 2004 10:34:25 -0500 (CDT) Subject: Lao TTf OT fonts In-Reply-To: <200409031529.i83FT3S0022142@mx1.redhat.com> References: <200409031529.i83FT3S0022142@mx1.redhat.com> Message-ID: On Fri, 3 Sep 2004, Anousak wrote: > copy *ttf to /usr/X11R6/lib/X11/fonts/TTF > run 'ttmkfdir > fonts.scale' > run 'mkfontdir' > run 'xset ft rehash' > I wasn't able to run 'xftcache' Replace those steps with /sbin/service xfs reload fc-cache -- Rex From rdieter at math.unl.edu Fri Sep 3 15:36:58 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 3 Sep 2004 10:36:58 -0500 (CDT) Subject: Lao TTf OT fonts In-Reply-To: References: <200409031529.i83FT3S0022142@mx1.redhat.com> Message-ID: On Fri, 3 Sep 2004, Rex Dieter wrote: > On Fri, 3 Sep 2004, Anousak wrote: > >> copy *ttf to /usr/X11R6/lib/X11/fonts/TTF >> run 'ttmkfdir > fonts.scale' >> run 'mkfontdir' >> run 'xset ft rehash' >> I wasn't able to run 'xftcache' > > Replace those steps with > /sbin/service xfs reload > fc-cache I should have said, replace the steps after the font/file copy. That part still needs to be done, of course. (-: -- Rex From anousak at muanglao.com Fri Sep 3 15:56:45 2004 From: anousak at muanglao.com (Anousak) Date: Fri, 3 Sep 2004 11:56:45 -0400 Subject: Lao TTf OT fonts In-Reply-To: Message-ID: <200409031556.i83FunS0029994@mx1.redhat.com> Thanks, Rex. Fonts still not loaded. As I did, 1) Copied all Lao TTF fonts into /usr/X11R6/lib/X11/fonts/TTF 2) executed '/sbin/service xfs reload' from /usr/X11R6/lib/X11/fonts/TTF 3) executed 'fc-cache' from /usr/X11R6/lib/X11/fonts/TTF 4) Open Kate, Configure Editor, Schemas-Font, no Lao TTF fonts listed, only Bitstream and others. Am I missing something? Anousak -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Rex Dieter Sent: Friday, September 03, 2004 11:37 AM To: Development discussions related to Fedora Core Subject: Re: Lao TTf OT fonts On Fri, 3 Sep 2004, Rex Dieter wrote: > On Fri, 3 Sep 2004, Anousak wrote: > >> copy *ttf to /usr/X11R6/lib/X11/fonts/TTF >> run 'ttmkfdir > fonts.scale' >> run 'mkfontdir' >> run 'xset ft rehash' >> I wasn't able to run 'xftcache' > > Replace those steps with > /sbin/service xfs reload > fc-cache I should have said, replace the steps after the font/file copy. That part still needs to be done, of course. (-: -- Rex -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list From dmalcolm at redhat.com Fri Sep 3 16:19:15 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 03 Sep 2004 12:19:15 -0400 Subject: libsoup / evolution broken dependencies? In-Reply-To: <1094180594.11651.42.camel@binkley> References: <4137DEC0.6070207@valuecommerce.com> <1094180594.11651.42.camel@binkley> Message-ID: <1094228356.3710.1.camel@localhost.localdomain> On Thu, 2004-09-02 at 23:03 -0400, seth vidal wrote: > On Fri, 2004-09-03 at 12:02 +0900, Naoki wrote: > > .......Unable to satisfy dependencies > > Package evolution-data-server needs libsoup-2.2.so.6, this is not available. > > Package evolution needs libgal-2.2.so.0, this is not available. > > Package evolution needs libgal-a11y-2.2.so.0, this is not available. > > Package evolution needs libsoup-2.2.so.6, this is not available. > > > > # rpm -q libsoup libgal libgal-a11y > > libsoup-2.2.0-1 > > package libgal is not installed > > package libgal-a11y is not installed > > > > Is this my brokenness? > > no, broken in rawhide. This is fixed now; to make sure I uninstalled the packages and regrabbed them from Rawhide (and am using them to send this email...) Dave Malcolm From Nicolas.Mailhot at laPoste.net Fri Sep 3 16:20:08 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 03 Sep 2004 18:20:08 +0200 Subject: Lao TTf OT fonts In-Reply-To: <200409031556.i83FunS0029994@mx1.redhat.com> References: <200409031556.i83FunS0029994@mx1.redhat.com> Message-ID: <1094228408.1826.3.camel@rousalka.dyndns.org> Le vendredi 03 septembre 2004 ? 11:56 -0400, Anousak a ?crit : > Thanks, Rex. > > Fonts still not loaded. As I did, > > 1) Copied all Lao TTF fonts into /usr/X11R6/lib/X11/fonts/TTF > 2) executed '/sbin/service xfs reload' from /usr/X11R6/lib/X11/fonts/TTF > 3) executed 'fc-cache' from /usr/X11R6/lib/X11/fonts/TTF > 4) Open Kate, Configure Editor, Schemas-Font, no Lao TTF fonts listed, only > Bitstream and others. > > Am I missing something? For most modern apps putting fonts in /usr/share/fonts/something or ~/.fonts is likely to be simpler and much more effective;) DEATH to the legacy font system. No more X font strings for me. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From marguz at ameritech.net Fri Sep 3 16:20:41 2004 From: marguz at ameritech.net (Mark Guzzo) Date: Fri, 03 Sep 2004 11:20:41 -0500 Subject: Lao TTf OT fonts In-Reply-To: <200409031556.i83FunS0029994@mx1.redhat.com> References: <200409031556.i83FunS0029994@mx1.redhat.com> Message-ID: <1094228441.2896.3.camel@LORDLINUX.GLOBAL.SHSYSTEM.ORG> On Fri, 2004-09-03 at 10:56, Anousak wrote: > Thanks, Rex. > > Fonts still not loaded. As I did, > > 1) Copied all Lao TTF fonts into /usr/X11R6/lib/X11/fonts/TTF > 2) executed '/sbin/service xfs reload' from /usr/X11R6/lib/X11/fonts/TTF > 3) executed 'fc-cache' from /usr/X11R6/lib/X11/fonts/TTF > 4) Open Kate, Configure Editor, Schemas-Font, no Lao TTF fonts listed, only > Bitstream and others. > > Am I missing something? > > Anousak > > > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Rex Dieter > Sent: Friday, September 03, 2004 11:37 AM > To: Development discussions related to Fedora Core > Subject: Re: Lao TTf OT fonts > > On Fri, 3 Sep 2004, Rex Dieter wrote: > > > On Fri, 3 Sep 2004, Anousak wrote: > > > >> copy *ttf to /usr/X11R6/lib/X11/fonts/TTF > >> run 'ttmkfdir > fonts.scale' > >> run 'mkfontdir' > >> run 'xset ft rehash' > >> I wasn't able to run 'xftcache' > > > > Replace those steps with > > /sbin/service xfs reload > > fc-cache > > I should have said, replace the steps after the font/file copy. That part > still needs to be done, of course. (-: > > -- Rex > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > I just copy the *.ttf files to /home/user/.fonts directory. It's not there by default, you must mkdir .fonts and then copy the *.ttf files to it. X does not even need to be restarted. HTH :-) -- Mark Guzzo Citrix / Linux Admin Sinai Health Systems guzmar at sinai.org M A R G U Z at A M E R I T E C H dot N E T From tibbs at math.uh.edu Fri Sep 3 16:24:06 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 03 Sep 2004 11:24:06 -0500 Subject: FC2 Grub raid problem, long standing.. In-Reply-To: <1094217396.8146.19.camel@linux.local> (Hans Kristian Rosbach's message of "Fri, 03 Sep 2004 15:16:37 +0200") References: <1094217396.8146.19.camel@linux.local> Message-ID: >>>>> "HKR" == Hans Kristian Rosbach writes: HKR> BUT, I cannot boot from any of the two disks since the boot disk HKR> is the one that died. I put GRUB on a floppy to cover this situation. I've had machines where the BIOS will simply not boot from any disk except the first, so I build a GRUB floppy with a menu entry for each disk that finds /boot and loads the grub.conf from there. - J< From anousak at muanglao.com Fri Sep 3 16:31:54 2004 From: anousak at muanglao.com (Anousak) Date: Fri, 3 Sep 2004 12:31:54 -0400 Subject: Lao TTf OT fonts In-Reply-To: <1094228408.1826.3.camel@rousalka.dyndns.org> Message-ID: <200409031631.i83GVrS0007786@mx1.redhat.com> Thanks, Nicolas and all. It works! Surely new features make life easier. Cheers, Anousak -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Nicolas Mailhot Sent: Friday, September 03, 2004 12:20 PM To: Development discussions related to Fedora Core Subject: RE: Lao TTf OT fonts Le vendredi 03 septembre 2004 ? 11:56 -0400, Anousak a ?crit : > Thanks, Rex. > > Fonts still not loaded. As I did, > > 1) Copied all Lao TTF fonts into /usr/X11R6/lib/X11/fonts/TTF > 2) executed '/sbin/service xfs reload' from /usr/X11R6/lib/X11/fonts/TTF > 3) executed 'fc-cache' from /usr/X11R6/lib/X11/fonts/TTF > 4) Open Kate, Configure Editor, Schemas-Font, no Lao TTF fonts listed, only > Bitstream and others. > > Am I missing something? For most modern apps putting fonts in /usr/share/fonts/something or ~/.fonts is likely to be simpler and much more effective;) DEATH to the legacy font system. No more X font strings for me. -- Nicolas Mailhot From anousak at muanglao.com Fri Sep 3 17:10:17 2004 From: anousak at muanglao.com (Anousak) Date: Fri, 3 Sep 2004 13:10:17 -0400 Subject: Lao KDE related questions In-Reply-To: <1094228441.2896.3.camel@LORDLINUX.GLOBAL.SHSYSTEM.ORG> Message-ID: <200409031710.i83HAHsT006351@mx3.redhat.com> Hi All, There are several more things which I need your help. The following are steps necessary to get Lao support in KDE. 1) I want to have KDE as default environment. Though I can manually select at the beginning but want to make it as default. 2) set 'setxkbmap -v us,lo -options grp:alt_toggle_shift' as default at start of Fedora. Which file should I include this statement? 3) Put all localized KDE files (mo files) in to usr/share/locale/lo. How do I load the KDE so that Lao GUIs/menus would take into effect? Could I do it from Control Panel? Thanks for your help in advance. Cheers, Anousak From florin at andrei.myip.org Fri Sep 3 17:44:07 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 03 Sep 2004 10:44:07 -0700 Subject: Nmap 3.70 Released: Core Scan Engine Rewrite Message-ID: <1094233447.12448.26.camel@stantz.corp.sgi.com> nmap-3.70 was released, with a lot of new features and improvements: http://seclists.org/lists/nmap-hackers/2004/Jul-Sep/0005.html The most important are: - parallel scan: many times requested, it improves the speed by orders of magnitude - improved UDP scans (fewer open port false positives) Please include it in the devel tree for the Fedora 3 release. -- Florin Andrei http://florin.myip.org/ From dax at gurulabs.com Fri Sep 3 17:51:48 2004 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 03 Sep 2004 11:51:48 -0600 Subject: rawhide report: 20040903 changes In-Reply-To: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> Message-ID: <1094233908.5087.7.camel@mentorng.gurulabs.com> > xorg-x11-6.7.99.2-2 > ------------------- > * Thu Aug 12 2004 Mike A. Harris 6.7.99.2-2 > > - Added code to the rpm pre script to munge the config file to change the > "keyboard" driver to "kbd" driver on upgrades, as XOrg no longer supports > the old "keyboard" driver. > - Use perl -p -i -e in pre rpm script for all config file munging instead of > grep and temporary files. Did the policy on no perl in RPM pre/post install scripts change? There have been many bugzilla bugs filed and fixed over the years removing perl from rpm scripts. Dax Kelson Guru Labs From mharris at redhat.com Fri Sep 3 17:59:36 2004 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 3 Sep 2004 13:59:36 -0400 (EDT) Subject: rawhide report: 20040903 changes In-Reply-To: <1094233908.5087.7.camel@mentorng.gurulabs.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> Message-ID: On Fri, 3 Sep 2004, Dax Kelson wrote: >> xorg-x11-6.7.99.2-2 >> ------------------- >> * Thu Aug 12 2004 Mike A. Harris 6.7.99.2-2 >> >> - Added code to the rpm pre script to munge the config file to change the >> "keyboard" driver to "kbd" driver on upgrades, as XOrg no longer supports >> the old "keyboard" driver. >> - Use perl -p -i -e in pre rpm script for all config file munging instead of >> grep and temporary files. > >Did the policy on no perl in RPM pre/post install scripts change? What policy? >There have been many bugzilla bugs filed and fixed over the years >removing perl from rpm scripts. That may be so, but it is impossible to install a modern Red Hat OS without installing perl. Since perl is guaranteed to be there, because so many parts of the OS require it, I see no reason not to use it. It's been present in XFree86 packaging for ages now. I've even considered making all of the rpm scripts pure perl by using #!/usr/bin/perl shebangs. ;o) The perl code present now, replaces some very ugly sed code which used temporary files. I see no compelling technical reason to not use perl. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - X11 Developer - Red Hat From lorenzo at reality.it Fri Sep 3 18:00:05 2004 From: lorenzo at reality.it (Lorenzo Luconi Trombacchi) Date: Fri, 03 Sep 2004 20:00:05 +0200 Subject: yum 2.1.0 In-Reply-To: <1094152015.11651.27.camel@binkley> References: <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> <4136BE55.80602@nis.yu> <1094130332.11651.5.camel@binkley> <20040902190414.GA2414@nostromo.devel.redhat.com> <1094152015.11651.27.camel@binkley> Message-ID: <4138B125.9080203@reality.it> The createrepo command works only on Fedora Core 2? I tried it on Fedora Core 1 and Red Hat 9 but I got an error like this one: 7/105 - mozilla-js-debugger-1.7.2-0.2.0.i386.rpmTraceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 488, in ? main(sys.argv[1:]) File "/usr/share/createrepo/genpkgmetadata.py", line 423, in main doPkgMetadata(cmds, ts) File "/usr/share/createrepo/genpkgmetadata.py", line 286, in doPkgMetadata node = dumpMetadata.generateXML(basedoc, baseroot, formatns, mdobj, cmds['sumtype']) File "/usr/share/createrepo/dumpMetadata.py", line 507, in generateXML value = utf8String(value) File "/usr/share/createrepo/dumpMetadata.py", line 92, in utf8String x = unicode(string, 'ascii') TypeError: coercing to Unicode: need string or buffer, NoneType found Can I do something to fix this problem? Unfortunately my repository are on Fedora Core 1 or RH9 machines! :-( Lorenzo > On Thu, 2004-09-02 at 15:04 -0400, Bill Nottingham wrote: > >>seth vidal (skvidal at phy.duke.edu) said: >> >>>yum-arch will be returning to yum for people who want to use the new yum >>>but have to maintain old repos. >>> >>>it's in the works now. >> >>I could have sworn Paul was just going to patch it into createrepo. >> > > > no, not into createrepo. That would be bad. putting into yum would be > better. > > -sv > > > From skvidal at phy.duke.edu Fri Sep 3 18:06:02 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Sep 2004 14:06:02 -0400 Subject: yum 2.1.0 In-Reply-To: <4138B125.9080203@reality.it> References: <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> <4136BE55.80602@nis.yu> <1094130332.11651.5.camel@binkley> <20040902190414.GA2414@nostromo.devel.redhat.com> <1094152015.11651.27.camel@binkley> <4138B125.9080203@reality.it> Message-ID: <1094234762.27009.11.camel@opus.phy.duke.edu> On Fri, 2004-09-03 at 14:00, Lorenzo Luconi Trombacchi wrote: > The createrepo command works only on Fedora Core 2? > > I tried it on Fedora Core 1 and Red Hat 9 but I got an error like this one: > > Can I do something to fix this problem? > > Unfortunately my repository are on Fedora Core 1 or RH9 machines! :-( install createrepo 0.3.6 from here: http://linux.duke.edu/metadata/generate/ 0.3.6 works fine on fc1 and rhl9 machines. 0.3.7 had a patch added that requires a newer libxml2, iirc. I'll get it fixed up. -sv From alan at redhat.com Fri Sep 3 18:07:52 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 3 Sep 2004 14:07:52 -0400 Subject: rawhide report: 20040903 changes In-Reply-To: References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> Message-ID: <20040903180752.GA17419@devserv.devel.redhat.com> On Fri, Sep 03, 2004 at 01:59:36PM -0400, Mike A. Harris wrote: > >Did the policy on no perl in RPM pre/post install scripts change? > > What policy? The "no perl" policy. We certainly used to have one. Part of the problem is that perl is *huge* and causes dependancy loops. Another part is that the perl syntax varies by release [until we get perl6]. That means a perl scriptlet might get run by something quite different. > That may be so, but it is impossible to install a modern Red Hat > OS without installing perl. Since perl is guaranteed to be Nope. I do it for all my firewalls. rpm -e perl is the highlight of the install experience ;) > for ages now. I've even considered making all of the rpm scripts > pure perl by using #!/usr/bin/perl shebangs. ;o) /usb/bin/perl5 ?? > The perl code present now, replaces some very ugly sed code which > used temporary files. I see no compelling technical reason to > not use perl. To quote a former employee: "We don't like it, it's perl" -Trond Eivind Glomsr From icon at linux.duke.edu Fri Sep 3 18:12:48 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Fri, 03 Sep 2004 14:12:48 -0400 Subject: rawhide report: 20040903 changes In-Reply-To: References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> Message-ID: <1094235168.5336.16.camel@hagrid.phy.duke.edu> On Fri, 2004-09-03 at 13:59 -0400, Mike A. Harris wrote: > I've even considered making all of the rpm scripts > pure perl by using #!/usr/bin/perl shebangs. ;o) Just in case, you know, your eyes weren't quite bleeding enough from reading the .spec files themselves. :) Regards, -- Konstantin ("Icon") Ryabitsev Duke University Physics Sysadmin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Fri Sep 3 18:34:11 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 3 Sep 2004 13:34:11 -0500 (CDT) Subject: Lao TTf OT fonts In-Reply-To: <200409031556.i83FunS0029994@mx1.redhat.com> References: <200409031556.i83FunS0029994@mx1.redhat.com> Message-ID: On Fri, 3 Sep 2004, Anousak wrote: > Thanks, Rex. > > Fonts still not loaded. As I did, > > 1) Copied all Lao TTF fonts into /usr/X11R6/lib/X11/fonts/TTF > 2) executed '/sbin/service xfs reload' from /usr/X11R6/lib/X11/fonts/TTF > 3) executed 'fc-cache' from /usr/X11R6/lib/X11/fonts/TTF > 4) Open Kate, Configure Editor, Schemas-Font, no Lao TTF fonts listed, only > Bitstream and others. > > Am I missing something? Actually yes. 1. Make sure that folder is in your legacy/xfs fontpath (as root) chkfontpath --add /usr/X11R6/lib/X11/fonts/TTF afterwhich, (re)run /sbin/service xfs reload 2. Make sure that folder is configured for use with fontconfig, ie, is it listed in /etc/fonts/fonts.conf afterwich, (re)run fc-cache -- Rex From sopwith at redhat.com Fri Sep 3 18:34:40 2004 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 3 Sep 2004 14:34:40 -0400 (EDT) Subject: rawhide report: 20040903 changes In-Reply-To: References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> Message-ID: On Fri, 3 Sep 2004, Mike A. Harris wrote: > The perl code present now, replaces some very ugly sed code which > used temporary files. I see no compelling technical reason to > not use perl. It's big and causes dependency loops, and it doesn't sound necessary in this case. ('perl -pi' uses temporary files too, it just hides them.) The script does look a little nicer with perl, but pretty isn't enough. :\ FWIW, -- Elliot The daring is in the doing http://people.redhat.com/sopwith/ From veillard at redhat.com Fri Sep 3 18:38:26 2004 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 3 Sep 2004 14:38:26 -0400 Subject: rawhide report: 20040903 changes In-Reply-To: <20040903180752.GA17419@devserv.devel.redhat.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> <20040903180752.GA17419@devserv.devel.redhat.com> Message-ID: <20040903183825.GF16238@redhat.com> On Fri, Sep 03, 2004 at 02:07:52PM -0400, Alan Cox wrote: > On Fri, Sep 03, 2004 at 01:59:36PM -0400, Mike A. Harris wrote: > > >Did the policy on no perl in RPM pre/post install scripts change? > > > > What policy? > > The "no perl" policy. We certainly used to have one. Part of the problem is > that perl is *huge* and causes dependancy loops. Another part is that the > perl syntax varies by release [until we get perl6]. That means a perl scriptlet > might get run by something quite different. > > > That may be so, but it is impossible to install a modern Red Hat > > OS without installing perl. Since perl is guaranteed to be > > Nope. I do it for all my firewalls. rpm -e perl is the highlight of the > install experience ;) The let's rewrite rpm in perl, will be easier to debug, we can then swap the spec syntax by perl's ones, and someone else takes care of the portability problem, plus this will annoy Yum and up2date maintainers to no end ... /me ducks and run ... Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From jakub at redhat.com Fri Sep 3 19:18:31 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 3 Sep 2004 15:18:31 -0400 Subject: rawhide report: 20040903 changes In-Reply-To: References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> Message-ID: <20040903191831.GR30573@devserv.devel.redhat.com> On Fri, Sep 03, 2004 at 02:34:40PM -0400, Elliot Lee wrote: > On Fri, 3 Sep 2004, Mike A. Harris wrote: > > > The perl code present now, replaces some very ugly sed code which > > used temporary files. I see no compelling technical reason to > > not use perl. > > It's big and causes dependency loops, and it doesn't sound necessary in > this case. ('perl -pi' uses temporary files too, it just hides them.) > > The script does look a little nicer with perl, but pretty isn't enough. :\ Furthermore you can sed -i -e 's/foo/bar/' baz too. Jakub From ville.skytta at iki.fi Fri Sep 3 19:38:39 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 03 Sep 2004 22:38:39 +0300 Subject: yum 2.1.0 In-Reply-To: <1094234762.27009.11.camel@opus.phy.duke.edu> References: <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> <4136BE55.80602@nis.yu> <1094130332.11651.5.camel@binkley> <20040902190414.GA2414@nostromo.devel.redhat.com> <1094152015.11651.27.camel@binkley> <4138B125.9080203@reality.it> <1094234762.27009.11.camel@opus.phy.duke.edu> Message-ID: <1094240318.2880.24.camel@bobcat.mine.nu> On Fri, 2004-09-03 at 21:06, seth vidal wrote: > On Fri, 2004-09-03 at 14:00, Lorenzo Luconi Trombacchi wrote: > > The createrepo command works only on Fedora Core 2? > > > > I tried it on Fedora Core 1 and Red Hat 9 but I got an error like this one: > > > > > Can I do something to fix this problem? > > > > Unfortunately my repository are on Fedora Core 1 or RH9 machines! :-( > > > install createrepo 0.3.6 from here: > http://linux.duke.edu/metadata/generate/ > > 0.3.6 works fine on fc1 and rhl9 machines. 0.3.7 had a patch added that > requires a newer libxml2, iirc. I'll get it fixed up. I don't think this particular traceback has anything to do with libxml2, but tagByName() behaving differently on FC2 and < FC2 (seemingly a rpm, rpm-python or python difference). The attached patch should fix this particular case. -------------- next part -------------- A non-text attachment was scrubbed... Name: utf8string-none.patch Type: text/x-patch Size: 587 bytes Desc: not available URL: From skvidal at phy.duke.edu Fri Sep 3 19:41:07 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Sep 2004 15:41:07 -0400 Subject: yum 2.1.0 In-Reply-To: <1094240318.2880.24.camel@bobcat.mine.nu> References: <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <4134AD7A.2070109@lanl.gov> <1093998882.3817.0.camel@binkley> <4135FCEF.6070003@lanl.gov> <4136BE55.80602@nis.yu> <1094130332.11651.5.camel@binkley> <20040902190414.GA2414@nostromo.devel.redhat.com> <1094152015.11651.27.camel@binkley> <4138B125.9080203@reality.it> <1094234762.27009.11.camel@opus.phy.duke.edu> <1094240318.2880.24.camel@bobcat.mine.nu> Message-ID: <1094240467.27009.68.camel@opus.phy.duke.edu> > I don't think this particular traceback has anything to do with libxml2, > but tagByName() behaving differently on FC2 and < FC2 (seemingly a rpm, > rpm-python or python difference). The attached patch should fix this > particular case. > > ______________________________________________________________________ > Index: dumpMetadata.py > =================================================================== > RCS file: /cvsroot/metadata/cvs-root/generate/dumpMetadata.py,v > retrieving revision 1.22 > diff -a -u -r1.22 dumpMetadata.py > --- dumpMetadata.py 27 Aug 2004 07:03:40 -0000 1.22 > +++ dumpMetadata.py 3 Sep 2004 19:37:02 -0000 > @@ -86,7 +86,9 @@ > > def utf8String(string): > """hands back a unicoded string""" > - if isinstance(string, unicode): > + if string is None: > + return '' > + elif isinstance(string, unicode): > return string > try: > x = unicode(string, 'ascii') > > ______________________________________________________________________ Thanks Ville, I'll get that applied to cvs shortly. -sv From ville.skytta at iki.fi Fri Sep 3 19:49:00 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 03 Sep 2004 22:49:00 +0300 Subject: rawhide report: 20040903 changes In-Reply-To: <20040903191831.GR30573@devserv.devel.redhat.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> <20040903191831.GR30573@devserv.devel.redhat.com> Message-ID: <1094240940.2880.33.camel@bobcat.mine.nu> On Fri, 2004-09-03 at 22:18, Jakub Jelinek wrote: > Furthermore you can > sed -i -e 's/foo/bar/' baz > too. Yes, as long as you assume sed >= 3.95 for '-i' (which means >= RH9, probably not an issue here) and are careful with your regexps. Unlike perl, sed has hideous regexp syntax/semantic incompatibilities between versions. From mail.sw.rh.rhl.devel at spam.fi.basen.net Fri Sep 3 20:04:15 2004 From: mail.sw.rh.rhl.devel at spam.fi.basen.net (Kaj J.Niemi) Date: Fri, 3 Sep 2004 23:04:15 +0300 (EEST) Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... References: <41349A1F.9030207@daimi.au.dk> Message-ID: <20040903200415.07C062F416E@Jenny.A51.ORG> > If i then shifts to the wire, UDP packages suddently isn't comming throug > but tcp connections work fine. That is, no name server resolution, but I'm > able to ping and access sites with the ip. Since you're running 4.0.4B you might want to upgrade to 4.6.00.0045 (released August 25, 2004), which fixes "The Linux VPN Client does not work with DNS requests and SMTP." (CSCee27420) The workaround for 4.0.3, 4.0.4 and 4.0.5 is to use a split-tunnel setup instead of tunneling everything and making sure the name servers are positioned outside the ranges setup as being tunneled. This of course will not work if your internal network consists of private address space and your external name servers do not return the correct answers for RFC 1918 address space queries. :) Yet another reason why nat is evil. ;-) // kaj From iago.rubio at hispalinux.es Fri Sep 3 20:17:11 2004 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Fri, 03 Sep 2004 22:17:11 +0200 Subject: yum 2.1.0 In-Reply-To: <1093936591.28867.14.camel@binkley> References: <1093936591.28867.14.camel@binkley> Message-ID: <1094242630.26965.8.camel@speedy.iagorubio.net> On Tue, 2004-08-31 at 09:16, seth vidal wrote: > What needs to be done: > - translations Attached the spanish one. Hope this helps. -- Iago Rubio - GPG Keyserv * pgp.rediris.es id=0x909BD4DD -------------- next part -------------- A non-text attachment was scrubbed... Name: es.po.gz Type: application/x-gzip Size: 7517 bytes Desc: not available URL: From skvidal at phy.duke.edu Fri Sep 3 20:18:50 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Sep 2004 16:18:50 -0400 Subject: yum 2.1.0 In-Reply-To: <1094242630.26965.8.camel@speedy.iagorubio.net> References: <1093936591.28867.14.camel@binkley> <1094242630.26965.8.camel@speedy.iagorubio.net> Message-ID: <1094242730.27009.81.camel@opus.phy.duke.edu> On Fri, 2004-09-03 at 16:17, Iago Rubio wrote: > On Tue, 2004-08-31 at 09:16, seth vidal wrote: > > What needs to be done: > > - translations > > Attached the spanish one. > > Hope this helps. Thank you, but the strings in the program are changing quite a bit right now as there are some explanations that are unfortunately unclear. I'll be begging for translations before long though. -sv From jfontain at free.fr Fri Sep 3 19:15:01 2004 From: jfontain at free.fr (Jean-Luc FONTAINE) Date: Fri, 03 Sep 2004 21:15:01 +0200 Subject: rawhide report: 20040903 changes In-Reply-To: <20040903180752.GA17419@devserv.devel.redhat.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> <20040903180752.GA17419@devserv.devel.redhat.com> Message-ID: <4138C2B5.30909@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Cox wrote: | Nope. I do it for all my firewalls. rpm -e perl is the highlight of the | install experience ;) Sorry about the noise, but I just had to express my thankfulness for such a statement... It makes me feel good. - -- Jean-Luc Fontaine mailto:jfontain at free.fr http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBOMKvkG/MMvcT1qQRAk8WAKCOfwF6i7ZTaI9bJkt569bybhQ2IgCfdUOO VkKbrevuRwEXo+PavD0vaMY= =pEdF -----END PGP SIGNATURE----- From smoogen at lanl.gov Fri Sep 3 20:45:26 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Fri, 03 Sep 2004 14:45:26 -0600 Subject: Religous wars In-Reply-To: <1094233908.5087.7.camel@mentorng.gurulabs.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> Message-ID: <4138D7E6.7020402@lanl.gov> Dax Kelson wrote: >>xorg-x11-6.7.99.2-2 >>------------------- >>* Thu Aug 12 2004 Mike A. Harris 6.7.99.2-2 >> >>- Added code to the rpm pre script to munge the config file to change the >> "keyboard" driver to "kbd" driver on upgrades, as XOrg no longer supports >> the old "keyboard" driver. >>- Use perl -p -i -e in pre rpm script for all config file munging instead of >> grep and temporary files. > > > Did the policy on no perl in RPM pre/post install scripts change? > > There have been many bugzilla bugs filed and fixed over the years > removing perl from rpm scripts. > Wow. I havent seen a good religous war in some time. Will be burning Larry Wall or Guido today? Its getting cold out soon so how about burning them both and the rest of the heretics who do not use awk. [Sorry.. just had a long 'discussion' on how Debian was the one true OS and RH/Fedora/Gentoo heretics were the cause of all problems on the earth.. I didnt figure I would see one here too.] -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From anousak at muanglao.com Fri Sep 3 21:18:38 2004 From: anousak at muanglao.com (Anousak) Date: Fri, 3 Sep 2004 17:18:38 -0400 Subject: Lao KDE? In-Reply-To: Message-ID: <200409032118.i83LIbS0021933@mx1.redhat.com> Hi All, After installed mo files (translated Lao KDE message files) under /usr/share/locale/lo then I configured Lao support under Control Center-Regional and Accessibility-Country/Region and Language-Laos. I then selected Appearance and Themes-Fonts, under Menus I select Lao OT font. Applied both changes. Opened Kwrite, but Lao GUI wasn't take into affect. I also tried with conqueror. Anything else I need to do? Thanks, Anousak From sopwith at redhat.com Fri Sep 3 21:58:55 2004 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 3 Sep 2004 17:58:55 -0400 (EDT) Subject: FC3test2 candidate tree Message-ID: Hi all, I've just started uploading the latest "release candidate" for FC3test2. This is __________________NOT__________________ the final FC3test2 tree. If you're interested in helping with testing for the FC3test2 milestone, wait until it finishes uploading (there's 39G still to go, but hopefully it will be done by tomorrow). Right now we're down to "no broken dependencies" and "might install". You'll have to find out for yourself. :-) Especially useful would be reports on installs from CD or DVD. Unlike rawhide, this tree has all the .iso images. Where to get it when it's uploaded? http://fedora.linux.duke.edu/FC3-re0903.0/ Cheers, -- Elliot The daring is in the doing http://people.redhat.com/sopwith/ From dax at gurulabs.com Fri Sep 3 22:17:32 2004 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 03 Sep 2004 16:17:32 -0600 Subject: Religous wars In-Reply-To: <4138D7E6.7020402@lanl.gov> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> <4138D7E6.7020402@lanl.gov> Message-ID: <1094249852.5087.23.camel@mentorng.gurulabs.com> On Fri, 2004-09-03 at 14:45, Stephen J Smoogen wrote: > Dax Kelson wrote: > >>xorg-x11-6.7.99.2-2 > >>------------------- > >>* Thu Aug 12 2004 Mike A. Harris 6.7.99.2-2 > >> > >>- Added code to the rpm pre script to munge the config file to change the > >> "keyboard" driver to "kbd" driver on upgrades, as XOrg no longer supports > >> the old "keyboard" driver. > >>- Use perl -p -i -e in pre rpm script for all config file munging instead of > >> grep and temporary files. > > > > > > Did the policy on no perl in RPM pre/post install scripts change? > > > > There have been many bugzilla bugs filed and fixed over the years > > removing perl from rpm scripts. > > > > Wow. I havent seen a good religous war in some time. Will be burning > Larry Wall or Guido today? Its getting cold out soon so how about > burning them both and the rest of the heretics who do not use awk. > > [Sorry.. just had a long 'discussion' on how Debian was the one true OS > and RH/Fedora/Gentoo heretics were the cause of all problems on the > earth.. I didnt figure I would see one here too.] Nah. This is not a religious thing. And my post wasn't meant as a troll. Read all the justification posts about lean installs without perl, etc. Dax From smoogen at lanl.gov Fri Sep 3 22:34:51 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Fri, 03 Sep 2004 16:34:51 -0600 Subject: Religous wars In-Reply-To: <1094249852.5087.23.camel@mentorng.gurulabs.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> <4138D7E6.7020402@lanl.gov> <1094249852.5087.23.camel@mentorng.gurulabs.com> Message-ID: <4138F18B.7040501@lanl.gov> Dax Kelson wrote: > On Fri, 2004-09-03 at 14:45, Stephen J Smoogen wrote: > > Nah. > > This is not a religious thing. And my post wasn't meant as a troll. > No it wasnt.. mine ended up being more like one.. probably because of other conversations I had just gotten out of. > Read all the justification posts about lean installs without perl, etc. > I understand the justification for not using perl, and I can see the justification of using perl. I just see some of the trolls below your message as me-andering into a discussion of what the one-true-scripting-language should be based off of feelings/emotions versus technical effects. In the end, it is up to the Fedora leadership to come up with a published policy on how official core/extra spec files should be scripted. And if perl/python/tcl/ruby isnt to be used in them.. then someone should help make the various sed bits more manageble to use for the developers who are stuck not using the language their brain finds most comfortable. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From steve at silug.org Fri Sep 3 22:50:19 2004 From: steve at silug.org (Steven Pritchard) Date: Fri, 3 Sep 2004 17:50:19 -0500 Subject: rawhide report: 20040903 changes In-Reply-To: <20040903183825.GF16238@redhat.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> <20040903180752.GA17419@devserv.devel.redhat.com> <20040903183825.GF16238@redhat.com> Message-ID: <20040903225019.GA29980@osiris.silug.org> On Fri, Sep 03, 2004 at 02:38:26PM -0400, Daniel Veillard wrote: > The let's rewrite rpm in perl The first version of rpm was written in Perl... ftp://ftp.rpm.org/pub/rpm/dist/rpm-1.x/ Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From alan at redhat.com Fri Sep 3 23:01:29 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 3 Sep 2004 19:01:29 -0400 Subject: rawhide report: 20040903 changes In-Reply-To: <20040903183825.GF16238@redhat.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> <20040903180752.GA17419@devserv.devel.redhat.com> <20040903183825.GF16238@redhat.com> Message-ID: <20040903230129.GA12954@devserv.devel.redhat.com> On Fri, Sep 03, 2004 at 02:38:26PM -0400, Daniel Veillard wrote: > The let's rewrite rpm in perl, will be easier to debug, we can then > swap the spec syntax by perl's ones, and someone else takes care of the Thats how it started. Take a look at a Red Hat mothers day CD From warren at togami.com Sat Sep 4 03:03:34 2004 From: warren at togami.com (Warren Togami) Date: Fri, 03 Sep 2004 17:03:34 -1000 Subject: rawhide report: 20040903 changes In-Reply-To: <20040903180752.GA17419@devserv.devel.redhat.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> <20040903180752.GA17419@devserv.devel.redhat.com> Message-ID: <41393086.9070403@togami.com> Alan Cox wrote: > >>That may be so, but it is impossible to install a modern Red Hat >>OS without installing perl. Since perl is guaranteed to be > > > Nope. I do it for all my firewalls. rpm -e perl is the highlight of the > install experience ;) It is impossible to not have perl in a minimal rpmbuild environment, so it should be okay to use it during rpmbuild. Warren From pri.rhl3 at iadonisi.to Sat Sep 4 03:09:20 2004 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Fri, 03 Sep 2004 23:09:20 -0400 Subject: Religous wars In-Reply-To: <4138F18B.7040501@lanl.gov> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> <4138D7E6.7020402@lanl.gov> <1094249852.5087.23.camel@mentorng.gurulabs.com> <4138F18B.7040501@lanl.gov> Message-ID: <1094267360.6576.11.camel@va.local.linuxlobbyist.org> On Fri, 2004-09-03 at 18:34, Stephen J Smoogen wrote: > Dax Kelson wrote: > > On Fri, 2004-09-03 at 14:45, Stephen J Smoogen wrote: > > > > > Nah. > > > > This is not a religious thing. And my post wasn't meant as a troll. > > > > No it wasnt.. mine ended up being more like one.. probably because of > other conversations I had just gotten out of. You fell victim to one of the classic blunders, the most famous of which is "Never get involved in a land war in Asia", but only slightly less well known is this: "Never go in against a Sicilian, when *death* is on the line.". But even less well known is never get in argument over operating systems with a Debianite. Hahahahahah. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From pri.rhl3 at iadonisi.to Sat Sep 4 03:15:05 2004 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Fri, 03 Sep 2004 23:15:05 -0400 Subject: FC2 Grub raid problem, long standing.. In-Reply-To: <1094217396.8146.19.camel@linux.local> References: <1094217396.8146.19.camel@linux.local> Message-ID: <1094267705.6576.18.camel@va.local.linuxlobbyist.org> On Fri, 2004-09-03 at 09:16, Hans Kristian Rosbach wrote: [snip] > "grub-install /dev/sda" tells me this: > "/dev/md0 does not have any corresponding BIOS drive" > > /dev/md0 is /boot > > This bug shows that this is a LONG TIME standing bug: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484 I have a workaround for this. I usually just edit /etc/mtab and change the /dev/md* entries with the corresponding /dev/sda* partitions. Use lsraid to determine what those are (or look at your /etc/raidtab). Then the 'grub-install /dev/sda' should work. You may also want to do the same for /dev/sdb. Don't forget to change them back to what they were or things might get a little confused (df, for one, will not show the correct information). It's a hack, but it's worked for me. However, I've never tried booting either of my soft-raid1 disks without the other one. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From linux00 at kornet.net Sat Sep 4 04:24:03 2004 From: linux00 at kornet.net (sangu) Date: Sat, 04 Sep 2004 13:24:03 +0900 Subject: Please add Un-series truetype fonts (Korean) in FC3. Message-ID: <1094271843.3362.8.camel@sangu.sangu.net> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112877 http://cvs.kldp.net/viewcvs/unfonts/un-fonts/README?view=auto&rev=1.1 un-series fonts using GNOME desktop screenshot : * http://hellocity.net/~iolo/wiki/ScreenShots?action=gallery&value=iolo- sshos-20040810-unfonts.png * http://gnome.or.kr/gallery/screenshots/gnome20040608?full=1 From dax at gurulabs.com Sat Sep 4 04:38:56 2004 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 03 Sep 2004 22:38:56 -0600 Subject: [Fwd: OpenLDAP 2.1 -> Historic] Message-ID: <1094272736.4926.3.camel@mentorng.gurulabs.com> It would be unfortunate if FC3 and RHEL4 (more so) still uses OpenLDAP v2.1. -----Forwarded Message----- From: Kurt D. Zeilenga To: openldap-announce at OpenLDAP.org Subject: OpenLDAP 2.1 -> Historic Date: Fri, 03 Sep 2004 18:30:07 -0700 OpenLDAP Software 2.1 is now considered Historic. Users of OpenLDAP Software 2.1 are encouraged to update to at least latest "stable" release. All Release Engineering activities on the OPENLDAP_REL_ENG_2_1 branch are now official discontinued (they have been informally discontinued for many months). Regards, Kurt From feliciano.matias at free.fr Sat Sep 4 06:32:07 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sat, 04 Sep 2004 08:32:07 +0200 Subject: yum 2.1.0 In-Reply-To: <1094212525.8940.7.camel@gort> References: <1093936591.28867.14.camel@binkley> <20040903100117.GE26676@neu.physik.fu-berlin.de> <1094212525.8940.7.camel@gort> Message-ID: <1094279521.20649.122.camel@one.myworld> Le ven 03/09/2004 ? 13:55, J. Gardner Biggs a ?crit : > On Fri, 2004-09-03 at 12:01 +0200, Axel Thimm wrote: > > On Tue, Aug 31, 2004 at 03:16:31AM -0400, seth vidal wrote: > > > I'm pleased(sorta) to announce yum 2.1.0. This is using the new xml- > > > based repository metadata (http://linux.duke.edu/metadata). > > > > > > NB: THIS CAN ONLY BE USED WITH REPOSITORIES THAT ARE USING THE NEW > > > METADATA FORMAT. THIS WILL NOT WORK WITH OLD-STYLE YUM-ARCH > > > REPOSITORIES. > > > > will a future yum support both legacy yum repos and new-metadata > > repos (I hope it will)? If not could new-yum and old-yum be rearranged > > in such a way as to allow concurrent installs? > -- > > Where can we find info on the new style repos? rpm -q -i -p createrepo-0.3.7-1.noarch.rpm [...] URL : http://linux.duke.edu/metadata/ [...] > And is there a > primer/FAQ on how to set up yum 2.1.x to use them? > > I would love to give this a test! > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From Axel.Thimm at ATrpms.net Sat Sep 4 07:11:56 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 4 Sep 2004 09:11:56 +0200 Subject: rawhide report: 20040903 changes In-Reply-To: <41393086.9070403@togami.com> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> <20040903180752.GA17419@devserv.devel.redhat.com> <41393086.9070403@togami.com> <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> Message-ID: <20040904071156.GB11531@neu.physik.fu-berlin.de> On Fri, Sep 03, 2004 at 11:51:48AM -0600, Dax Kelson wrote: > > xorg-x11-6.7.99.2-2 > > * Thu Aug 12 2004 Mike A. Harris 6.7.99.2-2 > > > > - Added code to the rpm pre script to munge the config file to change the > > "keyboard" driver to "kbd" driver on upgrades, as XOrg no longer supports > > the old "keyboard" driver. > > - Use perl -p -i -e in pre rpm script for all config file munging instead of > > grep and temporary files. > > Did the policy on no perl in RPM pre/post install scripts change? > > There have been many bugzilla bugs filed and fixed over the years > removing perl from rpm scripts. On Fri, Sep 03, 2004 at 05:03:34PM -1000, Warren Togami wrote: > Alan Cox wrote: > > > >>That may be so, but it is impossible to install a modern Red Hat > >>OS without installing perl. Since perl is guaranteed to be > > > > > >Nope. I do it for all my firewalls. rpm -e perl is the highlight of the > >install experience ;) > > It is impossible to not have perl in a minimal rpmbuild environment, so > it should be okay to use it during rpmbuild. That has nothing to do with Dax's remark, build time != install time. And the only only dependencies of rpm-build on perl are on in these times unused perl scripts sitting around having been obsolted by rpm's internal __find_requires/__find_provides. I doubt any modern Red Hat rpm needs these script to be build (if it does in needs an update). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Sat Sep 4 09:32:31 2004 From: notting at redhat.com (Bill Nottingham) Date: Sat, 4 Sep 2004 05:32:31 -0400 Subject: [Fwd: OpenLDAP 2.1 -> Historic] In-Reply-To: <1094272736.4926.3.camel@mentorng.gurulabs.com> References: <1094272736.4926.3.camel@mentorng.gurulabs.com> Message-ID: <20040904093231.GA27245@nostromo.devel.redhat.com> Dax Kelson (dax at gurulabs.com) said: > It would be unfortunate if FC3 and RHEL4 (more so) still uses OpenLDAP > v2.1. [notting at nostromo: ~]$ rpm -q openldap openldap-2.2.13-2 Bill From iago.rubio at hispalinux.es Sat Sep 4 11:05:11 2004 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Sat, 04 Sep 2004 13:05:11 +0200 Subject: yum 2.1.0 In-Reply-To: <1094242730.27009.81.camel@opus.phy.duke.edu> References: <1093936591.28867.14.camel@binkley> <1094242630.26965.8.camel@speedy.iagorubio.net> <1094242730.27009.81.camel@opus.phy.duke.edu> Message-ID: <1094295910.4436.57.camel@speedy.iagorubio.net> On Fri, 2004-09-03 at 22:18, seth vidal wrote: > On Fri, 2004-09-03 at 16:17, Iago Rubio wrote: > > On Tue, 2004-08-31 at 09:16, seth vidal wrote: > > > What needs to be done: > > > - translations > > Attached the spanish one. > > > > Hope this helps. > > Thank you, but the strings in the program are changing quite a bit right > now as there are some explanations that are unfortunately unclear. I should ask you before to start the translation, my fault. > I'll be begging for translations before long though. Ok, please post it here when ready - or feel free to mail me privately - if you need help with the spanish translation. Regards. -- Iago Rubio - GPG Keyserv * pgp.rediris.es id=0x909BD4DD -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Sat Sep 4 11:42:41 2004 From: buildsys at redhat.com (Build System) Date: Sat, 4 Sep 2004 07:42:41 -0400 Subject: rawhide report: 20040904 changes Message-ID: <200409041142.i84BgfG12723@porkchop.devel.redhat.com> Updated Packages: bash-3.0-9 ---------- * Tue Aug 31 2004 Tim Waugh 3.0-9 - Fix ulimits patch from Ulrich Drepper (bug #129800). * Fri Aug 27 2004 Tim Waugh 3.0-8 - Provide support for new limits (bug #129800). * Thu Aug 26 2004 Tim Waugh 3.0-7 - Use upstream patch for last fix. desktop-file-utils-0.8-1 ------------------------ * Fri Sep 03 2004 Mark McLoughlin 0.8-1 - Update to 0.8 dia-0.94-5 ---------- epiphany-1.3.8-0.3.1 -------------------- * Fri Sep 03 2004 Christopher Blizzard - Bump release and rebuild. firstboot-1.3.21-1 ------------------ * Fri Sep 03 2004 Adrian Likins - 1.3.21-1 - more fixes for #131308 gdb-6.1post-1.20040607.28 ------------------------- * Tue Aug 31 2004 Jeff Johnston 1.200400607.28 - Add test case for bugzilla 128618 fix. * Mon Aug 30 2004 Jeff Johnston 1.200400607.27 - Add support for breakpoints in manually loaded/unloaded shared libs. (bugzilla 128618) * Mon Aug 30 2004 Jeff Johnston 1.200400607.26 - Add java inferior call support. gedit-2.7.92-1 -------------- gnome-media-2.7.92-7 -------------------- * Fri Sep 03 2004 Matthias Clasen 2.7.92-7 - Make help button of gstreamer-properties work gnome-session-2.7.91-2 ---------------------- * Fri Sep 03 2004 Ray Strode 2.7.91-2 - Fix from Federico for infamous hanging splash screen problem. (http://bugzilla.gnome.org/show_bug.cgi?id=151664) gnome-vfs2-2.7.92-3 ------------------- * Fri Sep 03 2004 GNOME - 2.7.92-2 - remove mozilla as default browser libuser-0.51.9-1 ---------------- * Tue Aug 31 2004 Miloslav Trmac - 0.51.9-1 - Fix various typos - Document library interfaces - Build all shared libraries with -fPIC (#72536) * Wed Aug 25 2004 Miloslav Trmac - 0.51.8-1 - Update to build with latest autotools and gtk-doc - Update ALL_LINGUAS and POTFILES.in - Rebuild to depend on newer openldap * Mon Jan 26 2004 Dan Walsh 0.51.7-7 - fix is_selinux_enabled call mailman-2.1.5-15 ---------------- * Fri Sep 03 2004 John Dennis 3:2.1.5-15 - fix bug #117615, don't overwrite user modified templates on install made template directory "config noreplace" * Thu Sep 02 2004 John Dennis 3:2.1.5-14 - add comments into the crontab files so users know the /etc/cron.d file is volitile and will edit the right file. Also make the master crontab file "config noreplace" so edits are preserved. mc-4.6.0-18 ----------- * Sat Aug 21 2004 Jakub Jelinek 4.6.0-18 - 3 more quoting omissions in a.in * Sat Aug 21 2004 Jakub Jelinek 4.6.0-17 - fix shell quoting in extfs perl scripts (Leonard den Ottolander, #127973, CAN-2004-0494) * Tue Jun 15 2004 Elliot Lee - rebuilt rpmdb-fedora-2.91-0.20040904 ---------------------------- rwall-0.17-21 ------------- * Tue Jun 15 2004 Elliot Lee - rebuilt * Wed May 12 2004 Phil Knirsch 0.17-20 - Enabled PIE for server and application. - Switch from Copyright to License. * Fri Feb 13 2004 Elliot Lee - rebuilt shared-mime-info-0.15-2 ----------------------- * Fri Sep 03 2004 Alexander Larsson - 0.15-2 - Add list of default apps (#131643) system-config-network-1.3.20-1 ------------------------------ * Fri Sep 03 2004 Harald Hoyer - 1.3.20 - dhcp cannot be selected for aliased devices (bug 129096) system-config-printer-0.6.111-1 ------------------------------- * Fri Sep 03 2004 Tim Waugh 0.6.111-1 - 0.6.111: - More robust printer make/model matching for remove-local (bug #131434). udev-030-20 ----------- * Fri Sep 03 2004 Harald Hoyer - 030-20 - due to -x added to MAKEDEV specify the par and lp numbers * Fri Sep 03 2004 Harald Hoyer - 030-19 - added udev-030-rhsec.patch (bug 130351) urw-fonts-2.2-3 --------------- * Fri Sep 03 2004 Than Ngo 2.2-3 - own %{_datadir}/fonts/default #131648 * Tue Jun 15 2004 Elliot Lee - rebuilt xorg-x11-6.7.99.903-5 --------------------- * Thu Sep 02 2004 Bill Nottingham 6.7.99.903-5 - bump release again * Tue Aug 31 2004 Mike A. Harris 6.7.99.903-4 - Bump release field and rebuild unmodified to handle an off-by-one error in release field of font-utils subpackage dependancy * Tue Aug 31 2004 Mike A. Harris 6.7.99.903-3 - Enable "#define HasDevRandom YES" in host-$arch.def for bug (#126205) - Remove driver list overrides for all architectures except ia64, as ppc was missing the "nv" driver. In the future, we will use patches to the Imake config directory to disable individual drivers on particular architectures. - Disable building of fonts by setting with_fonts 0, as we now provide the fonts from a separate src.rpm which builds noarch packages, so that we no longer regenerate fonts every single X build, and people do not have to redownload fonts every single xorg-x11 update when the fonts never change anyway. - Added xorg-x11-6.8.0-Imake-add-BuildFontDevelUtils-macro.patch to allow building and inclusion of ucs2any and bdftruncate when doing "with_fonts 0" builds, as "BuildFonts NO" causes these utils to be excluded. - Change main package dependancy from xorg-x11-base-fonts to base-fonts which is a virtual provide in both the xorg-x11-base-fonts and fonts-xorg-base packages now, to maximize install/upgrade compatibility. - Moved "ucs2any" from the xorg-x11-tools subpackage to the font-utils subpackage where it belongs, and added a Conflicts line to the font-utils package to handle upgrades. - Moved "fonts/util" subdir from xorg-x11-base-fonts, to font-utils package, as the utilities that use it reside there, and it never made sense in the base-fonts package anyway really. Added Conflicts line to font-utils to handle upgrades. yelp-2.6.2-2 ------------ * Fri Sep 03 2004 Matthias Clasen 2.6.2-2 - fix an translation problem yum-2.1.3-1 ----------- * Fri Sep 03 2004 Bill Nottingham - 2.1.3-1 - 2.1.3 From dragoran at feuerpokemon.de Sat Sep 4 11:55:06 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 04 Sep 2004 13:55:06 +0200 Subject: FC3test2 candidate tree In-Reply-To: References: Message-ID: <4139AD1A.5080509@feuerpokemon.de> Elliot Lee schrieb: >Hi all, > >I've just started uploading the latest "release candidate" for FC3test2. >This is __________________NOT__________________ the final FC3test2 tree. >If you're interested in helping with testing for the FC3test2 milestone, >wait until it finishes uploading (there's 39G still to go, but hopefully >it will be done by tomorrow). > >Right now we're down to "no broken dependencies" and "might install". >You'll have to find out for yourself. :-) > >Especially useful would be reports on installs from CD or DVD. Unlike >rawhide, this tree has all the .iso images. > >Where to get it when it's uploaded? >http://fedora.linux.duke.edu/FC3-re0903.0/ > >Cheers, >-- Elliot >The daring is in the doing > >http://people.redhat.com/sopwith/ > > > > 8 disks??? From jakub at redhat.com Sat Sep 4 12:05:19 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 4 Sep 2004 08:05:19 -0400 Subject: FC3test2 candidate tree In-Reply-To: <4139AD1A.5080509@feuerpokemon.de> References: <4139AD1A.5080509@feuerpokemon.de> Message-ID: <20040904120519.GA398@devserv.devel.redhat.com> On Sat, Sep 04, 2004 at 01:55:06PM +0200, dragoran wrote: > >Where to get it when it's uploaded? > >http://fedora.linux.duke.edu/FC3-re0903.0/ > 8 disks??? 5-8 are SRPMS. Jakub From fedora at wir-sind-cool.org Sat Sep 4 12:15:58 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 4 Sep 2004 14:15:58 +0200 Subject: rawhide report: 20040903 changes In-Reply-To: References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <1094233908.5087.7.camel@mentorng.gurulabs.com> Message-ID: <20040904141558.02ce8b51.fedora@wir-sind-cool.org> On Fri, 3 Sep 2004 13:59:36 -0400 (EDT), Mike A. Harris wrote: > >Did the policy on no perl in RPM pre/post install scripts change? > The perl code present now, replaces some very ugly sed code which > used temporary files. I see no compelling technical reason to > not use perl. "sed -i" is one reason, albeit impossible with Red Hat Enterprise Linux 2.x or Red Hat Linux <= 8.0 -- Fedora Core release 1 (Yarrow) - Linux 2.4.22-1.2199.nptl loadavg: 0.19 0.22 0.11 From linux_4ever at yahoo.com Sat Sep 4 13:36:53 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 4 Sep 2004 06:36:53 -0700 (PDT) Subject: FC3test2 candidate tree In-Reply-To: <4139AD1A.5080509@feuerpokemon.de> Message-ID: <20040904133653.62488.qmail@web50610.mail.yahoo.com> >Hi all, > >I've just started uploading the latest "release candidate" for FC3test2. This is interesting. util-linux does not compile as is. It must be patches to link against ltermcap since slang requires it. cfdisk is what complains. Also, the latest glibc-kernheaders breaks gpm since it provides its own input struct definitions. Kudzu is also broken because it uses "byte" as a datatype which seems to be missing now. I typedef'd byte from unsigned char to fix this. My question...how does mach mysteriously fixup these bugs when the srpms clearly do not compile? Just curious... -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From buildsys at redhat.com Sat Sep 4 20:06:36 2004 From: buildsys at redhat.com (Build System) Date: Sat, 4 Sep 2004 16:06:36 -0400 Subject: rawhide report: 20040902 changes Message-ID: <200409042006.i84K6aB32279@porkchop.devel.redhat.com> From cra at WPI.EDU Sat Sep 4 21:25:49 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sat, 4 Sep 2004 17:25:49 -0400 Subject: yum 2.1.3 - development repomd.xml incorrect comps.xml location In-Reply-To: <1094203340.11651.65.camel@binkley> References: <1094203340.11651.65.camel@binkley> Message-ID: <20040904212549.GA22366@angus.ind.WPI.EDU> I'm trying to install a group with yum-2.1.3 on the FC3test2 candidate tree, but it seems that the repomd.xml in the rawhide/development tree points to the wrong location of comps.xml: d41d8cd98f00b204e9800998ecf8427e 1094288733 yum.conf: [development] name=Fedora Core $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ server listing: lftp download.fedora.redhat.com:/pub/fedora/linux/core/development/i386/repodata> dir drwxr-xr-x -- / drwxr-xr-x - 2004-09-04 07:31 .. -rw-r--r-- 473k 2004-09-04 05:05 comps.xml -rw-r--r-- 2.8M 2004-09-04 07:31 filelists.xml.gz -rw-r--r-- 5.4M 2004-09-04 07:31 other.xml.gz -rw-r--r-- 943k 2004-09-04 07:31 primary.xml.gz -rw-r--r-- 1k 2004-09-04 07:31 repomd.xml From veguilla at hpcf.upr.edu Sat Sep 4 22:04:24 2004 From: veguilla at hpcf.upr.edu (Ricardo Veguilla) Date: Sat, 04 Sep 2004 18:04:24 -0400 Subject: dev rpm update problem Message-ID: <1094335465.4561.50.camel@ricardo.veguilla.net> I get this error when updating to dev-3.11-1: Cannot install the dev package: mounted devfs detected. error: %pre(dev-3.11-1) scriptlet failed, exit status 1 error: install: %pre scriptlet failed (2), skipping dev-3.11-1 I know this was happening previously with the MAKEDEV rpm, but it seems like it was solved in that case (by removing the %pre script?). Anyway, how do I upgrade the package? Is this a bug? -- Ricardo Veguilla From alexander.dalloz at uni-bielefeld.de Sat Sep 4 22:34:04 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Sun, 05 Sep 2004 00:34:04 +0200 Subject: Sendmail 8.13.x socketmap support Message-ID: <1094337244.3881.579.camel@serendipity.dogma.lan> Hi! Is there a reason why current rawhide Sendmail has no socketmap support compiled in? socketmap is one of the improvements from version 8.13.x. I wonder a bit, because the changelog has following entry: * Do Jul 01 2004 Thomas Woerner 8.13.0-1.1 - fixed init script to not complain missing sendmail-cf package (#126975) - better message in /etc/mail/Makefile for missing sendmail-cf package. - added socketmap support So it claims being compiled with socketmap. But I do not see it in the debug output of Sendmail. Current rawhide Sendmail: sendmail-8.13.1-2 $ sendmail -bt -d0.9 < /dev/null Version 8.13.1 Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF STARTTLS TCPWRAPPERS USERDB USE_LDAP_INIT Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp Serendipity 00:14:01 up 5 days, 21:30, load average: 0.50, 0.76, 0.69 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From bobgus at rcn.com Sun Sep 5 00:39:28 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sat, 4 Sep 2004 19:39:28 -0500 Subject: FC3test2 candidate tree In-Reply-To: <20040904133653.62488.qmail@web50610.mail.yahoo.com> References: <4139AD1A.5080509@feuerpokemon.de> Message-ID: >>Hi all, >> >>I've just started uploading the latest "release candidate" for FC3test2. > >This is interesting. util-linux does not compile as is. It must be patches to >link against ltermcap since slang requires it. cfdisk is what complains. > >Also, the latest glibc-kernheaders breaks gpm since it provides its own input >struct definitions. Kudzu is also broken because it uses "byte" as a datatype >which seems to be missing now. I typedef'd byte from unsigned char to fix >this. > >My question...how does mach mysteriously fixup these bugs when the srpms >clearly >do not compile? > >Just curious... > >-Steve Grubb > Good question. Is there any documentation of the 'process' involved in putting together the "release candidate" What goes in, what is delayed, what machines are used, what compilers (consistent throughout all the rpms?), etc? Are there any tools used to check compatibility (tinderbox?) before inclusion, any theory? Or is it just a slice of rawhide torn off and put into iso images? BobG From paul at dishone.st Sun Sep 5 01:42:26 2004 From: paul at dishone.st (Paul Jakma) Date: Sun, 5 Sep 2004 02:42:26 +0100 (IST) Subject: syslog-ng to replace syslogd In-Reply-To: <1093838519.9616.64.camel@binkley> References: <20040820231547.70155.qmail@web50602.mail.yahoo.com> <1093048550.8229.9.camel@binkley> <1093838519.9616.64.camel@binkley> Message-ID: On Mon, 30 Aug 2004, seth vidal wrote: > Look into epylog for that. Aye, I did. But it doesnt 'know' about as much stuff as logwatch does. > But a syslog daemon that's not 25 yrs old would be a nice fresh start. Possibly. But I'd rather have a bare minimum traditional syslogd rewrite than an all singing, all dancing rewrite whose bells and whistles i'll never use. > -sv regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A Fortune: Kites rise highest against the wind -- not with it. -- Winston Churchill From buildsys at redhat.com Sun Sep 5 11:59:32 2004 From: buildsys at redhat.com (Build System) Date: Sun, 5 Sep 2004 07:59:32 -0400 Subject: rawhide report: 20040905 changes Message-ID: <200409051159.i85BxWs25552@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-2.91-0.20040905 ---------------------------- From ronny-vlug at vlugnet.org Sun Sep 5 16:09:45 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Sun, 5 Sep 2004 18:09:45 +0200 Subject: rawhide report: 20040903 changes In-Reply-To: <20040904141558.02ce8b51.fedora@wir-sind-cool.org> References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> <20040904141558.02ce8b51.fedora@wir-sind-cool.org> Message-ID: <200409051809.45872.ronny-vlug@vlugnet.org> On Saturday 04 September 2004 14:15, Michael Schwendt wrote: > On Fri, 3 Sep 2004 13:59:36 -0400 (EDT), Mike A. Harris wrote: > > >Did the policy on no perl in RPM pre/post install scripts change? > > > > The perl code present now, replaces some very ugly sed code which > > used temporary files. I see no compelling technical reason to > > not use perl. > > "sed -i" is one reason, albeit impossible with Red Hat Enterprise > Linux 2.x or Red Hat Linux <= 8.0 temporary files are the smaller part of the problem the big one is the unpredictable (and very limited) sed regex syntax -- http://LinuxWiki.org/RonnyBuchmann From leonard at den.ottolander.nl Sun Sep 5 12:45:36 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 05 Sep 2004 14:45:36 +0200 Subject: rawhide report: 20040904 changes In-Reply-To: <200409041142.i84BgfG12723@porkchop.devel.redhat.com> References: <200409041142.i84BgfG12723@porkchop.devel.redhat.com> Message-ID: <1094388336.4751.16.camel@athlon.localdomain> Hi Jakub, On Sat, 2004-09-04 at 13:42, Build System wrote: > mc-4.6.0-18 > ----------- > * Sat Aug 21 2004 Jakub Jelinek 4.6.0-18 > > - 3 more quoting omissions in a.in > > * Sat Aug 21 2004 Jakub Jelinek 4.6.0-17 > > - fix shell quoting in extfs perl scripts > (Leonard den Ottolander, #127973, CAN-2004-0494) What's up? rawhide report 20040904 speaks of: mc-4.6.1-0.1 ------------ * Thu Sep 02 2004 Jakub Jelinek 4.6.1-0.1 - update from CVS - handle INFO/LICENSE and INFO/OBSOLETES in rpm vfs (#67341) - remove mc-cvs-unzip (#85073) - fix hotkey handling when not UTF-8 (Leonard den Ottolander, #120735) - allow terminal aliases for keys in mc.lib and ~/mc/ini, add gnome, xterm-new and rxvt aliases for xterm (#128163) I know I asked you to wait with updating to CVS a while, but since we are in testing anyway, it probably doesn't matter that much. I don't expect an update to current CVS to introduce any (new) breakage, so maybe you should push ahead. If not, could you make the 4.6.1 src rpm available somewhere? I've got a few other things to take care of, but I'll try to fix Vladimir's UTF-8 fixes and enhancements this week. Regarding the patches you send me for upstream inclusion, I am busy writing up an answer but have to check a thing or two before I can reply in full. I will send you that answer tonight or tomorrow. And for interested developers: The todo list for 4.6.1 only has two items left: - Tilde not expanding in copy and move dialogs - Broken pipe warning when viewing large *.tar.gz files. Anyone cares to help out with patches for these? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From shockwave at clan-tf20.com Sun Sep 5 19:32:04 2004 From: shockwave at clan-tf20.com (Shockwave) Date: Sun, 05 Sep 2004 15:32:04 -0400 Subject: [FC2] OT - Desert Combat F-16 bug - SOLVED! In-Reply-To: <1094140386.20756.361.camel@aries> References: <1093964289.20756.101.camel@aries> <20040831150306.GY11465@devserv.devel.redhat.com> <1093974587.20756.139.camel@aries> <4134C176.8050301@lanl.gov> <1094055385.20756.252.camel@aries> <4135FF9C.9000703@lanl.gov> <1094074583.20756.293.camel@aries> <413725F3.5040903@lanl.gov> <1094140386.20756.361.camel@aries> Message-ID: <1094412724.20756.440.camel@aries> I've been successful in crafting a fix for this problem and wanted to say thanks to everyone who helped me track down the cause. As it turns out, I don't think it was the 2.6.x kernel, but rather how it responded to an incorrectly formed set of parameters given to it by the game engine. For a more complete discussion of this topic, you can view this post I made in the BF1942 Lightcubed forums: http://bf1942.lightcubed.com/forum/viewtopic.php?t=1866 Thanks again to everyone for the outstanding help! -- |TF20|Shockwave http://www.clan-tf20.com/ ICQ# 57671167 #taskforce20 irc.gamesurge.net From skvidal at phy.duke.edu Mon Sep 6 02:17:14 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Sep 2004 22:17:14 -0400 Subject: Notes on Yum Changes Message-ID: <1094437034.4702.13.camel@binkley> Here are some notes I typed up this weekend on a plane and in a truly dull airport about yum changes in the upcoming test release. Here they are: Making yum repositories now: Yum repositories are no longer created by yum-arch. There is a new program, createrepo (http://linux.duke.edu/metadata/generate), that creates the metadata. The metadata for rpm packages is the information that describes the data stored in the payload of the rpm. createrepo takes the metadata from each rpm in the repository and stores it in an xml format that is simple and expedient to load the data from. This makes it easier and more efficient for yum to resolve dependencies and find out other important information about the packages a user would want to install. To create your own repository install the createrepo rpm and run: create-repo /path/to/the/packages It will recursively go through the directory you specify, find all the rpm packages, and retrieve the pertinent metadata. Once this command completes you should have a directory named 'repodata' created in the directory path you specified on the command line. The repodata directory will contain at least 4 files. They are: repomd.xml - stores the information about the other metadata files. It is a meta-metadata file. :) It has checksums and timestamps for each file of the metadata. primary.xml[.gz] - stores the critical information for listing and dependency solving packages. It is the core of information for the repository and it is normally the smallest of the files containing package metadata. filelists.xml[.gz] - stores the complete file listing for each package. It also contains some information describing the files. It distinguishes between files, directories and ghosted files in the package. other.xml[.gz] - stores any other information that is available from the package. This file is available for completeness and convenience. In particular, this file stores all the changelog information for each package. If you specified the -g option to createrepo and listed a groups file (a comps.xml format file) then this file will also be copied to the repodata directory. Yum Changes: 1. Yum will no longer work with repositories generated with yum-arch. The new format and the old format do not conlict with each other so if you want to run createrepo and yum-arch on a single repository that will work just fine. However, the new yum will not support old-style repositories and there are no plans at this time to make it possible. 2. When specifying packages on the command line and in the exclude lists you can use complete version and arch strings now. In addition to specifying: yum install mypackage you can now also specify: yum install mypackage-1.1 The following version/arch string formats are accepted: name name-ver name-ver-rel name.arch name-ver-rel.arch epoch:name-ver-rel.arch 3. The config file has been enhanced in a number of ways. Inside the config file you can now specify include=url://some/location/file at any point. This allows you to include one config file inside another. The file is included literally, as though typed in place. The include option takes any url that yum is capable of handling (http, https, ftp and file). 4. In addition to the above config change, yum also offers an optional /etc/yum.repos.d directory for configurations. Each file named with a .repo extension will be parsed and added to the set of repositories listed in the yum.conf file. The format of these files is identical to the listing of a repository in the yum.conf file: [repository-id] name=repository name baseurl=url://path/to/repository ... 5. New command line options: --obsoletes - tell yum to include obsoletes in its update processing --enablerepo=repository-id - tell yum to enable the repository of that id this option can be specified multiple times on the command line. This will override the 'enabled' option to a repository in the configuration file. --disablerepo=repository-id - The logical opposite of the above. Other new features will be added and they'll be described in more detail then. This should give users an overview of the major changed items in yum, so far. hope this helps people. -sv From j.w.r.degoede at hhs.nl Mon Sep 6 06:24:56 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 06 Sep 2004 08:24:56 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094437034.4702.13.camel@binkley> References: <1094437034.4702.13.camel@binkley> Message-ID: <413C02B8.4010102@hhs.nl> Hi, I just tried the new yum (from rawhide) and it works great! Much much better then the old stuff, does this mean I can nuke all headers from the yum cache now? Are any livna developers on this list? livna needs to be updated to the new format :), so does macromedia.mplug probably. Regards, Hans From jakub at redhat.com Mon Sep 6 07:27:39 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 6 Sep 2004 03:27:39 -0400 Subject: rawhide report: 20040904 changes In-Reply-To: <1094388336.4751.16.camel@athlon.localdomain> References: <200409041142.i84BgfG12723@porkchop.devel.redhat.com> <1094388336.4751.16.camel@athlon.localdomain> Message-ID: <20040906072739.GA31909@devserv.devel.redhat.com> On Sun, Sep 05, 2004 at 02:45:36PM +0200, Leonard den Ottolander wrote: > Hi Jakub, > > On Sat, 2004-09-04 at 13:42, Build System wrote: > > mc-4.6.0-18 > > ----------- > > What's up? rawhide report 20040904 speaks of: > > mc-4.6.1-0.1 > ------------ mc-4.6.1-0.1 has been moved to fc3-hold, i.e. it won't appear in FC3 test2, but will appear right after it in rawhide. > I know I asked you to wait with updating to CVS a while, but since we > are in testing anyway, it probably doesn't matter that much. I don't > expect an update to current CVS to introduce any (new) breakage, so > maybe you should push ahead. If not, could you make the 4.6.1 src rpm > available somewhere? ftp://people.redhat.com/jakub/mc/ has the src.rpm, though not the binary rpms. It is just rpmbuild --rebuild away though. > I've got a few other things to take care of, but I'll try to fix > Vladimir's UTF-8 fixes and enhancements this week. Thanks. > Regarding the patches you send me for upstream inclusion, I am busy > writing up an answer but have to check a thing or two before I can reply > in full. I will send you that answer tonight or tomorrow. AFAIK Pavel commited most of the small patches. I'll update soon and see what's left, of course the UTF-8 stuff is not in. Jakub From naoki at valuecommerce.com Mon Sep 6 08:07:30 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 06 Sep 2004 17:07:30 +0900 Subject: Notes on Yum Changes In-Reply-To: <413C02B8.4010102@hhs.nl> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> Message-ID: <413C1AC2.4080509@valuecommerce.com> I missed the thread, what happened to 'upgrade' ? From wtogami at redhat.com Mon Sep 6 08:59:19 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 05 Sep 2004 22:59:19 -1000 Subject: Strangest Bug Report... Message-ID: <413C26E7.2020307@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127369 If you are going to waste Red Hat's resources and time by filing stupid joke reports like this, at least have the courtesy to convert it Theora format first. Warren Togami wtogami at redhat.com From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Sep 6 09:18:15 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 6 Sep 2004 11:18:15 +0200 Subject: FC3test2 candidate tree In-Reply-To: <20040904133653.62488.qmail@web50610.mail.yahoo.com> References: <4139AD1A.5080509@feuerpokemon.de> <20040904133653.62488.qmail@web50610.mail.yahoo.com> Message-ID: <20040906111815.61d18153@localhost> Steve G wrote : > This is interesting. util-linux does not compile as is. It must be > patches to link against ltermcap since slang requires it. cfdisk is what > complains. > > Also, the latest glibc-kernheaders breaks gpm since it provides its own > input struct definitions. Kudzu is also broken because it uses "byte" as > a datatype which seems to be missing now. I typedef'd byte from unsigned > char to fix this. > > My question...how does mach mysteriously fixup these bugs when the srpms > clearly do not compile? > > Just curious... AFAIK, the distribution isn't "bootstrapped" (rebuilt entirely using itself as the build host), but instead assembled from packages built all along the development cycle, rebuilt only for updates, bug fixes or to pick up new dependencies. So for now, it's clearly a good idea to try and rebuild the test release "on itself" and report any breakage like you've found to the list, or better, to bugzilla. Then there is the day when there will be a well defined and accepted minimal set of build packages... a small step for rpm-kind, but a huge step for build reproducibility :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.33 0.29 0.44 From twaugh at redhat.com Mon Sep 6 10:41:52 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 6 Sep 2004 11:41:52 +0100 Subject: FC3test2 candidate tree In-Reply-To: <20040906111815.61d18153@localhost> References: <4139AD1A.5080509@feuerpokemon.de> <20040904133653.62488.qmail@web50610.mail.yahoo.com> <20040906111815.61d18153@localhost> Message-ID: <20040906104152.GG32028@redhat.com> On Mon, Sep 06, 2004 at 11:18:15AM +0200, Matthias Saou wrote: > AFAIK, the distribution isn't "bootstrapped" (rebuilt entirely using itself > as the build host), but instead assembled from packages built all along the > development cycle, rebuilt only for updates, bug fixes or to pick up new > dependencies. So for now, it's clearly a good idea to try and rebuild the > test release "on itself" and report any breakage like you've found to the > list, or better, to bugzilla. In theory we do this automatically, but these "mass rebuild test" runs seem to be broken at the moment. :-( Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jorton at redhat.com Mon Sep 6 11:01:07 2004 From: jorton at redhat.com (Joe Orton) Date: Mon, 6 Sep 2004 12:01:07 +0100 Subject: FC3test2 candidate tree In-Reply-To: References: Message-ID: <20040906110107.GA3128@redhat.com> On Fri, Sep 03, 2004 at 05:58:55PM -0400, Elliot Lee wrote: > Hi all, > > I've just started uploading the latest "release candidate" for FC3test2. > This is __________________NOT__________________ the final FC3test2 tree. > If you're interested in helping with testing for the FC3test2 milestone, > wait until it finishes uploading (there's 39G still to go, but hopefully > it will be done by tomorrow). With a kickstart install I don't get IPv4 configured on boot up, it looks like dhclient was being run but doing nothing. Anyone else see anything like that? I can use the system over IPv6 for only a short while after boot before the kernel dies from #131706. joe From leonard at den.ottolander.nl Mon Sep 6 10:17:26 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 06 Sep 2004 12:17:26 +0200 Subject: rawhide report: 20040904 changes In-Reply-To: <20040906072739.GA31909@devserv.devel.redhat.com> References: <200409041142.i84BgfG12723@porkchop.devel.redhat.com> <1094388336.4751.16.camel@athlon.localdomain> <20040906072739.GA31909@devserv.devel.redhat.com> Message-ID: <1094465846.4751.19.camel@athlon.localdomain> On Mon, 2004-09-06 at 09:27, Jakub Jelinek wrote: > > If not, could you make the 4.6.1 src rpm available somewhere? > > ftp://people.redhat.com/jakub/mc/ > has the src.rpm, though not the binary rpms. It is just rpmbuild --rebuild > away though. I'm familiar with the process of rebuilding of rpms ;-p . Anyway, the request is for the src rpm since I need to make sure "my" patches patch against this version (probably no serious issues here as we probably work with CVS versions that are only off by a few days). > AFAIK Pavel commited most of the small patches. > I'll update soon and see what's left, of course the UTF-8 stuff is not in. The patches in http://www.ottolander.nl/mc-patches/fc1/full/ are now all committed or in the pipeline. There is *only* http://www.ottolander.nl/mc-patches/fc1/jumbo.parts/mc-4.6.0-jumbo.rest-same.patch that needs to be looked at. It could well be all this is covered in your smallpatches.patch. I've double checked that all other parts are either committed or in the pipeline. No need to look, but if you insist... :) Leonard. -- mount -t life -o ro /dev/dna /genetic/research From linux_4ever at yahoo.com Mon Sep 6 12:09:18 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 6 Sep 2004 05:09:18 -0700 (PDT) Subject: FC3test2 candidate tree In-Reply-To: <20040906104152.GG32028@redhat.com> Message-ID: <20040906120918.87800.qmail@web50606.mail.yahoo.com> >> AFAIK, the distribution isn't "bootstrapped" (rebuilt entirely using itself >> as the build host), I kind of determined this empirically. It doesn't build from itself, therefore, Red Hat is not shipping binaries that is built from the actually shipping copy of all the srpms. This is bad news for any group that needs the ability to rebuild a distribution to prove they have the complete set of source and can re-create it if they ever needed to; or prove there are no 3rd party add-ons/hacks. (There are govt institutions that require this.) >> but instead assembled from packages built all along the development cycle, >> rebuilt only for updates, bug fixes or to pick up new dependencies. I would have hoped that a "release" is built from itself so that *everything* matches. There are programs that are statically linked to glibc/dietlibc/slang/newt that may have bugs fixed in a subsequent release. >> So for now, it's clearly a good idea to try and rebuild the >> test release "on itself" and report any breakage like you've found to the >> list, or better, to bugzilla. >From my own study of the packages, these PR's in bugzilla keep it from building against itself: 127526, 129946, 130717, 131780, 131783, 131841 I think there are more that I haven't filed yet. >In theory we do this automatically, but these "mass rebuild test" runs >seem to be broken at the moment. :-( I am only tracking 200 or so packages that you would use for a console based server distribution. I've submitted over 75 patches to fix just those 200. I would venture to say it would take a lot of work to get anything in the X world to build cleanly. This is mostly due to the shear number of packages involved. It really is important to be able to re-create a distribution from the shipped srpms. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mk at crc.dk Mon Sep 6 12:31:55 2004 From: mk at crc.dk (Mogens Kjaer) Date: Mon, 06 Sep 2004 14:31:55 +0200 Subject: FC2 Grub raid problem, long standing.. In-Reply-To: <20040903161809.7fa891cd@pro8000x.aurox.org> References: <1094217396.8146.19.camel@linux.local> <41387191.9090206@crc.dk> <20040903161809.7fa891cd@pro8000x.aurox.org> Message-ID: <413C58BB.7060504@crc.dk> Jaroslaw Gorny wrote: ... > With all respect: it's a little bit weird advice because Lilo is not > supported very well (You cannot choose lilo during install) and we/you > are promoting grub as default. You can select lilo during installation if you boot the installation with "linux lilo". Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From buildsys at redhat.com Mon Sep 6 13:01:54 2004 From: buildsys at redhat.com (Build System) Date: Mon, 6 Sep 2004 09:01:54 -0400 Subject: rawhide report: 20040906 changes Message-ID: <200409061301.i86D1sV01771@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.8-1.540 ------------------ rpmdb-fedora-2.91-0.20040906 ---------------------------- From peter.backlund at home.se Mon Sep 6 13:26:20 2004 From: peter.backlund at home.se (Peter Backlund) Date: Mon, 06 Sep 2004 15:26:20 +0200 Subject: Eclipse? Message-ID: <1094477180.3378.4.camel@h65n2fls33o1121.telia.com> Hello. Any news on the Eclipse front? That is, how far away is it from Rawhide? Note that I'm talking about the native version. Also, I never got any response on why gcj35/libgcj35 isn't being built along with th rest of the gcc35 packages? Regards, Peter Backlund -- Peter Backlund From jakub at redhat.com Mon Sep 6 13:36:26 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 6 Sep 2004 09:36:26 -0400 Subject: Eclipse? In-Reply-To: <1094477180.3378.4.camel@h65n2fls33o1121.telia.com> References: <1094477180.3378.4.camel@h65n2fls33o1121.telia.com> Message-ID: <20040906133626.GE31909@devserv.devel.redhat.com> On Mon, Sep 06, 2004 at 03:26:20PM +0200, Peter Backlund wrote: > Hello. > > > Any news on the Eclipse front? That is, how far away is it from Rawhide? > Note that I'm talking about the native version. > > Also, I never got any response on why gcj35/libgcj35 isn't being built > along with th rest of the gcc35 packages? Because gcj-3.4*/libgcj-3.4* should be good enough for eclipse/ant/whatever other gcj using package. GCJ 3.5 is ATM known to be binary incompatible with both GCJ 3.4 and with the final GCJ 3.5, so including it is IMHO a bad idea. gcc35/g++35 uses the 3.4.2-RH headers/libraries, so it doesn't have such problem. Jakub From marcel at mesa.nl Mon Sep 6 13:50:48 2004 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Mon, 6 Sep 2004 15:50:48 +0200 Subject: rawhide report: 20040906 changes In-Reply-To: <200409061301.i86D1sV01771@porkchop.devel.redhat.com> References: <200409061301.i86D1sV01771@porkchop.devel.redhat.com> Message-ID: <20040906135048.GA29940@joshua.mesa.nl> On Mon, Sep 06, 2004 at 09:01:54AM -0400, Build System wrote: > > Updated Packages: > > kernel-2.6.8-1.540 > ------------------ Funny just an hour ago I downloaded: 38308686 Sep 2 00:16 kernel-2.6.8-1.541.src.rpm -Marcel -- ======-------- Marcel J.E. Mol MESA Consulting B.V. =======--------- ph. +31-(0)6-54724868 P.O. Box 112 =======--------- marcel at mesa.nl 2630 AC Nootdorp __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ They couldn't think of a number, Linux user 1148 -- counter.li.org so they gave me a name! -- Rupert Hine -- www.ruperthine.com From arjanv at redhat.com Mon Sep 6 13:53:16 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 06 Sep 2004 15:53:16 +0200 Subject: rawhide report: 20040906 changes In-Reply-To: <200409061301.i86D1sV01771@porkchop.devel.redhat.com> References: <200409061301.i86D1sV01771@porkchop.devel.redhat.com> Message-ID: <1094478796.2799.11.camel@laptop.fenrus.com> On Mon, 2004-09-06 at 15:01, Build System wrote: > > > Updated Packages: > > kernel-2.6.8-1.540 > ------------------ fwiw the kernel went backwards in revision due to the corruption reports about 541; 540 has the online resize patch disabled which is one of the two main suspects. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From icon at linux.duke.edu Mon Sep 6 12:48:41 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Mon, 06 Sep 2004 08:48:41 -0400 Subject: Notes on Yum Changes In-Reply-To: <413C1AC2.4080509@valuecommerce.com> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> Message-ID: <1094474921.10563.22.camel@fleur.hogwarts.jk> On Mon, 2004-09-06 at 17:07 +0900, Naoki wrote: > I missed the thread, what happened to 'upgrade' ? yum --obsoletes update Regards, -- Konstantin ("Icon") Riabitsev Duke University Physics Sysadmin From skvidal at phy.duke.edu Mon Sep 6 14:04:12 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Sep 2004 10:04:12 -0400 Subject: Notes on Yum Changes In-Reply-To: <413C02B8.4010102@hhs.nl> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> Message-ID: <1094479452.4702.19.camel@binkley> On Mon, 2004-09-06 at 08:24 +0200, Hans de Goede wrote: > Hi, > > I just tried the new yum (from rawhide) and it works great! Much much > better then the old stuff, does this mean I can nuke all headers from > the yum cache now? sure. > Are any livna developers on this list? livna needs to be updated to the > new format :), so does macromedia.mplug probably. > livna has the repodata. -sv From j.w.r.degoede at hhs.nl Mon Sep 6 15:06:50 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 06 Sep 2004 17:06:50 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094479452.4702.19.camel@binkley> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <1094479452.4702.19.camel@binkley> Message-ID: <413C7D0A.8050204@hhs.nl> seth vidal wrote: > On Mon, 2004-09-06 at 08:24 +0200, Hans de Goede wrote: > >>Hi, >> >>I just tried the new yum (from rawhide) and it works great! Much much >>better then the old stuff, does this mean I can nuke all headers from >>the yum cache now? > > > sure. > EXCELLENT! > > > >>Are any livna developers on this list? livna needs to be updated to the >>new format :), so does macromedia.mplug probably. >> > > > livna has the repodata. > > -sv > Since when? yesterday I got an error (using the 2.90 tree) Regards, Hans From rms at 1407.org Mon Sep 6 15:32:26 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 06 Sep 2004 16:32:26 +0100 Subject: Notes on Yum Changes In-Reply-To: <1094474921.10563.22.camel@fleur.hogwarts.jk> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> Message-ID: <1094484746.2635.42.camel@roque> On Mon, 2004-09-06 at 08:48 -0400, Konstantin Ryabitsev wrote: > On Mon, 2004-09-06 at 17:07 +0900, Naoki wrote: > > I missed the thread, what happened to 'upgrade' ? > > yum --obsoletes update I honestly fail to understand why this isn't the default. Yum has improved _definitely_a_lot_, it works much better on mirrors (and in the past it used to fail horribly and constantly due to mirror misbehaviour). But IMHO it places a lot of decisions on the enduser, failing in a scary way when bad things happen. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Sep 3 18:01:25 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 03 Sep 2004 20:01:25 +0200 Subject: rawhide report: 20040903 changes In-Reply-To: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> (Build System's message of "Fri, 3 Sep 2004 08:17:49 -0400") References: <200409031217.i83CHnY22247@porkchop.devel.redhat.com> Message-ID: <87acw7dyfe.fsf@kosh.ultra.csn.tu-chemnitz.de> buildsys at redhat.com (Build System) writes: > xorg-x11-6.7.99.2-2 > ------------------- > * Thu Aug 12 2004 Mike A. Harris 6.7.99.2-2 > ... > - Use perl -p -i -e in pre rpm script for all config file munging instead of > grep and temporary files. FWIW: the shipped 'sed' supports an '-i' option also... Enrico From jkeating at j2solutions.net Mon Sep 6 17:11:51 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 6 Sep 2004 10:11:51 -0700 Subject: ia32e, er EM64T that is... Message-ID: <200409061011.52742.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What are the chances of getting an ia32e specific kernel in the x86_64 version of Fedora Core 3? We're starting to ship Nacona based systems, and we have always done Fedora Core pre-installs. While the x86_64 kernel of FC2 works now, I thought it was in some sort of 'compatible 64bit' mode rather than ia32e or em64t specific mode. I guess a better question: With kernel 2.6, is there any need to have a specific ia32e vs amd64 kernel? Are all the differences worked out at runtime and thus a non-issue? Thanks. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBPJpX4v2HLvE71NURAgLOAJ41i+nTykxeQlOs+SG0Lxu297RM/gCfQ30X DzP7D/wWGZN0T8LiXAlZFpY= =7oGl -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Mon Sep 6 17:14:17 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Sep 2004 13:14:17 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094484746.2635.42.camel@roque> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> Message-ID: <1094490857.4702.29.camel@binkley> On Mon, 2004-09-06 at 16:32 +0100, Rui Miguel Seabra wrote: > On Mon, 2004-09-06 at 08:48 -0400, Konstantin Ryabitsev wrote: > > On Mon, 2004-09-06 at 17:07 +0900, Naoki wrote: > > > I missed the thread, what happened to 'upgrade' ? > > > > yum --obsoletes update > > I honestly fail to understand why this isn't the default. > > Yum has improved _definitely_a_lot_, it works much better on mirrors > (and in the past it used to fail horribly and constantly due to mirror > misbehaviour). > > But IMHO it places a lot of decisions on the enduser, failing in a scary > way when bad things happen. > osboletes can be what you set if you want. just set obsoletes=1 in the [main] section of your yum.conf however obsoletes should not be the default b/c of circular obsoletes. ie: foo obsoletes bar baz osboletes foo bar obsoletes baz and if you don't think that happens, look around, it definitely does. -sv From arjanv at redhat.com Mon Sep 6 17:21:19 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 06 Sep 2004 19:21:19 +0200 Subject: ia32e, er EM64T that is... In-Reply-To: <200409061011.52742.jkeating@j2solutions.net> References: <200409061011.52742.jkeating@j2solutions.net> Message-ID: <1094491279.8750.1.camel@laptop.fenrus.com> On Mon, 2004-09-06 at 19:11, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > What are the chances of getting an ia32e specific kernel in the x86_64 > version of Fedora Core 3? We're starting to ship Nacona based systems, > and we have always done Fedora Core pre-installs. While the x86_64 > kernel of FC2 works now, I thought it was in some sort of 'compatible > 64bit' mode rather than ia32e or em64t specific mode. > > I guess a better question: With kernel 2.6, is there any need to have a > specific ia32e vs amd64 kernel? Are all the differences worked out at > runtime and thus a non-issue? it's all runtime. The extra amd64 instructions are patched in at runtime no problem.... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Mon Sep 6 17:47:17 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Sep 2004 13:47:17 -0400 Subject: ia32e, er EM64T that is... In-Reply-To: <200409061011.52742.jkeating@j2solutions.net> References: <200409061011.52742.jkeating@j2solutions.net> Message-ID: <20040906174717.GA11888@devserv.devel.redhat.com> On Mon, Sep 06, 2004 at 10:11:51AM -0700, Jesse Keating wrote: > I guess a better question: With kernel 2.6, is there any need to have a > specific ia32e vs amd64 kernel? Are all the differences worked out at > runtime and thus a non-issue? Thanks. em64t as Intel currently call it is pretty close to the x86-64 architecture so its not too bad a clone. It lacks prefetch/prefetchw which can also be used by some fancy user space stuff like image processors. It also lacks a hardware IOMMU so you may have performance problems going above about 3.5Gb of RAM depending on your other hardware. Alan From shfukuzawa at jcom.home.ne.jp Mon Sep 6 14:46:23 2004 From: shfukuzawa at jcom.home.ne.jp (Shun Fukuzawa) Date: Mon, 06 Sep 2004 23:46:23 +0900 Subject: Self Introduction: Shun Fukuzawa Message-ID: <413C783F.2020102@jcom.home.ne.jp> Hello everyone. This is my introducing mail. 1.My leagal name Shun Fukuzawa (first name - family name) 2.Address Tokyo, Japan 3.Profeccional SE for SAP (but only businness...) 4.Company Tores Tores (small japanese company) 5.Your goals in the Fedora Project *Which packages do you want to see published? Kazehakase(Smart web browser made in Japan) http://kazehakase.sourceforge.jp/ Gimageview(Image and Vidoe viewer http://www.homa.ne.jp/~ashie/gimageview/index.html.en As possible, UIM(Universal input method) etc. *Do you want to do QA? Yes *Anything else special? I am a staff of fedora.jp(Japanese local community for Fedora Core). I want to translate documents to Japanese. 6.Historical qualifications *What other projects have you worked on in the past? I am a staff of Mozilla-Gumi(Japanese local community for Mozilla) and I conducted 5th Mozilla Party in Japan ( http://www.mozillazine.org/talkback.html?article=4504 ). And I am a document writer of Kazehakase, the web browser. Kazehakase is small opensource project. But Kazehakase is smart and excellent browser. This softwere is already included in Debian, Gentoo and other distributions. *What computer languages and other skills do you know? ABAP(for business), ruby(for private). I wrote Mozilla's manual in Japanese. 7.GPG KEYID and fingerprint gpg --fingerprint B8736A31 pub 1024D/B8736A31 2004-09-06 Shun Fukuzawa Key fingerprint = FA8A 9BDB B1AD CAED BE5B C204 E856 03CC B873 6A31 sub 1024g/7B8BCE5C 2004-09-06 Thanks! From rms at 1407.org Mon Sep 6 19:04:06 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 06 Sep 2004 20:04:06 +0100 Subject: Notes on Yum Changes In-Reply-To: <1094490857.4702.29.camel@binkley> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> Message-ID: <1094497446.2670.10.camel@roque> On Mon, 2004-09-06 at 13:14 -0400, seth vidal wrote: > On Mon, 2004-09-06 at 16:32 +0100, Rui Miguel Seabra wrote: > > On Mon, 2004-09-06 at 08:48 -0400, Konstantin Ryabitsev wrote: > > > On Mon, 2004-09-06 at 17:07 +0900, Naoki wrote: > > > > I missed the thread, what happened to 'upgrade' ? > > > > > > yum --obsoletes update > > > > I honestly fail to understand why this isn't the default. > > osboletes can be what you set if you want. > > just set obsoletes=1 in the [main] section of your yum.conf Oh, I've already done that. I just think it should be the default. > however obsoletes should not be the default b/c of circular obsoletes. > ie: > foo obsoletes bar > baz osboletes foo > bar obsoletes baz > > and if you don't think that happens, look around, it definitely does. Well, I thought there was a process for package submission, review and what not. Of course accidents happen. But this is no excuse, or is a "meta packager" like yum not better than plain rpm in itself? As far as I can see, I have to solve about as many problems as I did without a metapackager (--obsoletes, --exclude=..., etc...). The job of a meta packager is making things easier. My praise was precisely that yum has had a giant step towards this goal, but there are definitely corners to round. Anyway, loops are not that hard to find, just mark where you've been previously (prolog 101) and handle apropriately (ie, until repo fixes it, I can't do anything that touches foo, bar or baz, may I proceed with the rest?). Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From shiva at sewingwitch.com Mon Sep 6 18:49:16 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 06 Sep 2004 11:49:16 -0700 Subject: Strangest Bug Report... In-Reply-To: <413C26E7.2020307@redhat.com> References: <413C26E7.2020307@redhat.com> Message-ID: --On Sunday, September 05, 2004 10:59 PM -1000 Warren Togami wrote: > If you are going to waste Red Hat's resources and time by filing stupid > joke reports like this, at least have the courtesy to convert it Theora > format first. Hehe, got me to look up Theora! http://www.theora.org/ >From the FAQ: Theora is an open video codec being developed by the Xiph.org Foundation as part of their Ogg project (It is a project that aims to integrate On2's VP3 video codec, Ogg Vorbis audio codec and Ogg multimedia container formats into a multimedia solution that can compete with MPEG-4 format). Theora is derived directly from On2's VP3 codec; currently the two are nearly identical, varying only in framing headers, but Theora will diverge and improve from the main VP3 development lineage as time progresses. From rms at 1407.org Mon Sep 6 19:55:51 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 06 Sep 2004 20:55:51 +0100 Subject: Notes on Yum Changes In-Reply-To: <1094497446.2670.10.camel@roque> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> Message-ID: <1094500551.3630.0.camel@roque> On Mon, 2004-09-06 at 20:04 +0100, Rui Miguel Seabra wrote: > Well, I thought there was a process for package submission, review and > what not. Of course accidents happen. But this is no excuse, or is a > "meta packager" like yum not better than plain rpm in itself? > > As far as I can see, I have to solve about as many problems as I did > without a metapackager (--obsoletes, --exclude=..., etc...). The job of > a meta packager is making things easier. This is, of course, assuming I already have the RPMS. The automatic download of what's needed saves me a lot of time! Thanks! Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kyrre at solution-forge.net Mon Sep 6 19:56:35 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 06 Sep 2004 21:56:35 +0200 Subject: Strangest Bug Report... In-Reply-To: References: <413C26E7.2020307@redhat.com> Message-ID: <1094500594.28275.13.camel@kyrre> man, 06.09.2004 kl. 20.49 skrev Kenneth Porter: > --On Sunday, September 05, 2004 10:59 PM -1000 Warren Togami > wrote: > > > If you are going to waste Red Hat's resources and time by filing stupid > > joke reports like this, at least have the courtesy to convert it Theora > > format first. > > Hehe, got me to look up Theora! > > http://www.theora.org/ > > >From the FAQ: > > Theora is an open video codec being developed by the Xiph.org Foundation as > part of their Ogg project (It is a project that aims to integrate On2's VP3 > video codec, Ogg Vorbis audio codec and Ogg multimedia container formats > into a multimedia solution that can compete with MPEG-4 format). > Theora is derived directly from On2's VP3 codec; currently the two are > nearly identical, varying only in framing headers, but Theora will diverge > and improve from the main VP3 development lineage as time progresses. > > Isn't that planned to be in FC3 (helix player)? From kyrre at solution-forge.net Mon Sep 6 19:38:49 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 06 Sep 2004 21:38:49 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094497446.2670.10.camel@roque> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> Message-ID: <1094499528.28275.11.camel@kyrre> man, 06.09.2004 kl. 21.04 skrev Rui Miguel Seabra: > On Mon, 2004-09-06 at 13:14 -0400, seth vidal wrote: > > On Mon, 2004-09-06 at 16:32 +0100, Rui Miguel Seabra wrote: > > > On Mon, 2004-09-06 at 08:48 -0400, Konstantin Ryabitsev wrote: > > > > On Mon, 2004-09-06 at 17:07 +0900, Naoki wrote: > > > > > I missed the thread, what happened to 'upgrade' ? > > > > > > > > yum --obsoletes update > > > > > > I honestly fail to understand why this isn't the default. > > > > osboletes can be what you set if you want. > > > > just set obsoletes=1 in the [main] section of your yum.conf > > Oh, I've already done that. I just think it should be the default. > > > however obsoletes should not be the default b/c of circular obsoletes. > > ie: > > foo obsoletes bar > > baz osboletes foo > > bar obsoletes baz > > > > and if you don't think that happens, look around, it definitely does. > > Well, I thought there was a process for package submission, review and > what not. Of course accidents happen. But this is no excuse, or is a > "meta packager" like yum not better than plain rpm in itself? > > As far as I can see, I have to solve about as many problems as I did > without a metapackager (--obsoletes, --exclude=..., etc...). The job of > a meta packager is making things easier. > > My praise was precisely that yum has had a giant step towards this goal, > but there are definitely corners to round. > > Anyway, loops are not that hard to find, just mark where you've been > previously (prolog 101) and handle apropriately (ie, until repo fixes > it, I can't do anything that touches foo, bar or baz, may I proceed with > the rest?). Yup, ran into that when running "daily yum update" on a network, and discovered that "xmms-mp3" (installed from apt) blocked "xmms", and when xmms couldn't be upgraded, there is no reason to even try with the rest, right? > > Rui But this looks cool! Is there any plans for integrating rpm with yum - so that rpm would ask "you need dependancy foo, bar, baz.so in order to install this package, shall i ask yum to fetch them for you? (y/n)" BTW. Guess i forgot to introduce my self: My name is Kyrre Ness Sj?b?k, and i come from Norway, where i go to "high-school" (think that is the closest matching term - probably university next year) and also helps rolling out/maintaining Linux on my school, while feeling pity for the windows-guy who dont have any good scripting tools at hand... I know some programming (a bit of that and another bit of that), but that is probably not what i'm best at. I think i mostly joined this list in order to "see whats going on", but if there is anything i might help out with, ill be glad. Kyrre Ness Sj?b?k From feliciano.matias at free.fr Mon Sep 6 20:42:13 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Mon, 06 Sep 2004 22:42:13 +0200 Subject: Strangest Bug Report... In-Reply-To: <1094500594.28275.13.camel@kyrre> References: <413C26E7.2020307@redhat.com> <1094500594.28275.13.camel@kyrre> Message-ID: <1094503329.1061.1.camel@one.myworld> Le lun 06/09/2004 ? 21:56, Kyrre Ness Sjobak a ?crit : > > Isn't that planned to be in FC3 (helix player)? > helix player and gstreamer. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From shiva at sewingwitch.com Mon Sep 6 18:37:13 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 06 Sep 2004 11:37:13 -0700 Subject: Notes on Yum Changes In-Reply-To: <1094437034.4702.13.camel@binkley> References: <1094437034.4702.13.camel@binkley> Message-ID: --On Sunday, September 05, 2004 10:17 PM -0400 seth vidal wrote: > 1. Yum will no longer work with repositories generated with yum-arch. > The new format and the old format do not conlict with each other so > if you want to run createrepo and yum-arch on a single repository > that will work just fine. However, the new yum will not support > old-style repositories and there are no plans at this time to make > it possible. Which well-known repositories have the new metadata? Fedora base, update, development, testing? Dag? AT? From kyrre at solution-forge.net Mon Sep 6 20:52:15 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 06 Sep 2004 22:52:15 +0200 Subject: Strangest Bug Report... In-Reply-To: <1094503329.1061.1.camel@one.myworld> References: <413C26E7.2020307@redhat.com> <1094500594.28275.13.camel@kyrre> <1094503329.1061.1.camel@one.myworld> Message-ID: <1094503935.28275.16.camel@kyrre> man, 06.09.2004 kl. 22.42 skrev Matias Feliciano: > Le lun 06/09/2004 ? 21:56, Kyrre Ness Sjobak a ?crit : > > > > Isn't that planned to be in FC3 (helix player)? > > > > helix player and gstreamer. But.. gstreamer... That is the gnome audio/video framework, right? What do you mean? Will (does) helix utilize gstreamer? *confused* Where can i find more info? > > ______________________________________________________________________ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From veguilla at hpcf.upr.edu Mon Sep 6 20:59:44 2004 From: veguilla at hpcf.upr.edu (Ricardo Veguilla) Date: Mon, 06 Sep 2004 16:59:44 -0400 Subject: Notes on Yum Changes In-Reply-To: References: <1094437034.4702.13.camel@binkley> Message-ID: <1094504385.7130.0.camel@ricardo.veguilla.net> On Mon, 2004-09-06 at 11:37 -0700, Kenneth Porter wrote: > --On Sunday, September 05, 2004 10:17 PM -0400 seth vidal > wrote: > > > 1. Yum will no longer work with repositories generated with yum-arch. > > The new format and the old format do not conlict with each other so > > if you want to run createrepo and yum-arch on a single repository > > that will work just fine. However, the new yum will not support > > old-style repositories and there are no plans at this time to make > > it possible. > > Which well-known repositories have the new metadata? Fedora base, update, > development, testing? Dag? AT? > Both Dag and Freshrpms are using the new metadata. -- Ricardo Veguilla From rms at 1407.org Mon Sep 6 21:23:19 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 06 Sep 2004 22:23:19 +0100 Subject: Notes on Yum Changes In-Reply-To: <1094499528.28275.11.camel@kyrre> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> Message-ID: <1094505799.3630.8.camel@roque> On Mon, 2004-09-06 at 21:38 +0200, Kyrre Ness Sjobak wrote: > Is there any plans for integrating rpm with yum - so that rpm would ask > "you need dependancy foo, bar, baz.so in order to install this package, > shall i ask yum to fetch them for you? (y/n)" I wouldn't expect it to ever happen, since rpm is the base where yum works on :) > BTW. Guess i forgot to introduce my self: Welcome :) Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Sep 6 21:23:36 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Sep 2004 17:23:36 -0400 Subject: Strangest Bug Report... In-Reply-To: <1094503935.28275.16.camel@kyrre> References: <413C26E7.2020307@redhat.com> <1094500594.28275.13.camel@kyrre> <1094503329.1061.1.camel@one.myworld> <1094503935.28275.16.camel@kyrre> Message-ID: <20040906212336.GA24940@nostromo.devel.redhat.com> Kyrre Ness Sjobak (kyrre at solution-forge.net) said: > But.. gstreamer... That is the gnome audio/video framework, right? What > do you mean? Will (does) helix utilize gstreamer? HelixPlayer does not currently use gstreamer. Bill From elanthis at awesomeplay.com Mon Sep 6 21:26:35 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 06 Sep 2004 17:26:35 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094499528.28275.11.camel@kyrre> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> Message-ID: <1094505995.4720.1.camel@stargrazer> On Mon, 2004-09-06 at 21:38 +0200, Kyrre Ness Sjobak wrote: > Is there any plans for integrating rpm with yum - so that rpm would ask > "you need dependancy foo, bar, baz.so in order to install this package, > shall i ask yum to fetch them for you? (y/n)" Instead of integrating yum into rpm, just use a tool (such as yum itself) to install your packages instead of rpm. I don't know offhand if yum already supports this, but if not, it should. ;-) The graphical tools like system-install-packages and friends should also then integrate with yum. I'm sure the maintainers will accept patches for such a feature. ;-) From jspaleta at gmail.com Mon Sep 6 22:32:46 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 6 Sep 2004 18:32:46 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094497446.2670.10.camel@roque> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> Message-ID: <604aa791040906153254fca564@mail.gmail.com> On Mon, 06 Sep 2004 20:04:06 +0100, Rui Miguel Seabra wrote: > > just set obsoletes=1 in the [main] section of your yum.conf > > Oh, I've already done that. I just think it should be the default. I disagree. I would suggest instead of obsoletes being on by default that if yum can detect an situation wher an obsolete operation could be performaed when a conflict is detected yum should inform the user in some way that activating obsoletes might be worth trying to resolve the conflict ,becuase one of the invovled packages in the conflict has non-empty obsolete tags. > Well, I thought there was a process for package submission, review and > what not. Of course accidents happen. But this is no excuse, or is a > "meta packager" like yum not better than plain rpm in itself? Whose to say all the possible obsoleting loop situations are accidents? > As far as I can see, I have to solve about as many problems as I did > without a metapackager (--obsoletes, --exclude=..., etc...). The job of > a meta packager is making things easier. Are you talking about your experience with development and test releases specifically, because if you are.. no tool is going to make insanity of the development tree...sane. Test releases eat babies... the development tree more so. Easier...for clearly logical situations. Package tools should not take action in ill-defined situations such as repository self-consistency problems where excludes are needed. It is arguable whether obsoletes as a class are ill-defined, circular and/or chains of obsoletes definitely are. > Anyway, loops are not that hard to find, just mark where you've been > previously (prolog 101) and handle apropriately (ie, until repo fixes > it, I can't do anything that touches foo, bar or baz, may I proceed with > the rest?). I do not see how this is helpful overall. Are you suggesting yum hide repository side problems from users by default? How is that helpful in resolving those repository side problems? The safe thing to do, by default, is when an error is encountered to inform the user of the error and quit so that the user can decide to take appropriate action. Automating a loop that actives excludes for conflicts or dependancy errors does nothing but help users ignore problems, instead of reporting them. -jef From feliciano.matias at free.fr Mon Sep 6 22:11:25 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Tue, 07 Sep 2004 00:11:25 +0200 Subject: Strangest Bug Report... In-Reply-To: <1094503935.28275.16.camel@kyrre> References: <413C26E7.2020307@redhat.com> <1094500594.28275.13.camel@kyrre> <1094503329.1061.1.camel@one.myworld> <1094503935.28275.16.camel@kyrre> Message-ID: <1094508681.1044.14.camel@one.myworld> Le lun 06/09/2004 ? 22:52, Kyrre Ness Sjobak a ?crit : > man, 06.09.2004 kl. 22.42 skrev Matias Feliciano: > > Le lun 06/09/2004 ? 21:56, Kyrre Ness Sjobak a ?crit : > > > > > > Isn't that planned to be in FC3 (helix player)? > > > > > > > helix player and gstreamer. > > But.. gstreamer... That is the gnome audio/video framework, right? Right. $ rpm -q --requires gstreamer-plugins | grep theora libtheora.so.0 $ rpm -q -i --whatprovides libtheora.so.0 Name : libtheora Relocations: (not relocatable) [...] Summary : Theora Video Compression Codec [...] # rpm -q -l HelixPlayer | grep -i theo /usr/lib/helix/plugins/theorarend.so > What > do you mean? Will (does) helix utilize gstreamer? > No. And gstreamer does not use helix. > *confused* > > Where can i find more info? rpmdb :-) > > > > ______________________________________________________________________ > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From skvidal at phy.duke.edu Mon Sep 6 23:03:05 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Sep 2004 19:03:05 -0400 Subject: Notes on Yum Changes In-Reply-To: <604aa791040906153254fca564@mail.gmail.com> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <604aa791040906153254fca564@mail.gmail.com> Message-ID: <1094511785.4702.54.camel@binkley> On Mon, 2004-09-06 at 18:32 -0400, Jeff Spaleta wrote: > On Mon, 06 Sep 2004 20:04:06 +0100, Rui Miguel Seabra wrote: > > > just set obsoletes=1 in the [main] section of your yum.conf > > > > Oh, I've already done that. I just think it should be the default. > > I disagree. I would suggest instead of obsoletes being on by default > that if yum can detect an situation wher an obsolete operation could > be performaed when a conflict is detected yum should inform the user > in some way that activating obsoletes might be worth trying to resolve > the conflict ,becuase one of the invovled packages in the conflict has > non-empty obsolete tags. if one package obsoletes the other it's noted in the transaction by rpm. So two conflicting packages that obsolete each other should be acknowledged. The problem in the case of rawhide recently was that pkg1 obsoleted pkg2 but pkg2 was also up for an update. so without the obsoletes in the calculation pkg1 was never even being looked at but the new pkgs were conflicting. > Easier...for clearly logical situations. Package tools should not take > action in ill-defined situations such as repository self-consistency > problems where excludes are needed. > It is arguable whether obsoletes as a class are ill-defined, circular > and/or chains of obsoletes definitely are. This is why I've added the --obsoletes argument so the user can take these actions on their own. Additionally the 'list obsoletes' option is new. So you can see what from a repository will obsolete something on your system. The output is not as good right now, it's on my short list to make prettier. -sv From skvidal at phy.duke.edu Tue Sep 7 00:00:39 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Sep 2004 20:00:39 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094505995.4720.1.camel@stargrazer> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> Message-ID: <1094515239.4702.79.camel@binkley> On Mon, 2004-09-06 at 17:26 -0400, Sean Middleditch wrote: > On Mon, 2004-09-06 at 21:38 +0200, Kyrre Ness Sjobak wrote: > > > Is there any plans for integrating rpm with yum - so that rpm would ask > > "you need dependancy foo, bar, baz.so in order to install this package, > > shall i ask yum to fetch them for you? (y/n)" > > Instead of integrating yum into rpm, just use a tool (such as yum > itself) to install your packages instead of rpm. I don't know offhand > if yum already supports this, but if not, it should. ;-) > > The graphical tools like system-install-packages and friends should also > then integrate with yum. > > I'm sure the maintainers will accept patches for such a feature. ;-) The question becomes how to do this sensibly. yum install /some/path/to/an/rpm that's possible except I get an equal number of requests for: yum install /some/file/that/some/package/in/a/repository/provides. it's not impossible to check for but it means searching harder. the biggest limitation is time. I'm one guy. -sv From skvidal at phy.duke.edu Mon Sep 6 23:45:25 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Sep 2004 19:45:25 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094497446.2670.10.camel@roque> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> Message-ID: <1094514325.4702.67.camel@binkley> > Well, I thought there was a process for package submission, review and > what not. Of course accidents happen. But this is no excuse, or is a > "meta packager" like yum not better than plain rpm in itself? > As far as I can see, I have to solve about as many problems as I did > without a metapackager (--obsoletes, --exclude=..., etc...). The job of > a meta packager is making things easier. it's not the job of the metapackagers to let potentially serious problems go unseen. That's ridiculous. That's like saying: My kernel shouldn't scream at me about hard drive failures, it should quietly let them happen. if there is a potential conflict that can't really be resolved, prompt the user. > Anyway, loops are not that hard to find, just mark where you've been > previously (prolog 101) and handle apropriately (ie, until repo fixes > it, I can't do anything that touches foo, bar or baz, may I proceed with > the rest?). okay then define the procedure. Set up the standard for handling mutual obsoleting packages and updates. you write up the process for what has to occur and get EVERYONE to agree on it and I'll write the code. -sv From leonard at den.ottolander.nl Tue Sep 7 00:25:51 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 07 Sep 2004 02:25:51 +0200 Subject: Browsable source/patch/SPEC tree Message-ID: <1094516751.4756.91.camel@athlon.localdomain> Hi, When will we see a browsable source/patch/SPEC tree for all released srpms, so I don't have to download bloody xorg-x11.src.rpm just to have a peek at the current SPEC file? Just a tree with all packages, where every maintainer keeps his/her source, SPEC and patches for every version (s)he releases. Hard links could be used where appropriate (large tarballs and unmodified patches). Would be very useful, especially during development phases. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From skvidal at phy.duke.edu Mon Sep 6 23:47:51 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Sep 2004 19:47:51 -0400 Subject: Notes on Yum Changes In-Reply-To: <413C7D0A.8050204@hhs.nl> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <1094479452.4702.19.camel@binkley> <413C7D0A.8050204@hhs.nl> Message-ID: <1094514471.4702.69.camel@binkley> > Since when? yesterday I got an error (using the 2.90 tree) > since a few days ago. http://rpm.livna.org/fedora/2/i386/RPMS.stable/ -sv From jspaleta at gmail.com Tue Sep 7 01:56:44 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 6 Sep 2004 21:56:44 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094514471.4702.69.camel@binkley> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <1094479452.4702.19.camel@binkley> <413C7D0A.8050204@hhs.nl> <1094514471.4702.69.camel@binkley> Message-ID: <604aa79104090618566bc2d82c@mail.gmail.com> On Mon, 06 Sep 2004 19:47:51 -0400, seth vidal wrote: > > Since when? yesterday I got an error (using the 2.90 tree) > > > > since a few days ago. > http://rpm.livna.org/fedora/2/i386/RPMS.stable/ ah... he's trying to use 2.90 tree.. which doesnt even actually exist. -jef"move along...nothing to see here"spaleta From naoki at valuecommerce.com Tue Sep 7 03:02:52 2004 From: naoki at valuecommerce.com (Naoki) Date: Tue, 07 Sep 2004 12:02:52 +0900 Subject: rpm error message, some more detail would be nice. Message-ID: <413D24DC.9040204@valuecommerce.com> When doing something with rpm that should really be done as root could it please say for example "error: can't create transaction lock, do you need to be root", or maybe a permission problem message instead of : $ rpm -e kernel-2.6.5-1.358 kernel-2.6.8-1.541 error: can't create transaction lock How would I formally request a more useful error message? For the first half second I think, "huh, what's wrong", half a second after that I throw a 'sudo' in front of it. -n. From katzj at redhat.com Tue Sep 7 03:11:53 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Sep 2004 23:11:53 -0400 Subject: FC3test2 candidate tree In-Reply-To: <20040906120918.87800.qmail@web50606.mail.yahoo.com> References: <20040906120918.87800.qmail@web50606.mail.yahoo.com> Message-ID: <1094526713.3727.65.camel@bree.local.net> On Mon, 2004-09-06 at 05:09 -0700, Steve G wrote: > >> AFAIK, the distribution isn't "bootstrapped" (rebuilt entirely using itself > >> as the build host), > > I kind of determined this empirically. It doesn't build from itself, therefore, > Red Hat is not shipping binaries that is built from the actually shipping copy of > all the srpms. This is bad news for any group that needs the ability to rebuild a > distribution to prove they have the complete set of source and can re-create it > if they ever needed to; or prove there are no 3rd party add-ons/hacks. (There are > govt institutions that require this.) In the past, we ran rebuild tests regularly and fixed these sorts of things up until late in the cycle. Some of that infrastructure breaks from time to time, though. Filing bugs about "foo doesn't rebuild" are useful and then they should (hopefully) get fixed. > >> but instead assembled from packages built all along the development cycle, > >> rebuilt only for updates, bug fixes or to pick up new dependencies. > > I would have hoped that a "release" is built from itself so that *everything* > matches. There are programs that are statically linked to > glibc/dietlibc/slang/newt that may have bugs fixed in a subsequent release. If you do this, then you lose a lot of the benefit of any earlier testing. Although it'd be nice to believe that a rebuild with a newer compiler or whatnot won't change anything, the fact of the matter is that you may trip over new bugs in the build chain. Thus, if everything got rebuilt at the last minute, there'd be no way to sanely test and QA the distribution. Jeremy From jspaleta at gmail.com Tue Sep 7 03:14:44 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 6 Sep 2004 23:14:44 -0400 Subject: rpm error message, some more detail would be nice. In-Reply-To: <413D24DC.9040204@valuecommerce.com> References: <413D24DC.9040204@valuecommerce.com> Message-ID: <604aa79104090620145b2287c2@mail.gmail.com> On Tue, 07 Sep 2004 12:02:52 +0900, Naoki wrote: > When doing something with rpm that should really be done as root could > it please say for example > "error: can't create transaction lock, do you need to be root", or maybe > a permission problem message instead of : > > $ rpm -e kernel-2.6.5-1.358 kernel-2.6.8-1.541 > error: can't create transaction lock Doesn't this assume that ALL transaction lock problems are permissions related? Can you assume that? Does rpm have the capability to inherently know that its a permission problem? Can you assume that every rpm installation in use requires root? -jef"goes off to play with his self-compiled rpm installation he uses with a normal user account on a system where he doesn't have full adminstration access, but where he has to manage a subset of specialized software for a small group of users inside the 1000+ userbase of the large system"spaleta From katzj at redhat.com Tue Sep 7 03:21:02 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Sep 2004 23:21:02 -0400 Subject: FC3test2 candidate tree In-Reply-To: References: Message-ID: <1094527262.3727.67.camel@bree.local.net> On Fri, 2004-09-03 at 17:58 -0400, Elliot Lee wrote: > Right now we're down to "no broken dependencies" and "might install". > You'll have to find out for yourself. :-) > > Especially useful would be reports on installs from CD or DVD. Unlike > rawhide, this tree has all the .iso images. > > Where to get it when it's uploaded? > http://fedora.linux.duke.edu/FC3-re0903.0/ ... Where to reports bugs/problems? http://bugzilla.redhat.com/bugzilla/ I can't stress enough that this is the only way for problems to be actively tracked by developers. With the amount of mail received each day, if a problem reports comes in via just mail, it's virtually guaranteed to be forgotten about if it's not something that can be fixed at a glance. Jeremy From bos at serpentine.com Tue Sep 7 05:44:47 2004 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon, 06 Sep 2004 22:44:47 -0700 Subject: ia32e, er EM64T that is... In-Reply-To: <20040906174717.GA11888@devserv.devel.redhat.com> References: <200409061011.52742.jkeating@j2solutions.net> <20040906174717.GA11888@devserv.devel.redhat.com> Message-ID: <1094535887.21939.10.camel@camp4.serpentine.com> On Mon, 2004-09-06 at 13:47 -0400, Alan Cox wrote: > em64t as Intel currently call it is pretty close to the x86-64 architecture > so its not too bad a clone. It lacks prefetch/prefetchw which can also be > used by some fancy user space stuff like image processors. Er, EM64T provides the SSE prefetch{nta,t[012]} instructions, which are somewhat more expressive than prefetch anyway, and which also run on AMD chips. Shame about the lack of a prefetchw analogue, but it's hardly a surprise that Intel isn't implementing 3dnow. References: <413D24DC.9040204@valuecommerce.com> <604aa79104090620145b2287c2@mail.gmail.com> Message-ID: <1094536924.3569.6.camel@dragon.sys.intra> On Mon, 2004-09-06 at 23:14 -0400, Jeff Spaleta wrote: > On Tue, 07 Sep 2004 12:02:52 +0900, Naoki wrote: > > When doing something with rpm that should really be done as root could > > it please say for example > > "error: can't create transaction lock, do you need to be root", or maybe > > a permission problem message instead of : > > > > $ rpm -e kernel-2.6.5-1.358 kernel-2.6.8-1.541 > > error: can't create transaction lock > > Doesn't this assume that ALL transaction lock problems are permissions related? > Can you assume that? Does rpm have the capability to inherently know > that its a permission problem? Can you assume that every rpm > installation in use requires root? Yeah, I thought about this as well and decided that a 'normal' user just wouldn't ever work out what a transaction lock was. I don't care what the error is message or even if there is one because I know how to use 'strace'. Also considering the error is pretty obvious in it's cause : open("/var/lock/rpm/transaction", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied) It might make sense and help the average joe if we can tell them it's a permission problem. -n. From pmatilai at welho.com Tue Sep 7 05:24:44 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 07 Sep 2004 08:24:44 +0300 Subject: Notes on Yum Changes In-Reply-To: <1094515239.4702.79.camel@binkley> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> Message-ID: <1094534684.16965.3.camel@chip.laiskiainen.org> On Tue, 2004-09-07 at 03:00, seth vidal wrote: > On Mon, 2004-09-06 at 17:26 -0400, Sean Middleditch wrote: > > On Mon, 2004-09-06 at 21:38 +0200, Kyrre Ness Sjobak wrote: > > > > > Is there any plans for integrating rpm with yum - so that rpm would ask > > > "you need dependancy foo, bar, baz.so in order to install this package, > > > shall i ask yum to fetch them for you? (y/n)" > > > > Instead of integrating yum into rpm, just use a tool (such as yum > > itself) to install your packages instead of rpm. I don't know offhand > > if yum already supports this, but if not, it should. ;-) > > > > The graphical tools like system-install-packages and friends should also > > then integrate with yum. > > > > I'm sure the maintainers will accept patches for such a feature. ;-) > > The question becomes how to do this sensibly. > > yum install /some/path/to/an/rpm > > that's possible > > except I get an equal number of requests for: > > yum install /some/file/that/some/package/in/a/repository/provides. > > it's not impossible to check for but it means searching harder. Might be harder to search for but that IS an awfully nice and useful feature. - Panu - From jakub at redhat.com Tue Sep 7 06:37:02 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 7 Sep 2004 02:37:02 -0400 Subject: ia32e, er EM64T that is... In-Reply-To: <1094535887.21939.10.camel@camp4.serpentine.com> References: <200409061011.52742.jkeating@j2solutions.net> <20040906174717.GA11888@devserv.devel.redhat.com> <1094535887.21939.10.camel@camp4.serpentine.com> Message-ID: <20040907063702.GJ31909@devserv.devel.redhat.com> On Mon, Sep 06, 2004 at 10:44:47PM -0700, Bryan O'Sullivan wrote: > On Mon, 2004-09-06 at 13:47 -0400, Alan Cox wrote: > > > em64t as Intel currently call it is pretty close to the x86-64 architecture > > so its not too bad a clone. It lacks prefetch/prefetchw which can also be > > used by some fancy user space stuff like image processors. > > Er, EM64T provides the SSE prefetch{nta,t[012]} instructions, which are > somewhat more expressive than prefetch anyway, and which also run on AMD Somewhat more and somewhat less expressive to be exact. SSE prefetches allow you to specify locality very well, 3dNOW prefetch allows prefetching for write, but no locality. If GCC knows both SSE and 3dNOW prefetches are available, it will use 3dNOW prefetch for __builtin_prefetch (p, 1, [0-3]) (and disregard the locality) and SSE prefetch for __builtin_prefetch (p, 0, [0-3]) (where locality is used). > chips. Shame about the lack of a prefetchw analogue, but it's hardly a > surprise that Intel isn't implementing 3dnow. Jakub From j.w.r.degoede at hhs.nl Tue Sep 7 07:15:16 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 07 Sep 2004 09:15:16 +0200 Subject: Notes on Yum Changes In-Reply-To: <604aa79104090618566bc2d82c@mail.gmail.com> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <1094479452.4702.19.camel@binkley> <413C7D0A.8050204@hhs.nl> <1094514471.4702.69.camel@binkley> <604aa79104090618566bc2d82c@mail.gmail.com> Message-ID: <413D6004.90106@hhs.nl> Jeff Spaleta wrote: > On Mon, 06 Sep 2004 19:47:51 -0400, seth vidal wrote: > >>>Since when? yesterday I got an error (using the 2.90 tree) >>> >> >>since a few days ago. >>http://rpm.livna.org/fedora/2/i386/RPMS.stable/ > > > ah... he's trying to use 2.90 tree.. which doesnt even actually exist. > > -jef"move along...nothing to see here"spaleta > Ehm Oops that was a mistake I was ofcourse using the 2 tree, since as you say there is no 2.90 tree :) But the probem was that I was using: baseurl=http://rpm.livna.org/fedora/2/$basearch/yum/stable Instead of: baseurl=http://rpm.livna.org/fedora/2/$basearch/RPMS.stable This because when I made my yum.conf livna hadn't move to the new naming scheme yet. Thanks for showing me the problem. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From rms at 1407.org Tue Sep 7 07:21:23 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 07 Sep 2004 08:21:23 +0100 Subject: Notes on Yum Changes In-Reply-To: <1094514325.4702.67.camel@binkley> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094514325.4702.67.camel@binkley> Message-ID: <1094541683.3630.25.camel@roque> On Mon, 2004-09-06 at 19:45 -0400, seth vidal wrote: > > Well, I thought there was a process for package submission, review and > > what not. Of course accidents happen. But this is no excuse, or is a > > "meta packager" like yum not better than plain rpm in itself? > > > As far as I can see, I have to solve about as many problems as I did > > without a metapackager (--obsoletes, --exclude=..., etc...). The job of > > a meta packager is making things easier. > > it's not the job of the metapackagers to let potentially serious > problems go unseen. That's ridiculous. What do you think of a security update that doesn't update because there's a bug in an unrelated package? How "potentially serious" a problem would that be? The job of a metapackager is making updating easier, not harder just as hard as if it wasn't there. > That's like saying: My kernel shouldn't scream at me about hard drive > failures, it should quietly let them happen. I fail to see a resemblance. I'm saying to not touch with the problematic packages but try to keep on with the rest, if possible. There would be a resemblance if I was saying to install even if it screamed of a problem... > if there is a potential conflict that can't really be resolved, prompt > the user. Yum doesn't prompt. Barfs. You could be right if it did, but _it_doesn't_. You can handle it. Fine. I can handle it. Fine. But is it satisfying the purpose? > > Anyway, loops are not that hard to find, just mark where you've been > > previously (prolog 101) and handle apropriately (ie, until repo fixes > > it, I can't do anything that touches foo, bar or baz, may I proceed with > > the rest?). > > okay then define the procedure. Set up the standard for handling mutual > obsoleting packages and updates. > > you write up the process for what has to occur and get EVERYONE to agree > on it and I'll write the code. In a very highlevel way, I already did, wouldn't you say so? You simple mark where you've been so far (and where you have had problems), and check for those marks at each package. A mutual obsolete is just another kind of loop. There's no need to deny it from the start like you seem to be doing. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From russell at coker.com.au Tue Sep 7 08:12:39 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 7 Sep 2004 18:12:39 +1000 Subject: FC2 Problem possibly related to selinux In-Reply-To: <1094053095.5669.6.camel@linux.local> References: <1094052902.5669.3.camel@linux.local> <1094053095.5669.6.camel@linux.local> Message-ID: <200409071812.39406.russell@coker.com.au> On Thu, 2 Sep 2004 01:38, Hans Kristian Rosbach wrote: > > The interesting problem now is that I can no longer > > get a login prompt on the consoles. SSH works just > > fine, but the console is stuck at starting Postfix. > > Never seems to finish. > > Forgot to paste this: > > # ps ax > -snip- > 1562 ? S 0:00 /bin/sh /etc/rc3.d/S80postfix start > 1565 ? R 1311:00 /usr/sbin/postalias /etc/postfix/aliases > -snip- > > "audit2allow -l -i /var/log/messages" no longer gives me any more > rules to apply. Why do you think it's a SE Linux issue? Does the problem go away if you boot in permissive mode? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From hk at isphuset.no Tue Sep 7 08:18:38 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Tue, 07 Sep 2004 10:18:38 +0200 Subject: FC2 Problem possibly related to selinux In-Reply-To: <200409071812.39406.russell@coker.com.au> References: <1094052902.5669.3.camel@linux.local> <1094053095.5669.6.camel@linux.local> <200409071812.39406.russell@coker.com.au> Message-ID: <1094545118.17186.10.camel@linux.local> On Tue, 2004-09-07 at 10:12, Russell Coker wrote: > On Thu, 2 Sep 2004 01:38, Hans Kristian Rosbach wrote: > > > The interesting problem now is that I can no longer > > > get a login prompt on the consoles. SSH works just > > > fine, but the console is stuck at starting Postfix. > > > Never seems to finish. > > > > Forgot to paste this: > > > > # ps ax > > -snip- > > 1562 ? S 0:00 /bin/sh /etc/rc3.d/S80postfix start > > 1565 ? R 1311:00 /usr/sbin/postalias /etc/postfix/aliases > > -snip- > > > > "audit2allow -l -i /var/log/messages" no longer gives me any more > > rules to apply. > > Why do you think it's a SE Linux issue? > > Does the problem go away if you boot in permissive mode? Well, I found a workaround.. it was to remove the postmaster service in rc.3. It seems that "postalias aliases" or something will not finish, it just hangs forever. Thats why I couldn't get to the console. It also hangs if run manually as root with sysadmin rights. The reason for thinking it is a selinux problem is because we have not had this problem with the exact same install and post-install script on ~15 other computers not running selinux. I have no hard evidence. -HK From feliciano.matias at free.fr Tue Sep 7 08:25:17 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Tue, 07 Sep 2004 10:25:17 +0200 Subject: rpm error message, some more detail would be nice. In-Reply-To: <1094536924.3569.6.camel@dragon.sys.intra> References: <413D24DC.9040204@valuecommerce.com> <604aa79104090620145b2287c2@mail.gmail.com> <1094536924.3569.6.camel@dragon.sys.intra> Message-ID: <1094545517.1044.28.camel@one.myworld> Le mar 07/09/2004 ? 08:02, Naoki a ?crit : > It might make sense and help the average joe if we can tell them it's a > permission problem. > I don't think the average joe use rpm. They use system-config-packages or yum. [average_joe at here average_joe] yum install tata ... You need to be root to perform these commands -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From thomas at apestaart.org Tue Sep 7 08:47:44 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 07 Sep 2004 10:47:44 +0200 Subject: Strangest Bug Report... In-Reply-To: <1094503935.28275.16.camel@kyrre> References: <413C26E7.2020307@redhat.com> <1094500594.28275.13.camel@kyrre> <1094503329.1061.1.camel@one.myworld> <1094503935.28275.16.camel@kyrre> Message-ID: <1094546864.2714.18.camel@otto.amantes> Hi, > But.. gstreamer... That is the gnome audio/video framework, right? Nope. It is a multimedia framework, yes, and it is adopted by GNOME, yes. But it's not "the gnome framework". It's actually on freedesktop atm. > What > do you mean? Will (does) helix utilize gstreamer? It doesn't, and I'd be very surprised if it ever did. Incidentally, does anyone of the redhat guys know if helixplayer was put into fedora because of the realplayer contract for the redhat distros ? Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Well baby let me shake it If I can move it with you will you let me take it <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From alan at redhat.com Tue Sep 7 09:58:36 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 7 Sep 2004 05:58:36 -0400 Subject: ia32e, er EM64T that is... In-Reply-To: <1094535887.21939.10.camel@camp4.serpentine.com> References: <200409061011.52742.jkeating@j2solutions.net> <20040906174717.GA11888@devserv.devel.redhat.com> <1094535887.21939.10.camel@camp4.serpentine.com> Message-ID: <20040907095836.GB20945@devserv.devel.redhat.com> On Mon, Sep 06, 2004 at 10:44:47PM -0700, Bryan O'Sullivan wrote: > On Mon, 2004-09-06 at 13:47 -0400, Alan Cox wrote: > > > em64t as Intel currently call it is pretty close to the x86-64 architecture > > so its not too bad a clone. It lacks prefetch/prefetchw which can also be > > used by some fancy user space stuff like image processors. > > Er, EM64T provides the SSE prefetch{nta,t[012]} instructions, which are > somewhat more expressive than prefetch anyway, and which also run on AMD > chips. Shame about the lack of a prefetchw analogue, but it's hardly a > surprise that Intel isn't implementing 3dnow. x86-64 requires prefetch/prefetchw. It's in the specification. Alan From ufo at linux.net.mk Tue Sep 7 11:09:26 2004 From: ufo at linux.net.mk (Arangel Angov) Date: Tue, 07 Sep 2004 13:09:26 +0200 Subject: test Message-ID: <413D96E6.9000502@linux.net.mk> testing From linux_4ever at yahoo.com Tue Sep 7 12:01:37 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 7 Sep 2004 05:01:37 -0700 (PDT) Subject: rpm error message, some more detail would be nice. In-Reply-To: <604aa79104090620145b2287c2@mail.gmail.com> Message-ID: <20040907120137.37635.qmail@web50603.mail.yahoo.com> >> $ rpm -e kernel-2.6.5-1.358 kernel-2.6.8-1.541 >> error: can't create transaction lock >Doesn't this assume that ALL transaction lock problems are permissions related? No. There are a variety of reasons why this might fail. There's more than one value for errno returned. >Does rpm have the capability to inherently know that its a permission problem? errno is set, its just a matter of using it in the error message. >Can you assume that every rpm installation in use requires root? This is actually a good point. rpm should check the uid to see if its root. If not print a warning that there may be permission problems and re-run as root to avoid this warning. This patch has been on my todo list for a while. -Steve Grubb _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From leonard at den.ottolander.nl Tue Sep 7 12:05:02 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 07 Sep 2004 14:05:02 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094541683.3630.25.camel@roque> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094514325.4702.67.camel@binkley> <1094541683.3630.25.camel@roque> Message-ID: <1094558702.4751.27.camel@athlon.localdomain> Hi Rui, On Tue, 2004-09-07 at 09:21, Rui Miguel Seabra wrote: > What do you think of a security update that doesn't update because > there's a bug in an unrelated package? Firstly the fact that it interferes makes it related. Secondly it was pointed out by more than one user that hiding details about conflicts from the user (by skipping such packages) is probably worse than erroring out with a message. > How "potentially serious" a problem would that be? The user should have noticed there's a problem from the warnings (s)he received. If (s)he can't deal with those (s)he shouldn't be using multiple repos in the first place. > The job of a metapackager is making updating easier, not harder just as > hard as if it wasn't there. As pointed out the metapackager can not be expected to handle conflicts if no standard on which all the repositories (and users) agree is defined on how to do so. In case of your above example, how should yum know it needs to skip the package that holds the obsoletes, and not the package for which a security update is released? > There would be a resemblance if I was saying to install even if it > screamed of a problem... Well that is sort of what you suggest above. Install security update even though there is a conflict and skip the other package. I still don't see how that could solve a circular obsoletes by the way. > Yum doesn't prompt. Barfs. You could be right if it did, but > _it_doesn't_. Seth already pointed out developer time is limited. Would you be so kind to provide patches for more user friendly messages? > > you write up the process for what has to occur and get EVERYONE to agree > > on it and I'll write the code. > > In a very highlevel way, I already did, wouldn't you say so? No. You might have indicated a problem that you perceive, but you have neither described a standard on how to handle it, nor have you got everyone to agree on your solution. Leonard "you may feel a slight sting, that's pride fuckin' wit ya. Fuck pride!" den Ottolander. -- mount -t life -o ro /dev/dna /genetic/research From pnasrat at redhat.com Tue Sep 7 12:16:07 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 7 Sep 2004 08:16:07 -0400 Subject: rpm error message, some more detail would be nice. In-Reply-To: <20040907120137.37635.qmail@web50603.mail.yahoo.com> References: <604aa79104090620145b2287c2@mail.gmail.com> <20040907120137.37635.qmail@web50603.mail.yahoo.com> Message-ID: <20040907121605.GD31441@devserv.devel.redhat.com> On Tue, Sep 07, 2004 at 05:01:37AM -0700, Steve G wrote: > >> $ rpm -e kernel-2.6.5-1.358 kernel-2.6.8-1.541 > >> error: can't create transaction lock > > >Doesn't this assume that ALL transaction lock problems are permissions > >related? > No. There are a variety of reasons why this might fail. There's more than one > value for errno returned. Indeed there might be another write rpm operation happening! > > >Does rpm have the capability to inherently know that its a permission > >problem? > errno is set, its just a matter of using it in the error message. This is fair enough > >Can you assume that every rpm installation in use requires root? > This is actually a good point. rpm should check the uid to see if its root. > If not print a warning that there may be permission problems and re-run as > root to avoid this warning. This patch has been on my todo list for a while. I'm not sure that's ideal behaviour - it is possible to use things such as --dbpath and --root (ignoring not being able to move the transaction lock for the moment). I wouldn't expect a failed (EPERM) rm command to suggest rerunning as root, likewise for rpm. Also theoretically we could have a "package_installer_r" with selinux to enable certain rpm install operations. As always bugzilla or rpm-list the best places for RFEs or this sort of discussion. Paul From rms at 1407.org Tue Sep 7 12:32:53 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 07 Sep 2004 13:32:53 +0100 Subject: Notes on Yum Changes In-Reply-To: <1094558702.4751.27.camel@athlon.localdomain> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094514325.4702.67.camel@binkley> <1094541683.3630.25.camel@roque> <1094558702.4751.27.camel@athlon.localdomain> Message-ID: <1094560373.2673.35.camel@roque> On Tue, 2004-09-07 at 14:05 +0200, Leonard den Ottolander wrote: > On Tue, 2004-09-07 at 09:21, Rui Miguel Seabra wrote: > > What do you think of a security update that doesn't update because > > there's a bug in an unrelated package? > > Firstly the fact that it interferes makes it related. Secondly it was > pointed out by more than one user that hiding details about conflicts > from the user (by skipping such packages) is probably worse than > erroring out with a message. I never mentioned hiding, nor was that the intention. > > How "potentially serious" a problem would that be? > > The user should have noticed there's a problem from the warnings (s)he > received. If (s)he can't deal with those (s)he shouldn't be using > multiple repos in the first place. What multiple repos? Why do you suppose there have to be multiple repos for this to happen? The latest problem of barfing due to obsolete packages happened recently with xorg. > > The job of a metapackager is making updating easier, not harder just as > > hard as if it wasn't there. > As pointed out the metapackager can not be expected to handle conflicts > if no standard on which all the repositories (and users) agree is > defined on how to do so. There's nothing about solving conflicts. Just not letting a conflict on some packages affect the other unrelated (ie, those that do not depend on them). > In case of your above example, how should yum know it needs to skip the > package that holds the obsoletes, and not the package for which a > security update is released? Huh? You're not understanding: yum barfed because of obsolete packages. if there was an unrelated security package, it wouldn't be applied because yum barfed. if, since there was a problem with some packages, it offered to install the other unrelated ones, the problem would be minimized and life would be made easier for the end user. > > There would be a resemblance if I was saying to install even if it > > screamed of a problem... > > Well that is sort of what you suggest above. Install security update > even though there is a conflict and skip the other package. I still > don't see how that could solve a circular obsoletes by the way. No. You're misreading. Read again. I'm talking about a problem on an unrelated package preventing an update, because obsoletes is not on by default. Imagine there was a bug with mount (which is suid root). An update for util-linux wouldn't be upgraded on one of the last update batches because some xorg-x11 packages obsoleted others, halting the process. As you can see, there is no X here: [rms at roque ~]$ rpm -q util-linux --requires /bin/sh /bin/sh /etc/pam.d/system-auth /sbin/install-info config(util-linux) = 2.12a-6 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.3.3) libcrypt.so.1 libcrypt.so.1(GLIBC_2.0) libdl.so.2 libncurses.so.5 libpam.so.0 libpam_misc.so.0 libpopt.so.0 libtermcap.so.2 libutil.so.1 libutil.so.1(GLIBC_2.0) libuuid.so.1 libz.so.1 pam >= 0.66-4 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 > > Yum doesn't prompt. Barfs. You could be right if it did, but > > _it_doesn't_. > > Seth already pointed out developer time is limited. Would you be so kind > to provide patches for more user friendly messages? I'm not demaning it to be solved, I wondered why something wsn't the default and I don't see any answer with a sensible reason. Just "NOTABUG" or "WONTFIX". All I read were excuses. I can understand limited time, not bad and arrogant statements, like expecting a newbie to be able to solve yum dependency problems. > > > you write up the process for what has to occur and get EVERYONE to agree > > > on it and I'll write the code. > > In a very highlevel way, I already did, wouldn't you say so? > > No. You might have indicated a problem that you perceive, Not perceive. Exists. A newbie user is placed with a "difficult" challenge unecessarily, and important packages may not be upgraded due to certain bugs in unrelated packages. And the excuse for not solving is not "limited time" (which I would understand) but "WONTFIX" (not how the replies were written, but how they "sounded" to my "ears"). > but you have > neither described a standard on how to handle it, nor have you got > everyone to agree on your solution. I don't need to describe in detail what's taught on classes about finding paths on mazes without getting lost on loops, do I? You mark where you have been, so that if you find it again, you know you've been there. You mark obsolete "paths" until you find one that's already registered (a loop). Anyway, I'm not complaining my self. I just think this is a bad thing for newbie users. For me? It's just a minute (or so) more. > Leonard "you may feel a slight sting, that's pride fuckin' wit ya. Fuck > pride!" den Ottolander. I only hope this is a random quote or else, it is a very innadequate one, I think. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Tue Sep 7 12:51:31 2004 From: buildsys at redhat.com (Build System) Date: Tue, 7 Sep 2004 08:51:31 -0400 Subject: rawhide report: 20040907 changes Message-ID: <200409071251.i87CpVq19812@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-2.91-0.20040907 ---------------------------- From linux_4ever at yahoo.com Tue Sep 7 12:47:12 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 7 Sep 2004 05:47:12 -0700 (PDT) Subject: rpm error message, some more detail would be nice. In-Reply-To: <20040907121605.GD31441@devserv.devel.redhat.com> Message-ID: <20040907124712.8097.qmail@web50601.mail.yahoo.com> >I'm not sure that's ideal behaviour - it is possible to use things such >as --dbpath and --root (ignoring not being able to move the transaction >lock for the moment). I wouldn't expect a failed (EPERM) rm command to >suggest rerunning as root, likewise for rpm. I think that using --dbpath and --root is rare. The 80/20 rule is that people use rpm to simply upgrade/query a system. Nothing fancy. The only time I *ever* use those options is in my chroot build system when I'm setting up the build partition. Even in that case I need to run as root to make sure all file permissions are set correctly so that the build system will error when it tries to overwrite something important. I suppose another approach is to hold off the warning until EPERM is seen. But that complicates the code. For my source tree, I'm going to patch in a warning message since that is the simplest solution. >Also theoretically we could have a "package_installer_r" with selinux to >enable certain rpm install operations. This would have to be thought out carefully if I understand your suggestion. It could become and attack vector if done wrong. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From skvidal at phy.duke.edu Tue Sep 7 13:09:57 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 07 Sep 2004 09:09:57 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094560373.2673.35.camel@roque> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094514325.4702.67.camel@binkley> <1094541683.3630.25.camel@roque> <1094558702.4751.27.camel@athlon.localdomain> <1094560373.2673.35.camel@roque> Message-ID: <1094562597.4702.135.camel@binkley> > What multiple repos? Why do you suppose there have to be multiple repos > for this to happen? > > The latest problem of barfing due to obsolete packages happened recently > with xorg. The problem was with xorg in RAWHIDE. Not in a normal repository. If people want to run rawhide then they can figure out some subset of pkging problems that come up. I added the obsoletes option to yum.conf so that people who feel confident in obsoletes. I do not feel comfortable making obsoletes the default. The last time there was a circular obsoletes in the core distro was b/t zebra and routed. They each obsoleted each other. I discovered the problem b/c I watched a system oscillate b/t the two packages every other day. What I'm asking for is how should yum track that? Do you want it to maintain some state of what packages used to be installed outside of the rpmdb? Should I create a secondary yumdb of obsoletes so I can know what one was installed before the first obsoletes? > There's nothing about solving conflicts. Just not letting a conflict on > some packages affect the other unrelated (ie, those that do not depend > on them). We're not talking about conflicts - we're talking about obsoletes. > > > In case of your above example, how should yum know it needs to skip the > > package that holds the obsoletes, and not the package for which a > > security update is released? > > Huh? You're not understanding: > yum barfed because of obsolete packages. > if there was an unrelated security package, it wouldn't be applied > because yum barfed. > if, since there was a problem with some packages, it offered to > install the other unrelated ones, the problem would be minimized and > life would be made easier for the end user. So you would like yum, in the event of an automated loop to print out an error message but to do everything else in the transaction? This seems like safe behavior to you? > Imagine there was a bug with mount (which is suid root). > An update for util-linux wouldn't be upgraded on one of the last update > batches because some xorg-x11 packages obsoleted others, halting the > process. What about the inverse case? yum can update trivial things but b/c of some issue can't update a security related patch. Oh but wait, we have no metadata to tell us that one patch is security and one isn't so we can't rank the updates. The reason I error out on any package failing is to try to get the attention of the user. Happily continuing will typically make the user ignore it when they should probably be paying closer attention. > I'm not demaning it to be solved, I wondered why something wsn't the > default and I don't see any answer with a sensible reason. Just > "NOTABUG" or "WONTFIX". Where did I say either of those? I've asked, repeatedly, for the process everyone agrees on as the best behavior in those situations and I've gotten a general 'solve loops' response. No one has said: Answer these questions: In the event of a conflict what should occur? In the event of a conflict with a -y specified? In the event of an unresolvable dep? In the event of an unresolvable dept with -y specified? In the event of an obsoleting loop? In the event of an obsoleting loop with -y specified? If I'm going to write code that handles these cases I would love to get some other people's input on the best way to handle it. > All I read were excuses. I can understand limited time, not bad and > arrogant statements, like expecting a newbie to be able to solve yum > dependency problems. Where are the arrogant statements? I'm GENUINELY looking for expected behavior. > > > > you write up the process for what has to occur and get EVERYONE to agree > > > > on it and I'll write the code. > > > In a very highlevel way, I already did, wouldn't you say so? > > > > No. You might have indicated a problem that you perceive, > > Not perceive. Exists. A newbie user is placed with a "difficult" > challenge unecessarily, and important packages may not be upgraded due > to certain bugs in unrelated packages. > > And the excuse for not solving is not "limited time" (which I would > understand) but "WONTFIX" (not how the replies were written, but how > they "sounded" to my "ears"). Then get your ears checked. That's not what I've been saying. But I'll be damned if I'm going to "fix" something which will make it equally bad as if I hadn't. > I don't need to describe in detail what's taught on classes about > finding paths on mazes without getting lost on loops, do I? It's not about breaking loops. It's about expected behavior for pkging conflicts or problems of various types. It's about handling automated runs. -sv From leonard at den.ottolander.nl Tue Sep 7 13:40:41 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 07 Sep 2004 15:40:41 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094560373.2673.35.camel@roque> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094514325.4702.67.camel@binkley> <1094541683.3630.25.camel@roque> <1094558702.4751.27.camel@athlon.localdomain> <1094560373.2673.35.camel@roque> Message-ID: <1094564441.4751.64.camel@athlon.localdomain> Hi Rui, On Tue, 2004-09-07 at 14:32, Rui Miguel Seabra wrote: > I never mentioned hiding, nor was that the intention. So how would you make such a failure stand out in an otherwise successful update? Example: Critical update was skipped because a dependency issue. Newbie: "Oh, it's just a warning as the program completed successfully." This is not more or less valid than the examples you give. > What multiple repos? Why do you suppose there have to be multiple repos > for this to happen? > > The latest problem of barfing due to obsolete packages happened recently > with xorg. You are correct that I make a bit of an assumption, but in stable distribution trees such conflicts should be seldom and if they do exist it's fine newbies start crying for help as there is obviously something wrong with the tree. > Huh? You're not understanding: > yum barfed because of obsolete packages. > if there was an unrelated security package, it wouldn't be applied > because yum barfed. Indeed the packages are unrelated. But... > As you can see, there is no X here: > [rms at roque ~]$ rpm -q util-linux --requires That might be so, but what makes you so sure hiding the xorg-x11 packages won't cause other updates to fail in the process? > I'm not demaning it to be solved, I wondered why something wsn't the > default and I don't see any answer with a sensible reason. Just > "NOTABUG" or "WONTFIX". "Not a bug" is quite different from "won't fix". > All I read were excuses. I can understand limited time, not bad and > arrogant statements, like expecting a newbie to be able to solve yum > dependency problems. The dependency problems are not in yum but in the tree(s). > > > > you write up the process for what has to occur and get EVERYONE to agree > Not perceive. Exists. A newbie user is placed with a "difficult" > challenge unecessarily, and important packages may not be upgraded due > to certain bugs in unrelated packages. Ok. But you perceive this to be a yum issue instead of a repo issue. And you still don't answer the essential part, namely give us a definition of how yum should behave in case of conflicts. Just skipping packages might cause unexpected side effects. > > but you have > > neither described a standard on how to handle it, nor have you got > > everyone to agree on your solution. > > I don't need to describe in detail what's taught on classes about > finding paths on mazes without getting lost on loops, do I? Cute. If it's so obvious to you you might want to come up with a patch so we can evaluate it. But iirc your first proposal was just to toggle a switch, which doesn't cut it. > You mark where you have been, so that if you find it again, you know > you've been there. > You mark obsolete "paths" until you find one that's already registered > (a loop). How would the entry point in that path (assuming a circular obsoletes situation) influence which package gets installed or removed? > Anyway, I'm not complaining my self. I just think this is a bad thing > for newbie users. For me? It's just a minute (or so) more. As pointed out these issues will hardly exist in single distribution repositories (they shouldn't). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From Nicolas.Mailhot at laPoste.net Tue Sep 7 13:36:42 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 07 Sep 2004 15:36:42 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094562597.4702.135.camel@binkley> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094514325.4702.67.camel@binkley> <1094541683.3630.25.camel@roque> <1094558702.4751.27.camel@athlon.localdomain> <1094560373.2673.35.camel@roque> <1094562597.4702.135.camel@binkley> Message-ID: <1094564203.12771.10.camel@ulysse.olympe.o2t> Le mardi 07 septembre 2004 ? 09:09 -0400, seth vidal a ?crit : > > What multiple repos? Why do you suppose there have to be multiple repos > > for this to happen? > > > > The latest problem of barfing due to obsolete packages happened recently > > with xorg. > > The problem was with xorg in RAWHIDE. Not in a normal repository. If > people want to run rawhide then they can figure out some subset of > pkging problems that come up. You have most of the problems of Rawhide on standard RHAS/Fedora systemes. It may be less frequent, but usually you don't have the leeway to fix it you get with a Rawhide box (entreprise critical, etc etc) ? It's in Rawhide, I can ignore it ? has always been a poor excuse IMHO. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rms at 1407.org Tue Sep 7 14:17:56 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 07 Sep 2004 15:17:56 +0100 Subject: Notes on Yum Changes In-Reply-To: <1094562597.4702.135.camel@binkley> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094514325.4702.67.camel@binkley> <1094541683.3630.25.camel@roque> <1094558702.4751.27.camel@athlon.localdomain> <1094560373.2673.35.camel@roque> <1094562597.4702.135.camel@binkley> Message-ID: <1094566676.2673.64.camel@roque> On Tue, 2004-09-07 at 09:09 -0400, seth vidal wrote: > > What multiple repos? Why do you suppose there have to be multiple repos > > for this to happen? > > > > The latest problem of barfing due to obsolete packages happened recently > > with xorg. > > The problem was with xorg in RAWHIDE. Not in a normal repository. If > people want to run rawhide then they can figure out some subset of > pkging problems that come up. And I did figure. But this is nothing that couldn't happen by accident on the stable tree. > I added the obsoletes option to yum.conf so that people who feel > confident in obsoletes. I do not feel comfortable making obsoletes the > default. The last time there was a circular obsoletes in the core distro > was b/t zebra and routed. They each obsoleted each other. > > I discovered the problem b/c I watched a system oscillate b/t the two > packages every other day. > > What I'm asking for is how should yum track that? Do you want it to > maintain some state of what packages used to be installed outside of the > rpmdb? Should I create a secondary yumdb of obsoletes so I can know what > one was installed before the first obsoletes? Nothing so complicated. At each run one could keep a small graph of the obsoletes, and test wether one is walking _again_ through some path. > > There's nothing about solving conflicts. Just not letting a conflict on > > some packages affect the other unrelated (ie, those that do not depend > > on them). > We're not talking about conflicts - we're talking about obsoletes. Ok, the pratical effects ends up being the same, I understand what you mean by the difference. I was using the more general meaning of conflict. There's nothing about solving obsoletes. Just not letting an obsolete on some package affect other unrelated packages (ie, those that do not depend on them). Is it clearer like this? Sorry for the terminology inadequacy... > > > In case of your above example, how should yum know it needs to skip the > > > package that holds the obsoletes, and not the package for which a > > > security update is released? > > > > Huh? You're not understanding: > > yum barfed because of obsolete packages. > > if there was an unrelated security package, it wouldn't be applied > > because yum barfed. > > if, since there was a problem with some packages, it offered to > > install the other unrelated ones, the problem would be minimized and > > life would be made easier for the end user. > > So you would like yum, in the event of an automated loop to print out an > error message but to do everything else in the transaction? This seems > like safe behavior to you? If the other packages are unrelated (no dependency link), yes. > > Imagine there was a bug with mount (which is suid root). > > An update for util-linux wouldn't be upgraded on one of the last update > > batches because some xorg-x11 packages obsoleted others, halting the > > process. > > What about the inverse case? > > yum can update trivial things but b/c of some issue can't update a > security related patch. Oh but wait, we have no metadata to tell us that > one patch is security and one isn't so we can't rank the updates. It's not even a matter of rank, the rank here was only to highlight what I mean: unrelated packages should be safe to work on even if there's an obsolete conflict somewhere else. One can track obsoletes in order to avoid loops, is there a graph library for python? I suppose so, but I'm not familiar with python, sorry. > The reason I error out on any package failing is to try to get the > attention of the user. Happily continuing will typically make the user > ignore it when they should probably be paying closer attention. I understand that, and that works fine on people who have bigger experience with packages. I used to do this stuff "by hand", so I'm very glad there's software like yum (which since 2.1 satisfies my "needs" much more than it did before) and apt that help me on that. > > I'm not demaning it to be solved, I wondered why something wsn't the > > default and I don't see any answer with a sensible reason. Just > > "NOTABUG" or "WONTFIX". > > Where did I say either of those? I've asked, repeatedly, for the process > everyone agrees on as the best behavior in those situations and I've > gotten a general 'solve loops' response. No one has said: Ok, I'm probably drawning meanings from interpretation, but I haven't generally said solve loop. I've said that one should keep a log of loops (and obsoletes loops) and when one is found see if anything can be done with the rest before failing. > Answer these questions: I'll answer considering the following terminology, please correct me where I get it wrong: conflict -> like two packages trying to own the same file unresolvable dep -> self explanatory obsolete loop -> self explanatory > In the event of a conflict what should occur? I think that those packages and those that depend on them should be skipped, and try to work on with the rest. > In the event of a conflict with a -y specified? Should there even exist such a question to answer y? Assuming it should... ... and considering the above terminology, I think it shouldn't work. -y is a way to force an answer because you expect everything to be ok, but in this case not only it isn't, it can have serious consequences. But IMHO that question shouldn't exist. > In the event of an unresolvable dep? > In the event of an unresolvable dept with -y specified? ditto for both > In the event of an obsoleting loop? > In the event of an obsoleting loop with -y specified? ditto for both > If I'm going to write code that handles these cases I would love to get > some other people's input on the best way to handle it. I think that if some packages don't depend on the problematic packages, the metapackager should try to see if he can work with them. The only problem that could happen is very misbehaved packages (like, not telling the truth about what they require). > > All I read were excuses. I can understand limited time, not bad and > > arrogant statements, like expecting a newbie to be able to solve yum > > dependency problems. > > Where are the arrogant statements? I'm GENUINELY looking for expected > behavior. Not you specifically. I'm sorry if I haven't been specific enough to describe the expected behaviour, I didn't have in mind what kind of description you wanted. I hope my answers to your questions were helpful. > Then get your ears checked. That's not what I've been saying. I think I wrongly assumed some people were in the AUTHORS file. My mistake. > But I'll > be damned if I'm going to "fix" something which will make it equally bad > as if I hadn't. I understand. But consider this: Yum is much, much better now. Consider me as someone who up until recently _really_ preferred apt to yum, now they're pratically the same, as far as I need a meta packager. Since obviously apt is the preferred metapackager by FC maintainers at the moment, I think the current minor differences are completely irrelevant, and not being familiar with python it's better to suggest how to solve the problems instead of just working around them. So I'm a convert :) I'm just trying to incite yum into an even better spot. > It's not about breaking loops. It's about expected behavior for pkging > conflicts or problems of various types. It's about handling automated > runs. I really hope my answers help. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Tue Sep 7 14:56:40 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 7 Sep 2004 07:56:40 -0700 Subject: ia32e, er EM64T that is... In-Reply-To: <20040906174717.GA11888@devserv.devel.redhat.com> References: <200409061011.52742.jkeating@j2solutions.net> <20040906174717.GA11888@devserv.devel.redhat.com> Message-ID: <200409070756.49331.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 06 September 2004 10:47, Alan Cox wrote: > em64t as Intel currently call it is pretty close to the x86-64 > architecture so its not too bad a clone. It lacks prefetch/prefetchw > which can also be used by some fancy user space stuff like image > processors. It also lacks a hardware IOMMU so you may have > performance problems going above about 3.5Gb of RAM depending on your > other hardware. I know they are similar, and em64t lacks some things that AMD64 has, however we have lots of customers that refuse to run anything but Intel, and they want to run Naconas. I'm just making sure that the performance hit they get against Opteron isn't due to misconfigured software. If what Arjan says is true, and it's a runtime detection thing and I don't have to build a complete kernel optimized for em64t than that is cool. Thanks. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBPcwv4v2HLvE71NURAmV9AKCRZGO/ZwfqEgoI3tt7K1UOWV9lDgCfTENZ R+iKfPkNJ99QQLxVNmvR3P0= =/zQO -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Tue Sep 7 14:06:19 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 07 Sep 2004 10:06:19 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094564203.12771.10.camel@ulysse.olympe.o2t> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094514325.4702.67.camel@binkley> <1094541683.3630.25.camel@roque> <1094558702.4751.27.camel@athlon.localdomain> <1094560373.2673.35.camel@roque> <1094562597.4702.135.camel@binkley> <1094564203.12771.10.camel@ulysse.olympe.o2t> Message-ID: <1094565979.32524.1.camel@opus.phy.duke.edu> On Tue, 2004-09-07 at 09:36, Nicolas Mailhot wrote: > Le mardi 07 septembre 2004 ? 09:09 -0400, seth vidal a ?crit : > > > What multiple repos? Why do you suppose there have to be multiple repos > > > for this to happen? > > > > > > The latest problem of barfing due to obsolete packages happened recently > > > with xorg. > > > > The problem was with xorg in RAWHIDE. Not in a normal repository. If > > people want to run rawhide then they can figure out some subset of > > pkging problems that come up. > > You have most of the problems of Rawhide on standard RHAS/Fedora > systemes. It may be less frequent, but usually you don't have the leeway > to fix it you get with a Rawhide box (entreprise critical, etc etc) > > ? It's in Rawhide, I can ignore it ? has always been a poor excuse IMHO. I completely disagree. Rawhide frequently has unresolvable dependencies. It frequently has randomly introduced version updates that are rolled back in the next rawhide update. Those things, which catch something like 90% of the users, do not happen in stable releases. They do happen in broken repositories though. But I'm not sure that just continuing when a repository is broken is in anyone's best interest. -sv From fitzsim at redhat.com Tue Sep 7 15:17:15 2004 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 07 Sep 2004 11:17:15 -0400 Subject: open-xchange release In-Reply-To: <41334E3B.5040704@feuerpokemon.de> References: <20040830153754.GA22835@devserv.devel.redhat.com> <41334E3B.5040704@feuerpokemon.de> Message-ID: <1094570235.7528.38.camel@tortoise.toronto.redhat.com> On Mon, 2004-08-30 at 11:56, dragoran wrote: > Alan Cox schrieb: > > >On Mon, Aug 30, 2004 at 11:00:09AM -0400, Neal D. Becker wrote: > > > > > >>Announcement @ http://www.open-xchange.org > >>Anyone working on packaging for fedora? > >> > >>I guess one issue is that it requires a JDK. AFAIK, there isn't one > >>standard JDK for Fedora. > >> > >> > > > >Can it be built and run with gcj so that only open source is needed for it. > >If not it doesn't seem to be eligible for Fedora anyway. > > > > > > > > > checking for javac... no > configure: error: no acceptable java compiler found - please install at > least the Java(TM) 2 SDK. > Can you install the java-1.4.2-gcj-compat (FC3) package and try this again? It installs wrapper scripts for ecj and gij that make them quite similar in behaviour to Sun's tools. Open-Xchange doesn't seem to require Swing so there is a chance it will run with libgcj. Thanks, Tom From linux_4ever at yahoo.com Tue Sep 7 14:18:47 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 7 Sep 2004 07:18:47 -0700 (PDT) Subject: FC3test2 candidate tree In-Reply-To: <1094526713.3727.65.camel@bree.local.net> Message-ID: <20040907141847.8536.qmail@web50607.mail.yahoo.com> >> I would have hoped that a "release" is built from itself so that *everything* >> matches. > >If you do this, then you lose a lot of the benefit of any earlier >testing. I would suggest that rawhide will always be compiled independently, and sometimes it is built against itself. That's the nature of the beast. If the code really is correct and portable, you should not notice any bugs. And if you do, that would be a data point. >Although it'd be nice to believe that a rebuild with a newer >compiler or whatnot won't change anything, the fact of the matter is >that you may trip over new bugs in the build chain. And as it stands, the bugs are there but you don't find them until its critical to rebuild for some reason. Then its too late because the world has moved on. >Thus, if everything got rebuilt at the last minute, there'd be no way to >sanely test and QA the distribution. The solution is that all test releases are built against themselves. Many more people use binary rpms than build it themselves. (It can take a couple days for a full build to complete. Most people are not that patient.) So most bug reports you get would be from the built against itself version. You should be able to get sane QA'ing. This is one of the attractions that some people have for projects like Gentoo. You always know you got the whole thing, it compiles against itself, you can re-create a distribution at will if you ever needed to. I know some projects/installations that are going this route rather than Fedora *because* of these reasons. Just trying to help you guys out since you may not be seeing this trend yet. -Steve Grubb _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From notting at redhat.com Tue Sep 7 15:23:07 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Sep 2004 11:23:07 -0400 Subject: FC3 Bug Status - 2004-09-07 Message-ID: <20040907152306.GA29064@nostromo.devel.redhat.com> 2004-09-08 Severity Total Closed Need Testing BLOCKER 35 14 ( 40.00 %) 3 ( 21.43 %) TARGET 591 194 ( 32.83 %) 33 ( 17.01 %) Overall 626 208 ( 33.23 %) 36 ( 17.00 %) 2004-08-18 Severity Total Closed Need Testing TARGET 415 61 ( 14.70 %) 16 ( 26.23 %) From pp at ee.oulu.fi Tue Sep 7 15:41:37 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Tue, 7 Sep 2004 18:41:37 +0300 Subject: FC3 Bug Status - 2004-09-07 In-Reply-To: <20040907152306.GA29064@nostromo.devel.redhat.com> References: <20040907152306.GA29064@nostromo.devel.redhat.com> Message-ID: <20040907154137.GA1271@ee.oulu.fi> On Tue, Sep 07, 2004 at 11:23:07AM -0400, Bill Nottingham wrote: > > 2004-09-08 > Severity Total Closed Need Testing > BLOCKER 35 14 ( 40.00 %) 3 ( 21.43 %) > TARGET 591 194 ( 32.83 %) 33 ( 17.01 %) > Overall 626 208 ( 33.23 %) 36 ( 17.00 %) Hi Nice report, took asking on #fedora-devel to figure out how to figure out what these bugs are (Bug 123268/FC3Target and 130887/FC3Blocker in case someone is wondering). This info should probably be included in the report so people don't have so spend time figuring it out ;) Maybe even a "Most wanted bugs" thingy to really get everyones attention ;) -- Pekka Pietikainen From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Sep 7 13:39:47 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 7 Sep 2004 15:39:47 +0200 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec Message-ID: <20040907153947.298cf4be@localhost> Hi, I've ran into a real problem where package A requires B, and B requires A : The current httpd and httpd-suexec packages from FC Development. I've just installed FC Test from the latest ISOs, a minimal system, then did "yum install httpd" from there. The problem is that during the transaction, httpd-suexec (which got pulled in as a dependency) got installed first, outputting the message "apache group doesn't exist, using root"... BAD! Yes, the suexec binary is now sgid root on that system instead of sgid apache. Now... I'm posting here before bugzilla'ing this since I'd like to know what the general opinion is regarding packages requiring some of their own sub-packages like this. I really think it should be avoided since there are some side-effects like this one that can arise. Furthermore, I don't get why httpd-suexec nor php-mbstring (as another example) got split off... the main purpose I can see for such cases is for the original package to be overridden by another one providing the same functionality, like the X Mesa libraries. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 1.00 0.99 0.76 From rdieter at math.unl.edu Tue Sep 7 16:08:44 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 7 Sep 2004 11:08:44 -0500 (CDT) Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040907153947.298cf4be@localhost> References: <20040907153947.298cf4be@localhost> Message-ID: On Tue, 7 Sep 2004, Matthias Saou wrote: > Furthermore, I don't get > why httpd-suexec nor php-mbstring (as another example) got split off... the IMO, In the case of httpd-suexec, httpd should *NOT* require it, and the point of installing the subpkg would be to enable/disable the suexec functionality. -- Rex From ronny-vlug at vlugnet.org Tue Sep 7 16:59:18 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Tue, 7 Sep 2004 18:59:18 +0200 Subject: rpm error message, some more detail would be nice. In-Reply-To: <20040907121605.GD31441@devserv.devel.redhat.com> References: <604aa79104090620145b2287c2@mail.gmail.com> <20040907120137.37635.qmail@web50603.mail.yahoo.com> <20040907121605.GD31441@devserv.devel.redhat.com> Message-ID: <200409071859.18273.ronny-vlug@vlugnet.org> On Tuesday 07 September 2004 14:16, Paul Nasrat wrote: > I'm not sure that's ideal behaviour - it is possible to use things such as > --dbpath and --root (ignoring not being able to move the transaction lock > for the moment). I wouldn't expect a failed (EPERM) rm command to suggest > rerunning as root, likewise for rpm. > > Also theoretically we could have a "package_installer_r" with selinux to > enable certain rpm install operations. This would still require root permission. SELinux doesn't give additional rights. -- http://LinuxWiki.org/RonnyBuchmann From ronny-vlug at vlugnet.org Tue Sep 7 17:06:14 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Tue, 7 Sep 2004 19:06:14 +0200 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: References: <20040907153947.298cf4be@localhost> Message-ID: <200409071906.14898.ronny-vlug@vlugnet.org> On Tuesday 07 September 2004 18:08, Rex Dieter wrote: > On Tue, 7 Sep 2004, Matthias Saou wrote: > > Furthermore, I don't get > > why httpd-suexec nor php-mbstring (as another example) got split off... > > the > > IMO, In the case of httpd-suexec, httpd should *NOT* require it, and > the point of installing the subpkg would be to enable/disable the suexec > functionality. Which was a real enhancement, manually removing suexec after every update is really annoying (especially if your forgot about it and looking for the cause of errors...) If there really is a dep in httpd on httpd-suexec this is IMHO a bug. (I assume it was introduced for the upgrade from old httpd with integrated suexec to the new one with suexec subpackage) -- http://LinuxWiki.org/RonnyBuchmann From kyrre at solution-forge.net Tue Sep 7 18:06:21 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 07 Sep 2004 20:06:21 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094534684.16965.3.camel@chip.laiskiainen.org> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> <1094534684.16965.3.camel@chip.laiskiainen.org> Message-ID: <1094580381.2714.12.camel@kyrre> tir, 07.09.2004 kl. 07.24 skrev Panu Matilainen: > On Tue, 2004-09-07 at 03:00, seth vidal wrote: > > On Mon, 2004-09-06 at 17:26 -0400, Sean Middleditch wrote: > > > On Mon, 2004-09-06 at 21:38 +0200, Kyrre Ness Sjobak wrote: > > > > > > > Is there any plans for integrating rpm with yum - so that rpm would ask > > > > "you need dependancy foo, bar, baz.so in order to install this package, > > > > shall i ask yum to fetch them for you? (y/n)" > > > > > > Instead of integrating yum into rpm, just use a tool (such as yum > > > itself) to install your packages instead of rpm. I don't know offhand > > > if yum already supports this, but if not, it should. ;-) > > > > > > The graphical tools like system-install-packages and friends should also > > > then integrate with yum. > > > > > > I'm sure the maintainers will accept patches for such a feature. ;-) > > > > The question becomes how to do this sensibly. > > > > yum install /some/path/to/an/rpm > > > > that's possible > > > > except I get an equal number of requests for: > > > > yum install /some/file/that/some/package/in/a/repository/provides. > > > > it's not impossible to check for but it means searching harder. > > Might be harder to search for but that IS an awfully nice and useful > feature. > > - Panu - > > Yes, that is one way to solve it. What i was more thinking about, was really "integrating" (sorry if i use the wrong wording) yum into rpm. Yum has an API, yes? Only that will create a circular dependence rpm/yum - make it a compile option? But something that WILL be needed if this actually gets implemented, is some "--noyumdepsolve" and "--silent-answer-yes" flags - rpm is very useful also in scripts. (is there some way to detect if a program is getting called by a script (non-interactive) or by an actual person on a terminal? If so, --silent-answer-yes should be default imo. That option could be _very_ useful when talking about rpm that require a license to be read etc. (ever tried installing the Macromedia Flash rpm's through a script? /me likes Dag Wieers, who makes good non-interactive flash-rpms...) Ofcourse it is possible to tell people to use yum instead of rpm - but how nice is that? "Hey all you people, forget about rpm - always use yum instead!!" - or not? "rpm -ivh two-lettersTAB" is something that is built into my fingers... But a new tool could work (something like "rpm-depsolve -ivh my-package.fc2.rpm" Only problem now is actually finding a good programmer, and a good way to do this. From kyrre at solution-forge.net Tue Sep 7 18:11:51 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 07 Sep 2004 20:11:51 +0200 Subject: Strangest Bug Report... In-Reply-To: <1094546864.2714.18.camel@otto.amantes> References: <413C26E7.2020307@redhat.com> <1094500594.28275.13.camel@kyrre> <1094503329.1061.1.camel@one.myworld> <1094503935.28275.16.camel@kyrre> <1094546864.2714.18.camel@otto.amantes> Message-ID: <1094580711.2714.17.camel@kyrre> tir, 07.09.2004 kl. 10.47 skrev Thomas Vander Stichele: > Hi, > > But.. gstreamer... That is the gnome audio/video framework, right? > > Nope. It is a multimedia framework, yes, and it is adopted by GNOME, > yes. But it's not "the gnome framework". It's actually on freedesktop > atm. > > > What > > do you mean? Will (does) helix utilize gstreamer? > > It doesn't, and I'd be very surprised if it ever did. > > Incidentally, does anyone of the redhat guys know if helixplayer was put > into fedora because of the realplayer contract for the redhat distros ? > > Thomas > > > Dave/Dina : future TV today ! - http://www.davedina.org/ > <-*- thomas (dot) apestaart (dot) org -*-> > Well baby let me shake it > If I can move it with you will you let me take it > <-*- thomas (at) apestaart (dot) org -*-> > URGent, best radio on the net - 24/7 ! - http://urgent.fm/ > > OK. Real are just geniuses... *real is going to hell Hey OpenSource it! *real looks sad, and throws the whole thing to the Foss-comunity *foss goes on and makes a good player and a new video codec *real takes thing back, thanks, and releases a good player (not mentioning the properitary real codecs *everybody wins: Real gets a "framework" for nothing, Foss gets (another) multimedia-player - which hasn't got any patent problems THE END From elanthis at awesomeplay.com Tue Sep 7 19:19:31 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 07 Sep 2004 15:19:31 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094580381.2714.12.camel@kyrre> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> <1094534684.16965.3.camel@chip.laiskiainen.org> <1094580381.2714.12.camel@kyrre> Message-ID: <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2004-09-07 at 20:06 +0200, Kyrre Ness Sjobak wrote: > Yes, that is one way to solve it. > > What i was more thinking about, was really "integrating" (sorry if i use > the wrong wording) yum into rpm. Yum has an API, yes? Again, why? You don't get anything for this. Just use yum all the time and never invoke rpm. This is similar to how most users in Debian systems use apt-get all the time, but almost never directly invoke dpkg. And dpkg has no apt integration at all. The tools you use should be built on yum. What you're asking for is to allow tools to be built on rpm but have yum's features. That's a bad way to design the system, for many reasons, not the least of which is because the package manager should be able to just do its job; adding more meta-packager features to RPM is just going to increase the chance of bugs (and bugs which can and will affect the core of the package manager) > > Only that will create a circular dependence rpm/yum - make it a compile > option? > > But something that WILL be needed if this actually gets implemented, is > some "--noyumdepsolve" and "--silent-answer-yes" flags - rpm is very > useful also in scripts. (is there some way to detect if a program is > getting called by a script (non-interactive) or by an actual person on a > terminal? If so, --silent-answer-yes should be default imo. That option You can check if stdin is a (pseudo-)terminal or a pipe; the former indicates a user, the latter a script. Any time the user is directly interacting with the app, they should be using a PTY/TTY. Scripts may still use a PTY however; it's good to always be able to explicitly tell the tool that you're a script. > could be _very_ useful when talking about rpm that require a license to > be read etc. (ever tried installing the Macromedia Flash rpm's through a > script? /me likes Dag Wieers, who makes good non-interactive > flash-rpms...) The problem there is that, put bluntly, RPM sucks for applications. It is a low-level packaging tool intended for bundling the components of a distribution. It never was intended for third-party applications, and to this day still has huge problems supporting them, as the situation with Macromedia demonstrates. For license agreements, RPM would need meta-information to carry the full license text and allow a package to note that agreement is required; this would be done before any of the package installations even start. Currently, you'd have to put this in a script (and pray you made it portable enough *and* not use any binaries in your package, since it isn't unpacked yet, and make it pretty, and make it consistent... it's just not feasible) which would a) be executed sometime during installation, and b) have to report an error to rpm if the user declines, which would most likely cause all sorts of "Installation Failed!!! Here's some geeky nonsensical techie debug spew you, the user, don't understand or care about, because you are aware of the fact that you said 'No': " dialogs or console messages to appear. There are still then problems stemming from the fact that every version of every distribution is incompatible due to either developers not versioning their ABIs right, or packagers taking perfectly well versioned libraries and tools and putting them into poorly versioned and inconsistent packages (like the broken curl RPM in Fedora), but that's a whole different topic. ~_^ > > Ofcourse it is possible to tell people to use yum instead of rpm - but > how nice is that? "Hey all you people, forget about rpm - always use yum > instead!!" - or not? "rpm -ivh two-lettersTAB" is something that is > built into my fingers... But a new tool could work (something like > "rpm-depsolve -ivh my-package.fc2.rpm" If you're alright with requesting a tool like 'rpm-depsolve', I don't see at all how you can argue against just using yum. ;-) > > Only problem now is actually finding a good programmer, and a good way > to do this. > > -- Sean Middleditch AwesomePlay Productions, Inc. From steve at silug.org Tue Sep 7 19:50:06 2004 From: steve at silug.org (Steven Pritchard) Date: Tue, 7 Sep 2004 14:50:06 -0500 Subject: postfix bug? kernel bug? In-Reply-To: References: <20040901202439.GA20260@osiris.silug.org> Message-ID: <20040907195006.GA18362@osiris.silug.org> On Wed, Sep 01, 2004 at 04:43:54PM -0400, Chris Ricker wrote: > On Wed, 1 Sep 2004, Steven Pritchard wrote: > > > I'm setting it up with amavisd-new, which requires setting up postfix > > to listen on a port (so postfix relays to amavisd which relays to > > postfix). The initial connection to postfix (port 25) is fine. The > > mail is processed by amavisd fine. When amavisd tries to connect to > > postfix again, I get this: > > > > ==> /var/log/messages <== > > Aug 31 23:33:20 foo kernel: smtpd[1665]: segfault at 00000030bf300e20 rip 00000030bf206294 rsp 0000007fbfffd8b0 error 7 > > > > ==> /var/log/maillog <== > > Aug 31 23:33:20 foo postfix/master[1394]: warning: process /usr/libexec/postfix/smtpd pid 1665 killed by signal 11 > > Aug 31 23:33:20 foo postfix/master[1394]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling > > Does this happen every time, or sporadically? Every time. I tried un-installing postfix and installing the i386 postfix from rawhide... With the exact same configuration, the i386 postfix works perfectly, so there's definitely a bug here somewhere... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From ville.skytta at iki.fi Tue Sep 7 19:53:45 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 07 Sep 2004 22:53:45 +0300 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040907153947.298cf4be@localhost> References: <20040907153947.298cf4be@localhost> Message-ID: <1094586825.17961.119.camel@bobcat.mine.nu> On Tue, 2004-09-07 at 16:39, Matthias Saou wrote: > Now... I'm posting here before bugzilla'ing this since I'd like to know > what the general opinion is regarding packages requiring some of their own > sub-packages like this. I really think it should be avoided since there are > some side-effects like this one that can arise. Agreed. But in case a dependency "loop" like this between some packages is not avoidable (in general, not in this particular case) and the order in which they are installed inside one transaction matters, one of them should use "PreReq" and the other "Requires" in order to break the loop in predictable fashion (== PreReq "wins"; the package containing it will be installed last). That's what I've heard the difference between PreReq and Requires is, anyway. From jspaleta at gmail.com Tue Sep 7 13:20:51 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Sep 2004 09:20:51 -0400 Subject: rpm error message, some more detail would be nice. In-Reply-To: <20040907124712.8097.qmail@web50601.mail.yahoo.com> References: <20040907121605.GD31441@devserv.devel.redhat.com> <20040907124712.8097.qmail@web50601.mail.yahoo.com> Message-ID: <604aa791040907062018dcd6d@mail.gmail.com> On Tue, 7 Sep 2004 05:47:12 -0700 (PDT), Steve G wrote: > >I'm not sure that's ideal behaviour - it is possible to use things such > >as --dbpath and --root (ignoring not being able to move the transaction > >lock for the moment). I wouldn't expect a failed (EPERM) rm command to > >suggest rerunning as root, likewise for rpm. > > I think that using --dbpath and --root is rare. The 80/20 rule is that people > use rpm to simply upgrade/query a system. Nothing fancy. The 80/20 rule applies to error messages? We should be happy when an error message misinforms 20% of the time? That strikes me as a bit odd. Sure 80/20 for defaults and for ui features and for crap like that. Error messages, I have a hard time with that. -jef From rdieter at math.unl.edu Tue Sep 7 20:15:30 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 07 Sep 2004 15:15:30 -0500 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <1094586825.17961.119.camel@bobcat.mine.nu> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> Message-ID: <413E16E2.1090100@math.unl.edu> Ville Skytt? wrote: > Agreed. But in case a dependency "loop" like this between some packages > is not avoidable In many cases where foo Requires foo-bar and foo-bar Requires foo, IMO, there shouldn't *be* a foo-bar subpackage at all. One example off the top of my head: openoffice.org openoffice.org-libs What's the point of the separate -libs subpkg? -- Rex From wtogami at redhat.com Tue Sep 7 20:27:37 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 07 Sep 2004 10:27:37 -1000 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <1094586825.17961.119.camel@bobcat.mine.nu> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> Message-ID: <413E19B9.3060005@redhat.com> Ville Skytt? wrote: > On Tue, 2004-09-07 at 16:39, Matthias Saou wrote: > > >>Now... I'm posting here before bugzilla'ing this since I'd like to know >>what the general opinion is regarding packages requiring some of their own >>sub-packages like this. I really think it should be avoided since there are >>some side-effects like this one that can arise. > > > Agreed. But in case a dependency "loop" like this between some packages > is not avoidable (in general, not in this particular case) and the order > in which they are installed inside one transaction matters, one of them > should use "PreReq" and the other "Requires" in order to break the loop > in predictable fashion (== PreReq "wins"; the package containing it will > be installed last). That's what I've heard the difference between > PreReq and Requires is, anyway. > > Eh? jbj has confirmed on multiple occasions that there is NO DIFFERENCE between PreReq and Requires. Warren Togami wtogami at redhat.com From kyrre at solution-forge.net Tue Sep 7 19:51:21 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 07 Sep 2004 21:51:21 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> <1094534684.16965.3.camel@chip.laiskiainen.org> <1094580381.2714.12.camel@kyrre> <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1094586681.4141.3.camel@kyrre> tir, 07.09.2004 kl. 21.19 skrev Sean Middleditch: > On Tue, 2004-09-07 at 20:06 +0200, Kyrre Ness Sjobak wrote: > > > Yes, that is one way to solve it. > > > > What i was more thinking about, was really "integrating" (sorry if i use > > the wrong wording) yum into rpm. Yum has an API, yes? > > Again, why? You don't get anything for this. Just use yum all the time > and never invoke rpm. This is similar to how most users in Debian > systems use apt-get all the time, but almost never directly invoke dpkg. > And dpkg has no apt integration at all. > > The tools you use should be built on yum. What you're asking for is to > allow tools to be built on rpm but have yum's features. That's a bad > way to design the system, for many reasons, not the least of which is > because the package manager should be able to just do its job; adding > more meta-packager features to RPM is just going to increase the chance > of bugs (and bugs which can and will affect the core of the package > manager) > > > > > Only that will create a circular dependence rpm/yum - make it a compile > > option? > > > > But something that WILL be needed if this actually gets implemented, is > > some "--noyumdepsolve" and "--silent-answer-yes" flags - rpm is very > > useful also in scripts. (is there some way to detect if a program is > > getting called by a script (non-interactive) or by an actual person on a > > terminal? If so, --silent-answer-yes should be default imo. That option > > You can check if stdin is a (pseudo-)terminal or a pipe; the former > indicates a user, the latter a script. Any time the user is directly > interacting with the app, they should be using a PTY/TTY. Scripts may > still use a PTY however; it's good to always be able to explicitly tell > the tool that you're a script. > > > could be _very_ useful when talking about rpm that require a license to > > be read etc. (ever tried installing the Macromedia Flash rpm's through a > > script? /me likes Dag Wieers, who makes good non-interactive > > flash-rpms...) > > The problem there is that, put bluntly, RPM sucks for applications. It > is a low-level packaging tool intended for bundling the components of a > distribution. It never was intended for third-party applications, and > to this day still has huge problems supporting them, as the situation > with Macromedia demonstrates. > > For license agreements, RPM would need meta-information to carry the > full license text and allow a package to note that agreement is > required; this would be done before any of the package installations > even start. Currently, you'd have to put this in a script (and pray you > made it portable enough *and* not use any binaries in your package, > since it isn't unpacked yet, and make it pretty, and make it > consistent... it's just not feasible) which would a) be executed > sometime during installation, and b) have to report an error to rpm if > the user declines, which would most likely cause all sorts of > "Installation Failed!!! Here's some geeky nonsensical techie debug spew > you, the user, don't understand or care about, because you are aware of > the fact that you said 'No': " dialogs or console > messages to appear. > > There are still then problems stemming from the fact that every version > of every distribution is incompatible due to either developers not > versioning their ABIs right, or packagers taking perfectly well > versioned libraries and tools and putting them into poorly versioned and > inconsistent packages (like the broken curl RPM in Fedora), but that's a > whole different topic. ~_^ > > > > > Ofcourse it is possible to tell people to use yum instead of rpm - but > > how nice is that? "Hey all you people, forget about rpm - always use yum > > instead!!" - or not? "rpm -ivh two-lettersTAB" is something that is > > built into my fingers... But a new tool could work (something like > > "rpm-depsolve -ivh my-package.fc2.rpm" > > If you're alright with requesting a tool like 'rpm-depsolve', I don't > see at all how you can argue against just using yum. ;-) > Hmm... somhow using yum to install a local package feels wrong... Hmm... think ill acctually have to write some prototype stuff, then. rpm-depsolve, here i come! :P Always wanted to create some "core" utility... > > > > Only problem now is actually finding a good programmer, and a good way > > to do this. > > > > > -- > Sean Middleditch > AwesomePlay Productions, Inc. > From linux_4ever at yahoo.com Tue Sep 7 20:57:37 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 7 Sep 2004 13:57:37 -0700 (PDT) Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040907153947.298cf4be@localhost> Message-ID: <20040907205737.98756.qmail@web50602.mail.yahoo.com> >The problem is that during the transaction, httpd-suexec (which got pulled >in as a dependency) got installed first, outputting the message "apache >group doesn't exist, using root"... BAD! Really bad. I would think this bug needs fast attention. If you download a package from a 3rd party that has buffer overflows and is setgid, you now have a buggy program with buffer overflows running as root. Any setgid installation that fails should never revert to root, it should fail immediately and let the admin take care of it. Was this filed in bugzilla? -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From elanthis at awesomeplay.com Tue Sep 7 20:58:23 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 07 Sep 2004 16:58:23 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094586681.4141.3.camel@kyrre> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> <1094534684.16965.3.camel@chip.laiskiainen.org> <1094580381.2714.12.camel@kyrre> <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> <1094586681.4141.3.camel@kyrre> Message-ID: <1094590703.3391.83.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2004-09-07 at 21:51 +0200, Kyrre Ness Sjobak wrote: > tir, 07.09.2004 kl. 21.19 skrev Sean Middleditch: > > If you're alright with requesting a tool like 'rpm-depsolve', I don't > > see at all how you can argue against just using yum. ;-) > > > > Hmm... somhow using yum to install a local package feels wrong... Hmm... > think ill acctually have to write some prototype stuff, then. "Feels" wrong? How? It makes perfect sense. Nothing wrong with a separate tool either, although in the end all it would do is just invoke yum, so it (to me) makes sense to just have yum do the work. Yum itself has to handle the installation anyhow to make sure it actually works. Imagine a case where you are installing a local package foo, which provides a virtual bar, and depends on baz, which requires a package providing bar? Yum has to know about the package being manually installed to be able to satisfy the dependencies properly. An external/separate tool would pretty much be forced to take the local package, calculate its dependencies, request them from Yum, and once those are already installed, install the package requested by the user - the sort of chain above could not ever be properly resolved in this case. Again, there isn't anything wrong with yum installing local packages. It's the natural tool to do the job, and there isn't any compelling reason to do otherwise. "Feels wrong" does not count as a compelling reason, either. ;-) -- Sean Middleditch AwesomePlay Productions, Inc. From fedora at wir-sind-cool.org Tue Sep 7 20:53:47 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 7 Sep 2004 22:53:47 +0200 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <413E19B9.3060005@redhat.com> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E19B9.3060005@redhat.com> Message-ID: <20040907225347.01c8ce06.fedora@wir-sind-cool.org> On Tue, 07 Sep 2004 10:27:37 -1000, Warren Togami wrote: > Ville Skytt? wrote: > > On Tue, 2004-09-07 at 16:39, Matthias Saou wrote: > > > > > >>Now... I'm posting here before bugzilla'ing this since I'd like to know > >>what the general opinion is regarding packages requiring some of their own > >>sub-packages like this. I really think it should be avoided since there are > >>some side-effects like this one that can arise. > > > > > > Agreed. But in case a dependency "loop" like this between some packages > > is not avoidable (in general, not in this particular case) and the order > > in which they are installed inside one transaction matters, one of them > > should use "PreReq" and the other "Requires" in order to break the loop > > in predictable fashion (== PreReq "wins"; the package containing it will > > be installed last). That's what I've heard the difference between > > PreReq and Requires is, anyway. > > > > > > Eh? jbj has confirmed on multiple occasions that there is NO DIFFERENCE > between PreReq and Requires. Sure about that? BuildPreReq and BuildRequires are equal. But quoting RPM documentation: \subsection dependencies_prereqs Prereqs Prereqs are different from requires only in that a PreReq is guaranteed to be installed before the package that contains the PreReq. PreReq's are used only to order packages, otherwise PreReq's are exactly the same as a Requires: dependency. -- Fedora Core release 2 (Tettnang) - Linux 2.6.7-1.494.2.2 loadavg: 1.00 1.21 1.47 From rdieter at math.unl.edu Tue Sep 7 21:03:30 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 07 Sep 2004 16:03:30 -0500 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040907225347.01c8ce06.fedora@wir-sind-cool.org> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E19B9.3060005@redhat.com> <20040907225347.01c8ce06.fedora@wir-sind-cool.org> Message-ID: <413E2222.9000906@math.unl.edu> Michael Schwendt wrote: > On Tue, 07 Sep 2004 10:27:37 -1000, Warren Togami wrote: >>Eh? jbj has confirmed on multiple occasions that there is NO DIFFERENCE >>between PreReq and Requires. > Prereqs are different from requires only in that a PreReq is guaranteed > to be installed before the package that contains the PreReq. PreReq's > are used only to order packages, otherwise PreReq's are exactly the same > as a Requires: dependency. Yep. In my experience, at least for FC2 (and most earlier releases) that both Prereq and Requires(post) *does* make the Prereq'd item get installed first. -- Rex From kyrre at solution-forge.net Tue Sep 7 21:10:36 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 07 Sep 2004 23:10:36 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094590703.3391.83.camel@support02.civic.twp.ypsilanti.mi.us> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> <1094534684.16965.3.camel@chip.laiskiainen.org> <1094580381.2714.12.camel@kyrre> <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> <1094586681.4141.3.camel@kyrre> <1094590703.3391.83.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1094591436.4189.1.camel@kyrre> tir, 07.09.2004 kl. 22.58 skrev Sean Middleditch: > On Tue, 2004-09-07 at 21:51 +0200, Kyrre Ness Sjobak wrote: > > tir, 07.09.2004 kl. 21.19 skrev Sean Middleditch: > > > > If you're alright with requesting a tool like 'rpm-depsolve', I don't > > > see at all how you can argue against just using yum. ;-) > > > > > > > Hmm... somhow using yum to install a local package feels wrong... Hmm... > > think ill acctually have to write some prototype stuff, then. > > "Feels" wrong? How? It makes perfect sense. Nothing wrong with a > separate tool either, although in the end all it would do is just invoke > yum, so it (to me) makes sense to just have yum do the work. > > Yum itself has to handle the installation anyhow to make sure it > actually works. Imagine a case where you are installing a local package > foo, which provides a virtual bar, and depends on baz, which requires a > package providing bar? Yum has to know about the package being manually > installed to be able to satisfy the dependencies properly. An > external/separate tool would pretty much be forced to take the local > package, calculate its dependencies, request them from Yum, and once > those are already installed, install the package requested by the user - > the sort of chain above could not ever be properly resolved in this > case. > > Again, there isn't anything wrong with yum installing local packages. > It's the natural tool to do the job, and there isn't any compelling > reason to do otherwise. "Feels wrong" does not count as a compelling > reason, either. ;-) > Okay. But since i do not know enough to fool around with the internals of yum, ill write it (a prototype) as an external tool. And maybe somone more knowledgable of yum might just like the idea and implement it? > -- > Sean Middleditch > AwesomePlay Productions, Inc. > From wtogami at redhat.com Tue Sep 7 21:14:02 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 07 Sep 2004 11:14:02 -1000 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <413E2222.9000906@math.unl.edu> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E19B9.3060005@redhat.com> <20040907225347.01c8ce06.fedora@wir-sind-cool.org> <413E2222.9000906@math.unl.edu> Message-ID: <413E249A.9050302@redhat.com> Rex Dieter wrote: > >> Prereqs are different from requires only in that a PreReq is guaranteed >> to be installed before the package that contains the PreReq. PreReq's >> are used only to order packages, otherwise PreReq's are exactly the same >> as a Requires: dependency. > > > Yep. In my experience, at least for FC2 (and most earlier releases) > that both Prereq and Requires(post) *does* make the Prereq'd item get > installed first. > jbj, is PreReq exactly equivalent to Requires? warren: except for loop snipping (loops are different problem) yes, identical. when loops are snipped, PreReq is honored, but all Requires: in loop are ignored. again, loops need to be solved in other ways. Looks like I need to go back through all the specs I edited in the past year and see if I need to revert any PreReq to Requires changes... Warren From ville.skytta at iki.fi Tue Sep 7 21:24:21 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 08 Sep 2004 00:24:21 +0300 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <413E19B9.3060005@redhat.com> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E19B9.3060005@redhat.com> Message-ID: <1094592261.17961.158.camel@bobcat.mine.nu> On Tue, 2004-09-07 at 23:27, Warren Togami wrote: > Eh? jbj has confirmed on multiple occasions that there is NO DIFFERENCE > between PreReq and Requires. Well, it has been said by him and others so many times, so many different ways, in so many contexts, with so many "affected" rpm versions that it is not really clear to me (and I bet I'm not the only one), no need to shout. Even jbj's "confirmations" have been sort of self-contradicting. One such example is [1], where the first non-quoted paragraph from jbj mentions "preserving the PreReq: guarantee" for resolving circular dependencies with recent versions of rpm, and the last one says PreReq is "not any more" used for that for the same versions of rpm AFAICT. Whatever it's called nowadays, I don't care; The point made is still valid though: if loops cannot be avoided and the order matters, they should be made predictable with whatever tools are available, if any. If PreReq does not "exist" in the sense it used to any more, one such "tool" which supposedly nowadays at least partially replaces/provides that functionality are "context markers" (ie. Requires(pre) and friends if I've understood _that_ correctly). [1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2003-October/000095.html From alan at redhat.com Tue Sep 7 21:28:25 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 7 Sep 2004 17:28:25 -0400 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040907205737.98756.qmail@web50602.mail.yahoo.com> References: <20040907153947.298cf4be@localhost> <20040907205737.98756.qmail@web50602.mail.yahoo.com> Message-ID: <20040907212825.GA24402@devserv.devel.redhat.com> On Tue, Sep 07, 2004 at 01:57:37PM -0700, Steve G wrote: > >The problem is that during the transaction, httpd-suexec (which got pulled > >in as a dependency) got installed first, outputting the message "apache > >group doesn't exist, using root"... BAD! > > Really bad. I would think this bug needs fast attention. If you download a > package from a 3rd party that has buffer overflows and is setgid, you now have a > buggy program with buffer overflows running as root. Any setgid installation that > fails should never revert to root, it should fail immediately and let the admin > take care of it. Not sure about that - it should certainly not set the setuid bit, but its probably easier for the admin if it still installs it. > Was this filed in bugzilla? Ditto Q: and bug id ? From skvidal at phy.duke.edu Tue Sep 7 21:30:44 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 07 Sep 2004 17:30:44 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094590703.3391.83.camel@support02.civic.twp.ypsilanti.mi.us> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> <1094534684.16965.3.camel@chip.laiskiainen.org> <1094580381.2714.12.camel@kyrre> <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> <1094586681.4141.3.camel@kyrre> <1094590703.3391.83.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1094592644.7958.35.camel@opus.phy.duke.edu> > Yum itself has to handle the installation anyhow to make sure it > actually works. Imagine a case where you are installing a local package > foo, which provides a virtual bar, and depends on baz, which requires a > package providing bar? Yum has to know about the package being manually > installed to be able to satisfy the dependencies properly. An > external/separate tool would pretty much be forced to take the local > package, calculate its dependencies, request them from Yum, and once > those are already installed, install the package requested by the user - > the sort of chain above could not ever be properly resolved in this > case. > > Again, there isn't anything wrong with yum installing local packages. > It's the natural tool to do the job, and there isn't any compelling > reason to do otherwise. "Feels wrong" does not count as a compelling > reason, either. ;-) So here's a compelling reason: I've done a lot of work to make it so a user could 'import yum' and work from there with all the packageSacks from repositories and have access to the rpmdb. But right now I'm fairly positive b/t the above requested features and the AI that other people want yum to become to magically solve all problems and tap you on the shoulder about it that I'm not going to have time to do it. I work on yum in my spare time, it's not part of what I'm paid to do in my day job. So if there are considerable features people want to see developed then they're going to need to put up some functional, non-hacky code for it. The api for yum is, right now, not stable and I'm not sure when it will hit stability but I'm more than willing to talk about what people need and try to make the yum module work even better as a simple module for utility authoring. so right now that's the limitation. -sv From eric.tanguy at physique.univ-nantes.fr Tue Sep 7 21:42:49 2004 From: eric.tanguy at physique.univ-nantes.fr (eric tanguy) Date: Tue, 7 Sep 2004 23:42:49 +0200 (CEST) Subject: SDL-1.2.7-3 SDL-devel--1.2.7-3 and FC2 Message-ID: <33238.82.126.7.163.1094593369.squirrel@webmail.sciences.univ-nantes.fr> Where can i find the sources and the SPECs files used for theses packages in FC2 ? Thanxes Eric From alexander.dalloz at uni-bielefeld.de Tue Sep 7 21:45:57 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Tue, 07 Sep 2004 23:45:57 +0200 Subject: SDL-1.2.7-3 SDL-devel--1.2.7-3 and FC2 In-Reply-To: <33238.82.126.7.163.1094593369.squirrel@webmail.sciences.univ-nantes.fr> References: <33238.82.126.7.163.1094593369.squirrel@webmail.sciences.univ-nantes.fr> Message-ID: <1094593557.3881.1017.camel@serendipity.dogma.lan> Am Di, den 07.09.2004 schrieb eric tanguy um 23:42: > Where can i find the sources and the SPECs files used for theses packages > in FC2 ? > Eric http://ftp.crihan.fr/mirrors/fedora.redhat.com/fedora/linux/core/2/SRPMS/SDL-1.2.7-3.src.rpm Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp Serendipity 23:45:39 up 8 days, 21:02, load average: 1.24, 1.35, 1.25 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From wtogami at redhat.com Tue Sep 7 21:55:18 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 07 Sep 2004 11:55:18 -1000 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <413E249A.9050302@redhat.com> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E19B9.3060005@redhat.com> <20040907225347.01c8ce06.fedora@wir-sind-cool.org> <413E2222.9000906@math.unl.edu> <413E249A.9050302@redhat.com> Message-ID: <413E2E46.8030309@redhat.com> Warren Togami wrote: > > jbj, is PreReq exactly equivalent to Requires? > warren: except for loop snipping (loops are different problem) > yes, identical. > when loops are snipped, PreReq is honored, but all Requires: in > loop are ignored. > again, loops need to be solved in other ways. > > Looks like I need to go back through all the specs I edited in the past > year and see if I need to revert any PreReq to Requires changes... > warren: they *are* exactly equivalent, loops is a different problem, you can't possibly fix. you can't possibly fix by choosing PreReq: or Requires: jbj, *confused* Warren From rms at 1407.org Tue Sep 7 22:00:50 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 07 Sep 2004 23:00:50 +0100 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <413E2E46.8030309@redhat.com> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E19B9.3060005@redhat.com> <20040907225347.01c8ce06.fedora@wir-sind-cool.org> <413E2222.9000906@math.unl.edu> <413E249A.9050302@redhat.com> <413E2E46.8030309@redhat.com> Message-ID: <1094594450.2669.3.camel@roque> On Tue, 2004-09-07 at 11:55 -1000, Warren Togami wrote: > warren: they *are* exactly equivalent, loops is a different > problem, you can't possibly fix. > you can't possibly fix by choosing PreReq: or Requires: > jbj, *confused* You can't fix but you can be graceful about it :) Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dax at gurulabs.com Tue Sep 7 23:27:16 2004 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 07 Sep 2004 17:27:16 -0600 Subject: Kerberos HTTP authentication in RHEL4/FC3/FC2 Message-ID: <1094599636.3987.102.camel@mentorng.gurulabs.com> One of the new features of Mozilla 1.7 touted in the release notes is: "Support for Kerberos HTTP authentication using GSSAPI (benefits Unix-like platforms including Linux and OS X)." Single sign on rules. Whats needed is the addition of --with-gssapi in the spec along with adding krb5-devel to the BuildReq line. I've filed a request in bugzilla. mod_auth_kerb (http://modauthkerb.sourceforge.net/) for Apache makes a nice companion to this. Dax Kelson Guru Labs From linux_4ever at yahoo.com Tue Sep 7 23:47:35 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 7 Sep 2004 16:47:35 -0700 (PDT) Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040907212825.GA24402@devserv.devel.redhat.com> Message-ID: <20040907234735.63730.qmail@web50605.mail.yahoo.com> >>If you download a package from a 3rd party that has buffer overflows and >>is setgid, you now have a buggy program with buffer overflows running as root. > >Not sure about that - it should certainly not set the setuid bit You don't need the setuid bit of root to start with. The setgid bit of root is just enough wiggle room on most systems to compromise the whole thing in a few steps. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From fedora at wir-sind-cool.org Tue Sep 7 22:32:18 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 8 Sep 2004 00:32:18 +0200 Subject: Browsable source/patch/SPEC tree In-Reply-To: <1094516751.4756.91.camel@athlon.localdomain> References: <1094516751.4756.91.camel@athlon.localdomain> Message-ID: <20040908003218.6aa9a706.fedora@wir-sind-cool.org> On Tue, 07 Sep 2004 02:25:51 +0200, Leonard den Ottolander wrote: > Hi, > > When will we see a browsable source/patch/SPEC tree for all released > srpms, so I don't have to download bloody xorg-x11.src.rpm just to have > a peek at the current SPEC file? IMO, most likely when the CVS server becomes available. -- Fedora Core release 2 (Tettnang) - Linux 2.6.7-1.494.2.2 loadavg: 1.00 1.06 1.08 From lonnie at neenet.com Wed Sep 8 01:26:14 2004 From: lonnie at neenet.com (Lonnie Cumberland) Date: Tue, 07 Sep 2004 21:26:14 -0400 Subject: minimal install Message-ID: <413E5FB6.5080004@neenet.com> Hello All, I have been an avid Linux user for a long time now, but must say that I have been using Mandrake most of that time. That was because I thought that it was a little more cutting-edge than Red Hat. Now it seems that the price of that cutting edge was that things do not always work as good as you would like. Anyway, I am very eager to try Fedora and see if it is more stable and compatible with various other applications. I would like to know if someone could either tell me some of the specifics, or direct me to some documentation on the Fedora installer. I want to learn how things are done. For example I would like to know where in the Stage2.img is the list of install types and install messages that you see when it is running. I would like to see what file Fedora uses to define what the "minimal" install is, or "Server" install list of packages because I need the absolute smallest install + XWindows and the smallest (simplest) window manager. Any suggestions would be greatly appreciated, Thanks, Lonnie From skvidal at phy.duke.edu Wed Sep 8 03:25:27 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 07 Sep 2004 23:25:27 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094586681.4141.3.camel@kyrre> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> <1094534684.16965.3.camel@chip.laiskiainen.org> <1094580381.2714.12.camel@kyrre> <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> <1094586681.4141.3.camel@kyrre> Message-ID: <1094613927.12720.15.camel@binkley> > Hmm... somhow using yum to install a local package feels wrong... Hmm... > think ill acctually have to write some prototype stuff, then. > > rpm-depsolve, here i come! :P > > Always wanted to create some "core" utility... > yum install /some/path/to/an/rpm yum looks for that file if it can't find it, it exits and laughs at the user, as it should be. :) if it finds it then it reads in the header and other information and makes a special local repository in memory for it. it puts the package into a transaction set (just like a normal package) and checks it. If it can't find a resolution it looks through the repositories (as normal) and adds packages that do resolve it. I've done some thinking about it recently and it's really not all that special of a case. The trick is tracking the package state in a sane manner for putting in the transaction. -sv From drepper at redhat.com Wed Sep 8 05:11:16 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Tue, 07 Sep 2004 22:11:16 -0700 Subject: Kerberos HTTP authentication in RHEL4/FC3/FC2 In-Reply-To: <1094599636.3987.102.camel@mentorng.gurulabs.com> References: <1094599636.3987.102.camel@mentorng.gurulabs.com> Message-ID: <413E9474.9070809@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dax Kelson wrote: > One of the new features of Mozilla 1.7 touted in the release notes is: > > "Support for Kerberos HTTP authentication using GSSAPI (benefits > Unix-like platforms including Linux and OS X)." > > Single sign on rules. Have you even looked at the Mozilla in FC3? The negotiateauth component is present and... > mod_auth_kerb (http://modauthkerb.sourceforge.net/) for Apache makes a > nice companion to this. ... mod_auth_kerb is also present. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBPpR02ijCOnn/RHQRAmQ2AJ0Qp6sfEzo0qrxow/N6PCh/QjhHFACgkF+6 yKK9LfsAbOs8huu7K3rJpgA= =bXy0 -----END PGP SIGNATURE----- From leonard at den.ottolander.nl Wed Sep 8 07:24:49 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 08 Sep 2004 09:24:49 +0200 Subject: Browsable source/patch/SPEC tree In-Reply-To: <20040908003218.6aa9a706.fedora@wir-sind-cool.org> References: <1094516751.4756.91.camel@athlon.localdomain> <20040908003218.6aa9a706.fedora@wir-sind-cool.org> Message-ID: <1094628288.4751.4.camel@athlon.localdomain> Hello Michael, On Wed, 2004-09-08 at 00:32, Michael Schwendt wrote: > > When will we see a browsable source/patch/SPEC tree for all released > > srpms, so I don't have to download bloody xorg-x11.src.rpm just to have > > a peek at the current SPEC file? > > IMO, most likely when the CVS server becomes available. Is that a promise? ;-) Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mnemo at minimum.se Wed Sep 8 14:58:57 2004 From: mnemo at minimum.se (Martin Olsson) Date: Wed, 08 Sep 2004 07:58:57 -0700 Subject: minimal install In-Reply-To: <413E5FB6.5080004@neenet.com> References: <413E5FB6.5080004@neenet.com> Message-ID: <413F1E31.4030701@minimum.se> Last time I checked (in FC2) the minimal install was unfortunately heavily bloated. On the other hand, when I did the 'install everything' everything worked right away including, usb keyboard (whichs hangs in suse), flatscreen at 1280x1024 and sound. regards, martin Lonnie Cumberland wrote: > Hello All, > > I have been an avid Linux user for a long time now, but must say that I > have been using Mandrake most of that time. That was because I thought > that it was a little more cutting-edge than Red Hat. Now it seems that > the price of that cutting edge was that things do not always work as > good as you would like. > > Anyway, I am very eager to try Fedora and see if it is more stable and > compatible with various other applications. > > I would like to know if someone could either tell me some of the > specifics, or direct me to some documentation on the Fedora installer. > I want to learn how things are done. > > For example I would like to know where in the Stage2.img is the list of > install types and install messages that you see when it is running. > > I would like to see what file Fedora uses to define what the "minimal" > install is, or "Server" install list of packages because I need the > absolute smallest install + XWindows and the smallest (simplest) window > manager. > > Any suggestions would be greatly appreciated, > Thanks, > Lonnie > > From jorton at redhat.com Wed Sep 8 07:59:51 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 8 Sep 2004 08:59:51 +0100 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040907153947.298cf4be@localhost> References: <20040907153947.298cf4be@localhost> Message-ID: <20040908075951.GA20605@redhat.com> On Tue, Sep 07, 2004 at 03:39:47PM +0200, Matthias Saou wrote: > I've ran into a real problem where package A requires B, and B requires A : > The current httpd and httpd-suexec packages from FC Development. I've just > installed FC Test from the latest ISOs, a minimal system, then did "yum > install httpd" from there. The problem is that during the transaction, > httpd-suexec (which got pulled in as a dependency) got installed first, > outputting the message "apache group doesn't exist, using root"... BAD! > Yes, the suexec binary is now sgid root on that system instead of sgid > apache. Ouch :( > Now... I'm posting here before bugzilla'ing this since I'd like to know > what the general opinion is regarding packages requiring some of their own > sub-packages like this. I really think it should be avoided since there are > some side-effects like this one that can arise. Furthermore, I don't get > why httpd-suexec nor php-mbstring (as another example) got split off... the > main purpose I can see for such cases is for the original package to be > overridden by another one providing the same functionality, like the X Mesa > libraries. php-mbstring is not required by php in FC3, it's required in the FC2 update to avoid silently removing functionality during the update or a later upgrade to FC3. joe From jorton at redhat.com Wed Sep 8 08:07:07 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 8 Sep 2004 09:07:07 +0100 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <1094592261.17961.158.camel@bobcat.mine.nu> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E19B9.3060005@redhat.com> <1094592261.17961.158.camel@bobcat.mine.nu> Message-ID: <20040908080707.GB20605@redhat.com> On Wed, Sep 08, 2004 at 12:24:21AM +0300, Ville Skytt? wrote: > If PreReq does not "exist" in the sense it used to any more, one such > "tool" which supposedly nowadays at least partially replaces/provides > that functionality are "context markers" (ie. Requires(pre) and friends > if I've understood _that_ correctly). > > [1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2003-October/000095.html I thought Requires(pre) and friends are just for dependencies of the scripts? Can anyone state definitively (and preferably in plain English), if I have in the httpd-suexec subpackage: PreReq: httpd the files contained in said package will be installed only after the %pre script of the httpd package has run? joe From leonard at den.ottolander.nl Wed Sep 8 07:42:51 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 08 Sep 2004 09:42:51 +0200 Subject: Missing KDE and lha announcements Message-ID: <1094629371.4751.10.camel@athlon.localdomain> Hi, I've seen updates for kde and lha available since yesterday, but haven't seen announcements for them yet... Leonard. -- mount -t life -o ro /dev/dna /genetic/research From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Sep 8 08:16:29 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 8 Sep 2004 10:16:29 +0200 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040908075951.GA20605@redhat.com> References: <20040907153947.298cf4be@localhost> <20040908075951.GA20605@redhat.com> Message-ID: <20040908101629.3754c35a@localhost> Joe Orton wrote : [...] > php-mbstring is not required by php in FC3, it's required in the FC2 > update to avoid silently removing functionality during the update or a > later upgrade to FC3. Thanks for clarifying this one, it makes sense ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.54 0.63 0.55 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Sep 8 08:18:28 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 8 Sep 2004 10:18:28 +0200 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040907212825.GA24402@devserv.devel.redhat.com> References: <20040907153947.298cf4be@localhost> <20040907205737.98756.qmail@web50602.mail.yahoo.com> <20040907212825.GA24402@devserv.devel.redhat.com> Message-ID: <20040908101828.3ced2e46@localhost> Alan Cox wrote : [...] > > Was this filed in bugzilla? > > Ditto Q: and bug id ? #132045 "httpd and httpd-suexec dependency reciprocity" : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132045 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.85 0.69 0.57 From eric.tanguy at physique.univ-nantes.fr Wed Sep 8 08:22:13 2004 From: eric.tanguy at physique.univ-nantes.fr (eric tanguy) Date: Wed, 8 Sep 2004 10:22:13 +0200 (CEST) Subject: SDL-1.2.7-3 SDL-devel--1.2.7-3 and FC2 In-Reply-To: <1094593557.3881.1017.camel@serendipity.dogma.lan> References: <33238.82.126.7.163.1094593369.squirrel@webmail.sciences.univ-nantes.fr> <1094593557.3881.1017.camel@serendipity.dogma.lan> Message-ID: <57899.193.52.109.12.1094631733.squirrel@webmail.sciences.univ-nantes.fr> Thanks Eric > Am Di, den 07.09.2004 schrieb eric tanguy um 23:42: > >> Where can i find the sources and the SPECs files used for theses >> packages in FC2 ? > >> Eric > > http://ftp.crihan.fr/mirrors/fedora.redhat.com/fedora/linux/core/2/SRPMS/SDL-1.2.7-3.src.rpm > > Alexander > > > -- > Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 > Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp > Serendipity 23:45:39 up 8 days, 21:02, load average: 1.24, 1.35, 1.25 From jgorny at aurox.org Wed Sep 8 08:04:17 2004 From: jgorny at aurox.org (Jaroslaw Gorny) Date: Wed, 8 Sep 2004 10:04:17 +0200 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <413E16E2.1090100@math.unl.edu> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E16E2.1090100@math.unl.edu> Message-ID: <20040908100417.4a3271c1@pro8000x.aurox.org> On Tue, 07 Sep 2004 15:15:30 -0500 Rex Dieter wrote: > Ville Skytt? wrote: > > > Agreed. But in case a dependency "loop" like this between some > > packages is not avoidable > > In many cases where foo Requires foo-bar and foo-bar Requires foo, > IMO, there shouldn't *be* a foo-bar subpackage at all. One example > off the top of my head: > openoffice.org > openoffice.org-libs > What's the point of the separate -libs subpkg? > I agree. Another example that I was thinking about: rpm and popt. They *are* both built from the same SRPM (rpm). rpm is always in the system, and it requires popt in the exact version. Why not build *single* rpm containing them both??? Jarek From veillard at redhat.com Wed Sep 8 08:41:45 2004 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 8 Sep 2004 04:41:45 -0400 Subject: Missing KDE and lha announcements In-Reply-To: <1094629371.4751.10.camel@athlon.localdomain> References: <1094629371.4751.10.camel@athlon.localdomain> Message-ID: <20040908084145.GO5356@redhat.com> On Wed, Sep 08, 2004 at 09:42:51AM +0200, Leonard den Ottolander wrote: > Hi, > > I've seen updates for kde and lha available since yesterday, but haven't > seen announcements for them yet... Just wondering, you really have an use case for lha ??? Who is using this nowadays ? Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From wtogami at redhat.com Wed Sep 8 08:54:44 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 07 Sep 2004 22:54:44 -1000 Subject: Missing KDE and lha announcements In-Reply-To: <20040908084145.GO5356@redhat.com> References: <1094629371.4751.10.camel@athlon.localdomain> <20040908084145.GO5356@redhat.com> Message-ID: <413EC8D4.7010709@redhat.com> Daniel Veillard wrote: > On Wed, Sep 08, 2004 at 09:42:51AM +0200, Leonard den Ottolander wrote: > >>Hi, >> >>I've seen updates for kde and lha available since yesterday, but haven't >>seen announcements for them yet... > > > Just wondering, you really have an use case for lha ??? Who is using > this nowadays ? > > Daniel > I only see it in weird 16-bit DOS self extracting archives from Taiwanese manufacturers. =( Warren From leonard at den.ottolander.nl Wed Sep 8 07:17:33 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 08 Sep 2004 09:17:33 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> <1094534684.16965.3.camel@chip.laiskiainen.org> <1094580381.2714.12.camel@kyrre> <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1094627852.4751.1.camel@athlon.localdomain> Hello Sean, On Tue, 2004-09-07 at 21:19, Sean Middleditch wrote: > If you're alright with requesting a tool like 'rpm-depsolve', I don't > see at all how you can argue against just using yum. ;-) Take a look at the man page for rpm and scan for --aid. You need to setup the rpmdb for the dependencies to get resolved. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From wtogami at redhat.com Wed Sep 8 09:28:05 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 07 Sep 2004 23:28:05 -1000 Subject: vsftpd (GPL) and openssl? Message-ID: <413ED0A5.5050009@redhat.com> I just noticed this in cvs-commits. Another new instance of GPL linking with openssl. Problematic? Even if the vsftpd authors wont sue us for any possible GPL violation, does this possibly open a weak link in vsftpd's supposedly "very secure"ness? Even if ssl is disabled by default in our config? Please be sure... Warren Togami wtogami at redhat.com -------- Original Message -------- Subject: rpms/vsftpd vsftpd-2.0.1-build_ssl.patch,NONE,1.1 vsftpd.spec,1.44,1.45 Date: Wed, 8 Sep 2004 03:55:46 -0400 From: Radek Vokal Reply-To: cvs-commits-list at redhat.com Organization: Red Hat Inc. Internal News Newsgroups: rhat.general.cvs.cvs-rhlinux Update of /cvs/pkgs/rpms/vsftpd In directory cvs.devel.redhat.com:/tmp/cvs-serv32111 Modified Files: vsftpd.spec Added Files: vsftpd-2.0.1-build_ssl.patch Log Message: - added patch by Jan Kratochvil for SSL support vsftpd-2.0.1-build_ssl.patch: builddefs.h | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) --- NEW FILE vsftpd-2.0.1-build_ssl.patch --- --- vsftpd-2.0.1/builddefs.h-orig 2004-07-02 16:36:59.000000000 +0200 +++ vsftpd-2.0.1/builddefs.h 2004-08-17 13:40:42.834402983 +0200 @@ -3,7 +3,7 @@ #undef VSF_BUILD_TCPWRAPPERS #define VSF_BUILD_PAM -#undef VSF_BUILD_SSL +#define VSF_BUILD_SSL #endif /* VSF_BUILDDEFS_H */ Index: vsftpd.spec =================================================================== RCS file: /cvs/pkgs/rpms/vsftpd/vsftpd.spec,v retrieving revision 1.44 retrieving revision 1.45 diff -u -r1.44 -r1.45 --- vsftpd.spec 27 Aug 2004 10:56:11 -0000 1.44 +++ vsftpd.spec 8 Sep 2004 07:55:44 -0000 1.45 @@ -3,7 +3,7 @@ Summary: vsftpd - Very Secure Ftp Daemon Name: vsftpd Version: 2.0.1 -Release: 2 +Release: 3 License: GPL Group: System Environment/Daemons URL: http://vsftpd.beasts.org/ @@ -19,10 +19,17 @@ Patch4: vsftpd-1.5.1-libs.patch Patch5: vsftpd-2.0.1-signal.patch Patch6: vsftpd-1.2.1-conffile.patch +Patch7: vsftpd-2.0.1-build_ssl.patch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root %if %{tcp_wrappers} BuildPrereq: tcp_wrappers %endif +BuildRequires: pam-devel +Requires: pam +BuildRequires: libcap-devel +Requires: libcap +BuildRequires: openssl-devel +Requires: openssl # for -fpie BuildPrereq: gcc > gcc-3.2.3-13, binutils > binutils-2.14.90.0.4-24, glibc-devel >= 2.3.2-45 Requires: logrotate @@ -45,6 +52,7 @@ cp %{SOURCE1} . %patch5 -p1 -b .signal %patch6 -p1 +%patch7 -p1 -b .build_ssl %build %ifarch s390x @@ -52,7 +60,7 @@ %else make CFLAGS="$RPM_OPT_FLAGS -fpie -pipe" \ %endif - LINK="-pie" \ + LINK="-pie -lssl" \ %{?_smp_mflags} %install @@ -102,10 +110,13 @@ /var/ftp %changelog -* Fri Aug 27 2004 Radek Vokal +* Wed Sep 08 2004 Jan Kratochvil +- update for 2.0.1 for SSL + +* Fri Aug 27 2004 Radek Vokal 2.0.1-2 - vsftpd.conf file changed, default IPv6 support -* Fri Aug 20 2004 Radek Vokal +* Fri Aug 20 2004 Radek Vokal 2.0.1-1 - tcp_wrapper patch updated, signal patch updated - upgrade to 2.0.1, fixes several bugs, RHEL and FC builds From rms at 1407.org Wed Sep 8 09:31:43 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 08 Sep 2004 10:31:43 +0100 Subject: vsftpd (GPL) and openssl? In-Reply-To: <413ED0A5.5050009@redhat.com> References: <413ED0A5.5050009@redhat.com> Message-ID: <1094635903.3042.5.camel@roque> On Tue, 2004-09-07 at 23:28 -1000, Warren Togami wrote: > I just noticed this in cvs-commits. Another new instance of GPL linking > with openssl. Problematic? > > Even if the vsftpd authors wont sue us for any possible GPL violation, > does this possibly open a weak link in vsftpd's supposedly "very > secure"ness? Even if ssl is disabled by default in our config? Please > be sure... I think the case is beggining to grow for inclusion of GNUtls. GNUtls has a library which is alledgedly API-compatible with openssl. I have never tested. I'm willing to help with packaging it if no one is doing it right already, which is better than not having some SSL implementation on GPL packages. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Wed Sep 8 09:38:02 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 07 Sep 2004 23:38:02 -1000 Subject: vsftpd (GPL) and openssl? In-Reply-To: <1094635903.3042.5.camel@roque> References: <413ED0A5.5050009@redhat.com> <1094635903.3042.5.camel@roque> Message-ID: <413ED2FA.8000409@redhat.com> Rui Miguel Seabra wrote: > > I think the case is beggining to grow for inclusion of GNUtls. > > GNUtls has a library which is alledgedly API-compatible with openssl. > I have never tested. > > I'm willing to help with packaging it if no one is doing it right > already, which is better than not having some SSL implementation on GPL > packages. > > Rui > https://bugzilla.fedora.us/show_bug.cgi?id=1018 Looks like it needs someone to adopt it, cleanup and update. The deps might need updating too. Warren Togami wtogami at redhat.com From rc040203 at freenet.de Wed Sep 8 10:00:41 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 08 Sep 2004 12:00:41 +0200 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040908080707.GB20605@redhat.com> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E19B9.3060005@redhat.com> <1094592261.17961.158.camel@bobcat.mine.nu> <20040908080707.GB20605@redhat.com> Message-ID: <1094637641.22952.1780.camel@mccallum.corsepiu.local> On Wed, 2004-09-08 at 10:07, Joe Orton wrote: > On Wed, Sep 08, 2004 at 12:24:21AM +0300, Ville Skytt? wrote: > > If PreReq does not "exist" in the sense it used to any more, one such > > "tool" which supposedly nowadays at least partially replaces/provides > > that functionality are "context markers" (ie. Requires(pre) and friends > > if I've understood _that_ correctly). > > > > [1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2003-October/000095.html > > I thought Requires(pre) and friends are just for dependencies of the > scripts? Hmm, I think, you're mixing this up with BuildPreRequires and BuildRequires. > Can anyone state definitively (and preferably in plain English), if I > have in the httpd-suexec subpackage: > > PreReq: httpd > > the files contained in said package will be installed only after the > %pre script of the httpd package has run? Basically, "PreReq: httpd" denotes that "httpd" must be installed when the package is installed. At least some versions of rpm (e.g. the version shipped with FC2) re-sort package installation order if being given several packages: Example: 2 packages, gaga and gaga-addon, with gaga-addon using PreReq: gaga # rpm -Uv gaga-0-0.fdr.x.i386.rpm gaga-addon-0-0.fdr.x.i386.rpm Preparing packages for installation... gaga-0-0.fdr.x gaga-addon-0-0.fdr.x # rpm -e gaga gaga-addon # rpm -Uv gaga-addon-0-0.fdr.x.i386.rpm gaga-0-0.fdr.x.i386.rpm Preparing packages for installation... gaga-0-0.fdr.x gaga-addon-0-0.fdr.x [Note: rpm modified installation order] If installers (up2date/yum/apt) behave differently (I haven't checked), they'd have to be considered broken :-) Ralf From ralph+fedora at strg-alt-entf.org Wed Sep 8 10:04:25 2004 From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt) Date: Wed, 8 Sep 2004 12:04:25 +0200 Subject: Missing KDE and lha announcements In-Reply-To: <20040908084145.GO5356@redhat.com> References: <1094629371.4751.10.camel@athlon.localdomain> <20040908084145.GO5356@redhat.com> Message-ID: <20040908100425.GB15885@br-online.de> Daniel Veillard wrote: > On Wed, Sep 08, 2004 at 09:42:51AM +0200, Leonard den Ottolander wrote: > > Hi, > > > > I've seen updates for kde and lha available since yesterday, but haven't > > seen announcements for them yet... > > Just wondering, you really have an use case for lha ??? Who is using > this nowadays ? Well, Winzip will unpack it. And a lha-archive may contain viruses. So the use case is: virus scanners. And yes, I do find a few lha-packed viruses in my logs :) Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ynakai at redhat.com Wed Sep 8 10:17:06 2004 From: ynakai at redhat.com (Nakai) Date: Wed, 8 Sep 2004 19:17:06 +0900 Subject: Missing KDE and lha announcements In-Reply-To: <413EC8D4.7010709@redhat.com> References: <1094629371.4751.10.camel@athlon.localdomain> <20040908084145.GO5356@redhat.com> <413EC8D4.7010709@redhat.com> Message-ID: <200409081017.i88AH6M28456@ns.tokyo.redhat.com> Japanese government publishes archives of official documents in lha format. That's popular here.. But I know Japanese standard is not global standard, global standard is not Japanese standard - how is this in your countries? zip? -- Nakai On Tue, 07 Sep 2004 22:54:44 -1000 Warren Togami wrote: > Daniel Veillard wrote: > > On Wed, Sep 08, 2004 at 09:42:51AM +0200, Leonard den Ottolander wrote: > > > >>Hi, > >> > >>I've seen updates for kde and lha available since yesterday, but haven't > >>seen announcements for them yet... > > > > > > Just wondering, you really have an use case for lha ??? Who is using > > this nowadays ? > > > > Daniel > > > > I only see it in weird 16-bit DOS self extracting archives from > Taiwanese manufacturers. =( > > Warren > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From jnovy at redhat.com Wed Sep 8 10:38:55 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 08 Sep 2004 12:38:55 +0200 Subject: umb-scheme package removal Message-ID: <1094639935.3535.56.camel@localhost.localdomain> Hi Fedora folks, umb-scheme package is planned to be removed from FC3 and replaced by slib. The reason is that the most of packages are dependent on umb-scheme because of slib (such as Guile, etc.) and the thing what comes in question is whether the umb-scheme is used by someone. Furthermore encapsulation of slib into umb-scheme denies visibility of the slib authors. For more info see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125921 Note that umb-scheme will be still present in FC3t2. greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From pekkas at netcore.fi Wed Sep 8 11:02:41 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 8 Sep 2004 14:02:41 +0300 (EEST) Subject: vsftpd (GPL) and openssl? In-Reply-To: <1094635903.3042.5.camel@roque> Message-ID: On Wed, 8 Sep 2004, Rui Miguel Seabra wrote: > On Tue, 2004-09-07 at 23:28 -1000, Warren Togami wrote: > > I just noticed this in cvs-commits. Another new instance of GPL linking > > with openssl. Problematic? > > > > Even if the vsftpd authors wont sue us for any possible GPL violation, > > does this possibly open a weak link in vsftpd's supposedly "very > > secure"ness? Even if ssl is disabled by default in our config? Please > > be sure... > > I think the case is beggining to grow for inclusion of GNUtls. Replacing OpenSSL with GNUtls would very likely increase, not decrease, the security implications. >From the license/policitical/religious point of view, it might be closer in spirit to the vsftpd though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rms at 1407.org Wed Sep 8 11:13:38 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 08 Sep 2004 12:13:38 +0100 Subject: vsftpd (GPL) and openssl? In-Reply-To: References: Message-ID: <1094642018.3042.10.camel@roque> On Wed, 2004-09-08 at 14:02 +0300, Pekka Savola wrote: > On Wed, 8 Sep 2004, Rui Miguel Seabra wrote: > > On Tue, 2004-09-07 at 23:28 -1000, Warren Togami wrote: > > > I just noticed this in cvs-commits. Another new instance of GPL linking > > > with openssl. Problematic? > > > > > > Even if the vsftpd authors wont sue us for any possible GPL violation, > > > does this possibly open a weak link in vsftpd's supposedly "very > > > secure"ness? Even if ssl is disabled by default in our config? Please > > > be sure... > > > > I think the case is beggining to grow for inclusion of GNUtls. > > Replacing OpenSSL with GNUtls would very likely increase, not > decrease, the security implications. Inclusion. Not replacement. The inclusion would be specifically intended to solve... > >From the license/policitical/religious point of view, it might be > closer in spirit to the vsftpd though. Anyway, do you have any data to backup your defamatory statement? OpenSSL hasn't exactly been void of serious issues... Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From leonard at den.ottolander.nl Wed Sep 8 11:34:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 08 Sep 2004 13:34:50 +0200 Subject: Missing KDE and lha announcements In-Reply-To: <20040908084145.GO5356@redhat.com> References: <1094629371.4751.10.camel@athlon.localdomain> <20040908084145.GO5356@redhat.com> Message-ID: <1094643289.4751.18.camel@athlon.localdomain> Hi Daniel, On Wed, 2004-09-08 at 10:41, Daniel Veillard wrote: > > I've seen updates for kde and lha available since yesterday, but haven't > > seen announcements for them yet... > > Just wondering, you really have an use case for lha ??? Who is using > this nowadays ? There is probably much more stuff installed on my system that never gets used. Could be that I added this by hand (I usually just add all archivers). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From david.avery at united.com Wed Sep 8 14:03:35 2004 From: david.avery at united.com (david avery) Date: Wed, 08 Sep 2004 14:03:35 +0000 Subject: yum 2.1.x fails when using firewall Message-ID: <1094652216.15798.7.camel@i777linux.dentk.com> yum 2.1.x is failing when trying to get repodata/*/xml.gz. it gets repomd.xml OK and then sends a bad packet before trying to get repodata/primary.xml.gz the fire wall returns a HTTP 400 and the connection dies http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132061 dave From Axel.Thimm at ATrpms.net Wed Sep 8 14:53:54 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 8 Sep 2004 16:53:54 +0200 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040908080707.GB20605@redhat.com> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E19B9.3060005@redhat.com> <1094592261.17961.158.camel@bobcat.mine.nu> <20040908080707.GB20605@redhat.com> Message-ID: <20040908145354.GA4808@neu.physik.fu-berlin.de> On Wed, Sep 08, 2004 at 09:07:07AM +0100, Joe Orton wrote: > On Wed, Sep 08, 2004 at 12:24:21AM +0300, Ville Skytt? wrote: > > If PreReq does not "exist" in the sense it used to any more, one such > > "tool" which supposedly nowadays at least partially replaces/provides > > that functionality are "context markers" (ie. Requires(pre) and friends > > if I've understood _that_ correctly). > > > > [1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2003-October/000095.html > > I thought Requires(pre) and friends are just for dependencies of the > scripts? Yes, you usually want to ensure that script interpreteres are installed prior to scriptel runtime :) > Can anyone state definitively (and preferably in plain English), if I > have in the httpd-suexec subpackage: > > PreReq: httpd > > the files contained in said package will be installed only after the > %pre script of the httpd package has run? That's the idea, you could test with rpm -ihv httpd httpd-suexec vs rpm -ihv httpd-suexec httpd Output should be in both cases the same (first httpd then httpd-suexec), if you employ the above change. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dkl at redhat.com Wed Sep 8 14:49:03 2004 From: dkl at redhat.com (Dave Lawrence) Date: Wed, 08 Sep 2004 10:49:03 -0400 Subject: Where to report a missing component in bugzilla? In-Reply-To: <20040830201437.0aa59923@localhost> References: <20040830200922.7635c048@localhost> <20040830201437.0aa59923@localhost> Message-ID: <413F1BDF.601@redhat.com> Matthias Saou wrote: >Matthias Saou wrote : > > > >>My problem is that sysfsutils (which is from the sysfsutils source rpm, >>I've checked) isn't listed in the current Fedora Core Development >>components, and I need to report that it's missing /sbin/ldconfig >>scriplets:-) >> >> > >And now, the exact same with aiksaurus (in aiksaurus-gtk) :-/ > >Matthias > > > Should both be there in Fedora Core category now. Dave From kyrre at solution-forge.net Wed Sep 8 15:34:17 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 08 Sep 2004 17:34:17 +0200 Subject: Notes on Yum Changes In-Reply-To: <1094627852.4751.1.camel@athlon.localdomain> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> <1094534684.16965.3.camel@chip.laiskiainen.org> <1094580381.2714.12.camel@kyrre> <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> <1094627852.4751.1.camel@athlon.localdomain> Message-ID: <1094653971.2692.0.camel@kyrre> ons, 08.09.2004 kl. 09.17 skrev Leonard den Ottolander: > Hello Sean, > > On Tue, 2004-09-07 at 21:19, Sean Middleditch wrote: > > If you're alright with requesting a tool like 'rpm-depsolve', I don't > > see at all how you can argue against just using yum. ;-) > > Take a look at the man page for rpm and scan for --aid. You need to > setup the rpmdb for the dependencies to get resolved. > > Leonard. I did. But i don't understand what it means... --aid Add suggested packages to the transaction set when needed. > > -- > mount -t life -o ro /dev/dna /genetic/research > > From paul at frields.com Wed Sep 8 17:09:34 2004 From: paul at frields.com (Paul W. Frields) Date: Wed, 08 Sep 2004 13:09:34 -0400 Subject: Notes on Yum Changes In-Reply-To: <1094653971.2692.0.camel@kyrre> References: <1094437034.4702.13.camel@binkley> <413C02B8.4010102@hhs.nl> <413C1AC2.4080509@valuecommerce.com> <1094474921.10563.22.camel@fleur.hogwarts.jk> <1094484746.2635.42.camel@roque> <1094490857.4702.29.camel@binkley> <1094497446.2670.10.camel@roque> <1094499528.28275.11.camel@kyrre> <1094505995.4720.1.camel@stargrazer> <1094515239.4702.79.camel@binkley> <1094534684.16965.3.camel@chip.laiskiainen.org> <1094580381.2714.12.camel@kyrre> <1094584771.3391.60.camel@support02.civic.twp.ypsilanti.mi.us> <1094627852.4751.1.camel@athlon.localdomain> <1094653971.2692.0.camel@kyrre> Message-ID: <1094663374.20256.0.camel@bettie.internal.frields.org> On Wed, 2004-09-08 at 11:34, Kyrre Ness Sjobak wrote: > > > If you're alright with requesting a tool like 'rpm-depsolve', I don't > > > see at all how you can argue against just using yum. ;-) > > > > Take a look at the man page for rpm and scan for --aid. You need to > > setup the rpmdb for the dependencies to get resolved. > I did. But i don't understand what it means... > > --aid Add suggested packages to the transaction set when needed. q.v. http://www.redhat.com/advice/tips/rhce/rpm.html -- Paul W. Frields, RHCE From buildsys at redhat.com Wed Sep 8 17:59:57 2004 From: buildsys at redhat.com (Build System) Date: Wed, 8 Sep 2004 13:59:57 -0400 Subject: rawhide report: 20040908 changes Message-ID: <200409081759.i88Hxvm32516@porkchop.devel.redhat.com> Updated Packages: ImageMagick-6.0.6.2-2 --------------------- * Sat Sep 04 2004 Bill Nottingham 6.0.6.2-2 - move libWand out of -devel, fix requirements (#131767) MAKEDEV-3.12-1 -------------- * Tue Sep 07 2004 Nalin Dahyabhai 3.12-1 - add a -a (alwayscreate) flag, to skip checking if the device node is already present with the desired permissions/ownership/context - add a -u (udev permissions) flag, to spit out udev-style permissions settings for whatever nodes we would be creating * Mon Sep 06 2004 Nalin Dahyabhai - add a context-directory flag, for using contexts assigned to devices created in the -d directory look like they would if it was the -D directory - create intermediate subdirectories in exact (-x) mode * Sat Sep 04 2004 Nalin Dahyabhai - don't even try to reset the default file creation context if SELinux is disabled (#131776) abiword-2.0.11-2 ---------------- * Mon Sep 06 2004 Caolan McNamara 1:2.0.11-2 - merge abiword.keys into abiword.desktop anaconda-10.0.2-0.20040907223732 -------------------------------- * Tue Sep 07 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode arts-1.3.0-3 ------------ * Fri Sep 03 2004 Colin Walters 1.3.0-3 - Fix trivial conflict in glib patch and reapply; this removes dependency on glib2.0 and therefore prevents symbol clashes with applications loading arts still using glib 1.2, like XMMS. * Mon Aug 23 2004 Than Ngo 1.3.0-2 - add missing epoch tag authconfig-4.6.4-2 ------------------ * Wed Aug 25 2004 Jindrich Novy 4.6.4-2 - modified authconfig-gtk interface to fit lower resolution screens (#127175) - modified accelerators in authconfig-gtk (#125797) - updated package dependencies (#125306) * Tue Aug 24 2004 Jindrich Novy - updated configure scripts - warnfixes and minor hacks * Mon Jun 07 2004 Nalin Dahyabhai 4.6.4-1 - tweak account management to fix #55193 correctly - require anything we might want to run in the gui subpackage because it doesn't warn about missing things and you don't have a terminal to see error messages about missing commands - properly display the domain in the GUI join dialog (#124621) bogl-0.1.18-2 ------------- * Mon Sep 06 2004 Jeremy Katz - 0:0.1.18-2 - fPIC on ppc too (#130719) cdrdao-1.1.9-3 -------------- * Tue Sep 07 2004 Harald Hoyer - 1.1.9-3 - build requires newer cdrecord-devel control-center-2.7.1-3 ---------------------- * Tue Sep 07 2004 Matthias Clasen - 1:2.7.1-3 - don't show hyper if its mapped to super (#131635) diskdumputils-0.6.1-0 --------------------- * Fri Sep 03 2004 Nobuhiro Tachino (0.6.1) - Always load scsi_dump and ide-dump because scsi_uniq_id becomes obsolete. finger-0.17-26 -------------- * Mon Sep 06 2004 Radek Vokal 0.17-26 - rebuilt firefox-0.9.3-8 --------------- * Fri Sep 03 2004 Christopher Aillon 0:0.9.3-8 - Fixup .desktop entry Name, GenericName, and Comment (#131602) - Add MimeType desktop entry (patch from jrb at redhat.com) - Build with --disable-xprint gkrellm-2.2.2-2 --------------- * Mon Sep 06 2004 Karsten Hopp 2.2.2-2 - change group of wireless subpackage (#131699) - add icon glibc-2.3.3-49 -------------- * Fri Sep 03 2004 Jakub Jelinek 2.3.3-49 - update from CVS - fix linuxthreads tst-cancel{[45],-static} * Fri Sep 03 2004 Jakub Jelinek 2.3.3-48 - update from CVS - fix pthread_cond_destroy (BZ #342) - fix fnmatch without FNM_NOESCAPE (BZ #361) - fix ppc32 setcontext (BZ #357) - add NPTL support for i386 glibc (only if run on i486 or higher CPU) - add __NR_waitid defines for i386, x86_64 and sparc* gnumeric-1.2.13-2 ----------------- * Mon Sep 06 2004 Caolan McNamara 1.2.13-2 - update .keys to .desktop gnuplot-4.0.0-3 --------------- * Tue Sep 07 2004 Karsten Hopp 4.0.0-3 - fix typo in preun script httpd-2.0.50-6 -------------- * Sun Sep 05 2004 Joe Orton 2.0.50-6 - include /etc/sysconfig/httpd template (#112085) - pass $OPTIONS in httpd invocations in apachectl (#115910) - do not pass $OPTIONS to apachectl from init script - start httpd in C locale by default from apachectl hwdata-0.130-1 -------------- * Sat Sep 04 2004 Bill Nottingham 0.130-1 - trim pcitable - now just ids/drivers iproute-2.6.9-2 --------------- * Mon Sep 06 2004 Radek Vokal 2.6.9-2 - fixed possible buffer owerflow, path by Steve Grubb * Wed Sep 01 2004 Radek Vokal 2.6.9-1 - updated to iproute-2.6.9, spec file change, patches cleared * Tue Jun 15 2004 Elliot Lee - rebuilt kdebase-3.3.0-2 --------------- * Sun Sep 05 2004 Than Ngo 6:3.3.0-2 - Own mozilla plugin dir, bug #131667 - Fix hangup in kicker when user clears clipboard history fom klipper - Fix df problem on AFS again kernel-2.6.8-1.541 ------------------ kudzu-1.1.87-1 -------------- * Tue Sep 07 2004 Jeremy Katz - 1.1.87-1 - add probing of ibmveth and ibmvscsic for POWER5 boxes * Fri Sep 03 2004 Bill Nottingham 1.1.86-1 - read pci device descriptions from pci.ids, not pcitable libgnomecups-0.1.11-4 --------------------- * Fri Sep 03 2004 Matthias Clasen 0.1.11-4 - Make updating the printer list async. libgnomeprint22-2.7.1-7 ----------------------- * Fri Sep 03 2004 Matthias Clasen - 2.7.1-7 - Make updating the printer list async. * Tue Aug 31 2004 Matthias Clasen - 2.7.1-6 - Update the async ppd patch mailman-2.1.5-17 ---------------- * Tue Sep 07 2004 John Dennis 3:2.1.5-17 - fix bug #120930, add contents of contrib to doc area * Tue Sep 07 2004 John Dennis 3:2.1.5-16 - fix bug #121220, httpd config file tweaks add doc to INSTALL.REDHAT for selecting MTA net-snmp-5.1.2-3 ---------------- * Tue Sep 07 2004 Radek Vokal 5.1.2-3 - Agentx failed to send trap, fixed (#130752, #122338) * Mon Sep 06 2004 Radek Vokal 5.1.2-2 - Patch fixing uninitalized stack variable in smux_trap_process (#130179) net-tools-1.60-36 ----------------- * Mon Sep 06 2004 Radek Vokal 1.60-36 - parse error fixed (#131539) passwd-0.68-10 -------------- * Mon Aug 23 2004 Jindrich Novy - applied cleanup patch from Steve Grubb #120060 - fixed man page #115380 - added libselinux-devel to BuildPrereq #123750, #119416 * Thu Aug 19 2004 Jindrich Novy 0.68-10 - moved to 0.68-10 to fix problem with RHEL4-Alpha4 #129548 - updated GNU build scripts and file structure to recent style * Wed Feb 04 2004 Dan Walsh 0.68-8 - add check for enforcing mode rpm-4.3.2-2 ----------- * Sat Sep 04 2004 Jeff Johnson 4.3.2-2 - ia64: make sure that autorelocated file dependencies are satisfied. - ia64: relocate all scriptlet interpreters. - ia64: don't bother trying to preload autorelocated modules. - fix: filesystem package needs mail/lock w/o getgrnam. - fix: do getpwnam/getgrnam to load correct modules before chroot. - restore file conflict detection traditional behavior. rpmdb-fedora-2.91-0.20040908 ---------------------------- selinux-policy-strict-1.17.10-2 ------------------------------- * Tue Sep 07 2004 Dan Walsh 1.17.10-2 - Fix named file context and add dbus patch from Colin - Fix udev and tmpfs boot problems * Sat Sep 04 2004 Dan Walsh 1.17.10-1 - Update from NSA * Thu Sep 02 2004 Dan Walsh 1.17.9-2 - Clean up patch selinux-policy-targeted-1.17.10-2 --------------------------------- * Tue Sep 07 2004 Dan Walsh 1.17.10-2 - Fix named file context and add dbus patch from Colin - Fix udev and tmpfs boot problems * Sat Sep 04 2004 Dan Walsh 1.17.10-1 - Update from NSA * Thu Sep 02 2004 Dan Walsh 1.17.9-2 - Clean up patch shared-mime-info-0.15-3 ----------------------- * Mon Sep 06 2004 Caolan McNamara - 0.15-3 - wpd can be opened in abiword, but not in openoffice.org (#114907) system-config-keyboard-1.2.2-1 ------------------------------ * Tue Sep 07 2004 Paul Nasrat 1.2.2-1 - i18n desktop system-config-kickstart-2.5.13-1 -------------------------------- * Tue Sep 07 2004 Paul Nasrat - 2.5.13-1 - i18n .desktop * Mon Sep 06 2004 Paul Nasrat - 2.5.12-4 - PyGTK API fix system-config-language-1.1.6-2 ------------------------------ * Tue Sep 07 2004 Paul Nasrat 1.1.6-2 - Buildrequires intltool * Tue Sep 07 2004 Paul Nasrat 1.1.6-1 - Translatable desktop * Mon Sep 06 2004 Paul Nasrat 1.1.5-3 - fix gtk.mainloop/mainquit system-config-mouse-1.2.8-1 --------------------------- * Mon Sep 06 2004 Paul Nasrat - 1.2.8-1 - PyGTK API fixups system-config-printer-0.6.112-1 ------------------------------- * Mon Sep 06 2004 Tim Waugh 0.6.112-1 - 0.6.112: - Revert change from bug #130811, to avoid traceback. system-config-rootpassword-1.1.5-1 ---------------------------------- * Tue Sep 07 2004 Paul Nasrat 1.1.5-1 - translatable desktop * Mon Sep 06 2004 Paul Nasrat 1.1.4-1 - PyGTK API changes system-config-securitylevel-1.4.3-1 ----------------------------------- * Tue Sep 07 2004 Paul Nasrat 1.4.3-1 - Translatable desktop udev-030-22 ----------- * Tue Sep 07 2004 Harald Hoyer - 030-22 - applied rules from David Zeuthen which read /proc directly without shellscript * Tue Sep 07 2004 Harald Hoyer - 030-21 - applied enumeration patch from David Zeuthen for cdrom symlinks (bug 131532) - create /dev/ppp in start_udev (bug 131114) - removed nvidia devices from start_udev - check for restorecon presence in start_udev (bug 131904) vino-2.7.92-3 ------------- * Tue Sep 07 2004 Matthias Clasen 2.7.92-3 - Disable help button until there is help (#131632) xorg-x11-6.7.99.903-6 --------------------- * Fri Sep 03 2004 Mike A. Harris 6.7.99.903-6 - Remove hard coded dependancy on Glide3 from xorg-x11 package, as the tdfx DRI driver has used dlopen() with Glide3 since XFree86 4.2.1 or so, and no longer has a build time or runtime dependancy on Glide3 being present. If Glide3 is present, DRI will work (theoretically), but if it is not present, the tdfx driver should still function correctly, so we can get rid of this dependancy now, as we are removing Glide3 from some of our OS products. From dax at gurulabs.com Wed Sep 8 18:30:20 2004 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 08 Sep 2004 12:30:20 -0600 Subject: Kerberos HTTP authentication in RHEL4/FC3/FC2 In-Reply-To: <413E9474.9070809@redhat.com> References: <1094599636.3987.102.camel@mentorng.gurulabs.com> <413E9474.9070809@redhat.com> Message-ID: <1094668220.3972.136.camel@mentorng.gurulabs.com> On Tue, 2004-09-07 at 23:11, Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dax Kelson wrote: > > One of the new features of Mozilla 1.7 touted in the release notes is: > > > > "Support for Kerberos HTTP authentication using GSSAPI (benefits > > Unix-like platforms including Linux and OS X)." > > > > Single sign on rules. > > Have you even looked at the Mozilla in FC3? The negotiateauth component > is present and... Yes, I examined mozilla-1.7.2-0.3.0.src.rpm snagged from rawhide yesterday. The --with-gssapi configuration option was missing in the spec for the configure invocation and ldd showed no gssapi/krb libraries. After further checking today it appears that --with-gssapi is the default, and either dlopen is used or mozilla is statically linked against the gssapi/kerb libraries. Sorry, my bad. Dax From pekkas at netcore.fi Wed Sep 8 18:40:12 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 8 Sep 2004 21:40:12 +0300 (EEST) Subject: vsftpd (GPL) and openssl? In-Reply-To: <1094642018.3042.10.camel@roque> Message-ID: On Wed, 8 Sep 2004, Rui Miguel Seabra wrote: > > >From the license/policitical/religious point of view, it might be > > closer in spirit to the vsftpd though. > > Anyway, do you have any data to backup your defamatory statement? > OpenSSL hasn't exactly been void of serious issues... Do you want the devil you know or the one you don't? That's the point. Very few are using GNUtls, so even if there are gaping holes, they wouldn't be worth the effort of either the whitehat or blackhat communities to dig out and expose/abuse. On the other hand OpenSSL exists in millions or dozens of millions of systems, so at least is has been exposed to some significant security review. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From wart at kobold.org Wed Sep 8 18:41:44 2004 From: wart at kobold.org (Wart) Date: Wed, 08 Sep 2004 11:41:44 -0700 Subject: rpmlint error messages Message-ID: <1094668904.32344.51.camel@tigger> I'm trying to build a fedora-compatible spec file for tclhttpd (http://tclhttpd.sourceforge.net/), but I'm having trouble understanding some of the message that rpmlint reports on the generated RPM file. Here are the particular messages that are causing me trouble: W: tclhttpd no-soname /usr/lib/libcrypt1.0.so E: tclhttpd non-versioned-file-in-library-package /usr/tclhttpd/htdocs/.tml Is there a detailed description of rpmlint's messages anywhere? --Wart From smoogen at lanl.gov Wed Sep 8 18:42:02 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Wed, 08 Sep 2004 12:42:02 -0600 Subject: FC3test2 candidate tree In-Reply-To: <20040906120918.87800.qmail@web50606.mail.yahoo.com> References: <20040906120918.87800.qmail@web50606.mail.yahoo.com> Message-ID: <413F527A.5060608@lanl.gov> Steve G wrote: >>>AFAIK, the distribution isn't "bootstrapped" (rebuilt entirely using itself >>>as the build host), > > > I kind of determined this empirically. It doesn't build from itself, therefore, > Red Hat is not shipping binaries that is built from the actually shipping copy of > all the srpms. This is bad news for any group that needs the ability to rebuild a > distribution to prove they have the complete set of source and can re-create it > if they ever needed to; or prove there are no 3rd party add-ons/hacks. (There are > govt institutions that require this.) > I know that there are trends for several sections here having to do that... It is one of the previous selling points of RH distro was that the distro could be rebuilt from what was given. -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From rms at 1407.org Wed Sep 8 18:56:01 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 08 Sep 2004 19:56:01 +0100 Subject: vsftpd (GPL) and openssl? In-Reply-To: References: Message-ID: <1094669761.19270.5.camel@roque> On Wed, 2004-09-08 at 21:40 +0300, Pekka Savola wrote: > Very few are using GNUtls, so even if there are gaping holes, they > wouldn't be worth the effort of either the whitehat or blackhat > communities to dig out and expose/abuse. hms hms... nice logic... > On the other hand OpenSSL exists in millions or dozens of millions of > systems, so at least is has been exposed to some significant security > review. I don't get your problem. I'm a fairly strong user of OpenSSL, but GNUtls has importance: * better licensing * alternative implementation * brings competition I think it's about time more people started using it too. By your logic, GNU/Linux would never have grown as it has been growing. It's more important to make GNUtls ready than discussing strawmen... Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From caillon at redhat.com Wed Sep 8 19:21:34 2004 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 08 Sep 2004 15:21:34 -0400 Subject: Kerberos HTTP authentication in RHEL4/FC3/FC2 In-Reply-To: <1094599636.3987.102.camel@mentorng.gurulabs.com> References: <1094599636.3987.102.camel@mentorng.gurulabs.com> Message-ID: <413F5BBE.4050706@redhat.com> Dax Kelson wrote: >One of the new features of Mozilla 1.7 touted in the release notes is: > >"Support for Kerberos HTTP authentication using GSSAPI (benefits >Unix-like platforms including Linux and OS X)." > >Single sign on rules. > >Whats needed is the addition of --with-gssapi in the spec along with >adding krb5-devel to the BuildReq line. > > The --with-gssapi configure flag is only required if you have a non-standard header location, or some weird setup as on SuSE. From what I understand though, even that is broken so the flag will be getting work done on it soon. The negotiateauth extension is enabled for both our Mozilla and Firefox packages, and has been working for me when I used it in the past. Is there a specific case where it breaks for you? If so, that would be a bug. From j.w.r.degoede at hhs.nl Wed Sep 8 20:11:20 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 08 Sep 2004 22:11:20 +0200 Subject: rawhide report: 20040908 changes In-Reply-To: <200409081759.i88Hxvm32516@porkchop.devel.redhat.com> References: <200409081759.i88Hxvm32516@porkchop.devel.redhat.com> Message-ID: <413F6768.6000204@hhs.nl> > > xorg-x11-6.7.99.903-6 > --------------------- > * Fri Sep 03 2004 Mike A. Harris 6.7.99.903-6 > > - Remove hard coded dependancy on Glide3 from xorg-x11 package, as the tdfx > DRI driver has used dlopen() with Glide3 since XFree86 4.2.1 or so, and no > longer has a build time or runtime dependancy on Glide3 being present. If > Glide3 is present, DRI will work (theoretically), but if it is not present, > the tdfx driver should still function correctly, so we can get rid of this > dependancy now, as we are removing Glide3 from some of our OS products. > Erm, I hope those OS products are the enterprise line and stuff, since I've just done a lott of work on Glide as you (mharris) should know. I think removing Glide3 from Fedora is a bad idea, some people still have voodoos and they won't like loosing 3D support. I know I'm yelling fire before there is a fire, just making sure there won't be a fire. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 8 20:38:11 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 08 Sep 2004 22:38:11 +0200 Subject: Fix for RHSA-2004-349 already in FC2's httpd? Message-ID: <87u0u8mr7w.fsf@kosh.ultra.csn.tu-chemnitz.de> Hello, is the issue from http://rhn.redhat.com/errata/RHSA-2004-349.html already fixed in the latest FC2 httpd package (2.0.50-2.1)? The announcement mentions that 2.0.50 and below are affected, the issue was reported at 2004-07-07 in apache's bugzilla[1], the package was built at 2004-06-29 and the changelog does not seem to have related entries. Enrico Footnotes: [1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29964 From linux_4ever at yahoo.com Wed Sep 8 20:58:20 2004 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 8 Sep 2004 13:58:20 -0700 (PDT) Subject: raidtools and MAKEDEV Message-ID: <20040908205820.73070.qmail@web50603.mail.yahoo.com> Hi, I was starting to test some of the newer MAKEDEV, udev, hal stuff and ran into something that I don't remember anyone mentioning. Raidtools now dies on installation: 93:procmail ########################################### [ 42%] 94:raidtools ########################################### [ 42%] /var/tmp/rpm-tmp.42736: line 2: ./MAKEDEV: No such file or directory error: %post(raidtools-1.00.3-8) scriptlet failed, exit status 127 95:rootfiles ########################################### [ 42%] 96:slocate Looking at the raidtools spec file: %post cd /dev ./MAKEDEV -m 16 md So I change raidtools to use /sbin/MAKEDEV and then it spews errors: MAKEDEV: /dev/md0: unable to reset file creation context MAKEDEV: /dev/md1: unable to reset file creation context and this continues for all 16 devices. (I saw a new parameter in today's rawhide report to suppress this kind of thing.) The installation is successful, though. Does anyone else see raidtools die like this or is it just my setup and anaconda takes care of these details? Do you want this in bugzilla? raidtools hasn't been updated for a long time. Thanks, -Steve Grubb _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From adrian at lisas.de Wed Sep 8 21:23:31 2004 From: adrian at lisas.de (Adrian Reber) Date: Wed, 8 Sep 2004 23:23:31 +0200 Subject: rpmlint error messages In-Reply-To: <1094668904.32344.51.camel@tigger> References: <1094668904.32344.51.camel@tigger> Message-ID: <20040908212331.GB16722@lisas.de> On Wed, Sep 08, 2004 at 11:41:44AM -0700, Wart wrote: > Here are the particular messages that are causing me trouble: > > W: tclhttpd no-soname /usr/lib/libcrypt1.0.so > E: tclhttpd non-versioned-file-in-library-package > /usr/tclhttpd/htdocs/.tml > > Is there a detailed description of rpmlint's messages anywhere? rpmlint is more verbose if you use the "-i" switch. Try "rpmlint -i" This does help me sometimes, though not always. Adrian From rms at 1407.org Wed Sep 8 21:43:16 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 08 Sep 2004 22:43:16 +0100 Subject: vsftpd (GPL) and openssl? In-Reply-To: <413ED2FA.8000409@redhat.com> References: <413ED0A5.5050009@redhat.com> <1094635903.3042.5.camel@roque> <413ED2FA.8000409@redhat.com> Message-ID: <1094679796.2767.6.camel@roque> On Tue, 2004-09-07 at 23:38 -1000, Warren Togami wrote: > Rui Miguel Seabra wrote: > > > > I think the case is beggining to grow for inclusion of GNUtls. > > > > GNUtls has a library which is alledgedly API-compatible with openssl. > > I have never tested. > > > > I'm willing to help with packaging it if no one is doing it right > > already, which is better than not having some SSL implementation on GPL > > packages. > > https://bugzilla.fedora.us/show_bug.cgi?id=1018 > Looks like it needs someone to adopt it, cleanup and update. The deps > might need updating too. I've got it fixed, plus a couple of packaging quircks. I also added a {?_with_opencdk} flag for future reference. Is it worthy? At this moment it doesn't do anything useful, it's just ground work for when I can package opencdk. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kbn at daimi.au.dk Wed Sep 8 21:45:46 2004 From: kbn at daimi.au.dk (Kim B. Nielsen) Date: Wed, 08 Sep 2004 23:45:46 +0200 Subject: Yum not working on development repos ?? Message-ID: <413F7D8A.6030507@daimi.au.dk> I'm trying to upgrade a FC2 machine to the latest development packages via yum, but I get this message: [root at furious kbn]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 2 - Development Tree retrygrab() failed for: http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/headers/header.info Executing failover method failover: out of servers to try Error getting file http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/headers/header.info [Errno 4] IOError: HTTP Error 404: Not Found I've noticed that the headers directory (and the headers naturally) has dissapeared from http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/ Is this intentional, or a mishap ?? And if it's a mishap, is there anyone who would be so kind to make the headers directore Thanks Kim From kyrre at solution-forge.net Wed Sep 8 20:19:10 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 08 Sep 2004 22:19:10 +0200 Subject: rawhide report: 20040908 changes In-Reply-To: <413F6768.6000204@hhs.nl> References: <200409081759.i88Hxvm32516@porkchop.devel.redhat.com> <413F6768.6000204@hhs.nl> Message-ID: <1094674750.4994.3.camel@kyrre> Hmmm... Ill never got 3d out of my vodoo 3 (fc2). Was there any vodoo to it, exept from installing? ons, 08.09.2004 kl. 22.11 skrev Hans de Goede: > > > > xorg-x11-6.7.99.903-6 > > --------------------- > > * Fri Sep 03 2004 Mike A. Harris 6.7.99.903-6 > > > > - Remove hard coded dependancy on Glide3 from xorg-x11 package, as the tdfx > > DRI driver has used dlopen() with Glide3 since XFree86 4.2.1 or so, and no > > longer has a build time or runtime dependancy on Glide3 being present. If > > Glide3 is present, DRI will work (theoretically), but if it is not present, > > the tdfx driver should still function correctly, so we can get rid of this > > dependancy now, as we are removing Glide3 from some of our OS products. > > > > Erm, > > I hope those OS products are the enterprise line and stuff, since I've > just done a lott of work on Glide as you (mharris) should know. > > I think removing Glide3 from Fedora is a bad idea, some people still > have voodoos and they won't like loosing 3D support. > > I know I'm yelling fire before there is a fire, just making sure there > won't be a fire. > > Regards, > > Hans > > > > > -- > EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es > From jorton at redhat.com Wed Sep 8 22:08:49 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 8 Sep 2004 23:08:49 +0100 Subject: Fix for RHSA-2004-349 already in FC2's httpd? In-Reply-To: <87u0u8mr7w.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87u0u8mr7w.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20040908220849.GA31262@redhat.com> On Wed, Sep 08, 2004 at 10:38:11PM +0200, Enrico Scholz wrote: > is the issue from http://rhn.redhat.com/errata/RHSA-2004-349.html already > fixed in the latest FC2 httpd package (2.0.50-2.1)? The announcement > mentions that 2.0.50 and below are affected, the issue was reported at > 2004-07-07 in apache's bugzilla[1], the package was built at 2004-06-29 > and the changelog does not seem to have related entries. No, this issue will be fixed in 2.0.51, the release process for which is already well under way: I'll issue 2.0.51 updates for Fedora when it's done. CAN-2004-0748 or CAN-2004-0751 (another public mod_ssl issue, which was not fixed in the RHEL3 U3 httpd update) do not really necessitate an httpd update in the mean time: the former means with very particular timing you can possibly trigger CPU hogs, the latter can only be triggered in rather uncommon configurations where you allow proxying to a remote SSL server. Regards, joe From alan at redhat.com Wed Sep 8 22:34:13 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 8 Sep 2004 18:34:13 -0400 Subject: rawhide report: 20040908 changes In-Reply-To: <413F6768.6000204@hhs.nl> References: <200409081759.i88Hxvm32516@porkchop.devel.redhat.com> <413F6768.6000204@hhs.nl> Message-ID: <20040908223413.GC11970@devserv.devel.redhat.com> On Wed, Sep 08, 2004 at 10:11:20PM +0200, Hans de Goede wrote: > I hope those OS products are the enterprise line and stuff, since I've > just done a lott of work on Glide as you (mharris) should know. Indeed - and the Glide3 from Fedora plan predates your contribution. Prior to that it was a very tempting item for flushing > I know I'm yelling fire before there is a fire, just making sure there > won't be a fire. For Fedora no, its now a resolved issue thanks to external maintenance. For the enterprise product line its an open question. From alan at redhat.com Wed Sep 8 22:36:17 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 8 Sep 2004 18:36:17 -0400 Subject: rawhide report: 20040908 changes In-Reply-To: <1094674750.4994.3.camel@kyrre> References: <200409081759.i88Hxvm32516@porkchop.devel.redhat.com> <413F6768.6000204@hhs.nl> <1094674750.4994.3.camel@kyrre> Message-ID: <20040908223617.GD11970@devserv.devel.redhat.com> On Wed, Sep 08, 2004 at 10:19:10PM +0200, Kyrre Ness Sjobak wrote: > Hmmm... Ill never got 3d out of my vodoo 3 (fc2). Was there any vodoo to > it, exept from installing? It doesn't work for 3D in FC2 - thats a known problem. Hans fixed it for FC3test and contributed patches. Alan From jspaleta at gmail.com Wed Sep 8 14:29:10 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 8 Sep 2004 10:29:10 -0400 Subject: yum 2.1.x fails when using firewall In-Reply-To: <1094652216.15798.7.camel@i777linux.dentk.com> References: <1094652216.15798.7.camel@i777linux.dentk.com> Message-ID: <604aa79104090807293f9c8218@mail.gmail.com> On Wed, 08 Sep 2004 14:03:35 +0000, david avery wrote: > yum 2.1.x is failing when trying to get repodata/*/xml.gz. it gets > repomd.xml OK and then sends a bad packet before trying to get > repodata/primary.xml.gz the fire wall returns a HTTP 400 and the > connection dies > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132061 when using what? an http1.0 authenticating proxy? Which proxy where? If this is a problem specific to the proxy you are using how does anyone reproduce this? Can you browse to the the primary.xml.gz file via another browser that can use the the same http proxy? -jef From lonnie at neenet.com Thu Sep 9 01:07:27 2004 From: lonnie at neenet.com (Lonnie Cumberland) Date: Wed, 08 Sep 2004 21:07:27 -0400 Subject: floppy install Message-ID: <413FACCF.2090500@neenet.com> Hello All, I am starting to get a small feel for the FC2 Linux os with many differences from my old Mandrake 10.0 distro and I must say that I like what I have seen so far. In as much, I will be re-formatting my machine to remove the MDK and put in the FC2 code. I have seen that I can use a boot.iso burned onto a cdrom to install Fedora, but I was wondering what provisions were there for booting from a floppy and then installing over the net, NFS, hard drive, http, etc... ? Seems that if FC2 only supports bootable CDROM systems then it would be hard to place on some older machines or did I miss something? Thanks All and have a good day, Lonnie From daa at rm.incc.net Thu Sep 9 01:37:18 2004 From: daa at rm.incc.net (daa) Date: Wed, 08 Sep 2004 19:37:18 -0600 Subject: yum 2.1.x fails when using firewall Message-ID: <413FB3CE.70500@rm.incc.net> > when using what? an http1.0 authenticating proxy? Which proxy where? > If this is a problem specific to the proxy you are using how does > anyone reproduce this? > Can you browse to the the primary.xml.gz file via another browser that > can use the > the same http proxy? this is a HTTP1.0 authenticating proxy (Sidewinder 5.2 http://www.securecomputing.com) browser ( IE or mozilla) has no problem getting to the dir and file) dave From sopwith at redhat.com Thu Sep 9 02:08:11 2004 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 8 Sep 2004 22:08:11 -0400 Subject: Another FC3test2 candidate tree Message-ID: <1A03C3EC-0205-11D9-8ED4-000D93565D78@redhat.com> The previous bug reports on the re0903.0 tree were very helpful - here's another one to chew on: http://fedora.linux.duke.edu/FC3-re0908.0/ (As before, I just started syncing it, so it will be a while. Please make sure that any .iso's you download are dated today 2004-09-08 - the old ones in place there are from yesterday and are known-broken.) Please see how it installs/runs if you get a chance. -- Elliot From wtogami at redhat.com Thu Sep 9 02:25:19 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 08 Sep 2004 16:25:19 -1000 Subject: Another FC3test2 candidate tree In-Reply-To: <1A03C3EC-0205-11D9-8ED4-000D93565D78@redhat.com> References: <1A03C3EC-0205-11D9-8ED4-000D93565D78@redhat.com> Message-ID: <413FBF0F.4030504@redhat.com> Elliot Lee wrote: > The previous bug reports on the re0903.0 tree were very helpful - here's > another one to chew on: > > http://fedora.linux.duke.edu/FC3-re0908.0/ > > (As before, I just started syncing it, so it will be a while. Please > make sure that any .iso's you download are dated today 2004-09-08 - the > old ones in place there are from yesterday and are known-broken.) > > Please see how it installs/runs if you get a chance. > -- Elliot > > For me x86_64 network install failed, but i386 worked on the same hardware. It somehow doens't recognize that my e1000 is a network card while in x86_64, so it keeps returning to that menu that tells you to select a driver or driver disk. =( Is this filed anywhere? Warren Togami wtogami at redhat.com From ggw at wolves.durham.nc.us Thu Sep 9 02:35:07 2004 From: ggw at wolves.durham.nc.us (Gregory Woodbury) Date: Wed, 8 Sep 2004 22:35:07 -0400 Subject: floppy install In-Reply-To: <413FACCF.2090500@neenet.com> References: <413FACCF.2090500@neenet.com> Message-ID: <20040909023507.GA18541@wolves.durham.nc.us> On Wed, Sep 08, 2004 at 09:07:27PM -0400, Lonnie Cumberland wrote: > Hello All, > > I am starting to get a small feel for the FC2 Linux os with many > differences from my old Mandrake 10.0 distro and I must say that I like > what I have seen so far. In as much, I will be re-formatting my machine > to remove the MDK and put in the FC2 code. > > I have seen that I can use a boot.iso burned onto a cdrom to install > Fedora, but I was wondering what provisions were there for booting from > a floppy and then installing over the net, NFS, hard drive, http, etc... ? > > Seems that if FC2 only supports bootable CDROM systems then it would be > hard to place on some older machines or did I miss something? No, you didn't miss anything. The kernel for FC2 is too big to fit on a 1.44MiB floppy along with a reasonable initrd image for booting. -- G.Wolfe Woodbury `- -' RHCT U The Line Eater is a boojum! From lonnie at neenet.com Thu Sep 9 01:54:41 2004 From: lonnie at neenet.com (Lonnie Cumberland) Date: Wed, 08 Sep 2004 21:54:41 -0400 Subject: floppy install In-Reply-To: <20040909023507.GA18541@wolves.durham.nc.us> References: <413FACCF.2090500@neenet.com> <20040909023507.GA18541@wolves.durham.nc.us> Message-ID: <413FB7E1.5020001@neenet.com> What about the possibility of having a multi-floppy version of the boot.iso in that older machines would be able to take advantage of Fedora as well? I'm not sure how to split up the image though, but I think that it should be possible. worth investigating? Well, just my small input on what I see is a small short-fall of the system. Thanks again, Lonnie Gregory Woodbury wrote: >On Wed, Sep 08, 2004 at 09:07:27PM -0400, Lonnie Cumberland wrote: > > >>Hello All, >> >>I am starting to get a small feel for the FC2 Linux os with many >>differences from my old Mandrake 10.0 distro and I must say that I like >>what I have seen so far. In as much, I will be re-formatting my machine >>to remove the MDK and put in the FC2 code. >> >>I have seen that I can use a boot.iso burned onto a cdrom to install >>Fedora, but I was wondering what provisions were there for booting from >>a floppy and then installing over the net, NFS, hard drive, http, etc... ? >> >>Seems that if FC2 only supports bootable CDROM systems then it would be >>hard to place on some older machines or did I miss something? >> >> > >No, you didn't miss anything. The kernel for FC2 is too big to fit on a >1.44MiB floppy along with a reasonable initrd image for booting. > > > From aoliva at redhat.com Thu Sep 9 04:01:06 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 09 Sep 2004 01:01:06 -0300 Subject: raidtools and MAKEDEV In-Reply-To: <20040908205820.73070.qmail@web50603.mail.yahoo.com> References: <20040908205820.73070.qmail@web50603.mail.yahoo.com> Message-ID: On Sep 8, 2004, Steve G wrote: > %post > cd /dev > ./MAKEDEV -m 16 md Looks definitely wrong for a udev system. Please file this in bugzilla, if you haven't done so yet. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From skvidal at phy.duke.edu Thu Sep 9 03:40:27 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 08 Sep 2004 23:40:27 -0400 Subject: rpm --redhat-requires, rpm --redhat-provides Message-ID: <1094701227.15411.13.camel@binkley> Hi Everyone, I don't want a flamewar, just opinions. Are there a lot of people who use the two commands listed in the subject very often? I ask b/c there has been some discussion of minimizing the number of copies of the package metadata from the installation. comps.rpm and rpmdb-fedora take up considerable space and now would be a good time to discuss removing them for FC4. if yum or some other command line tool were to be able to return the same data from the xml metadata, instead of the comps or rpmdb-fedora, would people be willing to use those? Thanks -sv From feliciano.matias at free.fr Thu Sep 9 04:15:05 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 09 Sep 2004 06:15:05 +0200 Subject: floppy install In-Reply-To: <413FACCF.2090500@neenet.com> References: <413FACCF.2090500@neenet.com> Message-ID: <1094703305.1064.65.camel@one.myworld> Le jeu 09/09/2004 ? 03:07, Lonnie Cumberland a ?crit : > Hello All, > > I am starting to get a small feel for the FC2 Linux os with many > differences from my old Mandrake 10.0 distro and I must say that I like > what I have seen so far. In as much, I will be re-formatting my machine > to remove the MDK and put in the FC2 code. > > I have seen that I can use a boot.iso burned onto a cdrom to install > Fedora, but I was wondering what provisions were there for booting from > a floppy and then installing over the net, NFS, hard drive, http, etc... ? > It's "easy" to install FC2. You need a way to load vmlinuz and initrd.img. These files are in /isolinux of CD1. Most common options can be found in the same directory (isolinux.cfg and *.msg files). askmethod parameter provide the ability to install with NFS/FTP/HTTP and hard drive method. For example, copy vmlinuz and initrd.img in the hard drive, then use a floppy with grub and load vmlinuz/initrd.img : title Fedore Core 3 _not_T2 (Install) root(hd0,0) kernel /vmlinuz ramdisk_size=8192 askmethod initrd /initrd.img You can use "Smart Boot Manager" http://btmgr.webframe.org/index.php3 : Booting from CD-ROM Smart BootManager supports booting from almost all kinds of IDE ATAPI CD-ROM > Seems that if FC2 only supports bootable CDROM systems then it would be > hard to place on some older machines or did I miss something? > > Thanks All and have a good day, > Lonnie > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From rc040203 at freenet.de Thu Sep 9 04:57:33 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 09 Sep 2004 06:57:33 +0200 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094701227.15411.13.camel@binkley> References: <1094701227.15411.13.camel@binkley> Message-ID: <1094705853.22952.2664.camel@mccallum.corsepiu.local> On Thu, 2004-09-09 at 05:40, seth vidal wrote: > Hi Everyone, > I don't want a flamewar, just opinions. OK, here is mine: > Are there a lot of people who use the two commands listed in the subject > very often? I ask b/c there has been some discussion of minimizing the > number of copies of the package metadata from the installation. > > comps.rpm and rpmdb-fedora take up considerable space and now would be a > good time to discuss removing them for FC4. Good idea. > if yum or some other command line tool were to be able to return the > same data from the xml metadata, instead of the comps or rpmdb-fedora, > would people be willing to use those? IMO, the only tool that is relevant here is "rpm", not "some other command line tool" and definitely not "yum", because the package management system being used is "rpm", not yum, apt nor up2date. I.e. if you want to make metadata the exclusive and normative source of available packages, the next step would be to enable rpm to process them. Alternatively, I could imagine "some other command tool" could replace "rpm --redhat-*" as part of the rpm package. Ralf From skvidal at phy.duke.edu Thu Sep 9 04:59:38 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 09 Sep 2004 00:59:38 -0400 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094705853.22952.2664.camel@mccallum.corsepiu.local> References: <1094701227.15411.13.camel@binkley> <1094705853.22952.2664.camel@mccallum.corsepiu.local> Message-ID: <1094705978.15411.34.camel@binkley> > > if yum or some other command line tool were to be able to return the > > same data from the xml metadata, instead of the comps or rpmdb-fedora, > > would people be willing to use those? > > IMO, the only tool that is relevant here is "rpm", not "some other > command line tool" and definitely not "yum", because the package > management system being used is "rpm", not yum, apt nor up2date. well, in this particular case there is no pkg mgmt going on. it's just querying an rpmdb that is not frequently updated, tbh. > I.e. if you want to make metadata the exclusive and normative source of > available packages, the next step would be to enable rpm to process > them. Alternatively, I could imagine "some other command tool" could > replace "rpm --redhat-*" as part of the rpm package. so to make sure I'm hearing you right: either: make rpm parse the xml repodata directly or: provide another 'some other command tool' that replaces the popt macro for 'rpm --redhat-*'? -sv From feliciano.matias at free.fr Thu Sep 9 04:36:38 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 09 Sep 2004 06:36:38 +0200 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094701227.15411.13.camel@binkley> References: <1094701227.15411.13.camel@binkley> Message-ID: <1094704594.1064.72.camel@one.myworld> Le jeu 09/09/2004 ? 05:40, seth vidal a ?crit : > Hi Everyone, > I don't want a flamewar, just opinions. > > Are there a lot of people who use the two commands listed in the subject > very often? you can add --aid : add suggested packages to transaction --nosuggest : do not suggest missing dependency resolution(s) > I ask b/c there has been some discussion of minimizing the > number of copies of the package metadata from the installation. > > comps.rpm and rpmdb-fedora take up considerable space and now would be a > good time to discuss removing them for FC4. > > if yum or some other command line tool were to be able to return the > same data from the xml metadata, instead of the comps or rpmdb-fedora, > would people be willing to use those? > > Thanks > -sv > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From philip at wyett.net Thu Sep 9 05:14:03 2004 From: philip at wyett.net (Philip Wyett) Date: Thu, 09 Sep 2004 06:14:03 +0100 Subject: Patch for rawhide valgrind adding FC1 BuildRequires Message-ID: <1094706842.3073.7.camel@wyett> Hi, Thought I'd submit this patch that merely adds the build requirements for those who may attempt building on FC1. Please consider for inclusion. Regards -- Philip Wyett Personal Email: philip at wyett.net Website: http://www.wyett.net Work email: pwyett at a-novo.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: valgrind_fc1_build.patch Type: text/x-patch Size: 921 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cra at WPI.EDU Thu Sep 9 05:23:49 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 9 Sep 2004 01:23:49 -0400 Subject: Another FC3test2 candidate tree In-Reply-To: <1A03C3EC-0205-11D9-8ED4-000D93565D78@redhat.com> References: <1A03C3EC-0205-11D9-8ED4-000D93565D78@redhat.com> Message-ID: <20040909052349.GD27565@angus.ind.WPI.EDU> On Wed, Sep 08, 2004 at 10:08:11PM -0400, Elliot Lee wrote: > The previous bug reports on the re0903.0 tree were very helpful - > here's another one to chew on: > http://fedora.linux.duke.edu/FC3-re0908.0/ I tried a fresh install on an IBM ThinkPad T42p with the 1600x1200 15" LCD and 128MB ATI FireGL Mobility T2 graphics card. Install went better this time around. Graphical installer worked. I did a Custom install from CD's, Manual partition, formatting all system partitions from my previous install. A few points: 1. In rc0903, bootup hung on firstboot. Ctrl-Alt-Backspace was needed to continue bootup, skipping firstboot. Now in rc0908, bootup continues right past firstboot. I assume firstboot failed to run, but at least it didn't hang this time. The rhgb graphics displayed, followed by what looked like the X server reinitializing and the screen clearing to black. Then the X server was reinitialized again, and GDM appeared. /var/log/boot.log says: "firstboot: failed". 2. Possibly due to the above, switching from graphical login on VT7 to the text consoles on VT1-VT6 displayed blank text screens with a blinking cursor. The cursor moved with keyboard input. Mingetty was actually running, so I was able to login blind. After logging in as root, the text screen was "reset" somehow (by an /etc/profile script?), and all the previous and current text appeared... 3. dmesg says "kernel: radeonfb: Non-DDC laptop panel detected", but then says "kernel: radeonfb: detected LVDS panel size from BIOS: 1600x1200". However, xorg-x11 always starts in 800x600. Perhaps firstboot would offer the correct default resolution of 1600x1200 if it had worked? This is easily remedied by using System Settings->Display after logging in, changing Monitor Type from "Unknown monitor" to "Generic LCD Display / LCD Panel 1600x1200", and selecting Resolution: 1600x1200, and re-logging in. 4. Double-clicking the battery applet gives an error dialog: "The Suspend command '/usr/bin/apm -s' was unsuccessful." 5. I see xcdroast was replaced by k3b in the menu. This is good, because re0903's xcdroast didn't work (it spewed some error about /dev/sg* not found). I also found xcdroast hard to use (this was my first time seeing it). However, why is k3b in "Sound & Video" and not "System Tools" or perhaps "Accessories"? It seems silly that k3b would be considered solely a Sound or Video application... Once I found k3b, I was impressed with its ease of use and proper functioning. I erased a CD-RW and burned an ISO image with no trouble or configuration required. Good work so far--FC3 is going to be an exciting release. I'll find/file bugs for these issues soon... From mitr at volny.cz Thu Sep 9 05:31:06 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Thu, 9 Sep 2004 07:31:06 +0200 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094701227.15411.13.camel@binkley> References: <1094701227.15411.13.camel@binkley> Message-ID: <20040909053103.GA17160@chrys.ms.mff.cuni.cz> Hello, On Wed, Sep 08, 2004 at 11:40:27PM -0400, seth vidal wrote: > Are there a lot of people who use the two commands listed in the subject > very often? I use something more general: $ cat .popt rpm alias --fedora --nogpg --dbpath /usr/lib/rpmdb/%{_arch}-%{_vendor}-%{_os}/redhat $ Then (rpm --fedora -q --whatprovides PACKAGE), (rpm --fedora -qf FILE), (rpm --fedora -ql PACKAGE), (rpm --fedora -ev --test PACKAGE) etc., I tend to use this very often (daily is a good estimate). > if yum or some other command line tool were to be able to return the > same data from the xml metadata, instead of the comps or rpmdb-fedora, > would people be willing to use those? I don't think the XML metadata allows so general queries and I'm not sure what is the subset of rpmdb data that would be enough to completely replace all the ways I have ever used rpmdb. But if the rpmdb is not available in the distribution, I can always create my own, so ths mail does not imply "I don't want rpmdb removed". Mirek From rc040203 at freenet.de Thu Sep 9 05:34:27 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 09 Sep 2004 07:34:27 +0200 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094705978.15411.34.camel@binkley> References: <1094701227.15411.13.camel@binkley> <1094705853.22952.2664.camel@mccallum.corsepiu.local> <1094705978.15411.34.camel@binkley> Message-ID: <1094708067.22952.2713.camel@mccallum.corsepiu.local> On Thu, 2004-09-09 at 06:59, seth vidal wrote: > > > if yum or some other command line tool were to be able to return the > > > same data from the xml metadata, instead of the comps or rpmdb-fedora, > > > would people be willing to use those? > > > > IMO, the only tool that is relevant here is "rpm", not "some other > > command line tool" and definitely not "yum", because the package > > management system being used is "rpm", not yum, apt nor up2date. > > I.e. if you want to make metadata the exclusive and normative source of > > available packages, the next step would be to enable rpm to process > > them. Alternatively, I could imagine "some other command tool" could > > replace "rpm --redhat-*" as part of the rpm package. > > so to make sure I'm hearing you right: > > either: > make rpm parse the xml repodata directly > > or: > > provide another 'some other command tool' that replaces the popt macro > for 'rpm --redhat-*'? Yes, this is essentially what I had in mind. In particular I was thinking along the lines of shipping a metadata*rpm, to replace rpmdb-fedora*rpm, because I'd expect the info contained in both of them to be completely equivalent. Yum then could use this rpmdb-fedora-replacement rpm to setup its initial package-metadata/header cache etc. Another aspect, I am not sure about is if and how to reflect dynamically set up metadata-caches to "rpm --redhat-*". On one hand, ATM, rpm doesn't know anything about yum/apt/up2date, so not considering this case would not be a regression. On the other hand, if rpm is able to read metadata-files/caches, it should not be too be difficult to extended it to read arbitrary metadata-files/caches such as the ones being used by yum. Ralf From skvidal at phy.duke.edu Thu Sep 9 05:07:29 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 09 Sep 2004 01:07:29 -0400 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094704594.1064.72.camel@one.myworld> References: <1094701227.15411.13.camel@binkley> <1094704594.1064.72.camel@one.myworld> Message-ID: <1094706449.15411.36.camel@binkley> On Thu, 2004-09-09 at 06:36 +0200, Matias Feliciano wrote: > Le jeu 09/09/2004 ? 05:40, seth vidal a ?crit : > > Hi Everyone, > > I don't want a flamewar, just opinions. > > > > Are there a lot of people who use the two commands listed in the subject > > very often? > > you can add > --aid : > add suggested packages to transaction > --nosuggest : > do not suggest missing dependency resolution(s) And on that subject. Are these often used? -sv From pmatilai at welho.com Thu Sep 9 05:53:51 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 9 Sep 2004 08:53:51 +0300 (EEST) Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094701227.15411.13.camel@binkley> References: <1094701227.15411.13.camel@binkley> Message-ID: On Wed, 8 Sep 2004, seth vidal wrote: > Hi Everyone, > I don't want a flamewar, just opinions. > > Are there a lot of people who use the two commands listed in the subject > very often? I ask b/c there has been some discussion of minimizing the > number of copies of the package metadata from the installation. Often? No. Occasionally yes, although that tends to be on either a) ancient b) standalone boxes. Because of the static nature of rpmdb-redhat it grows more useless over time especially on distro like FC where packages get renamed during the release lifetime and updates are fast and furious. What I would miss probably is the formatting capabilities of rpm --qf which makes it useful from scripts for certain things. > comps.rpm and rpmdb-fedora take up considerable space and now would be a > good time to discuss removing them for FC4. comps.rpm has the same problem of being a static entity and a rather strange beast at that. I wouldn't miss it a single day as long as the equivalent of comps.xml is somewhere around.. but the information is more important for systems without network connectivity (or if you just happen to *love* shuffling CD's back and forth to install stuff) > > if yum or some other command line tool were to be able to return the > same data from the xml metadata, instead of the comps or rpmdb-fedora, > would people be willing to use those? Oh absolutely, if the command line tool can grok rpm's --queryformat syntax or equivalent alternative (but compatibility with rpm would be quite important I think so rpm --qf junkies like me don't have to relearn a new query "language" :) - Panu - From skvidal at phy.duke.edu Thu Sep 9 06:04:13 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 09 Sep 2004 02:04:13 -0400 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: References: <1094701227.15411.13.camel@binkley> Message-ID: <1094709853.15411.58.camel@binkley> > Often? No. Occasionally yes, although that tends to be on either a) > ancient b) standalone boxes. Because of the static nature of rpmdb-redhat > it grows more useless over time especially on distro like FC where > packages get renamed during the release lifetime and updates are fast and > furious. What I would miss probably is the formatting capabilities of rpm > --qf which makes it useful from scripts for certain things. I think all that functionality is housed in popt, but yah - I agree it is handy. > comps.rpm has the same problem of being a static entity and a rather > strange beast at that. I wouldn't miss it a single day as long as the > equivalent of comps.xml is somewhere around.. but the information is more > important for systems without network connectivity (or if you just > happen to *love* shuffling CD's back and forth to install stuff) What are these "systems without network connectivity" that you speak of? :) Actually, there was also some discussion this evening of if the xml-metadata could store cd information in an additional attribute in the tag. Specifically for things like system-config-packages and anaconda to be able to use the metadata with removable media. > Oh absolutely, if the command line tool can grok rpm's --queryformat > syntax or equivalent alternative (but compatibility with rpm would be > quite important I think so rpm --qf junkies like me don't have to relearn > a new query "language" :) you know... if you're interested, it would be a fun time to learn the repomd module for accessing the metadata. :) -sv From skvidal at phy.duke.edu Thu Sep 9 05:40:52 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 09 Sep 2004 01:40:52 -0400 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <20040909053103.GA17160@chrys.ms.mff.cuni.cz> References: <1094701227.15411.13.camel@binkley> <20040909053103.GA17160@chrys.ms.mff.cuni.cz> Message-ID: <1094708452.15411.44.camel@binkley> > Then (rpm --fedora -q --whatprovides PACKAGE), (rpm --fedora -qf FILE), > (rpm --fedora -ql PACKAGE), (rpm --fedora -ev --test PACKAGE) etc., > I tend to use this very often (daily is a good estimate). > I dare say your use is extremely special. > I don't think the XML metadata allows so general queries and I'm > not sure what is the subset of rpmdb data that would be enough to > completely replace all the ways I have ever used rpmdb. umm. The xml metadata allows whatever query the tool that is accessing it allows. the intent of yum is to be somewhat simpler for a given subset of commands but the xml metadata provides a significant fraction of the data that is normally in an rpmdb. Not the file checksums, to be sure, but it does provide: changelogs files dirs provides/obsoletes/conflicts/requires standard info on a package (rpm -qpi type stuff) it might be worthwhile to implement a general query tool for the xml metadata. Anyone interested? -sv From dwmw2 at infradead.org Thu Sep 9 06:44:44 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 09 Sep 2004 07:44:44 +0100 Subject: Yum not working on development repos ?? In-Reply-To: <413F7D8A.6030507@daimi.au.dk> References: <413F7D8A.6030507@daimi.au.dk> Message-ID: <1094712284.15909.11.camel@localhost.localdomain> On Wed, 2004-09-08 at 23:45 +0200, Kim B. Nielsen wrote: > I've noticed that the headers directory (and the headers naturally) has > dissapeared from > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/ > > Is this intentional, or a mishap ?? Apparently the metadata format changed. It's now created by 'createrepo' and yum-arch has disappeared. Apparently both yum and up2date ought to cope with the new format already. I couldn't get them to work though -- I just downgraded yum and ran 'yum-arch' again on my local mirror. -- dwmw2 From skvidal at phy.duke.edu Thu Sep 9 06:51:47 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 09 Sep 2004 02:51:47 -0400 Subject: Yum not working on development repos ?? In-Reply-To: <1094712284.15909.11.camel@localhost.localdomain> References: <413F7D8A.6030507@daimi.au.dk> <1094712284.15909.11.camel@localhost.localdomain> Message-ID: <1094712707.15411.65.camel@binkley> On Thu, 2004-09-09 at 07:44 +0100, David Woodhouse wrote: > On Wed, 2004-09-08 at 23:45 +0200, Kim B. Nielsen wrote: > > I've noticed that the headers directory (and the headers naturally) has > > dissapeared from > > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/ > > > > Is this intentional, or a mishap ?? > > Apparently the metadata format changed. It's now created by 'createrepo' > and yum-arch has disappeared. Apparently both yum and up2date ought to > cope with the new format already. I couldn't get them to work though -- > I just downgraded yum and ran 'yum-arch' again on my local mirror. yum-arch will return before fc3t3. Yum 2.1.X will work with the new metadata, yes. -sv From pmatilai at welho.com Thu Sep 9 06:47:08 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 9 Sep 2004 09:47:08 +0300 (EEST) Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094709853.15411.58.camel@binkley> References: <1094701227.15411.13.camel@binkley> <1094709853.15411.58.camel@binkley> Message-ID: On Thu, 9 Sep 2004, seth vidal wrote: > > > Often? No. Occasionally yes, although that tends to be on either a) > > ancient b) standalone boxes. Because of the static nature of rpmdb-redhat > > it grows more useless over time especially on distro like FC where > > packages get renamed during the release lifetime and updates are fast and > > furious. What I would miss probably is the formatting capabilities of rpm > > --qf which makes it useful from scripts for certain things. > > I think all that functionality is housed in popt, but yah - I agree it > is handy. Yup it's heavily tied into popt but I'm not too familiar with the details .. hmm, popt-python anybody? :) Anyway need to have a closer look at how the thing works. > > > comps.rpm has the same problem of being a static entity and a rather > > strange beast at that. I wouldn't miss it a single day as long as the > > equivalent of comps.xml is somewhere around.. but the information is more > > important for systems without network connectivity (or if you just > > happen to *love* shuffling CD's back and forth to install stuff) > > What are these "systems without network connectivity" that you speak > of? :) Creatures from our worst nightmares? :) > Actually, there was also some discussion this evening of if the > xml-metadata could store cd information in an additional attribute in > the tag. Specifically for things like system-config-packages > and anaconda to be able to use the metadata with removable media. Indeed. People with modem-only internet access still exist and for those it's important that the new metadata works with removable media. And anaconda as well of course. > > > Oh absolutely, if the command line tool can grok rpm's --queryformat > > syntax or equivalent alternative (but compatibility with rpm would be > > quite important I think so rpm --qf junkies like me don't have to relearn > > a new query "language" :) > > you know... if you're interested, it would be a fun time to learn the > repomd module for accessing the metadata. :) Sure, why not, should be a fun project. I should start having a bit more time to use for freetime hacking in a few weeks. If you start something let me know. - Panu - From kwade at redhat.com Thu Sep 9 07:09:41 2004 From: kwade at redhat.com (Karsten Wade) Date: Thu, 09 Sep 2004 00:09:41 -0700 Subject: minimal install In-Reply-To: <413E5FB6.5080004@neenet.com> References: <413E5FB6.5080004@neenet.com> Message-ID: <1094713781.3014.11423.camel@erato.phig.org> On Tue, 2004-09-07 at 18:26, Lonnie Cumberland wrote: > I would like to see what file Fedora uses to define what the "minimal" > install is, or "Server" install list of packages because I need the > absolute smallest install + XWindows and the smallest (simplest) window > manager. I think you need, from disc1 of any Fedora/Red Hat installation, this file: disc1/Fedora/base/comps.xml -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From skvidal at phy.duke.edu Thu Sep 9 07:12:37 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 09 Sep 2004 03:12:37 -0400 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: References: <1094701227.15411.13.camel@binkley> <1094709853.15411.58.camel@binkley> Message-ID: <1094713957.15411.70.camel@binkley> > > Actually, there was also some discussion this evening of if the > > xml-metadata could store cd information in an additional attribute in > > the tag. Specifically for things like system-config-packages > > and anaconda to be able to use the metadata with removable media. > > Indeed. People with modem-only internet access still exist and > for those it's important that the new metadata works with removable media. > And anaconda as well of course. Check my post to rpm-metadata list and comment. If it seems reasonable then it's a way to go. it'll take some work to put that in createrepo, though. > > Sure, why not, should be a fun project. I should start having a bit more > time to use for freetime hacking in a few weeks. If you start something > let me know. if you install yum 2.1.3 from rawhide you'll have a good version of the repomd module. Some new updates added in cvs but the concepts are more or less there. Also paul nasrat has been working on something related. Drop by #fedora-devel on irc and ping at me or nasrat about it. I'd love to get a quick and simple tool to parse the files and dump the outputs. -sv From harald at redhat.com Thu Sep 9 08:18:37 2004 From: harald at redhat.com (Harald Hoyer) Date: Thu, 09 Sep 2004 10:18:37 +0200 Subject: raidtools and MAKEDEV In-Reply-To: References: <20040908205820.73070.qmail@web50603.mail.yahoo.com> Message-ID: <414011DD.7070301@redhat.com> Alexandre Oliva wrote: > On Sep 8, 2004, Steve G wrote: > > >>%post >>cd /dev >>./MAKEDEV -m 16 md > > > Looks definitely wrong for a udev system. Please file this in > bugzilla, if you haven't done so yet. > Well, /dev/MAKEDEV is a symlink to /sbin, if system was started with the new udev. From fedora at wir-sind-cool.org Thu Sep 9 08:34:51 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 9 Sep 2004 10:34:51 +0200 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094706449.15411.36.camel@binkley> References: <1094701227.15411.13.camel@binkley> <1094704594.1064.72.camel@one.myworld> <1094706449.15411.36.camel@binkley> Message-ID: <20040909103451.438d00ca.fedora@wir-sind-cool.org> On Thu, 09 Sep 2004 01:07:29 -0400, seth vidal wrote: > On Thu, 2004-09-09 at 06:36 +0200, Matias Feliciano wrote: > > Le jeu 09/09/2004 ? 05:40, seth vidal a ?crit : > > > Hi Everyone, > > > I don't want a flamewar, just opinions. > > > > > > Are there a lot of people who use the two commands listed in the subject > > > very often? > > > > you can add > > --aid : > > add suggested packages to transaction > > --nosuggest : > > do not suggest missing dependency resolution(s) > > And on that subject. Are these often used? FWIW, I use --aid regularly for installs from a FC mirror on local disk. And I use rpmdb-fedora based queries for checking conflicts and directory ownerships of fedora.us packages. -- Fedora Core release 2 (Tettnang) - Linux 2.6.8-1.521 loadavg: 2.00 2.19 2.41 From twaugh at redhat.com Thu Sep 9 08:44:39 2004 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 9 Sep 2004 09:44:39 +0100 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094706449.15411.36.camel@binkley> References: <1094701227.15411.13.camel@binkley> <1094704594.1064.72.camel@one.myworld> <1094706449.15411.36.camel@binkley> Message-ID: <20040909084439.GR32028@redhat.com> On Thu, Sep 09, 2004 at 01:07:29AM -0400, seth vidal wrote: > On Thu, 2004-09-09 at 06:36 +0200, Matias Feliciano wrote: > > Le jeu 09/09/2004 ? 05:40, seth vidal a ?crit : > > > Hi Everyone, > > > I don't want a flamewar, just opinions. > > > > > > Are there a lot of people who use the two commands listed in the subject > > > very often? > > > > you can add > > --aid : > > add suggested packages to transaction > > --nosuggest : > > do not suggest missing dependency resolution(s) > > And on that subject. Are these often used? I use --aid all the time, and would *really* miss the rpmdb data it requires. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at wir-sind-cool.org Thu Sep 9 08:47:01 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 9 Sep 2004 10:47:01 +0200 Subject: Dependency reciprocity : real world problem with httpd and httpd-suexec In-Reply-To: <20040908080707.GB20605@redhat.com> References: <20040907153947.298cf4be@localhost> <1094586825.17961.119.camel@bobcat.mine.nu> <413E19B9.3060005@redhat.com> <1094592261.17961.158.camel@bobcat.mine.nu> <20040908080707.GB20605@redhat.com> Message-ID: <20040909104701.3a5a914c.fedora@wir-sind-cool.org> On Wed, 8 Sep 2004 09:07:07 +0100, Joe Orton wrote: > On Wed, Sep 08, 2004 at 12:24:21AM +0300, Ville Skytt? wrote: > > If PreReq does not "exist" in the sense it used to any more, one such > > "tool" which supposedly nowadays at least partially replaces/provides > > that functionality are "context markers" (ie. Requires(pre) and friends > > if I've understood _that_ correctly). > > > > [1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2003-October/000095.html > > I thought Requires(pre) and friends are just for dependencies of the > scripts? Yes, but since the scriptlets are contained within the same package, Requires(pre) is the earliest you can get for specifying pre-install dependencies of the entire package. > Can anyone state definitively (and preferably in plain English), if I > have in the httpd-suexec subpackage: > > PreReq: httpd > > the files contained in said package will be installed only after the > %pre script of the httpd package has run? Whatever package contains above line will be installed after httpd has been installed. httpd becomes a pre-install requirement. -- Fedora Core release 2 (Tettnang) - Linux 2.6.8-1.521 loadavg: 2.43 2.18 2.26 From skvidal at phy.duke.edu Thu Sep 9 05:37:32 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 09 Sep 2004 01:37:32 -0400 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094708067.22952.2713.camel@mccallum.corsepiu.local> References: <1094701227.15411.13.camel@binkley> <1094705853.22952.2664.camel@mccallum.corsepiu.local> <1094705978.15411.34.camel@binkley> <1094708067.22952.2713.camel@mccallum.corsepiu.local> Message-ID: <1094708252.15411.39.camel@binkley> > In particular I was thinking along the lines of shipping a metadata*rpm, > to replace rpmdb-fedora*rpm, because I'd expect the info contained in > both of them to be completely equivalent. > > Yum then could use this rpmdb-fedora-replacement rpm to setup its > initial package-metadata/header cache etc. well, yum doesn't need an initial header cache anymore - as of 2.1.X - it only needs the headers of the packages it will actually use in the transaction. > Another aspect, I am not sure about is if and how to reflect dynamically > set up metadata-caches to "rpm --redhat-*". > On one hand, ATM, rpm doesn't know anything about yum/apt/up2date, so > not considering this case would not be a regression. > On the other hand, if rpm is able to read metadata-files/caches, it > should not be too be difficult to extended it to read arbitrary > metadata-files/caches such as the ones being used by yum. Would it be presumptive to start thinking about tying more things around remote repositories or at least a set of repositories rather than a local cache of information? -sv From fedora at wir-sind-cool.org Thu Sep 9 08:37:32 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 9 Sep 2004 10:37:32 +0200 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094708067.22952.2713.camel@mccallum.corsepiu.local> References: <1094701227.15411.13.camel@binkley> <1094705853.22952.2664.camel@mccallum.corsepiu.local> <1094705978.15411.34.camel@binkley> <1094708067.22952.2713.camel@mccallum.corsepiu.local> Message-ID: <20040909103732.0b52c45b.fedora@wir-sind-cool.org> On Thu, 09 Sep 2004 07:34:27 +0200, Ralf Corsepius wrote: > > provide another 'some other command tool' that replaces the popt macro > > for 'rpm --redhat-*'? > Yes, this is essentially what I had in mind. +1 rpmdb-fedora is very useful, but is not updated after all the Fedora Core updates unless you do that yourself with --justdb and related RPM options. -- Fedora Core release 2 (Tettnang) - Linux 2.6.8-1.521 loadavg: 2.08 2.12 2.34 From feliciano.matias at free.fr Thu Sep 9 06:38:27 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 09 Sep 2004 08:38:27 +0200 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094706449.15411.36.camel@binkley> References: <1094701227.15411.13.camel@binkley> <1094704594.1064.72.camel@one.myworld> <1094706449.15411.36.camel@binkley> Message-ID: <1094711903.1064.130.camel@one.myworld> Le jeu 09/09/2004 ? 07:07, seth vidal a ?crit : > On Thu, 2004-09-09 at 06:36 +0200, Matias Feliciano wrote: > > Le jeu 09/09/2004 ? 05:40, seth vidal a ?crit : > > > Hi Everyone, > > > I don't want a flamewar, just opinions. > > > > > > Are there a lot of people who use the two commands listed in the subject > > > very often? > > > > you can add > > --aid : > > add suggested packages to transaction > > --nosuggest : > > do not suggest missing dependency resolution(s) > > And on that subject. Are these often used? > I think this is not really the point. I don't often use rpmdb. But sometimes rpmdb is useful in conjunction with "rpm -q -qf" ou "rpm -e --test". Exemple : what packages depend on xorg-x11-deprecated-libs ? # rpm -e --test --dbpath `pwd` xorg-x11-deprecated-libs erreur: D?pendances requises: libXp.so.6 est n?cessaire pour (d?j? install?) ddd-3.3.9-1 libXp.so.6 est n?cessaire pour (d?j? install?) nedit-5.4-2 libXp.so.6 est n?cessaire pour (d?j? install?) openmotif-2.2.3-5 libXp.so.6 est n?cessaire pour (d?j? install?) openmotif-devel-2.2.3-5 libXp.so.6 est n?cessaire pour (d?j? install?) openmotif21-2.1.30-11 libXp.so.6 est n?cessaire pour (d?j? install?) xorg-x11-6.7.99.903-6 libXp.so.6 est n?cessaire pour (d?j? install?) xorg-x11-tools-6.7.99.903-6 libXp.so.6 est n?cessaire pour (d?j? install?) xpdf-3.00-5 xorg-x11-deprecated-libs = 6.7.99.903-6 est n?cessaire pour (d?j? install?) xorg-x11-deprecated-libs-devel-6.7.99.903-6 With a local copy of rawhide, it's easy to create a custom rpmdb with "rpm --initdb" and "rpm -i --justdb --notrigger.... *.rpm" rpmdb is useful because *rpm* and not because yum ! I am not arguing to keep rpmdb. I am arguing to create something like : - yum install --justdb --dbpath usr/lib/rpmdb/i386-redhat-linux/redhat/ '*' or - repodata2rpmdb http://..../rawhide/repodata http://.../fedora.us/repodata /usr/lib/rpmdb/i386-redhat-linux/redhat/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From pmatilai at welho.com Thu Sep 9 09:58:17 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 9 Sep 2004 12:58:17 +0300 (EEST) Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <20040909103732.0b52c45b.fedora@wir-sind-cool.org> References: <1094701227.15411.13.camel@binkley> <1094705853.22952.2664.camel@mccallum.corsepiu.local> <1094705978.15411.34.camel@binkley> <1094708067.22952.2713.camel@mccallum.corsepiu.local> <20040909103732.0b52c45b.fedora@wir-sind-cool.org> Message-ID: On Thu, 9 Sep 2004, Michael Schwendt wrote: > On Thu, 09 Sep 2004 07:34:27 +0200, Ralf Corsepius wrote: > > > > provide another 'some other command tool' that replaces the popt macro > > > for 'rpm --redhat-*'? > > Yes, this is essentially what I had in mind. > > +1 > > rpmdb-fedora is very useful, but is not updated after all the Fedora > Core updates unless you do that yourself with --justdb and related RPM > options. I'm starting to have funny ideas about 'repoquery' (or whatever you want to call it) which does what rpmquery does but handles seamlessly both rpmdb and repository metadata information. AND provides meaningful answers to things like '--whatrequires foo' - this is one of my "favorites": [pmatilai at chip pmatilai]$ rpm -q --whatrequires openssl libpcap-0.8.3-3 curl-7.11.1-1 openssl-devel-0.9.7a-35 w3m-0.5-3 sendmail-8.12.11-4.6 dovecot-0.99.10.6-1,FC2,1 kdelibs-3.2.2-8.FC2 [pmatilai at chip pmatilai]$ A whopping 5 packages. Yet what REALLY requires openssl: [pmatilai at chip pmatilai]$ rpm -q --whatrequires `rpm -q --provides openssl`|grep -v "no package"|sort -u|wc -l 55 [pmatilai at chip pmatilai]$ Ooops... - Panu - From kbn at daimi.au.dk Thu Sep 9 10:22:43 2004 From: kbn at daimi.au.dk (Kim B. Nielsen) Date: Thu, 09 Sep 2004 12:22:43 +0200 Subject: Yum not working on development repos ?? In-Reply-To: <1094712707.15411.65.camel@binkley> References: <413F7D8A.6030507@daimi.au.dk> <1094712284.15909.11.camel@localhost.localdomain> <1094712707.15411.65.camel@binkley> Message-ID: <41402EF3.6010403@daimi.au.dk> Ok... But what to do now ?? Isn't there someone that will be so kind as to run the yum-arch on the development tree. It's kinda hard to update yum, when the old yum cannot find the headers... Surely I could do the upgrade by hand, but I would prefer by yum... Regards /kbn seth vidal wrote: >On Thu, 2004-09-09 at 07:44 +0100, David Woodhouse wrote: > > >>On Wed, 2004-09-08 at 23:45 +0200, Kim B. Nielsen wrote: >> >> >>>I've noticed that the headers directory (and the headers naturally) has >>>dissapeared from >>>http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/ >>> >>>Is this intentional, or a mishap ?? >>> >>> >>Apparently the metadata format changed. It's now created by 'createrepo' >>and yum-arch has disappeared. Apparently both yum and up2date ought to >>cope with the new format already. I couldn't get them to work though -- >>I just downgraded yum and ran 'yum-arch' again on my local mirror. >> >> > >yum-arch will return before fc3t3. Yum 2.1.X will work with the new >metadata, yes. > >-sv > > > > > -- "UNIX is user friendly, it's just selective about who its friends are." --Unknown From fedora at wir-sind-cool.org Thu Sep 9 10:32:20 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 9 Sep 2004 12:32:20 +0200 Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: References: <1094701227.15411.13.camel@binkley> <1094705853.22952.2664.camel@mccallum.corsepiu.local> <1094705978.15411.34.camel@binkley> <1094708067.22952.2713.camel@mccallum.corsepiu.local> <20040909103732.0b52c45b.fedora@wir-sind-cool.org> Message-ID: <20040909123220.746ec212.fedora@wir-sind-cool.org> On Thu, 9 Sep 2004 12:58:17 +0300 (EEST), Panu Matilainen wrote: > I'm starting to have funny ideas about 'repoquery' (or whatever you want > to call it) which does what rpmquery does but handles seamlessly both > rpmdb and repository metadata information. AND provides meaningful answers > to things like '--whatrequires foo' - this is one of my "favorites": > > [pmatilai at chip pmatilai]$ rpm -q --whatrequires openssl libpcap-0.8.3-3 > curl-7.11.1-1 > openssl-devel-0.9.7a-35 > w3m-0.5-3 > sendmail-8.12.11-4.6 > dovecot-0.99.10.6-1,FC2,1 > kdelibs-3.2.2-8.FC2 > [pmatilai at chip pmatilai]$ > > A whopping 5 packages. Yet what REALLY requires openssl: > > [pmatilai at chip pmatilai]$ rpm -q --whatrequires `rpm -q --provides > openssl`|grep -v "no package"|sort -u|wc -l > 55 > [pmatilai at chip pmatilai]$ > > Ooops... Yes, that's due to automatically generated dependencies on the openssl library sonames (libssl.so.4 and libcrypto.so.4) $ rpm -q --whatrequires $(rpm -q --provides openssl | grep lib) | wc -l 77 An interesting part about creating a new repoquery/rpmquery would be to create high-level queries which "know" how to find out which packages depend on "openssl" rather than letting the user find out complex queries like above. -- Fedora Core release 2 (Tettnang) - Linux 2.6.8-1.521 loadavg: 1.15 1.12 1.05 From pmatilai at welho.com Thu Sep 9 10:44:00 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 9 Sep 2004 13:44:00 +0300 (EEST) Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <1094711903.1064.130.camel@one.myworld> References: <1094701227.15411.13.camel@binkley> <1094704594.1064.72.camel@one.myworld> <1094706449.15411.36.camel@binkley> <1094711903.1064.130.camel@one.myworld> Message-ID: On Thu, 9 Sep 2004, Matias Feliciano wrote: > Le jeu 09/09/2004 ?? 07:07, seth vidal a ??crit : > > On Thu, 2004-09-09 at 06:36 +0200, Matias Feliciano wrote: > > > Le jeu 09/09/2004 ?? 05:40, seth vidal a ??crit : > > > > Hi Everyone, > > > > I don't want a flamewar, just opinions. > > > > > > > > Are there a lot of people who use the two commands listed in the subject > > > > very often? > > > > > > you can add > > > --aid : > > > add suggested packages to transaction > > > --nosuggest : > > > do not suggest missing dependency resolution(s) > > > > And on that subject. Are these often used? > > > > I think this is not really the point. > > I don't often use rpmdb. > But sometimes rpmdb is useful in conjunction with "rpm -q -qf" ou "rpm > -e --test". > Exemple : > what packages depend on xorg-x11-deprecated-libs ? > # rpm -e --test --dbpath `pwd` xorg-x11-deprecated-libs > erreur: D??pendances requises: > libXp.so.6 est n??cessaire pour (d??j?? install??) ddd-3.3.9-1 > libXp.so.6 est n??cessaire pour (d??j?? install??) nedit-5.4-2 [...] This is exactly the kind of madness we (or at least I) would like to *solve* with the new tool. See my other mail about this very thing where 'rpm --whatrequires' fails to give a decent answer. > > With a local copy of rawhide, it's easy to create a custom rpmdb with > "rpm --initdb" and "rpm -i --justdb --notrigger.... *.rpm" > > rpmdb is useful because *rpm* and not because yum ! It (the new tool) doesn't have to depend on yum, just the repomd libraries which currently come from the yum package but could be separated easily, although yum is hardly what I'd call a large package :) - Panu - From pmatilai at welho.com Thu Sep 9 10:38:51 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 9 Sep 2004 13:38:51 +0300 (EEST) Subject: rpm --redhat-requires, rpm --redhat-provides In-Reply-To: <20040909123220.746ec212.fedora@wir-sind-cool.org> References: <1094701227.15411.13.camel@binkley> <1094705853.22952.2664.camel@mccallum.corsepiu.local> <1094705978.15411.34.camel@binkley> <1094708067.22952.2713.camel@mccallum.corsepiu.local> <20040909103732.0b52c45b.fedora@wir-sind-cool.org> <20040909123220.746ec212.fedora@wir-sind-cool.org> Message-ID: On Thu, 9 Sep 2004, Michael Schwendt wrote: > On Thu, 9 Sep 2004 12:58:17 +0300 (EEST), Panu Matilainen wrote: > > > I'm starting to have funny ideas about 'repoquery' (or whatever you want > > to call it) which does what rpmquery does but handles seamlessly both > > rpmdb and repository metadata information. AND provides meaningful answers > > to things like '--whatrequires foo' - this is one of my "favorites": > > > > [pmatilai at chip pmatilai]$ rpm -q --whatrequires openssl libpcap-0.8.3-3 > > curl-7.11.1-1 > > openssl-devel-0.9.7a-35 > > w3m-0.5-3 > > sendmail-8.12.11-4.6 > > dovecot-0.99.10.6-1,FC2,1 > > kdelibs-3.2.2-8.FC2 > > [pmatilai at chip pmatilai]$ > > > > A whopping 5 packages. Yet what REALLY requires openssl: > > > > [pmatilai at chip pmatilai]$ rpm -q --whatrequires `rpm -q --provides > > openssl`|grep -v "no package"|sort -u|wc -l > > 55 > > [pmatilai at chip pmatilai]$ > > > > Ooops... > > Yes, that's due to automatically generated dependencies on the > openssl library sonames (libssl.so.4 and libcrypto.so.4) > > $ rpm -q --whatrequires $(rpm -q --provides openssl | grep lib) | wc -l > 77 > > An interesting part about creating a new repoquery/rpmquery would be > to create high-level queries which "know" how to find out which > packages depend on "openssl" rather than letting the user find out > complex queries like above. Well that's what I said above: "...provides meaningful answers to things like '--whatrequires foo'". Will work on this and based on a quick look inside repomd/*.py actually like it as well :) And along this road I'm perfectly willing to dump 1:1 rpmquery compatibility for something that's both user- and script-friendly. - Panu - From casimiro_barreto at uol.com.br Thu Sep 9 11:15:58 2004 From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto) Date: Thu, 09 Sep 2004 08:15:58 -0300 Subject: Yum not working on development repos ?? In-Reply-To: <41402EF3.6010403@daimi.au.dk> References: <413F7D8A.6030507@daimi.au.dk> <1094712284.15909.11.camel@localhost.localdomain> <1094712707.15411.65.camel@binkley> <41402EF3.6010403@daimi.au.dk> Message-ID: <41403B6E.5050109@uol.com.br> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From alan at redhat.com Thu Sep 9 11:38:59 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 9 Sep 2004 07:38:59 -0400 Subject: floppy install In-Reply-To: <413FB7E1.5020001@neenet.com> References: <413FACCF.2090500@neenet.com> <20040909023507.GA18541@wolves.durham.nc.us> <413FB7E1.5020001@neenet.com> Message-ID: <20040909113859.GA600@devserv.devel.redhat.com> On Wed, Sep 08, 2004 at 09:54:41PM -0400, Lonnie Cumberland wrote: > What about the possibility of having a multi-floppy version of the > boot.iso in that older machines would be able to take advantage of > Fedora as well? Assuming you have a CD-ROM drive then you only need enough to boot that CD-ROM images. > worth investigating? Probably > Well, just my small input on what I see is a small short-fall of the system. There is a howto on installing Fedora without either a Floppy or CDROM which may also be helpful especially if you have a network: http://www-2.cs.cmu.edu/~colohan/docs/fedora_upgrade.html From jorton at redhat.com Thu Sep 9 12:02:53 2004 From: jorton at redhat.com (Joe Orton) Date: Thu, 9 Sep 2004 13:02:53 +0100 Subject: Another FC3test2 candidate tree In-Reply-To: <1A03C3EC-0205-11D9-8ED4-000D93565D78@redhat.com> References: <1A03C3EC-0205-11D9-8ED4-000D93565D78@redhat.com> Message-ID: <20040909120252.GA2801@redhat.com> On Wed, Sep 08, 2004 at 10:08:11PM -0400, Elliot Lee wrote: > The previous bug reports on the re0903.0 tree were very helpful - > here's another one to chew on: > > http://fedora.linux.duke.edu/FC3-re0908.0/ This is still broken out-of-the-box for me since network interfaces are not getting addresses. Mmmmm... OK, they are getting addresses but NetworkManager is taking them away. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132156 From mk at crc.dk Thu Sep 9 12:34:31 2004 From: mk at crc.dk (Mogens Kjaer) Date: Thu, 09 Sep 2004 14:34:31 +0200 Subject: floppy install In-Reply-To: <20040909113859.GA600@devserv.devel.redhat.com> References: <413FACCF.2090500@neenet.com> <20040909023507.GA18541@wolves.durham.nc.us> <413FB7E1.5020001@neenet.com> <20040909113859.GA600@devserv.devel.redhat.com> Message-ID: <41404DD7.2070706@crc.dk> Alan Cox wrote: > On Wed, Sep 08, 2004 at 09:54:41PM -0400, Lonnie Cumberland wrote: > >>What about the possibility of having a multi-floppy version of the >>boot.iso in that older machines would be able to take advantage of >>Fedora as well? > > > Assuming you have a CD-ROM drive then you only need enough to boot that > CD-ROM images. > > >>worth investigating? If you have a floppy drive and a CDROM on a machine where the BIOS is too old to boot FC2, you can use http://btmgr.sourceforge.net/about.html I've used the version from Debian, in sarge-i386-netinst.iso /install/sbm.bin Copy it to a floppy, boot from it, select the CDROM, and it will continue to load FC2 from the CDROM. This worked for FC2 and FreeBSD. Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From linux_4ever at yahoo.com Thu Sep 9 12:28:35 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 9 Sep 2004 05:28:35 -0700 (PDT) Subject: raidtools and MAKEDEV In-Reply-To: <414011DD.7070301@redhat.com> Message-ID: <20040909122835.7956.qmail@web50605.mail.yahoo.com> > Looks definitely wrong for a udev system. Please file this in > bugzilla, if you haven't done so yet. > > >Well, /dev/MAKEDEV is a symlink to /sbin, if system was started with the new >udev. I just backed out my patch and it still fails. The problem is that udev is not running when I do the installation. When the full path is given, there's no problem during installation. This is not using anaconda, this is installing to a test partition after building. You would never want udev to make entries into a chroot test partition during install. Its fine when the system reboots to that partition. So what's the consensus? A quirk of my build system, or do you want to make ./MAKEDEV into a full path for raidtools? It should be simple enough to fix raidtools to do this: %post cd /dev %if [ -x ./MAKEDEV ] ; then ./MAKEDEV -m 16 md %else /sbin/MAKEDEV -m 16 md %fi This solves it for old and new systems. Thanks, -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From veguilla at hpcf.upr.edu Thu Sep 9 10:34:55 2004 From: veguilla at hpcf.upr.edu (Ricardo Veguilla) Date: Thu, 09 Sep 2004 06:34:55 -0400 Subject: Yum not working on development repos ?? In-Reply-To: <41402EF3.6010403@daimi.au.dk> References: <413F7D8A.6030507@daimi.au.dk> <1094712284.15909.11.camel@localhost.localdomain> <1094712707.15411.65.camel@binkley> <41402EF3.6010403@daimi.au.dk> Message-ID: <1094726096.12245.6.camel@ricardo.veguilla.net> On Thu, 2004-09-09 at 12:22 +0200, Kim B. Nielsen wrote: > Ok... But what to do now ?? > You can: a) Update yum manually. Download the latest yum from: http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/ and update it manually (rpm -Uhv ) and then use yum to update your system. b) use "up2date" to update yum an then update the system c) use "up2date" to update the whole system -- Ricardo Veguilla From katzj at redhat.com Thu Sep 9 14:47:14 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 09 Sep 2004 10:47:14 -0400 Subject: raidtools and MAKEDEV In-Reply-To: <20040908205820.73070.qmail@web50603.mail.yahoo.com> References: <20040908205820.73070.qmail@web50603.mail.yahoo.com> Message-ID: <1094741234.4850.3.camel@bree.local.net> On Wed, 2004-09-08 at 13:58 -0700, Steve G wrote: > Looking at the raidtools spec file: > > %post > cd /dev > ./MAKEDEV -m 16 md > > So I change raidtools to use /sbin/MAKEDEV and then it spews errors: [snip] > Does anyone else see raidtools die like this or is it just my setup and anaconda > takes care of these details? Do you want this in bugzilla? raidtools hasn't been > updated for a long time. This is broken... of course, the plan is to finish the switchover of everything to using mdadm instead of raidtools (the only thing outstanding is initscripts), at which point raidtools will die the death it deserves. :) Jeremy From cra at WPI.EDU Thu Sep 9 15:10:58 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 9 Sep 2004 11:10:58 -0400 Subject: Another FC3test2 candidate tree In-Reply-To: <20040909120252.GA2801@redhat.com> References: <1A03C3EC-0205-11D9-8ED4-000D93565D78@redhat.com> <20040909120252.GA2801@redhat.com> Message-ID: <20040909151058.GE27565@angus.ind.WPI.EDU> On Thu, Sep 09, 2004 at 01:02:53PM +0100, Joe Orton wrote: > On Wed, Sep 08, 2004 at 10:08:11PM -0400, Elliot Lee wrote: > > The previous bug reports on the re0903.0 tree were very helpful - > > here's another one to chew on: > > > > http://fedora.linux.duke.edu/FC3-re0908.0/ > > This is still broken out-of-the-box for me since network interfaces are > not getting addresses. Mmmmm... OK, they are getting addresses but > NetworkManager is taking them away. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132156 I'm seeing something similar. I get an IP address on bootup, and this works for "awhile". Then I lose connectivity. I noticed that dhclient was trying to renew with a unicast request directly to my dhcp server's IP address, but since there was no IP configured on the eth0 interface, it was failing. The NetworkManager service had died, leaving a stale /var/lock/subsys/ file around. Restarting the NetworkManager service fixed it. From buildsys at redhat.com Thu Sep 9 15:21:58 2004 From: buildsys at redhat.com (Build System) Date: Thu, 9 Sep 2004 11:21:58 -0400 Subject: rawhide report: 20040909 changes Message-ID: <200409091521.i89FLww10605@porkchop.devel.redhat.com> New package linuxwacom Wacom Drivers from Linux Wacom Project Updated Packages: anaconda-10.0.2-2 ----------------- * Wed Sep 08 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode cdrdao-1.1.9-4 -------------- * Wed Sep 08 2004 Harald Hoyer - 1.1.9-4 - build requires newer cdrecord-devel cdrtools-2.01.0.a38-2 --------------------- * Wed Sep 08 2004 Harald Hoyer - 8:2.01.0.a38-2 - improved the scanbus routing (scan.patch) now using glob(3) - removed linuxcheck() * Fri Sep 03 2004 Harald Hoyer - 8:2.01.0.a38-1 - updated to version 2.01.0.a38 - corrected the permissions for /etc/cdrecord.conf (bug 131541) devlabel-0.48.03-4 ------------------ * Wed Sep 08 2004 Bill Nottingham 0.48.03-4 - remove typo patch * Tue Sep 07 2004 Bill Nottingham - use /etc/sysconfig/devlabel.d, not /var/lib/devalbel eject-2.0.13-10 --------------- * Tue Sep 07 2004 Than Ngo 2.0.13-10 - Added patch to find name in /media gtk2-2.4.9-6 ------------ * Tue Sep 07 2004 Matthias Clasen - 2.4.9-6 - fix expander drawing (#131676) httpd-2.0.50-7 -------------- * Wed Sep 08 2004 Joe Orton 2.0.50-7 - prereq rather than just require httpd from -suexec (#132045) initscripts-7.78-2 ------------------ * Wed Sep 08 2004 Dan Walsh - 7.78-2 - fix setting SELinux contexts on udev-created-in-initrd devices - Let restorecon check if selinux is enabled. * Wed Sep 08 2004 Bill Nottingham - 7.78-1 - set SELinux contexts on udev-created-in-initrd devices, if necessary kdebase-3.3.0-3 --------------- * Wed Sep 08 2004 Than Ngo 6:3.3.0-3 - Fix ALT-F2 command line opens on wrong desktop bug #129698 kdelibs-3.3.0-2 --------------- * Tue Sep 07 2004 Than Ngo 6:3.3.0-2 - add patch to fix KDE trash always full #122988 kudzu-1.1.88-1 -------------- * Wed Sep 08 2004 Bill Nottingham - 1.1.88-1 - fix pcitable parsing bug introduced in 1.1.86-1 libgnomeprintui22-2.7.1-7 ------------------------- * Tue Aug 31 2004 Matthias Clasen 2.7.1-7 - Fix handling of selection changes when the previously selected printer is gone. (#131626) libselinux-1.17.9-1 ------------------- * Wed Sep 08 2004 Dan Walsh 1.17.9-1 - Update from NSA * Added get_default_context_with_role. mkinitrd-4.1.10-1 ----------------- * Wed Sep 08 2004 Jeremy Katz - 4.1.10-1 - mkinitrd: mount tmpfs with the right permissions net-snmp-5.1.2-4 ---------------- * Wed Sep 08 2004 Radek Vokal 5.1.2-4 - New prereq for net-snmp-devel - lelf check removed from configure.in (#128748) - fixed snmpd coredump when sent SIGHUP (#127314) pango-1.5.2-3 ------------- * Wed Sep 08 2004 Jeremy Katz - 1.5.2-3 - fix running of pango-query-modules to have necessary libraries available (#132052) pcmcia-cs-3.2.7-1.10 -------------------- * Wed Sep 08 2004 Bill Nottingham - minor init script fixes (#121742,#127627) - remove references to updfstab (#131337) - move initscript before network (#various) rpmdb-fedora-2.91-0.20040909 ---------------------------- udev-030-23 ----------- * Wed Sep 08 2004 Harald Hoyer - 030-23 - mount tmpfs with mode 0755 in start_udev umb-scheme-3.2-34 ----------------- * Thu Aug 26 2004 Jindrich Novy - updated slib to 3a1 - added slib license information vim-6.3.025-2 ------------- * Wed Sep 08 2004 Karsten Hopp 6.3.025-2 - clean up spec file - disable fontset - enable cscope * Mon Sep 06 2004 Karsten Hopp 6.3.025-1 - patchlevel 25 From linux_4ever at yahoo.com Thu Sep 9 13:05:17 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 9 Sep 2004 06:05:17 -0700 (PDT) Subject: First boot with 20040908 changes Message-ID: <20040909130517.21053.qmail@web50602.mail.yahoo.com> Hi, Just got the system up with the latest changes. kudzu-1.1.87-1, MAKEDEV-3.12-1, udev-030-22, & hal-0.2.97.cvs20040901-1. First, I get this message: Sep 9 08:44:43 buildhost kernel: PCI: Probing PCI hardware (bus 00) Sep 9 08:44:43 buildhost kernel: get_random_bytes called before random driver initialization This doesn't sound good. Then I got a series of messages like: "/sbin/restorecon get context on /dev failed: Operation not supported" "/usr/sbin/setfiles unable to obtain attr for /dev" These did not get into syslog. Problems from restorecon & setfiles like this should be logged. Then kudzu detected my usb hub twice. And finally: Sep 9 08:44:53 buildhost fstab-sync[2607]: removed all generated mount points Sep 9 08:44:53 buildhost fstab-sync[2649]: added mount point /media/idedisk for /dev/hda5 Sep 9 08:44:54 buildhost fstab-sync[2655]: added mount point /media/idedisk1 for /dev/hda1 Sep 9 08:44:54 buildhost fstab-sync[2686]: added mount point /media/scsidisk for /dev/sda2 Sep 9 08:44:54 buildhost fstab-sync[2689]: added mount point /media/scsidisk1 for /dev/sda1 I hand edit my /etc/fstab to only have these disks: /dev/sda3, /dev/sda5. I really do not want anything else accessible to the system...its a security violation in my view. The sad part is that it did not recognize the cdrom which is /dev/hdc. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From jspaleta at gmail.com Thu Sep 9 16:11:48 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 9 Sep 2004 12:11:48 -0400 Subject: First boot with 20040908 changes In-Reply-To: <20040909130517.21053.qmail@web50602.mail.yahoo.com> References: <20040909130517.21053.qmail@web50602.mail.yahoo.com> Message-ID: <604aa791040909091164beabbf@mail.gmail.com> On Thu, 9 Sep 2004 06:05:17 -0700 (PDT), Steve G wrote: > I hand edit my /etc/fstab to only have these disks: /dev/sda3, /dev/sda5. I > really do not want anything else accessible to the system...its a security > violation in my view. The sad part is that it did not recognize the cdrom which > is /dev/hdc. Sounds to me like you need to either complete disable hal or invest some time into learning how to configure hal for your local system policy to show only devices of your choosing. -jef From mike at flyn.org Thu Sep 9 16:10:32 2004 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 9 Sep 2004 11:10:32 -0500 (CDT) Subject: First boot with 20040908 changes In-Reply-To: <20040909130517.21053.qmail@web50602.mail.yahoo.com> References: <20040909130517.21053.qmail@web50602.mail.yahoo.com> Message-ID: <2995.66.151.13.191.1094746232.squirrel@66.151.13.191> [...] > Then I got a series of messages like: "/sbin/restorecon get context on > /dev failed: Operation not supported" "/usr/sbin/setfiles unable to > obtain attr for /dev" > > These did not get into syslog. Problems from restorecon & setfiles like > this should be logged. Have you rebuilt your initd with a recent version of mkinitrd? Mkinitrd and udev now use tmpfs instead of ramfs to host /dev. Tmpfs supports SELinux EA's (with the patch Red Hat applies). Ramfs does not. > [...] -- Mike From m.a.young at durham.ac.uk Thu Sep 9 16:21:50 2004 From: m.a.young at durham.ac.uk (M A Young) Date: Thu, 9 Sep 2004 17:21:50 +0100 (BST) Subject: Yum not working on development repos ?? In-Reply-To: <41403B6E.5050109@uol.com.br> References: <413F7D8A.6030507@daimi.au.dk> <1094712284.15909.11.camel@localhost.localdomain> <1094712707.15411.65.camel@binkley> <41402EF3.6010403@daimi.au.dk> <41403B6E.5050109@uol.com.br> Message-ID: On Thu, 9 Sep 2004, Casimiro de Almeida Barreto wrote: > That's what I get from yum, lately: > > [root at 200-170-99-221 ~]# yum update > Setting up Update Process > Setting up Repo: development > repodata/repomd.xml: [Errno 4] IOError: HTTP Error 404: Not > Found > Cannot open/read repomd.xml file for repository: development > failure: repodata/repomd.xml from development: [Errno 256] No > more mirrors to try. It looks like neither header type is being built on the development tree at the moment - there are currently some errors in the ppc64-logs directory which suggests that the build of that platform is broken. Michael Young From russell at coker.com.au Thu Sep 9 16:33:35 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 10 Sep 2004 02:33:35 +1000 Subject: /proc and init Message-ID: <200409100233.35615.russell@coker.com.au> During the early stages of boot /sbin/init mounts /proc so that it can check for the presence of SE Linux. After it has finished doing the SE Linux stuff it will umount /proc. What I want to know is, why umount /proc? Why not just leave it mounted? It seems a waste to umount it when you are just going to mount it again later. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From linux_4ever at yahoo.com Thu Sep 9 16:41:36 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 9 Sep 2004 09:41:36 -0700 (PDT) Subject: First boot with 20040908 changes In-Reply-To: <2995.66.151.13.191.1094746232.squirrel@66.151.13.191> Message-ID: <20040909164136.4254.qmail@web50602.mail.yahoo.com> >Have you rebuilt your initd with a recent version of mkinitrd? Yes, I use mkinitrd-4.1.9-1. I also still have 2 /proc's and 2 /dev's. So who knows which /dev its complaining about. /proc /proc proc rw,nodiratime 0 0 none /dev tmpfs rw 0 0 /dev/root / ext3 rw 0 0 none /dev tmpfs rw 0 0 none /selinux selinuxfs rw 0 0 /proc /proc proc rw,nodiratime 0 0 -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From brugolsky at telemetry-investments.com Thu Sep 9 13:10:34 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 9 Sep 2004 09:10:34 -0400 Subject: rawhide report: 20040906 changes In-Reply-To: <1094478796.2799.11.camel@laptop.fenrus.com> References: <200409061301.i86D1sV01771@porkchop.devel.redhat.com> <1094478796.2799.11.camel@laptop.fenrus.com> Message-ID: <20040909131034.GB1384@ti64.telemetry-investments.com> On Mon, Sep 06, 2004 at 03:53:16PM +0200, Arjan van de Ven wrote: > fwiw the kernel went backwards in revision due to the corruption reports > about 541; 540 has the online resize patch disabled which is one of the > two main suspects. FWIW (not much), I've been running variants of your kernels (with 4G/4G and Exec Shield dropped) patched with Stephen's 2.6.6-rc1 ext3 online resize patch for several months, and I've seen no corruption. Regards, Bill Rugolsky From sopwith at redhat.com Thu Sep 9 17:40:02 2004 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 9 Sep 2004 13:40:02 -0400 (EDT) Subject: Fedora Core 3 test 2 schedule change Message-ID: Hi all, The plan is changing a bit and the intention right now is to release FC3test2 to the public on September 20. There are too many niggling issues remaining in the test2 candidate trees. firstboot still isn't quite there, and hardware detection & X seem to have a few issues. Please continue to look at http://fedora.linux.duke.edu/FC3-re0908.0/ and find other problems that must be fixed for the test release. Issues that must be fixed generally are ones that prevent most users from installing & setting up a running system, or bad app crashes. Please use http://bugzilla.redhat.com/bugzilla/ to report issues so the developers can keep things straight. :) Best, -- Elliot It doesn't matter what temperature the room is. It's always room-temperature. From kyrre at solution-forge.net Thu Sep 9 16:55:19 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 09 Sep 2004 18:55:19 +0200 Subject: rawhide report: 20040908 changes In-Reply-To: <20040908223617.GD11970@devserv.devel.redhat.com> References: <200409081759.i88Hxvm32516@porkchop.devel.redhat.com> <413F6768.6000204@hhs.nl> <1094674750.4994.3.camel@kyrre> <20040908223617.GD11970@devserv.devel.redhat.com> Message-ID: <1094745325.2715.2.camel@kyrre> Okay. Anyway ill got a geforce 2 mx pci card now. :P Got from a friend of mine, which pulled it out of the old computer he had in the closet... And it got twice the amount of RAM, doesn't crash (yes the vodoo was instable! Suddenly the screen would freeze/go black etc. HW failure?) tor, 09.09.2004 kl. 00.36 skrev Alan Cox: > On Wed, Sep 08, 2004 at 10:19:10PM +0200, Kyrre Ness Sjobak wrote: > > Hmmm... Ill never got 3d out of my vodoo 3 (fc2). Was there any vodoo to > > it, exept from installing? > > It doesn't work for 3D in FC2 - thats a known problem. Hans fixed it for > FC3test and contributed patches. > > Alan > From lnxxprt at arcor.de Thu Sep 9 17:56:17 2004 From: lnxxprt at arcor.de (D. Stolte) Date: Thu, 09 Sep 2004 19:56:17 +0200 Subject: Fedora Core 3 test 2 schedule change In-Reply-To: References: Message-ID: <41409941.8070805@arcor.de> hi all to delay the release of fc3test2 seems to be a good idea IMHO. but please, someone @redhat should create the repodata ASAP so that we can test and report the bugs or fixes of the new packages. /ds Elliot Lee wrote: > Hi all, > > The plan is changing a bit and the intention right now is to release > FC3test2 to the public on September 20. > > There are too many niggling issues remaining in the test2 candidate trees. > firstboot still isn't quite there, and hardware detection & X seem to have > a few issues. Please continue to look at > http://fedora.linux.duke.edu/FC3-re0908.0/ and find other problems that > must be fixed for the test release. Issues that must be fixed generally > are ones that prevent most users from installing & setting up a running > system, or bad app crashes. Please use > http://bugzilla.redhat.com/bugzilla/ to report issues so the developers > can keep things straight. :) > > Best, > -- Elliot > It doesn't matter what temperature the room is. It's always room-temperature. > > From kyrre at solution-forge.net Thu Sep 9 18:06:27 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 09 Sep 2004 20:06:27 +0200 Subject: Fedora Core 3 test 2 schedule change In-Reply-To: <41409941.8070805@arcor.de> References: <41409941.8070805@arcor.de> Message-ID: <1094753187.2715.15.camel@kyrre> If this helps making the quality of FC3 better, i am more than willing to wait. tor, 09.09.2004 kl. 19.56 skrev D. Stolte: > hi all > > to delay the release of fc3test2 seems to be a good idea IMHO. but > please, someone @redhat should create the repodata ASAP so that we can > test and report the bugs or fixes of the new packages. > > /ds > > Elliot Lee wrote: > > Hi all, > > > > The plan is changing a bit and the intention right now is to release > > FC3test2 to the public on September 20. > > > > There are too many niggling issues remaining in the test2 candidate trees. > > firstboot still isn't quite there, and hardware detection & X seem to have > > a few issues. Please continue to look at > > http://fedora.linux.duke.edu/FC3-re0908.0/ and find other problems that > > must be fixed for the test release. Issues that must be fixed generally > > are ones that prevent most users from installing & setting up a running > > system, or bad app crashes. Please use > > http://bugzilla.redhat.com/bugzilla/ to report issues so the developers > > can keep things straight. :) > > > > Best, > > -- Elliot > > It doesn't matter what temperature the room is. It's always room-temperature. > > > > > From david at fubar.dk Thu Sep 9 18:21:00 2004 From: david at fubar.dk (David Zeuthen) Date: Thu, 09 Sep 2004 20:21:00 +0200 Subject: First boot with 20040908 changes In-Reply-To: <20040909130517.21053.qmail@web50602.mail.yahoo.com> References: <20040909130517.21053.qmail@web50602.mail.yahoo.com> Message-ID: <1094754060.9937.14.camel@localhost.localdomain> On Thu, 2004-09-09 at 06:05 -0700, Steve G wrote: > Sep 9 08:44:53 buildhost fstab-sync[2607]: removed all generated mount points > Sep 9 08:44:53 buildhost fstab-sync[2649]: added mount point /media/idedisk for > /dev/hda5 > Sep 9 08:44:54 buildhost fstab-sync[2655]: added mount point /media/idedisk1 for > /dev/hda1 > Sep 9 08:44:54 buildhost fstab-sync[2686]: added mount point /media/scsidisk for > /dev/sda2 > Sep 9 08:44:54 buildhost fstab-sync[2689]: added mount point /media/scsidisk1 > for /dev/sda1 > Are there valid mountable filesystems on these partitions? > I hand edit my /etc/fstab to only have these disks: /dev/sda3, /dev/sda5. I > really do not want anything else accessible to the system...its a security > violation in my view. I'm not sure I agree: if one cares about security one is using filesystems with uid/gid attributes anyway. That said, however, it might be useful to have a configuration file fstab-sync to explicitly specify don't add this or that drive. And in the longterm finetune the mount point names, e.g. using labels or whatnot. You could also just remove the kudzu,user option from the fstab file for the entries you are concerned about. That way they wont get added the next time you start the haldaemon service and no unprivileged user is able to mount them. > The sad part is that it did not recognize the cdrom which > is /dev/hdc. > This should work. What does 'udevinfo -r -q name -p /block/hdc' say? I've seen on some occasions that udevstart doesn't run; at least the udev database isn't populated with sufficient information to do the udevinfo. Does running 'service haldaemon stop; udevstart; service haldaemon start' solve your problem? Does ude Otherwise you need to file a bug against hal to we can fix it. Thanks, David From notting at redhat.com Thu Sep 9 18:34:18 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 9 Sep 2004 14:34:18 -0400 Subject: RFC: cleaning up updates and updates-testing Message-ID: <20040909183417.GB15025@nostromo.devel.redhat.com> At the moment, the Fedora updates tree is somewhat out of hand (look, wow - 27G). Does anyone have any specific and concrete objections to removing older, superceded, updates? Bill From kbn at daimi.au.dk Thu Sep 9 18:35:48 2004 From: kbn at daimi.au.dk (Kim B. Nielsen) Date: Thu, 09 Sep 2004 20:35:48 +0200 Subject: Yum not working on development repos ?? In-Reply-To: <1094726096.12245.6.camel@ricardo.veguilla.net> References: <413F7D8A.6030507@daimi.au.dk> <1094712284.15909.11.camel@localhost.localdomain> <1094712707.15411.65.camel@binkley> <41402EF3.6010403@daimi.au.dk> <1094726096.12245.6.camel@ricardo.veguilla.net> Message-ID: <4140A284.3070003@daimi.au.dk> Ricardo Veguilla wrote: >On Thu, 2004-09-09 at 12:22 +0200, Kim B. Nielsen wrote: > > >>Ok... But what to do now ?? >> >> >> > >You can: > >a) Update yum manually. > >Download the latest yum from: >http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/ >and update it manually (rpm -Uhv ) and then use yum to update your >system. > >b) use "up2date" to update yum an then update the system > >c) use "up2date" to update the whole system > > > > Ok.. I'm trying plan b first: [root at furious root]# rpm -q yum yum-2.0.7-3 [root at furious root]# up2date -u yum http://fedora.redhat.com/download/up2date-mirrors/fedora-core-2 using mirror: http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/ http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc2 using mirror: http://mirror.hiwaay.net/redhat/fedora/linux/core/updates/2/i386/ There was a fatal error communicating with the server. The message was: An HTTP error occurred: URL: http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386//headers/header.info Status Code: 404 Error Message: Not Found That didn't work. But then plan c doesn't work either. Then on to plan a: [root at furious root]# rpm -Uvh /home/kbn/yum-2.1.3-1.noarch.rpm warning: /home/kbn/yum-2.1.3-1.noarch.rpm: V3 DSA signature: NOKEY, key ID 30c9ecf8 Preparing... ########################################### [100%] 1:yum ########################################### [100%] [root at furious root]# vi /etc/yum.conf [root at furious root]# yum update Setting up Update Process Setting up Repo: development repodata/repomd.xml: [Errno 4] IOError: HTTP Error 404: Not Found Cannot open/read repomd.xml file for repository: development failure: repodata/repomd.xml from development: [Errno 256] No more mirrors to try. Doesn't work either... That is, I'm unable to update in any case. Tho only way left, as I can see, is to download the entire beast, create my own headers, and the yum update the lot... Regards /kbn From balay at fastmail.fm Thu Sep 9 18:45:10 2004 From: balay at fastmail.fm (Satish Balay) Date: Thu, 9 Sep 2004 13:45:10 -0500 (CDT) Subject: Yum not working on development repos ?? In-Reply-To: <4140A284.3070003@daimi.au.dk> References: <413F7D8A.6030507@daimi.au.dk> <1094712284.15909.11.camel@localhost.localdomain> <1094712707.15411.65.camel@binkley> <41402EF3.6010403@daimi.au.dk> <1094726096.12245.6.camel@ricardo.veguilla.net> <4140A284.3070003@daimi.au.dk> Message-ID: On Thu, 9 Sep 2004, Kim B. Nielsen wrote: > http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/ using FC2 repo for rawhide? > repodata/repomd.xml: [Errno 4] IOError: HTTP Error 404: Not Found > Cannot open/read repomd.xml file for repository: development > failure: repodata/repomd.xml from development: [Errno 256] No more mirrors to > try. > That is, I'm unable to update in any case. Tho only way left, as I can see, is > to download the entire beast, create my own headers, and the yum update the > lot... Yeah - the repo-data (both yum-arch & createrepo) are broken on the rawhide download site. We'll just have to wait until it gets fixed. (or as you sugest mirror/create the repo-data locally) Satish From russell at coker.com.au Thu Sep 9 19:18:03 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 10 Sep 2004 05:18:03 +1000 Subject: nash Message-ID: <200409100518.03899.russell@coker.com.au> In what situation will nash create /dev/md0? What command-line parameter to nash causes this? avc: denied { create } for pid=1528 exe=/sbin/nash name=md0 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:device_t tclass=blk_file -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From notting at redhat.com Thu Sep 9 19:23:23 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 9 Sep 2004 15:23:23 -0400 Subject: nash In-Reply-To: <200409100518.03899.russell@coker.com.au> References: <200409100518.03899.russell@coker.com.au> Message-ID: <20040909192323.GB15732@nostromo.devel.redhat.com> Russell Coker (russell at coker.com.au) said: > In what situation will nash create /dev/md0? What command-line parameter to > nash causes this? raidautorun /dev/ Used for triggering the kernel's raid autodetection code. Bill From russell at coker.com.au Thu Sep 9 19:36:59 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 10 Sep 2004 05:36:59 +1000 Subject: tmpfs /dev Message-ID: <200409100536.59711.russell@coker.com.au> I have got a working system with tmpfs /dev and with udev in the initrd. I modified /sbin/init to run the following script immediately after loading the policy: #!/bin/sh . /etc/selinux/config /sbin/setfiles-mine /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts /dev Naturally we need to change the location of setfiles to /sbin from /usr/sbin if this is the solution we choose as this script will run before any file systems are mounted. Below is the policy I added. I had already changed the type declarations to use the dev_filesystem attribute for everything that may occur under /dev (patch sent to the main SE Linux list). I have setfiles being run as kernel_t because I feel that running setfiles as kernel_t is better than granting setfiles_t more access than is otherwise required. This means that I have to grant kernel_t access to relabel the device nodes, no big deal IMHO as kernel_t generally has ultimate access anyway. I relabeled /sbin/MAKEDEV as udev_exec_t so that it runs as udev_t when run from /sbin/start_udev and can do the things that it wants to do. This is a minor hack. Maybe it would be better to label /sbin/start_udev as udev_exec_t? That would remove the need to allow initrc_t to create sym-links under /dev. avc: denied { getattr } for pid=1641 exe=/sbin/lvm.static path=/sbin/MAKEDEV dev=dm-0 ino=196261 scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:udev_exec_t tclass=file Why does lvm.static want to stat /sbin/MAKEDEV? Seems strange to me. Below is the policy I wrote to allow tmpfs /dev and udev in initrd. I haven't split it into all the relevant .te files because it's still an experiment at this stage. After some discussion I'll produce a release version. # for tmpfs /dev allow dev_filesystem tmpfs_t:filesystem associate; allow kernel_t tmpfs_t:chr_file rw_file_perms; allow kernel_t tmpfs_t:{ dir file lnk_file chr_file blk_file } { getattr relabel from }; allow kernel_t device_t:{ dir lnk_file chr_file blk_file } relabelto; allow kernel_t device_type:{ chr_file blk_file } relabelto; allow kernel_t udev_tbl_t:file relabelto; can_exec(kernel_t, { sbin_t setfiles_exec_t }) # for /dev/pts on tmpfs allow mount_t tmpfs_t:dir mounton; # for /sbin/MAKEDEV - why? allow lvm_t udev_exec_t:file getattr; # allow /sbin/start_udev to run ln allow initrc_t device_t:lnk_file create_lnk_perms; -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From Nicolas.Mailhot at laPoste.net Thu Sep 9 19:44:10 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 09 Sep 2004 21:44:10 +0200 Subject: Yum not working on development repos ?? In-Reply-To: <4140A284.3070003@daimi.au.dk> References: <413F7D8A.6030507@daimi.au.dk> <1094712284.15909.11.camel@localhost.localdomain> <1094712707.15411.65.camel@binkley> <41402EF3.6010403@daimi.au.dk> <1094726096.12245.6.camel@ricardo.veguilla.net> <4140A284.3070003@daimi.au.dk> Message-ID: <1094759051.3407.1.camel@rousalka.dyndns.org> Le jeudi 09 septembre 2004 ? 20:35 +0200, Kim B. Nielsen a ?crit : > Ricardo Veguilla wrote: > > >On Thu, 2004-09-09 at 12:22 +0200, Kim B. Nielsen wrote: > > > > > >>Ok... But what to do now ?? > >> > >> > >> > > > >You can: > > > >a) Update yum manually. > > > >Download the latest yum from: > >http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/ > >and update it manually (rpm -Uhv ) and then use yum to update your > >system. > > > >b) use "up2date" to update yum an then update the system > > > >c) use "up2date" to update the whole system > > d) [root at rousalka ~]# apt-get dist-upgrade Reading Package Lists... Done Building Dependency Tree... Done Calculating Upgrade... Done The following packages will be upgraded ImageMagick (6.0.6.2-1 => 6.0.6.2-2) ImageMagick-perl (6.0.6.2-1 => 6.0.6.2-2) MAKEDEV (3.11-1 => 3.12-1) arts (1.3.0-1 => 1.3.0-3) authconfig (4.6.3-2 => 4.6.4-2) authconfig-gtk (4.6.3-2 => 4.6.4-2) cdda2wav (2.01.0.a37.99-1 => 2.01.0.a38-2) cdrecord (2.01.0.a37.99-1 => 2.01.0.a38-2) control-center (2.7.1-2 => 2.7.1-3) dev (3.11-1 => 3.12-1) devlabel (0.48.03-2 => 0.48.03-4) eject (2.0.13-9 => 2.0.13-10) finger (0.17-25 => 0.17-26) firefox (0.9.3-7 => 0.9.3-8) glibc (2.3.3-47 => 2.3.3-49) glibc-common (2.3.3-47 => 2.3.3-49) glibc-devel (2.3.3-47 => 2.3.3-49) glibc-headers (2.3.3-47 => 2.3.3-49) gnumeric (1.2.13-1 => 1.2.13-2) gtk2 (2.4.9-5 => 2.4.9-6) gtk2-devel (2.4.9-5 => 2.4.9-6) hwdata (0.125-1 => 0.130-1) initscripts (7.77-1 => 7.78-2) iproute (2.6.9-1 => 2.6.9-2) kdebase (3.3.0-1 => 3.3.0-3) kdelibs (3.3.0-1 => 3.3.0-2) kudzu (1.1.85-1 => 1.1.88-1) kudzu-devel (1.1.85-1 => 1.1.88-1) libgnomecups (0.1.11-3 => 0.1.11-4) libgnomeprint22 (2.7.1-5 => 2.7.1-7) libgnomeprintui22 (2.7.1-5 => 2.7.1-7) libselinux (1.17.8-2 => 1.17.9-1) libselinux-devel (1.17.8-2 => 1.17.9-1) mkinitrd (4.1.9-1 => 4.1.10-1) mkisofs (2.01.0.a37.99-1 => 2.01.0.a38-2) net-snmp (5.1.2-1 => 5.1.2-4) net-tools (1.60-35 => 1.60-36) nscd (2.3.3-47 => 2.3.3-49) pango (1.5.2-2 => 1.5.2-3) pango-devel (1.5.2-2 => 1.5.2-3) passwd (0.68-9 => 0.68-10) popt (1.9.1-1 => 1.9.1-2) rpm (4.3.2-1 => 4.3.2-2) rpm-build (4.3.2-1 => 4.3.2-2) rpm-devel (4.3.2-1 => 4.3.2-2) rpm-python (4.3.2-1 => 4.3.2-2) selinux-policy-targeted (1.17.9-2 => 1.17.10-2) shared-mime-info (0.15-2 => 0.15-3) system-config-keyboard (1.2.1-2 => 1.2.2-1) system-config-kickstart (2.5.12-3 => 2.5.13-1) system-config-language (1.1.5-2 => 1.1.6-2) system-config-mouse (1.2.7-1 => 1.2.8-1) system-config-printer (0.6.111-1 => 0.6.112-1) system-config-printer-gui (0.6.111-1 => 0.6.112-1) system-config-rootpassword (1.1.3-2 => 1.1.5-1) system-config-securitylevel (1.4.2-2 => 1.4.3-1) system-config-securitylevel-tui (1.4.2-2 => 1.4.3-1) udev (030-20 => 030-23) umb-scheme (3.2-33 => 3.2-34) vim-X11 (6.3.020-1 => 6.3.025-2) vim-common (6.3.020-1 => 6.3.025-2) vim-enhanced (6.3.020-1 => 6.3.025-2) vim-minimal (6.3.020-1 => 6.3.025-2) xorg-x11 (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-Mesa-libGL (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-Mesa-libGLU (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-Xvfb (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-deprecated-libs (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-devel (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-font-utils (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-libs (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-tools (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-xauth (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-xdm (6.7.99.903-5 => 6.7.99.903-6) xorg-x11-xfs (6.7.99.903-5 => 6.7.99.903-6) The following NEW packages will be installed: rpm-libs (4.3.2-2) 75 upgraded, 1 newly installed, 0 removed and 0 not upgraded. Need to get 150MB of archives. After unpacking 21,7MB of additional disk space will be used. Do you want to continue? [Y/n] (of course locating an aptable rawhide mirror is not always easy) Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From buytenh at wantstofly.org Thu Sep 9 19:34:21 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 9 Sep 2004 21:34:21 +0200 Subject: RFC: cleaning up updates and updates-testing In-Reply-To: <20040909183417.GB15025@nostromo.devel.redhat.com> References: <20040909183417.GB15025@nostromo.devel.redhat.com> Message-ID: <20040909193421.GE27782@xi.wantstofly.org> On Thu, Sep 09, 2004 at 02:34:18PM -0400, Bill Nottingham wrote: > At the moment, the Fedora updates tree is somewhat out of > hand (look, wow - 27G). > > Does anyone have any specific and concrete objections to > removing older, superceded, updates? It was useful for me to be able to go back and fetch all the older kernel updates to see which one broke qemu. So I would say that it would be useful to have older updates available. They don't have to be in the same directory, of course. --L From dwalsh at redhat.com Thu Sep 9 20:19:04 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 09 Sep 2004 16:19:04 -0400 Subject: tmpfs /dev In-Reply-To: <200409100536.59711.russell@coker.com.au> References: <200409100536.59711.russell@coker.com.au> Message-ID: <4140BAB8.8070808@redhat.com> Russell Coker wrote: >I have got a working system with tmpfs /dev and with udev in the initrd. I >modified /sbin/init to run the following script immediately after loading the >policy: > >#!/bin/sh >. /etc/selinux/config >/sbin/setfiles-mine /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts /dev > >Naturally we need to change the location of setfiles to /sbin from /usr/sbin >if this is the solution we choose as this script will run before any file >systems are mounted. > >Below is the policy I added. I had already changed the type declarations to >use the dev_filesystem attribute for everything that may occur under /dev >(patch sent to the main SE Linux list). I have setfiles being run as >kernel_t because I feel that running setfiles as kernel_t is better than >granting setfiles_t more access than is otherwise required. This means that >I have to grant kernel_t access to relabel the device nodes, no big deal IMHO >as kernel_t generally has ultimate access anyway. > >I relabeled /sbin/MAKEDEV as udev_exec_t so that it runs as udev_t when run >from /sbin/start_udev and can do the things that it wants to do. This is a >minor hack. Maybe it would be better to label /sbin/start_udev as >udev_exec_t? That would remove the need to allow initrc_t to create >sym-links under /dev. > >avc: denied { getattr } for pid=1641 exe=/sbin/lvm.static >path=/sbin/MAKEDEV dev=dm-0 ino=196261 scontext=system_u:system_r:lvm_t >tcontext=system_u:object_r:udev_exec_t tclass=file > >Why does lvm.static want to stat /sbin/MAKEDEV? Seems strange to me. > >Below is the policy I wrote to allow tmpfs /dev and udev in initrd. I haven't >split it into all the relevant .te files because it's still an experiment at >this stage. After some discussion I'll produce a release version. > ># for tmpfs /dev >allow dev_filesystem tmpfs_t:filesystem associate; >allow kernel_t tmpfs_t:chr_file rw_file_perms; >allow kernel_t tmpfs_t:{ dir file lnk_file chr_file blk_file } { getattr >relabel >from }; >allow kernel_t device_t:{ dir lnk_file chr_file blk_file } relabelto; >allow kernel_t device_type:{ chr_file blk_file } relabelto; >allow kernel_t udev_tbl_t:file relabelto; >can_exec(kernel_t, { sbin_t setfiles_exec_t }) ># for /dev/pts on tmpfs >allow mount_t tmpfs_t:dir mounton; ># for /sbin/MAKEDEV - why? >allow lvm_t udev_exec_t:file getattr; ># allow /sbin/start_udev to run ln >allow initrc_t device_t:lnk_file create_lnk_perms; > > > You will need to talk to Bill Nottingham about modifying /sbin/init to do this. They are not crazy about putting additional code into /sbin/init since it is very hard to debug. They prefer rc.sysinit. They also do not want to relabel the /dev file system if it is not a tmpfs, since with 8000 or more files it could take a while and slow down the boot up. The modification that we are currently using only modifies rc.sysinit to do a restorecon on /dev/* when it is tmpfs and adds a couple of allows for hostname, init, mount and consoletype to use tmpfs_t. Dan From buildsys at redhat.com Thu Sep 9 20:24:33 2004 From: buildsys at redhat.com (Build System) Date: Thu, 9 Sep 2004 16:24:33 -0400 Subject: rawhide report: 20040909 changes Message-ID: <200409092024.i89KOXL01365@porkchop.devel.redhat.com> Updated Packages: From fedora at wir-sind-cool.org Thu Sep 9 21:06:00 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 9 Sep 2004 23:06:00 +0200 Subject: vsftpd (GPL) and openssl? In-Reply-To: <1094679796.2767.6.camel@roque> References: <413ED0A5.5050009@redhat.com> <1094635903.3042.5.camel@roque> <413ED2FA.8000409@redhat.com> <1094679796.2767.6.camel@roque> Message-ID: <20040909230600.73a006a3.fedora@wir-sind-cool.org> On Wed, 08 Sep 2004 22:43:16 +0100, Rui Miguel Seabra wrote: > On Tue, 2004-09-07 at 23:38 -1000, Warren Togami wrote: > > Rui Miguel Seabra wrote: > > > > > > I think the case is beggining to grow for inclusion of GNUtls. > > > > > > GNUtls has a library which is alledgedly API-compatible with openssl. > > > I have never tested. > > > > > > I'm willing to help with packaging it if no one is doing it right > > > already, which is better than not having some SSL implementation on GPL > > > packages. > > > > https://bugzilla.fedora.us/show_bug.cgi?id=1018 > > Looks like it needs someone to adopt it, cleanup and update. The deps > > might need updating too. > > I've got it fixed, plus a couple of packaging quircks. > > I also added a {?_with_opencdk} flag for future reference. Is it worthy? > At this moment it doesn't do anything useful, it's just ground work for > when I can package opencdk. Enrico Scholz has packaged opencdk for fedora.us before, it's in the "unstable" repository. -- Fedora Core release 2 (Tettnang) - Linux 2.6.7-1.494.2.2 loadavg: 0.28 0.34 0.66 From rms at 1407.org Thu Sep 9 22:18:09 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 09 Sep 2004 23:18:09 +0100 Subject: vsftpd (GPL) and openssl? In-Reply-To: <20040909230600.73a006a3.fedora@wir-sind-cool.org> References: <413ED0A5.5050009@redhat.com> <1094635903.3042.5.camel@roque> <413ED2FA.8000409@redhat.com> <1094679796.2767.6.camel@roque> <20040909230600.73a006a3.fedora@wir-sind-cool.org> Message-ID: <1094768289.2767.8.camel@roque> On Thu, 2004-09-09 at 23:06 +0200, Michael Schwendt wrote: > Enrico Scholz has packaged opencdk for fedora.us before, it's in the > "unstable" repository. Yes. But my first focus is on gnutls for the SSL part :) Hugs, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kyrre at solution-forge.net Thu Sep 9 19:28:00 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 09 Sep 2004 21:28:00 +0200 Subject: Plans to include tools to make FC3 more user-friendly in terms of RPM? Message-ID: <1094758080.2715.24.camel@kyrre> I'm just wondering: Why was the "rpm-dubbleclick-to-install" feature removed from FC2? It worked quite well in FC1 and RH9, and made installing RPM's much easyer for newbies. Will this tool (or something similar) be included into FC3, and if not, why? If there is anything i can do to help, please tell. I am also wondering if there is any plans to include a (one of the) grapichal frontends to yum. Kyrre Ness Sj?b?k From steve at silug.org Fri Sep 10 02:32:49 2004 From: steve at silug.org (Steven Pritchard) Date: Thu, 9 Sep 2004 21:32:49 -0500 Subject: RFC: cleaning up updates and updates-testing In-Reply-To: <20040909193421.GE27782@xi.wantstofly.org> References: <20040909183417.GB15025@nostromo.devel.redhat.com> <20040909193421.GE27782@xi.wantstofly.org> Message-ID: <20040910023249.GB3521@osiris.silug.org> On Thu, Sep 09, 2004 at 09:34:21PM +0200, Lennert Buytenhek wrote: > It was useful for me to be able to go back and fetch all the older > kernel updates to see which one broke qemu. > > So I would say that it would be useful to have older updates available. > They don't have to be in the same directory, of course. ISTR this comes up on mirror-list-d occasionally, and the preferred solution seems to be what you are suggesting. An obsolete-updates directory could be easily --exclude'd, and people who need to back out an update for whatever reason would still have the old updates available. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From katzj at redhat.com Fri Sep 10 02:42:24 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 09 Sep 2004 22:42:24 -0400 Subject: Plans to include tools to make FC3 more user-friendly in terms of RPM? In-Reply-To: <1094758080.2715.24.camel@kyrre> References: <1094758080.2715.24.camel@kyrre> Message-ID: <1094784144.4850.18.camel@bree.local.net> On Thu, 2004-09-09 at 21:28 +0200, Kyrre Ness Sjobak wrote: > I'm just wondering: Why was the "rpm-dubbleclick-to-install" feature > removed from FC2? It worked quite well in FC1 and RH9, and made > installing RPM's much easyer for newbies. Will this tool (or something > similar) be included into FC3, and if not, why? If there is anything i > can do to help, please tell. The GNOME mime stuff changed and broke things. It should come back in FC3 once someone tells me how it's supposed to work now ;) > I am also wondering if there is any plans to include a (one of the) > grapichal frontends to yum. There have been a few threads on this... realistically, the best option is getting the work done so that system-config-packages sits nicely on top of the new yum stuff. Not going to happen for FC3 at this point, though. Jeremy From cra at WPI.EDU Fri Sep 10 03:59:21 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 9 Sep 2004 23:59:21 -0400 Subject: RFC: cleaning up updates and updates-testing In-Reply-To: <20040910023249.GB3521@osiris.silug.org> References: <20040909183417.GB15025@nostromo.devel.redhat.com> <20040909193421.GE27782@xi.wantstofly.org> <20040910023249.GB3521@osiris.silug.org> Message-ID: <20040910035921.GA28619@angus.ind.WPI.EDU> On Thu, Sep 09, 2004 at 09:32:49PM -0500, Steven Pritchard wrote: > On Thu, Sep 09, 2004 at 09:34:21PM +0200, Lennert Buytenhek wrote: > > It was useful for me to be able to go back and fetch all the older > > kernel updates to see which one broke qemu. > > > > So I would say that it would be useful to have older updates available. > > They don't have to be in the same directory, of course. > > ISTR this comes up on mirror-list-d occasionally, and the preferred > solution seems to be what you are suggesting. > > An obsolete-updates directory could be easily --exclude'd, and people > who need to back out an update for whatever reason would still have > the old updates available. >From a mirroring perspective, it is much more efficient to have an all-updates directory containing all the real files, and a latest-updates directory containing only symlinks to the newest files in the other directory. That way rsync can sync the symlinks with --delete and you don't have to download the files again when they become obsolete and would otherwise be moved between directories. From yusufg at outblaze.com Fri Sep 10 04:23:27 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Fri, 10 Sep 2004 12:23:27 +0800 Subject: Will FC3 grub DTRT wrt installation on software RAID-1 boot arrays Message-ID: <20040910042327.GA13857@outblaze.com> Hi, I haven't tested FC3test as yet and wanted to ask if grub in FC3 would do the right thing when installing on a software raid-1 boot array (ie, that it would write to the MBR on both disks) so if there was a disk failure, the machine would still come up. Currently in FC1/FC2, if you install on software raid-1 array and then remove the first disk, the system won't boot up since there is no boot information on the MBR of the 2nd disk. lilo would do the right thing but since that's being deprecated. I don't know if Grub is capable of this task An engineer from Dell has provided a document which gives a workaround for this http://lists.us.dell.com/pipermail/linux-poweredge/2003-July/014331.html Regards, Yusuf From russell at coker.com.au Fri Sep 10 05:08:27 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 10 Sep 2004 15:08:27 +1000 Subject: tmpfs /dev In-Reply-To: <4140BAB8.8070808@redhat.com> References: <200409100536.59711.russell@coker.com.au> <4140BAB8.8070808@redhat.com> Message-ID: <200409101508.27612.russell@coker.com.au> On Fri, 10 Sep 2004 06:19, Daniel J Walsh wrote: > You will need to talk to Bill Nottingham about modifying /sbin/init to > do this. They are not crazy about > putting additional code into /sbin/init since it is very hard to debug. We've done it once, we can do it again. > They prefer rc.sysinit. They also do not rc.sysinit means changing the policy for init_t, initrc_t, and maybe others. > want to relabel the /dev file system if it is not a tmpfs, since with > 8000 or more files it could take a while and > slow down the boot up. On the slowest machine I have access to (a machine that can never run Fedora because it doesn't meet the hardware requirements) it takes 12 seconds to run setfiles on a fully loaded /dev. On machines that are a mere four years old it takes about 2 seconds, I doubt that you will be able to measure the difference that this makes on any hardware that can be purchased now. But writing some code to check for the file system type is not too difficult. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From aoliva at redhat.com Fri Sep 10 06:14:55 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Sep 2004 03:14:55 -0300 Subject: Will FC3 grub DTRT wrt installation on software RAID-1 boot arrays In-Reply-To: <20040910042327.GA13857@outblaze.com> References: <20040910042327.GA13857@outblaze.com> Message-ID: On Sep 10, 2004, Yusuf Goolamabbas wrote: > Hi, I haven't tested FC3test as yet and wanted to ask if grub in FC3 > would do the right thing when installing on a software raid-1 boot array > (ie, that it would write to the MBR on both disks) so if there was a > disk failure, the machine would still come up. The right thing depends on your BIOS and on the disk failure mode. Consider, for example, that you have two disks, 0x80 and 0x81. If you naively install boot information on both disks' boot records such that it looks for the boot partition in the disk itself, if you remove disk 0x80, disk 0x81 may not boot because it becomes 0x80. OTOH, if you replace disk 0x80, the BIOS will likely try to boot from it, and fail. If it fails over to the other disk, or if you change the BIOS settings so as to boot from this other disk, then it might be renumbered to 0x80, or it might not. You can't have it work both ways, unfortunately. Then consider more interesting scenarios like multiple disks and you may realize that, when lilo claims to be safe for raid 1, it's only for a some failure scenarios, and within certain BIOS behaviors. > I don't know if Grub is capable of this task It is, but you have to do it yourself, implying what kind of failure scenarios you're trying to prepare for. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From jspaleta at gmail.com Thu Sep 9 19:07:24 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 9 Sep 2004 15:07:24 -0400 Subject: First boot with 20040908 changes In-Reply-To: <1094754060.9937.14.camel@localhost.localdomain> References: <20040909130517.21053.qmail@web50602.mail.yahoo.com> <1094754060.9937.14.camel@localhost.localdomain> Message-ID: <604aa79104090912076944f759@mail.gmail.com> On Thu, 09 Sep 2004 20:21:00 +0200, David Zeuthen wrote: > I'm not sure I agree: if one cares about security one is using > filesystems with uid/gid attributes anyway. That said, however, it might > be useful to have a configuration file fstab-sync to explicitly specify > don't add this or that drive. And in the longterm finetune the mount > point names, e.g. using labels or whatnot. I think if someone wants to approach this from a locked down system point of view, you'd want to have a a policy of no devices allowed by default with specific devices allowed via administrative control. As compared to a policy of everything by default with a list of devices disallowed. Though of course both approaches will have their uses. I'm still poking at figuring out how to break hal in spectacular ways... but are the files in /usr/share/hal/fdi useful for creating locally defined policy of this sort? -jef From al at casa.org.ro Fri Sep 10 07:42:32 2004 From: al at casa.org.ro (Alin Osan) Date: Fri, 10 Sep 2004 10:42:32 +0300 Subject: yum and local cache Message-ID: <200409101042.32717.al@casa.org.ro> Hello, The latest version of yum doesn't seem to use the local cache. If for some reason, yum -y update has to be restarted (dependency problem, conflicts), it begins to download all the files from the top, including those were previously downloaded. Is this a bug or a feature? -- -- We are what we repeatedly do. Excellence, then, is not an act, but a habit. -- Alin Osan From skvidal at phy.duke.edu Fri Sep 10 07:57:21 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 10 Sep 2004 03:57:21 -0400 Subject: yum and local cache In-Reply-To: <200409101042.32717.al@casa.org.ro> References: <200409101042.32717.al@casa.org.ro> Message-ID: <1094803041.21859.22.camel@binkley> On Fri, 2004-09-10 at 10:42 +0300, Alin Osan wrote: > Hello, > > The latest version of yum doesn't seem to use the local cache. If for some > reason, yum -y update has to be restarted (dependency problem, conflicts), > it begins to download all the files from the top, including those were > previously downloaded. Is this a bug or a feature? 1. what version of yum 2. why do you say it's downloading things over and over again? -sv From al at casa.org.ro Fri Sep 10 08:09:07 2004 From: al at casa.org.ro (Alin Osan) Date: Fri, 10 Sep 2004 11:09:07 +0300 Subject: yum and local cache In-Reply-To: <1094803041.21859.22.camel@binkley> References: <200409101042.32717.al@casa.org.ro> <1094803041.21859.22.camel@binkley> Message-ID: <200409101109.07427.al@casa.org.ro> On Friday 10 September 2004 10:57, seth vidal wrote: > 1. what version of yum yum-2.1.3-1 > 2. why do you say it's downloading things over and over again? I say it because it happens. First time, it stopped with "Error: xorg-x11-font-utils conflicts: xorg-x11-base-fonts<= 6.7.99.903-3" and after I manually installed xorg-x11-font-utils yum -y update started to download all the files from the beginning. I noticed this on a PC at home, it was not a problem since bandwidth is plenty but I'm doing the same thing on a machine at work where I have 512 kbps. I don't want to think about dial-up users... -- -- We are what we repeatedly do. Excellence, then, is not an act, but a habit. -- Alin Osan From skvidal at phy.duke.edu Fri Sep 10 08:20:21 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 10 Sep 2004 04:20:21 -0400 Subject: yum and local cache In-Reply-To: <200409101109.07427.al@casa.org.ro> References: <200409101042.32717.al@casa.org.ro> <1094803041.21859.22.camel@binkley> <200409101109.07427.al@casa.org.ro> Message-ID: <1094804421.24485.1.camel@binkley> > > 2. why do you say it's downloading things over and over again? > > I say it because it happens. First time, it stopped with "Error: > xorg-x11-font-utils conflicts: xorg-x11-base-fonts<= 6.7.99.903-3" and > after I manually installed xorg-x11-font-utils yum -y update started to > download all the files from the beginning. I noticed this on a PC at home, > it was not a problem since bandwidth is plenty but I'm doing the same > thing on a machine at work where I have 512 kbps. I don't want to think > about dial-up users... > What files is it that you're seeing it redownload. A LOT of people have been confused by the ####### progess bar. that is ONLY Reading information in. it is NOT downloading ANYTHING the '====' progress bar is for downloads '####' - not downloading, just reading. -sv From kyrre at solution-forge.net Fri Sep 10 08:23:57 2004 From: kyrre at solution-forge.net (kyrre at solution-forge.net) Date: Fri, 10 Sep 2004 10:23:57 +0200 (CEST) Subject: Plans to include tools to make FC3 more user-friendly in termsof RPM? In-Reply-To: <1094784144.4850.18.camel@bree.local.net> References: <1094758080.2715.24.camel@kyrre> <1094784144.4850.18.camel@bree.local.net> Message-ID: <33076.81.191.130.121.1094804637.squirrel@solution-forge.net> > On Thu, 2004-09-09 at 21:28 +0200, Kyrre Ness Sjobak wrote: >> I'm just wondering: Why was the "rpm-dubbleclick-to-install" feature >> removed from FC2? It worked quite well in FC1 and RH9, and made >> installing RPM's much easyer for newbies. Will this tool (or something >> similar) be included into FC3, and if not, why? If there is anything i >> can do to help, please tell. > > The GNOME mime stuff changed and broke things. It should come back in > FC3 once someone tells me how it's supposed to work now ;) Hmm... it seems to bee there - but deactivated. I have just activated it (and activated the file-roller display, but not as default) - and it seems to work. I found instructions here: http://www.fedoraforum.org/forum/showpost.php?p=81008 > >> I am also wondering if there is any plans to include a (one of the) >> grapichal frontends to yum. > > There have been a few threads on this... realistically, the best option > is getting the work done so that system-config-packages sits nicely on > top of the new yum stuff. Not going to happen for FC3 at this point, > though. > > Jeremy > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From alan at redhat.com Fri Sep 10 08:45:11 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 10 Sep 2004 04:45:11 -0400 Subject: First boot with 20040908 changes In-Reply-To: <604aa79104090912076944f759@mail.gmail.com> References: <20040909130517.21053.qmail@web50602.mail.yahoo.com> <1094754060.9937.14.camel@localhost.localdomain> <604aa79104090912076944f759@mail.gmail.com> Message-ID: <20040910084511.GA10443@devserv.devel.redhat.com> On Thu, Sep 09, 2004 at 03:07:24PM -0400, Jeff Spaleta wrote: > I'm still poking at figuring out how to break hal in spectacular > ways... but are the files in > /usr/share/hal/fdi useful for creating locally defined policy of this sort? I would hope not because /usr can be shared. Local policy belongs in /etc 8) From al at casa.org.ro Fri Sep 10 08:44:59 2004 From: al at casa.org.ro (Alin Osan) Date: Fri, 10 Sep 2004 11:44:59 +0300 Subject: yum and local cache In-Reply-To: <1094804421.24485.1.camel@binkley> References: <200409101042.32717.al@casa.org.ro> <200409101109.07427.al@casa.org.ro> <1094804421.24485.1.camel@binkley> Message-ID: <200409101144.59851.al@casa.org.ro> On Friday 10 September 2004 11:20, seth vidal wrote: > > the '====' progress bar is for downloads I didn't know the difference before, but I've got '=========', I even checked with tcpdump, so it's definitely download. -- -- We are what we repeatedly do. Excellence, then, is not an act, but a habit. -- Alin Osan From ufo at linux.net.mk Tue Sep 7 12:57:15 2004 From: ufo at linux.net.mk (Arangel Angov) Date: Tue, 07 Sep 2004 14:57:15 +0200 Subject: FC3: Gnome 2.8 system tools Message-ID: <413DB02B.6060501@linux.net.mk> I think that this is the right place to disscuss this... While translating gnome 2.8 I noticed that gnome-system-tools is very similiar with all of the redhat sys-tools. How is this going to be resolved in FC3? Will there be no gnome-system-tools in the gnome edition that comes with FC3? Cause it wouldn't be nice if we have them both (personally, I wouldn't like the rh tools to go) and I just doubt that the fedora developers are going to get rid of the rh tools. Arangel From mr700 at globalnet.bg Fri Sep 10 09:24:54 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Fri, 10 Sep 2004 12:24:54 +0300 Subject: yum and local cache In-Reply-To: <200409101144.59851.al@casa.org.ro> References: <200409101042.32717.al@casa.org.ro> <1094804421.24485.1.camel@binkley> <200409101144.59851.al@casa.org.ro> Message-ID: <200409101224.54475@-mr700> On 2004 09 10 (Friday) 11:44, Alin Osan wrote: > On Friday 10 September 2004 11:20, seth vidal wrote: > > > > the '====' progress bar is for downloads > > I didn't know the difference before, but I've got '=========', I even > checked with tcpdump, so it's definitely download. > Same with lftp: Removing old file `RPMS/glib-1.2.10-15.i386.rpm' Transferring file `RPMS/glib-1.2.10-15.i386.rpm' Removing old file `RPMS/glib-devel-1.2.10-15.i386.rpm' Transferring file `RPMS/glib-devel-1.2.10-15.i386.rpm' ... Maybe they 'touch'-ed them all? -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 http://pgp.mit.edu Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From mr700 at globalnet.bg Fri Sep 10 09:21:25 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Fri, 10 Sep 2004 12:21:25 +0300 Subject: Will FC3 grub DTRT wrt installation on software RAID-1 boot arrays In-Reply-To: References: <20040910042327.GA13857@outblaze.com> Message-ID: <200409101221.25818@-mr700> On 2004 09 10 (Friday) 09:14, Alexandre Oliva wrote: > On Sep 10, 2004, Yusuf Goolamabbas wrote: > > > Hi, I haven't tested FC3test as yet and wanted to ask if grub in FC3 > > would do the right thing when installing on a software raid-1 boot array > > (ie, that it would write to the MBR on both disks) so if there was a > > disk failure, the machine would still come up. > > The right thing depends on your BIOS and on the disk failure mode. > > Consider, for example, that you have two disks, 0x80 and 0x81. If you > naively install boot information on both disks' boot records such that > it looks for the boot partition in the disk itself, if you remove disk > 0x80, disk 0x81 may not boot because it becomes 0x80. OTOH, if you > replace disk 0x80, the BIOS will likely try to boot from it, and > fail. If it fails over to the other disk, or if you change the BIOS > settings so as to boot from this other disk, then it might be > renumbered to 0x80, or it might not. You can't have it work both > ways, unfortunately. > > Then consider more interesting scenarios like multiple disks and you > may realize that, when lilo claims to be safe for raid 1, it's only > for a some failure scenarios, and within certain BIOS behaviors. > > > I don't know if Grub is capable of this task > > It is, but you have to do it yourself, implying what kind of failure > scenarios you're trying to prepare for. > I have a Pentium 4 3000E and EPox EP-4PCAI with three Seagate ST3160023A disks. I'm testing it with software raid1 and raid5 to see how it works. I use (waiting for additional IDE controller): --- cut --- # grub grub> root (hd0,0) grub> setup (hd0) grub> device (hd0) /dev/hdb grub> root (hd0,0) grub> setup (hd0) grub> device (hd0) /dev/hdc grub> root (hd0,0) grub> setup (hd0) --- cut --- When I remove any of the disks (or swap them randomly) it boots without problems (even changing hdc to hdd). My setup is: --- cut --- # cat /proc/mdstat Personalities : [raid1] [raid5] md1 : active raid5 hda2[0] hdb2[1] hdc2[2] 312046080 blocks level 5, 256k chunk, algorithm 2 [3/3] [UUU] md0 : active raid1 hda1[0] hdb1[1] hdc1[2] 264960 blocks [3/3] [UUU] -- cut --- md0 is /boot and everything else is on md1 (LVM). I don't know if BIOS moves the first available disk to 0x80, but GRUB loads from any disk (even if I connect hdc only). I'll try this with more machines when I have time to. -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 http://pgp.mit.edu Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From david at fubar.dk Fri Sep 10 10:32:03 2004 From: david at fubar.dk (David Zeuthen) Date: Fri, 10 Sep 2004 12:32:03 +0200 Subject: First boot with 20040908 changes In-Reply-To: <604aa79104090912076944f759@mail.gmail.com> References: <20040909130517.21053.qmail@web50602.mail.yahoo.com> <1094754060.9937.14.camel@localhost.localdomain> <604aa79104090912076944f759@mail.gmail.com> Message-ID: <1094812323.4481.5.camel@localhost.localdomain> On Thu, 2004-09-09 at 15:07 -0400, Jeff Spaleta wrote: > On Thu, 09 Sep 2004 20:21:00 +0200, David Zeuthen wrote: > > I'm not sure I agree: if one cares about security one is using > > filesystems with uid/gid attributes anyway. That said, however, it might > > be useful to have a configuration file fstab-sync to explicitly specify > > don't add this or that drive. And in the longterm finetune the mount > > point names, e.g. using labels or whatnot. > > I think if someone wants to approach this from a locked down system > point of view, > you'd want to have a a policy of no devices allowed by default with > specific devices allowed via administrative control. As compared to a > policy of everything by default with a list of devices disallowed. > Though of course both approaches will have their uses. > Yeah, I'm thinking /etc/fstab-sync.conf would do this - still have to write the code but it shouldn't be too hard. I'm not sure what the default policy should be though - most people are happy about not having to go to the commandline to get access to their partitions and some people have more or less valid security concerns. My take is that the latter group is more capable of going and editing /etc/fstab-sync.conf that the former. But that is just my personal opinion. > I'm still poking at figuring out how to break hal in spectacular > ways... but are the files in > /usr/share/hal/fdi useful for creating locally defined policy of this sort? > Those files, hal device information files, or .fdi files, are meant to contain *facts* about certain devices, e.g. this device that looks like a mass storage device to the kernel is in fact really a mp3 player/ camera/whatever. So, yes Alan, they are really suitable to be shared between archs and used site-wide etc. David From rdieter at math.unl.edu Fri Sep 10 12:08:46 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 10 Sep 2004 07:08:46 -0500 (CDT) Subject: FC3: Gnome 2.8 system tools In-Reply-To: <413DB02B.6060501@linux.net.mk> References: <413DB02B.6060501@linux.net.mk> Message-ID: On Tue, 7 Sep 2004, Arangel Angov wrote: > I think that this is the right place to disscuss this... > > While translating gnome 2.8 I noticed that gnome-system-tools is very > similiar with all of the redhat sys-tools. How is this going to be resolved > in FC3? Will there be no gnome-system-tools in the gnome edition that comes > with FC3? I'd assume that gnome-system-tools would be omitted, as the usual policy is to omit tools that provide similar functionality to system-* tools. -- Rex From buildsys at redhat.com Fri Sep 10 12:25:09 2004 From: buildsys at redhat.com (Build System) Date: Fri, 10 Sep 2004 08:25:09 -0400 Subject: rawhide report: 20040910 changes Message-ID: <200409101225.i8ACP9A31090@porkchop.devel.redhat.com> Updated Packages: anaconda-10.0.2-3 ----------------- * Thu Sep 09 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode kudzu-1.1.89-1 -------------- * Thu Sep 09 2004 Bill Nottingham - 1.1.89-1 - fix searching when it returns descriptionless keys rpmdb-fedora-2.91-0.20040910 ---------------------------- From linux_4ever at yahoo.com Fri Sep 10 12:40:46 2004 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 10 Sep 2004 05:40:46 -0700 (PDT) Subject: First boot with 20040908 changes In-Reply-To: <1094812323.4481.5.camel@localhost.localdomain> Message-ID: <20040910124046.12865.qmail@web50610.mail.yahoo.com> >I'm not sure what the default policy should be though - most people are >happy about not having to go to the commandline to get access to their >partitions and some people have more or less valid security concerns. OK, I've had some time to think this over. Traditionally, the default is on the open - all inclusive side of things unless there is the possibility of damage. e.g., tcp_wrapper defaults to open, iptable defaults to open. You must intervene to secure the system. As long as the drives are only detected and mount points made, it don't have a problem. If the drives are *mounted*, I have a real problem. By mounting the drive, you may suddenly cause a drive to get fsck'ed by a newer program that oopses older kernels, or relabeled by SE Linux which will oops older kernels. No mounting! Even thought I have hand edited my fstab and hal made mount points, it appears not to have mounted the drives. Based on a suggestion from Jeff yesterday, I went and tuned my /etc/hal/hald.conf file for false, false, false. On next boot, the mount points disappeared. Then I re-installed hal. My config file was renamed hald.cond.rpmorig. :( There needs to be a %config(noreplace) for hald.conf in the spec file. Also, on first boot, hal ignores my wishes and puts the mount points there. I haven't tried a reboot yet to see if on second boot they go away. Not sure yet if this is a regression from yesterdays updates or just a first boot behavior. Next question, is there supposed to be a /media/cdrom mount point? or is it still /dev/cdrom? Or both? >Those files, hal device information files, or .fdi files, are meant to >contain *facts* about certain devices, e.g. this device that looks like >a mass storage device to the kernel is in fact really a mp3 player/ >camera/whatever. I am wondering about people that have /usr as nfs? I think that's why things that have a bearing on config keep a copy in /etc. For example, timezone data. The master copy is under /usr somewhere, but its copied to /etc. -Steve Grubb _______________________________ Do you Yahoo!? Shop for Back-to-School deals on Yahoo! Shopping. http://shopping.yahoo.com/backtoschool From skvidal at phy.duke.edu Fri Sep 10 12:55:23 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 10 Sep 2004 08:55:23 -0400 Subject: yum and local cache In-Reply-To: <200409101144.59851.al@casa.org.ro> References: <200409101042.32717.al@casa.org.ro> <200409101109.07427.al@casa.org.ro> <1094804421.24485.1.camel@binkley> <200409101144.59851.al@casa.org.ro> Message-ID: <1094820923.24520.2.camel@binkley> On Fri, 2004-09-10 at 11:44 +0300, Alin Osan wrote: > On Friday 10 September 2004 11:20, seth vidal wrote: > > > > the '====' progress bar is for downloads > > I didn't know the difference before, but I've got '=========', I even > checked with tcpdump, so it's definitely download. the only download that happens every time is the repomd.xml file. that's a <1000byte file. -sv From al at casa.org.ro Fri Sep 10 13:06:22 2004 From: al at casa.org.ro (Alin Osan) Date: Fri, 10 Sep 2004 16:06:22 +0300 Subject: yum and local cache In-Reply-To: <1094820923.24520.2.camel@binkley> References: <200409101042.32717.al@casa.org.ro> <200409101144.59851.al@casa.org.ro> <1094820923.24520.2.camel@binkley> Message-ID: <200409101606.23068.al@casa.org.ro> On Friday 10 September 2004 15:55, seth vidal wrote: > the only download that happens every time is the repomd.xml file. > > that's a <1000byte file. No, it's not. Believe me, I know what I'm talking about. How else can I prove it? -- -- We are what we repeatedly do. Excellence, then, is not an act, but a habit. -- Alin Osan From skvidal at phy.duke.edu Fri Sep 10 13:08:12 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 10 Sep 2004 09:08:12 -0400 Subject: yum and local cache In-Reply-To: <200409101606.23068.al@casa.org.ro> References: <200409101042.32717.al@casa.org.ro> <200409101144.59851.al@casa.org.ro> <1094820923.24520.2.camel@binkley> <200409101606.23068.al@casa.org.ro> Message-ID: <1094821692.24520.4.camel@binkley> On Fri, 2004-09-10 at 16:06 +0300, Alin Osan wrote: > On Friday 10 September 2004 15:55, seth vidal wrote: > > > > the only download that happens every time is the repomd.xml file. > > > > that's a <1000byte file. > > No, it's not. Believe me, I know what I'm talking about. How else can I > prove it? > file a bug and post the output you're seeing in multiple runs. -sv From jspaleta at gmail.com Fri Sep 10 13:14:57 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Sep 2004 09:14:57 -0400 Subject: yum and local cache In-Reply-To: <1094820923.24520.2.camel@binkley> References: <200409101042.32717.al@casa.org.ro> <200409101109.07427.al@casa.org.ro> <1094804421.24485.1.camel@binkley> <200409101144.59851.al@casa.org.ro> <1094820923.24520.2.camel@binkley> Message-ID: <604aa791040910061473cdbed0@mail.gmail.com> On Fri, 10 Sep 2004 08:55:23 -0400, seth vidal wrote: > On Fri, 2004-09-10 at 11:44 +0300, Alin Osan wrote: > > On Friday 10 September 2004 11:20, seth vidal wrote: > > > > > > the '====' progress bar is for downloads > > > > I didn't know the difference before, but I've got '=========', I even > > checked with tcpdump, so it's definitely download. > > the only download that happens every time is the repomd.xml file. > > that's a <1000byte file. As a comparison... i did a full update to rawhide last night...and i just reverted to an older s-c-printer package and used yum to install the newer again. I know the packages and headers for s-c-printer are cached via visual inspection of the cache directories. /var/cache/yum/development/packages/system-config-printer-0.6.112-1.i386.rpm /var/cache/yum/development/headers/system-config-printer-0.6.112-1.i386.hdr yum did not redownload the s-c-printer header nor the s-c-printer package, so from where I'm sitting, things look like they are working correctly from the cache to me. -jef"is thinking the rawhide yum should default to -d6 just to save time asking for people to run d5 or d6"spaleta From ottohaliburton at comcast.net Fri Sep 10 14:09:03 2004 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Fri, 10 Sep 2004 09:09:03 -0500 Subject: yum and local cache In-Reply-To: <604aa791040910061473cdbed0@mail.gmail.com> Message-ID: <007101c4973f$ba68a310$4801a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Jeff Spaleta > Sent: Friday, September 10, 2004 8:15 AM > To: Development discussions related to Fedora Core > Subject: Re: yum and local cache > > On Fri, 10 Sep 2004 08:55:23 -0400, seth vidal > wrote: > > On Fri, 2004-09-10 at 11:44 +0300, Alin Osan wrote: > > > On Friday 10 September 2004 11:20, seth vidal wrote: > > > > > > > > the '====' progress bar is for downloads > > > > > > I didn't know the difference before, but I've got '=========', I even > > > checked with tcpdump, so it's definitely download. > > > > the only download that happens every time is the repomd.xml file. > > > > that's a <1000byte file. > > As a comparison... i did a full update to rawhide last night...and i > just reverted to an older > s-c-printer package and used yum to install the newer again. I know > the packages and headers for s-c-printer are cached via visual > inspection of the cache directories. > /var/cache/yum/development/packages/system-config-printer-0.6.112- > 1.i386.rpm > /var/cache/yum/development/headers/system-config-printer-0.6.112- > 1.i386.hdr > > yum did not redownload the s-c-printer header nor the s-c-printer > package, so from where I'm sitting, things look like they are working > correctly from the cache to me. > > -jef"is thinking the rawhide yum should default to -d6 just to save > time asking for people to run d5 or d6"spaleta > > > -- FYI, I had a problem similar to the description here but I didn't investigate further. There is something wrong with the new yum, but I can't be sure what it is. I do know that it failed at a particular repository that it work for before. From skvidal at phy.duke.edu Fri Sep 10 14:24:35 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 10 Sep 2004 10:24:35 -0400 Subject: yum and local cache In-Reply-To: <007101c4973f$ba68a310$4801a8c0@C515816A> References: <007101c4973f$ba68a310$4801a8c0@C515816A> Message-ID: <1094826275.26144.3.camel@opus.phy.duke.edu> > FYI, I had a problem similar to the description here but I didn't > investigate further. There is something wrong with the new yum, but I can't > be sure what it is. I do know that it failed at a particular repository > that it work for before. 'something wrong' That's not terribly helpful for bugfixing. -sv From ottohaliburton at comcast.net Fri Sep 10 14:46:50 2004 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Fri, 10 Sep 2004 09:46:50 -0500 Subject: yum and local cache In-Reply-To: <1094826275.26144.3.camel@opus.phy.duke.edu> Message-ID: <007301c49745$01a25550$4801a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of seth vidal > Sent: Friday, September 10, 2004 9:25 AM > To: Development discussions related to Fedora Core > Subject: RE: yum and local cache > > > FYI, I had a problem similar to the description here but I didn't > > investigate further. There is something wrong with the new yum, but I > can't > > be sure what it is. I do know that it failed at a particular repository > > that it work for before. > > 'something wrong' > > That's not terribly helpful for bugfixing. > > -sv > > > > -- and actually it is. It says that if yours is working properly and mine and the others is not working properly, then something is happening in the installation of the new yum that is causing a problem or in my case some of the repositories have something different that is causing a problem. My failed on the livna(sp) repository. From skvidal at phy.duke.edu Fri Sep 10 14:50:48 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 10 Sep 2004 10:50:48 -0400 Subject: yum and local cache In-Reply-To: <007301c49745$01a25550$4801a8c0@C515816A> References: <007301c49745$01a25550$4801a8c0@C515816A> Message-ID: <1094827848.26144.9.camel@opus.phy.duke.edu> > and actually it is. It says that if yours is working properly and mine and > the others is not working properly, then something is happening in the > installation of the new yum that is causing a problem or in my case some of > the repositories have something different that is causing a problem. My > failed on the livna(sp) repository. So, as the guy who wrote yum I can say w/almost complete certainty yum does not fail quietly. if something 'failed' there was an error message. if there was an error message and it is not explained by the content of the error message or the situation then it should probably be filed as a bug. -sv From david at fubar.dk Fri Sep 10 14:51:58 2004 From: david at fubar.dk (David Zeuthen) Date: Fri, 10 Sep 2004 16:51:58 +0200 Subject: First boot with 20040908 changes In-Reply-To: <20040910124046.12865.qmail@web50610.mail.yahoo.com> References: <20040910124046.12865.qmail@web50610.mail.yahoo.com> Message-ID: <1094827918.7068.27.camel@localhost.localdomain> On Fri, 2004-09-10 at 05:40 -0700, Steve G wrote: > >I'm not sure what the default policy should be though - most people are > >happy about not having to go to the commandline to get access to their > >partitions and some people have more or less valid security concerns. > > OK, I've had some time to think this over. Traditionally, the default is on the > open - all inclusive side of things unless there is the possibility of damage. > e.g., tcp_wrapper defaults to open, iptable defaults to open. You must intervene > to secure the system. > > As long as the drives are only detected and mount points made, it don't have a > problem. If the drives are *mounted*, I have a real problem. By mounting the > drive, you may suddenly cause a drive to get fsck'ed by a newer program that > oopses older kernels, or relabeled by SE Linux which will oops older kernels. > > No mounting! > > Even thought I have hand edited my fstab and hal made mount points, it appears > not to have mounted the drives. > Sure, hal doesn't mount drives. However, when you log in to GNOME then gnome-volume-manager, in the default configuration, mounts all the drives as the user who is logging in. And unmounts them at logout. I think this is sane given the options put in /etc/fstab. An example from my fstab /dev/sda1 /media/compact_flash vfat noauto,user,exec,kudzu,noatime,sync 0 0 and it's mounted as /dev/sda1 /media/compact_flash vfat rw,sync,noatime,nodiratime,nosuid,nodev,uid=500,gid=500,fmask=0022,dmask=0022 0 0 Note the nosuid,nodev options thanks to having user in the fstab line. So, I hope we can agree this is pretty safe? > Based on a suggestion from Jeff yesterday, I went and tuned my /etc/hal/hald.conf > file for false, false, false. That is bad advice; I'm not sure how well turning off media detection works presently (I test it once in a while though) and I think g-v-m ignores the automount hint. When Nautilus and GNOME VFS is ready, this will be supported as well [1]. [1] : GNOME VFS presently relies on the fstab, but there is no fstab entry if there is no media in card and there wont be if media detection is disabled :-) > On next boot, the mount points disappeared. Then I > re-installed hal. My config file was renamed hald.cond.rpmorig. :( There needs > to be a %config(noreplace) for hald.conf in the spec file. Sounds like a bug that is easy to fix. I'll do that, thanks for pointing it out. > Also, on first boot, hal ignores my wishes and puts the mount points there. I > haven't tried a reboot yet to see if on second boot they go away. Not sure yet if > this is a regression from yesterdays updates or just a first boot behavior. > Disabling media detection in /etc/hal/hald.conf only means we won't poll for media if we otherwise would do that. So of course hal initially detects your devices and create mount points. > Next question, is there supposed to be a /media/cdrom mount point? or is it still > /dev/cdrom? Or both? There is supposed to be a /media/cdrom mount point if you got a CD-ROM only drive; if it's a DVD-ROM it will be /media/dvdrom, if it's a CD- RW/DVD-RW it will be /media/cdrw_dvdrw and so on. It will probably reference the non-symlinked device e.g. /dev/hdc, /dev/hdd, /dev/sr0 or whatever. With the latest udev, however, there will be compatibility symlinks /dev/cdrom, /dev/cdrom1, ... that points to the real device file e.g. /dev/hdc. hal doesn't really care about these symlinks. David From rstrode at redhat.com Fri Sep 10 14:51:57 2004 From: rstrode at redhat.com (Ray Strode) Date: Fri, 10 Sep 2004 10:51:57 -0400 Subject: Plans to include tools to make FC3 more user-friendly in terms of RPM? In-Reply-To: <1094784144.4850.18.camel@bree.local.net> References: <1094758080.2715.24.camel@kyrre> <1094784144.4850.18.camel@bree.local.net> Message-ID: <1094827918.3908.1.camel@localhost.localdomain> Hi, > On Thu, 2004-09-09 at 21:28 +0200, Kyrre Ness Sjobak wrote: > > I'm just wondering: Why was the "rpm-dubbleclick-to-install" feature > > removed from FC2? It worked quite well in FC1 and RH9, and made > > installing RPM's much easyer for newbies. Will this tool (or something > > similar) be included into FC3, and if not, why? If there is anything i > > can do to help, please tell. > > The GNOME mime stuff changed and broke things. It should come back in > FC3 once someone tells me how it's supposed to work now ;) There seems to be some confusion about this in general, so I've put up a page with a little information on the new MIME system for packagers here: http://fedora.linux.duke.edu/wiki/NewMIMESystem --Ray Strode From david at fubar.dk Fri Sep 10 14:51:58 2004 From: david at fubar.dk (David Zeuthen) Date: Fri, 10 Sep 2004 16:51:58 +0200 Subject: First boot with 20040908 changes In-Reply-To: <20040910124046.12865.qmail@web50610.mail.yahoo.com> References: <20040910124046.12865.qmail@web50610.mail.yahoo.com> Message-ID: <1094827918.7068.27.camel@localhost.localdomain> On Fri, 2004-09-10 at 05:40 -0700, Steve G wrote: > >I'm not sure what the default policy should be though - most people are > >happy about not having to go to the commandline to get access to their > >partitions and some people have more or less valid security concerns. > > OK, I've had some time to think this over. Traditionally, the default is on the > open - all inclusive side of things unless there is the possibility of damage. > e.g., tcp_wrapper defaults to open, iptable defaults to open. You must intervene > to secure the system. > > As long as the drives are only detected and mount points made, it don't have a > problem. If the drives are *mounted*, I have a real problem. By mounting the > drive, you may suddenly cause a drive to get fsck'ed by a newer program that > oopses older kernels, or relabeled by SE Linux which will oops older kernels. > > No mounting! > > Even thought I have hand edited my fstab and hal made mount points, it appears > not to have mounted the drives. > Sure, hal doesn't mount drives. However, when you log in to GNOME then gnome-volume-manager, in the default configuration, mounts all the drives as the user who is logging in. And unmounts them at logout. I think this is sane given the options put in /etc/fstab. An example from my fstab /dev/sda1 /media/compact_flash vfat noauto,user,exec,kudzu,noatime,sync 0 0 and it's mounted as /dev/sda1 /media/compact_flash vfat rw,sync,noatime,nodiratime,nosuid,nodev,uid=500,gid=500,fmask=0022,dmask=0022 0 0 Note the nosuid,nodev options thanks to having user in the fstab line. So, I hope we can agree this is pretty safe? > Based on a suggestion from Jeff yesterday, I went and tuned my /etc/hal/hald.conf > file for false, false, false. That is bad advice; I'm not sure how well turning off media detection works presently (I test it once in a while though) and I think g-v-m ignores the automount hint. When Nautilus and GNOME VFS is ready, this will be supported as well [1]. [1] : GNOME VFS presently relies on the fstab, but there is no fstab entry if there is no media in card and there wont be if media detection is disabled :-) > On next boot, the mount points disappeared. Then I > re-installed hal. My config file was renamed hald.cond.rpmorig. :( There needs > to be a %config(noreplace) for hald.conf in the spec file. Sounds like a bug that is easy to fix. I'll do that, thanks for pointing it out. > Also, on first boot, hal ignores my wishes and puts the mount points there. I > haven't tried a reboot yet to see if on second boot they go away. Not sure yet if > this is a regression from yesterdays updates or just a first boot behavior. > Disabling media detection in /etc/hal/hald.conf only means we won't poll for media if we otherwise would do that. So of course hal initially detects your devices and create mount points. > Next question, is there supposed to be a /media/cdrom mount point? or is it still > /dev/cdrom? Or both? There is supposed to be a /media/cdrom mount point if you got a CD-ROM only drive; if it's a DVD-ROM it will be /media/dvdrom, if it's a CD- RW/DVD-RW it will be /media/cdrw_dvdrw and so on. It will probably reference the non-symlinked device e.g. /dev/hdc, /dev/hdd, /dev/sr0 or whatever. With the latest udev, however, there will be compatibility symlinks /dev/cdrom, /dev/cdrom1, ... that points to the real device file e.g. /dev/hdc. hal doesn't really care about these symlinks. David From tjb at unh.edu Fri Sep 10 14:54:52 2004 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 10 Sep 2004 10:54:52 -0400 Subject: yum and local cache In-Reply-To: <007301c49745$01a25550$4801a8c0@C515816A> References: <007301c49745$01a25550$4801a8c0@C515816A> Message-ID: <1094828092.25787.26.camel@wintermute.sr.unh.edu> On Fri, 2004-09-10 at 09:46 -0500, Otto Haliburton wrote: > > > -----Original Message----- > > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > > bounces at redhat.com] On Behalf Of seth vidal > > Sent: Friday, September 10, 2004 9:25 AM > > To: Development discussions related to Fedora Core > > Subject: RE: yum and local cache > > > > > FYI, I had a problem similar to the description here but I didn't > > > investigate further. There is something wrong with the new yum, but I > > can't > > > be sure what it is. I do know that it failed at a particular repository > > > that it work for before. > > > > 'something wrong' > > > > That's not terribly helpful for bugfixing. > > > > -sv > > > > > > > > -- > and actually it is. It says that if yours is working properly and mine and > the others is not working properly, then something is happening in the > installation of the new yum that is causing a problem or in my case some of > the repositories have something different that is causing a problem. My > failed on the livna(sp) repository. > > > livna works fine. the urls have changed which could be causing your problems: [livna-stable] name=Livna.org for FC$releasever ($basearch) (stable) baseurl= http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.stable gpgcheck=1 [livna-unstable] name=Livna.org for FC$releasever ($basearch) (unstable) baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.unstable gpgcheck=1 [livna-testing] name=Livna.org for FC$releasever ($basearch) (testing) baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.testing gpgcheck=1 All anyone is saying is that you've got to provide more info than 'it doesn't work'. tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From ottohaliburton at comcast.net Fri Sep 10 14:55:22 2004 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Fri, 10 Sep 2004 09:55:22 -0500 Subject: yum and local cache In-Reply-To: <1094827848.26144.9.camel@opus.phy.duke.edu> Message-ID: <007401c49746$3325d9c0$4801a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of seth vidal > Sent: Friday, September 10, 2004 9:51 AM > To: Development discussions related to Fedora Core > Subject: RE: yum and local cache > > > and actually it is. It says that if yours is working properly and mine > and > > the others is not working properly, then something is happening in the > > installation of the new yum that is causing a problem or in my case some > of > > the repositories have something different that is causing a problem. My > > failed on the livna(sp) repository. > > So, as the guy who wrote yum I can say w/almost complete certainty yum > does not fail quietly. > > if something 'failed' there was an error message. > > if there was an error message and it is not explained by the content of > the error message or the situation then it should probably be filed as a > bug. > > -sv > > > > > It didn't fail quietly, It failed as has been described in this thread, I just didn't want to continue repeating the same error message. The description of the problem is valid. From ottohaliburton at comcast.net Fri Sep 10 14:41:29 2004 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Fri, 10 Sep 2004 09:41:29 -0500 Subject: yum and local cache In-Reply-To: <1094826275.26144.3.camel@opus.phy.duke.edu> Message-ID: <007201c49744$457125f0$4801a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of seth vidal > Sent: Friday, September 10, 2004 9:25 AM > To: Development discussions related to Fedora Core > Subject: RE: yum and local cache > > > FYI, I had a problem similar to the description here but I didn't > > investigate further. There is something wrong with the new yum, but I > can't > > be sure what it is. I do know that it failed at a particular repository > > that it work for before. > > 'something wrong' > > That's not terribly helpful for bugfixing. > > -sv > > > > -- I agree, I was merely confirming the problem. There appears to be an effort to say that it is working and it is not. I didn't do the necessary footwork to describe it because I used another method. Also 'yum upgrade' is no longer an option, which is fine. From ottohaliburton at comcast.net Fri Sep 10 15:01:04 2004 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Fri, 10 Sep 2004 10:01:04 -0500 Subject: yum and local cache In-Reply-To: <1094828092.25787.26.camel@wintermute.sr.unh.edu> Message-ID: <007501c49747$01ca3dc0$4801a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Thomas J. Baker > Sent: Friday, September 10, 2004 9:55 AM > To: Development discussions related to Fedora Core > Subject: RE: yum and local cache > > On Fri, 2004-09-10 at 09:46 -0500, Otto Haliburton wrote: > > > > > -----Original Message----- > > > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > > > bounces at redhat.com] On Behalf Of seth vidal > > > Sent: Friday, September 10, 2004 9:25 AM > > > To: Development discussions related to Fedora Core > > > Subject: RE: yum and local cache > > > > > > > FYI, I had a problem similar to the description here but I didn't > > > > investigate further. There is something wrong with the new yum, but > I > > > can't > > > > be sure what it is. I do know that it failed at a particular > repository > > > > that it work for before. > > > > > > 'something wrong' > > > > > > That's not terribly helpful for bugfixing. > > > > > > -sv > > > > > > > > > > > > -- > > and actually it is. It says that if yours is working properly and mine > and > > the others is not working properly, then something is happening in the > > installation of the new yum that is causing a problem or in my case some > of > > the repositories have something different that is causing a problem. My > > failed on the livna(sp) repository. > > > > > > > > livna works fine. the urls have changed which could be causing your > problems: > > [livna-stable] > name=Livna.org for FC$releasever ($basearch) (stable) > baseurl= http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.stable > gpgcheck=1 > > [livna-unstable] > name=Livna.org for FC$releasever ($basearch) (unstable) > baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.unstable > gpgcheck=1 > > [livna-testing] > name=Livna.org for FC$releasever ($basearch) (testing) > baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.testing > gpgcheck=1 > > > All anyone is saying is that you've got to provide more info than 'it > doesn't work'. > > tjb > -- > ======================================================================= > | Thomas Baker email: tjb at unh.edu | > | Systems Programmer | > | Research Computing Center voice: (603) 862-4490 | > | University of New Hampshire fax: (603) 862-1761 | > | 332 Morse Hall | > | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | > ======================================================================= > > Look I was just confirming the problem, I had used the yum 2.0... and everything work, immediately after manually installing the new yum if failed on the livna repository and didn't proceed past that point. I wasn't complaining just confirming. I can wait until it is fixed it is no BFD. From skvidal at phy.duke.edu Fri Sep 10 15:02:40 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 10 Sep 2004 11:02:40 -0400 Subject: yum and local cache In-Reply-To: <007201c49744$457125f0$4801a8c0@C515816A> References: <007201c49744$457125f0$4801a8c0@C515816A> Message-ID: <1094828560.26144.13.camel@opus.phy.duke.edu> > I agree, I was merely confirming the problem. There appears to be an effort > to say that it is working and it is not. I didn't do the necessary footwork > to describe it because I used another method. Also 'yum upgrade' is no > longer an option, which is fine. No, The effort is to say that if it is not working then I need more information. -sv From bpm at ec-group.com Fri Sep 10 15:01:17 2004 From: bpm at ec-group.com (Brian Millett) Date: Fri, 10 Sep 2004 10:01:17 -0500 (CDT) Subject: yum and local cache In-Reply-To: <007301c49745$01a25550$4801a8c0@C515816A> References: <1094826275.26144.3.camel@opus.phy.duke.edu> <007301c49745$01a25550$4801a8c0@C515816A> Message-ID: <50982.12.41.112.51.1094828477.squirrel@webmail.ec-group.com> > > >> -----Original Message----- >> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- >> bounces at redhat.com] On Behalf Of seth vidal >> Sent: Friday, September 10, 2004 9:25 AM >> To: Development discussions related to Fedora Core >> Subject: RE: yum and local cache >> >> > FYI, I had a problem similar to the description here but I didn't >> investigate further. There is something wrong with the new yum, but >> I >> can't >> > be sure what it is. I do know that it failed at a particular >> repository that it work for before. >> >> 'something wrong' >> >> That's not terribly helpful for bugfixing. >> >> -sv >> >> >> >> -- > and actually it is. It says that if yours is working properly and mine > and the others is not working properly, then something is happening in > the installation of the new yum that is causing a problem or in my case > some of the repositories have something different that is causing a > problem. My failed on the livna(sp) repository. > Yep, this bit me also. What happened is that the location of the repo changed. Below is how I have it now. [livna-stable] name=Livna.org Fedora Compatible Packages (stable) #baseurl= http://rpm.livna.org/fedora/2/$basearch/yum/stable baseurl= http://rpm.livna.org/fedora/2/$basearch/RPMS.stable gpgcheck=1 -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From tjb at unh.edu Fri Sep 10 15:06:00 2004 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 10 Sep 2004 11:06:00 -0400 Subject: yum and local cache In-Reply-To: <007501c49747$01ca3dc0$4801a8c0@C515816A> References: <007501c49747$01ca3dc0$4801a8c0@C515816A> Message-ID: <1094828760.25787.31.camel@wintermute.sr.unh.edu> On Fri, 2004-09-10 at 10:01 -0500, Otto Haliburton wrote: > > livna works fine. the urls have changed which could be causing your > > problems: > > > > [livna-stable] > > name=Livna.org for FC$releasever ($basearch) (stable) > > baseurl= http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.stable > > gpgcheck=1 > > > > [livna-unstable] > > name=Livna.org for FC$releasever ($basearch) (unstable) > > baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.unstable > > gpgcheck=1 > > > > [livna-testing] > > name=Livna.org for FC$releasever ($basearch) (testing) > > baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.testing > > gpgcheck=1 > > > > > > > Look I was just confirming the problem, I had used the yum 2.0... and > everything work, immediately after manually installing the new yum if failed > on the livna repository and didn't proceed past that point. I wasn't > complaining just confirming. I can wait until it is fixed it is no BFD. I had the same problem. It seems that livna changed the URLs at the same time they started making yum 2.1 compatible repodata. So unless you fix your yum.conf, it's not going to get fixed. tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From walters at redhat.com Fri Sep 10 15:09:08 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 10 Sep 2004 11:09:08 -0400 Subject: First boot with 20040908 changes In-Reply-To: <20040910124046.12865.qmail@web50610.mail.yahoo.com> References: <20040910124046.12865.qmail@web50610.mail.yahoo.com> Message-ID: <1094828948.7061.22.camel@nexus.verbum.private> On Fri, 2004-09-10 at 05:40 -0700, Steve G wrote: > >I'm not sure what the default policy should be though - most people are > >happy about not having to go to the commandline to get access to their > >partitions and some people have more or less valid security concerns. > > OK, I've had some time to think this over. Traditionally, the default is on the > open - all inclusive side of things unless there is the possibility of damage. > e.g., tcp_wrapper defaults to open, iptable defaults to open. You must intervene > to secure the system. > > As long as the drives are only detected and mount points made, it don't have a > problem. If the drives are *mounted*, I have a real problem. By mounting the > drive, you may suddenly cause a drive to get fsck'ed by a newer program that > oopses older kernels, Has this actually happened? > or relabeled by SE Linux which will oops older kernels. Yes; it's really a bug that the default relabeling procedure will try to relabel mount points. I've submitted a patch to fix this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Fri Sep 10 15:18:31 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Sep 2004 11:18:31 -0400 Subject: yum and local cache In-Reply-To: <007401c49746$3325d9c0$4801a8c0@C515816A> References: <1094827848.26144.9.camel@opus.phy.duke.edu> <007401c49746$3325d9c0$4801a8c0@C515816A> Message-ID: <604aa7910409100818159c6892@mail.gmail.com> On Fri, 10 Sep 2004 09:55:22 -0500, Otto Haliburton wrote: > It didn't fail quietly, It failed as has been described in this thread, I > just didn't want to continue repeating the same error message. The > description of the problem is valid. I have NOT seen a full or detailed error message from yum in this thread from anyone who thinks they are seeing a problem with yum's caching behavior. Its very important... to be as accurate as possible... when reporting problems. And that means giving error messages VERBATIM. All i see in this thread is talk about the error messages being seen, i have not seen the actually yum output reproduced. No one in this thread has actually submitted the actually messages yum was producing in context with the actions being performed. No one has gone through the trouble of running yum in a higher debug level and logging the output. Now, I don't expect a novice tester to know where to look for yum's cache information like I did to visually inspect that cache files are being stored. I don't expect a novice tester to automatically know they should perhaps maybe look to turn on higher verbosity and debuging output. But what I do expect, and I would dare say most developers would expect from competent testers even novice ones to give accurate and full error and log messages that the programs are producing when trying to communicate a problem. -jef"if you can't cut and paste, get a digital camera and take a picture of the screen with the yum message text..do whatever it takes to get accurate error messages into the bug report...you did file a bug report right?"spaleta From ottohaliburton at comcast.net Fri Sep 10 15:13:16 2004 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Fri, 10 Sep 2004 10:13:16 -0500 Subject: yum and local cache In-Reply-To: <50982.12.41.112.51.1094828477.squirrel@webmail.ec-group.com> Message-ID: <007c01c49748$b603ac30$4801a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Brian Millett > Sent: Friday, September 10, 2004 10:01 AM > To: fedora-devel-list at redhat.com > Subject: RE: yum and local cache > > > > > > > >> -----Original Message----- > >> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > >> bounces at redhat.com] On Behalf Of seth vidal > >> Sent: Friday, September 10, 2004 9:25 AM > >> To: Development discussions related to Fedora Core > >> Subject: RE: yum and local cache > >> > >> > FYI, I had a problem similar to the description here but I didn't > >> investigate further. There is something wrong with the new yum, but > >> I > >> can't > >> > be sure what it is. I do know that it failed at a particular > >> repository that it work for before. > >> > >> 'something wrong' > >> > >> That's not terribly helpful for bugfixing. > >> > >> -sv > >> > >> > >> > >> -- > > and actually it is. It says that if yours is working properly and mine > > and the others is not working properly, then something is happening in > > the installation of the new yum that is causing a problem or in my case > > some of the repositories have something different that is causing a > > problem. My failed on the livna(sp) repository. > > > > Yep, this bit me also. What happened is that the location of the repo > changed. Below is how I have it now. > > [livna-stable] > name=Livna.org Fedora Compatible Packages (stable) > #baseurl= http://rpm.livna.org/fedora/2/$basearch/yum/stable > baseurl= http://rpm.livna.org/fedora/2/$basearch/RPMS.stable > gpgcheck=1 > > > > -- > Brian Millett > Enterprise Consulting Group "Shifts in paradigms > (314) 205-9030 often cause nose bleeds." > bpmATec-groupDOTcom Greg Glenn > > > > > -- I'm going to make the changes now and see if they work. I assume they will. Thanks. From skvidal at phy.duke.edu Fri Sep 10 14:58:02 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 10 Sep 2004 10:58:02 -0400 Subject: yum and local cache In-Reply-To: <007401c49746$3325d9c0$4801a8c0@C515816A> References: <007401c49746$3325d9c0$4801a8c0@C515816A> Message-ID: <1094828282.26144.11.camel@opus.phy.duke.edu> > It didn't fail quietly, It failed as has been described in this thread, I > just didn't want to continue repeating the same error message. The > description of the problem is valid. Nothing has been described in this thread. no output, no error messages, NOTHING. -sv From ottohaliburton at comcast.net Fri Sep 10 16:00:11 2004 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Fri, 10 Sep 2004 11:00:11 -0500 Subject: yum and local cache In-Reply-To: <1094828282.26144.11.camel@opus.phy.duke.edu> References: <007401c49746$3325d9c0$4801a8c0@C515816A> <1094828282.26144.11.camel@opus.phy.duke.edu> Message-ID: <1094832011.4379.1.camel@c515816-a> On Fri, 2004-09-10 at 09:58, seth vidal wrote: > > It didn't fail quietly, It failed as has been described in this thread, I > > just didn't want to continue repeating the same error message. The > > description of the problem is valid. > > Nothing has been described in this thread. > > no output, no error messages, NOTHING. > > -sv > this is the preleminary output I got the error on > [root at c515816-a etc]# yum update Setting up Update Process Setting up Repo: core repomd.xml 100% |=========================| 843 B 00:00 Setting up Repo: freshrpms repomd.xml 100% |=========================| 843 B 00:00 Setting up Repo: updates repomd.xml 100% |=========================| 843 B 00:00 Setting up Repo: livna-stable repodata/repomd.xml: [Errno 4] IOError: HTTP Error 404: Not Found Cannot open/read repomd.xml file for repository: livna-stable failure: repodata/repomd.xml from livna-stable: [Errno 256] No more mirrors to t ry. [r From kyrre at solution-forge.net Fri Sep 10 15:38:41 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 10 Sep 2004 17:38:41 +0200 Subject: yum and local cache In-Reply-To: <1094828282.26144.11.camel@opus.phy.duke.edu> References: <007401c49746$3325d9c0$4801a8c0@C515816A> <1094828282.26144.11.camel@opus.phy.duke.edu> Message-ID: <1094830721.2734.7.camel@kyrre> fre, 10.09.2004 kl. 16.58 skrev seth vidal: > > It didn't fail quietly, It failed as has been described in this thread, I > > just didn't want to continue repeating the same error message. The > > description of the problem is valid. > > Nothing has been described in this thread. > > no output, no error messages, NOTHING. > > -sv > > But a long thread it is :P From linux_4ever at yahoo.com Fri Sep 10 15:58:17 2004 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 10 Sep 2004 08:58:17 -0700 (PDT) Subject: First boot with 20040908 changes In-Reply-To: <1094828948.7061.22.camel@nexus.verbum.private> Message-ID: <20040910155817.22756.qmail@web50605.mail.yahoo.com> >> As long as the drives are only detected and mount points made, it don't have a >> problem. If the drives are *mounted*, I have a real problem. By mounting the >> drive, you may suddenly cause a drive to get fsck'ed by a newer program that >> oopses older kernels, > >Has this actually happened? Yes. I have a drive that is a pass between 2 OS's that's partitioned as ext3. When FC3 does anything to that drive & I reboot into another OS, it oopses. Sometimes on boot it drops me to a nash console where I basically reformat the partition to recover. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From notting at redhat.com Fri Sep 10 16:30:21 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Sep 2004 12:30:21 -0400 Subject: tmpfs /dev In-Reply-To: <200409101508.27612.russell@coker.com.au> References: <200409100536.59711.russell@coker.com.au> <4140BAB8.8070808@redhat.com> <200409101508.27612.russell@coker.com.au> Message-ID: <20040910163021.GA28303@nostromo.devel.redhat.com> Russell Coker (russell at coker.com.au) said: > On Fri, 10 Sep 2004 06:19, Daniel J Walsh wrote: > > You will need to talk to Bill Nottingham about modifying /sbin/init to > > do this. They are not crazy about > > putting additional code into /sbin/init since it is very hard to debug. > > We've done it once, we can do it again. But why is init any better? Especially when it's just spawning a shell script - that's a hack. > > They prefer rc.sysinit. They also do not > > rc.sysinit means changing the policy for init_t, initrc_t, and maybe others. init runs in init_t, surely? > > want to relabel the /dev file system if it is not a tmpfs, since with > > 8000 or more files it could take a while and > > slow down the boot up. > > On the slowest machine I have access to (a machine that can never run Fedora > because it doesn't meet the hardware requirements) it takes 12 seconds to run > setfiles on a fully loaded /dev. On machines that are a mere four years old > it takes about 2 seconds, I doubt that you will be able to measure the > difference that this makes on any hardware that can be purchased now. But > writing some code to check for the file system type is not too difficult. The code's already written and there. The reason you don't want to run it on a normal /dev is because it's *pointless.* Bill From steve at silug.org Fri Sep 10 16:53:15 2004 From: steve at silug.org (Steven Pritchard) Date: Fri, 10 Sep 2004 11:53:15 -0500 Subject: RFC: cleaning up updates and updates-testing In-Reply-To: <20040910035921.GA28619@angus.ind.WPI.EDU> References: <20040909183417.GB15025@nostromo.devel.redhat.com> <20040909193421.GE27782@xi.wantstofly.org> <20040910023249.GB3521@osiris.silug.org> <20040910035921.GA28619@angus.ind.WPI.EDU> Message-ID: <20040910165315.GA7754@osiris.silug.org> On Thu, Sep 09, 2004 at 11:59:21PM -0400, Charles R. Anderson wrote: > >From a mirroring perspective, it is much more efficient to have an > all-updates directory containing all the real files, and a > latest-updates directory containing only symlinks to the newest files > in the other directory. That way rsync can sync the symlinks with > --delete and you don't have to download the files again when they > become obsolete and would otherwise be moved between directories. But then there wouldn't be anything to --exclude easily (for mirrors concerned about space). To avoid the multiple-download problem, when the new update appears, a hard link to the old update could be created in the obsolete-updates directory. The updates directory copy could then be deleted a week later (or whatever). As long as mirrors are using rsync -H and mirroring regularly, they'd never need to re-download an update. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From linux_4ever at yahoo.com Fri Sep 10 17:27:42 2004 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 10 Sep 2004 10:27:42 -0700 (PDT) Subject: First boot with 20040908 changes In-Reply-To: <1094827918.7068.27.camel@localhost.localdomain> Message-ID: <20040910172742.75076.qmail@web50610.mail.yahoo.com> >However, when you log in to GNOME then gnome-volume-manager, in the >default configuration, mounts all the drives as the user who is logging >in. And unmounts them at logout. I think this is sane given the options >put in /etc/fstab. > > /dev/sda1 /media/compact_flash vfat >rw,sync,noatime,nodiratime,nosuid,nodev,uid=500,gid=500,fmask=0022,dmask=0022 0 0 > >Note the nosuid,nodev options thanks to having user in the fstab line. > >So, I hope we can agree this is pretty safe? The damage comes from xattr. Suppose I have a machine that boots Mandrake, debian, and FC3. I use the /opt as a pass between the the various OS's. It is on its own partition. One of these days, the mount count triggers a fsck. I don't want it to write anything to the drive if it can mess it up. Again, the problem is xattrs and the older OS's not handling them. Its too late now, but I think allowing xattrs into ext3 was a big mistake from a backwards compatibility stance. It should have been ext4. Sure, the bugs in ext3 would still be there waiting to bite you, but you won't face them every single day. Can you detect a ext3 drive that doesn't have xattrs applied? If so, the work around is not to write anything related to xattrs to that drive. >I'm not sure how well turning off media detection works presently Something changed after yesterday's updates. I set everything to false yesterday and there were no entries in /media and fstab. Today they are there. >(I test it once in a while though) and I think g-v-m >ignores the automount hint. When Nautilus and GNOME VFS is ready, this >will be supported as well [1]. Then the answer is not to make the drive available. There should probably be a configuration option that says do not update fstab with detected media and another for do not create mount points for detected media. This way, people that cannot afford to get a corrupted partition from xattrs being written to a partition that a NON-SE Linux OS must access can avoid damage. >There is supposed to be a /media/cdrom mount point if you got a CD-ROM drive; OK, I don't see one. The following is from an earlier e-mail to the list that I didn't get a chance to answer: >This should work. What does 'udevinfo -r -q name -p /block/hdc' say? /dev/hdc >Does running 'service haldaemon stop; udevstart; service >haldaemon start' solve your problem? No. [root at buildhost root]# ls /media/ idedisk idedisk1 scsidisk scsidisk1 [root at buildhost root]# service haldaemon stop Stopping HAL daemon: [FAILED] [root at buildhost root]# udevstart [root at buildhost root]# service haldaemon start Starting HAL daemon: [ OK ] /etc/init.d/haldaemon: line 31: /var/run/hald/pid: No such file or directory >Otherwise you need to file a bug against hal to we can fix it Does the above look like a bug? If so I will file one. Thanks, -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From aoliva at redhat.com Fri Sep 10 17:57:52 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Sep 2004 14:57:52 -0300 Subject: Will FC3 grub DTRT wrt installation on software RAID-1 boot arrays In-Reply-To: <200409101221.25818@-mr700> References: <20040910042327.GA13857@outblaze.com> <200409101221.25818@-mr700> Message-ID: On Sep 10, 2004, "Doncho N. Gunchev" wrote: > When I remove any of the disks (or swap them randomly) it boots > without problems (even changing hdc to hdd). Right. Now try to get the first disk to fail in such a way that it remains visible to the BIOS but it no longer works, or no longer serves the boot sector correctly, and see how that goes. That's the kind of scenario you might be willing to protect against, right? Unfortunately, in this case, it won't renumber the disks, and the system won't boot up. > md0 is /boot and everything else is on md1 (LVM). I don't know if > BIOS moves the first available disk to 0x80 It does. This is exactly what you're tell grub when you change the device mapping. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From jamesaharrisonuk at yahoo.co.uk Fri Sep 10 15:43:37 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Fri, 10 Sep 2004 08:43:37 -0700 (PDT) Subject: vsftpd.conf Message-ID: <20040910154337.48501.qmail@web25305.mail.ukl.yahoo.com> Hi all, Im not sure is this is a security hole, but I have Ferdora Core 2 loaded on my machine and the vsftpd.conf shows: anonymous_enable=YES If its Very Secure then surely anonymous_enable=NO allowing only local users to connect. James Harrison __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From kashif at linuxcraft.co.uk Fri Sep 10 18:35:23 2004 From: kashif at linuxcraft.co.uk (Kashif Ali) Date: Fri, 10 Sep 2004 19:35:23 +0100 Subject: vsftpd.conf References: <20040910154337.48501.qmail@web25305.mail.ukl.yahoo.com> Message-ID: <001701c49764$eeff77a0$82368552@thor> Vsftpd by default allows anonymous connection to download and not upload so its ok. Kashif Ali ----- Original Message ----- From: "James Harrison" To: "redhat fedora dev" Sent: Friday, September 10, 2004 4:43 PM Subject: vsftpd.conf > Hi all, > > Im not sure is this is a security hole, but I have Ferdora Core 2 loaded > on my > machine and the vsftpd.conf shows: anonymous_enable=YES > > If its Very Secure then surely anonymous_enable=NO allowing only local > users > to connect. > > James Harrison > > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - Send 10MB messages! > http://promotions.yahoo.com/new_mail > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From smoogen at lanl.gov Fri Sep 10 18:38:54 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Fri, 10 Sep 2004 12:38:54 -0600 Subject: First boot with 20040908 changes In-Reply-To: <20040910172742.75076.qmail@web50610.mail.yahoo.com> References: <20040910172742.75076.qmail@web50610.mail.yahoo.com> Message-ID: <4141F4BE.5040207@lanl.gov> Steve G wrote: > > Its too late now, but I think allowing xattrs into ext3 was a big mistake > from a backwards compatibility stance. It should have been ext4. Sure, the bugs > in ext3 would still be there waiting to bite you, but you won't face them every > single day. > Reading the kernel list.. I think that Linus has a similar opinion :). -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From kyrre at solution-forge.net Fri Sep 10 18:51:15 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 10 Sep 2004 20:51:15 +0200 Subject: vsftpd.conf In-Reply-To: <001701c49764$eeff77a0$82368552@thor> References: <20040910154337.48501.qmail@web25305.mail.ukl.yahoo.com> <001701c49764$eeff77a0$82368552@thor> Message-ID: <1094842275.3924.1.camel@kyrre> And the anonymous user it is "chrooted" to an empty folder. But i agree with the principe - don't ship with anonymous logon turned on - let the user do this if he/she wants to. fre, 10.09.2004 kl. 20.35 skrev Kashif Ali: > Vsftpd by default allows anonymous connection to download and not upload so > its ok. > > Kashif Ali > > > ----- Original Message ----- > From: "James Harrison" > To: "redhat fedora dev" > Sent: Friday, September 10, 2004 4:43 PM > Subject: vsftpd.conf > > > > Hi all, > > > > Im not sure is this is a security hole, but I have Ferdora Core 2 loaded > > on my > > machine and the vsftpd.conf shows: anonymous_enable=YES > > > > If its Very Secure then surely anonymous_enable=NO allowing only local > > users > > to connect. > > > > James Harrison > > > > > > > > __________________________________ > > Do you Yahoo!? > > New and Improved Yahoo! Mail - Send 10MB messages! > > http://promotions.yahoo.com/new_mail > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From kyrre at solution-forge.net Fri Sep 10 18:52:34 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 10 Sep 2004 20:52:34 +0200 Subject: First boot with 20040908 changes In-Reply-To: <4141F4BE.5040207@lanl.gov> References: <20040910172742.75076.qmail@web50610.mail.yahoo.com> <4141F4BE.5040207@lanl.gov> Message-ID: <1094842353.3924.3.camel@kyrre> Hmm... will ext3 suddeny change name to ext4? That would be... interesting. fre, 10.09.2004 kl. 20.38 skrev Stephen J Smoogen: > Steve G wrote: > > > > > Its too late now, but I think allowing xattrs into ext3 was a big mistake > > from a backwards compatibility stance. It should have been ext4. Sure, the bugs > > in ext3 would still be there waiting to bite you, but you won't face them every > > single day. > > > > Reading the kernel list.. I think that Linus has a similar opinion :). > > > > > -- > Stephen John Smoogen | CCN-5 Security Team > LANL SIRT Team Leader | SMTP: smoogen at lanl.gov > Los Alamos National Laboratory | Voice: 505.664.0645 > Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 > Los Alamos, NM 87545 | > From al at casa.org.ro Fri Sep 10 20:10:29 2004 From: al at casa.org.ro (Alin Osan) Date: Fri, 10 Sep 2004 23:10:29 +0300 Subject: yum and local cache In-Reply-To: <1094828282.26144.11.camel@opus.phy.duke.edu> References: <007401c49746$3325d9c0$4801a8c0@C515816A> <1094828282.26144.11.camel@opus.phy.duke.edu> Message-ID: <200409102310.29763.al@casa.org.ro> On Fri September 10 2004 17:58, seth vidal wrote: > Nothing has been described in this thread. > > no output, no error messages, NOTHING. Wrong (again) :-) In my first mail of this thread I described the problem. Here are my posts (again): ### Hello, The latest version of yum doesn't seem to use the local cache. If for some reason, yum -y update has to be restarted (dependency problem, conflicts), it begins to download all the files from the top, including those were previously downloaded. Is this a bug or a feature? ### And the second one, with required informations: ### On Friday 10 September 2004 10:57, seth vidal wrote: > 1. what version of yum yum-2.1.3-1 > 2. why do you say it's downloading things over and over again? I say it because it happens. First time, it stopped with "Error: xorg-x11-font-utils conflicts: xorg-x11-base-fonts<= 6.7.99.903-3" and after I manually installed xorg-x11-font-utils yum -y update started to download all the files from the beginning. I noticed this on a PC at home, it was not a problem since bandwidth is plenty but I'm doing the same thing on a machine at work where I have 512 kbps. I don't want to think about dial-up users... ### If and only if yum gets an error like the one before, it will download again all files, will just ignore the files allready downloaded. I'm absolutely sure about this, it happen on two distict machines, both with rawide, I even checked with tcdump to see if there is any bits flow. Otherwise, yum uses the files in cache, but it does not if you get a conflict (like the one that I had, "Error: xorg-x11-font-utils conflicts: xorg-x11-base-fonts<= 6.7.99.903-3"). Meanwhile, yum is a great tool and you are doing a great job. I'm just trying to help. -- -- Alin Osan From dax at gurulabs.com Fri Sep 10 21:36:59 2004 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 10 Sep 2004 15:36:59 -0600 Subject: vsftpd.conf In-Reply-To: <1094842275.3924.1.camel@kyrre> References: <20040910154337.48501.qmail@web25305.mail.ukl.yahoo.com> <001701c49764$eeff77a0$82368552@thor> <1094842275.3924.1.camel@kyrre> Message-ID: <1094852219.3929.91.camel@mentorng.gurulabs.com> On Fri, 2004-09-10 at 12:51, Kyrre Ness Sjobak wrote: > And the anonymous user it is "chrooted" to an empty folder. > > But i agree with the principe - don't ship with anonymous logon turned > on - let the user do this if he/she wants to. This will break long standing behavior, besides, you still have to install vsftpd, and then manual start it and/or chkconfig it on, and enable incoming FTP in the default firewall. It isn't as if all this will happen by accident. Dax Kelson From jamesaharrisonuk at yahoo.co.uk Fri Sep 10 21:38:50 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Fri, 10 Sep 2004 14:38:50 -0700 (PDT) Subject: vsftpd.conf In-Reply-To: <1094842275.3924.1.camel@kyrre> Message-ID: <20040910213850.55093.qmail@web25306.mail.ukl.yahoo.com> > But i agree with the principe - don't ship with anonymous logon turned > on - let the user do this if he/she wants to. I agree too. User logins are OK but not anonymous. --- Kyrre Ness Sjobak wrote: > And the anonymous user it is "chrooted" to an empty folder. > > But i agree with the principe - don't ship with anonymous logon turned > on - let the user do this if he/she wants to. > > fre, 10.09.2004 kl. 20.35 skrev Kashif Ali: > > Vsftpd by default allows anonymous connection to download and not upload > so > > its ok. > > > > Kashif Ali > > > > > > ----- Original Message ----- > > From: "James Harrison" > > To: "redhat fedora dev" > > Sent: Friday, September 10, 2004 4:43 PM > > Subject: vsftpd.conf > > > > > > > Hi all, > > > > > > Im not sure is this is a security hole, but I have Ferdora Core 2 loaded > > > > on my > > > machine and the vsftpd.conf shows: anonymous_enable=YES > > > > > > If its Very Secure then surely anonymous_enable=NO allowing only local > > > users > > > to connect. > > > > > > James Harrison > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > New and Improved Yahoo! Mail - Send 10MB messages! > > > http://promotions.yahoo.com/new_mail > > > > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From veillard at redhat.com Fri Sep 10 21:41:07 2004 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 10 Sep 2004 17:41:07 -0400 Subject: vsftpd.conf In-Reply-To: <20040910213850.55093.qmail@web25306.mail.ukl.yahoo.com> References: <1094842275.3924.1.camel@kyrre> <20040910213850.55093.qmail@web25306.mail.ukl.yahoo.com> Message-ID: <20040910214107.GU20796@redhat.com> On Fri, Sep 10, 2004 at 02:38:50PM -0700, James Harrison wrote: > > But i agree with the principe - don't ship with anonymous logon turned > > on - let the user do this if he/she wants to. > I agree too. User logins are OK but not anonymous. Well I disagree, that would break the existing setups. FTP is firewalled by default, so unless you explicitely turn off firewalling (for ftp) then there is no risk. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From jamesaharrisonuk at yahoo.co.uk Fri Sep 10 21:49:51 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Fri, 10 Sep 2004 14:49:51 -0700 (PDT) Subject: vsftpd.conf In-Reply-To: <20040910214107.GU20796@redhat.com> Message-ID: <20040910214951.56595.qmail@web25306.mail.ukl.yahoo.com> You have a lot of faith in your firewall setup. Why have a firewall rule to stop an anonymous someone ftping into the machine when you can either disable ftp altogether or stop that anonymous someone accessing the system and only allow known trusted users in. Allowing anonymous ftp should be a special case. --- Daniel Veillard wrote: > On Fri, Sep 10, 2004 at 02:38:50PM -0700, James Harrison wrote: > > > But i agree with the principe - don't ship with anonymous logon turned > > > on - let the user do this if he/she wants to. > > I agree too. User logins are OK but not anonymous. > > Well I disagree, that would break the existing setups. > FTP is firewalled by default, so unless you explicitely turn off > firewalling (for ftp) then there is no risk. > > Daniel > > -- > Daniel Veillard | Red Hat Desktop team http://redhat.com/ > veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > _______________________________ Do you Yahoo!? Shop for Back-to-School deals on Yahoo! Shopping. http://shopping.yahoo.com/backtoschool From notting at redhat.com Fri Sep 10 22:14:25 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Sep 2004 18:14:25 -0400 Subject: Fedora Core 3 Schedule Update - Test 2 Delayed Message-ID: <20040910221424.GA31318@nostromo.devel.redhat.com> Due to various issues with candidate trees so far, Test 2 has been pushed out one week, to September 20th. Updated schedule is at: http://fedora.redhat.com/participate/schedule/ Bill From fkooman at bromstraat.net Fri Sep 10 22:41:21 2004 From: fkooman at bromstraat.net (F. Kooman) Date: Sat, 11 Sep 2004 00:41:21 +0200 Subject: vsftpd.conf In-Reply-To: <20040910214951.56595.qmail@web25306.mail.ukl.yahoo.com> References: <20040910214951.56595.qmail@web25306.mail.ukl.yahoo.com> Message-ID: <1094856081.13137.7.camel@dilithium.bromstraat.net> On Fri, 2004-09-10 at 23:49, James Harrison wrote: > You have a lot of faith in your firewall setup. > > Why have a firewall rule to stop an anonymous someone ftping into the machine > when you can either disable ftp altogether or stop that anonymous someone > accessing the system and only allow known trusted users in. Allowing trusted users in is even worse than allowing anonymous users (plain text authentication) in short: you shouldn't use ftp at all... Fran?ois -- Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html From jamesaharrisonuk at yahoo.co.uk Sat Sep 11 00:09:44 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Fri, 10 Sep 2004 17:09:44 -0700 (PDT) Subject: vsftpd.conf In-Reply-To: <1094856081.13137.7.camel@dilithium.bromstraat.net> Message-ID: <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> If youre going to be that paranoid, dont connect the machine to the internet. James --- "F. Kooman" wrote: > On Fri, 2004-09-10 at 23:49, James Harrison wrote: > > You have a lot of faith in your firewall setup. > > > > Why have a firewall rule to stop an anonymous someone ftping into the > machine > > when you can either disable ftp altogether or stop that anonymous someone > > accessing the system and only allow known trusted users in. > > Allowing trusted users in is even worse than allowing anonymous users > (plain text authentication) in short: you shouldn't use ftp at all... > > Fran?ois > -- > Please avoid sending me Word or PowerPoint attachments. > See http://www.fsf.org/philosophy/no-word-attachments.html > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From jspaleta at gmail.com Fri Sep 10 21:15:02 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Sep 2004 17:15:02 -0400 Subject: yum and local cache In-Reply-To: <200409102310.29763.al@casa.org.ro> References: <007401c49746$3325d9c0$4801a8c0@C515816A> <1094828282.26144.11.camel@opus.phy.duke.edu> <200409102310.29763.al@casa.org.ro> Message-ID: <604aa79104091014153b7df02a@mail.gmail.com> On Fri, 10 Sep 2004 23:10:29 +0300, Alin Osan wrote: > If and only if yum gets an error like the one before, it will download > again all files, will just ignore the files allready downloaded. I'm > absolutely sure about this, it happen on two distict machines, both > with rawide, I even checked with tcdump to see if there is any bits > flow. Otherwise, yum uses the files in cache, but it does not if you > get a conflict (like the one that I had, "Error: > xorg-x11-font-utils conflicts: xorg-x11-base-fonts<= 6.7.99.903-3"). > Meanwhile, yum is a great tool and you are doing a great job. I'm just > trying to help. I just created two very small test packages... that conflict... and I do not see yum redownloading anything after recieving the conflict error. yum install barapp foolib Excluding Packages from Local Test Resolving Dependencies barapp-0.1-2.i386.rpm 100% |=========================| 1.7 kB 00:00 foolib-0.2-1.i386.rpm 100% |=========================| 1.6 kB 00:00 Error: barapp conflicts: foolib= 0.2-1 let me point out to you that what you just saw downloaded were the HEADERS as found in /var/cache/yum//headers In my test package case /var/cache/yum/local/headers: -rw-r--r-- 1 root root 1716 Sep 10 16:58 barapp-0.1-2.i386.hdr -rw-r--r-- 1 root root 1600 Sep 10 16:59 foolib-0.2-1.i386.hdr /var/cache/yum/local/packages: is empty No packages are downloaded if a detected conflict causes yum to error out. Now I go back and just install foolib by itself yum install foolib Excluding Packages from Local Test Resolving Dependencies Dependencies Resolved [i] foolib.i386 0:0.2-1 - user Is this ok [y/N]: y foolib-0.2-1.i386.rpm 100% |=========================| 1.9 kB 00:00 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction foolib 100 % done 1/1 Complete! That download was the download of the actual package. The headers were NOT re-downloaded! after this second attempt to install foolib without the conflicting barapp package, I now have a cached package. /var/cache/yum/local/packages: -rw-r--r-- 1 root root 1987 Sep 10 16:59 foolib-0.2-1.i386.rpm to recap..... if yum errors out due to a conflict NO PACKAGES WERE DOWNLOADED. yum downloads headers from the packages during depresolution. Packages are only downloaded if depresolution clears successfully. you are NOT seeing redownloading of anything. The cache IS working, the header files in the cache ARE being reused. -jef"happy friday afternoon.... time to go kick a puppy"spaleta From foolish at fedoraforum.org Sat Sep 11 00:34:55 2004 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Sat, 11 Sep 2004 02:34:55 +0200 Subject: Fedora Core 3 Schedule Update - Test 2 Delayed In-Reply-To: <20040910221424.GA31318@nostromo.devel.redhat.com> References: <20040910221424.GA31318@nostromo.devel.redhat.com> Message-ID: <1094862895.4676.0.camel@localhost.localdomain> Does this mean the support for Core 1 will be extended as well? fre, 10,.09.2004 kl. 18.14 -0400, skrev Bill Nottingham: > Due to various issues with candidate trees so far, Test 2 > has been pushed out one week, to September 20th. > > Updated schedule is at: > > http://fedora.redhat.com/participate/schedule/ > > Bill > > -- Sindre Pedersen Bjordal www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From pekkas at netcore.fi Sat Sep 11 05:29:45 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 11 Sep 2004 08:29:45 +0300 (EEST) Subject: vsftpd.conf In-Reply-To: <1094852219.3929.91.camel@mentorng.gurulabs.com> Message-ID: On Fri, 10 Sep 2004, Dax Kelson wrote: > On Fri, 2004-09-10 at 12:51, Kyrre Ness Sjobak wrote: > > And the anonymous user it is "chrooted" to an empty folder. > > > > But i agree with the principe - don't ship with anonymous logon turned > > on - let the user do this if he/she wants to. > > This will break long standing behavior, besides, you still have to > install vsftpd, and then manual start it and/or chkconfig it on, and > enable incoming FTP in the default firewall. > > It isn't as if all this will happen by accident. Totally agree. You'll need to configure the FTP server in any case, and you can just configure vsftpd for your tastes as well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From michaelo.waugh at telus.net Sat Sep 11 05:31:44 2004 From: michaelo.waugh at telus.net (Michael O. Waugh) Date: Fri, 10 Sep 2004 22:31:44 -0700 Subject: REMOVE FROM MAILING LIST Message-ID: <41428DC0.509@telus.net> michaelo.waugh at telus.net From cra at WPI.EDU Sat Sep 11 05:33:17 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sat, 11 Sep 2004 01:33:17 -0400 Subject: RFC: cleaning up updates and updates-testing In-Reply-To: <20040910165315.GA7754@osiris.silug.org> References: <20040909183417.GB15025@nostromo.devel.redhat.com> <20040909193421.GE27782@xi.wantstofly.org> <20040910023249.GB3521@osiris.silug.org> <20040910035921.GA28619@angus.ind.WPI.EDU> <20040910165315.GA7754@osiris.silug.org> Message-ID: <20040911053317.GA10610@angus.ind.WPI.EDU> On Fri, Sep 10, 2004 at 11:53:15AM -0500, Steven Pritchard wrote: > On Thu, Sep 09, 2004 at 11:59:21PM -0400, Charles R. Anderson wrote: > > >From a mirroring perspective, it is much more efficient to have an > > all-updates directory containing all the real files, and a > > latest-updates directory containing only symlinks to the newest files > > in the other directory. That way rsync can sync the symlinks with > > --delete and you don't have to download the files again when they > > become obsolete and would otherwise be moved between directories. > > But then there wouldn't be anything to --exclude easily (for mirrors > concerned about space). Sure there would. Just download the latest-updates directory, following the symlink targets. > To avoid the multiple-download problem, when the new update appears, a > hard link to the old update could be created in the obsolete-updates > directory. The updates directory copy could then be deleted a week > later (or whatever). As long as mirrors are using rsync -H and > mirroring regularly, they'd never need to re-download an update. Not everyone uses rsync... Symlinks could be supported by ftp mirroring. From cra at WPI.EDU Sat Sep 11 05:42:06 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sat, 11 Sep 2004 01:42:06 -0400 Subject: vsftpd.conf In-Reply-To: <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> Message-ID: <20040911054206.GB10610@angus.ind.WPI.EDU> On Fri, Sep 10, 2004 at 05:09:44PM -0700, James Harrison wrote: > --- "F. Kooman" wrote: > > Allowing trusted users in is even worse than allowing anonymous users > > (plain text authentication) in short: you shouldn't use ftp at all... > If youre going to be that paranoid, dont connect the machine to the internet. Not really...I think he makes a very valid point that allowing trusted users to login via FTP is worse than allowing anonymous users FTP access. FTP should only ever be used in anonymous mode, like HTTP servers are mostly used for. If you don't what that, don't enable the service. From russell at coker.com.au Sat Sep 11 06:43:54 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 11 Sep 2004 16:43:54 +1000 Subject: tmpfs /dev In-Reply-To: <20040910163021.GA28303@nostromo.devel.redhat.com> References: <200409100536.59711.russell@coker.com.au> <200409101508.27612.russell@coker.com.au> <20040910163021.GA28303@nostromo.devel.redhat.com> Message-ID: <200409111643.54132.russell@coker.com.au> On Sat, 11 Sep 2004 02:30, Bill Nottingham wrote: > Russell Coker (russell at coker.com.au) said: > > On Fri, 10 Sep 2004 06:19, Daniel J Walsh wrote: > > > You will need to talk to Bill Nottingham about modifying /sbin/init to > > > do this. They are not crazy about > > > putting additional code into /sbin/init since it is very hard to debug. > > > > We've done it once, we can do it again. > > But why is init any better? Especially when it's just spawning a > shell script - that's a hack. Spawning a shell script is good for a test. If we decide to run it from init then we can do it differently in the release version of the code. > > > They prefer rc.sysinit. They also do not > > > > rc.sysinit means changing the policy for init_t, initrc_t, and maybe > > others. > > init runs in init_t, surely? init runs in init_t AFTER it re-exec's itself. At the time it is doing the SE Linux stuff it's running as kernel_t or running on a system with no policy loaded. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From mmitu at bitdefender.com Sat Sep 11 06:49:49 2004 From: mmitu at bitdefender.com (Mircea MITU) Date: Sat, 11 Sep 2004 09:49:49 +0300 Subject: dev rpm update problem Message-ID: <1094885390.15218.8.camel@localhost.localdomain> > I get this error when updating to dev-3.11-1: > > Cannot install the dev package: mounted devfs detected. > error: %pre(dev-3.11-1) scriptlet failed, exit status 1 > error: install: %pre scriptlet failed (2), skipping dev-3.11-1 > > I know this was happening previously with the MAKEDEV rpm, but it seems > like it was solved in that case (by removing the %pre script?). > > Anyway, how do I upgrade the package? Is this a bug? I had the same problem but upgrading from dev-3.11-1 to dev-3.12-1 The pre-install script of the rpm is looking for devfs into /proc/mounts and it founds none /dev tmpfs rw 0 0 I did succeed to upgrade by executing the pre-install script by hand, ignoring the devfs check ( #if [ -r /proc/mounts ]; then # while read source mountpoint rest ; do # if [ "$mountpoint" = "/dev" ]; then # echo $"Cannot install the dev package: mounted devfs detected." # exit 1 # fi # done < /proc/mounts #fi [ -d /dev ] || /bin/mkdir /dev /usr/sbin/groupadd -g 19 -r -f floppy > /dev/null 2>/dev/null /usr/sbin/useradd -c "virtual console memory owner" -u 69 \ -s /sbin/nologin -r -d /dev vcsa 2> /dev/null ) and then using --nopre rpm option rpm -Uvh dev-3.12-1.i386.rpm --nopre -- This message was scanned for spam and viruses by BitDefender For more information please visit http://linux.bitdefender.com/ From david at fubar.dk Sat Sep 11 07:33:58 2004 From: david at fubar.dk (David Zeuthen) Date: Sat, 11 Sep 2004 09:33:58 +0200 Subject: First boot with 20040908 changes In-Reply-To: <20040910172742.75076.qmail@web50610.mail.yahoo.com> References: <20040910172742.75076.qmail@web50610.mail.yahoo.com> Message-ID: <1094888039.18143.15.camel@localhost.localdomain> On Fri, 2004-09-10 at 10:27 -0700, Steve G wrote: > The damage comes from xattr. Suppose I have a machine that boots Mandrake, > debian, and FC3. I use the /opt as a pass between the the various OS's. It is on > its own partition. One of these days, the mount count triggers a fsck. I don't > want it to write anything to the drive if it can mess it up. Again, the problem > is xattrs and the older OS's not handling them. > > Its too late now, but I think allowing xattrs into ext3 was a big mistake > from a backwards compatibility stance. It should have been ext4. Sure, the bugs > in ext3 would still be there waiting to bite you, but you won't face them every > single day. > > Can you detect a ext3 drive that doesn't have xattrs applied? If so, the work > around is not to write anything related to xattrs to that drive. > It sounds to me like this should be fixed in the kernel. > >I'm not sure how well turning off media detection works presently > > Something changed after yesterday's updates. I set everything to false yesterday > and there were no entries in /media and fstab. Today they are there. > > >(I test it once in a while though) and I think g-v-m > >ignores the automount hint. When Nautilus and GNOME VFS is ready, this > >will be supported as well [1]. > > Then the answer is not to make the drive available. There should probably be a > configuration option that says do not update fstab with detected media and > another for do not create mount points for detected media. Maintaining mountpoints == maintaining /etc/fstab. There will be a configuration for fstab-sync to specify whether a drive or media should be ignored. So you'll be able to say something like block.device="/dev/hda7", ignore storage.serial="CLP225F2G3UR4A", ignore block.device="/dev/hda2", mount_point="/mnt/my_own_mount_point" volume.label="CANON_DC", mount_point="/mnt/my_camera", options="noauto,user,exec,noatime,sync" or something - need to work out the exact format but it will be simple and probably like the udev rules. > This way, people that > cannot afford to get a corrupted partition from xattrs being written to a > partition that a NON-SE Linux OS must access can avoid damage. I'm not sure how to best work around the xattr issue and I'm wary at adding special casing code at the hal level for this - I'm more of the opinion that this should be solved at the kernel level and I'm curious at what other people think. > >There is supposed to be a /media/cdrom mount point if you got a CD-ROM drive; > > OK, I don't see one. The following is from an earlier e-mail to the list that I > didn't get a chance to answer: > Right. > >This should work. What does 'udevinfo -r -q name -p /block/hdc' say? > > /dev/hdc > Looks good. > >Does running 'service haldaemon stop; udevstart; service > >haldaemon start' solve your problem? > > No. > [root at buildhost root]# ls /media/ > idedisk idedisk1 scsidisk scsidisk1 > > [root at buildhost root]# service haldaemon stop > Stopping HAL daemon: [FAILED] > [root at buildhost root]# udevstart > [root at buildhost root]# service haldaemon start > Starting HAL daemon: [ OK ] > /etc/init.d/haldaemon: line 31: /var/run/hald/pid: No such file or directory > > >Otherwise you need to file a bug against hal to we can fix it > > Does the above look like a bug? If so I will file one. > It indeed looks like hald crashed - haven't seen that in some time though :-). Yes, please submit a bug report; I wrote down some information about what to capture here http://freedesktop.org/Software/HalTraces Many thanks, David From wtogami at redhat.com Sat Sep 11 09:21:19 2004 From: wtogami at redhat.com (Warren Togami) Date: Fri, 10 Sep 2004 23:21:19 -1000 Subject: dev rpm update problem In-Reply-To: <1094885390.15218.8.camel@localhost.localdomain> References: <1094885390.15218.8.camel@localhost.localdomain> Message-ID: <4142C38F.9060503@redhat.com> Mircea MITU wrote: >>I get this error when updating to dev-3.11-1: >> >>Cannot install the dev package: mounted devfs detected. >>error: %pre(dev-3.11-1) scriptlet failed, exit status 1 >>error: install: %pre scriptlet failed (2), skipping dev-3.11-1 >> >>I know this was happening previously with the MAKEDEV rpm, but it seems >>like it was solved in that case (by removing the %pre script?). >> >>Anyway, how do I upgrade the package? Is this a bug? > > > I had the same problem but upgrading from dev-3.11-1 to dev-3.12-1 > > The pre-install script of the rpm is looking for devfs into /proc/mounts > and it founds none /dev tmpfs rw 0 0 > What I'm wondering is, why doesn't the people working on udev in the distribution realize this is a problem? Is their configuration non-default and they are not hitting this problem like everyone else? Warren From russell at coker.com.au Sat Sep 11 09:34:19 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 11 Sep 2004 19:34:19 +1000 Subject: /dev/dri/* and SE Linux Message-ID: <200409111934.19937.russell@coker.com.au> In the latest CVS SE Linux policy xserver_macros.te has: # Create and access /dev/dri devices. allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; allow $1_xserver_t dri_device_t:chr_file create_file_perms; [...] # Do not flood audit logs due to device node creation attempts. dontaudit $1_xserver_t device_t:chr_file create; [...] allow $1_xserver_t device_t:dir { create }; It seems that the first and second sections don't work well together. Since we changed /dev/dri to have type device_t instead of dri_device_t it seems that attempts to create /dev/dri/whatever will be permitted on the device_t:dir access but dontaudit'd on the device_t:chr_file access. Does it even make sense to allow creating device nodes under /dev/dri now that we have udev doing so much? Can't udev do this for us? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From paul at icdw.co.uk Sat Sep 11 09:39:16 2004 From: paul at icdw.co.uk (Paul Trippett) Date: Sat, 11 Sep 2004 10:39:16 +0100 Subject: vsftpd.conf In-Reply-To: <20040911054206.GB10610@angus.ind.WPI.EDU> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> Message-ID: <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> On Sat, 2004-09-11 at 06:42, Charles R. Anderson wrote: > Not really...I think he makes a very valid point that allowing trusted > users to login via FTP is worse than allowing anonymous users FTP > access. FTP should only ever be used in anonymous mode, like HTTP > servers are mostly used for. If you don't what that, don't enable the > service. yes, it is best practise but how many companies use FTP on there internal network "in a controlled enviroment" to put data onto internal web/ftp/email etc servers. This number has to outway the number of companies running known anonymous ftp servers. Linux is being used more an more in internal company networks where anonymous ftp to servers would not be wanted. /pt From lfarkas at bppiac.hu Sat Sep 11 10:57:26 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sat, 11 Sep 2004 12:57:26 +0200 Subject: mysql 4.0.21 and it's dependencies in FC3? Message-ID: <4142DA16.9010808@bppiac.hu> hi, i know it has a long discussion in many redhat list, but since yesterday there is a new situation. after the first mysql released in the 4.x series which contains the foss license exception and that was the main reason why not included in any redhat/fedora ditro. is there any chance to get mysql 4.0.21 into fc3? or is it too late now? of course this means all other packages which depend on mysql should have to rebuild also. yours -- Levente "Si vis pacem para bellum!" From buildsys at redhat.com Sat Sep 11 11:29:13 2004 From: buildsys at redhat.com (Build System) Date: Sat, 11 Sep 2004 07:29:13 -0400 Subject: rawhide report: 20040911 changes Message-ID: <200409111129.i8BBTD930128@porkchop.devel.redhat.com> Updated Packages: crypto-utils-2.1-1 ------------------ * Fri Sep 10 2004 Joe Orton 2.1-1 - add /usr/bin/certwatch - support --days argument to genkey (#131045) desktop-backgrounds-2.0-22 -------------------------- * Thu Sep 09 2004 Elliot Lee 2.0-22 - Update the default background. devlabel-0.48.03-5 ------------------ * Thu Sep 09 2004 Bill Nottingham 0.48.03-5 - fix typo in filelist dhcp-3.0.1-8 ------------ * Fri Sep 10 2004 Jason Vas Dias 7:3.0.1-8 - Fix bug 131212: - If "deny booting" is defined for some group of hosts, - then after one of those hosts is denied booting, all - hosts are denied booting, because of a pointer not being - cleared in the lease record. - An upstream patch was obtained which will be in dhcp-3.0.2 . * Mon Aug 16 2004 Jason Vas Dias 7:3.0.1-7 - Forward DNS update by client was disabled by a bug that I - found in code where 'client->sent_options' was being - freed too early. - Re-enabled it after contacting upstream maintainer - who confirmed that this was a bug (bug #130069) - - submitted patch dhcp-3.0.1.preserve-sent-options.patch. - Upstream maintainer informs me this patch will be in dhcp-3.0.2 . * Tue Aug 03 2004 Jason Vas Dias 6:3.0.1-6 - Allow 2.0 kernels to obtain default gateway via dhcp esound-0.2.35-2 --------------- * Tue Sep 07 2004 John (J5) Palmieri - Add 64bit_install patch to make the LD_PRELOAD does not refrence different directories on a 64bit install. This causes parallel install errors. firstboot-1.3.23-1 ------------------ * Fri Sep 10 2004 Adrian Likins - 1.3.23-1 - fix for finish screen - ignore modules that throw exceptions on import (#129532 and other variations of "firstboot doesnt start) imlib-1.9.13-21 --------------- * Thu Sep 09 2004 Matthias Clasen - security fixes initscripts-7.80-1 ------------------ * Fri Sep 10 2004 Bill Nottingham - 7.80-1 - fix IPv6 6to4 & NAT (#118928, , ) * Fri Sep 10 2004 Karsten Hopp - 7.79-1 - load ctc device config after /etc/sysconfig/network so that GATEWAY doesn't get overwritten lha-1.14i-17 ------------ * Fri Sep 10 2004 Than Ngo 1.14i-17 - security vulnerabilities CAN-2004-0769, CAN-2004-0771, CAN-2004-0694, CAN-2004-0745 libgda-1.0.4-2 -------------- * Thu Sep 09 2004 Bill Nottingham 1:1.0.4-2 - %defattr mkinitrd-4.1.11-1 ----------------- * Fri Sep 10 2004 Jeremy Katz - 4.1.11-1 - more fixing nautilus-2.7.92-3 ----------------- * Fri Sep 10 2004 Alexander Larsson - 2.7.92-3 - Don't require eject on s390(x), since there is none (#132228) * Tue Sep 07 2004 Alexander Larsson - 2.7.92-2 - Add patch to fix desktop keynav (#131894) openswan-2.1.4-6 ---------------- * Thu Sep 09 2004 Bill Nottingham - 2.1.4-6 - don't run by default - don't create/chmod directories in %post, just include them with the right perms - fix debuginfo - fix docs php-4.3.8-11 ------------ * Thu Sep 09 2004 Joe Orton 4.3.8-11 - don't use --with-regex=system, it's ignored for apache* SAPIs privoxy-3.0.3-5 --------------- * Thu Sep 09 2004 Bill Nottingham 3.0.3-5 - don't run by default (again :) ) quagga-0.96.5-2 --------------- * Thu Sep 09 2004 Bill Nottingham 0.96.5-2 - don't run by default rpmdb-fedora-2.91-0.20040911 ---------------------------- selinux-policy-strict-1.17.12-1 ------------------------------- * Thu Sep 09 2004 Dan Walsh 1.17.12-1 - Add media context file - Add ncsd.te to targeted policy selinux-policy-targeted-1.17.12-1 --------------------------------- * Thu Sep 09 2004 Dan Walsh 1.17.12-1 - Add media context file - Add ncsd.te to targeted policy ttmkfdir-3.0.9-14 ----------------- * Fri Sep 10 2004 Yu Shao 3.0.9-14 - bug #100560, requires zlib-devel rather than zlib udev-030-24 ----------- * Fri Sep 10 2004 Harald Hoyer - 030-24 - check if SELINUX is not disabled before executing setfiles (bug 132099) yp-tools-2.8-7 -------------- * Fri Sep 10 2004 Steve Dickson - removed the call to yp_master() since the better fix was to make ypserv return the error status in a way that the client notices it. * Tue Aug 31 2004 Steve Dickson - Added a yp_master() call to ypcat so the existance of that map can be determined and the correct error can be returned when it does not. (bz 124557) From kms at passback.co.uk Sat Sep 11 11:36:24 2004 From: kms at passback.co.uk (Keith Sharp) Date: Sat, 11 Sep 2004 12:36:24 +0100 Subject: mysql 4.0.21 and it's dependencies in FC3? In-Reply-To: <4142DA16.9010808@bppiac.hu> References: <4142DA16.9010808@bppiac.hu> Message-ID: <1094902584.7683.2.camel@animal> On Sat, 2004-09-11 at 12:57 +0200, Farkas Levente wrote: > hi, > i know it has a long discussion in many redhat list, but since yesterday > there is a new situation. after the first mysql released in the 4.x > series which contains the foss license exception and that was the main > reason why not included in any redhat/fedora ditro. is there any chance > to get mysql 4.0.21 into fc3? or is it too late now? of course this > means all other packages which depend on mysql should have to rebuild also. > yours See this thread from fedora-test (ignore the MySQL vs PostgreSQL flames): http://www.redhat.com/archives/fedora-test-list/2004-September/msg00377.html Looks like FC4 at the earliest. Keith. From warren at togami.com Sat Sep 11 11:45:51 2004 From: warren at togami.com (Warren Togami) Date: Sat, 11 Sep 2004 01:45:51 -1000 Subject: mysql 4.0.21 and it's dependencies in FC3? In-Reply-To: <4142DA16.9010808@bppiac.hu> References: <4142DA16.9010808@bppiac.hu> Message-ID: <4142E56F.8010308@togami.com> Farkas Levente wrote: > hi, > i know it has a long discussion in many redhat list, but since yesterday > there is a new situation. after the first mysql released in the 4.x > series which contains the foss license exception and that was the main > reason why not included in any redhat/fedora ditro. is there any chance > to get mysql 4.0.21 into fc3? or is it too late now? of course this > means all other packages which depend on mysql should have to rebuild also. > yours > RH's legal opinion was that even the latest FOSS exception was problematic. Last I heard RH legal is in direct communication with MySQL to attempt to resolve this. It remains to be seen if we will be able to ship MySQL 4.x with FC3. I certainly hope so... Warren From fedora at wir-sind-cool.org Sat Sep 11 11:52:59 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 11 Sep 2004 13:52:59 +0200 Subject: rawhide report: 20040911 changes In-Reply-To: <200409111129.i8BBTD930128@porkchop.devel.redhat.com> References: <200409111129.i8BBTD930128@porkchop.devel.redhat.com> Message-ID: <20040911135259.2ea03527.fedora@wir-sind-cool.org> On Sat, 11 Sep 2004 07:29:13 -0400, Build System wrote: > ttmkfdir-3.0.9-14 > ----------------- > * Fri Sep 10 2004 Yu Shao 3.0.9-14 > > - bug #100560, requires zlib-devel rather than zlib "You are not authorized to access bug #100560." Does the new package "Requires: zlib-devel" or did it require zlib-devel before and was changed to require zlib instead? In case it depends on zlib-devel that would be strange and indicates that zlib is dlopened by ttmkfdir or something like that and a patch should be applied instead to fix that. -- Fedora Core release 2 (Tettnang) - Linux 2.6.7-1.494.2.2 loadavg: 1.19 1.14 1.05 From jakub at redhat.com Sat Sep 11 11:56:09 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 11 Sep 2004 07:56:09 -0400 Subject: rawhide report: 20040911 changes In-Reply-To: <20040911135259.2ea03527.fedora@wir-sind-cool.org> References: <200409111129.i8BBTD930128@porkchop.devel.redhat.com> <20040911135259.2ea03527.fedora@wir-sind-cool.org> Message-ID: <20040911115609.GI31909@devserv.devel.redhat.com> On Sat, Sep 11, 2004 at 01:52:59PM +0200, Michael Schwendt wrote: > On Sat, 11 Sep 2004 07:29:13 -0400, Build System wrote: > > > ttmkfdir-3.0.9-14 > > ----------------- > > * Fri Sep 10 2004 Yu Shao 3.0.9-14 > > > > - bug #100560, requires zlib-devel rather than zlib > > "You are not authorized to access bug #100560." > > Does the new package "Requires: zlib-devel" or did it require > zlib-devel before and was changed to require zlib instead? In case it > depends on zlib-devel that would be strange and indicates that zlib is > dlopened by ttmkfdir or something like that and a patch should be > applied instead to fix that. The %changelog entry is misleading, this rpm changed BuildRequires, not Requires. Jakub From al at casa.org.ro Sat Sep 11 12:52:04 2004 From: al at casa.org.ro (Alin Osan) Date: Sat, 11 Sep 2004 15:52:04 +0300 Subject: yum and local cache In-Reply-To: <604aa79104091014153b7df02a@mail.gmail.com> References: <007401c49746$3325d9c0$4801a8c0@C515816A> <200409102310.29763.al@casa.org.ro> <604aa79104091014153b7df02a@mail.gmail.com> Message-ID: <200409111552.04739.al@casa.org.ro> On Sat September 11 2004 00:15, Jeff Spaleta wrote: > yum install barapp foolib What version of yum do you have? With yum-2.1.3-1 you don't get any headers, just repomd.xml and primary.xml.gz. And the error was reported doing an update of the rawhide (development) version from an official Fedora development mirror. > to recap..... > if yum errors out due to a conflict NO PACKAGES WERE DOWNLOADED. > yum downloads headers from the packages during depresolution. > Packages are only downloaded if depresolution clears successfully. > you are NOT seeing redownloading of anything. > The cache IS working, the header files in the cache ARE being reused. No, it's not. The test is irrelevant, as, I believe, it was not done with the version of yum that caused the problems. It definitely downloads the rpm packages again if you have an error (conflict) like I had, I checked this on two separat machines, I even checked with tcpdump to see the real volume of traffic, it took me almoust 2 hours to download all the updated packages, it stoped with the error that I have described before, manually fixed the conflict and then it took me another 2 hours to download all the packages again. I don't know why is so hard to believe it. Do I need to add my system engineer signature? ;-) -- -- Alin Osan From jspaleta at gmail.com Sat Sep 11 14:21:12 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Sep 2004 10:21:12 -0400 Subject: First boot with 20040908 changes In-Reply-To: <1094888039.18143.15.camel@localhost.localdomain> References: <20040910172742.75076.qmail@web50610.mail.yahoo.com> <1094888039.18143.15.camel@localhost.localdomain> Message-ID: <604aa7910409110721365ab605@mail.gmail.com> On Sat, 11 Sep 2004 09:33:58 +0200, David Zeuthen wrote: > Maintaining mountpoints == maintaining /etc/fstab. There will be a > configuration for fstab-sync to specify whether a drive or media should > be ignored. So you'll be able to say something like > > block.device="/dev/hda7", ignore > storage.serial="CLP225F2G3UR4A", ignore > block.device="/dev/hda2", mount_point="/mnt/my_own_mount_point" > volume.label="CANON_DC", mount_point="/mnt/my_camera", options="noauto,user,exec,noatime,sync" > > or something - need to work out the exact format but it will be simple > and probably like the udev rules. sweeeeeeeeet being able to pre-define what the mountpoints will be called would be nice for specific devices. Being able to set an ignore policy for all devices or for ranges of devices would be good too. Should I open up an RFE in bugzilla with more specific ideas fro fstab-sync configuratrion? -jef From al at casa.org.ro Sat Sep 11 15:22:00 2004 From: al at casa.org.ro (Alin Osan) Date: Sat, 11 Sep 2004 18:22:00 +0300 Subject: yum and local cache In-Reply-To: <604aa79104091014153b7df02a@mail.gmail.com> References: <007401c49746$3325d9c0$4801a8c0@C515816A> <200409102310.29763.al@casa.org.ro> <604aa79104091014153b7df02a@mail.gmail.com> Message-ID: <200409111822.00128.al@casa.org.ro> On Sat September 11 2004 00:15, Jeff Spaleta wrote: > to recap..... > if yum errors out due to a conflict NO PACKAGES WERE DOWNLOADED. > yum downloads headers from the packages during depresolution. > Packages are only downloaded if depresolution clears successfully. > you are NOT seeing redownloading of anything. > The cache IS working, the header files in the cache ARE being reused. You may be right, I tried to reproduce the error, I have the same situation you described and after a second yum -y update does not download anything again, like it happend to me before. I can't reproduce it, since I can't revert to an older development version and then do the update. The info I gave to Seth was from the console's buffer, I don't have it anymore... I'll go thru yum sources when I'll have the time and I'll see if I'll come up with something. I've been suggested by someone who runs this list that fedora-test-list is more appropriate for this, so I'll continue on that list if something has to add up. Thank you, guys, you're the best. -- -- Alin Osan From mlauterbach at mail.wtamu.edu Sat Sep 11 17:02:48 2004 From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach) Date: Sat, 11 Sep 2004 12:02:48 -0500 Subject: Another FC3test2 candidate tree In-Reply-To: <20040911160005.477C473B24@hormel.redhat.com> References: <20040911160005.477C473B24@hormel.redhat.com> Message-ID: <1094922168.5728.25.camel@mccaslin-138.wtamu.edu> On Wed, Sep 08, 2004 at 10:08:11PM -0400, Elliot Lee wrote: > The previous bug reports on the re0903.0 tree were very helpful - > here's another one to chew on: > > http://fedora.linux.duke.edu/FC3-re0908.0/ A clean "everything" install of i386 version of re0908.0 on an x86_64 had the following problems: - Doesn't see my SATA drive at all (worked fine with FC2 clean install) during install or on subsequent boots. dmesg says it is seeing the controller just not the drive. - Firstboot failed. Threw some python errors. Didn't catch what they said and not recorded in boot.log. Are these known problems or do you need me to post bugreports? I'm about to download and install the x86_64 version alongside this one now. Matt From ville.skytta at iki.fi Sat Sep 11 17:09:44 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 11 Sep 2004 20:09:44 +0300 Subject: kernel module fs permissions Message-ID: <1094922583.3284.60.camel@bobcat.mine.nu> Is there another reason besides rpm automagic stripping (+ laziness or something like that in not resetting to 644 in the specfile later) for all *.ko to be executable by root (mode 744) in the kernel package? From arjanv at redhat.com Sat Sep 11 17:39:43 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 11 Sep 2004 19:39:43 +0200 Subject: kernel module fs permissions In-Reply-To: <1094922583.3284.60.camel@bobcat.mine.nu> References: <1094922583.3284.60.camel@bobcat.mine.nu> Message-ID: <1094924383.7456.1.camel@laptop.fenrus.com> On Sat, 2004-09-11 at 19:09, Ville Skytt? wrote: > Is there another reason besides rpm automagic stripping (+ laziness or > something like that in not resetting to 644 in the specfile later) for > all *.ko to be executable by root (mode 744) in the kernel package? well..... the stripping happens during the final rpmbuild stage; I don't have scripts running after that, it's pure RPM itself from that point on but other than the strip-to-file there is no reason indeed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Sat Sep 11 18:23:15 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 11 Sep 2004 21:23:15 +0300 Subject: kernel module fs permissions In-Reply-To: <1094924383.7456.1.camel@laptop.fenrus.com> References: <1094922583.3284.60.camel@bobcat.mine.nu> <1094924383.7456.1.camel@laptop.fenrus.com> Message-ID: <1094926995.3284.71.camel@bobcat.mine.nu> On Sat, 2004-09-11 at 20:39, Arjan van de Ven wrote: > On Sat, 2004-09-11 at 19:09, Ville Skytt? wrote: > > Is there another reason besides rpm automagic stripping (+ laziness or > > something like that in not resetting to 644 in the specfile later) for > > all *.ko to be executable by root (mode 744) in the kernel package? [Apologies, this sounded more foul than it was supposed to...] > well..... the stripping happens during the final rpmbuild stage; I don't > have scripts running after that, it's pure RPM itself from that point on You can always "reset" the attributes using %attr in %files. One solution would be to create a file list during the "find" in BuildKernel(), and use that later on, something like this (definitely incomplete and buggy, but just to throw in the idea): rm %{name}-%{version}-%{release}.files for file in find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f ; do chmod u+x $file echo $file | sed "s|^$RPM_BUILD_ROOT|%attr(644,root,root) |" \ >> %{name}-%{version}-%{release}.files done # Add similar stuff to handle dirs and files other than "*.ko" in # $RPM_BUILD_ROOT/lib/modules/$KernelVer here [...] %files -f %{name}-%{version}.files > but other than the strip-to-file there is no reason indeed Ok, thanks for the confirmation. From linux_4ever at yahoo.com Sat Sep 11 18:33:02 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 11 Sep 2004 11:33:02 -0700 (PDT) Subject: First boot with 20040908 changes In-Reply-To: <1094888039.18143.15.camel@localhost.localdomain> Message-ID: <20040911183302.45376.qmail@web50605.mail.yahoo.com> >> Can you detect a ext3 drive that doesn't have xattrs applied? If so, the work >> around is not to write anything related to xattrs to that drive. > >It sounds to me like this should be fixed in the kernel. Agreed. A solution in the kernel would be ideal. However, I cannot assume that will ever happen. I am looking for a work around that prevents the problem from occurring in the first place. I think it can be done by simply not having enough info available for automounting programs to "connect the dots". >>>I'm not sure how well turning off media detection works presently >> >> Something changed after yesterday's updates. I set everything to false >> yesterday and there were no entries in /media and fstab. Today they >> are there. I found this problem. My shell script didn't provide quotes to the xml attribute tags. parse error. This all works fine. >Maintaining mountpoints == maintaining /etc/fstab. There will be a >configuration for fstab-sync to specify whether a drive or media should >be ignored. So you'll be able to say something like > > block.device="/dev/hda7", ignore > storage.serial="CLP225F2G3UR4A", ignore > block.device="/dev/hda2", mount_point="/mnt/my_own_mount_point" > volume.label="CANON_DC", mount_point="/mnt/my_camera", > options="noauto,user,exec,noatime,sync" It would be nice if the syntax was awk or bash friendly. I plan to write a configuration tool for this in the ccs tools. >I'm not sure how to best work around the xattr issue and I'm wary at >adding special casing code at the hal level for this - I'm more of the >opinion that this should be solved at the kernel level and I'm curious >at what other people think. Maybe the above syntax will be enough for a work around. That's all I'm after for the short term. Where are these config files to be kept? /etc or /usr? If /usr, be sure to test on a computer that has /usr on a separate partition. I also wonder how well it works from a nash shell when something blows up during boot. :) With the xattr oops problem affecting me everyday, I'm sure I'll find out... 2 bugzilla reports were filed for hal. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From arjanv at redhat.com Sat Sep 11 19:03:59 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 11 Sep 2004 21:03:59 +0200 Subject: kernel module fs permissions In-Reply-To: <1094926995.3284.71.camel@bobcat.mine.nu> References: <1094922583.3284.60.camel@bobcat.mine.nu> <1094924383.7456.1.camel@laptop.fenrus.com> <1094926995.3284.71.camel@bobcat.mine.nu> Message-ID: <1094929438.7456.6.camel@laptop.fenrus.com> On Sat, 2004-09-11 at 20:23, Ville Skytt? wrote: > On Sat, 2004-09-11 at 20:39, Arjan van de Ven wrote: > > On Sat, 2004-09-11 at 19:09, Ville Skytt? wrote: > > > Is there another reason besides rpm automagic stripping (+ laziness or > > > something like that in not resetting to 644 in the specfile later) for > > > all *.ko to be executable by root (mode 744) in the kernel package? > > [Apologies, this sounded more foul than it was supposed to...] > > > well..... the stripping happens during the final rpmbuild stage; I don't > > have scripts running after that, it's pure RPM itself from that point on > > You can always "reset" the attributes using %attr in %files. One > solution would be to create a file list during the "find" in > BuildKernel(), and use that later on, something like this (definitely > incomplete and buggy, but just to throw in the idea): ok now it's my turn .. ;-) is having the modules executable an actual problem? If so in what scenario ? Before going down a semi complex and probably somewhat fragile road I'd like to be sure there's a real problem getting fixed by something like this and not just something cosmetical... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kyrre at solution-forge.net Sat Sep 11 20:13:08 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 11 Sep 2004 22:13:08 +0200 Subject: vsftpd.conf In-Reply-To: <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> Message-ID: <1094933588.2715.10.camel@kyrre> ... And if you want anonymous logins, you WILL notice it if it dont work. Same goes to user-logins. So why not simply disable both in the standard-config-file (effectively making the server unusable until someone have changed the config), and include comments telling how to enable it? One common use case for non-anonymous ftp is file uppload to a web-hotel - as most users either dont know about or dont care about more secure ways. And those have mostly disabled ssh logins. l?r, 11.09.2004 kl. 11.39 skrev Paul Trippett: > On Sat, 2004-09-11 at 06:42, Charles R. Anderson wrote: > > Not really...I think he makes a very valid point that allowing trusted > > users to login via FTP is worse than allowing anonymous users FTP > > access. FTP should only ever be used in anonymous mode, like HTTP > > servers are mostly used for. If you don't what that, don't enable the > > service. > > yes, it is best practise but how many companies use FTP on there > internal network "in a controlled enviroment" to put data onto internal > web/ftp/email etc servers. This number has to outway the number of > companies running known anonymous ftp servers. Linux is being used more > an more in internal company networks where anonymous ftp to servers > would not be wanted. > > /pt > From ville.skytta at iki.fi Sat Sep 11 20:52:11 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 11 Sep 2004 23:52:11 +0300 Subject: kernel module fs permissions In-Reply-To: <1094929438.7456.6.camel@laptop.fenrus.com> References: <1094922583.3284.60.camel@bobcat.mine.nu> <1094924383.7456.1.camel@laptop.fenrus.com> <1094926995.3284.71.camel@bobcat.mine.nu> <1094929438.7456.6.camel@laptop.fenrus.com> Message-ID: <1094935931.3284.106.camel@bobcat.mine.nu> On Sat, 2004-09-11 at 22:03, Arjan van de Ven wrote: > is having the modules executable an actual problem? AFAICT it's the same problem or non-problem as with any file out there if a file that is not meant to be executable has executable bits set. But I believe it's pretty much cosmetic in this case. The reason I was asking are separate extra kernel module packages; in those it's usually trivial to tune the permissions to be "correct" and still have rpm auto-strip them. Or at least more trivial than in the actual kernel package as currently implemented. From kyrre at solution-forge.net Sat Sep 11 21:26:48 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 11 Sep 2004 23:26:48 +0200 Subject: Midi-player for FC - an will there be anyone in FC3? Message-ID: <1094938008.2715.59.camel@kyrre> Hmm... Does anybody know why Fedora haven't included a simple midi-player, which simply sends things to your soundcard for rendering, which in turn plays it?? And does anybody know about a good such program? Kyrre Ness Sj?b?k From janina at rednote.net Sat Sep 11 23:11:20 2004 From: janina at rednote.net (Janina Sajka) Date: Sat, 11 Sep 2004 19:11:20 -0400 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <1094938008.2715.59.camel@kyrre> References: <1094938008.2715.59.camel@kyrre> Message-ID: <20040911231120.GF4297@rednote.net> Kyrre Ness Sjobak writes: > Hmm... Does anybody know why Fedora haven't included a simple > midi-player, which simply sends things to your soundcard for rendering, > which in turn plays it?? And does anybody know about a good such > program? > Huh? Did timidity++ disappear? Or, am I misunderstanding your question? [root at concerto 19:07:32] root#rpm -qi timidity++ Name : timidity++ Relocations: (not relocatable) Version : 2.11.3 Vendor: Red Hat, Inc. Release : 9 Build Date: Tue 17 Feb 2004 03:13:56 AM EST Install Date: Tue 20 Jul 2004 06:13:03 PM EDT Build Host: romaine.build.redhat.com Group : Applications/Multimedia Source RPM: timidity++-2.11.3-9.src.rpm Size : 10659100 License: GPL Signature : DSA/SHA1, Thu 06 May 2004 06:20:44 PM EDT, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. URL : http://www.onicos.com/staff/iz/timidity/ Summary : A software wavetable MIDI synthesizer. Description : TiMidity++ is a MIDI format to wave table format converter and player. Install timitidy++ if you'd like to play MIDI files and your sound card does not natively support wave table format. > Kyrre Ness Sj?b?k > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Chair Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org Phone: +1 202.494.7040 From paul at icdw.co.uk Sat Sep 11 23:18:37 2004 From: paul at icdw.co.uk (Paul Trippett) Date: Sun, 12 Sep 2004 00:18:37 +0100 Subject: vsftpd.conf In-Reply-To: <1094933588.2715.10.camel@kyrre> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> Message-ID: <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> Why not take a BSD approach and give them the option when installing the package, say for example... # rpm -i vsftp....rpm Would you like to enable Anonymous logins? (y/n) [N] Would you like to enable Local user Logins? (y/n) [N] Copying relevant base configuration file.... Done. Anonymous/User logins have been enabled if at a later date you would like to change this behaviour you can do so by editing /etc/vsftpd.conf # /pt On Sat, 2004-09-11 at 21:13, Kyrre Ness Sjobak wrote: > ... And if you want anonymous logins, you WILL notice it if it dont > work. Same goes to user-logins. So why not simply disable both in the > standard-config-file (effectively making the server unusable until > someone have changed the config), and include comments telling how to > enable it? > > One common use case for non-anonymous ftp is file uppload to a web-hotel > - as most users either dont know about or dont care about more secure > ways. And those have mostly disabled ssh logins. > > l?r, 11.09.2004 kl. 11.39 skrev Paul Trippett: > > On Sat, 2004-09-11 at 06:42, Charles R. Anderson wrote: > > > Not really...I think he makes a very valid point that allowing trusted > > > users to login via FTP is worse than allowing anonymous users FTP > > > access. FTP should only ever be used in anonymous mode, like HTTP > > > servers are mostly used for. If you don't what that, don't enable the > > > service. > > > > yes, it is best practise but how many companies use FTP on there > > internal network "in a controlled enviroment" to put data onto internal > > web/ftp/email etc servers. This number has to outway the number of > > companies running known anonymous ftp servers. Linux is being used more > > an more in internal company networks where anonymous ftp to servers > > would not be wanted. > > > > /pt > > > From kyrre at solution-forge.net Sat Sep 11 23:20:11 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 12 Sep 2004 01:20:11 +0200 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <20040911231120.GF4297@rednote.net> References: <1094938008.2715.59.camel@kyrre> <20040911231120.GF4297@rednote.net> Message-ID: <1094944811.4796.7.camel@kyrre> s?n, 12.09.2004 kl. 01.11 skrev Janina Sajka: > Kyrre Ness Sjobak writes: > > Hmm... Does anybody know why Fedora haven't included a simple > > midi-player, which simply sends things to your soundcard for rendering, > > which in turn plays it?? And does anybody know about a good such > > program? > > > Huh? Did timidity++ disappear? Or, am I misunderstanding your question? > > [root at concerto 19:07:32] root#rpm -qi timidity++ > Name : timidity++ Relocations: (not > relocatable) > Version : 2.11.3 Vendor: Red Hat, Inc. > Release : 9 Build Date: Tue 17 Feb 2004 > 03:13:56 AM EST > Install Date: Tue 20 Jul 2004 06:13:03 PM EDT Build Host: > romaine.build.redhat.com > Group : Applications/Multimedia Source RPM: > timidity++-2.11.3-9.src.rpm > Size : 10659100 License: GPL > Signature : DSA/SHA1, Thu 06 May 2004 06:20:44 PM EDT, Key ID > b44269d04f2a6fd2 > Packager : Red Hat, Inc. > URL : http://www.onicos.com/staff/iz/timidity/ > Summary : A software wavetable MIDI synthesizer. > Description : > TiMidity++ is a MIDI format to wave table format converter and > player. Install timitidy++ if you'd like to play MIDI files and your > sound card does not natively support wave table format. > > > Kyrre Ness Sj?b?k > > > > Hmm... what if i (as many others) are so lucky to have a HW-based midi-playing soundcard (such as the AWE 64)? Methinks maybe they wants to use it... Could it be possible to do something like MS does - in the gstreamer setup, give an option to either use timidity (with a full patchset - the patches included don't even rival my old SB16, and there is (as far as i have heard) plenty of space on cd4...) - or HW sequencer (including external) - if aviable. Then any app using gst (ex. rythmbox) could easyly play .mid. But another thing - when i move my mouse over some music-file in nautilus - it displays a little note in a speak-bubble. Is it meant that nautilus should preweiv them that way? Seems like a good idea, but its not working... Kyrre From kyrre at solution-forge.net Sat Sep 11 23:21:41 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 12 Sep 2004 01:21:41 +0200 Subject: vsftpd.conf In-Reply-To: <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> Message-ID: <1094944900.4796.10.camel@kyrre> That would make script-based instalation impossible. So putting a script which ask questions during installation inside the rpm is a BAD idea. s?n, 12.09.2004 kl. 01.18 skrev Paul Trippett: > Why not take a BSD approach and give them the option when installing the > package, say for example... > > # rpm -i vsftp....rpm > Would you like to enable Anonymous logins? (y/n) [N] > Would you like to enable Local user Logins? (y/n) [N] > > Copying relevant base configuration file.... Done. > > Anonymous/User logins have been enabled if at a later date you would > like to change this behaviour you can do so by editing /etc/vsftpd.conf > > # > > /pt > > On Sat, 2004-09-11 at 21:13, Kyrre Ness Sjobak wrote: > > ... And if you want anonymous logins, you WILL notice it if it dont > > work. Same goes to user-logins. So why not simply disable both in the > > standard-config-file (effectively making the server unusable until > > someone have changed the config), and include comments telling how to > > enable it? > > > > One common use case for non-anonymous ftp is file uppload to a web-hotel > > - as most users either dont know about or dont care about more secure > > ways. And those have mostly disabled ssh logins. > > > > l?r, 11.09.2004 kl. 11.39 skrev Paul Trippett: > > > On Sat, 2004-09-11 at 06:42, Charles R. Anderson wrote: > > > > Not really...I think he makes a very valid point that allowing trusted > > > > users to login via FTP is worse than allowing anonymous users FTP > > > > access. FTP should only ever be used in anonymous mode, like HTTP > > > > servers are mostly used for. If you don't what that, don't enable the > > > > service. > > > > > > yes, it is best practise but how many companies use FTP on there > > > internal network "in a controlled enviroment" to put data onto internal > > > web/ftp/email etc servers. This number has to outway the number of > > > companies running known anonymous ftp servers. Linux is being used more > > > an more in internal company networks where anonymous ftp to servers > > > would not be wanted. > > > > > > /pt > > > > > > From elanthis at awesomeplay.com Sat Sep 11 23:25:11 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 11 Sep 2004 19:25:11 -0400 Subject: vsftpd.conf In-Reply-To: <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> Message-ID: <1094945111.27052.6.camel@stargrazer> On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote: > Why not take a BSD approach and give them the option when installing the > package, say for example... > > # rpm -i vsftp....rpm > Would you like to enable Anonymous logins? (y/n) [N] > Would you like to enable Local user Logins? (y/n) [N] Because RPMs are absolutely never ever supposed to ask questions. - What if the RPM is being installed non-interactively? - What if the RPM is being installed with a GUI tool? - What if the user doesn't understand English? And then you get into the general usability problems - are the question phrased properly? Is "Y/N" an appropriate prompt? etc. Better to offer a nice GUI configuration utility and just let admins run it after the installation, or just edit the .conf file if they're of the mind. From jspaleta at gmail.com Sat Sep 11 23:25:36 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Sep 2004 19:25:36 -0400 Subject: vsftpd.conf In-Reply-To: <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> Message-ID: <604aa791040911162559eb0c60@mail.gmail.com> On Sun, 12 Sep 2004 00:18:37 +0100, Paul Trippett wrote: > Why not take a BSD approach and give them the option when installing the > package, say for example... > > # rpm -i vsftp....rpm > Would you like to enable Anonymous logins? (y/n) [N] > Would you like to enable Local user Logins? (y/n) [N] > > Copying relevant base configuration file.... Done. nope rpm packages as a design goal should be installable in an automated fashion packages that demand any interactiveness...are suboptimal across a wide range of situations. If you had ever done a kickstart install, would have never suggested this. -jef From smoogen at lanl.gov Sat Sep 11 23:38:05 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Sat, 11 Sep 2004 17:38:05 -0600 Subject: vsftpd.conf In-Reply-To: <1094945111.27052.6.camel@stargrazer> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> <1094945111.27052.6.camel@stargrazer> Message-ID: <41438C5D.2020609@lanl.gov> Sean Middleditch wrote: > On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote: > >>Why not take a BSD approach and give them the option when installing the >>package, say for example... >> >># rpm -i vsftp....rpm >>Would you like to enable Anonymous logins? (y/n) [N] >>Would you like to enable Local user Logins? (y/n) [N] > > > Because RPMs are absolutely never ever supposed to ask questions. > > - What if the RPM is being installed non-interactively? > - What if the RPM is being installed with a GUI tool? > - What if the user doesn't understand English? > > And then you get into the general usability problems - are the question > phrased properly? Is "Y/N" an appropriate prompt? etc. > Each rpm could then drop a scriptlet into a directory that gui would then be able to run to set things up for it. /etc/system-setup/ vsftpd.py httpd.py samba.py kill_my_harddrive.py And then the system-setup program would display the questions, get the answers... and possibly be able to bring the system into at least a bare-bones configuration. Reset to original configuration [Yes] [No] [Help] -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From jspaleta at gmail.com Sat Sep 11 23:39:43 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 11 Sep 2004 19:39:43 -0400 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <1094938008.2715.59.camel@kyrre> References: <1094938008.2715.59.camel@kyrre> Message-ID: <604aa791040911163927f5993a@mail.gmail.com> On Sat, 11 Sep 2004 23:26:48 +0200, Kyrre Ness Sjobak wrote: > Hmm... Does anybody know why Fedora haven't included a simple > midi-player, which simply sends things to your soundcard for rendering, > which in turn plays it?? And does anybody know about a good such > program? I think the fact that you have to ask the second question, points to a reason why you have to ask the first one. If you have the hardware and the interest in playing midi files, and you can't find an appropriate software for linux that fedora could evaluate for inclusion... that should tell you something about why its not included. here's how you can be proactive: Find software that works for what you need to do. File a bug report in bugzilla.redhat.com requesting its inclusion making a case that nothing so far in Core provides this functionality Create packages for the software and submit it for QA review at fedora.us if its not already there. A quick google gives me: http://mail.gnome.org/archives/gnome-multimedia/2003-December/msg00099.html http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-dependencies.html quote 3.6. Does GStreamer support MIDI ? Not yet. The GStreamer architecture should be able to support the needs of MIDI applications very well however. If you are a developer interested in adding MIDI support to GStreamer we are very interested in getting in touch with you. endquote Are you that developer? I think perhaps you can serve your own interests by communicating directly with the gstreamer developers. -jef From elanthis at awesomeplay.com Sat Sep 11 23:56:03 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 11 Sep 2004 19:56:03 -0400 Subject: vsftpd.conf In-Reply-To: <41438C5D.2020609@lanl.gov> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> <1094945111.27052.6.camel@stargrazer> <41438C5D.2020609@lanl.gov> Message-ID: <1094946963.27052.17.camel@stargrazer> On Sat, 2004-09-11 at 17:38 -0600, Stephen J Smoogen wrote: > Sean Middleditch wrote: > > On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote: > > > >>Why not take a BSD approach and give them the option when installing the > >>package, say for example... > >> > >># rpm -i vsftp....rpm > >>Would you like to enable Anonymous logins? (y/n) [N] > >>Would you like to enable Local user Logins? (y/n) [N] > > > > > > Because RPMs are absolutely never ever supposed to ask questions. > > > > - What if the RPM is being installed non-interactively? > > - What if the RPM is being installed with a GUI tool? > > - What if the user doesn't understand English? > > > > And then you get into the general usability problems - are the question > > phrased properly? Is "Y/N" an appropriate prompt? etc. > > > > Each rpm could then drop a scriptlet into a directory that gui would > then be able to run to set things up for it. > > /etc/system-setup/ > vsftpd.py > httpd.py > samba.py > kill_my_harddrive.py > > And then the system-setup program would display the questions, get the > answers... and possibly be able to bring the system into at least a > bare-bones configuration. > > Reset to original configuration [Yes] [No] [Help] Again, what if the configuration data isn't translated into the user's language? They end up getting some vital system configuration question they can't possibly answer? Why the heck does this *need* to be done at install time? If you are going to make a configuration tool, let the user run it them self after install. It shouldn't be required to ask questions to get a "bare bones" setup. If you want a system that asks a bazillion questions on install time, doesn't guarantee they'll be translated, doesn't guarantee they'll be phrased intelligibly, and has tons and tons of infrastructure developed and maintained instead of just good configuration tools and intelligent defaults, you should install the OS produced over at http://www.debian.org. For network services, there isn't any good reason at all for them to be enabled at install time. Have them disabled by default (Fedora/RHEL has a nice tool for enabling/disabling services even novices can use), and if the user doesn't like the defaults, they can change them. The .conf file is always there, and if that's Not Good Enough, a graphical tool that does a _lot_ more than ask some simplistic questions that probably don't cover many likely scenarios can be developed and delivered with the service. What happens with new/inexperienced users that just Install Everything? They'll get all these questions they probably don't understand. They'll likely end up answering all sorts of questions (and there will be a hell of a lot of them too, if you add this infrastructure - look at Debian) they don't understand, providing answers that are not ideal for their situation, etc. If the user needs the service, they can configure and enable it manually, and things will work for _everyone_ equally well. > > > > -- > Stephen John Smoogen | CCN-5 Security Team > LANL SIRT Team Leader | SMTP: smoogen at lanl.gov > Los Alamos National Laboratory | Voice: 505.664.0645 > Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 > Los Alamos, NM 87545 | > > From alan at redhat.com Sun Sep 12 00:12:30 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 11 Sep 2004 20:12:30 -0400 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <1094938008.2715.59.camel@kyrre> References: <1094938008.2715.59.camel@kyrre> Message-ID: <20040912001230.GA30393@devserv.devel.redhat.com> On Sat, Sep 11, 2004 at 11:26:48PM +0200, Kyrre Ness Sjobak wrote: > Hmm... Does anybody know why Fedora haven't included a simple > midi-player, which simply sends things to your soundcard for rendering, > which in turn plays it?? And does anybody know about a good such > program? timidity and midiplay seem to be the popular ones. From paul at icdw.co.uk Sun Sep 12 01:44:45 2004 From: paul at icdw.co.uk (Paul Trippett) Date: Sun, 12 Sep 2004 02:44:45 +0100 Subject: vsftpd.conf In-Reply-To: <1094946963.27052.17.camel@stargrazer> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> <1094945111.27052.6.camel@stargrazer> <41438C5D.2020609@lanl.gov> <1094946963.27052.17.camel@stargrazer> Message-ID: <1094953485.25682.48.camel@neuwklin.ad.icdw.co.uk> Dont you love it when you mention something at 1am without properly thinking something through :) However... > It shouldn't be required to ask questions to get a "bare bones" setup. I don't think we should rule out the large majority of people coming over from other OS's, these people being the "I know what I want to do and why I want to do it, but don't quite know how to do it". Realistically how often would you install a tcp service and leave it at that. How many times have you heard someone say "I installed Linux, now what do i do?" Some people may like being asked questions while others do not, but it doesn't hurt to give people the option. There must be quite a few uses for more generalised post install package configuration tool which isn't just limited to vsftpd and this thread. > If you want a system that asks a bazillion questions on install time, > doesn't guarantee they'll be translated, doesn't guarantee they'll be > phrased intelligibly, and has tons and tons of infrastructure developed > and maintained instead of just good configuration tools and intelligent > defaults, you should install the OS produced over at > http://www.debian.org. Last time I used apt on debian from the command line i remember it saying something along the lines of "The following packages need to be configured before the can be used, would you like to configure them now", not only does it tell you they need to be configured it also gives you the option to help you do it, nor does it break automated installs. Just like everything else Debian has its place and also has a pretty good "bare bones" install itself. I dont know why but not everyone likes trawling through man pages for half their waking day trying to get something to work. From elanthis at awesomeplay.com Sun Sep 12 02:05:03 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 11 Sep 2004 22:05:03 -0400 Subject: vsftpd.conf In-Reply-To: <1094953485.25682.48.camel@neuwklin.ad.icdw.co.uk> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> <1094945111.27052.6.camel@stargrazer> <41438C5D.2020609@lanl.gov> <1094946963.27052.17.camel@stargrazer> <1094953485.25682.48.camel@neuwklin.ad.icdw.co.uk> Message-ID: <1094954703.27052.31.camel@stargrazer> On Sun, 2004-09-12 at 02:44 +0100, Paul Trippett wrote: > Dont you love it when you mention something at 1am without properly > thinking something through :) > > However... > > > It shouldn't be required to ask questions to get a "bare bones" setup. > > I don't think we should rule out the large majority of people coming > over from other OS's, these people being the "I know what I want to do > and why I want to do it, but don't quite know how to do it". > Realistically how often would you install a tcp service and leave it at > that. Who cares what other OSes do? If your reason is "other OSes do it," your reason, for lack of a better term, sucks. ;-) > > How many times have you heard someone say "I installed Linux, now what > do i do?" "Documentation." ^_^ > > Some people may like being asked questions while others do not, but it > doesn't hurt to give people the option. There must be quite a few uses > for more generalised post install package configuration tool which isn't > just limited to vsftpd and this thread. Yes, actually, it *DOES* hurt people to give them the option. You have to ask questions about asking questions. You still end up with tons of questions that the user has no clue about or doesn't care about and, therefor, you get back answers that are most likely incorrect for what the user really wants. You add a lot of complication for little gain when other solutions exist. > > > If you want a system that asks a bazillion questions on install time, > > doesn't guarantee they'll be translated, doesn't guarantee they'll be > > phrased intelligibly, and has tons and tons of infrastructure developed > > and maintained instead of just good configuration tools and intelligent > > defaults, you should install the OS produced over at > > http://www.debian.org. > > Last time I used apt on debian from the command line i remember it > saying something along the lines of "The following packages need to be > configured before the can be used, would you like to configure them > now", not only does it tell you they need to be configured it also gives > you the option to help you do it, nor does it break automated installs. > Just like everything else Debian has its place and also has a pretty > good "bare bones" install itself. The debconf system has various priority levels for their questions. You are forced to answer a "what priority of question do you want to answer" question, and then lower-priority questions are ignored and a default answer is used. A number of packages, however, abuse this system heavily. The system also maps very poorly to a GUI. Packagers cannot craft a clean, usable GUI, but instead must specify questions in a rather abstract format so multiple frontends can handle it. They are forced to deal with a lowest common denominator that functions pretty poorly for every frontend. The priority system is also entirely broken in concept. What is important to one use is trivial to another. Many packages which are merely dependencies have questions which must be answered, which especially is confusing when they are pulled in due to some completely unrelated package. (Yes, dependency chains *will* do that, when packagers don't break up their packages appropriately, or application authors make it impossible to break up the packages.) When a novice user hits Install Everything, they get everything. Are they really expected to be able to answer all the questions that come up? Or do you expect the priority levels to give sensible defaults with the user being able to change things later? If you picked the latter (which you should've), then the question becomes, why the heck have the infrastructure to ask questions at install time anyhow, when you *already* have to ship a second solution and provide sensible defaults?? > > I dont know why but not everyone likes trawling through man pages for > half their waking day trying to get something to work. There are better forms of documentation than man pages. If you think the only options available are "ask questions at install" and "be a UNIX guru," you are failing to think of a ton of options in between. Fedora/RHEL already have some great server configuration utilities. A new user just has to go to System Settings to find them. Tools exist for Apache and Samba at least, and I know quite a few others exist. More can be added. Along with good, clean, user-oriented documentation. These solutions help both users during the initial install *and* helps them down the road when they need to update or modify their settings. Honestly, it isn't that much more "work" to install a package and click on its config utility than it is to install the package and have a half- assed config dialog popup. And the former solution solves far more problems in a much better fashion. > > From cmadams at hiwaay.net Sun Sep 12 02:49:48 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 11 Sep 2004 21:49:48 -0500 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <20040912001230.GA30393@devserv.devel.redhat.com> References: <1094938008.2715.59.camel@kyrre> <20040912001230.GA30393@devserv.devel.redhat.com> Message-ID: <20040912024948.GD1086333@hiwaay.net> Once upon a time, Alan Cox said: > On Sat, Sep 11, 2004 at 11:26:48PM +0200, Kyrre Ness Sjobak wrote: > > Hmm... Does anybody know why Fedora haven't included a simple > > midi-player, which simply sends things to your soundcard for rendering, > > which in turn plays it?? And does anybody know about a good such > > program? > > timidity and midiplay seem to be the popular ones. timidity renders in software with its own wavetable set - that's not what the OP asked about. It looks like midiplay is the same sort of thing, but it doesn't seem to have a home anymore. The nicer sound cards have hardware wavetable synthesizers, but there doesn't appear to be a way to use them much under Linux. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dragoran at feuerpokemon.de Sun Sep 12 11:15:52 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 12 Sep 2004 13:15:52 +0200 Subject: vsftpd.conf In-Reply-To: <1094945111.27052.6.camel@stargrazer> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> <1094945111.27052.6.camel@stargrazer> Message-ID: <41442FE8.4040402@feuerpokemon.de> Sean Middleditch schrieb: >On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote: > > >>Why not take a BSD approach and give them the option when installing the >>package, say for example... >> >># rpm -i vsftp....rpm >>Would you like to enable Anonymous logins? (y/n) [N] >>Would you like to enable Local user Logins? (y/n) [N] >> >> > >Because RPMs are absolutely never ever supposed to ask questions. > >- What if the RPM is being installed non-interactively? >- What if the RPM is being installed with a GUI tool? >- What if the user doesn't understand English? > >And then you get into the general usability problems - are the question >phrased properly? Is "Y/N" an appropriate prompt? etc. > >Better to offer a nice GUI configuration utility and just let admins run >it after the installation, or just edit the .conf file if they're of the >mind. > > > > Nobody set up a ftp server and leave the default config, so it doesn't really matter if anonymous logins are on by default or not. From kyrre at solution-forge.net Sun Sep 12 11:29:28 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 12 Sep 2004 13:29:28 +0200 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <20040912024948.GD1086333@hiwaay.net> References: <1094938008.2715.59.camel@kyrre> <20040912001230.GA30393@devserv.devel.redhat.com> <20040912024948.GD1086333@hiwaay.net> Message-ID: <1094988568.2653.106.camel@kyrre> I have tried playmidi - compiled for awe32 - and it played (at least it didn't return for the time the midi sequence lasted) - but no sound... I also found midiplay - but wasn't able to download it (exept the atari version, packed in a .zoo i dont (or at least fileroller dont) know how to open. http://www.hitsquad.com/smm/programs/midiplay_linux/ <- linux http://www.hitsquad.com/smm/programs/MIDIPlay/ <- atari I know what timidity does - the problem is just that the default patcset sucks beyond anything i have formerly seen. The kmidi help page recomends some places to download better patches for timidity, but all the links are broken. The biggest question is really: Why are those not included in timidity by default? Hmm.. why not? ever-lasting driver issue? We have a /dev/sequencer, why is it so hard to use? Think ill just have to fool around a little bit more, find out more things etc. s?n, 12.09.2004 kl. 04.49 skrev Chris Adams: > Once upon a time, Alan Cox said: > > On Sat, Sep 11, 2004 at 11:26:48PM +0200, Kyrre Ness Sjobak wrote: > > > Hmm... Does anybody know why Fedora haven't included a simple > > > midi-player, which simply sends things to your soundcard for rendering, > > > which in turn plays it?? And does anybody know about a good such > > > program? > > > > timidity and midiplay seem to be the popular ones. > > timidity renders in software with its own wavetable set - that's not > what the OP asked about. It looks like midiplay is the same sort of > thing, but it doesn't seem to have a home anymore. The nicer sound > cards have hardware wavetable synthesizers, but there doesn't appear to > be a way to use them much under Linux. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > From buildsys at redhat.com Sun Sep 12 11:33:24 2004 From: buildsys at redhat.com (Build System) Date: Sun, 12 Sep 2004 07:33:24 -0400 Subject: rawhide report: 20040912 changes Message-ID: <200409121133.i8CBXOf10524@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-2.91-0.20040912 ---------------------------- From kyrre at solution-forge.net Sun Sep 12 11:45:46 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 12 Sep 2004 13:45:46 +0200 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <604aa791040911163927f5993a@mail.gmail.com> References: <1094938008.2715.59.camel@kyrre> <604aa791040911163927f5993a@mail.gmail.com> Message-ID: <1094989546.2653.112.camel@kyrre> s?n, 12.09.2004 kl. 01.39 skrev Jeff Spaleta: > On Sat, 11 Sep 2004 23:26:48 +0200, Kyrre Ness Sjobak > wrote: > > Hmm... Does anybody know why Fedora haven't included a simple > > midi-player, which simply sends things to your soundcard for rendering, > > which in turn plays it?? And does anybody know about a good such > > program? > > I think the fact that you have to ask the second question, points to a > reason why you have to ask the first one. If you have the hardware and > the interest in playing midi files, and you can't find an appropriate > software for linux that fedora could evaluate for inclusion... that > should tell you something about why its not included. > > here's how you can be proactive: > Find software that works for what you need to do. > File a bug report in bugzilla.redhat.com requesting its inclusion > making a case that nothing > so far in Core provides this functionality > Create packages for the software and submit it for QA review at > fedora.us if its not already there. > > A quick google gives me: > http://mail.gnome.org/archives/gnome-multimedia/2003-December/msg00099.html > > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-dependencies.html > quote > 3.6. Does GStreamer support MIDI ? > Not yet. The GStreamer architecture should be able to support the > needs of MIDI applications very well however. If you are a developer > interested in adding MIDI support to GStreamer we are very interested > in getting in touch with you. > endquote > > Are you that developer? I think perhaps you can serve your own > interests by communicating directly with the gstreamer developers. > > -jef > Think that is somewhat over my head ;) But after some googling (thanks for the links, gave me some hints), ill found amSynth ( http://amsynthe.sourceforge.net/amSynth/index.html ) and MusE ( http://lmuse.sourceforge.net/ ) - which i will test out and report back to bugzilla if any of them seem "worthy". As a welcome side-effect, we migth by inclusion of midi-sequencer progs acctually prepare the ground for more musicans to swich to linux. Kyrre From kyrre at solution-forge.net Sun Sep 12 11:50:26 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 12 Sep 2004 13:50:26 +0200 Subject: vsftpd.conf In-Reply-To: <1094954703.27052.31.camel@stargrazer> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> <1094945111.27052.6.camel@stargrazer> <41438C5D.2020609@lanl.gov> <1094946963.27052.17.camel@stargrazer> <1094953485.25682.48.camel@neuwklin.ad.icdw.co.uk> <1094954703.27052.31.camel@stargrazer> Message-ID: <1094989826.2653.114.camel@kyrre> Who mentioned man here? Last time i edited vsftpd.conf, the comments provided me with more-than-enough information. s?n, 12.09.2004 kl. 04.05 skrev Sean Middleditch: > On Sun, 2004-09-12 at 02:44 +0100, Paul Trippett wrote: > > Dont you love it when you mention something at 1am without properly > > thinking something through :) > > > > However... > > > > > It shouldn't be required to ask questions to get a "bare bones" setup. > > > > I don't think we should rule out the large majority of people coming > > over from other OS's, these people being the "I know what I want to do > > and why I want to do it, but don't quite know how to do it". > > Realistically how often would you install a tcp service and leave it at > > that. > > Who cares what other OSes do? If your reason is "other OSes do it," > your reason, for lack of a better term, sucks. ;-) > > > > > How many times have you heard someone say "I installed Linux, now what > > do i do?" > > "Documentation." ^_^ > > > > > Some people may like being asked questions while others do not, but it > > doesn't hurt to give people the option. There must be quite a few uses > > for more generalised post install package configuration tool which isn't > > just limited to vsftpd and this thread. > > Yes, actually, it *DOES* hurt people to give them the option. You have > to ask questions about asking questions. You still end up with tons of > questions that the user has no clue about or doesn't care about and, > therefor, you get back answers that are most likely incorrect for what > the user really wants. You add a lot of complication for little gain > when other solutions exist. > > > > > > If you want a system that asks a bazillion questions on install time, > > > doesn't guarantee they'll be translated, doesn't guarantee they'll be > > > phrased intelligibly, and has tons and tons of infrastructure developed > > > and maintained instead of just good configuration tools and intelligent > > > defaults, you should install the OS produced over at > > > http://www.debian.org. > > > > Last time I used apt on debian from the command line i remember it > > saying something along the lines of "The following packages need to be > > configured before the can be used, would you like to configure them > > now", not only does it tell you they need to be configured it also gives > > you the option to help you do it, nor does it break automated installs. > > Just like everything else Debian has its place and also has a pretty > > good "bare bones" install itself. > > The debconf system has various priority levels for their questions. You > are forced to answer a "what priority of question do you want to answer" > question, and then lower-priority questions are ignored and a default > answer is used. A number of packages, however, abuse this system > heavily. The system also maps very poorly to a GUI. Packagers cannot > craft a clean, usable GUI, but instead must specify questions in a > rather abstract format so multiple frontends can handle it. They are > forced to deal with a lowest common denominator that functions pretty > poorly for every frontend. > > The priority system is also entirely broken in concept. What is > important to one use is trivial to another. Many packages which are > merely dependencies have questions which must be answered, which > especially is confusing when they are pulled in due to some completely > unrelated package. (Yes, dependency chains *will* do that, when > packagers don't break up their packages appropriately, or application > authors make it impossible to break up the packages.) > > When a novice user hits Install Everything, they get everything. Are > they really expected to be able to answer all the questions that come > up? Or do you expect the priority levels to give sensible defaults with > the user being able to change things later? If you picked the latter > (which you should've), then the question becomes, why the heck have the > infrastructure to ask questions at install time anyhow, when you > *already* have to ship a second solution and provide sensible defaults?? > > > > > I dont know why but not everyone likes trawling through man pages for > > half their waking day trying to get something to work. > > There are better forms of documentation than man pages. If you think > the only options available are "ask questions at install" and "be a UNIX > guru," you are failing to think of a ton of options in between. > > Fedora/RHEL already have some great server configuration utilities. A > new user just has to go to System Settings to find them. Tools exist > for Apache and Samba at least, and I know quite a few others exist. > More can be added. Along with good, clean, user-oriented documentation. > These solutions help both users during the initial install *and* helps > them down the road when they need to update or modify their settings. > > Honestly, it isn't that much more "work" to install a package and click > on its config utility than it is to install the package and have a half- > assed config dialog popup. And the former solution solves far more > problems in a much better fashion. > > > > > > From kyrre at solution-forge.net Sun Sep 12 11:54:36 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 12 Sep 2004 13:54:36 +0200 Subject: vsftpd.conf In-Reply-To: <41442FE8.4040402@feuerpokemon.de> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> <1094945111.27052.6.camel@stargrazer> <41442FE8.4040402@feuerpokemon.de> Message-ID: <1094990075.2653.119.camel@kyrre> s?n, 12.09.2004 kl. 13.15 skrev dragoran: > Sean Middleditch schrieb: > > >On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote: > > > > > >>Why not take a BSD approach and give them the option when installing the > >>package, say for example... > >> > >># rpm -i vsftp....rpm > >>Would you like to enable Anonymous logins? (y/n) [N] > >>Would you like to enable Local user Logins? (y/n) [N] > >> > >> > > > >Because RPMs are absolutely never ever supposed to ask questions. > > > >- What if the RPM is being installed non-interactively? > >- What if the RPM is being installed with a GUI tool? > >- What if the user doesn't understand English? > > > >And then you get into the general usability problems - are the question > >phrased properly? Is "Y/N" an appropriate prompt? etc. > > > >Better to offer a nice GUI configuration utility and just let admins run > >it after the installation, or just edit the .conf file if they're of the > >mind. > > > > > > > > > Nobody set up a ftp server and leave the default config, so it doesn't > really matter if anonymous logins are on by default or not. > ... exept those noobs who just hits "install everything" (which amounts to 50% of n00bs comming straight from the bare-bones windows world). There should be a "install everything, exept servers" option in anaconda... BTW asking questions during install caused me a lot of trouble when macromedia flash plugin did this - i was rolling it out to a number of machines using admin-script (www.solution-forge.net/source/unprotected) (the protected folder is empty ;) ). Thank you dag for providing a no-questions-asked rpm. But if nobody installs a ftpd without confing it, what bad would it do to disable logins? From kyrre at solution-forge.net Sun Sep 12 12:35:14 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 12 Sep 2004 14:35:14 +0200 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <1094989546.2653.112.camel@kyrre> References: <1094938008.2715.59.camel@kyrre> <604aa791040911163927f5993a@mail.gmail.com> <1094989546.2653.112.camel@kyrre> Message-ID: <1094992514.2653.123.camel@kyrre> Hmm... anybody know of "jack" rpms for fc2? It seems to be a callback based audio multiplexing server - and i dont like compiling libs... Hmm.. guess i just do "prefix=/usr/local/jack" and hope i can persuade muse to look for jack there ;) s?n, 12.09.2004 kl. 13.45 skrev Kyrre Ness Sjobak: > s?n, 12.09.2004 kl. 01.39 skrev Jeff Spaleta: > > On Sat, 11 Sep 2004 23:26:48 +0200, Kyrre Ness Sjobak > > wrote: > > > Hmm... Does anybody know why Fedora haven't included a simple > > > midi-player, which simply sends things to your soundcard for rendering, > > > which in turn plays it?? And does anybody know about a good such > > > program? > > > > I think the fact that you have to ask the second question, points to a > > reason why you have to ask the first one. If you have the hardware and > > the interest in playing midi files, and you can't find an appropriate > > software for linux that fedora could evaluate for inclusion... that > > should tell you something about why its not included. > > > > here's how you can be proactive: > > Find software that works for what you need to do. > > File a bug report in bugzilla.redhat.com requesting its inclusion > > making a case that nothing > > so far in Core provides this functionality > > Create packages for the software and submit it for QA review at > > fedora.us if its not already there. > > > > A quick google gives me: > > http://mail.gnome.org/archives/gnome-multimedia/2003-December/msg00099.html > > > > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-dependencies.html > > quote > > 3.6. Does GStreamer support MIDI ? > > Not yet. The GStreamer architecture should be able to support the > > needs of MIDI applications very well however. If you are a developer > > interested in adding MIDI support to GStreamer we are very interested > > in getting in touch with you. > > endquote > > > > Are you that developer? I think perhaps you can serve your own > > interests by communicating directly with the gstreamer developers. > > > > -jef > > > > Think that is somewhat over my head ;) > > But after some googling (thanks for the links, gave me some hints), ill > found amSynth ( http://amsynthe.sourceforge.net/amSynth/index.html ) and > MusE ( http://lmuse.sourceforge.net/ ) - which i will test out and > report back to bugzilla if any of them seem "worthy". > > As a welcome side-effect, we migth by inclusion of midi-sequencer progs > acctually prepare the ground for more musicans to swich to linux. > > Kyrre > From jspaleta at gmail.com Sun Sep 12 13:40:29 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 12 Sep 2004 09:40:29 -0400 Subject: vsftpd.conf In-Reply-To: <1094990075.2653.119.camel@kyrre> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> <1094945111.27052.6.camel@stargrazer> <41442FE8.4040402@feuerpokemon.de> <1094990075.2653.119.camel@kyrre> Message-ID: <604aa79104091206405af7823d@mail.gmail.com> On Sun, 12 Sep 2004 13:54:36 +0200, Kyrre Ness Sjobak wrote: > But if nobody installs a ftpd without confing it, what bad would it do > to disable logins? What bad would it be if http came completely unconfigured? Or if sshd came completely unconfigured? Its not unreasonable for a service to come configured to do something, as soon as its in enabled. The subtle and competent use of reasonably sane defaults to provide commonly used reasonable safe(relative to the purpose and scope of the service being started) and consistent functionality is an art. In the case of ftp, password protected logins by default are just completely unsafe becuase ftp uses clear text authentication. That is clearly and utterly irresponsble if enabled by default, such a feature relies heavily on the network its exposed to being "trustable." We can debate, forever, whether its reasonably safe to enable anonymous user access by default for ftp. But to leave anon login for ftp unconfigured by default, that sets a precedent, to leave every service completely unconfigured to do NOTHING by default. And thats just not a reasonable expectation. If sshd can come preconfigured to do something, and httpd can come ccnfigured to do something... vsftpd can come configured to do something by default as well. And for ftp, the very restricted anonymous access vsftpd allows, seems a relatively safe option compared to all the other default configured to do something options for ftp. The bulk of this discussion is completely uninteresting.. but there have been hints about how to extend the functionality of system-config-* for more and more services. It would be interesting to see if there is any interest to extend firstboot in some way to be aware of each service package that was installed, and to think hard about the ui of presenting users with a list of services that are available and whether to enable it and maybe an option to configure each service that has a system-config tool associated with it. -jef From russell at coker.com.au Sun Sep 12 14:27:34 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 13 Sep 2004 00:27:34 +1000 Subject: kernel module fs permissions In-Reply-To: <1094935931.3284.106.camel@bobcat.mine.nu> References: <1094922583.3284.60.camel@bobcat.mine.nu> <1094929438.7456.6.camel@laptop.fenrus.com> <1094935931.3284.106.camel@bobcat.mine.nu> Message-ID: <200409130027.34943.russell@coker.com.au> On Sun, 12 Sep 2004 06:52, Ville Skytt? wrote: > On Sat, 2004-09-11 at 22:03, Arjan van de Ven wrote: > > is having the modules executable an actual problem? > > AFAICT it's the same problem or non-problem as with any file out there > if a file that is not meant to be executable has executable bits set. > But I believe it's pretty much cosmetic in this case. http://www.yak.net/carmen/unix_horror.html Go to the above URL and search for the submission from mike at sojurn.lns.pa.us . -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From janina at rednote.net Sun Sep 12 14:57:41 2004 From: janina at rednote.net (Janina Sajka) Date: Sun, 12 Sep 2004 10:57:41 -0400 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <1094944811.4796.7.camel@kyrre> References: <1094938008.2715.59.camel@kyrre> <20040911231120.GF4297@rednote.net> <1094944811.4796.7.camel@kyrre> Message-ID: <20040912145741.GB7623@rednote.net> Kyrre Ness Sjobak writes: > s?n, 12.09.2004 kl. 01.11 skrev Janina Sajka: > > Kyrre Ness Sjobak writes: > > > Hmm... Does anybody know why Fedora haven't included a simple > > > midi-player, which simply sends things to your soundcard for rendering, > > > which in turn plays it?? And does anybody know about a good such > > > program? > > > > > Huh? Did timidity++ disappear? Or, am I misunderstanding your question? > > ... ... > > Hmm... what if i (as many others) are so lucky to have a HW-based > midi-playing soundcard (such as the AWE 64)? Methinks maybe they wants > to use it... > Are you aware of Planet CCRMA which is an entire distribution for musicians based on Fedora? http://ccrma.stanford.edu/planetccrma/software/ I mention CCRMA because it's Fedora and rpm based and aimed at professional musicians. However, I would also agree that support for driving MIDI instruments directly is weak on Linux. So, I heartily second Jeff's suggestion to get involved adding MIDI support to gstreamer--if that's something you're able to contribute. > Could it be possible to do something like MS does - in the gstreamer > setup, give an option to either use timidity (with a full patchset - the > patches included don't even rival my old SB16, The CCRMA repository does have timidity with a better set of instruments, fortunately. From alan at redhat.com Sun Sep 12 15:39:13 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 12 Sep 2004 11:39:13 -0400 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <20040912024948.GD1086333@hiwaay.net> References: <1094938008.2715.59.camel@kyrre> <20040912001230.GA30393@devserv.devel.redhat.com> <20040912024948.GD1086333@hiwaay.net> Message-ID: <20040912153913.GA908@devserv.devel.redhat.com> On Sat, Sep 11, 2004 at 09:49:48PM -0500, Chris Adams wrote: > thing, but it doesn't seem to have a home anymore. The nicer sound > cards have hardware wavetable synthesizers, but there doesn't appear to > be a way to use them much under Linux. ALSA exposes the midi hardware nicely but very few cards have midi and many that do have inferior midi processing to that you can do with a modern processor From kyrre at solution-forge.net Sun Sep 12 15:43:27 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 12 Sep 2004 17:43:27 +0200 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <20040912145741.GB7623@rednote.net> References: <1094938008.2715.59.camel@kyrre> <20040911231120.GF4297@rednote.net> <1094944811.4796.7.camel@kyrre> <20040912145741.GB7623@rednote.net> Message-ID: <1095003807.2653.130.camel@kyrre> s?n, 12.09.2004 kl. 16.57 skrev Janina Sajka: > Kyrre Ness Sjobak writes: > > s?n, 12.09.2004 kl. 01.11 skrev Janina Sajka: > > > Kyrre Ness Sjobak writes: > > > > Hmm... Does anybody know why Fedora haven't included a simple > > > > midi-player, which simply sends things to your soundcard for rendering, > > > > which in turn plays it?? And does anybody know about a good such > > > > program? > > > > > > > Huh? Did timidity++ disappear? Or, am I misunderstanding your question? > > > > ... ... > > > > Hmm... what if i (as many others) are so lucky to have a HW-based > > midi-playing soundcard (such as the AWE 64)? Methinks maybe they wants > > to use it... > > > > Are you aware of Planet CCRMA which is an entire distribution for > musicians based on Fedora? > > http://ccrma.stanford.edu/planetccrma/software/ > > I mention CCRMA because it's Fedora and rpm based and aimed at > professional musicians. > > However, I would also agree that support for driving MIDI instruments > directly is weak on Linux. So, I heartily second Jeff's suggestion to > get involved adding MIDI support to gstreamer--if that's something > you're able to contribute. > > > Could it be possible to do something like MS does - in the gstreamer > > setup, give an option to either use timidity (with a full patchset - the > > patches included don't even rival my old SB16, > > The CCRMA repository does have timidity with a better set of > instruments, fortunately. > Okay. Problem is: - I am not a professional musician, only some guy who wondered why i couldn't just play my midi-files - Wish i could do that. only problem is that my knowledge of C is inferior. MIDI also. But if CCRMA also has a repo, it should be possible to just install the necessary RPMS, right? Thanks for the hint. From bja at illinois.dyndns.org Sun Sep 12 17:07:35 2004 From: bja at illinois.dyndns.org (Brandon Joseph Adams) Date: Sun, 12 Sep 2004 17:07:35 -0000 (GMT) Subject: vsftpd.conf In-Reply-To: <41442FE8.4040402@feuerpokemon.de> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk><1094945111.27052.6.camel@stargrazer> <41442FE8.4040402@feuerpokemon.de> Message-ID: <4156.192.168.1.252.1095008855.squirrel@Illinois.DynDNS.Org> >>Better to offer a nice GUI configuration utility and just let admins run >>it after the installation, or just edit the .conf file if they're of the >>mind. >> >> >> >> > Nobody set up a ftp server and leave the default config, so it doesn't > really matter if anonymous logins are on by default or not. Incorrect. That should read, "Nobody SHOULD set up an ftp server and leave the default config...". Unfortunately a lot of people who don't have a clue do this exact thing, and allowing anonymous ftp logins by default may be a security issue for these people. I agree that a nice configuration utility would be nice and to just let the admin edit the config to his/her liking, but leaving anonymous logins off only requires an extra line in the release notes and a small paragraph in any manual. I think this is a small price to pay for the potential benefits. Brandon -- Brandon Joseph Adams Email: bja at illinois.dyndns.org AIM: Ace50003 From jamesaharrisonuk at yahoo.co.uk Sun Sep 12 18:11:00 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Sun, 12 Sep 2004 11:11:00 -0700 (PDT) Subject: vsftpd.conf In-Reply-To: <4156.192.168.1.252.1095008855.squirrel@Illinois.DynDNS.Org> Message-ID: <20040912181100.97612.qmail@web25303.mail.ukl.yahoo.com> Hi, Has anyone looked at proftpd an alternative to vsftpd (http://proftpd.linux.co.uk) ? It appears that it has a provision for ssl. No more need for clear text passwords...... James --- Brandon Joseph Adams wrote: > >>Better to offer a nice GUI configuration utility and just let admins run > >>it after the installation, or just edit the .conf file if they're of the > >>mind. > >> > >> > >> > >> > > Nobody set up a ftp server and leave the default config, so it doesn't > > really matter if anonymous logins are on by default or not. > > Incorrect. That should read, "Nobody SHOULD set up an ftp server and leave > the default config...". Unfortunately a lot of people who don't have a > clue do this exact thing, and allowing anonymous ftp logins by default may > be a security issue for these people. > > I agree that a nice configuration utility would be nice and to just let > the admin edit the config to his/her liking, but leaving anonymous logins > off only requires an extra line in the release notes and a small paragraph > in any manual. I think this is a small price to pay for the potential > benefits. > > Brandon > > -- > Brandon Joseph Adams > Email: bja at illinois.dyndns.org > AIM: Ace50003 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From ville.skytta at iki.fi Sun Sep 12 18:51:04 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 12 Sep 2004 21:51:04 +0300 Subject: RFC: extra kernel module install locations Message-ID: <1095015064.3284.180.camel@bobcat.mine.nu> There are various practices around about where to install extra kernel modules, I thought I'd throw in a quick RFC about what people think is the best practice, and why. Some alternatives off the cuff: 0) Somewhere directly below /lib/modules/$uname, in a per-package subdir. 1) A suitable location below /lib/modules/$uname/kernel. 2) /lib/modules/$uname/updates, mirroring the dir structure from /lib/modules/$uname/kernel as applicable. 3) Same as 2), but s/updates/$something_else_than_updates/. 4) As long as it Just Works(tm), does not matter. 5) Insert your favourite here. Status of how things seem to be "out there" currently, based on a very brief look: - fedora.us: both 0 (for thinkpad) and 1 (for alsa) - livna.org, Dag, freshrpms (FC1/alsa only checked): 1 - ATrpms: 2 - CCRMA uses something that doesn't fit 100% any of the above, but I guess 2 would be the closest. My .02? of the above: 0) Yuck, gets messy. 1) IMO shouldn't use "kernel" for stuff that is not included in kernel distributed by the kernel vendor. 2) My #1 pick as of now, maybe, depending on 3) below. 3) Is this better or worse than 2)? Dunno. Is "updates" the only dir that Just Works in earlier distro versions? Is using "updates" more or less likely to cause conflicts than "extra" or something else? Is it a bad thing to put all these extra modules to "updates", when the vast majority of them are not updates per se, but "new" modules instead (in the sense that they're not included in the vendor's kernel)? 4) I would feel more comfortable with some kind of documented guidelines or best practices, for consistency. Comments? From shiva at sewingwitch.com Sun Sep 12 20:33:41 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 12 Sep 2004 13:33:41 -0700 Subject: Packaging optional netfilter modules Message-ID: <5B4A7A485FEA550AA9F8C861@[10.0.0.4]> I wanted to try the experimental TARPIT module from netfilter, and because it's experimental, neither the upstream kernel team nor Red Hat will incorporate this into the stock kernel. This is of course perfectly reasonable. But since netfilter modules are kernel modules, it seems like it should be straightforward to package them as free-standing packages. Has anyone tried to do this? What success have you had? Another factor is that the kernel module will need matching machinery in the iptables userspace program to select the module and parse its options. (eg. for TARPIT, it would parse the "-j TARPIT" command.) I believe currently this requires a recompile of the utility. Has any work been done to make this more modular, with runtime selection of additional parsing routines? That would allow the userspace parsing piece to be supplied in the kernel module package to be dropped in a suitable directory for use at runtime. From lsomike at futzin.com Sun Sep 12 21:00:23 2004 From: lsomike at futzin.com (Mike Klinke) Date: Sun, 12 Sep 2004 16:00:23 -0500 Subject: Packaging optional netfilter modules In-Reply-To: <5B4A7A485FEA550AA9F8C861@[10.0.0.4]> References: <5B4A7A485FEA550AA9F8C861@[10.0.0.4]> Message-ID: <200409121600.23291.lsomike@futzin.com> On Sunday 12 September 2004 15:33, Kenneth Porter wrote: > I wanted to try the experimental TARPIT module from netfilter, > and because it's experimental, neither the upstream kernel team > nor Red Hat will incorporate this into the stock kernel. This is > of course perfectly reasonable. > > But since netfilter modules are kernel modules, it seems like it > should be straightforward to package them as free-standing > packages. Has anyone tried to do this? What success have you had? > Would this be close to what you're looking for? http://labrea.sourceforge.net/ Regards, Mike Klinke From fedora at wir-sind-cool.org Sun Sep 12 21:05:37 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 12 Sep 2004 23:05:37 +0200 Subject: Packaging optional netfilter modules In-Reply-To: <5B4A7A485FEA550AA9F8C861@[10.0.0.4]> References: <5B4A7A485FEA550AA9F8C861@[10.0.0.4]> Message-ID: <20040912230537.741c1f38.fedora@wir-sind-cool.org> On Sun, 12 Sep 2004 13:33:41 -0700, Kenneth Porter wrote: > I wanted to try the experimental TARPIT module from netfilter, and because > it's experimental, neither the upstream kernel team nor Red Hat will > incorporate this into the stock kernel. This is of course perfectly > reasonable. > > But since netfilter modules are kernel modules, it seems like it should be > straightforward to package them as free-standing packages. Has anyone tried > to do this? What success have you had? > > Another factor is that the kernel module will need matching machinery in > the iptables userspace program to select the module and parse its options. > (eg. for TARPIT, it would parse the "-j TARPIT" command.) I believe > currently this requires a recompile of the utility. Has any work been done > to make this more modular, with runtime selection of additional parsing > routines? That would allow the userspace parsing piece to be supplied in > the kernel module package to be dropped in a suitable directory for use at > runtime. Last time I looked at it, the iptables userspace tarball used hidden scripts to examine the kernel source code tree for what's available. That was with kernel 2.4.x and FC1, though. -- Fedora Core release 2 (Tettnang) - Linux 2.6.8-1.521 loadavg: 1.38 1.19 1.07 From strange at nsk.no-ip.org Sun Sep 12 21:45:11 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sun, 12 Sep 2004 22:45:11 +0100 Subject: Packaging optional netfilter modules In-Reply-To: <5B4A7A485FEA550AA9F8C861@[10.0.0.4]> References: <5B4A7A485FEA550AA9F8C861@[10.0.0.4]> Message-ID: <20040912214511.GA1970@nsk.no-ip.org> On Sun, Sep 12, 2004 at 01:33:41PM -0700, Kenneth Porter wrote: > I wanted to try the experimental TARPIT module from netfilter, and because > it's experimental, neither the upstream kernel team nor Red Hat will > incorporate this into the stock kernel. This is of course perfectly > reasonable. > > But since netfilter modules are kernel modules, it seems like it should be > straightforward to package them as free-standing packages. Has anyone tried > to do this? What success have you had? > > Another factor is that the kernel module will need matching machinery in > the iptables userspace program to select the module and parse its options. > (eg. for TARPIT, it would parse the "-j TARPIT" command.) I believe > currently this requires a recompile of the utility. Has any work been done > to make this more modular, with runtime selection of additional parsing > routines? That would allow the userspace parsing piece to be supplied in > the kernel module package to be dropped in a suitable directory for use at > runtime. It's also modular, using shared libraries (/lib/iptables/*.so). -- Consciousness: that annoying time between naps. From wart at kobold.org Sun Sep 12 22:37:46 2004 From: wart at kobold.org (Wart) Date: Sun, 12 Sep 2004 15:37:46 -0700 Subject: Self-Introduction: Wart Message-ID: <1095028666.22843.17.camel@tigger> Name: Michael "wart" Thomas Country, City: US, Pasadena Profession: Scientific Software Engineer Company: Caltech Goals in the Fedora project: To push for the inclusion of more Tcl extensions. I have a number of personal projects that make use of various Tcl extensions, and I'm just tired of typing "./configure ; make ; make install" to install it on clusters of machines. I'd rather type 'yum install ...' to save a few keystrokes. :) In particular, I'd like to help get tclhttpd and the various Tcl xml/soap extensions included in Fedora. I wouldn't mind doing QA on other packages, either, in my limited free time. Qualifications: I've been developing software for the scientific community for 10 years now. I've managed one fairly quiet project on SourceForge for over a year (ciphertool), and I am one of the main developers on another SourceForge project (clarens). I'm also starting to contribute packaging-related patches to a handful of other projects (all tcl-related). My programming languages include C, Tcl, Java, and a smattering of perl, python, and C++. GPG fingerprint (uploaded to pgp.mit.edu): pub 1024D/FB38D20F 2004-09-08 Michael Thomas (Wart) Key fingerprint = 00F9 CE86 4B6A F577 8914 55FA 0DE6 253D FB38 D20F sub 1024g/D0F16529 2004-09-08 --Wart From jspaleta at gmail.com Sun Sep 12 22:48:36 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 12 Sep 2004 18:48:36 -0400 Subject: vsftpd.conf In-Reply-To: <20040912181100.97612.qmail@web25303.mail.ukl.yahoo.com> References: <4156.192.168.1.252.1095008855.squirrel@Illinois.DynDNS.Org> <20040912181100.97612.qmail@web25303.mail.ukl.yahoo.com> Message-ID: <604aa7910409121548360ebf6a@mail.gmail.com> On Sun, 12 Sep 2004 11:11:00 -0700 (PDT), James Harrison wrote: > Has anyone looked at proftpd an alternative to vsftpd > (http://proftpd.linux.co.uk) ? > > It appears that it has a provision for ssl. > > No more need for clear text passwords...... So does vsftpd via openssl(though there are of course licensing issues associated with openssl which make adding for support for gnutls attractive). I won't bother giving you the faq url or the quote from the vsftpd manpage outlining that. I'll leave that as an excercise for the reader. But thats not the point... the point is a sane default that provides reasonable commonly expected functionality when the service is enabled in a reasonable safe fashion. Tradeoffs must be made between security and functionality and usability. Reasonable defaults find the balance. Reasonable.... that's a word that can't be stressed enough. Let's talk about reasonable for a minute.... I don't see anyone using the same arguments to say that httpd should come configured by default to ONLY do encypted authenticated based access. I wonder why that is? There is an expectation that httpd should come enabled by default to allow unencrypted public access when its enabled. Thats a reasonable expectation, considering http's widespread use as a public anonymous way to retrieve information. And i think the same expectation can be reasonable applied for default ftp server behavior, to enable anonymous public access to data. Both http and ftp can be configured for different purposes...but we are talking about reasonable defaults that strike the balance. And I for one find it...unreasonable...to talk about ftp's anonymous default access like its a special case situation, when no one is making the same arguments to lockdown httpd's default configuration. -jef"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. --George Bernard Shaw"spaleta From steve at silug.org Sun Sep 12 23:01:40 2004 From: steve at silug.org (Steven Pritchard) Date: Sun, 12 Sep 2004 18:01:40 -0500 Subject: QA request: dosbox Message-ID: <20040912230140.GA1469@osiris.silug.org> Anybody have a few minutes to spare? https://bugzilla.fedora.us/show_bug.cgi?id=2060 The version of dosbox in fedora.us stable is well over a year old. The newer version adds support for (at least some) protected-mode games. I was using it to play Tie Fighter this morning, in fact. (My computer may not be good enough to run Doom3, but at least it can run a decade-old game reasonably well... ;-) Anyway, this should be a really easy QA job for anyone who is interested... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From notting at redhat.com Mon Sep 13 05:11:28 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Sep 2004 01:11:28 -0400 Subject: Fedora Core 3 Schedule Update - Test 2 Delayed In-Reply-To: <1094862895.4676.0.camel@localhost.localdomain> References: <20040910221424.GA31318@nostromo.devel.redhat.com> <1094862895.4676.0.camel@localhost.localdomain> Message-ID: <20040913051128.GD24268@nostromo.devel.redhat.com> Sindre Pedersen Bjordal (foolish at fedoraforum.org) said: > Does this mean the support for Core 1 will be extended as well? Well, the date for letting Fedora Legacy take over FC1 support was the release of test2, so, yes. Bill From j.w.r.degoede at hhs.nl Mon Sep 13 06:27:00 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 13 Sep 2004 08:27:00 +0200 Subject: QA request: dosbox In-Reply-To: <20040912230140.GA1469@osiris.silug.org> References: <20040912230140.GA1469@osiris.silug.org> Message-ID: <41453DB4.6040809@hhs.nl> Steven Pritchard wrote: > Anybody have a few minutes to spare? > > https://bugzilla.fedora.us/show_bug.cgi?id=2060 > > The version of dosbox in fedora.us stable is well over a year old. > The newer version adds support for (at least some) protected-mode > games. I was using it to play Tie Fighter this morning, in fact. > (My computer may not be good enough to run Doom3, but at least it can > run a decade-old game reasonably well... ;-) > > Anyway, this should be a really easy QA job for anyone who is > interested... > Well I'm interested, but there is a catch I also have 2 (obscure) packages which need QA, choose one and you've got a deal: https://bugzilla.fedora.us/show_bug.cgi?id=444 https://bugzilla.fedora.us/show_bug.cgi?id=1925 One problem though the 100% free website hosting I was using, has dropped the srpms after a week so that 100% sucks :) Anyways I've got some webspace with a friend now, so I'll upload the srpms there and post a new URL in the bugs tonight (CET) Regards, Hans From arjanv at redhat.com Mon Sep 13 07:33:34 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 13 Sep 2004 09:33:34 +0200 Subject: the fate of firewire Message-ID: <1095060813.2624.12.camel@laptop.fenrus.com> Hi, there still appears to be problems with firewire, even in UP kernels. This makes me not happy ;-( The problem seems to mostly be people who do have a firewire controller but no firewire devices, and the symptoms are general "hangs during bootup sequence". We already disabled firewire in smp kernels for this, but I fear that if things don't improve really soon that firewire becomes unkeepable for UP kernels as well..... Greetings, Arjan van de Ven -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Sep 13 07:40:47 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 13 Sep 2004 09:40:47 +0200 Subject: RFC: extra kernel module install locations In-Reply-To: <1095015064.3284.180.camel@bobcat.mine.nu> References: <1095015064.3284.180.camel@bobcat.mine.nu> Message-ID: <20040913094047.3debaa35@localhost> Ville Skytt? wrote : > 0) Somewhere directly below /lib/modules/$uname, in a per-package > subdir. > 1) A suitable location below /lib/modules/$uname/kernel. > 2) /lib/modules/$uname/updates, mirroring the dir structure from > /lib/modules/$uname/kernel as applicable. > 3) Same as 2), but s/updates/$something_else_than_updates/. > 4) As long as it Just Works(tm), does not matter. > 5) Insert your favourite here. > [...] > > My .02___ of the above: > > 0) Yuck, gets messy. > 1) IMO shouldn't use "kernel" for stuff that is not included in kernel > distributed by the kernel vendor. > 2) My #1 pick as of now, maybe, depending on 3) below. > 3) Is this better or worse than 2)? Dunno. > Is "updates" the only dir that Just Works in earlier distro versions? > Is using "updates" more or less likely to cause conflicts > than "extra" or something else? Is it a bad thing to put all these > extra modules to "updates", when the vast majority of them are not > updates per se, but "new" modules instead (in the sense that they're > not included in the vendor's kernel)? > 4) I would feel more comfortable with some kind of documented guidelines > or best practices, for consistency. > > Comments? I definitely wouldn't mind going for 2) or 3). Having the sub-dir called something else than "updates" for kernel modules that are already existing in the original "kernel" module tree could lead to confusion, no? Also, the most important point I think is to be sure that the location where the separately packaged modules are installed gets precedence over the original "kernel" module tree, in order to make sure we can package more recent versions of modules already shipped with the kernel and have those loaded instead of the default ones. I'd go for "updates". BTW, what I do currently is 1) but also 2) ("updates" without mirroring the structure, though) for modules already shipped with the kernel (pwc/pwcx for instance). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.78 0.79 0.81 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Sep 13 07:49:01 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 13 Sep 2004 09:49:01 +0200 Subject: the fate of firewire In-Reply-To: <1095060813.2624.12.camel@laptop.fenrus.com> References: <1095060813.2624.12.camel@laptop.fenrus.com> Message-ID: <20040913094901.3ac47ed3@localhost> Arjan van de Ven wrote : > there still appears to be problems with firewire, even in UP kernels. > This makes me not happy ;-( > > The problem seems to mostly be people who do have a firewire controller > but no firewire devices, and the symptoms are general "hangs during > bootup sequence". > > We already disabled firewire in smp kernels for this, but I fear that if > things don't improve really soon that firewire becomes unkeepable for UP > kernels as well..... Argh. C'mmon, I can't believe I'm the only geek to shoot hours and hours of MiniDV and import/edit them on my Fedora Core laptop?? I actually need firewire more than I need USB ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.55 0.73 0.77 From dr at cluenet.de Mon Sep 13 08:50:57 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 13 Sep 2004 10:50:57 +0200 Subject: the fate of firewire In-Reply-To: <1095060813.2624.12.camel@laptop.fenrus.com> References: <1095060813.2624.12.camel@laptop.fenrus.com> Message-ID: <20040913085057.GA17010@srv01.cluenet.de> On Mon, Sep 13, 2004 at 09:33:34AM +0200, Arjan van de Ven wrote: > there still appears to be problems with firewire, even in UP kernels. > This makes me not happy ;-( > > The problem seems to mostly be people who do have a firewire controller > but no firewire devices, and the symptoms are general "hangs during > bootup sequence". > > We already disabled firewire in smp kernels for this, but I fear that if > things don't improve really soon that firewire becomes unkeepable for UP > kernels as well..... Could you please think about prolonging the FC1 support cycle until there is a usable 2.6-based distro out there? Regards, Daniel From alexl at redhat.com Mon Sep 13 09:01:51 2004 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 13 Sep 2004 11:01:51 +0200 Subject: the fate of firewire In-Reply-To: <20040913085057.GA17010@srv01.cluenet.de> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> Message-ID: <1095066111.7807.14.camel@greebo.homeip.net> On Mon, 2004-09-13 at 10:50 +0200, Daniel Roesen wrote: > On Mon, Sep 13, 2004 at 09:33:34AM +0200, Arjan van de Ven wrote: > > there still appears to be problems with firewire, even in UP kernels. > > This makes me not happy ;-( > > > > The problem seems to mostly be people who do have a firewire controller > > but no firewire devices, and the symptoms are general "hangs during > > bootup sequence". > > > > We already disabled firewire in smp kernels for this, but I fear that if > > things don't improve really soon that firewire becomes unkeepable for UP > > kernels as well..... > > Could you please think about prolonging the FC1 support cycle until > there is a usable 2.6-based distro out there? If you are interested in longer support for FC1, join the Fedora Legacy project: http://fedoralegacy.org/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a world-famous dishevelled paramedic who hides his scarred face behind a mask. She's a cynical African-American museum curator prone to fits of savage, blood-crazed rage. They fight crime! From dr at cluenet.de Mon Sep 13 09:31:02 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 13 Sep 2004 11:31:02 +0200 Subject: the fate of firewire In-Reply-To: <1095066111.7807.14.camel@greebo.homeip.net> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> Message-ID: <20040913093102.GA17330@srv01.cluenet.de> On Mon, Sep 13, 2004 at 11:01:51AM +0200, Alexander Larsson wrote: > If you are interested in longer support for FC1, join the Fedora Legacy > project: > http://fedoralegacy.org/ Is Fedora Legacy on vendor-sec? And what do you mean with "join"? Regards, Daniel From byte at aeon.com.my Mon Sep 13 09:40:03 2004 From: byte at aeon.com.my (Colin Charles) Date: Mon, 13 Sep 2004 19:40:03 +1000 Subject: the fate of firewire In-Reply-To: <20040913093102.GA17330@srv01.cluenet.de> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> <20040913093102.GA17330@srv01.cluenet.de> Message-ID: <1095068403.27996.0.camel@albus.aeon.com.my> On Mon, 2004-09-13 at 19:31, Daniel Roesen wrote: > > If you are interested in longer support for FC1, join the Fedora Legacy > > project: > > http://fedoralegacy.org/ > > Is Fedora Legacy on vendor-sec? Yes, I believe the Team Leader, Jesse Keating is in the know > And what do you mean with "join"? Start helping, testing packages, QA, building packages, and so on -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From Axel.Thimm at ATrpms.net Mon Sep 13 10:07:04 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 13 Sep 2004 12:07:04 +0200 Subject: RFC: extra kernel module install locations In-Reply-To: <1095015064.3284.180.camel@bobcat.mine.nu> References: <1095015064.3284.180.camel@bobcat.mine.nu> Message-ID: <20040913100704.GD3968@neu.physik.fu-berlin.de> On Sun, Sep 12, 2004 at 09:51:04PM +0300, Ville Skytt? wrote: > There are various practices around about where to install extra kernel > modules, I thought I'd throw in a quick RFC about what people think is > the best practice, and why. Some alternatives off the cuff: > > 0) Somewhere directly below /lib/modules/$uname, in a per-package > subdir. > 1) A suitable location below /lib/modules/$uname/kernel. > 2) /lib/modules/$uname/updates, mirroring the dir structure from > /lib/modules/$uname/kernel as applicable. > 3) Same as 2), but s/updates/$something_else_than_updates/. 3a) lkml style is s/updates/extra/, but last time I checked it flattened the directory structure (in contrast to 2). > 4) As long as it Just Works(tm), does not matter. > 5) Insert your favourite here. > Status of how things seem to be "out there" currently, based on a very > brief look: > - fedora.us: both 0 (for thinkpad) and 1 (for alsa) > - livna.org, Dag, freshrpms (FC1/alsa only checked): 1 > - ATrpms: 2 > - CCRMA uses something that doesn't fit 100% any of the above, > but I guess 2 would be the closest. > > My .02? of the above: > > 0) Yuck, gets messy. > 1) IMO shouldn't use "kernel" for stuff that is not included in kernel > distributed by the kernel vendor. > 2) My #1 pick as of now, maybe, depending on 3) below. > 3) Is this better or worse than 2)? Dunno. > Is "updates" the only dir that Just Works in earlier distro versions? > Is using "updates" more or less likely to cause conflicts > than "extra" or something else? Is it a bad thing to put all these > extra modules to "updates", when the vast majority of them are not > updates per se, but "new" modules instead (in the sense that they're > not included in the vendor's kernel)? > 4) I would feel more comfortable with some kind of documented guidelines > or best practices, for consistency. > > Comments? I think I'd prefer 2) ;) I am not really happy with the name of "updates", due to the reasons you state above, but it has already become traditional, is used by other distros (at least SuSE) as well, some kernel module software starts changing /extra/ to /updates/ also, and finally modutils give /updates/ preference over the rest [*] (the latter is technically very important, any other scheme needs to get modutils adjusted first). OTOH /extras/ (3a above) is what the kernel developers have currently blessed, but the flat structure is irritating. On the linguistic side both updates and extras are sometimes out of scope. "external" or similar would be more to the point. There is some inertia toward /updates/ (modutils gives preferencs, some distros like SuSE already use it, ATrpms uses it ;), some upstream kernel modules start to use it. Perhaps this discussion should move to lkml. I think it is important to have a coherent approach (non-packagers and packagers) here. [*] this is half true, for FC2-shipped modutils this was forgotten, but there is a bugzilla entry with appropriate patches that hopefully made it for FC3. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dr at cluenet.de Mon Sep 13 11:43:10 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 13 Sep 2004 13:43:10 +0200 Subject: the fate of firewire In-Reply-To: <1095068403.27996.0.camel@albus.aeon.com.my> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> <20040913093102.GA17330@srv01.cluenet.de> <1095068403.27996.0.camel@albus.aeon.com.my> Message-ID: <20040913114310.GA18987@srv01.cluenet.de> On Mon, Sep 13, 2004 at 07:40:03PM +1000, Colin Charles wrote: > > Is Fedora Legacy on vendor-sec? > > Yes, I believe the Team Leader, Jesse Keating is in the know Well, I'll take a look how quickly updates got/will be released (when having coordinated releases). > > And what do you mean with "join"? > > Start helping, testing packages, QA, building packages, and so on I simply don't have the time for that. In my current situation, my Linux servers are workhorses and I want/need to spend as few time on maintaining them as possible. Red Hat Linux support cycle has worked for that, Fedora doesn't anymore. I've completed the last migration from my RHL 7.1 based servers to FC1 based servers a couple of weeks ago, and now FC1 is already EOS. Wether Fedora Legacy is a viable alternative for prolonged critical upgrade service will have to be seen. I'll watch closely how timely security updates will be released. Really, this is not picking on anyone, as after all it's all free as in beer. I just need a modern Linux distro with a (basic) support cycle of about 3 years. I don't want to reinstall all my servers every couple of months. And no, distro-upgrades are no option. Too dangerous to end up with a messed-up system. So I usually install a replacement server with a new distro version, and subsequently move services over, then retire the old box. Worked nicely for 6.2 => 7.1 => 9 => FC1 up to now. Regards, Daniel From katzj at redhat.com Mon Sep 13 12:21:13 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Sep 2004 08:21:13 -0400 Subject: RFC: extra kernel module install locations In-Reply-To: <20040913100704.GD3968@neu.physik.fu-berlin.de> References: <1095015064.3284.180.camel@bobcat.mine.nu> <20040913100704.GD3968@neu.physik.fu-berlin.de> Message-ID: <1095078073.9565.2.camel@bree.local.net> On Mon, 2004-09-13 at 12:07 +0200, Axel Thimm wrote: > [*] this is half true, for FC2-shipped modutils this was forgotten, > but there is a bugzilla entry with appropriate patches that hopefully > made it for FC3. thomasvs's patches are in upstream module-init-tools now (well, at least, equivalent functionality is; istr that Rusty did the implementation slightly differently) Jeremy From tdiehl at rogueind.com Mon Sep 13 12:44:17 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Mon, 13 Sep 2004 08:44:17 -0400 (EDT) Subject: the fate of firewire In-Reply-To: <20040913114310.GA18987@srv01.cluenet.de> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> <20040913093102.GA17330@srv01.cluenet.de> <1095068403.27996.0.camel@albus.aeon.com.my> <20040913114310.GA18987@srv01.cluenet.de> Message-ID: On Mon, 13 Sep 2004, Daniel Roesen wrote: > On Mon, Sep 13, 2004 at 07:40:03PM +1000, Colin Charles wrote: > > > Is Fedora Legacy on vendor-sec? > > > > Yes, I believe the Team Leader, Jesse Keating is in the know > > Well, I'll take a look how quickly updates got/will be released > (when having coordinated releases). > > > > And what do you mean with "join"? > > > > Start helping, testing packages, QA, building packages, and so on > > I simply don't have the time for that. In my current situation, my > Linux servers are workhorses and I want/need to spend as few time > on maintaining them as possible. Red Hat Linux support cycle has > worked for that, Fedora doesn't anymore. I've completed the last > migration from my RHL 7.1 based servers to FC1 based servers a > couple of weeks ago, and now FC1 is already EOS. Wether Fedora Legacy > is a viable alternative for prolonged critical upgrade service will > have to be seen. I'll watch closely how timely security updates will > be released. It is not intended to be. fedora-legacy is a volunteer effort. If people volunteer to do the work it will get done, if not... > Really, this is not picking on anyone, as after all it's all free > as in beer. I just need a modern Linux distro with a (basic) support > cycle of about 3 years. I don't want to reinstall all my servers > every couple of months. And no, distro-upgrades are no option. Too > dangerous to end up with a messed-up system. So I usually install > a replacement server with a new distro version, and subsequently move > services over, then retire the old box. Worked nicely for 6.2 => 7.1 > => 9 => FC1 up to now. Based on your above comments, I would submit that you are using the wrong distro. If you need stability and timely updates then you need something like RHEL. Don't want to pay for it? Go look at Whitebox, cAoS, Tao, etc. There are plenty of alternatives without whining about the support of cycle of fedora. In addition I would suggest you read the fedora web page so that you will understand what fedora is and is not. FWIW you can get the RHPW version of RHEL3 for < $100 USD. It only provides for 30 days of installation support but you get a year of RHN. The downside to this is that it does not include some of the server packages but they are available in SRPM format so you can build them yourself. Since there is no support with the thing you do not have to worry about violating your support agreement. :-) Tom From buildsys at redhat.com Mon Sep 13 12:50:14 2004 From: buildsys at redhat.com (Build System) Date: Mon, 13 Sep 2004 08:50:14 -0400 Subject: rawhide report: 20040913 changes Message-ID: <200409131250.i8DCoEW14023@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.2-2 -------------------- * Sat Sep 11 2004 Dan Williams 0.2-2 - Require gnome-panel, not gnome-panel-devel - Turn off by default bind-9.2.4rc7-12 ---------------- * Fri Sep 10 2004 Jason Vas Dias - 10:9.2.4rc7-12_EL3 - Fix bug 132303: if ROOTDIR line was replaced after upgrade from - bind-chroot-9.2.2-21, restart named * Wed Sep 08 2004 Jason Vas Dias - 10:9.2.4rc7-11_EL3 - Fix bug 131803: replace ROOTDIR line removed by broken - bind-chroot 9.2.2-21's '%postun'; added %triggerpostun for bind-chroot * Tue Sep 07 2004 Jason Vas Dias - 10:9.2.4rc7-10_EL3 - Fix bugs 130121 & 130981 for RHEL-3 glibc-2.3.3-51 -------------- * Fri Sep 10 2004 Jakub Jelinek 2.3.3-51 - update from CVS - disable one of the malloc double free checks for non-contiguous arenas where it doesn't have to be true even for non-broken apps * Thu Sep 09 2004 Jakub Jelinek 2.3.3-50 - update from CVS - pwd/grp/host loops with nscd speed up by sharing the nscd cache r/o with applications - inexpensive double free check in free(3) - make NPTL pthread.h initializers usable even from C++ (BZ #375) - use atomic instructions even in i386 nscd on i486+ CPUs (conditionally) gtk2-2.4.9-7 ------------ * Fri Sep 10 2004 Matthias Clasen - 2.4.9-7 - backport support for PangoLogAttr.backspace_deletes_character mailman-2.1.5-19 ---------------- * Fri Sep 10 2004 John Dennis 3:2.1.5-19 - add il18n start/stop strings to init.d script * Fri Sep 10 2004 John Dennis 3:2.1.5-18 - fix bug #89250, add condrestart also fix status return values in mailmanctl and init.d script rhgb-0.12.6-1 ------------- * Sat Sep 11 2004 Daniel Veillard 0.12.6 - fix the X keyboard setting before launching firstboot #100686 * Fri Sep 10 2004 Daniel Veillard 0.12.5 - fix part of the patch for xinerama which hung firstboot #128003 * Thu Sep 09 2004 Daniel Veillard 0.12.4 - move rhgb out of /initrd to /etc/rhgb fixes #117575 rpmdb-fedora-2.91-0.20040913 ---------------------------- From dr at cluenet.de Mon Sep 13 13:21:15 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 13 Sep 2004 15:21:15 +0200 Subject: the fate of firewire In-Reply-To: References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> <20040913093102.GA17330@srv01.cluenet.de> <1095068403.27996.0.camel@albus.aeon.com.my> <20040913114310.GA18987@srv01.cluenet.de> Message-ID: <20040913132115.GA19708@srv01.cluenet.de> On Mon, Sep 13, 2004 at 08:44:17AM -0400, Tom Diehl wrote: > > Wether Fedora Legacy is a viable alternative for prolonged critical > > upgrade service will have to be seen. I'll watch closely how timely > > security updates will be released. > > It is not intended to be. fedora-legacy is a volunteer effort. Eh? It's there to provide exactly this: prolonged support cycle for Fedora. Wether it is a volunteer or paid effort doesn't matter. > If people volunteer to do the work it will get done, if not... Yup. But still it's becoming worthless for me, if security updates don't arrive in time. When vulns are published, there is no time for "waiting weeks for an upgrade". When FL doesn't publish a security errata quickly, I have to resort to compile-and-install-myself, and then I obviously don't need FL anymore. > > Really, this is not picking on anyone, as after all it's all free > > as in beer. I just need a modern Linux distro with a (basic) support > > cycle of about 3 years. I don't want to reinstall all my servers > > every couple of months. And no, distro-upgrades are no option. Too > > dangerous to end up with a messed-up system. So I usually install > > a replacement server with a new distro version, and subsequently move > > services over, then retire the old box. Worked nicely for 6.2 => 7.1 > > => 9 => FC1 up to now. > > Based on your above comments, I would submit that you are using the wrong > distro. Indeed. This is my current dilemma, as I don't see a good alternative for me in the Linux market anymore. And the BSD area doesn't look too appaeling to... have now installed FBSD 5.3 on one of my Netras to look around there. Now that they have a non-stoneage init system. > If you need stability and timely updates then you need something > like RHEL. No, RHEL has a too long innovation cycle. What I need is something like the Fedora release (innovation) cycle, together with a RHEL-like support cycle. But this is a case of TANSTAAFL, at least in the the Red Hat land. > There are plenty of alternatives without whining about the support > of cycle of fedora. It's a typical problem of OS fanatics to discredit any discussion/criticism as "whining". I'm certainly not "whining". > In addition I would suggest you read the fedora web page so that > you will understand what fedora is and is not. It's totally clear what it is about. It is about Red Hat getting rid of the support burden for their non-enterprise customers as far as possible without upsetting people too much and as a consequence being able to be a bit more experimental, and using the Fedora user base as betatesters for their RHEL product line. This is nothing wrong per se, though I'm a little bit disgruntled about reading "community" everwhere, but seeing that this is just totally lip service up until now. Anyway... in summary Fedora is OK for me as long as Fedora Legacy "works" in regard of providing timely(!) security updates for about three years after release of a specific Fedora version. And from talking to many other admins (collegues, friends) they are all in the same dilemma. Regards, Daniel From rdieter at math.unl.edu Mon Sep 13 13:31:46 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 13 Sep 2004 08:31:46 -0500 Subject: the fate of firewire In-Reply-To: <20040913132115.GA19708@srv01.cluenet.de> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> <20040913093102.GA17330@srv01.cluenet.de> <1095068403.27996.0.camel@albus.aeon.com.my> <20040913114310.GA18987@srv01.cluenet.de> <20040913132115.GA19708@srv01.cluenet.de> Message-ID: <4145A142.3010508@math.unl.edu> Daniel Roesen wrote: > No, RHEL has a too long innovation cycle. What I need is something > like the Fedora release (innovation) cycle, together with a RHEL-like > support cycle. And redhat decided that these 2 items, short innovation cycle + long support cycle, are mutually exclusive. redhat would end up "supporting" 5-6 releases (going back ~3 years @ ~ 6 month innovation cycle), which would be unmanageable. Is that really what you want? Besides, IMO, RHEL is pretty good when it comes to innovation too. Are there features missing from RHEL that you need? -- Rex From thomas at apestaart.org Mon Sep 13 13:31:50 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 13 Sep 2004 15:31:50 +0200 Subject: the fate of firewire In-Reply-To: <1095060813.2624.12.camel@laptop.fenrus.com> References: <1095060813.2624.12.camel@laptop.fenrus.com> Message-ID: <1095082310.17600.2.camel@otto.amantes> Hi Arjan, > there still appears to be problems with firewire, even in UP kernels. > This makes me not happy ;-( Yep, I sometimes get bitten by them too. Though, in general, it mostly works - See http://mirror.fluendo.com/cortado for an example of our use. > The problem seems to mostly be people who do have a firewire controller > but no firewire devices, and the symptoms are general "hangs during > bootup sequence". > > We already disabled firewire in smp kernels for this, but I fear that if > things don't improve really soon that firewire becomes unkeepable for UP > kernels as well..... ... but firewire currently are modules, right ? I don't think disabling compilation completely makes any sense at all. People for whom firewire doesn't work well should just not use it, or fix it upstream. I'd hate to see Fedora a) change too much between major releases what is or is not provided in the kernel or b) make it really really hard to have firewire working (I think it's a bad idea to have users complie their own kernel). Out of curiosity, why is firewire such a problem child ? Are there simply no kernel hackers interested in it ? Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> I know someday you'll have a beautiful life I know you'll be a star in someone else's sky but why oh why oh why why can't it be mine ? <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From arjanv at redhat.com Mon Sep 13 13:44:08 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 13 Sep 2004 15:44:08 +0200 Subject: the fate of firewire In-Reply-To: <1095082310.17600.2.camel@otto.amantes> References: <1095060813.2624.12.camel@laptop.fenrus.com> <1095082310.17600.2.camel@otto.amantes> Message-ID: <20040913134408.GA24944@devserv.devel.redhat.com> On Mon, Sep 13, 2004 at 03:31:50PM +0200, Thomas Vander Stichele wrote: > ... but firewire currently are modules, right ? I don't think disabling > compilation completely makes any sense at all. People for whom firewire > doesn't work well should just not use it problem is that it gets autoloaded > Out of curiosity, why is firewire such a problem child ? Are there > simply no kernel hackers interested in it ? not sure; the locking for sure smells like dead fish.... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From harald at redhat.com Mon Sep 13 13:48:53 2004 From: harald at redhat.com (Harald Hoyer) Date: Mon, 13 Sep 2004 15:48:53 +0200 Subject: the fate of firewire In-Reply-To: <20040913134408.GA24944@devserv.devel.redhat.com> References: <1095060813.2624.12.camel@laptop.fenrus.com> <1095082310.17600.2.camel@otto.amantes> <20040913134408.GA24944@devserv.devel.redhat.com> Message-ID: <4145A545.2020709@redhat.com> Arjan van de Ven wrote: > On Mon, Sep 13, 2004 at 03:31:50PM +0200, Thomas Vander Stichele wrote: > > >>... but firewire currently are modules, right ? I don't think disabling >>compilation completely makes any sense at all. People for whom firewire >>doesn't work well should just not use it > > > problem is that it gets autoloaded we could blacklist that From tiemann at redhat.com Mon Sep 13 13:51:34 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 13 Sep 2004 09:51:34 -0400 Subject: the fate of firewire In-Reply-To: <4145A142.3010508@math.unl.edu> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> <20040913093102.GA17330@srv01.cluenet.de> <1095068403.27996.0.camel@albus.aeon.com.my> <20040913114310.GA18987@srv01.cluenet.de> <20040913132115.GA19708@srv01.cluenet.de> <4145A142.3010508@math.unl.edu> Message-ID: <1095083494.3457.30.camel@dhcp63-226.rdu.redhat.com> Red Hat "decided" that short innovation cycle + long support cycle are mutually exclusive about as much as Galileo "decided" that the Earth orbited the Sun, not the other way around. I just hope that The Community is as forgiving about our "decision" as The Church was about Galileo's ;-) M On Mon, 2004-09-13 at 09:31, Rex Dieter wrote: > Daniel Roesen wrote: > > > No, RHEL has a too long innovation cycle. What I need is something > > like the Fedora release (innovation) cycle, together with a RHEL-like > > support cycle. > > And redhat decided that these 2 items, short innovation cycle + long > support cycle, are mutually exclusive. redhat would end up "supporting" > 5-6 releases (going back ~3 years @ ~ 6 month innovation cycle), which > would be unmanageable. Is that really what you want? > > Besides, IMO, RHEL is pretty good when it comes to innovation too. Are > there features missing from RHEL that you need? > > -- Rex > From dr at cluenet.de Mon Sep 13 13:53:50 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 13 Sep 2004 15:53:50 +0200 Subject: the fate of firewire In-Reply-To: <4145A142.3010508@math.unl.edu> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> <20040913093102.GA17330@srv01.cluenet.de> <1095068403.27996.0.camel@albus.aeon.com.my> <20040913114310.GA18987@srv01.cluenet.de> <20040913132115.GA19708@srv01.cluenet.de> <4145A142.3010508@math.unl.edu> Message-ID: <20040913135350.GA20037@srv01.cluenet.de> On Mon, Sep 13, 2004 at 08:31:46AM -0500, Rex Dieter wrote: > >No, RHEL has a too long innovation cycle. What I need is something > >like the Fedora release (innovation) cycle, together with a RHEL-like > >support cycle. > > And redhat decided that these 2 items, short innovation cycle + long > support cycle, are mutually exclusive. redhat would end up "supporting" > 5-6 releases (going back ~3 years @ ~ 6 month innovation cycle), which > would be unmanageable. Is that really what you want? Yes, it is what I want. But obviously nothing Red Hat does provide (anymore). I'm not complaining about that fact, it just explains why I have a problem now and a working Fedora Legacy is the only hope I have allowing me to stay with RH/Fedora. > Besides, IMO, RHEL is pretty good when it comes to innovation too. Are > there features missing from RHEL that you need? It's not necessarily features. When I (re-)install a computer today, I don't want a general software release level which is a year old (or even more, RHEL4 isn't on the horizont yet as far as I can see). And exactly this is one of the motivations of Red Hat for Fedora, as stated by Red Hat themselves. Regards, Daniel From aoliva at redhat.com Mon Sep 13 13:54:43 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 13 Sep 2004 10:54:43 -0300 Subject: the fate of firewire In-Reply-To: <1095060813.2624.12.camel@laptop.fenrus.com> References: <1095060813.2624.12.camel@laptop.fenrus.com> Message-ID: On Sep 13, 2004, Arjan van de Ven wrote: > there still appears to be problems with firewire, even in UP kernels. -ENOINFO What kernel version? What problems? Where are the kernel stack traces? Please don't even try use this as an excuse to simply remove Firewire support. I'm more than willing to try to fix problems that turn up to have Firewire enabled. It certainly works very reliably for me, and I haven't been able to duplicate old problems that are already fixed, but that some people claim to have resurfaced. I'd like to get in touch with whoever has such problems and try to help fix them. Please send such bug reports my way. And, while at that, enable Firewire on SMP again, ideally in time for FC3test2, such that we get more of a chance to actually get the bug reports on it and fix the problems. It's easy enough to disable the module, but I just don't see people rebuilding the modules to help us address problems in drivers for a piece of hardware they may not even know they have. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From cmadams at hiwaay.net Mon Sep 13 14:04:39 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 13 Sep 2004 09:04:39 -0500 Subject: the fate of firewire In-Reply-To: <20040913135350.GA20037@srv01.cluenet.de> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> <20040913093102.GA17330@srv01.cluenet.de> <1095068403.27996.0.camel@albus.aeon.com.my> <20040913114310.GA18987@srv01.cluenet.de> <20040913132115.GA19708@srv01.cluenet.de> <4145A142.3010508@math.unl.edu> <20040913135350.GA20037@srv01.cluenet.de> Message-ID: <20040913140439.GA1150202@hiwaay.net> Once upon a time, Daniel Roesen said: > On Mon, Sep 13, 2004 at 08:31:46AM -0500, Rex Dieter wrote: > > redhat would end up "supporting" > > 5-6 releases (going back ~3 years @ ~ 6 month innovation cycle), which > > would be unmanageable. Is that really what you want? > > Yes, it is what I want. But obviously nothing Red Hat does provide > (anymore). AFAIK nobody provides that. When I looked a while back, most of the free OS distributions only commit to 1 year of updates for a particular release. The commercial OS vendors have longer support, but don't have full new releases as often. > > Besides, IMO, RHEL is pretty good when it comes to innovation too. Are > > there features missing from RHEL that you need? > > It's not necessarily features. When I (re-)install a computer today, > I don't want a general software release level which is a year old > (or even more, RHEL4 isn't on the horizont yet as far as I can see). It is on the horizon; just look at the changelogs of some RPMs in Fedora. I've seen numerous "RHEL4" related comments. If the features you need are there, what difference does the release date make? There is software in both RHEL and Fedora that hasn't been changed in a while. Also, RHEL has quarterly updates with new versions of some things (and feature backports in other things like the kernel). I just updated my server install tree with RHEL 3 Update 3. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From lnxxprt at arcor.de Mon Sep 13 14:09:20 2004 From: lnxxprt at arcor.de (D. Stolte) Date: Mon, 13 Sep 2004 16:09:20 +0200 Subject: the fate of firewire In-Reply-To: <20040913132115.GA19708@srv01.cluenet.de> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> <20040913093102.GA17330@srv01.cluenet.de> <1095068403.27996.0.camel@albus.aeon.com.my> <20040913114310.GA18987@srv01.cluenet.de> <20040913132115.GA19708@srv01.cluenet.de> Message-ID: <4145AA10.5060805@arcor.de> disclaimer: i am not a rh employee. you have some options: if you have many friends and collegues sitting in the same boat (newest linux software and 3-or-more-years support) then you all could pay someone to offer you the service of fixing buggy packages. and you could do the community a favor and offer your then fixed software back to the community. or you could wait until the lifecycle is over and setup testing servers with the next fedora release as you said it worked until now. i dont see a reason why it shouldnt work anymore. whatever you decision will be, you dont get running servers without investing anything. but thats also true for every other OS. /ds > >>>Wether Fedora Legacy is a viable alternative for prolonged critical >>>upgrade service will have to be seen. I'll watch closely how timely >>>security updates will be released. >> >>It is not intended to be. fedora-legacy is a volunteer effort. > > > Eh? It's there to provide exactly this: prolonged support cycle > for Fedora. Wether it is a volunteer or paid effort doesn't matter. > > >>If people volunteer to do the work it will get done, if not... > > > Yup. But still it's becoming worthless for me, if security updates > don't arrive in time. When vulns are published, there is no time for > "waiting weeks for an upgrade". When FL doesn't publish a security > errata quickly, I have to resort to compile-and-install-myself, and > then I obviously don't need FL anymore. > > >>>Really, this is not picking on anyone, as after all it's all free >>>as in beer. I just need a modern Linux distro with a (basic) support >>>cycle of about 3 years. I don't want to reinstall all my servers >>>every couple of months. And no, distro-upgrades are no option. Too >>>dangerous to end up with a messed-up system. So I usually install >>>a replacement server with a new distro version, and subsequently move >>>services over, then retire the old box. Worked nicely for 6.2 => 7.1 >>>=> 9 => FC1 up to now. >> >>Based on your above comments, I would submit that you are using the wrong >>distro. > > > Indeed. This is my current dilemma, as I don't see a good alternative > for me in the Linux market anymore. And the BSD area doesn't look too > appaeling to... have now installed FBSD 5.3 on one of my Netras to > look around there. Now that they have a non-stoneage init system. > > >>If you need stability and timely updates then you need something >>like RHEL. > > > No, RHEL has a too long innovation cycle. What I need is something > like the Fedora release (innovation) cycle, together with a RHEL-like > support cycle. But this is a case of TANSTAAFL, at least in the the > Red Hat land. > > >>There are plenty of alternatives without whining about the support >>of cycle of fedora. > > > It's a typical problem of OS fanatics to discredit any > discussion/criticism as "whining". I'm certainly not "whining". > > >>In addition I would suggest you read the fedora web page so that >>you will understand what fedora is and is not. > > > It's totally clear what it is about. It is about Red Hat getting rid > of the support burden for their non-enterprise customers as far as possible > without upsetting people too much and as a consequence being able to > be a bit more experimental, and using the Fedora user base as > betatesters for their RHEL product line. This is nothing wrong per se, > though I'm a little bit disgruntled about reading "community" everwhere, > but seeing that this is just totally lip service up until now. > > Anyway... in summary Fedora is OK for me as long as Fedora Legacy > "works" in regard of providing timely(!) security updates for about > three years after release of a specific Fedora version. And from talking > to many other admins (collegues, friends) they are all in the same > dilemma. > > > Regards, > Daniel > > From otaylor at redhat.com Mon Sep 13 14:25:11 2004 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 13 Sep 2004 10:25:11 -0400 Subject: Fedora Core 3 Schedule Update - Test 2 Delayed In-Reply-To: <20040910221424.GA31318@nostromo.devel.redhat.com> References: <20040910221424.GA31318@nostromo.devel.redhat.com> Message-ID: <1095085510.2898.7.camel@localhost.localdomain> On Fri, 2004-09-10 at 18:14, Bill Nottingham wrote: > Due to various issues with candidate trees so far, Test 2 > has been pushed out one week, to September 20th. > > Updated schedule is at: > > http://fedora.redhat.com/participate/schedule/ Hmm, with this change, Test 2 is going to be after the final GNOME-2.8 package releases. If we can get the final packages past the release managers, I think we should get them in; the value of getting the Test 2 testing with the newer packages I think outweighs the small chance of causing additional problems. Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Mon Sep 13 14:38:33 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 13 Sep 2004 10:38:33 -0400 Subject: /dev/dri/* and SE Linux In-Reply-To: <200409111934.19937.russell@coker.com.au> References: <200409111934.19937.russell@coker.com.au> Message-ID: <4145B0E9.80000@redhat.com> Russell Coker wrote: >In the latest CVS SE Linux policy xserver_macros.te has: > ># Create and access /dev/dri devices. >allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; >allow $1_xserver_t dri_device_t:chr_file create_file_perms; > >[...] > ># Do not flood audit logs due to device node creation attempts. >dontaudit $1_xserver_t device_t:chr_file create; > >[...] > >allow $1_xserver_t device_t:dir { create }; > >It seems that the first and second sections don't work well together. Since >we changed /dev/dri to have type device_t instead of dri_device_t it seems >that attempts to create /dev/dri/whatever will be permitted on the >device_t:dir access but dontaudit'd on the device_t:chr_file access. > >Does it even make sense to allow creating device nodes under /dev/dri now that >we have udev doing so much? Can't udev do this for us? > > > It should in the future, but it doesn't right now. (Might need to add the broken software tunable. :^) Dan From fedora at leemhuis.info Mon Sep 13 14:42:52 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 13 Sep 2004 16:42:52 +0200 Subject: RFC: extra kernel module install locations In-Reply-To: <1095015064.3284.180.camel@bobcat.mine.nu> References: <1095015064.3284.180.camel@bobcat.mine.nu> Message-ID: <1095086572.1860.20.camel@localhost.localdomain> Hi * Am Sonntag, den 12.09.2004, 21:51 +0300 schrieb Ville Skytt?: > There are various practices around about where to install extra kernel > modules, I thought I'd throw in a quick RFC about what people think is > the best practice, and why. Some alternatives off the cuff: > > 0) Somewhere directly below /lib/modules/$uname, in a per-package > subdir. > 1) A suitable location below /lib/modules/$uname/kernel. > 2) /lib/modules/$uname/updates, mirroring the dir structure from > /lib/modules/$uname/kernel as applicable. > 3) Same as 2), but s/updates/$something_else_than_updates/. > 4) As long as it Just Works(tm), does not matter. > 5) Insert your favourite here. > > Status of how things seem to be "out there" currently, based on a very > brief look: > - fedora.us: both 0 (for thinkpad) and 1 (for alsa) For alsa (and some other things at livna.org) I decided to install it there, where the module would have been installed by the original scripts during a normal install. [...] > 0) Yuck, gets messy. ++ > 1) IMO shouldn't use "kernel" for stuff that is not included in kernel > distributed by the kernel vendor. I don't think it's a problem. I think installing the module exactly at the same place where it normally would have been installed when you compile it also has a lot of benefits. > 2) My #1 pick as of now, maybe, depending on 3) below. But do we really need to mirror the stucture? Is there any benefit in doing so? Why not a simple per-package dir? Otherwise I don't have any strong opinions. I tend a bit more to 1), but can also live with either 2) or 3) -- Thorsten Leemhuis From fedora at leemhuis.info Mon Sep 13 14:46:26 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 13 Sep 2004 16:46:26 +0200 Subject: the fate of firewire In-Reply-To: <1095060813.2624.12.camel@laptop.fenrus.com> References: <1095060813.2624.12.camel@laptop.fenrus.com> Message-ID: <1095086786.1860.23.camel@localhost.localdomain> Am Montag, den 13.09.2004, 09:33 +0200 schrieb Arjan van de Ven: > Hi, > > there still appears to be problems with firewire, even in UP kernels. > This makes me not happy ;-( > > The problem seems to mostly be people who do have a firewire controller > but no firewire devices, and the symptoms are general "hangs during > bootup sequence". > > We already disabled firewire in smp kernels for this, but I fear that if > things don't improve really soon that firewire becomes unkeepable for UP > kernels as well..... I'd like to bring up another solution again. Why not build it and put in in a separate rpm. Ship it in an unsupported dir or something like that. So those people that don't have any problems can install it easily. And those who have problems can test easily and debug. -- Thorsten Leemhuis From arjanv at redhat.com Mon Sep 13 14:47:45 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 13 Sep 2004 16:47:45 +0200 Subject: the fate of firewire In-Reply-To: <1095086786.1860.23.camel@localhost.localdomain> References: <1095060813.2624.12.camel@laptop.fenrus.com> <1095086786.1860.23.camel@localhost.localdomain> Message-ID: <20040913144745.GC24944@devserv.devel.redhat.com> On Mon, Sep 13, 2004 at 04:46:26PM +0200, Thorsten Leemhuis wrote: > > I'd like to bring up another solution again. Why not build it and put in > in a separate rpm. Ship it in an unsupported dir or something like that. > So those people that don't have any problems can install it easily. And > those who have problems can test easily and debug. I can't package that right so I rather don't. If someone else thinks he can package it right he's free to do so of course :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Sep 13 14:54:06 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 13 Sep 2004 16:54:06 +0200 Subject: the fate of firewire In-Reply-To: <20040913144745.GC24944@devserv.devel.redhat.com> References: <1095060813.2624.12.camel@laptop.fenrus.com> <1095086786.1860.23.camel@localhost.localdomain> <20040913144745.GC24944@devserv.devel.redhat.com> Message-ID: <1095087246.1860.26.camel@localhost.localdomain> Am Montag, den 13.09.2004, 16:47 +0200 schrieb Arjan van de Ven: > On Mon, Sep 13, 2004 at 04:46:26PM +0200, Thorsten Leemhuis wrote: > > > > I'd like to bring up another solution again. Why not build it and put in > > in a separate rpm. Ship it in an unsupported dir or something like that. > > So those people that don't have any problems can install it easily. And > > those who have problems can test easily and debug. > > I can't package that right so I rather don't. > If someone else thinks he can package it right he's free to do so of > course :) Just out of curiosity, could you give me one or to details on the problem(s)? Thanks. -- Thorsten Leemhuis From russell at coker.com.au Mon Sep 13 15:24:10 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 14 Sep 2004 01:24:10 +1000 Subject: /dev/dri/* and SE Linux In-Reply-To: <4145B0E9.80000@redhat.com> References: <200409111934.19937.russell@coker.com.au> <4145B0E9.80000@redhat.com> Message-ID: <200409140124.10133.russell@coker.com.au> On Tue, 14 Sep 2004 00:38, Daniel J Walsh wrote: > Russell Coker wrote: > >In the latest CVS SE Linux policy xserver_macros.te has: > > > ># Create and access /dev/dri devices. > >allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; > >allow $1_xserver_t dri_device_t:chr_file create_file_perms; > > > >[...] > > > ># Do not flood audit logs due to device node creation attempts. > >dontaudit $1_xserver_t device_t:chr_file create; > > > >[...] > > > >allow $1_xserver_t device_t:dir { create }; # Create and access /dev/dri devices. allow $1_xserver_t device_t:dir create; file_type_auto_trans($1_xserver_t, device_t, dri_device_t, chr_file) OK, the above should do all that's needed, replacing the other rules above. You can replace the current policy with that, the current policy definately doesn't work while the above should give the same result that the old policy did before we changed the type of /dev/dri. Of course it would be nice to get this tested by someone who uses and understands DRI... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From alan at redhat.com Mon Sep 13 15:36:44 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 13 Sep 2004 11:36:44 -0400 Subject: the fate of firewire In-Reply-To: <20040913134408.GA24944@devserv.devel.redhat.com> References: <1095060813.2624.12.camel@laptop.fenrus.com> <1095082310.17600.2.camel@otto.amantes> <20040913134408.GA24944@devserv.devel.redhat.com> Message-ID: <20040913153644.GC32349@devserv.devel.redhat.com> On Mon, Sep 13, 2004 at 03:44:08PM +0200, Arjan van de Ven wrote: > On Mon, Sep 13, 2004 at 03:31:50PM +0200, Thomas Vander Stichele wrote: > > > ... but firewire currently are modules, right ? I don't think disabling > > compilation completely makes any sense at all. People for whom firewire > > doesn't work well should just not use it > > problem is that it gets autoloaded Thats fixable alias it off with a comment of "# sure smells like dead fish" in the default modules conf 8) From russell at coker.com.au Mon Sep 13 16:14:23 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 14 Sep 2004 02:14:23 +1000 Subject: the fate of firewire In-Reply-To: <20040913140439.GA1150202@hiwaay.net> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913135350.GA20037@srv01.cluenet.de> <20040913140439.GA1150202@hiwaay.net> Message-ID: <200409140214.23872.russell@coker.com.au> On Tue, 14 Sep 2004 00:04, Chris Adams wrote: > Once upon a time, Daniel Roesen said: > > On Mon, Sep 13, 2004 at 08:31:46AM -0500, Rex Dieter wrote: > > > redhat would end up "supporting" > > > 5-6 releases (going back ~3 years @ ~ 6 month innovation cycle), which > > > would be unmanageable. Is that really what you want? > > > > Yes, it is what I want. But obviously nothing Red Hat does provide > > (anymore). > > AFAIK nobody provides that. When I looked a while back, most of the > free OS distributions only commit to 1 year of updates for a particular > release. The commercial OS vendors have longer support, but don't have > full new releases as often. Debian supports each version until the next one is released. That is usually much longer than one year. Of course the down-side as far as Daniel is concerned is the lack of regular updates. I think that the release schedule of RHEL is pretty good. Waiting one year for the latest feature isn't such a big deal (IMHO). Let's face facts, if you use the new features as soon as they are released by the upstream developers then you will discover that most of them don't work anyway. The release schedule for RHEL is quite aggressive when you consider all the new stuff that's going in! -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From kyrre at solution-forge.net Mon Sep 13 16:37:28 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 13 Sep 2004 18:37:28 +0200 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <20040912145741.GB7623@rednote.net> References: <1094938008.2715.59.camel@kyrre> <20040911231120.GF4297@rednote.net> <1094944811.4796.7.camel@kyrre> <20040912145741.GB7623@rednote.net> Message-ID: <1095093448.28790.7.camel@kyrre> Yes, i have found it, and i am downloading the "eawpats" src.rpm right now. (hmm... sound-font source-rpm?) I will (as soon as i have figured out to do with a "source"-rpm... Any help, links etc? I feel ashamed not knowing how to handle them!) test those patches asap, and will when i have tested them contact ccrma for licensing information etc. And if all goes well, ill find some gui for it - i have found kmid, but not tested it this far. Maybe find a GTK-based one as well, or persuade a friend of mine into learning me GTK :P if i cant find one (maybe make it python-based?). Then i will report back to bugzilla (which version? i am currently running FC2) with a RFE. Does that seem good? First time i acctually do any real work to enchase Fedora Core :D Kyrre Ness Sj?b?k s?n, 12.09.2004 kl. 16.57 skrev Janina Sajka: > Kyrre Ness Sjobak writes: > > s?n, 12.09.2004 kl. 01.11 skrev Janina Sajka: > > > Kyrre Ness Sjobak writes: > > > > Hmm... Does anybody know why Fedora haven't included a simple > > > > midi-player, which simply sends things to your soundcard for rendering, > > > > which in turn plays it?? And does anybody know about a good such > > > > program? > > > > > > > Huh? Did timidity++ disappear? Or, am I misunderstanding your question? > > > > ... ... > > > > Hmm... what if i (as many others) are so lucky to have a HW-based > > midi-playing soundcard (such as the AWE 64)? Methinks maybe they wants > > to use it... > > > > Are you aware of Planet CCRMA which is an entire distribution for > musicians based on Fedora? > > http://ccrma.stanford.edu/planetccrma/software/ > > I mention CCRMA because it's Fedora and rpm based and aimed at > professional musicians. > > However, I would also agree that support for driving MIDI instruments > directly is weak on Linux. So, I heartily second Jeff's suggestion to > get involved adding MIDI support to gstreamer--if that's something > you're able to contribute. > > > Could it be possible to do something like MS does - in the gstreamer > > setup, give an option to either use timidity (with a full patchset - the > > patches included don't even rival my old SB16, > > The CCRMA repository does have timidity with a better set of > instruments, fortunately. > From smoogen at lanl.gov Mon Sep 13 17:12:28 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Mon, 13 Sep 2004 11:12:28 -0600 Subject: vsftpd.conf In-Reply-To: <1094946963.27052.17.camel@stargrazer> References: <1094856081.13137.7.camel@dilithium.bromstraat.net> <20040911000944.4905.qmail@web25301.mail.ukl.yahoo.com> <20040911054206.GB10610@angus.ind.WPI.EDU> <1094895556.8133.2.camel@neuwklin.ad.icdw.co.uk> <1094933588.2715.10.camel@kyrre> <1094944717.24973.4.camel@neuwklin.ad.icdw.co.uk> <1094945111.27052.6.camel@stargrazer> <41438C5D.2020609@lanl.gov> <1094946963.27052.17.camel@stargrazer> Message-ID: <4145D4FC.904@lanl.gov> Sean Middleditch wrote: > On Sat, 2004-09-11 at 17:38 -0600, Stephen J Smoogen wrote: > >>Sean Middleditch wrote: >> >>>On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote: >>> >>> >>>>Why not take a BSD approach and give them the option when installing the >>>>package, say for example... >>>> >>>># rpm -i vsftp....rpm >>>>Would you like to enable Anonymous logins? (y/n) [N] >>>>Would you like to enable Local user Logins? (y/n) [N] >>> >>> >>>Because RPMs are absolutely never ever supposed to ask questions. >>> >>>- What if the RPM is being installed non-interactively? >>>- What if the RPM is being installed with a GUI tool? >>>- What if the user doesn't understand English? >>> >>>And then you get into the general usability problems - are the question >>>phrased properly? Is "Y/N" an appropriate prompt? etc. >>> >> >>Each rpm could then drop a scriptlet into a directory that gui would >>then be able to run to set things up for it. >> >>/etc/system-setup/ >> vsftpd.py >> httpd.py >> samba.py >> kill_my_harddrive.py >> >>And then the system-setup program would display the questions, get the >>answers... and possibly be able to bring the system into at least a >>bare-bones configuration. >> >>Reset to original configuration [Yes] [No] [Help] > > > Again, what if the configuration data isn't translated into the user's > language? They end up getting some vital system configuration question > they can't possibly answer? Why the heck does this *need* to be done at > install time? If you are going to make a configuration tool, let the > user run it them self after install. Uhm.. this is what I am talking about with the 'system-setup program'. Maybe I was not too clear, but I think you are just looking for a fight. Not going to get one today sorry. -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From hp at redhat.com Mon Sep 13 18:42:35 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 13 Sep 2004 14:42:35 -0400 Subject: "Stateless Linux" project Message-ID: <1095100955.5481.14.camel@localhost.localdomain> Hi, Red Hat engineering is starting a new project we're calling "stateless Linux" for lack of a better name - some components of this are already in Rawhide, and others will be appearing shortly. We've been keeping the project a little bit quiet at first, but now we've written it up in some detail: - an overview document, available from http://people.redhat.com/~hp/stateless/ - a HOWTO document and a couple associated RPMs, available from http://people.redhat.com/dmalcolm/stateless/ There aren't many new RPMs for this, because stateless Linux isn't a single codebase or package, it's a set of changes across the distribution (you might think of it as a "philosophy"). Most of the changes are already in Rawhide (the highlights are mentioned in the StatelessLinux.pdf document). Appreciate feedback, especially from anyone who has time to try out the HOWTO. We expect the code to change quite a bit as issues and suggestions come in. Havoc From smoogen at lanl.gov Mon Sep 13 19:13:38 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Mon, 13 Sep 2004 13:13:38 -0600 Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <4145F162.6030903@lanl.gov> Havoc Pennington wrote: > Hi, > > Red Hat engineering is starting a new project we're calling > "stateless Linux" for lack of a better name - some components of this > are already in Rawhide, and others will be appearing shortly. > > We've been keeping the project a little bit quiet at first, but now > we've written it up in some detail: > > - an overview document, available from > http://people.redhat.com/~hp/stateless/ > > - a HOWTO document and a couple associated RPMs, available from > http://people.redhat.com/dmalcolm/stateless/ > > There aren't many new RPMs for this, because stateless Linux isn't a > single codebase or package, it's a set of changes across the > distribution (you might think of it as a "philosophy"). Most of the > changes are already in Rawhide (the highlights are mentioned in the > StatelessLinux.pdf document). > > Appreciate feedback, especially from anyone who has time to try out > the HOWTO. We expect the code to change quite a bit as issues and > suggestions come in. > Ok I havent had time to deal with the HOWTO.. but this does look very good. A good many 'secure' locations will be looking for thick thin clients and the problems I have had with current solutions is that an update to the system was a pain in the butt. Having an architecture that can be used to update cleanly 8000 diskless machines without having to take each one down, rebuild the NFS diskspace from a master copy, and reboot is a win. -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From kyrre at solution-forge.net Mon Sep 13 19:24:06 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 13 Sep 2004 21:24:06 +0200 Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <1095103445.29494.1.camel@kyrre> Hmm... seems like a good idea, but your pdf is (at least on my computer, by gnome-pdf-viewer) completly unreadable: all i get is a page with some sqares randomly distibuted... man, 13.09.2004 kl. 20.42 skrev Havoc Pennington: > Hi, > > Red Hat engineering is starting a new project we're calling > "stateless Linux" for lack of a better name - some components of this > are already in Rawhide, and others will be appearing shortly. > > We've been keeping the project a little bit quiet at first, but now > we've written it up in some detail: > > - an overview document, available from > http://people.redhat.com/~hp/stateless/ > > - a HOWTO document and a couple associated RPMs, available from > http://people.redhat.com/dmalcolm/stateless/ > > There aren't many new RPMs for this, because stateless Linux isn't a > single codebase or package, it's a set of changes across the > distribution (you might think of it as a "philosophy"). Most of the > changes are already in Rawhide (the highlights are mentioned in the > StatelessLinux.pdf document). > > Appreciate feedback, especially from anyone who has time to try out > the HOWTO. We expect the code to change quite a bit as issues and > suggestions come in. > > Havoc > > From hp at redhat.com Mon Sep 13 19:32:31 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 13 Sep 2004 15:32:31 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095103445.29494.1.camel@kyrre> References: <1095100955.5481.14.camel@localhost.localdomain> <1095103445.29494.1.camel@kyrre> Message-ID: <1095103951.5481.18.camel@localhost.localdomain> On Mon, 2004-09-13 at 21:24 +0200, Kyrre Ness Sjobak wrote: > Hmm... seems like a good idea, but your pdf is (at least on my computer, > by gnome-pdf-viewer) completly unreadable: all i get is a page with some > sqares randomly distibuted... > Can you try xpdf/acroread so we know if it's your computer, the pdf, or gnome-pdf-viewer specifically? Havoc From kyrre at solution-forge.net Mon Sep 13 19:33:44 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 13 Sep 2004 21:33:44 +0200 Subject: "Stateless Linux" project In-Reply-To: <1095103951.5481.18.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <1095103445.29494.1.camel@kyrre> <1095103951.5481.18.camel@localhost.localdomain> Message-ID: <1095104024.29494.7.camel@kyrre> Seems to be gnome-pdf - ggv reads it no problem ;) So we have just discovered a bug in gnome-pdf in the process then. man, 13.09.2004 kl. 21.32 skrev Havoc Pennington: > On Mon, 2004-09-13 at 21:24 +0200, Kyrre Ness Sjobak wrote: > > Hmm... seems like a good idea, but your pdf is (at least on my computer, > > by gnome-pdf-viewer) completly unreadable: all i get is a page with some > > sqares randomly distibuted... > > > > Can you try xpdf/acroread so we know if it's your computer, the pdf, or > gnome-pdf-viewer specifically? > > Havoc > > From perbj at stanford.edu Mon Sep 13 19:38:36 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Mon, 13 Sep 2004 12:38:36 -0700 Subject: gpdf bug [Re: "Stateless Linux" project] In-Reply-To: <1095103951.5481.18.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <1095103445.29494.1.camel@kyrre> <1095103951.5481.18.camel@localhost.localdomain> Message-ID: <1095104316.2903.38.camel@localhost.localdomain> On Mon, 2004-09-13 at 12:32, Havoc Pennington wrote: > Can you try xpdf/acroread so we know if it's your computer, the pdf, or > gnome-pdf-viewer specifically? It works fine in xpdf, it's the gpdf version in FC2 that's borked - lots of PDFs generated by OpenOffice look like this in gpdf. Possibly fixed upstream - is it OK in rawhide? Report in the Red Hat bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124056 Upstream (Gnome bugzilla) indicates that it should be fixed: http://bugzilla.gnome.org/show_bug.cgi?id=140337 resolved as duplicate of http://bugzilla.gnome.org/show_bug.cgi?id=148362 /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From hp at redhat.com Mon Sep 13 19:48:28 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 13 Sep 2004 15:48:28 -0400 Subject: gpdf bug [Re: "Stateless Linux" project] In-Reply-To: <1095104316.2903.38.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <1095103445.29494.1.camel@kyrre> <1095103951.5481.18.camel@localhost.localdomain> <1095104316.2903.38.camel@localhost.localdomain> Message-ID: <1095104908.5481.20.camel@localhost.localdomain> On Mon, 2004-09-13 at 12:38 -0700, Per Bjornsson wrote: > On Mon, 2004-09-13 at 12:32, Havoc Pennington wrote: > > > Can you try xpdf/acroread so we know if it's your computer, the pdf, or > > gnome-pdf-viewer specifically? > > It works fine in xpdf, it's the gpdf version in FC2 that's borked - lots > of PDFs generated by OpenOffice look like this in gpdf. Possibly fixed > upstream - is it OK in rawhide? > rawhide gpdf seems to work for me, so maybe it's fixed, unless it's an issue of fonts available or something. Havoc From kyrre at solution-forge.net Mon Sep 13 19:51:22 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 13 Sep 2004 21:51:22 +0200 Subject: gpdf bug [Re: "Stateless Linux" project] In-Reply-To: <1095104908.5481.20.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <1095103445.29494.1.camel@kyrre> <1095103951.5481.18.camel@localhost.localdomain> <1095104316.2903.38.camel@localhost.localdomain> <1095104908.5481.20.camel@localhost.localdomain> Message-ID: <1095105081.29775.4.camel@kyrre> If you can give me an url where i can download the rawhide rpm - i shall do so, in order to test it. Then we can be shure that there is no font issues etc. Hmm... does not fedora use a common folder for fonts, shared amongst all programs? BTW. if that was made by oo it certainly looked very nice! And the content was also extremly exiting - especcially the laptop stuff. I might even consider running that (home folder stuff) at home! I do administrate a small school network, and we use a small self-written tool called admin-script to get the thick-clients in sync. man, 13.09.2004 kl. 21.48 skrev Havoc Pennington: > On Mon, 2004-09-13 at 12:38 -0700, Per Bjornsson wrote: > > On Mon, 2004-09-13 at 12:32, Havoc Pennington wrote: > > > > > Can you try xpdf/acroread so we know if it's your computer, the pdf, or > > > gnome-pdf-viewer specifically? > > > > It works fine in xpdf, it's the gpdf version in FC2 that's borked - lots > > of PDFs generated by OpenOffice look like this in gpdf. Possibly fixed > > upstream - is it OK in rawhide? > > > > rawhide gpdf seems to work for me, so maybe it's fixed, unless it's an > issue of fonts available or something. > > Havoc > > From mike at flyn.org Mon Sep 13 19:52:19 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 13 Sep 2004 14:52:19 -0500 (CDT) Subject: /dev/dri/* and SE Linux In-Reply-To: <200409140124.10133.russell@coker.com.au> References: <200409111934.19937.russell@coker.com.au> <4145B0E9.80000@redhat.com> <200409140124.10133.russell@coker.com.au> Message-ID: <49502.66.151.13.191.1095105139.squirrel@66.151.13.191> >>> In the latest CVS SE Linux policy xserver_macros.te has: >>> >>> # Create and access /dev/dri devices. >>> allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; >>> allow $1_xserver_t dri_device_t:chr_file create_file_perms; >>> >>> [...] >>> >>> # Do not flood audit logs due to device node creation attempts. >>> dontaudit $1_xserver_t device_t:chr_file create; >>> >>> [...] >>> >>> allow $1_xserver_t device_t:dir { create }; > # Create and access /dev/dri devices. > allow $1_xserver_t device_t:dir create; > file_type_auto_trans($1_xserver_t, device_t, dri_device_t, chr_file) > > OK, the above should do all that's needed, replacing the other rules > above. You can replace the current policy with that, the current policy > definately doesn't work while the above should give the same result that > the old policy did before we changed the type of /dev/dri. > > Of course it would be nice to get this tested by someone who uses and > understands DRI... For what its worth, I entered a bug into bugzilla about this a while ago: DRI use denied by Red Hat SELinux policy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124837 -- Mike From mike at flyn.org Mon Sep 13 19:50:43 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 13 Sep 2004 14:50:43 -0500 (CDT) Subject: /dev/dri/* and SE Linux In-Reply-To: <200409140124.10133.russell@coker.com.au> References: <200409111934.19937.russell@coker.com.au> <4145B0E9.80000@redhat.com> <200409140124.10133.russell@coker.com.au> Message-ID: <47766.66.151.13.191.1095105043.squirrel@66.151.13.191> >>> In the latest CVS SE Linux policy xserver_macros.te has: >>> >>> # Create and access /dev/dri devices. >>> allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; >>> allow $1_xserver_t dri_device_t:chr_file create_file_perms; >>> >>> [...] >>> >>> # Do not flood audit logs due to device node creation attempts. >>> dontaudit $1_xserver_t device_t:chr_file create; >>> >>> [...] >>> >>> allow $1_xserver_t device_t:dir { create }; > # Create and access /dev/dri devices. > allow $1_xserver_t device_t:dir create; > file_type_auto_trans($1_xserver_t, device_t, dri_device_t, chr_file) > > OK, the above should do all that's needed, replacing the other rules > above. You can replace the current policy with that, the current policy > definately doesn't work while the above should give the same result that > the old policy did before we changed the type of /dev/dri. > > Of course it would be nice to get this tested by someone who uses and > understands DRI... For what its worth, I entered a bug into bugzilla about this a while ago: DRI use denied by Red Hat SELinux policy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124837 -- Mike From smoogen at lanl.gov Mon Sep 13 20:06:24 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Mon, 13 Sep 2004 14:06:24 -0600 Subject: "Stateless Linux" project In-Reply-To: <1095103951.5481.18.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <1095103445.29494.1.camel@kyrre> <1095103951.5481.18.camel@localhost.localdomain> Message-ID: <4145FDC0.6040506@lanl.gov> Havoc Pennington wrote: > On Mon, 2004-09-13 at 21:24 +0200, Kyrre Ness Sjobak wrote: > >>Hmm... seems like a good idea, but your pdf is (at least on my computer, >>by gnome-pdf-viewer) completly unreadable: all i get is a page with some >>sqares randomly distibuted... >> > > > Can you try xpdf/acroread so we know if it's your computer, the pdf, or > gnome-pdf-viewer specifically? > acroread seemed to display it ok.. but really really pegged X cpu usage in RHEL-3. > Havoc > > > -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From john.hearns at clustervision.com Mon Sep 13 20:25:07 2004 From: john.hearns at clustervision.com (John Hearns) Date: Mon, 13 Sep 2004 21:25:07 +0100 Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <1095107107.6254.85.camel@vigor12> On Mon, 2004-09-13 at 19:42, Havoc Pennington wrote: > Hi, > > Red Hat engineering is starting a new project we're calling > "stateless Linux" for lack of a better name - some components of this > are already in Rawhide, and others will be appearing shortly. > Fantastic project. A lot of these ideas are already used in Beowulf-type clustering (our clusters install by similar methods) But that's not to claim its all been done - not by a long way. I like the use of an LDAP server to store the snapshot version information etc. From miles at milessabin.com Mon Sep 13 20:36:35 2004 From: miles at milessabin.com (Miles Sabin) Date: Mon, 13 Sep 2004 21:36:35 +0100 Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <200409132136.35379.miles@milessabin.com> Havoc Pennington wrote, > Appreciate feedback, especially from anyone who has time to try out > the HOWTO. We expect the code to change quite a bit as issues and > suggestions come in. I think this is a fine idea. I have a few questions tho' ... Outside of largish corporates where clones are common, there are smaller environments where machines are mostly (95%+, say) similar, but where there are machine-by-machine variations which fall outside the set of things which are covered by per-user homes or hardware auto- configuration. For instance, differences in which services should be running, their configuration, or minor kernel tweaks. Are such environments outside the scope of this proposal, or is there some plan to support per-machine or per-group/class deltas from a common baseline? One thing that's always stopped me from bothering with NFS mounted homes is that for me a different machine quite often implies a different role, hence that the stuff that's appropriate to be in my home varies. This also tends to be a delta from a common baseline, so handling the variability by having distinct users for each role doesn't seem like quite the right answer. Caching doesn't seem likely to change this, and the "recreate Joe's workstation" scenario in the document seems to wander into this kind of territory. Do you have any thoughts about handling this? Slightly related to the previous two questions ... My laptop moves between my home network, my work network, business-client networks, connected by dialup ISP, and disconnected. In each scenario the services running, their configuration, and what's appropriate for my home dir vary slightly. Even tho' this is pretty clearly beyond the scope of your proposal, there seems to be at least something in common: the setup is mostly the same, but there are some small deltas. Would it make sense to have a common mechanism to handle this? I think all my questions boil down to: looks great for the 95% of stuff which stays the same, but how do you deal with the 5% of stuff which varies? And can you do it in a way which is 95% less hassle than treating the machines as completely separate entities? Cheers, Miles From hp at redhat.com Mon Sep 13 20:58:52 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 13 Sep 2004 16:58:52 -0400 Subject: "Stateless Linux" project In-Reply-To: <200409132136.35379.miles@milessabin.com> References: <1095100955.5481.14.camel@localhost.localdomain> <200409132136.35379.miles@milessabin.com> Message-ID: <1095109132.13059.22.camel@localhost.localdomain> On Mon, 2004-09-13 at 21:36 +0100, Miles Sabin wrote: > > I think all my questions boil down to: looks great for the 95% of stuff > which stays the same, but how do you deal with the 5% of stuff which > varies? And can you do it in a way which is 95% less hassle than > treating the machines as completely separate entities? Right, for a sufficiently low number of machines, setting up an elaborate framework is going to be more annoying than just managing them all separately. Though we should try to make the framework easy enough to use that it makes sense even for a single machine, if we can. I think there are maybe a couple answers to your question. 1) Should there be some kind of OS 'layering' (words like 'profile' or 'inheritance' come to mind). This is possible today with something like RHN, which can describe a machine install as a set of RPMs and a set of config files. Today you can have RHN keep machines in sync directly by syncing their config files and package lists. In the future it might make sense if RHN could stage each profile to a file tree, and then the file tree could be mounted diskless (or synced on a file level) by the machines that have that profile. There are other setups people use for this too. A lot of customers we have really do not have package list profiles, though; they have one "profile" for the whole company, and only vary the machines by config file. Important caveat: part of enabling this in most cases is to provide apps via NFS rather than installing them on each system, so the RPM package list is just a core rather than all the apps. But the idea is that any system on the network can run any workload (workload = service, or even have desktop users log in). You then keep a central mapping that assigns workloads to specific machines, but you can change that mapping as required. This seems like the ideal, while in one sense "profiles" feels like a workaround. 2) How can you avoid a separate 'profile' to make small changes. This is a matter of pulling state out of the OS install and config files. We've been approaching this by saying there's a toolbox you can use. Here are some of the approaches in the toolbox: - dynamic/automatic configuration - look up configuration from a central place, e.g. a directory server, or even a file share - write scripts that examine the machine and determine its desired configuration based on hardware, network location, or by looking up configuration from a central place - move the configuration to be per-user rather than per-computer So some of this can be done out of the box in the OS; for example for desktops, NetworkManager helps address network configuration that varies between machines. A good kudzu helps avoid hardware config in general. etc. But you'd expect a local site to do some work as well. Anyway, to the extent that machines can vary by workload rather than by install profile, so there can be a single install profile, that seems desirable. I'm kind of sleepy so sorry if this answer is sort of muddled; but I think your questions really get to the heart of what we're trying to solve here. Havoc From otaylor at redhat.com Mon Sep 13 21:00:15 2004 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 13 Sep 2004 17:00:15 -0400 Subject: gpdf bug [Re: "Stateless Linux" project] In-Reply-To: <1095105081.29775.4.camel@kyrre> References: <1095100955.5481.14.camel@localhost.localdomain> <1095103445.29494.1.camel@kyrre> <1095103951.5481.18.camel@localhost.localdomain> <1095104316.2903.38.camel@localhost.localdomain> <1095104908.5481.20.camel@localhost.localdomain> <1095105081.29775.4.camel@kyrre> Message-ID: <1095109215.2898.47.camel@localhost.localdomain> On Mon, 2004-09-13 at 15:51, Kyrre Ness Sjobak wrote: > If you can give me an url where i can download the rawhide rpm - i shall > do so, in order to test it. Then we can be shure that there is no font > issues etc. > > Hmm... does not fedora use a common folder for fonts, shared amongst all > programs? I don't think it's a problem with gpdf finding the fonts, but rather it knowing how to use them properly. (Also, the fonts are probably actually embedded in the PDF file.) Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dcbw at redhat.com Mon Sep 13 21:13:21 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 13 Sep 2004 17:13:21 -0400 Subject: gpdf bug [Re: "Stateless Linux" project] In-Reply-To: <1095109215.2898.47.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <1095103445.29494.1.camel@kyrre> <1095103951.5481.18.camel@localhost.localdomain> <1095104316.2903.38.camel@localhost.localdomain> <1095104908.5481.20.camel@localhost.localdomain> <1095105081.29775.4.camel@kyrre> <1095109215.2898.47.camel@localhost.localdomain> Message-ID: <1095110001.31982.2.camel@dcbw.boston.redhat.com> OOo will attempt to embed fonts if the TrueType font's license allows OOo to do so (permission to embed is stored in the font). Dan On Mon, 2004-09-13 at 17:00 -0400, Owen Taylor wrote: > On Mon, 2004-09-13 at 15:51, Kyrre Ness Sjobak wrote: > > If you can give me an url where i can download the rawhide rpm - i shall > > do so, in order to test it. Then we can be shure that there is no font > > issues etc. > > > > Hmm... does not fedora use a common folder for fonts, shared amongst all > > programs? > > I don't think it's a problem with gpdf finding the fonts, but rather > it knowing how to use them properly. (Also, the fonts are probably > actually embedded in the PDF file.) > > Regards, > Owen > From jamesaharrisonuk at yahoo.co.uk Mon Sep 13 21:45:25 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Mon, 13 Sep 2004 14:45:25 -0700 (PDT) Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <20040913214525.70046.qmail@web25305.mail.ukl.yahoo.com> Hello, I think this is a great idea and I work for a company that could make use of this. However, I have never been able to get our 3COM cards working with PXE. Ive tried many things and read different HOWTOs, short of changing to different network cards. I have just tried the dhcp configuration in the "Stateless Linux" project HOWTO document and still the client wont use the server: "No DHCP or ProxyDHCP offers found" Any ideas? James --- Havoc Pennington wrote: > Hi, > > Red Hat engineering is starting a new project we're calling > "stateless Linux" for lack of a better name - some components of this > are already in Rawhide, and others will be appearing shortly. > > We've been keeping the project a little bit quiet at first, but now > we've written it up in some detail: > > - an overview document, available from > hthttp/people.reredhatom/~hp/stateless/ > > - a HOHOWTOocument and a couple associated RPRPMsavailable from > hthttp/people.reredhatom/dmdmalcolmtateless/ > > There aren't many new RPRPMsor this, because stateless Linux isn't a > single cocodebaser package, it's a set of changes across the > distribution (you might think of it as a "philosophy"). Most of the > changes are already in Rawhide (the highlights are mentioned in the > StStatelessLinuxdpdfocument). > > Appreciate feedback, especially from anyone who has time to try out > the HOHOWTOWe expect the code to change quite a bit as issues and > suggestions come in. > > Havoc > > > > -- > fedora-dedevelist mailing list > fedora-dedevelist at reredhatom > hthttp/wwwwweredhatom/mailman/lilistinfoedora-dedevelist > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From paul at frields.com Mon Sep 13 21:51:50 2004 From: paul at frields.com (Paul W. Frields) Date: Mon, 13 Sep 2004 17:51:50 -0400 Subject: "Stateless Linux" project In-Reply-To: <20040913214525.70046.qmail@web25305.mail.ukl.yahoo.com> References: <20040913214525.70046.qmail@web25305.mail.ukl.yahoo.com> Message-ID: <1095112310.21495.6.camel@bettie.internal.frields.org> On Mon, 2004-09-13 at 17:45, James Harrison wrote: > I think this is a great idea and I work for a company that could make use of > this. > > However, I have never been able to get our 3COM cards working with PXE. Ive > tried many things and read different HOWTOs, short of changing to different > network cards. > > I have just tried the dhcp configuration in the "Stateless Linux" project > HOWTO document and still the client wont use the server: "No DHCP or ProxyDHCP > offers found" Have you checked /var/log/messages on the server? If you haven't altered the default configuration for syslog, DHCP DISCOVER/OFFER/etc. messages should appear there IIRC. Is the server receiving the client's query? If not, you may have to solve a network problem first. -- Paul W. Frields, RHCE From Theodore.Papadopoulo at sophia.inria.fr Mon Sep 13 21:52:59 2004 From: Theodore.Papadopoulo at sophia.inria.fr (Theodore Papadopoulo) Date: Mon, 13 Sep 2004 23:52:59 +0200 Subject: "Stateless Linux" project In-Reply-To: Your message of "Mon, 13 Sep 2004 14:42:35 EDT." <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <200409132152.i8DLqxnT011753@taquilee.inria.fr> I just read the first of the two documents and this proposal looks extremely exciting. Actually, I believe it raises (and partially answers) a lot of problems that people face when deploying linux on large sets of computers. >From the philosophical point of view, one thing that comes to mind is that often you might want to explicitly add some hierarchy into the state-less infrastructure/description. What I mean by this is that often various levels of the operating system are dealt with different groups and you want to allow them to interact with minimum effort. Eg if you have a company wide linux base with a group dealing with hardware/security and networking and subgroups of small teams that require some specific software combinations or configuration for their computers, it would be nice to let the first group maintain the core of the systems and let the subgroups make "refinements" over the standard base independently. This is certainly doable up to some level: having a subgroup define their application software settings is fairly easy and (maybe with some inconvenience) seems to be doable with the current scheme. -------------------------------------------------------------------- Theodore Papadopoulo Email: Theodore.Papadopoulo at sophia.inria.fr Tel: (33) 04 92 38 76 01 -------------------------------------------------------------------- From dmalcolm at redhat.com Mon Sep 13 21:54:20 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 13 Sep 2004 17:54:20 -0400 Subject: "Stateless Linux" project In-Reply-To: <20040913214525.70046.qmail@web25305.mail.ukl.yahoo.com> References: <20040913214525.70046.qmail@web25305.mail.ukl.yahoo.com> Message-ID: <1095112460.4441.4.camel@cassandra.boston.redhat.com> On Mon, 2004-09-13 at 14:45 -0700, James Harrison wrote: > Hello, > > I think this is a great idea and I work for a company that could make use of > this. > > However, I have never been able to get our 3COM cards working with PXE. Ive > tried many things and read different HOWTOs, short of changing to different > network cards. > > I have just tried the dhcp configuration in the "Stateless Linux" project > HOWTO document and still the client wont use the server: "No DHCP or ProxyDHCP > offers found" > > Any ideas? You could try running ethereal to sniff what network traffic (if any) is passing between client and server. [snip] From miles at milessabin.com Mon Sep 13 21:55:56 2004 From: miles at milessabin.com (Miles Sabin) Date: Mon, 13 Sep 2004 22:55:56 +0100 Subject: "Stateless Linux" project In-Reply-To: <1095109132.13059.22.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <200409132136.35379.miles@milessabin.com> <1095109132.13059.22.camel@localhost.localdomain> Message-ID: <200409132255.56541.miles@milessabin.com> Havoc Pennington wrote, > Right, for a sufficiently low number of machines, setting up an > elaborate framework is going to be more annoying than just managing > them all separately. Though we should try to make the framework easy > enough to use that it makes sense even for a single machine, if we > can. Do you have any feel for how low that number is given the current stage of development? > I think there are maybe a couple answers to your question. > > 1) Should there be some kind of OS 'layering' (words like 'profile' > or 'inheritance' come to mind). > But the idea is that any system on the network can run any workload > (workload = service, or even have desktop users log in). You then > keep a central mapping that assigns workloads to specific machines, > but you can change that mapping as required. > > This seems like the ideal, while in one sense "profiles" feels like a > workaround. I'm not so sure about this. There are many scenarios where it makes sense to restrict particular roles to a specific set of hosts, or to restrict particular hosts to a specific set of roles. Security is one (eg., to take an extreme example, I don't want a firewall to be able to run any workload) but it's not the only one. > 2) How can you avoid a separate 'profile' to make small changes. > This is a matter of pulling state out of the OS install and config > files. We've been approaching this by saying there's a toolbox you > can use. Here are some of the approaches in the toolbox: > > - dynamic/automatic configuration > - look up configuration from a central place, e.g. a directory > server, or even a file share > - write scripts that examine the machine and determine its desired > configuration based on hardware, network location, or by looking > up configuration from a central place > - move the configuration to be per-user rather than per-computer > > So some of this can be done out of the box in the OS; for example for > desktops, NetworkManager helps address network configuration that > varies between machines. A good kudzu helps avoid hardware config in > general. etc. But you'd expect a local site to do some work as well. As you say, a lot of this works already ... I work with parallel applications on clusters, and common configuration in a shared filesystem with symmetry-breaking via hostname works fabulously well given how trivial it is to set up (until the NFS server goes down, that is ;-). But it's pretty much limited to machines which are always connected to the same network. Extending this to laptops which move between networks, or no network at all could be a lot more challenging. OTOH, a scheme which could handle that case as well would be a huge bonus. > Anyway, to the extent that machines can vary by workload rather than > by install profile, so there can be a single install profile, that > seems desirable. > > I'm kind of sleepy so sorry if this answer is sort of muddled; but I > think your questions really get to the heart of what we're trying to > solve here. No, I think that it was clear and to the point. And I think it's an excellent problem to be trying to solve. Cheers, Miles From nutello at sweetness.com Mon Sep 13 22:02:45 2004 From: nutello at sweetness.com (Rudi Chiarito) Date: Tue, 14 Sep 2004 00:02:45 +0200 Subject: "Stateless Linux" project In-Reply-To: <20040913214525.70046.qmail@web25305.mail.ukl.yahoo.com> References: <1095100955.5481.14.camel@localhost.localdomain> <20040913214525.70046.qmail@web25305.mail.ukl.yahoo.com> Message-ID: <20040913220245.GS14918@server4.8080.it> On Mon, Sep 13, 2004 at 02:45:25PM -0700, James Harrison wrote: > However, I have never been able to get our 3COM cards working with PXE. Ive > tried many things and read different HOWTOs, short of changing to different > network cards. I think I ran into a similar problem last year when setting up a cluster. Recent Tornado cards had a larger Flash chip which was not supported yet by the flashing tools of the time. Does that ring a bell? -- Rudi From foolish at fedoraforum.org Mon Sep 13 22:03:48 2004 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Tue, 14 Sep 2004 00:03:48 +0200 Subject: gpdf bug [Re: "Stateless Linux" project] In-Reply-To: <1095110001.31982.2.camel@dcbw.boston.redhat.com> References: <1095100955.5481.14.camel@localhost.localdomain> <1095103445.29494.1.camel@kyrre> <1095103951.5481.18.camel@localhost.localdomain> <1095104316.2903.38.camel@localhost.localdomain> <1095104908.5481.20.camel@localhost.localdomain> <1095105081.29775.4.camel@kyrre> <1095109215.2898.47.camel@localhost.localdomain> <1095110001.31982.2.camel@dcbw.boston.redhat.com> Message-ID: <1095113028.8105.4.camel@localhost.localdomain> For the record, the gpdf from rawhide fixed all these issues for me. I couldn't read Colin Charles presentation or this one using FC2 gpdf, but using rawhide it works just fine. man, 13,.09.2004 kl. 17.13 -0400, skrev Dan Williams: > OOo will attempt to embed fonts if the TrueType font's license allows > OOo to do so (permission to embed is stored in the font). > > Dan > > On Mon, 2004-09-13 at 17:00 -0400, Owen Taylor wrote: > > On Mon, 2004-09-13 at 15:51, Kyrre Ness Sjobak wrote: > > > If you can give me an url where i can download the rawhide rpm - i shall > > > do so, in order to test it. Then we can be shure that there is no font > > > issues etc. > > > > > > Hmm... does not fedora use a common folder for fonts, shared amongst all > > > programs? > > > > I don't think it's a problem with gpdf finding the fonts, but rather > > it knowing how to use them properly. (Also, the fonts are probably > > actually embedded in the PDF file.) > > > > Regards, > > Owen > > > > -- Sindre Pedersen Bjordal www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From strange at nsk.no-ip.org Mon Sep 13 22:04:02 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Mon, 13 Sep 2004 23:04:02 +0100 Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <20040913220402.GA15241@nsk.no-ip.org> On Mon, Sep 13, 2004 at 02:42:35PM -0400, Havoc Pennington wrote: > Hi, > > Red Hat engineering is starting a new project we're calling > "stateless Linux" for lack of a better name - some components of this > are already in Rawhide, and others will be appearing shortly. > > We've been keeping the project a little bit quiet at first, but now > we've written it up in some detail: > > - an overview document, available from > http://people.redhat.com/~hp/stateless/ > > - a HOWTO document and a couple associated RPMs, available from > http://people.redhat.com/dmalcolm/stateless/ > > There aren't many new RPMs for this, because stateless Linux isn't a > single codebase or package, it's a set of changes across the > distribution (you might think of it as a "philosophy"). Most of the > changes are already in Rawhide (the highlights are mentioned in the > StatelessLinux.pdf document). > > Appreciate feedback, especially from anyone who has time to try out > the HOWTO. We expect the code to change quite a bit as issues and > suggestions come in. > > Havoc > An experience that might be interesting: My LUG got involved in a Linux divulgation project that ended up using stateless clients, FC1 based. The project required two different classes of clients: one for a 3d game and another for a webpaper contest. The class of a client was deduced from the PCI ID of the graphics adapter (i810 and NVidia for the gamers, and mga for the others). The initrd didn't mount the nfs share as root and used a tmpfs in conjunction with --bind mounts, as the "stateless linux" project currently uses. Instead, the tmpfs was used as the root folder, with changeable files and directories copied to the tmpfs directory, while the other non-changeable directories and files were symlinked. A slight complication arouse from supporting both i810+dri acceleration and NVidia's glcore libraries. Still, the script that created the root filesystem was under 20 lines and the boot performance was good. Updates to the image were easy. A chroot and rpm/yum install on the server, or a remount /nfs -o rw, make the appropriate changes, and migrate the volatile files to their location. A script was also running on each client that connected to the server and reported its class. The server had then the ability to restart, power down, or cycle the client. (Cycling meaning killing all user processes, restoring the home dir from a known location, and logging the user.) Regards, Luciano Rocha -- Consciousness: that annoying time between naps. From hp at redhat.com Mon Sep 13 22:24:58 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 13 Sep 2004 18:24:58 -0400 Subject: "Stateless Linux" project In-Reply-To: <200409132255.56541.miles@milessabin.com> References: <1095100955.5481.14.camel@localhost.localdomain> <200409132136.35379.miles@milessabin.com> <1095109132.13059.22.camel@localhost.localdomain> <200409132255.56541.miles@milessabin.com> Message-ID: <1095114298.13059.39.camel@localhost.localdomain> On Mon, 2004-09-13 at 22:55 +0100, Miles Sabin wrote: > Havoc Pennington wrote, > > Right, for a sufficiently low number of machines, setting up an > > elaborate framework is going to be more annoying than just managing > > them all separately. Though we should try to make the framework easy > > enough to use that it makes sense even for a single machine, if we > > can. > > Do you have any feel for how low that number is given the current stage > of development? Right now I think you'd be spending a lot of time fixing the framework ;-) It's pretty alpha. But the goal here is to get the OS itself to comprehensively assume that the OS install may be shared read- only. Then at least an individual site only has to worry about their unique configuration and workload, rather than all the OS bits. At that point the degree of pain to "go stateless" would depend on the local site. > I'm not so sure about this. There are many scenarios where it makes > sense to restrict particular roles to a specific set of hosts, or to > restrict particular hosts to a specific set of roles. Security is one > (eg., to take an extreme example, I don't want a firewall to be able to > run any workload) but it's not the only one. Good point. > As you say, a lot of this works already ... I work with parallel > applications on clusters, and common configuration in a shared > filesystem with symmetry-breaking via hostname works fabulously well > given how trivial it is to set up (until the NFS server goes down, that > is ;-). > > But it's pretty much limited to machines which are always connected to > the same network. Extending this to laptops which move between > networks, or no network at all could be a lot more challenging. OTOH, a > scheme which could handle that case as well would be a huge bonus. Right. We've been primarily thinking of the laptop case, really, since the desktop hackers have been working on this. So all the networking stuff for example is designed with laptops as primary target. Havoc From riel at redhat.com Mon Sep 13 22:27:09 2004 From: riel at redhat.com (Rik van Riel) Date: Mon, 13 Sep 2004 18:27:09 -0400 (EDT) Subject: the fate of firewire In-Reply-To: <1095087246.1860.26.camel@localhost.localdomain> Message-ID: On Mon, 13 Sep 2004, Thorsten Leemhuis wrote: > Am Montag, den 13.09.2004, 16:47 +0200 schrieb Arjan van de Ven: > > I can't package that right so I rather don't. > > Just out of curiosity, could you give me one or to details on the > problem(s)? Thanks. Installing a new kernel won't automatically get a new kernel-firewire package installed. This breaks setups where people forget to update the kernel and will certainly break any automatic upgrades people may have set up. On the one hand, you can't have kernel depend on an optional kernel-firewire package. On the other hand, people's systems might depend on it... AFAIK Yum can't handle situations like this right. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From smoogen at lanl.gov Mon Sep 13 22:33:32 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Mon, 13 Sep 2004 16:33:32 -0600 Subject: the fate of firewire In-Reply-To: <1095083494.3457.30.camel@dhcp63-226.rdu.redhat.com> References: <1095060813.2624.12.camel@laptop.fenrus.com> <20040913085057.GA17010@srv01.cluenet.de> <1095066111.7807.14.camel@greebo.homeip.net> <20040913093102.GA17330@srv01.cluenet.de> <1095068403.27996.0.camel@albus.aeon.com.my> <20040913114310.GA18987@srv01.cluenet.de> <20040913132115.GA19708@srv01.cluenet.de> <4145A142.3010508@math.unl.edu> <1095083494.3457.30.camel@dhcp63-226.rdu.redhat.com> Message-ID: <4146203C.7000408@lanl.gov> Michael Tiemann wrote: > Red Hat "decided" that short innovation cycle + long support cycle are > mutually exclusive about as much as Galileo "decided" that the Earth > orbited the Sun, not the other way around. I just hope that The > Community is as forgiving about our "decision" as The Church was about > Galileo's ;-) > Hmmm in that case it could take a couple hundred years for that to occur. I think you will need a couple more hours on the rack and the hot irons just in case... you might recant. -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From jamesaharrisonuk at yahoo.co.uk Mon Sep 13 22:37:26 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Mon, 13 Sep 2004 15:37:26 -0700 (PDT) Subject: "Stateless Linux" project In-Reply-To: <1095112310.21495.6.camel@bettie.internal.frields.org> Message-ID: <20040913223726.77879.qmail@web25305.mail.ukl.yahoo.com> > Have you checked /var/log/messages on the server? Sep 13 14:32:20 galapagos dhcpd: DHCPDISCOVER from 00:04:75:c3:c9:8f via eth0: unknown client My server is detecting the NICs attempt to communicate..... --- "Paul W. Frields" wrote: > On Mon, 2004-09-13 at 17:45, James Harrison wrote: > > I think this is a great idea and I work for a company that could make use > of > > this. > > > > However, I have never been able to get our 3COM cards working with PXE. > Ive > > tried many things and read different HOWTOs, short of changing to > different > > network cards. > > > > I have just tried the dhcp configuration in the "Stateless Linux" project > > HOWTO document and still the client wont use the server: "No DHCP or > ProxyDHCP > > offers found" > > Have you checked /var/log/messages on the server? If you haven't altered > the default configuration for syslog, DHCP DISCOVER/OFFER/etc. messages > should appear there IIRC. Is the server receiving the client's query? If > not, you may have to solve a network problem first. > > -- > Paul W. Frields, RHCE > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From Axel.Thimm at ATrpms.net Mon Sep 13 22:49:40 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 14 Sep 2004 00:49:40 +0200 Subject: RFC: extra kernel module install locations In-Reply-To: <1095086572.1860.20.camel@localhost.localdomain> References: <1095015064.3284.180.camel@bobcat.mine.nu> <1095086572.1860.20.camel@localhost.localdomain> Message-ID: <20040913224940.GE20176@neu.physik.fu-berlin.de> Hi, On Mon, Sep 13, 2004 at 04:42:52PM +0200, Thorsten Leemhuis wrote: > Am Sonntag, den 12.09.2004, 21:51 +0300 schrieb Ville Skytt?: > > There are various practices around about where to install extra kernel > > modules, I thought I'd throw in a quick RFC about what people think is > > the best practice, and why. Some alternatives off the cuff: > > > > 0) Somewhere directly below /lib/modules/$uname, in a per-package > > subdir. > > 1) A suitable location below /lib/modules/$uname/kernel. > > 2) /lib/modules/$uname/updates, mirroring the dir structure from > > /lib/modules/$uname/kernel as applicable. > > 3) Same as 2), but s/updates/$something_else_than_updates/. > > 4) As long as it Just Works(tm), does not matter. > > 5) Insert your favourite here. > > 1) IMO shouldn't use "kernel" for stuff that is not included in kernel > > distributed by the kernel vendor. > > I don't think it's a problem. I think installing the module exactly at > the same place where it normally would have been installed when you > compile it also has a lot of benefits. You never know what the next kernel upgrade will look like (look at firewire), the vendor namespace should be left alone, so that no unnecessary migrations and specfile editing occurs. It is just like the case of /usr vs /usr/local or perl's perl/vendor/site hierarchies, where you mirror the substructures starting at different tree starts depending on origin. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Sep 13 22:51:31 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 14 Sep 2004 00:51:31 +0200 Subject: RFC: extra kernel module install locations In-Reply-To: <1095078073.9565.2.camel@bree.local.net> References: <1095015064.3284.180.camel@bobcat.mine.nu> <20040913100704.GD3968@neu.physik.fu-berlin.de> <1095078073.9565.2.camel@bree.local.net> Message-ID: <20040913225131.GF20176@neu.physik.fu-berlin.de> On Mon, Sep 13, 2004 at 08:21:13AM -0400, Jeremy Katz wrote: > On Mon, 2004-09-13 at 12:07 +0200, Axel Thimm wrote: > > [*] this is half true, for FC2-shipped modutils this was forgotten, > > but there is a bugzilla entry with appropriate patches that hopefully > > made it for FC3. > > thomasvs's patches are in upstream module-init-tools now (well, at > least, equivalent functionality is; istr that Rusty did the > implementation slightly differently) But he did uses /updates/ and not /extra/ as the preferred path for looking up modules? It looks like even in kernel hacker land there is still no real consensus on where exernal modules should get placed in. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Sep 13 23:04:48 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 14 Sep 2004 01:04:48 +0200 Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <20040913230448.GG20176@neu.physik.fu-berlin.de> On Mon, Sep 13, 2004 at 02:42:35PM -0400, Havoc Pennington wrote: > Hi, > > Red Hat engineering is starting a new project we're calling > "stateless Linux" for lack of a better name - some components of this > are already in Rawhide, and others will be appearing shortly. > > We've been keeping the project a little bit quiet at first, but now > we've written it up in some detail: > > - an overview document, available from > http://people.redhat.com/~hp/stateless/ > > - a HOWTO document and a couple associated RPMs, available from > http://people.redhat.com/dmalcolm/stateless/ > > There aren't many new RPMs for this, because stateless Linux isn't a > single codebase or package, it's a set of changes across the > distribution (you might think of it as a "philosophy"). Most of the > changes are already in Rawhide (the highlights are mentioned in the > StatelessLinux.pdf document). > > Appreciate feedback, especially from anyone who has time to try out > the HOWTO. We expect the code to change quite a bit as issues and > suggestions come in. It looks very promising, and reminds in part of fai, the Debian installer with centralised (and CVS managed) host configuration. Could some parts of fai (like the class based configuration file repository) be taken over? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zaitcev at redhat.com Mon Sep 13 23:52:11 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 13 Sep 2004 16:52:11 -0700 Subject: the fate of firewire In-Reply-To: References: Message-ID: <20040913165211.22b3ff48@lembas.zaitcev.lan> On Mon, 13 Sep 2004 09:33:34 +0200 Arjan van de Ven wrote: > We already disabled firewire in smp kernels for this, but I fear that if > things don't improve really soon that firewire becomes unkeepable for UP > kernels as well..... Al was going to have a look at Firewire. Did it happen or he had no time? -- Pete From andy.grover at gmail.com Mon Sep 13 23:53:27 2004 From: andy.grover at gmail.com (Andrew Grover) Date: Mon, 13 Sep 2004 16:53:27 -0700 Subject: Self-Introduction: Andy Grover Message-ID: 1. Full legal name Andrew Grover 2. Country, City Beaverton Oregon, USA 3. Profession or Student status Professional 4. Company or School Intel (btw I'm not here in a work capacity) * Which packages do you want to see published? latest oprofile, cervisia, rapidsvn, netperf, nttcp * Do you want to do QA? I certainly will file bugs when stuff is broken... * What other projects have you worked on in the past? Lots of ACPI and irq-related kernel work, submitted bugs against RH/Mozilla etc. in the past too. Doing network profiling, lately, and finding it sure would be nice if Fedora came with all the stuff I use. * What computer languages and other skills do you know? C, C++, a little perl, python etc. GPG KEYID and fingerprint pub 1024D/01386173 2004-09-13 Andy Grover Key fingerprint = 74E0 BCDF D98F 7F18 E21B 8411 50E1 7443 0138 6173 sub 1024g/BC0F2B6B 2004-09-13 Regards -- Andy From alan at redhat.com Tue Sep 14 00:07:15 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 13 Sep 2004 20:07:15 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095103445.29494.1.camel@kyrre> References: <1095100955.5481.14.camel@localhost.localdomain> <1095103445.29494.1.camel@kyrre> Message-ID: <20040914000715.GB18332@devserv.devel.redhat.com> On Mon, Sep 13, 2004 at 09:24:06PM +0200, Kyrre Ness Sjobak wrote: > Hmm... seems like a good idea, but your pdf is (at least on my computer, > by gnome-pdf-viewer) completly unreadable: all i get is a page with some > sqares randomly distibuted... FC2 xpdf renders it happily if that helps From shiva at sewingwitch.com Tue Sep 14 00:31:22 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 13 Sep 2004 17:31:22 -0700 Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <1D38490EE2C71C9462372F51@[10.169.6.246]> --On Monday, September 13, 2004 2:42 PM -0400 Havoc Pennington wrote: > Red Hat engineering is starting a new project we're calling > "stateless Linux" for lack of a better name - some components of this > are already in Rawhide, and others will be appearing shortly. Looks like the news has made SlashDot: From hp at redhat.com Tue Sep 14 01:02:51 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 13 Sep 2004 21:02:51 -0400 Subject: "Stateless Linux" project In-Reply-To: <20040913230448.GG20176@neu.physik.fu-berlin.de> References: <1095100955.5481.14.camel@localhost.localdomain> <20040913230448.GG20176@neu.physik.fu-berlin.de> Message-ID: <1095123771.16108.5.camel@localhost.localdomain> On Tue, 2004-09-14 at 01:04 +0200, Axel Thimm wrote: > It looks very promising, and reminds in part of fai, the Debian > installer with centralised (and CVS managed) host configuration. Could > some parts of fai (like the class based configuration file repository) > be taken over? Right, the difference in the stateless model is that you'd want to fetch the config files at runtime and keep them somewhere transient, or assign them to a central install rather than a particular computer. Havoc From skvidal at phy.duke.edu Tue Sep 14 01:09:55 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 13 Sep 2004 21:09:55 -0400 Subject: the fate of firewire In-Reply-To: References: Message-ID: <1095124195.21264.2.camel@binkley> > On the one hand, you can't have kernel depend on an > optional kernel-firewire package. On the other hand, > people's systems might depend on it... > > AFAIK Yum can't handle situations like this right. > you want to track the version of the kernel and update another package based on what the latest kernel version is. No, that's not something yum can do. -sv From grmoc at yahoo.com Tue Sep 14 03:14:39 2004 From: grmoc at yahoo.com (Roberto Peon) Date: Mon, 13 Sep 2004 23:14:39 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095123771.16108.5.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <20040913230448.GG20176@neu.physik.fu-berlin.de> <1095123771.16108.5.camel@localhost.localdomain> Message-ID: <200409132314.39182.grmoc@yahoo.com> I sure like the idea of an 'overlay' fs. =) -Roberto JP On Monday 13 September 2004 09:02 pm, Havoc Pennington wrote: > On Tue, 2004-09-14 at 01:04 +0200, Axel Thimm wrote: > > It looks very promising, and reminds in part of fai, the Debian > > installer with centralised (and CVS managed) host configuration. Could > > some parts of fai (like the class based configuration file repository) > > be taken over? > > Right, the difference in the stateless model is that you'd want to fetch > the config files at runtime and keep them somewhere transient, or assign > them to a central install rather than a particular computer. > > Havoc From hp at redhat.com Tue Sep 14 03:22:58 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 13 Sep 2004 23:22:58 -0400 Subject: "Stateless Linux" project In-Reply-To: <200409132314.39182.grmoc@yahoo.com> References: <1095100955.5481.14.camel@localhost.localdomain> <20040913230448.GG20176@neu.physik.fu-berlin.de> <1095123771.16108.5.camel@localhost.localdomain> <200409132314.39182.grmoc@yahoo.com> Message-ID: <1095132178.16108.7.camel@localhost.localdomain> AFS has context-dependent symlinks that can also be used for this sort of thing. Havoc On Mon, 2004-09-13 at 23:14 -0400, Roberto Peon wrote: > I sure like the idea of an 'overlay' fs. =) > -Roberto JP > > > On Monday 13 September 2004 09:02 pm, Havoc Pennington wrote: > > On Tue, 2004-09-14 at 01:04 +0200, Axel Thimm wrote: > > > It looks very promising, and reminds in part of fai, the Debian > > > installer with centralised (and CVS managed) host configuration. Could > > > some parts of fai (like the class based configuration file repository) > > > be taken over? > > > > Right, the difference in the stateless model is that you'd want to fetch > > the config files at runtime and keep them somewhere transient, or assign > > them to a central install rather than a particular computer. > > > > Havoc > > From grmoc at yahoo.com Tue Sep 14 03:23:54 2004 From: grmoc at yahoo.com (Roberto Peon) Date: Mon, 13 Sep 2004 23:23:54 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095132178.16108.7.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <200409132314.39182.grmoc@yahoo.com> <1095132178.16108.7.camel@localhost.localdomain> Message-ID: <200409132323.54451.grmoc@yahoo.com> It handles modifications to files, and not just wholesale replacement?? -R On Monday 13 September 2004 11:22 pm, Havoc Pennington wrote: > AFS has context-dependent symlinks that can also be used for this sort > of thing. > > Havoc > > On Mon, 2004-09-13 at 23:14 -0400, Roberto Peon wrote: > > I sure like the idea of an 'overlay' fs. =) > > -Roberto JP > > > > On Monday 13 September 2004 09:02 pm, Havoc Pennington wrote: > > > On Tue, 2004-09-14 at 01:04 +0200, Axel Thimm wrote: > > > > It looks very promising, and reminds in part of fai, the Debian > > > > installer with centralised (and CVS managed) host configuration. > > > > Could some parts of fai (like the class based configuration file > > > > repository) be taken over? > > > > > > Right, the difference in the stateless model is that you'd want to > > > fetch the config files at runtime and keep them somewhere transient, or > > > assign them to a central install rather than a particular computer. > > > > > > Havoc From hp at redhat.com Tue Sep 14 03:31:24 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 13 Sep 2004 23:31:24 -0400 Subject: "Stateless Linux" project In-Reply-To: <200409132323.54451.grmoc@yahoo.com> References: <1095100955.5481.14.camel@localhost.localdomain> <200409132314.39182.grmoc@yahoo.com> <1095132178.16108.7.camel@localhost.localdomain> <200409132323.54451.grmoc@yahoo.com> Message-ID: <1095132684.16108.12.camel@localhost.localdomain> On Mon, 2004-09-13 at 23:23 -0400, Roberto Peon wrote: > It handles modifications to files, and not just wholesale replacement?? > You'd use context-dependent symlinks to push different config files to different systems. But right, it's whole files. Havoc From grmoc at yahoo.com Tue Sep 14 03:54:36 2004 From: grmoc at yahoo.com (Roberto Peon) Date: Mon, 13 Sep 2004 23:54:36 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095132684.16108.12.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <200409132323.54451.grmoc@yahoo.com> <1095132684.16108.12.camel@localhost.localdomain> Message-ID: <200409132354.36175.grmoc@yahoo.com> And file deletion? What if the package maintainer didn't setup everything in its proper place as aymlinks? -R On Monday 13 September 2004 11:31 pm, Havoc Pennington wrote: > On Mon, 2004-09-13 at 23:23 -0400, Roberto Peon wrote: > > It handles modifications to files, and not just wholesale replacement?? > > You'd use context-dependent symlinks to push different config files to > different systems. But right, it's whole files. > > Havoc From hp at redhat.com Tue Sep 14 04:01:11 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 14 Sep 2004 00:01:11 -0400 Subject: "Stateless Linux" project In-Reply-To: <200409132354.36175.grmoc@yahoo.com> References: <1095100955.5481.14.camel@localhost.localdomain> <200409132323.54451.grmoc@yahoo.com> <1095132684.16108.12.camel@localhost.localdomain> <200409132354.36175.grmoc@yahoo.com> Message-ID: <1095134471.16108.19.camel@localhost.localdomain> On Mon, 2004-09-13 at 23:54 -0400, Roberto Peon wrote: > And file deletion? What if the package maintainer didn't setup everything in > its proper place as aymlinks? > I think we're talking about different things ;-) With AFS people sometimes set up a read-only root filesystem, where each system sees different config files (using context-dependent symlinks). You can't delete files, it's read-only. Packages aren't involved in this layer, the links are set up site local. Havoc From fedora at leemhuis.info Tue Sep 14 05:07:43 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Sep 2004 07:07:43 +0200 Subject: the fate of firewire In-Reply-To: References: Message-ID: <1095138463.2851.7.camel@thl.ct.heise.de> Am Montag, den 13.09.2004, 18:27 -0400 schrieb Rik van Riel: > On Mon, 13 Sep 2004, Thorsten Leemhuis wrote: > > Am Montag, den 13.09.2004, 16:47 +0200 schrieb Arjan van de Ven: > > > > I can't package that right so I rather don't. > > > > Just out of curiosity, could you give me one or to details on the > > problem(s)? Thanks. > > Installing a new kernel won't automatically get a new > kernel-firewire package installed. Sure. > This breaks setups > where people forget to update the kernel and will > certainly break any automatic upgrades people may have > set up. Yes, but putting it somewhere so people can it install *manually* after a kernel-update is still a lot easier then rebuild the firewire module every time yourself. There are some kernel-module packages in fedora.us and in livna.org (and more in the queue) -- they all have this problem AFAIK. But IMHO thats not a reason to not package these modules ;-) CU thl From ville.skytta at iki.fi Tue Sep 14 06:38:11 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 14 Sep 2004 09:38:11 +0300 Subject: the fate of firewire In-Reply-To: <1095138463.2851.7.camel@thl.ct.heise.de> References: <1095138463.2851.7.camel@thl.ct.heise.de> Message-ID: <1095143891.7580.100.camel@bobcat.mine.nu> On Tue, 2004-09-14 at 08:07, Thorsten Leemhuis wrote: > There are some kernel-module packages in fedora.us and in livna.org (and > more in the queue) -- they all have this problem AFAIK. But IMHO thats > not a reason to not package these modules ;-) Agreed. And FWIW, recent versions of apt (at least from fedora.us) will magically pull in these external kernel module packages when the kernel is upgraded (or warn if they're not available), as long as they follow the configured module naming practices ("kernel-module-*" by default). From arjanv at redhat.com Tue Sep 14 06:49:27 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 14 Sep 2004 08:49:27 +0200 Subject: the fate of firewire In-Reply-To: References: Message-ID: <1095144566.2698.21.camel@laptop.fenrus.com> On Tue, 2004-09-14 at 00:27, Rik van Riel wrote: > On Mon, 13 Sep 2004, Thorsten Leemhuis wrote: > > Am Montag, den 13.09.2004, 16:47 +0200 schrieb Arjan van de Ven: > > > > I can't package that right so I rather don't. > > > > Just out of curiosity, could you give me one or to details on the > > problem(s)? Thanks. > > Installing a new kernel won't automatically get a new > kernel-firewire package installed. This breaks setups > where people forget to update the kernel and will > certainly break any automatic upgrades people may have > set up. it's even worse, say you want to install an OLDER kernel for whatever reason; just "newest external" won't cut it with the way most of these are packages; you need the exact matching one. and you need it installed before the kernel gets installed, so that it makes the initrd. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Tue Sep 14 06:50:12 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 14 Sep 2004 09:50:12 +0300 Subject: RFC: extra kernel module install locations In-Reply-To: <1095086572.1860.20.camel@localhost.localdomain> References: <1095015064.3284.180.camel@bobcat.mine.nu> <1095086572.1860.20.camel@localhost.localdomain> Message-ID: <1095144612.7580.106.camel@bobcat.mine.nu> On Mon, 2004-09-13 at 17:42, Thorsten Leemhuis wrote: > > 1) IMO shouldn't use "kernel" for stuff that is not included in kernel > > distributed by the kernel vendor. > > I don't think it's a problem. I think installing the module exactly at > the same place where it normally would have been installed when you > compile it also has a lot of benefits. Could you elaborate on "lot of benefits", it is not at all clear to me. Axel already commented why intruding this "vendor space" can cause problems. > > 2) My #1 pick as of now, maybe, depending on 3) below. > > But do we really need to mirror the stucture? Is there any benefit in > doing so? Why not a simple per-package dir? Why not be consistent with what the kernel does? What benefits does a per-package dir approach have? If you are thinking about directory ownership in module packages, everything below _and including_ the "updates" or "extra" dirs should be owned by the module package(s) anyway because the kernel package does not create nor own them. From ville.skytta at iki.fi Tue Sep 14 07:02:32 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 14 Sep 2004 10:02:32 +0300 Subject: RFC: extra kernel module install locations In-Reply-To: <20040913100704.GD3968@neu.physik.fu-berlin.de> References: <1095015064.3284.180.camel@bobcat.mine.nu> <20040913100704.GD3968@neu.physik.fu-berlin.de> Message-ID: <1095145352.7580.117.camel@bobcat.mine.nu> On Mon, 2004-09-13 at 13:07, Axel Thimm wrote: > OTOH /extras/ (3a above) is what the kernel developers have currently > blessed, but the flat structure is irritating. Agreed. But if that has some sort of blessing, I think it would be good to either follow the blessed structure, irritating or not, or not to install into this dir at all. I would personally go for the latter :) (and just use updates/ for everything at least until extras/ becomes a more prominent "standard"). By the way, you used both extra/ and extras/ in your message, I assume only one of them is "correct"? It seems that alternative 2 in my original mail (updates/ with mirroring the dir structure from kernel/ where applicable) has received most +1's so far. From fedora at leemhuis.info Tue Sep 14 07:10:00 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Sep 2004 09:10:00 +0200 Subject: RFC: extra kernel module install locations In-Reply-To: <1095144612.7580.106.camel@bobcat.mine.nu> References: <1095015064.3284.180.camel@bobcat.mine.nu> <1095086572.1860.20.camel@localhost.localdomain> <1095144612.7580.106.camel@bobcat.mine.nu> Message-ID: <1095145800.2851.44.camel@thl.ct.heise.de> Am Dienstag, den 14.09.2004, 09:50 +0300 schrieb Ville Skytt?: > On Mon, 2004-09-13 at 17:42, Thorsten Leemhuis wrote: > > > > 1) IMO shouldn't use "kernel" for stuff that is not included in kernel > > > distributed by the kernel vendor. > > > > I don't think it's a problem. I think installing the module exactly at > > the same place where it normally would have been installed when you > > compile it also has a lot of benefits. > > Could you elaborate on "lot of benefits", it is not at all clear to me. Mainly Documentation and Howtos of the external drivers. They all will tell you that you find the module in the place, where it is normally installed. I don't see why we should differ from those. And if you install an RPM and later compile a newer driver version locally that is installed at the original place its always the version from the RPM witch will be used -- thats a bit confusing IMO. > Axel already commented why intruding this "vendor space" can cause > problems. I don't see the point here. We need to rebuild the RPM for each kernel anew so we can look after that. Maybe it's something that (also) should be fixed upstream first, then everyone is happy ;-) > > > 2) My #1 pick as of now, maybe, depending on 3) below. > > > > But do we really need to mirror the stucture? Is there any benefit in > > doing so? Why not a simple per-package dir? > > Why not be consistent with what the kernel does? What benefits does a > per-package dir approach have? No strong arguments here. I just find a per-package dir a bit cleaner to read and see no benefits from the structure the kernel has. ;-) ls /lib/modules/uname/(extras|updates)/ simply would show which drivers are installed. No digging trough sub-directorys. > If you are thinking about directory > ownership in module packages, everything below _and including_ the > "updates" or "extra" dirs should be owned by the module package(s) > anyway because the kernel package does not create nor own them. Of course. CU thl From rc040203 at freenet.de Tue Sep 14 07:17:23 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Sep 2004 09:17:23 +0200 Subject: the fate of firewire In-Reply-To: <1095144566.2698.21.camel@laptop.fenrus.com> References: <1095144566.2698.21.camel@laptop.fenrus.com> Message-ID: <1095146243.4989.80.camel@mccallum.corsepiu.local> On Tue, 2004-09-14 at 08:49, Arjan van de Ven wrote: > it's even worse, > [..] > you need the exact matching one. > and you need it installed before the kernel gets installed, so that it > makes the initrd. How that? Can you elaborate? To me this sounds like a fundamental bug somewhere. Ralf From Axel.Thimm at ATrpms.net Tue Sep 14 07:29:12 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 14 Sep 2004 09:29:12 +0200 Subject: RFC: extra kernel module install locations In-Reply-To: <1095145352.7580.117.camel@bobcat.mine.nu> References: <1095015064.3284.180.camel@bobcat.mine.nu> <20040913100704.GD3968@neu.physik.fu-berlin.de> <1095145352.7580.117.camel@bobcat.mine.nu> Message-ID: <20040914072912.GB27706@neu.physik.fu-berlin.de> On Tue, Sep 14, 2004 at 10:02:32AM +0300, Ville Skytt? wrote: > On Mon, 2004-09-13 at 13:07, Axel Thimm wrote: > > > OTOH /extras/ (3a above) is what the kernel developers have currently > > blessed, but the flat structure is irritating. > > Agreed. But if that has some sort of blessing, I think it would be good > to either follow the blessed structure, irritating or not, or not to > install into this dir at all. I would personally go for the latter :) > (and just use updates/ for everything at least until extras/ becomes a > more prominent "standard"). Yes, it looks like this is an area of flux. modutils /upstream) seems to prefer /updates/, the kernel sources themselves /extra/. Given that this is a "recent" change (2.6), there is probably still space for convergence. > By the way, you used both extra/ and extras/ in your message, I assume > only one of them is "correct"? Sorry, the /extra/ is correct. Here is the relevant Makefile snippet (from scripts/Makefile.modinst): modinst_dir = $(MODLIB)/$(if $(filter ../% /%,$@),extra/,kernel/$(@D)) A trivial patch would be -modinst_dir = $(MODLIB)/$(if $(filter ../% /%,$@),extra/,kernel/$(@D)) +modinst_dir = $(MODLIB)/$(if $(filter ../% /%,$@),updates/$(@D),kernel/$(@D)) This would make the kernel sources do the right thing in the sense of alternative 2). > It seems that alternative 2 in my original mail (updates/ with mirroring > the dir structure from kernel/ where applicable) has received most +1's > so far. If we feel confident that this is the way to go (aka there are not objections), we should submit the patch above and see what the reaction is. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Sep 14 07:35:13 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 14 Sep 2004 09:35:13 +0200 Subject: the fate of firewire In-Reply-To: <1095144566.2698.21.camel@laptop.fenrus.com> References: <1095144566.2698.21.camel@laptop.fenrus.com> Message-ID: <20040914073513.GC27706@neu.physik.fu-berlin.de> On Tue, Sep 14, 2004 at 08:49:27AM +0200, Arjan van de Ven wrote: > On Tue, 2004-09-14 at 00:27, Rik van Riel wrote: > > On Mon, 13 Sep 2004, Thorsten Leemhuis wrote: > > > Am Montag, den 13.09.2004, 16:47 +0200 schrieb Arjan van de Ven: > > > > > > I can't package that right so I rather don't. > > > > > > Just out of curiosity, could you give me one or to details on the > > > problem(s)? Thanks. > > > > Installing a new kernel won't automatically get a new > > kernel-firewire package installed. This breaks setups where > > people forget to update the kernel and will certainly break any > > automatic upgrades people may have set up. > > it's even worse, say you want to install an OLDER kernel for whatever > reason; just "newest external" won't cut it with the way most of these > are packages; you need the exact matching one. That's now an old problem in kernel-module packaging which has been solved a year ago. Just place the kernel's version/release into the kernel module rpm's name like kernel-module-firewire-2.6.8-1.521-2.6.8-1.521 and set up struct dependencies to the matching kernel. Doesn't solve the extra install stepp, but you won't get bitten by downgrades, concurrent kernel installs and so on. > and you need it installed before the kernel gets installed, so that it > makes the initrd. If you want to support booting from firewire there is no sense in splitting any sub-package off. firewire won't be optional. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Sep 14 07:35:35 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Sep 2004 09:35:35 +0200 Subject: the fate of firewire In-Reply-To: <1095144566.2698.21.camel@laptop.fenrus.com> References: <1095144566.2698.21.camel@laptop.fenrus.com> Message-ID: <1095147335.2851.53.camel@thl.ct.heise.de> Am Dienstag, den 14.09.2004, 08:49 +0200 schrieb Arjan van de Ven: > On Tue, 2004-09-14 at 00:27, Rik van Riel wrote: > > On Mon, 13 Sep 2004, Thorsten Leemhuis wrote: > > > Am Montag, den 13.09.2004, 16:47 +0200 schrieb Arjan van de Ven: > > > > > > I can't package that right so I rather don't. > > > > > > Just out of curiosity, could you give me one or to details on the > > > problem(s)? Thanks. > > > > Installing a new kernel won't automatically get a new > > kernel-firewire package installed. This breaks setups > > where people forget to update the kernel and will > > certainly break any automatic upgrades people may have > > set up. > > it's even worse, say you want to install an OLDER kernel for whatever > reason; just "newest external" won't cut it with the way most of these > are packages; you need the exact matching one. Thats the reason why we name the packages at fedora.us kernel-module-ipw2100-$(uname -r)-%{version}%{release} Then you can install more than one version of the driver (e.g. for older kernels or for UP and SMP at the same time). > and you need it installed before the kernel gets installed, so that it > makes the initrd. If you want to boot from firewire you need in in the initrd, yes. Otherwise not AFAIK. But booting from firewire is not the standard-case IMO. CU thl From enrico.scholz at informatik.tu-chemnitz.de Tue Sep 14 07:52:20 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 14 Sep 2004 09:52:20 +0200 Subject: rawhide report: 20040911 changes In-Reply-To: <200409111129.i8BBTD930128@porkchop.devel.redhat.com> (Build System's message of "Sat, 11 Sep 2004 07:29:13 -0400") References: <200409111129.i8BBTD930128@porkchop.devel.redhat.com> Message-ID: <87sm9ll22z.fsf@kosh.ultra.csn.tu-chemnitz.de> buildsys at redhat.com (Build System) writes: > dhcp-3.0.1-8 > ------------ > * Mon Aug 16 2004 Jason Vas Dias 7:3.0.1-7 > * Tue Aug 03 2004 Jason Vas Dias 6:3.0.1-6 ~~ What is the sense behind this epoch inflation? Or, does here somebody think that %epoch == %release should hold? Enrico From steven at nchc.org.tw Tue Sep 14 08:55:41 2004 From: steven at nchc.org.tw (Steven Shiau) Date: Tue, 14 Sep 2004 16:55:41 +0800 Subject: The DRBL project (Wsa Re: "Stateless Linux" project) In-Reply-To: <20040914071742.96E3A7334D@hormel.redhat.com> References: <20040914071742.96E3A7334D@hormel.redhat.com> Message-ID: <4146B20D.8060909@nchc.org.tw> Hi... We run a project called DRBL (Diskless Remote Boot in Linux) . The website is http://drbl.nchc.org.tw (Traditional Chinese) and http://drbl.sf.net (English). Maybe someone can have a look at that, some part of DRBL are similar to this Stateless Linux project. DRBL runs well on RedHat, Fedora, Mandrake and Debian. In Taiwan, more than 100 sites already downloaded and run DRBL, some of them are schools (Primary/High school/University), some of them are NPO and buisness companies. check this: http://drbl.nchc.org.tw/sites/98_DRBL%A8%CF%A5%CE%AA%CC%A4%C0%A7G/DRBL%A8%CF%A5%CE%AA%CC%A4%C0%A7G_20040820.pdf Also, there is a program comes with DRBL called "Clonezilla". It can let people to massively clone the system image to the harddisk of client computers. The function of clonezilla is quite similar to the Symantec Ghost Corporate Edition?. For more information about clonezilla, check this: http://clonezilla.sf.net (English) and http://drbl.nchc.org.tw/clonezilla.php (Traditional Chinese) > Date: Tue, 14 Sep 2004 01:04:48 +0200 > From: Axel Thimm > Subject: Re: "Stateless Linux" project > To: Development discussions related to Fedora Core > > Message-ID: <20040913230448.GG20176 at neu.physik.fu-berlin.de> > Content-Type: text/plain; charset="us-ascii" > > On Mon, Sep 13, 2004 at 02:42:35PM -0400, Havoc Pennington wrote: > >>Hi, >> >>Red Hat engineering is starting a new project we're calling >>"stateless Linux" for lack of a better name - some components of this >>are already in Rawhide, and others will be appearing shortly. >> >>We've been keeping the project a little bit quiet at first, but now >>we've written it up in some detail: >> >> - an overview document, available from >> http://people.redhat.com/~hp/stateless/ >> >> - a HOWTO document and a couple associated RPMs, available from >> http://people.redhat.com/dmalcolm/stateless/ >> >>There aren't many new RPMs for this, because stateless Linux isn't a >>single codebase or package, it's a set of changes across the >>distribution (you might think of it as a "philosophy"). Most of the >>changes are already in Rawhide (the highlights are mentioned in the >>StatelessLinux.pdf document). >> >>Appreciate feedback, especially from anyone who has time to try out >>the HOWTO. We expect the code to change quite a bit as issues and >>suggestions come in. > > > It looks very promising, and reminds in part of fai, the Debian > installer with centralised (and CVS managed) host configuration. Could > some parts of fai (like the class based configuration file repository) > be taken over? -- Say YES to Openoffice.org (www.openoffice.org, openoffice.nchc.org.tw). Please AVOID distributing documents in WORD, EXCEL or POWERPOINT format. [Chinese Big5] ?????WORD, EXCEL ?? POWERPOINT?????. See http://www.fsf.org/philosophy/no-word-attachments.html and http://www.cyut.edu.tw/~ckhung/a/c_91.shtml ----------------------------------------------------------------------------- Steven Shiau [Chinese Big5] ??? NCHC [Chinese Big5] ??????????? E-mail: steven _at_ nchc.org.tw; steven _at_ stick.idv.tw From fedora at wir-sind-cool.org Tue Sep 14 09:31:00 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 14 Sep 2004 11:31:00 +0200 Subject: Reminder: REVIEWED keyword at bugzilla.fedora.us Message-ID: <20040914113100.2b81e219.fedora@wir-sind-cool.org> I've noticed that some people started reviewing eachother's packages in order to get productive. Please note that you can set the REVIEWED bugzilla keyword to mark tickets, which have got one review, and also query bugzilla for other tickets with that keyword. Short link here: http://tinyurl.com/4tdu8 With that system it's easier to meet the publish criteria. http://www.fedora.us/wiki/PackageSubmissionQAPolicy#review I've also seen some Fedora Legacy people using the keyword, too, so checking out those tickets, if you want to help Fedora Legacy, could be worthwhile. Fedora Legacy uses a separate "Product" in bugzilla, choose "Fedora Legacy" when querying the database. -- Fedora Core release 1 (Yarrow) - Linux 2.4.22-1.2199.nptl loadavg: 1.45 0.74 0.58 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From s.ellis at fastmail.co.uk Tue Sep 14 12:20:46 2004 From: s.ellis at fastmail.co.uk (Stuart Ellis) Date: Tue, 14 Sep 2004 13:20:46 +0100 Subject: "Stateless Linux" project Message-ID: <1095164446.11530.204330179@webmail.messagingengine.com> I'm absolutely delighted by this - I'd long since given up hope of a mainstream vendor looking at a cached client approach rather than trying to insist on either thick or thin. The issue of backing up user home directories from mobile devices in mentioned in the PDF, but I'd be very interested in hearing about approaches for dealing with syncing shared data stores. With a home directory or private data store basic sync works if it can be made transparent to the user, and/or integrated into the GUI (Off-line Files on MS Windows, Mac iDisk). Writable shared data stores presumably require some form of reconciliation or version control for multiple off-line copies to be handled smoothly. I suppose that one solution might be to wrap access to a version control system into the standard GUI so that the functionality becomes accessible to office workers; another might be to use a database-backed system like Storage, which could replicate. How are people dealing with this issue on their networks now ? What do we think would be the "Just Works" solution in the context of Stateless Linux ? (I've seen the problem, but I don't know the answer...) -- Stuart Ellis s.ellis at fastmail.co.uk From linux_4ever at yahoo.com Tue Sep 14 13:52:47 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 14 Sep 2004 06:52:47 -0700 (PDT) Subject: glibc-2.3.3-51 breaks m4 Message-ID: <20040914135247.32276.qmail@web50601.mail.yahoo.com> Hi, The latest glibc in rawhide breaks the compile of m4: stackovf.c:108: warning: `__nothrow__' attribute ignored stackovf.c: In function `setup_stackovf_trap': stackovf.c:359: error: parse error before "__attribute__" make[1]: *** [stackovf.o] Error 1 make: *** [all] Error 1 This seems to be centered on the __P macro which is only used in stackovf.c. I have filed "glibc breaks the build" bug reports and they languish in bugzilla. Does someone involved in glibc know that m4 is now broken due to something in the headers? (glibc-2.3.3-45 works fine) Is glibc going to get fixed/reverted? Or is m4 going to be fixed? Thanks, -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From erik at totalcirculation.com Tue Sep 14 14:31:49 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Tue, 14 Sep 2004 10:31:49 -0400 Subject: "Stateless Linux" project Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDD0F@smith.interlink.local> > > Hi, > > Red Hat engineering is starting a new project we're calling > "stateless Linux" for lack of a better name - some components of this > are already in Rawhide, and others will be appearing shortly. > > Appreciate feedback, especially from anyone who has time to try out > the HOWTO. We expect the code to change quite a bit as issues and > suggestions come in. > > Havoc > I too am thrilled to see this happening. It's this sort of technology that has the potential to give linux a solid leg up on the competition for both the desktop and the server. I have a couple of questions. 1. Do I need to be running rawhide to test out the read-only root rpms and the HOWTO? 2. Configuration management. I've been trying to extract my configuration from running systems for a while now, but not really been entirely successful. Typically the list of files to "watch" gets unwieldy, or someone forgets to make the .orig file, or commit to cvs. I think ideally a configuration management system would integrate rpm (to know what files are config files) and cvs/subversion (to provide revision control) in such a way that you have revision controlled configuration files available off-system. In a truly stateless system, you could just export all the config files from CVS into the ramdisk on bootup. I'd REALLY like to be able to edit files on a "live" system, and type a command to "check in" my changes. I'd like to be able to use the same system to show my the change history for a given file, and to ease forward migration. Is this sort of thing within the scope of this project? 3. I'd like to recommend looking at including the linux-vserver [1] patches and tools with the OS distribution for server-side applications. All the aforementioned technology would be an ideal fit in virtual servers, and the ability to keep all your "logical servers" in virtual sandboxes makes testing and deployment in smaller environments much easier. Statelessness would make virtual servers far more efficient, since you could run them all off the same physical filesystem instead of making hard link trees. I'm already close to running "stateless servers" just by keeping them in virtual machines, where I can shut them down and rsync them to a different physical machine without leaving my desk. Thanks --erik [1] http://www.linux-vserver.net/ From john.hearns at clustervision.com Tue Sep 14 14:48:38 2004 From: john.hearns at clustervision.com (John Hearns) Date: Tue, 14 Sep 2004 15:48:38 +0100 Subject: "Stateless Linux" project In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDD0F@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDD0F@smith.interlink.local> Message-ID: <1095173318.10739.127.camel@vigor12> On Tue, 2004-09-14 at 15:31, Erik LaBianca wrote: > I too am thrilled to see this happening. It's this sort of technology > that has the potential to give linux a solid leg up on the competition > for both the desktop and the server. > 2. Configuration management. I've been trying to extract my > configuration from running systems for a while now, but not really been > entirely successful. Typically the list of files to "watch" gets > unwieldy, or someone forgets to make the .orig file, or commit to cvs. I > think ideally a configuration management system would integrate rpm (to > know what files are config files) and cvs/subversion (to provide > revision control) in such a way that you have revision controlled > configuration files available off-system. > > In a truly stateless system, you could just export all the config files > from CVS into the ramdisk on bootup. http://quattor.web.cern.ch/quattor http://www.lcfg.org might help there. From jjengla at sandia.gov Tue Sep 14 15:06:13 2004 From: jjengla at sandia.gov (Josh England) Date: Tue, 14 Sep 2004 08:06:13 -0700 Subject: how about oneSIS? was: "Stateless Linux" project Message-ID: <1095174373.6592.28.camel@localhost> Hello all, I'd like to introduce to the list a piece of software that just happens to do exactly what this project sounds like its trying to accomplish. The software handles the root image of any number of nodes, but allows for node/role specific behavior. It allows you to deploy a local cache of the root image onto a local disk, and a bootloader if desired. No matter what, though, the root filesystem is bit-for-bit identical everywhere. Deviations are handled by creating soft links to/from a tmpfs ramdisk. It really gives ultimate flexibility as to how/where components of the filesystem should live (localdisk/ramdisk/NFS). It can bootstrap the traditional NFSroot way (root=/dev/nfs) or use an initrd to bootstrap in any number of creative ways. The framework is in place to be able to easily boot over any network filesystem (including Lustre when it arrives), or over any network medium (including InfiniBand). It uses an initrd 'template' to create new initrds with very customizable behavior. The project is called oneSIS (http://onesis.sourceforge.net). We've used it in production for running clusters for years, but I've just recently (early this year) re-written it from scratch to make it cleaner and more flexible. Grab the CVS version from sourceforge and check it out. It makes everything the "Stateless linux" project is trying to do very, very easy. There is more information in the oneSIS software manual (http://onesis.sourceforge.net/oneSIS-manual.pdf), and I currently have a paper being reviewed for submission, or I'd send it also. -JE ----------------------------------------------- Josh England Sandia National Laboratory, Livermore, CA Visualization and Scientific Computing email: jjengla at sandia.gov phone: (925) 294-2076 Miles Sabin wrote, I think this is a fine idea. I have a few questions tho' ... Outside of largish corporates where clones are common, there are smaller environments where machines are mostly (95%+, say) similar, but where there are machine-by-machine variations which fall outside the set of things which are covered by per-user homes or hardware auto- configuration. For instance, differences in which services should be running, their configuration, or minor kernel tweaks. Are such environments outside the scope of this proposal, or is there some plan to support per-machine or per-group/class deltas from a common baseline? One thing that's always stopped me from bothering with NFS mounted homes is that for me a different machine quite often implies a different role, hence that the stuff that's appropriate to be in my home varies. This also tends to be a delta from a common baseline, so handling the variability by having distinct users for each role doesn't seem like quite the right answer. Caching doesn't seem likely to change this, and the "recreate Joe's workstation" scenario in the document seems to wander into this kind of territory. Do you have any thoughts about handling this? Slightly related to the previous two questions ... My laptop moves between my home network, my work network, business-client networks, connected by dialup ISP, and disconnected. In each scenario the services running, their configuration, and what's appropriate for my home dir vary slightly. Even tho' this is pretty clearly beyond the scope of your proposal, there seems to be at least something in common: the setup is mostly the same, but there are some small deltas. Would it make sense to have a common mechanism to handle this? I think all my questions boil down to: looks great for the 95% of stuff which stays the same, but how do you deal with the 5% of stuff which varies? And can you do it in a way which is 95% less hassle than treating the machines as completely separate entities? Cheers, Miles From 23e9t5t02 at sneakemail.com Tue Sep 14 15:20:08 2004 From: 23e9t5t02 at sneakemail.com (Steve Coleman) Date: Tue, 14 Sep 2004 11:20:08 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <5463-61862@sneakemail.com> Havoc Pennington hp-at-redhat.com |fedora| wrote: > > Appreciate feedback, As long as you are looking for opinions and ideas... I think that the CODA project would be an excellent match for your stateless linux concept. It combines the sort of stateless distributed file system that caches data locally and can even deal with rejoining networks after a temporary network outage/failover type situation. Much of what you are looking for could be incorporated from there, or at least the lessons learned should be taken into account. http://www.coda.cs.cmu.edu/ What ever you come up with, in my opinion, MUST support SELinux but not necessarily require it. This could be a short term wrench in the cogs of progress but it will be well worth the effort to assume that support is needed. Adding SE to the initial boot cycle you would ensure better control over the network bootstrap process so that it will be harder to hack into, as network loading of images is inherently vulnerable since the logic needed for proper validation of the image must have been cached already or the security contexts transferred first. Changing the boot up sequence necessitates getting some SE gurus in on your design early because the permissions must be labeled in the file system and permissions granted in the right sequences, otherwise the SE system will have major problems booting up. I think you need a form of distributed SE profiles which are used to bootstrap the network loading of the OS and relabeling of the root filesystem and runtime cache images. I'm no guru on SE but I know its not going to be trivial. Another suggestion I have is to have a long term objective of incorporating OpenMosix like capabilities in order to add application migration and interprocess communication through network shared IPC. This will probably be quite useful in the network wide administration and coordinating all hosts through their administrative software/OS upgrade/bootstrap cycle amongst other things. http://openmosix.sourceforge.net/ It would also be nice to have some form of a VPN used during the boot process and subsequent distribution of runtime images. Make it easy to boot secure and the rest of the security will fall into place. Roll all that together and I'd like to see M$ top that! ;) Steve Coleman http://www.........../ From john.hearns at clustervision.com Tue Sep 14 15:35:59 2004 From: john.hearns at clustervision.com (John Hearns) Date: Tue, 14 Sep 2004 16:35:59 +0100 Subject: "Stateless Linux" project In-Reply-To: <5463-61862@sneakemail.com> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> Message-ID: <1095176159.10739.140.camel@vigor12> On Tue, 2004-09-14 at 16:20, Steve Coleman wrote: > > Another suggestion I have is to have a long term objective of > incorporating OpenMosix like capabilities in order to add application > migration and interprocess communication through network shared IPC. Speaking as someone who looks after a Mosix cluster, from what I've read I doubt Mosix will ever make it into the official Linux kernel. A downside for Stateless Linux is that you have to have the same kernel running on all nodes. As I say, I like Mosix, and look after it. > It would also be nice to have some form of a VPN used during the boot > process and subsequent distribution of runtime images. Make it easy to > boot secure and the rest of the security will fall into place. I don't see what you are trying to achieve here. Given a bare-metal machine, the only unique thing on it is the MAC address on the NIC. That is of course used to allocate DHCP addresses etc. We, and many other cluster vendors, use the MAC address as the unique aspect of a node. Yes, you can generate host keys and have the central server retrieve them, but that's in the firstboot stage. Early in the boot/install process you only have the MAC address. I suspect your concept is 'only securely identifiable machines get access to the VPN to then get their PXE download, DHCP, image download...'. My contention is that the MAC is the only 'key' at this stage. And swapping machines out for new in a MAC based environment is easy. If you are considering some physical way to distribute keys to a VPN then it won't scale - either in the data centre environment with 1000's or nodes in a cluster, or in the corporate environment where a tech would have to deliver a floppy/USB stick/dongle... I'm happy to be proved wrong. Maybe there's a scheme to allocate keys over the network. From 23e9t5t02 at sneakemail.com Tue Sep 14 16:45:07 2004 From: 23e9t5t02 at sneakemail.com (Steve Coleman) Date: Tue, 14 Sep 2004 12:45:07 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095176159.10739.140.camel@vigor12> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> Message-ID: <10152-71629@sneakemail.com> John Hearns john.hearns-at-clustervision.com |fedora| wrote: > My contention is that the MAC is the only 'key' at this > stage. I was just basically saying to make sure security is thought about early in the boot process, or at least as early as possible. Authenticating and verifying images can only be done reliably when there is a security context of some sort installed already. If there is a way to cache a vpn key locally to be used for the initial boot process then spoofing the MAC address (think 'script kiddies' here) would do you little good. That of course assumes a way to cache the key across instances of the OS, but they did mention that local caching was a goal of the proposed system. If a locally cached key is not configured/available then using the hardware MAC is the best you can do and it should fall back to the mode that you suggested. But having the key cached locally could essentially do what M$ Palladium(tm) aimed to do by verifying the runtime boot images first and giving you a verifiable core memory image free of network delivered rootkits etc.. If someone chose to enable that extra security feature then they could be reasonably ensured that *every* machine in their domain is not running a hacked image. If one delivered image is hacked then they all might be, and how would you know which? The verified memory image would then go on to verify that the rest of the system security is also sound, like to the SELinux level if it is configured that way. Not everyone needs this kind of setup, but some do. > Speaking as someone who looks after a Mosix cluster, > from what I've read I doubt Mosix will ever make it into > the official Linux kernel. As for Mosix I am likely putting my foot in my mouth, as I never used it. I do fault tolerant distributed processing but I do customized applications for research purposes. I do however like the ideas that Mosix is trying to achieve. I have had to build a system much like that myself and appreciate how nice it would be to have those features available on every machine by default. I would love to hear more of your thoughts about Mosix off line if you have a few minutes to spare. ;) Other than that I was just rambling on. - lol Steve Coleman http://www jhuapl edu/ steve.coleman [atsign] jhuapl [adot] edu From john.hearns at clustervision.com Tue Sep 14 16:53:42 2004 From: john.hearns at clustervision.com (John Hearns) Date: Tue, 14 Sep 2004 17:53:42 +0100 Subject: "Stateless Linux" project In-Reply-To: <10152-71629@sneakemail.com> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> Message-ID: <1095180821.10739.145.camel@vigor12> On Tue, 2004-09-14 at 17:45, Steve Coleman wrote: > John Hearns john.hearns-at-clustervision.com |fedora| wrote: > > > My contention is that the MAC is the only 'key' at this > > stage. > > > Speaking as someone who looks after a Mosix cluster, > > from what I've read I doubt Mosix will ever make it into > > the official Linux kernel. > > As for Mosix I am likely putting my foot in my mouth, as I never used > it. Steve, not at all. In fact I thought I was putting my foot in my mouth. That's what discussion lists are for. I have always liked Mosix, and have followed it. One of our customers uses Mosix on his cluster, as it is a 'fire and forget' solution, and he doesn't want the fuss of a batch system. For him, it works marvellously. On the Beowulf list recently, there was a post from someone from SAP (I think) asking about migrating vmware images. Interesting... Sadly they don't migrate. Only certain processes migrate - have a look at the Mosix wiki. And my remarks about the Linux kernel are based on something I rad once about Linus saying he would never have it in the kernel. From 23e9t5t02 at sneakemail.com Tue Sep 14 17:28:14 2004 From: 23e9t5t02 at sneakemail.com (Steve Coleman) Date: Tue, 14 Sep 2004 13:28:14 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095180821.10739.145.camel@vigor12> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095180821.10739.145.camel@vigor12> Message-ID: <20490-85369@sneakemail.com> John Hearns john.hearns-at-clustervision.com |fedora| wrote: > On the Beowulf list recently, there was a post from someone from SAP > (I think) asking about migrating vmware images. Interesting... I think that the OS would need specialized support to do that. For what its worth I use vmware, and I would not even attempt to migrate something with it. Its not an application per se, nor an OS, and there is lots of magic involved since not all x86 asm ops are virtualizable. Look at the old plex86 if you want to learn about that kind of stuff, the new one only runs Linux images under Linux as to run more efficiently without lots of code scanning and op replacements to trap them as a work around. > Sadly they don't migrate. Only certain processes migrate Yes, and thats actually why I don't use it here. Without thread support it is useless to me because most my applications have at least 5 threads, and thats just the framework that sits under the applications which may add *lots* more. If they ever get thread support working I have lots of ideas to try out. :)) > And my remarks about the Linux kernel are based on something I rad > once about Linus saying he would never have it in the kernel. I'd like to know what his objection to it was. Philosophical, or technical reasons I wonder. I Guess I'll google for that answer. Steve Coleman From bryan at ayesha.phys.Virginia.EDU Tue Sep 14 17:40:06 2004 From: bryan at ayesha.phys.Virginia.EDU (Bryan K. Wright) Date: Tue, 14 Sep 2004 13:40:06 -0400 Subject: "Stateless Linux" project Message-ID: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> Hi folks, The stateless project is a great idea. Thanks for pursuing this. One concern, though: the pdf overview says: "No question that work remains. However, a categorical policy going forward is that we expect an office productivity worker to be able to use all their hardware without the root password, and without touching the command line. We will consider it a bug if desktop-class hardware requires either root or opening a terminal." This sounds fine, but please don't REQUIRE a graphical interface to use the hardware. I have lots of researchers who ssh into group servers and use USB disks, shared tape drives, printers, etc. On another topic, the overview notes that disaster recovery for laptops requires that the laptop home directory be backed up often -- "perhaps whenever the laptop connects to the intranet". Toward this end, will the stateless project incorporate support for network block devices? A local disk in a "RAID 1" array with a remote block device sounds like a good way to ensure that an up-to-date remote copy of files is maintained while the user is connected. When the connection is broken, the remote half of the mirror would be unavailable, and the local disk would be used. On reconnection, the halves of the mirror would resync. Thanks, Bryan -- =============================================================================== Bryan Wright |"If you take cranberries and stew them like Physics Department | applesauce, they taste much more like prunes University of Virginia | than rhubarb does." -- Groucho Charlottesville, VA 22901 | (434) 924-7218 | bryan at virginia.edu =============================================================================== From jjengla at sandia.gov Tue Sep 14 17:44:07 2004 From: jjengla at sandia.gov (Josh England) Date: Tue, 14 Sep 2004 10:44:07 -0700 Subject: "Stateless Linux" project In-Reply-To: <10152-71629@sneakemail.com> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> Message-ID: <1095183847.10863.32.camel@localhost> On Tue, 2004-09-14 at 09:45, Steve Coleman wrote: > John Hearns john.hearns-at-clustervision.com |fedora| wrote: > I was just basically saying to make sure security is thought about early > in the boot process, or at least as early as possible. I believe the best way to implement a security model here would be to add the authentication into the initrd. Some form of authentication could be done before the root filesystem is ever mounted, but NFS v3 is not a secure protocol. If NFS is being exported to a certain node, no amount of client-side authentication can stop someone from getting to a prompt and running the 'mount -t nfs' by hand. This pushes the security concerns onto the NFS server. I believe that NFS v4 has paid more attention to security details. -JE From dragoran at feuerpokemon.de Tue Sep 14 18:07:59 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 14 Sep 2004 20:07:59 +0200 Subject: Gnome 2.8 and menu editing Message-ID: <4147337F.3040907@feuerpokemon.de> will menu editing be enabled in gnome2.8 /fc3 ? or is it still buggy? From jjengla at sandia.gov Tue Sep 14 18:09:57 2004 From: jjengla at sandia.gov (Josh England) Date: Tue, 14 Sep 2004 11:09:57 -0700 Subject: "Stateless Linux" project In-Reply-To: <1095183847.10863.32.camel@localhost> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> Message-ID: <1095185397.10863.53.camel@localhost> I believe the following are desirable features: - bit-for-bit identical filesystem - ability to group nodes into classes of functional roles - inheritance hierarchy for functional roles - ability to have different behavior for any node/role - ability to locally deploy chosen bits of the rootfs onto a local disk - ability to boot fully diskless - central configuration - distribution independent - easy to use oneSIS (http://onesis.sourceforge.net) has all of these features and more. I've set it up on many, many systems, and have found it to be very flexible, easy to use, and easily extensible. I've used it in production environments (+500 machines, several roles, single root FS) for several years. I would very much encourage you guys to take a look at the software and leave feedback. More than a starting point, it already provides a complete solution for much of what I think you're trying to accomplish. -JE ----------------------------------------------- Josh England Sandia National Laboratory, Livermore, CA High Performance Computing and Networking email: jjengla at sandia.gov phone: (925) 294-2076 On Tue, 2004-09-14 at 10:44, Josh England wrote: > On Tue, 2004-09-14 at 09:45, Steve Coleman wrote: > > John Hearns john.hearns-at-clustervision.com |fedora| wrote: > > > I was just basically saying to make sure security is thought about early > > in the boot process, or at least as early as possible. > > I believe the best way to implement a security model here would be to > add the authentication into the initrd. Some form of authentication > could be done before the root filesystem is ever mounted, but NFS v3 is > not a secure protocol. If NFS is being exported to a certain node, no > amount of client-side authentication can stop someone from getting to a > prompt and running the 'mount -t nfs' by hand. This pushes the security > concerns onto the NFS server. I believe that NFS v4 has paid more > attention to security details. > > -JE > From drepper at redhat.com Tue Sep 14 18:14:51 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Tue, 14 Sep 2004 11:14:51 -0700 Subject: glibc-2.3.3-51 breaks m4 In-Reply-To: <20040914135247.32276.qmail@web50601.mail.yahoo.com> References: <20040914135247.32276.qmail@web50601.mail.yahoo.com> Message-ID: <4147351B.4020008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve G wrote: > The latest glibc in rawhide breaks the compile of m4: m4 is just one of many programs which incorrectly use glibc symbols. These apps never should have done that and the change I've made exposes this. But conceding to the laziness of the developers of those packages I've implemented the underlying change differently and __P will be back in its old form soon. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBRzUb2ijCOnn/RHQRAoohAKCK4UyIIDs2wSdlUDYpIkzxQJJgAwCgnqBd 4/E6SfV3C//YFLePKg+z1gM= =mCOg -----END PGP SIGNATURE----- From linux_4ever at yahoo.com Tue Sep 14 18:21:20 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 14 Sep 2004 11:21:20 -0700 (PDT) Subject: glibc-2.3.3-51 breaks m4 In-Reply-To: <4147351B.4020008@redhat.com> Message-ID: <20040914182120.89094.qmail@web50607.mail.yahoo.com> >> The latest glibc in rawhide breaks the compile of m4: > >m4 is just one of many programs which incorrectly use glibc symbols. >These apps never should have done that and the change I've made exposes >this. OK, this is what I was curious about. __P is defined in config.h of m4, but subsequent headers are pulled in. Some of the glibc headers do an undef of __P which I think is where the problem lies. >But conceding to the laziness of the developers of those packages >I've implemented the underlying change differently and __P will be back >in its old form soon. The patch is trivial. I just wanted to know which way this should be fixed. Do you want to leave glibc in this form or do you want me to file this in bugzilla with m4's patch? Thanks for the quick answer. -Steve Grubb _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From markmc at redhat.com Tue Sep 14 18:48:55 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 14 Sep 2004 19:48:55 +0100 Subject: Gnome 2.8 and menu editing In-Reply-To: <4147337F.3040907@feuerpokemon.de> References: <4147337F.3040907@feuerpokemon.de> Message-ID: <1095187735.8719.3.camel@localhost.localdomain> Hi, On Tue, 2004-09-14 at 19:07, dragoran wrote: > will menu editing be enabled in gnome2.8 /fc3 ? or is it still buggy? > No change from FC2, hopefully will be targeted in 2.10. See: http://www.redhat.com/archives/fedora-desktop-list/2004-September/thread.html#00000 Cheers, Mark. From skvidal at phy.duke.edu Tue Sep 14 18:57:18 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 14 Sep 2004 14:57:18 -0400 Subject: Outage Notice Message-ID: <1095188237.32569.84.camel@opus.phy.duke.edu> Hi All, The Physics Department of Duke University will have a site-wide power outage for 8 hours on Friday Sept 17th from 6PM(1800) until 2AM(0200) Saturday Sept 18th. This affects: * fedora.linux.duke.edu * fedoraproject.org * www.linux.duke.edu * lists.linux.duke.edu * potentially: mirror.linux.duke.edu (depending on dns) * torrent.linux.duke.edu Tell your friends, tell your family, tell your enemies, just don't come complaining to me that you weren't warned. -sv From dragoran at feuerpokemon.de Tue Sep 14 18:59:08 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 14 Sep 2004 20:59:08 +0200 Subject: Gnome 2.8 and menu editing In-Reply-To: <1095187735.8719.3.camel@localhost.localdomain> References: <4147337F.3040907@feuerpokemon.de> <1095187735.8719.3.camel@localhost.localdomain> Message-ID: <41473F7C.8020106@feuerpokemon.de> Mark McLoughlin schrieb: >Hi, > >On Tue, 2004-09-14 at 19:07, dragoran wrote: > > >>will menu editing be enabled in gnome2.8 /fc3 ? or is it still buggy? >> >> >> > > No change from FC2, hopefully will be targeted in 2.10. See: > >http://www.redhat.com/archives/fedora-desktop-list/2004-September/thread.html#00000 > >Cheers, >Mark. > > > > ok thank you for the link From dmalcolm at redhat.com Tue Sep 14 19:07:17 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 14 Sep 2004 15:07:17 -0400 Subject: "Stateless Linux" project In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDD0F@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDD0F@smith.interlink.local> Message-ID: <1095188837.30762.20.camel@cassandra.boston.redhat.com> On Tue, 2004-09-14 at 10:31 -0400, Erik LaBianca wrote: > > > > Hi, > > > > Red Hat engineering is starting a new project we're calling > > "stateless Linux" for lack of a better name - some components of this > > are already in Rawhide, and others will be appearing shortly. > > > > Appreciate feedback, especially from anyone who has time to try out > > the HOWTO. We expect the code to change quite a bit as issues and > > suggestions come in. > > > > Havoc > > > > I too am thrilled to see this happening. It's this sort of technology > that has the potential to give linux a solid leg up on the competition > for both the desktop and the server. > > I have a couple of questions. > > 1. Do I need to be running rawhide to test out the read-only root rpms > and the HOWTO? You could ask this question separately for the client and the server. Most of our recent testing on this has been against the latest versions of FC3 for both client and server, since we've trying as far as possible to integrate support for this into the rest of the OS. There have been small fixes in various packages to make booting with a readonly root filesystem easier, on the client side, and I believe there have been some LVM fixes on the server side. I don't have a list to hand, unfortunately. It would be interesting to see how well the HOWTO works against, say, FC2. You'll need to rebuild the various packages (SRPMs are in my people.redhat.com site); the main new dependency IIRC is python-ldap, which is Rawhide and the FC3 test isos but not in FC2 (though there are RPMs of it on Fedora us. Another thing you may want to try is to use the Live CD creation tool in the readonly-root package; I hope that with an appropriate selection of packages you'd be able to squeeze a bootable Fedora onto a Live CD. > > 2. Configuration management. I've been trying to extract my > configuration from running systems for a while now, but not really been > entirely successful. Typically the list of files to "watch" gets > unwieldy, or someone forgets to make the .orig file, or commit to cvs. I > think ideally a configuration management system would integrate rpm (to > know what files are config files) and cvs/subversion (to provide > revision control) in such a way that you have revision controlled > configuration files available off-system. > > In a truly stateless system, you could just export all the config files > from CVS into the ramdisk on bootup. > > I'd REALLY like to be able to edit files on a "live" system, and type a > command to "check in" my changes. I'd like to be able to use the same > system to show my the change history for a given file, and to ease > forward migration. So, in the terminology of the HOWTO, you'd want to boot off a protosystem directly in read/write mode, make some changes, then take a new snapshot. We're some way towards this, but not there yet. > > Is this sort of thing within the scope of this project? > > 3. I'd like to recommend looking at including the linux-vserver [1] > patches and tools with the OS distribution for server-side applications. > All the aforementioned technology would be an ideal fit in virtual > servers, and the ability to keep all your "logical servers" in virtual > sandboxes makes testing and deployment in smaller environments much > easier. > > Statelessness would make virtual servers far more efficient, since you > could run them all off the same physical filesystem instead of making > hard link trees. > > I'm already close to running "stateless servers" just by keeping them in > virtual machines, where I can shut them down and rsync them to a > different physical machine without leaving my desk. > > Thanks > > --erik > > > [1] http://www.linux-vserver.net/ > > From mattdm at mattdm.org Tue Sep 14 19:41:03 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 14 Sep 2004 15:41:03 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <20040914194103.GA8106@jadzia.bu.edu> On Mon, Sep 13, 2004 at 02:42:35PM -0400, Havoc Pennington wrote: > Red Hat engineering is starting a new project we're calling > "stateless Linux" for lack of a better name - some components of this > are already in Rawhide, and others will be appearing shortly. [snip] > - an overview document, available from > http://people.redhat.com/~hp/stateless/ I think my small patch to usermode to allow group-based auth-as-self (i.e. admin users don't need root password, but still need to reenter their own) fits nicely with some of the goals expressed. (Makes sense for systrem-config-date, for example.) So I'll take this moment to plug it again. :) Please see: -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kyrre at solution-forge.net Tue Sep 14 20:23:05 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 14 Sep 2004 22:23:05 +0200 Subject: "Stateless Linux" project In-Reply-To: <10152-71629@sneakemail.com> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> Message-ID: <1095193385.2682.1.camel@kyrre> tir, 14.09.2004 kl. 18.45 skrev Steve Coleman: > John Hearns john.hearns-at-clustervision.com |fedora| wrote: > > > My contention is that the MAC is the only 'key' at this > > stage. > > I was just basically saying to make sure security is thought about early > in the boot process, or at least as early as possible. Authenticating > and verifying images can only be done reliably when there is a security > context of some sort installed already. If there is a way to cache a vpn > key locally to be used for the initial boot process then spoofing the > MAC address (think 'script kiddies' here) would do you little good. That > of course assumes a way to cache the key across instances of the OS, but > they did mention that local caching was a goal of the proposed system. > > If a locally cached key is not configured/available then using the > hardware MAC is the best you can do and it should fall back to the mode > that you suggested. But having the key cached locally could essentially > do what M$ Palladium(tm) aimed to do by verifying the runtime boot > images first and giving you a verifiable core memory image free of > network delivered rootkits etc.. If someone chose to enable that extra > security feature then they could be reasonably ensured that *every* > machine in their domain is not running a hacked image. If one delivered > image is hacked then they all might be, and how would you know which? > The verified memory image would then go on to verify that the rest of > the system security is also sound, like to the SELinux level if it is > configured that way. Not everyone needs this kind of setup, but some do. > > > Speaking as someone who looks after a Mosix cluster, > > from what I've read I doubt Mosix will ever make it into > > the official Linux kernel. > > As for Mosix I am likely putting my foot in my mouth, as I never used > it. I do fault tolerant distributed processing but I do customized > applications for research purposes. I do however like the ideas that > Mosix is trying to achieve. I have had to build a system much like that > myself and appreciate how nice it would be to have those features > available on every machine by default. > > I would love to hear more of your thoughts about Mosix off line if you > have a few minutes to spare. ;) > > Other than that I was just rambling on. - lol > > Steve Coleman > http://www jhuapl edu/ > steve.coleman [atsign] jhuapl [adot] edu > > > > One way to cache VPN keys localy (and other stuff) would be to mount /etc on a flash-disk. But that might again defeat the whole purpose of this stuff... From alan at redhat.com Tue Sep 14 20:27:34 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 14 Sep 2004 16:27:34 -0400 Subject: "Stateless Linux" project In-Reply-To: <20490-85369@sneakemail.com> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095180821.10739.145.camel@vigor12> <20490-85369@sneakemail.com> Message-ID: <20040914202734.GA4100@devserv.devel.redhat.com> On Tue, Sep 14, 2004 at 01:28:14PM -0400, Steve Coleman wrote: > Look at the old plex86 if you want to learn about that kind of stuff, > the new one only runs Linux images under Linux as to run more > efficiently without lots of code scanning and op replacements to trap > them as a work around. Or Xen. Xen takes a different approach and runs a slightly modified Linux (or OpenBSD, or several other things) in what they call "paravirtualization". Xen has very very low overhead and also supports mildly insane things like moving a running Linux image between two machines without downtime of any note From alan at redhat.com Tue Sep 14 20:29:21 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 14 Sep 2004 16:29:21 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095183847.10863.32.camel@localhost> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> Message-ID: <20040914202921.GB4100@devserv.devel.redhat.com> On Tue, Sep 14, 2004 at 10:44:07AM -0700, Josh England wrote: > prompt and running the 'mount -t nfs' by hand. This pushes the security > concerns onto the NFS server. I believe that NFS v4 has paid more > attention to security details. So I hack DHCP, or the kernel PXE boot. Booting without keys on local storage is a known hard problem. I'm not aware of any solutions From snickell at redhat.com Tue Sep 14 20:55:03 2004 From: snickell at redhat.com (Seth Nickell) Date: Tue, 14 Sep 2004 16:55:03 -0400 Subject: "Stateless Linux" project In-Reply-To: <20040914202921.GB4100@devserv.devel.redhat.com> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> <20040914202921.GB4100@devserv.devel.redhat.com> Message-ID: <1095195303.4205.5.camel@localhost.localdomain> On Tue, 2004-09-14 at 16:29 -0400, Alan Cox wrote: > On Tue, Sep 14, 2004 at 10:44:07AM -0700, Josh England wrote: > > prompt and running the 'mount -t nfs' by hand. This pushes the security > > concerns onto the NFS server. I believe that NFS v4 has paid more > > attention to security details. > > So I hack DHCP, or the kernel PXE boot. Booting without keys on local storage > is a known hard problem. I'm not aware of any solutions The design plan for this involves using keys on first "install" as one of the three or four things you have to set. The keys should also specify the IP address of the directory server, so everything else should be fetchable from there. I don't think we've moved this into the technical bits yet though. -Seth From hp at redhat.com Tue Sep 14 21:02:43 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 14 Sep 2004 17:02:43 -0400 Subject: "Stateless Linux" project In-Reply-To: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> Message-ID: <1095195763.4127.74.camel@localhost.localdomain> On Tue, 2004-09-14 at 13:40 -0400, Bryan K. Wright wrote: > > This sounds fine, but please don't REQUIRE a graphical interface > to use the hardware. I have lots of researchers who ssh into group servers > and use USB disks, shared tape drives, printers, etc. Certainly, you will always be able to do things "manually" > On another topic, the overview notes that disaster recovery for > laptops requires that the laptop home directory be backed up often -- > "perhaps whenever the laptop connects to the intranet". Toward this end, > will the stateless project incorporate support for network block devices? > A local disk in a "RAID 1" array with a remote block device sounds like > a good way to ensure that an up-to-date remote copy of files is maintained > while the user is connected. When the connection is broken, the remote > half of the mirror would be unavailable, and the local disk would be used. > On reconnection, the halves of the mirror would resync. That's a clever idea. Dan Reed has some code written that's a bit simpler approach - it just rsyncs the homedir periodically. The hard questions on homedir backup seem to be around how it interfaces to an "industrial strength" backup solution, i.e. we can keep the homedir synced to a network share pretty easily, but how does that interact with incremental backups and so forth. Havoc From jjengla at sandia.gov Tue Sep 14 21:03:52 2004 From: jjengla at sandia.gov (Josh England) Date: Tue, 14 Sep 2004 14:03:52 -0700 Subject: "Stateless Linux" project In-Reply-To: <20040914202921.GB4100@devserv.devel.redhat.com> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> <20040914202921.GB4100@devserv.devel.redhat.com> Message-ID: <1095195831.10863.75.camel@localhost> On Tue, 2004-09-14 at 13:29, Alan Cox wrote: > So I hack DHCP, or the kernel PXE boot. Booting without keys on local storage > is a known hard problem. I'm not aware of any solutions You have to imagine the client as being fully diskless. Anything and everything that a client needs to boot is supplied by the server. There can be no key on the client that wasn't first shipped to it (ie: in an initrd) by the server. All thats left is using a DRM-like key in CMOS somewhere and passing that in with the initial PXE requests, but that's ugly and requires BIOS vendors to buy-in. -JE From snickell at redhat.com Tue Sep 14 21:09:51 2004 From: snickell at redhat.com (Seth Nickell) Date: Tue, 14 Sep 2004 17:09:51 -0400 Subject: "Stateless Linux" project In-Reply-To: <20040914202734.GA4100@devserv.devel.redhat.com> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095180821.10739.145.camel@vigor12> <20490-85369@sneakemail.com> <20040914202734.GA4100@devserv.devel.redhat.com> Message-ID: <1095196191.4205.14.camel@localhost.localdomain> On Tue, 2004-09-14 at 16:27 -0400, Alan Cox wrote: > On Tue, Sep 14, 2004 at 01:28:14PM -0400, Steve Coleman wrote: > > Look at the old plex86 if you want to learn about that kind of stuff, > > the new one only runs Linux images under Linux as to run more > > efficiently without lots of code scanning and op replacements to trap > > them as a work around. > > Or Xen. Xen takes a different approach and runs a slightly modified Linux > (or OpenBSD, or several other things) in what they call "paravirtualization". > Xen has very very low overhead and also supports mildly insane things like > moving a running Linux image between two machines without downtime of any > note We are actually considering using Xen2 at the moment on the image server side for running the protosystem images. We've been coodrinating some with the cluster dudes who are also interested in Xen. -Seth From 23e9t5t02 at sneakemail.com Tue Sep 14 22:08:27 2004 From: 23e9t5t02 at sneakemail.com (Steve Coleman) Date: Tue, 14 Sep 2004 18:08:27 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095195763.4127.74.camel@localhost.localdomain> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> Message-ID: <16077-94241@sneakemail.com> Havoc Pennington hp-at-redhat.com |fedora| wrote: > On Tue, 2004-09-14 at 13:40 -0400, Bryan K. Wright wrote: >>When the connection is broken, the remote >>half of the mirror would be unavailable, and the local disk would be used. >>On reconnection, the halves of the mirror would resync. > > > That's a clever idea. Dan Reed has some code written that's a bit > simpler approach - it just rsyncs the homedir periodically. The remote on-again-off-again network distributed file system is exactly what CODA is designed for. And it handles laptops in disconnected mode, caches files, and merges changes back in on reconnect. Lots of good stuff in there, and many lessons learned. You may find slight differences in your requirements but it deserves a close look because it addresses most of the problems I have read about in this thread so far. From hp at redhat.com Tue Sep 14 23:18:55 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 14 Sep 2004 19:18:55 -0400 Subject: "Stateless Linux" project In-Reply-To: <16077-94241@sneakemail.com> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <16077-94241@sneakemail.com> Message-ID: <1095203935.4127.96.camel@localhost.localdomain> On Tue, 2004-09-14 at 18:08 -0400, Steve Coleman wrote: > The remote on-again-off-again network distributed file system is exactly > what CODA is designed for. And it handles laptops in disconnected mode, > caches files, and merges changes back in on reconnect. Lots of good > stuff in there, and many lessons learned. You may find slight > differences in your requirements but it deserves a close look because it > addresses most of the problems I have read about in this thread so far. > Right, the .pdf mentions Coda (and also more generally the idea of using a filesystem). The major downside of a filesystem approach is that filesystems are hard, and in the kernel, and supporting another one isn't trivial. The upside is that you can do some clever things on the filesystem level that are tricky with rsync-type userspace hacks, even rsync-type userspace hacks assisted by LVM. One of the points of the broad term "stateless Linux" though is to emphasize that our instantiation mode (whether Coda, NFS, AFS, rsync, live CD, or whatever) is only one tunable element of the architecture; the other elements should remain constant as you tune this element. Of course, we'll want to recommend some specific filesystem or other approach or approaches, I'm not saying we just make it configurable and forget the problem. What I'm saying is that it's important to keep the design of the overall system one level "higher" than how the bits end up on the CPU that execs them. One thing some of us would like to avoid is two-way sync (merge), since it seems to be impossible to put a reasonable UI on it no matter how cool your underlying technology, and seems to crank up the complexity of the underlying technology in a big way. If instead we do one-way sync (aka backup) with a very clear and simple user model, it's about as good for the typical desktop user. Of course, nothing in the architecture keeps you from using two-way sync, this is just a matter of what to work on first. Havoc From perbj at stanford.edu Tue Sep 14 23:31:13 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 14 Sep 2004 16:31:13 -0700 Subject: "Stateless Linux" project In-Reply-To: <1095195763.4127.74.camel@localhost.localdomain> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> Message-ID: <1095204673.2701.147.camel@localhost.localdomain> On Tue, 2004-09-14 at 14:02, Havoc Pennington wrote: > On Tue, 2004-09-14 at 13:40 -0400, Bryan K. Wright wrote: > > On another topic, the overview notes that disaster recovery for > > laptops requires that the laptop home directory be backed up often -- > > "perhaps whenever the laptop connects to the intranet". Toward this end, > > will the stateless project incorporate support for network block devices? > > A local disk in a "RAID 1" array with a remote block device sounds like > > a good way to ensure that an up-to-date remote copy of files is maintained > > while the user is connected. When the connection is broken, the remote > > half of the mirror would be unavailable, and the local disk would be used. > > On reconnection, the halves of the mirror would resync. > > That's a clever idea. Dan Reed has some code written that's a bit > simpler approach - it just rsyncs the homedir periodically. Sounds like it would actually functionally be pretty similar? At least if the rsync is done "as soon as possible" when the notebook gets connected to the "home" network. Actually I think this really needs some more smarts, in order to be really useful it has to be able to deal with changes made both on the server and on the client (at least if shared directories are included, and even if they aren't if one considers the case of one user who uses several computers using the same home directory). Possibly Unison or something similar might be a starting point: http://www.cis.upenn.edu/~bcpierce/unison/ Such a system keeps track of what files got changed on what side. It pretty much punts to the user if changes have been made to a file on both ends. (You can plug in a merge tool for merging text files though; I don't think that there is really any hope to "merge" more complex documents with any particular degree of automation.) I keep directories that I'm working in synced between a file server and my notebook, and I do sometimes muck around in both sides of the connection (e.g. dumping new measurement data on the file server, syncing, and analyzing the data on my notebook). This kind of serves as a simple userspace cached network filesystem. > The hard questions on homedir backup seem to be around how it interfaces > to an "industrial strength" backup solution, i.e. we can keep the > homedir synced to a network share pretty easily, but how does that > interact with incremental backups and so forth. Well backing up the disconnected notebook on a main backup server sounds hard! ;) In what scenario does just backing up the server side fail (apart from losing any changes since the last check-in)? As far as I can tell the backups should never really change any file state (apart from possibly atime) on the files? /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From hp at redhat.com Tue Sep 14 23:41:52 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 14 Sep 2004 19:41:52 -0400 Subject: user data sync (Re: "Stateless Linux" project) In-Reply-To: <1095164446.11530.204330179@webmail.messagingengine.com> References: <1095164446.11530.204330179@webmail.messagingengine.com> Message-ID: <1095205312.4127.119.camel@localhost.localdomain> On Tue, 2004-09-14 at 13:20 +0100, Stuart Ellis wrote: > > The issue of backing up user home directories from mobile devices in > mentioned in the PDF, but I'd be very interested in hearing about > approaches for dealing with syncing shared data stores. > > With a home directory or private data store basic sync works if it can > be made transparent to the user, and/or integrated into the GUI > (Off-line Files on MS Windows, Mac iDisk). > > Writable shared data stores presumably require some form of > reconciliation or version control for multiple off-line copies to be > handled smoothly. I suppose that one solution might be to wrap access > to a version control system into the standard GUI so that the > functionality becomes accessible to office workers; another might be to > use a database-backed system like Storage, which could replicate. > > How are people dealing with this issue on their networks now ? What do > we think would be the "Just Works" solution in the context of Stateless > Linux ? A sentiment around the office is that the "merge" concept is impossible to sanely present to users, and so instead we should stick to "master copy" and "backups" Here is one UI idea which may be attributable to Bryan and Seth or may be something they wish to disown. In any case, imagine you have two laptops, "Thinkpad" and "Inspiron", and a workstation "Optiplex". The Thinkpad is currently on the network, and the Inspiron is disconnected. You might see the following on the desktop of each system, in place of the current "hp's Home": Thinkpad Desktop: [icon] Thinkpad [icon] Copy of Inspiron [icon] Optiplex Inspiron Desktop: [icon] Inspiron Optiplex Desktop: [icon] Optiplex [icon] Thinkpad [icon] Copy of Inspiron So the "Copy of Inspiron" is a read-only backup of your Inspiron homedir (kept on some network share). The other icons are the actual homedirs on those systems. If you imagine I now connect the Inspiron, my Optiplex desktop changes in real time: [icon] Optiplex [icon] Thinkpad [icon] Inspiron And if I disconnect the Thinkpad, then instantly Optiplex displays: [icon] Optiplex [icon] Copy of Thinkpad [icon] Inspiron In the above example, the disconnected Inspiron didn't have "Copy of Optiplex" or "Copy of Thinkpad" but optionally you could have that, if you were willing to use the disk space to keep a disconnected copy rather than having "Copy of Foo" be a read-only network file share. This example is pretty contrived; making up numbers, I bet conservatively the 90% or more case is the user has only one computer, and the 98% case is only two, and the 2% case is more than two. We might also want to think about the user having a user-specific laptop, and then using multiuser sort of desktop systems. In that case perhaps there's a single network NFS homedir used for all desktop systems, and then a homedir for each laptop. Anyway, the basic point is there's only one writable copy of each homedir (the copy that lives on the laptop itself), and multiple read- only copies. For a file share used by multiple users, a simple approach is that they have a read only copy on their laptop, and it changes to the writable actual share while they are connected. Or just vanishes while disconnected, if appropriate. Just having reliable homedir backup, plus the above UI, would be very useful and dramatically better than what most people use today. Maybe a complex merge solution would be even better, but those solutions never seem to catch on even though they've been implemented many times... Havoc From hp at redhat.com Tue Sep 14 23:48:41 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 14 Sep 2004 19:48:41 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095204673.2701.147.camel@localhost.localdomain> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <1095204673.2701.147.camel@localhost.localdomain> Message-ID: <1095205721.4127.126.camel@localhost.localdomain> On Tue, 2004-09-14 at 16:31 -0700, Per Bjornsson wrote: > Such a system keeps track of what files got changed on what side. It > pretty much punts to the user if changes have been made to a file on > both ends. (You can plug in a merge tool for merging text files though; > I don't think that there is really any hope to "merge" more complex > documents with any particular degree of automation.) The merge part is where we think a large number of users will just go "huh?" ... though it doesn't hurt to have two-way sync available, it might be sort of a high effort to benefit ratio because of the UI problem. > > The hard questions on homedir backup seem to be around how it interfaces > > to an "industrial strength" backup solution, i.e. we can keep the > > homedir synced to a network share pretty easily, but how does that > > interact with incremental backups and so forth. > > Well backing up the disconnected notebook on a main backup server sounds > hard! ;) In what scenario does just backing up the server side fail > (apart from losing any changes since the last check-in)? As far as I can > tell the backups should never really change any file state (apart from > possibly atime) on the files? Dan's stuff right now keeps incremental backups (it uses rsync with the option to hardlink a new tree based on an old tree) and so the questions are e.g. when do you throw out the old backups, etc. Maybe the right answer is to make the rsync-to-server thingy dead stupid (no incremental backup or anything like that, though maybe it should ensure each sync is atomic by having two copies) and rely on backing up the server for getting incrementals and so forth. Havoc From jspaleta at gmail.com Tue Sep 14 23:59:50 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Sep 2004 19:59:50 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095205721.4127.126.camel@localhost.localdomain> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <1095204673.2701.147.camel@localhost.localdomain> <1095205721.4127.126.camel@localhost.localdomain> Message-ID: <604aa791040914165968c9ae37@mail.gmail.com> On Tue, 14 Sep 2004 19:48:41 -0400, Havoc Pennington wrote: > Dan's stuff right now keeps incremental backups (it uses rsync with the > option to hardlink a new tree based on an old tree) and so the questions > are e.g. when do you throw out the old backups, etc. why does this discussion keep reminding me of rdiff-backup? -jef From merriam at ntlworld.com Wed Sep 15 00:00:29 2004 From: merriam at ntlworld.com (William Merriam's most spammed mbox) Date: Wed, 15 Sep 2004 00:00:29 +0000 Subject: Stateless Linux -- HTML version of the PDF intro Message-ID: <4147861D.4080409@ntlworld.com> I realize it's a bit late, but here's an HTML version of the introduction, StatelessLinux.pdf, which Havoc Pennington referred to at the start of the Stateless Linux project thread. http://citethisbook.net/Red_Hat_Introduction_to_Stateless_Linux.html Something unusual about the original PDF prevents copying and pasting in xpdf and, I hear, even in Adobe Acrobat Reader 6.0 under windows. The problem also affects xpdf-utils, causing pdftotext to print garbage. From hp at redhat.com Wed Sep 15 00:12:16 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 14 Sep 2004 20:12:16 -0400 Subject: "Stateless Linux" project In-Reply-To: <604aa791040914165968c9ae37@mail.gmail.com> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <1095204673.2701.147.camel@localhost.localdomain> <1095205721.4127.126.camel@localhost.localdomain> <604aa791040914165968c9ae37@mail.gmail.com> Message-ID: <1095207136.4127.130.camel@localhost.localdomain> On Tue, 2004-09-14 at 19:59 -0400, Jeff Spaleta wrote: > On Tue, 14 Sep 2004 19:48:41 -0400, Havoc Pennington wrote: > > Dan's stuff right now keeps incremental backups (it uses rsync with the > > option to hardlink a new tree based on an old tree) and so the questions > > are e.g. when do you throw out the old backups, etc. > > why does this discussion keep reminding me of rdiff-backup? Looks like an interesting project. Havoc From skvidal at phy.duke.edu Wed Sep 15 00:42:34 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 14 Sep 2004 20:42:34 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095207136.4127.130.camel@localhost.localdomain> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <1095204673.2701.147.camel@localhost.localdomain> <1095205721.4127.126.camel@localhost.localdomain> <604aa791040914165968c9ae37@mail.gmail.com> <1095207136.4127.130.camel@localhost.localdomain> Message-ID: <1095208954.23039.17.camel@binkley> On Tue, 2004-09-14 at 20:12 -0400, Havoc Pennington wrote: > On Tue, 2004-09-14 at 19:59 -0400, Jeff Spaleta wrote: > > On Tue, 14 Sep 2004 19:48:41 -0400, Havoc Pennington wrote: > > > Dan's stuff right now keeps incremental backups (it uses rsync with the > > > option to hardlink a new tree based on an old tree) and so the questions > > > are e.g. when do you throw out the old backups, etc. > > > > why does this discussion keep reminding me of rdiff-backup? > > Looks like an interesting project. Ryan Tomayko, a while back, was working on a front end/config interface to rdiff-backup that would allow the user to select files/dirs they wanted to have rdiff-backup get. He also had looked into interfacing it w/rpm-python to make sure it didn't grab files managed by rpm - or if it did only backing up those files that have changed since the rpm install. -sv From hp at redhat.com Wed Sep 15 01:07:38 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 14 Sep 2004 21:07:38 -0400 Subject: how about oneSIS? was: "Stateless Linux" project In-Reply-To: <1095174373.6592.28.camel@localhost> References: <1095174373.6592.28.camel@localhost> Message-ID: <1095210458.4127.143.camel@localhost.localdomain> Hi, On Tue, 2004-09-14 at 08:06 -0700, Josh England wrote: > The project is called oneSIS (http://onesis.sourceforge.net). We've used > it in production for running clusters for years, but I've just recently > (early this year) re-written it from scratch to make it cleaner and more > flexible. Grab the CVS version from sourceforge and check it out. It > makes everything the "Stateless linux" project is trying to do very, very > easy. Reading the manual now, this looks great. The changes we're making to Fedora should eliminate the rc script changes you mention here: http://onesis.sourceforge.net/oneSIS-manual/node22.html This is very clever: http://onesis.sourceforge.net/oneSIS-manual/node17.html Anyway, I think it will take us some time to digest how this maps to the desktop/server case in addition to clusters, and how to fit it together with the work we have so far. Your thoughts on how to pull it all together are welcome. Havoc From perbj at stanford.edu Wed Sep 15 01:07:02 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 14 Sep 2004 18:07:02 -0700 Subject: "Stateless Linux" project In-Reply-To: <1095205721.4127.126.camel@localhost.localdomain> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <1095204673.2701.147.camel@localhost.localdomain> <1095205721.4127.126.camel@localhost.localdomain> Message-ID: <1095210422.2701.215.camel@localhost.localdomain> On Tue, 2004-09-14 at 16:48, Havoc Pennington wrote: > On Tue, 2004-09-14 at 16:31 -0700, Per Bjornsson wrote: > > Such a system keeps track of what files got changed on what side. It > > pretty much punts to the user if changes have been made to a file on > > both ends. (You can plug in a merge tool for merging text files though; > > I don't think that there is really any hope to "merge" more complex > > documents with any particular degree of automation.) > > The merge part is where we think a large number of users will just go > "huh?" ... though it doesn't hurt to have two-way sync available, it > might be sort of a high effort to benefit ratio because of the UI > problem. Yes, presenting true file merging functionality is certainly difficult, but propagating files that have only been changed on one end in the right direction should be doable completely automatically. I believe that this solves the main problem. One alternative to presenting true merge functionality might be something like a dialog box that asks: --- The file "my-spreadsheet.sxi" has been changed both on the server and on your local computer since the last synchronization. --- (Gnome style button order, "Rename local copy" is the default, and it then pops up something that looks like the Nautilus rename dialog box.) Is that a usability disaster too? In any case, if syncs are done often (as they should be if this is supposed to keep things backed up), the likelihood of this situation (essentially a screwup) is fairly small, at least for personal directories. Of course doing something like this with a shared directory with lots of people working on the files is more difficult, but without some kind of out-of-band locking mechanism (e.g. an e-mail saying "hey, can you look at my changes and see if you like them") this is very difficult anyways. Both MS Office and OpenOffice.org have some version control features as far as I know, but do either of them deal with merging documents that have diverged from a common source? As a side note, I personally actually don't think that the Unison interface (where you get a list of changed files and can choose in which direction to propagate conflicting changes or choose to rename one of the files in case of conflicts) is too bad, but I'm probably way to geeky to be part of the target audience. ... > Maybe the right answer is to make the rsync-to-server thingy dead stupid > (no incremental backup or anything like that, though maybe it should > ensure each sync is atomic by having two copies) and rely on backing up > the server for getting incrementals and so forth. That certainly sounds like the easiest solution, and not a bad one as far as I can tell. It's not safe to ignore real backups anyways. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From dcbw at redhat.com Wed Sep 15 01:15:08 2004 From: dcbw at redhat.com (Dan Williams) Date: Tue, 14 Sep 2004 21:15:08 -0400 (EDT) Subject: "Stateless Linux" project In-Reply-To: <1095195303.4205.5.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> <20040914202921.GB4100@devserv.devel.redhat.com> <1095195303.4205.5.camel@localhost.localdomain> Message-ID: So, I can't remeber if anybody mentioned this, but: How about using config info stored on a USB keydriver? A relatively simple GUI app could dump the config information to one/multiple keydrives which could then be plugged into the machine when it boots up, and an initial installation program would get values from the keydrive. Could optionally encrypt the data on the drive since the OS image from the server would certainly have the keys to decrypt the info on the keydrive. On a side note, Microsoft does this for wireless configuration of some sort with Wireless Zero Configuration, but I don't think for anything OS-based (correct me if I'm wrong). Dan On Tue, 14 Sep 2004, Seth Nickell wrote: > On Tue, 2004-09-14 at 16:29 -0400, Alan Cox wrote: > > On Tue, Sep 14, 2004 at 10:44:07AM -0700, Josh England wrote: > > > prompt and running the 'mount -t nfs' by hand. This pushes the security > > > concerns onto the NFS server. I believe that NFS v4 has paid more > > > attention to security details. > > > > So I hack DHCP, or the kernel PXE boot. Booting without keys on local storage > > is a known hard problem. I'm not aware of any solutions > > The design plan for this involves using keys on first "install" as one > of the three or four things you have to set. The keys should also > specify the IP address of the directory server, so everything else > should be fetchable from there. I don't think we've moved this into the > technical bits yet though. > > -Seth > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From drepper at redhat.com Wed Sep 15 02:32:23 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Tue, 14 Sep 2004 19:32:23 -0700 Subject: glibc-2.3.3-51 breaks m4 In-Reply-To: <20040914182120.89094.qmail@web50607.mail.yahoo.com> References: <20040914182120.89094.qmail@web50607.mail.yahoo.com> Message-ID: <4147A9B7.70904@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve G wrote: > The patch is trivial. I just wanted to know which way this should be fixed. Do > you want to leave glibc in this form or do you want me to file this in bugzilla > with m4's patch? glibc-2.3.3-53 (when released) will have the __P macro in the form m4 and other packages expects it. glibc itself will simply not use the macro anymore, at all, so it doesn't matter the optimizations we introduced through __P are not present. No need to file any bugs related to this. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBR6m22ijCOnn/RHQRAge8AJ47VzRIY++2k9LXDzWuka2IQWdwaQCfWzdj 2Z2USg50OdXY9GQeFZ6bAhA= =JvUf -----END PGP SIGNATURE----- From john.hearns at clustervision.com Wed Sep 15 06:02:31 2004 From: john.hearns at clustervision.com (John Hearns) Date: Wed, 15 Sep 2004 07:02:31 +0100 Subject: "Stateless Linux" project In-Reply-To: <1095203935.4127.96.camel@localhost.localdomain> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <16077-94241@sneakemail.com> <1095203935.4127.96.camel@localhost.localdomain> Message-ID: <1095228150.10739.159.camel@vigor12> On Wed, 2004-09-15 at 00:18, Havoc Pennington wrote: > > One thing some of us would like to avoid is two-way sync (merge), since > it seems to be impossible to put a reasonable UI on it no matter how > cool your underlying technology, and seems to crank up the complexity of > the underlying technology in a big way Talking about a two-way sync... At the UKUUG Linux Developers Conference in Leeds Dave Coombs gave a presentation on a project called WvSync. There was a pretty good demonstration of two-way merging, which he has given a great deal of attention to. http://www.ukuug.org/events/linux2004/programme/abstract-DCoombs-1.shtml http://www.ukuug.org/events/linux2004/programme/paper-DCoombs-1/wvsync.pdf http://open.nit.ca/wiki/?page=WvSync WvSync is a general framework for replicating named objects (which can be files, but also many other things). Have a look - it might find a place here. From john.hearns at clustervision.com Wed Sep 15 06:25:30 2004 From: john.hearns at clustervision.com (John Hearns) Date: Wed, 15 Sep 2004 07:25:30 +0100 Subject: "Stateless Linux" project In-Reply-To: References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> <20040914202921.GB4100@devserv.devel.redhat.com> <1095195303.4205.5.camel@localhost.localdomain> Message-ID: <1095229530.10739.183.camel@vigor12> On Wed, 2004-09-15 at 02:15, Dan Williams wrote: > So, I can't remeber if anybody mentioned this, but: > > How about using config info stored on a USB keydriver? A relatively > simple GUI app could dump the config information to one/multiple > keydrives which could then be plugged into the machine when it boots up, > and an initial installation program would get values from the keydrive. > Could optionally encrypt the data on the drive since the OS image from the > server would certainly have the keys to decrypt the info on the keydrive. Great idea. Imagine being able to bring your identity/keys/config info on a USB stick to a conference, or a branch office of your company, or hotel room. There are laptops in the conference rooms for you to do a presentation, or public machines for you to work on. Insert the bootable USB stick, it boots a minimal kernel in RAM then sets up a VPM to the Stateless Linux server back in your department/office. Installs to the laptop and you are off. Hopefully the shutdown sequence does a sync back to the server. I blue-skyed the idea of bringing a complete distro on a large USB stick at the UKUUG meeting this year. This is a much better concept. No more lugging laptops about. From skvidal at phy.duke.edu Wed Sep 15 06:40:37 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Sep 2004 02:40:37 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095229530.10739.183.camel@vigor12> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> <20040914202921.GB4100@devserv.devel.redhat.com> <1095195303.4205.5.camel@localhost.localdomain> <1095229530.10739.183.camel@vigor12> Message-ID: <1095230437.23039.36.camel@binkley> > Great idea. > Imagine being able to bring your identity/keys/config info on a USB > stick to a conference, or a branch office of your company, or hotel > room. > There are laptops in the conference rooms for you to do a presentation, > or public machines for you to work on. > Insert the bootable USB stick, it boots a minimal kernel in RAM then > sets up a VPM to the Stateless Linux server back in your > department/office. Installs to the laptop and you are off. > Hopefully the shutdown sequence does a sync back to the server. > > I blue-skyed the idea of bringing a complete distro on a large USB stick > at the UKUUG meeting this year. This is a much better concept. > > No more lugging laptops about. So I don't mean to be a wet blanket but: Most people and many IT groups cannot successfully make a video projector work for presentations. Do we seriously think that something as complex as what is being suggested has a snowball's chance in hell of succeeding. I know this is all pie in the sky but cmon folks, let's bound ourselves a little bit in reality. Moving as much data as we're talking about for a distribution and even remotely having the hope of getting it functioning on whatever goofy hardware some misc location has is as close to delusional as you can get. So why not take a few steps back from the ubiquitous computing, I-take- my-desktop-with-me-wherever-I-go model and try to achieve a few limited goals: 1. fool proof pxe configurations out of the box in the install of the dhcp server or even maybe a pxelinux package! 2. a good syncing file system or backup tool that isn't ridiculously difficult to configure for the average user. 3. a network filesystem that has: - robustness - locking - strong authentication - success in working over high-latency connections - doesn't piss off kernel developers by it's mere existence. and has all of those things, at the same time. Hell, I'd take 4/5. 4. A usb implementation that has a mode other than 'panic and die w/ unhelpful error message' when it encounters a problem. 5. a firewire implementation that doesn't make most kernel developers cringe. What do you think about starting with this list before the flights of fancy and delusions of grandeur are undertaken? I'm sorry if I sound like a curmudgeon but this is just what happens when you hear developers promising the world year after year and the world simply never showing up. -sv From jjengla at sandia.gov Wed Sep 15 06:55:46 2004 From: jjengla at sandia.gov (Josh England) Date: Tue, 14 Sep 2004 23:55:46 -0700 Subject: how about oneSIS? was: "Stateless Linux" project In-Reply-To: <1095210458.4127.143.camel@localhost.localdomain> References: <1095174373.6592.28.camel@localhost> <1095210458.4127.143.camel@localhost.localdomain> Message-ID: <1095231346.7291.50.camel@localhost> On Tue, 2004-09-14 at 18:07, Havoc Pennington wrote: > Anyway, I think it will take us some time to digest how this maps to the > desktop/server case in addition to clusters, and how to fit it together > with the work we have so far. Your thoughts on how to pull it all > together are welcome. Havoc, Thanks for taking a look at oneSIS. I'm certainly willing to discuss how I can help it fit in with your ideas for Stateless Linux. All of the abstractions in oneSIS are at the file level, so I believe it can be used for many diskless-like environments besides clustering. The 'compute/admin/etc' classes in the manual are completely arbitrary but useful class names for a cluster system. I have set up X on diskless nodes before with only minor trickery, and it works just fine. I think a single INCLUDE file could be tailored to provide a working base system capable of starting X, etc, on however many client nodes. What kind of base functionality do you want out of the client nodes? What daemons would run...what kind of roles do you expect...what bits of the root FS should live on a local disk..what should the bootstrap look like? In clustering, it is generally assumed that the whole cluster is on a protected network, so oneSIS doesn't address any security concerns directly, but I would love to hear ideas for how to improve that. -JE From john.hearns at clustervision.com Wed Sep 15 07:01:00 2004 From: john.hearns at clustervision.com (John Hearns) Date: Wed, 15 Sep 2004 08:01:00 +0100 Subject: "Stateless Linux" project In-Reply-To: <1095230437.23039.36.camel@binkley> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> <20040914202921.GB4100@devserv.devel.redhat.com> <1095195303.4205.5.camel@localhost.localdomain> <1095229530.10739.183.camel@vigor12> <1095230437.23039.36.camel@binkley> Message-ID: <1095231659.10739.205.camel@vigor12> On Wed, 2004-09-15 at 07:40, seth vidal wrote: > > Great idea. > > > I'm sorry if I sound like a curmudgeon but this is just what happens > when you hear developers promising the world year after year and the > world simply never showing up. Point(s) taken. I won't argue - you are right. However, I'd just like to flag up the popularity of Knoppix. Who really would have predicted two years ago that it would be common for people to hand out live CDs at public meetings, or engineers take along a Knoppix CD to rescue and diagnose sick systems (I do). At the UKUUG meeting there was a presentation from Sunderland University on preparing custom Knoppix CDs for their staff and students this year. Other places will be doing similar. I fully recognise this is a different scenario. From skvidal at phy.duke.edu Wed Sep 15 07:05:04 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Sep 2004 03:05:04 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095231659.10739.205.camel@vigor12> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> <20040914202921.GB4100@devserv.devel.redhat.com> <1095195303.4205.5.camel@localhost.localdomain> <1095229530.10739.183.camel@vigor12> <1095230437.23039.36.camel@binkley> <1095231659.10739.205.camel@vigor12> Message-ID: <1095231904.23039.41.camel@binkley> On Wed, 2004-09-15 at 08:01 +0100, John Hearns wrote: > On Wed, 2004-09-15 at 07:40, seth vidal wrote: > > > Great idea. > > > > > I'm sorry if I sound like a curmudgeon but this is just what happens > > when you hear developers promising the world year after year and the > > world simply never showing up. > > Point(s) taken. I won't argue - you are right. > > However, I'd just like to flag up the popularity of Knoppix. > Who really would have predicted two years ago that it would be common > for people to hand out live CDs at public meetings, or engineers take > along a Knoppix CD to rescue and diagnose sick systems (I do). > At the UKUUG meeting there was a presentation from Sunderland University > on preparing custom Knoppix CDs for their staff and students this year. > Other places will be doing similar. > I fully recognise this is a different scenario. You are indeed correct. And what would the world be if there wasn't some pie-in-the-sky dreaming. Knoppix is not that different a scenario but I would like to bring up a useful point. Knoppix has to do very similar things as stateless linux will need to do insofar as hardware detection and configuration. how many of us have popped in a knoppix to a new machine only to see it fail spectacularly to figure out what we just inserted it in? I think everyone has. HW detection has a long way to go, not to mention drivers. -sv From john.hearns at clustervision.com Wed Sep 15 07:25:30 2004 From: john.hearns at clustervision.com (John Hearns) Date: Wed, 15 Sep 2004 08:25:30 +0100 Subject: how about oneSIS? was: "Stateless Linux" project In-Reply-To: <1095231346.7291.50.camel@localhost> References: <1095174373.6592.28.camel@localhost> <1095210458.4127.143.camel@localhost.localdomain> <1095231346.7291.50.camel@localhost> Message-ID: <1095233130.10739.215.camel@vigor12> On Wed, 2004-09-15 at 07:55, Josh England wrote: > In clustering, it is generally assumed that the whole cluster is on a > protected network, so oneSIS doesn't address any security concerns > directly, but I would love to hear ideas for how to improve that. Agreed. There are more requests coming from users to have something else than the traditional Beowulf 'master with two interfaces' network architectures. Improvements in security will only help. From pnasrat at redhat.com Wed Sep 15 09:55:12 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 15 Sep 2004 10:55:12 +0100 Subject: Outage Notice In-Reply-To: <1095188237.32569.84.camel@opus.phy.duke.edu> References: <1095188237.32569.84.camel@opus.phy.duke.edu> Message-ID: <1095242112.8372.0.camel@anu.eridu> On Tue, 2004-09-14 at 14:57 -0400, seth vidal wrote: > Hi All, > > The Physics Department of Duke University will have a site-wide power > outage for 8 hours on Friday Sept 17th from 6PM(1800) until 2AM(0200) > Saturday Sept 18th. This affects: That's UTC right ;) Thanks for the heads up. Paul From alan at redhat.com Wed Sep 15 11:45:55 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 15 Sep 2004 07:45:55 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095230437.23039.36.camel@binkley> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> <20040914202921.GB4100@devserv.devel.redhat.com> <1095195303.4205.5.camel@localhost.localdomain> <1095229530.10739.183.camel@vigor12> <1095230437.23039.36.camel@binkley> Message-ID: <20040915114555.GD27854@devserv.devel.redhat.com> On Wed, Sep 15, 2004 at 02:40:37AM -0400, seth vidal wrote: > Most people and many IT groups cannot successfully make a video > projector work for presentations. Do we seriously think that something > as complex as what is being suggested has a snowball's chance in hell of > succeeding. They do seem to be able to insert a CD and run its contents. > 1. fool proof pxe configurations out of the box in the install of the > dhcp server or even maybe a pxelinux package! system-config-netboot or somesuch ? - I've never used it > 2. a good syncing file system or backup tool that isn't ridiculously > difficult to configure for the average user. > 3. a network filesystem that has: > - robustness > - locking > - strong authentication > - success in working over high-latency connections > - doesn't piss off kernel developers by it's mere existence. > and has all of those things, at the same time. Hell, I'd take 4/5. Sfs is as close as I've seen. Alan From dr at cluenet.de Wed Sep 15 12:13:02 2004 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 15 Sep 2004 14:13:02 +0200 Subject: clean up updates/testing In-Reply-To: <604aa7910408060641393c2b69@mail.gmail.com> References: <41134C6D.5070708@bppiac.hu> <604aa7910408060641393c2b69@mail.gmail.com> Message-ID: <20040915121302.GA11299@srv01.cluenet.de> On Fri, Aug 06, 2004 at 09:41:19AM -0400, Jeff Spaleta wrote: > In fact I say keeping them in the trees helps in troubleshooting > situations, where someone > is trying to confirm another persons bug report or problem and needs > to make sure they have the same version installed to do the > comparison. Downgrading a package to confirm a problem/fix while > helping someone troubleshoot is not unheard of. It would be cool to move superceeded updates into some "historic-updates" hierarchy, so mirrors can decide wether to "waste" disk space for those or not. This would still allow one to get older updates, but doesn't put unnecessary burden to people who just want to keep a copy of all current updates. Best regards, Daniel From dr at cluenet.de Wed Sep 15 12:15:43 2004 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 15 Sep 2004 14:15:43 +0200 Subject: RFC: cleaning up updates and updates-testing In-Reply-To: <20040909183417.GB15025@nostromo.devel.redhat.com> References: <20040909183417.GB15025@nostromo.devel.redhat.com> Message-ID: <20040915121543.GB11299@srv01.cluenet.de> On Thu, Sep 09, 2004 at 02:34:18PM -0400, Bill Nottingham wrote: > At the moment, the Fedora updates tree is somewhat out of > hand (look, wow - 27G). > > Does anyone have any specific and concrete objections to > removing older, superceded, updates? Superceded updates should be preserved somehow, but outside of the current updates tree. How to best achieve this for mirroring efficiency I leave up to the guys to comment on who have actual experience with rsync et al. :-) Best regards, Daniel From skvidal at phy.duke.edu Wed Sep 15 13:19:17 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Sep 2004 09:19:17 -0400 Subject: Outage Notice In-Reply-To: <1095242112.8372.0.camel@anu.eridu> References: <1095188237.32569.84.camel@opus.phy.duke.edu> <1095242112.8372.0.camel@anu.eridu> Message-ID: <1095254357.23039.43.camel@binkley> On Wed, 2004-09-15 at 10:55 +0100, Paul Nasrat wrote: > On Tue, 2004-09-14 at 14:57 -0400, seth vidal wrote: > > Hi All, > > > > The Physics Department of Duke University will have a site-wide power > > outage for 8 hours on Friday Sept 17th from 6PM(1800) until 2AM(0200) > > Saturday Sept 18th. This affects: > > That's UTC right ;) No it's EDT -sv From bryan at ayesha.phys.Virginia.EDU Wed Sep 15 14:43:57 2004 From: bryan at ayesha.phys.Virginia.EDU (Bryan K. Wright) Date: Wed, 15 Sep 2004 10:43:57 -0400 Subject: "Stateless Linux" project Message-ID: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> hp at redhat.com said: > Dan Reed has some code written that's a bit simpler approach - it just > rsyncs the homedir periodically. This would work fine, at least for people with small /home directories, and it has the distinct advantage that it can be done right now, without a lot of development. It might be a problem for folks with larger /home directories, though. On my laptop, I have about 20GB of user files (images, maps, data, documents) and it takes a few minutes of disk grinding for rsync just to walk the tree and decide what's changed. This might be prohibitive (or at least prohibitively annoying) for the user. It also cuts into the battery life. Another possible user-space option would be something based on SGI::FAM. Around here, I use a fam-based intrusion-detection system to monitor a few system files that are commonly modified by root kits, and send me a notice when one changes. A similar system could monitor the directories in /home and, whenever a file changes, queue it up for synchronization with a remote mirror. This has the advantage of not needing to walk the whole file tree repeatedly, as you'd need to do with rsync. I suspect that you might run into problems with the number of file descriptors or memory use for large /home directories, though. When I get a chance, I'll whip up a script and try it out on my laptop. Moving out of user space, and requiring some of development, you could have the kernel's VFS layer generate a notice, maybe via DBUS, whenever a file changes. It'd be nice to be able to turn this on only for selected filesystems: monitor /home, but don't bother with /var, for example. A client would watch for changes and queue up files for synchronization. Back to my original suggestion of a "RAID 1" mirror composed of a local disk and a network block device: It seems like you'd need to make the RAID system smart enough to realize that one device has much bigger latencies than the other, otherwise you'd get performance problems. You'd want to preferentially read from the local disk, for example, and you'd want to queue up writes to the remote disk instead of waiting for them to complete synchronously. I don't know if the current software RAID implementation supports this sort of thing. Ideas are easy. Coding's hard. Thanks again for pulling together a lot of disconnected useful ideas into "stateless linux" and starting to instantiate them in code. Bryan -- =============================================================================== Bryan Wright |"If you take cranberries and stew them like Physics Department | applesauce, they taste much more like prunes University of Virginia | than rhubarb does." -- Groucho Charlottesville, VA 22901 | (434) 924-7218 | bryan at virginia.edu =============================================================================== From jon.nettleton at gmail.com Wed Sep 15 15:02:29 2004 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 15 Sep 2004 11:02:29 -0400 Subject: Wireless update to ifup and network-functions Message-ID: If have put together a function and some new code for is_wireless_device that uses iwlist to scan available access points and then ifup a new configuration file if it finds one matching ifcfg-DEVICE_ESSID. My questions are. 1) Is this the correct list? 2) Is this something that maintainers are interested in adding? 3) What is prefered format for patches? Hope to help out making Fedora Core 3 the best it can be. -Jon From laroche at redhat.com Wed Sep 15 15:11:28 2004 From: laroche at redhat.com (Florian La Roche) Date: Wed, 15 Sep 2004 17:11:28 +0200 Subject: Wireless update to ifup and network-functions In-Reply-To: References: Message-ID: <20040915151128.GA7468@dudweiler.stuttgart.redhat.com> On Wed, Sep 15, 2004 at 11:02:29AM -0400, Jon Nettleton wrote: > If have put together a function and some new code for > is_wireless_device that uses iwlist to scan available access points > and then ifup a new configuration file if it finds one matching > ifcfg-DEVICE_ESSID. My questions are. > > 1) Is this the correct list? > 2) Is this something that maintainers are interested in adding? > 3) What is prefered format for patches? All bugreports and patches should also go into http://bugzilla.redhat.com/bugzilla/ The mailinglist often helps discussions, but bugzilla is helping to track patches and bug-reports. greetings, Florian La Roche From nutello at sweetness.com Wed Sep 15 15:13:25 2004 From: nutello at sweetness.com (Rudi Chiarito) Date: Wed, 15 Sep 2004 17:13:25 +0200 Subject: "Stateless Linux" project In-Reply-To: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> Message-ID: <20040915151325.GU14918@server4.8080.it> On Wed, Sep 15, 2004 at 10:43:57AM -0400, Bryan K. Wright wrote: > directories, though. On my laptop, I have about 20GB of user files > (images, maps, data, documents) and it takes a few minutes of disk > grinding for rsync just to walk the tree and decide what's changed. > This might be prohibitive (or at least prohibitively annoying) for the > user. It also cuts into the battery life. Another problem to worry about is saturation of the link upstream. I'm sure the average user wouldn't want the browser choked by rsync. Yes, you can tell rsync to use at most N KB/s, but that's not always easy to get right, if the user is in the position to estimate it at all - not to mention that link speed might change at any time for e.g. mobile users. And you run into the risk of the opposite scenario: you are forcing rsync to use only a fraction of the bandwidth, when there's nothing else using the rest. Or do we just assume that there's going to be enough bandwidth? A saturated DSL is likely to be still more responsive than a saturated 56k connection. -- Rudi From otaylor at redhat.com Wed Sep 15 16:09:28 2004 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 15 Sep 2004 12:09:28 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <20040915151325.GU14918@server4.8080.it> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> Message-ID: <1095264568.5860.29.camel@localhost.localdomain> On Wed, 2004-09-15 at 11:13, Rudi Chiarito wrote: > On Wed, Sep 15, 2004 at 10:43:57AM -0400, Bryan K. Wright wrote: > > directories, though. On my laptop, I have about 20GB of user files > > (images, maps, data, documents) and it takes a few minutes of disk > > grinding for rsync just to walk the tree and decide what's changed. > > This might be prohibitive (or at least prohibitively annoying) for the > > user. It also cuts into the battery life. > > Another problem to worry about is saturation of the link upstream. I'm > sure the average user wouldn't want the browser choked by rsync. Yes, > you can tell rsync to use at most N KB/s, but that's not always easy to > get right, if the user is in the position to estimate it at all - not to > mention that link speed might change at any time for e.g. mobile users. > And you run into the risk of the opposite scenario: you are forcing > rsync to use only a fraction of the bandwidth, when there's nothing else > using the rest. > > Or do we just assume that there's going to be enough bandwidth? A > saturated DSL is likely to be still more responsive than a saturated 56k > connection. Well, a bigger problem with rsync is that in many cases, the listing files part is the biggest time sync. And if that gets interrupted, you start from the beginning. (*) So, starting a backup via wireless/vpn when you open your laptop for 5 minutes at the coffee shop doesn't usually make sense. So, you might want to look at it as "backup only when on these networks". I think it's pretty reasonable to assume that people have lots of bandwidth at home and at work these days. Regards, Owen (*) This may actually not be the case for most people's home directories; they probably don't have source trees, maildir folders, etc, so perhaps 200 files is more typical than the 50,000 you might find in a hacker's homedir. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From grmoc at yahoo.com Wed Sep 15 16:41:57 2004 From: grmoc at yahoo.com (Roberto Peon) Date: Wed, 15 Sep 2004 12:41:57 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095231904.23039.41.camel@binkley> References: <1095100955.5481.14.camel@localhost.localdomain> <1095231659.10739.205.camel@vigor12> <1095231904.23039.41.camel@binkley> Message-ID: <200409151241.57376.grmoc@yahoo.com> On Wednesday 15 September 2004 03:05 am, seth vidal wrote: > On Wed, 2004-09-15 at 08:01 +0100, John Hearns wrote: > > On Wed, 2004-09-15 at 07:40, seth vidal wrote: > > > > Great idea. > > > > > > I'm sorry if I sound like a curmudgeon but this is just what happens > > > when you hear developers promising the world year after year and the > > > world simply never showing up. > > > > Point(s) taken. I won't argue - you are right. > > > > However, I'd just like to flag up the popularity of Knoppix. > > Who really would have predicted two years ago that it would be common > > for people to hand out live CDs at public meetings, or engineers take > > along a Knoppix CD to rescue and diagnose sick systems (I do). > > At the UKUUG meeting there was a presentation from Sunderland University > > on preparing custom Knoppix CDs for their staff and students this year. > > Other places will be doing similar. > > I fully recognise this is a different scenario. > > You are indeed correct. And what would the world be if there wasn't some > pie-in-the-sky dreaming. Knoppix is not that different a scenario but I > would like to bring up a useful point. Knoppix has to do very similar > things as stateless linux will need to do insofar as hardware detection > and configuration. > > how many of us have popped in a knoppix to a new machine only to see it > fail spectacularly to figure out what we just inserted it in? I think > everyone has. HW detection has a long way to go, not to mention drivers. > > -sv And Knoppix uses Kudzu. In response to Rudi: >Another problem to worry about is saturation of the link upstream. I'm >sure the average user wouldn't want the browser choked by rsync. Yes, >you can tell rsync to use at most N KB/s, but that's not always easy to >get right, if the user is in the position to estimate it at all - not to >mention that link speed might change at any time for e.g. mobile users. >And you run into the risk of the opposite scenario: you are forcing >rsync to use only a fraction of the bandwidth, when there's nothing else >using the rest. Well, we could setup a bandwidth sharing policy by default, like the SFQ, I'd imagine that should do a decent job of managing the bandwidth between what the client is doing and the background rsync (or equivalent). -R From skvidal at phy.duke.edu Wed Sep 15 16:54:34 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Sep 2004 12:54:34 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095264568.5860.29.camel@localhost.localdomain> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> Message-ID: <1095267273.9073.6.camel@opus.phy.duke.edu> > So, you might want to look at it as "backup only when on these > networks". I think it's pretty reasonable to assume that people > have lots of bandwidth at home and at work these days. > I think this is a pretty safe assumption In the United States and some portions of the western world, but not a good assumption in a lot of other places. -sv From alan at redhat.com Wed Sep 15 16:59:12 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 15 Sep 2004 12:59:12 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095267273.9073.6.camel@opus.phy.duke.edu> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267273.9073.6.camel@opus.phy.duke.edu> Message-ID: <20040915165912.GA23359@devserv.devel.redhat.com> On Wed, Sep 15, 2004 at 12:54:34PM -0400, seth vidal wrote: > I think this is a pretty safe assumption In the United States and some > portions of the western world, but not a good assumption in a lot of > other places. I disagree even with that. There are a lot of networks that have volume charges and you don't want to mistake them for the users home lan. OTOH if you've got the kind of autoconfiguration that can find the backup service and see if it is the right one for this user you can get the right results. Alan From dcbw at redhat.com Wed Sep 15 17:06:26 2004 From: dcbw at redhat.com (Dan Williams) Date: Wed, 15 Sep 2004 13:06:26 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095264568.5860.29.camel@localhost.localdomain> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> Message-ID: <1095267986.30358.33.camel@dcbw.boston.redhat.com> On Wed, 2004-09-15 at 12:09 -0400, Owen Taylor wrote: > So, you might want to look at it as "backup only when on these > networks". I think it's pretty reasonable to assume that people > have lots of bandwidth at home and at work these days. Which presents the question, is there any attributes that NetworkManager can expose about the network that would help this? Time connected so far attribute (though that wouldn't really tell you anything about what the user might do 5 seconds from now when they pull the plug and walk out of the coffee shop)? NetworkManager doesn't have a concept of profiles, since that was a specific exclusion from the beginning (profiles suck). I'm not quite sure how to go about a "backup only when on these networks", except perhaps for these two ideas: 1) on wired networks, use your hostname as returned via DHCP, match that against a "home network" sort of thing. But remember, NetworkManager keeps the hostname of the actual machine constant (because otherwise X falls over and dies), so NM would save the hostname right before setting it back and expose that via DBus 2) On wireless networks, we could key off of the ESSID of the base station to figure out whether you were on a "home" network or not. 3) other, more complicated ways? Dan From alan at redhat.com Wed Sep 15 17:08:23 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 15 Sep 2004 13:08:23 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095267986.30358.33.camel@dcbw.boston.redhat.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> Message-ID: <20040915170823.GA27765@devserv.devel.redhat.com> On Wed, Sep 15, 2004 at 01:06:26PM -0400, Dan Williams wrote: > 1) on wired networks, use your hostname as returned via DHCP, match that > against a "home network" sort of thing. But remember, NetworkManager MAC address of router is another good hint From skvidal at phy.duke.edu Wed Sep 15 17:07:51 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Sep 2004 13:07:51 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095267986.30358.33.camel@dcbw.boston.redhat.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> Message-ID: <1095268071.9073.8.camel@opus.phy.duke.edu> > 2) On wireless networks, we could key off of the ESSID of the base > station to figure out whether you were on a "home" network or not. umm - something like 90% of all NetGear WAPS are 'netgear' as the ESSID. I think that might be unsafe to key off of. :) -sv From grmoc at yahoo.com Wed Sep 15 17:10:32 2004 From: grmoc at yahoo.com (Roberto Peon) Date: Wed, 15 Sep 2004 13:10:32 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095268071.9073.8.camel@opus.phy.duke.edu> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095268071.9073.8.camel@opus.phy.duke.edu> Message-ID: <200409151310.32520.grmoc@yahoo.com> I'd imagine that MAC addresses were more likely to work, given the whole 'designed uniqueness' thing. -R On Wednesday 15 September 2004 01:07 pm, seth vidal wrote: > > 2) On wireless networks, we could key off of the ESSID of the base > > station to figure out whether you were on a "home" network or not. > > umm - something like 90% of all NetGear WAPS are 'netgear' as the ESSID. > > I think that might be unsafe to key off of. :) > > -sv From dcbw at redhat.com Wed Sep 15 17:12:46 2004 From: dcbw at redhat.com (Dan Williams) Date: Wed, 15 Sep 2004 13:12:46 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <20040915170823.GA27765@devserv.devel.redhat.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <20040915170823.GA27765@devserv.devel.redhat.com> Message-ID: <1095268366.30358.35.camel@dcbw.boston.redhat.com> On Wed, 2004-09-15 at 13:08 -0400, Alan Cox wrote: > On Wed, Sep 15, 2004 at 01:06:26PM -0400, Dan Williams wrote: > > 1) on wired networks, use your hostname as returned via DHCP, match that > > against a "home network" sort of thing. But remember, NetworkManager > > MAC address of router is another good hint If that's the case, then NetworkManager doesn't need to do anything :) Dan From skvidal at phy.duke.edu Wed Sep 15 17:13:07 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Sep 2004 13:13:07 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <200409151310.32520.grmoc@yahoo.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095268071.9073.8.camel@opus.phy.duke.edu> <200409151310.32520.grmoc@yahoo.com> Message-ID: <1095268387.9073.15.camel@opus.phy.duke.edu> On Wed, 2004-09-15 at 13:10, Roberto Peon wrote: > I'd imagine that MAC addresses were more likely to work, given the whole > 'designed uniqueness' thing. you mean 'theoretical uniqueness' There are MAC duplicates out there. Trust me. :) -sv From otaylor at redhat.com Wed Sep 15 17:13:44 2004 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 15 Sep 2004 13:13:44 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095267273.9073.6.camel@opus.phy.duke.edu> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267273.9073.6.camel@opus.phy.duke.edu> Message-ID: <1095268424.5860.34.camel@localhost.localdomain> On Wed, 2004-09-15 at 12:54, seth vidal wrote: > > So, you might want to look at it as "backup only when on these > > networks". I think it's pretty reasonable to assume that people > > have lots of bandwidth at home and at work these days. > > > > I think this is a pretty safe assumption In the United States and some > portions of the western world, but not a good assumption in a lot of > other places. The question in my mind is: If you never have a high bandwidth connection to the backup server, does the automatic homedir backup concept make sense? Maybe it does, but it's certainly more of a challenge to make it work well in such circumstances, so I'd think of that as something to be looked at later, rather than a primary use case. Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Wed Sep 15 17:20:54 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Sep 2004 13:20:54 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095268424.5860.34.camel@localhost.localdomain> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267273.9073.6.camel@opus.phy.duke.edu> <1095268424.5860.34.camel@localhost.localdomain> Message-ID: <1095268854.9073.20.camel@opus.phy.duke.edu> > The question in my mind is: > > If you never have a high bandwidth connection to the backup server, > does the automatic homedir backup concept make sense? > > Maybe it does, but it's certainly more of a challenge to make it work > well in such circumstances, so I'd think of that as something to > be looked at later, rather than a primary use case. > The question in my mind is: is an automatic homedir backup concept attainable? I think the word we're going to keep running into trouble on is 'automatic'. We've got to get the user to leave it the hell alone for long enough to get the data and you're going to need to tell the user how long that will be in some sort of progress bar or notification. I think a good place to start would be a user-enabled homedir backup utility. Something graphical, simple but reasonably configurable (exclusion lists, inclusion lists, etc). Then move on from there on how to invoke it automatically. But we're not really anywhere close to the latter afaict. -sv From michael at insitesinc.com Wed Sep 15 17:22:29 2004 From: michael at insitesinc.com (Michael Favia) Date: Wed, 15 Sep 2004 12:22:29 -0500 Subject: "Stateless Linux" project In-Reply-To: <20040915151325.GU14918@server4.8080.it> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> Message-ID: <41487A55.3040809@insitesinc.com> Rudi Chiarito wrote: >Another problem to worry about is saturation of the link upstream. I'm >sure the average user wouldn't want the browser choked by rsync. Yes, >you can tell rsync to use at most N KB/s, but that's not always easy to >get right, if the user is in the position to estimate it at all - not to >mention that link speed might change at any time for e.g. mobile users. > > > I've always wondered why applications are so greedy individually. Is there no mechanism to throttle requested bandwidth between apps? I often run into instances when a bit torrent uplink is saturating my uplink and crippling my web browsing capabilities because i dont even have enough space to send requests (id imagine thats the cause any way). Obviously i could manually divide my bandwidth but it often changes (laptop and on cable modem with variable up/down at home, bottomless connection speeds at work). Is the overhead of such a monitoring system too high for the benefit? Has it been attempted? There seem to be so many advantages to such a system with the increasing popularity of higbandwidth activities and the general user (Bittorrent, video on demand, aMule, Music services) It just seems like a self auditing network interface would make sense here. -- Michael Favia michael at insitesinc dot com Insites Incorporated http://michael.insitesinc.com From skvidal at phy.duke.edu Wed Sep 15 17:22:23 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Sep 2004 13:22:23 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095268854.9073.20.camel@opus.phy.duke.edu> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267273.9073.6.camel@opus.phy.duke.edu> <1095268424.5860.34.camel@localhost.localdomain> <1095268854.9073.20.camel@opus.phy.duke.edu> Message-ID: <1095268943.9073.22.camel@opus.phy.duke.edu> > The question in my mind is: is an automatic homedir backup concept > attainable? > > I think the word we're going to keep running into trouble on is > 'automatic'. We've got to get the user to leave it the hell alone for > long enough to get the data and you're going to need to tell the user > how long that will be in some sort of progress bar or notification. > > I think a good place to start would be a user-enabled homedir backup > utility. Something graphical, simple but reasonably configurable > (exclusion lists, inclusion lists, etc). Then move on from there on how > to invoke it automatically. > > But we're not really anywhere close to the latter afaict. I could definitely see a good place to start is to make the backup software nagware. It tracks the lack backup date and throbs like the rhn-applet until the user runs its until completion. -sv From bryan at ayesha.phys.Virginia.EDU Wed Sep 15 17:24:51 2004 From: bryan at ayesha.phys.Virginia.EDU (Bryan K. Wright) Date: Wed, 15 Sep 2004 13:24:51 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) Message-ID: <200409151724.i8FHOpv11425@ayesha.phys.Virginia.EDU> otaylor at redhat.com said: > The question in my mind is: > If you never have a high bandwidth connection to the backup server, > does the automatic homedir backup concept make sense? It may make sense with something like rsync, using its --partial and --compare-dest options. See the following from the rsync documentation: --compare-dest=DIR This option instructs rsync to use DIR on the des? tination machine as an additional directory to com? pare destination files against when doing transfers if the files are missing in the destination direc? tory. This is useful for doing transfers to a new destination while leaving existing files intact, and then doing a flash-cutover when all files have been successfully transferred (for example by mov? ing directories around and removing the old direc? tory, although this skips files that haven?t changed; see also --link-dest). This option increases the usefulness of --partial because par? tially transferred files will remain in the new temporary destination until they have a chance to be completed. If DIR is a relative path, it is relative to the destination directory. You could use these features to synchronize files as much as possible (even partial file transfers) over a slow link, without damaging the "last known good" version. When a complete, newer version has been trasferred, it can be dropped in place of the previous "known good" version. Bryan -- =============================================================================== Bryan Wright |"If you take cranberries and stew them like Physics Department | applesauce, they taste much more like prunes University of Virginia | than rhubarb does." -- Groucho Charlottesville, VA 22901 | (434) 924-7218 | bryan at virginia.edu =============================================================================== From grmoc at yahoo.com Wed Sep 15 17:28:13 2004 From: grmoc at yahoo.com (Roberto Peon) Date: Wed, 15 Sep 2004 13:28:13 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095268387.9073.15.camel@opus.phy.duke.edu> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <200409151310.32520.grmoc@yahoo.com> <1095268387.9073.15.camel@opus.phy.duke.edu> Message-ID: <200409151328.13716.grmoc@yahoo.com> Well, design is often theoretical, yes. =) -R On Wednesday 15 September 2004 01:13 pm, seth vidal wrote: > On Wed, 2004-09-15 at 13:10, Roberto Peon wrote: > > I'd imagine that MAC addresses were more likely to work, given the whole > > 'designed uniqueness' thing. > > you mean 'theoretical uniqueness' > > There are MAC duplicates out there. Trust me. :) > > -sv From dhollis at davehollis.com Wed Sep 15 17:35:02 2004 From: dhollis at davehollis.com (David Hollis) Date: Wed, 15 Sep 2004 13:35:02 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095268366.30358.35.camel@dcbw.boston.redhat.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <20040915170823.GA27765@devserv.devel.redhat.com> <1095268366.30358.35.camel@dcbw.boston.redhat.com> Message-ID: <1095269703.6499.9.camel@dhollis-lnx.kpmg.com> On Wed, 2004-09-15 at 13:12 -0400, Dan Williams wrote: > On Wed, 2004-09-15 at 13:08 -0400, Alan Cox wrote: > > On Wed, Sep 15, 2004 at 01:06:26PM -0400, Dan Williams wrote: > > > 1) on wired networks, use your hostname as returned via DHCP, match that > > > against a "home network" sort of thing. But remember, NetworkManager > > > > MAC address of router is another good hint > > If that's the case, then NetworkManager doesn't need to do anything :) > > Dan > Though router mac is certainly subject to change. I could by on my company network but on a different segment and have a different gateway mac. Or when the network guys finally decide to ditch that old Wellfleet router and put in something from this century.... And what about VPN connectivity? If I have a VPN open, I'm cool with it synching files across that - though there still is the bandwidth congestion issue of course. I often go months at a time before I'm back in the office and that's a long time to not have things backed up. I think the test/validation/whatever-you-want-to-call-it may need to be more of a "can I access X location" type of test. It could be as simple as a ping or something slightly more substantial as a TCP connection. You can also get some crude metrics of latency that may be useful to tune how much/how fast the sync will go. -- David Hollis From jjengla at sandia.gov Wed Sep 15 17:35:21 2004 From: jjengla at sandia.gov (Josh England) Date: Wed, 15 Sep 2004 10:35:21 -0700 Subject: "Stateless Linux" project In-Reply-To: <41487A55.3040809@insitesinc.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <41487A55.3040809@insitesinc.com> Message-ID: <1095269721.16966.40.camel@localhost> On Wed, 2004-09-15 at 10:22, Michael Favia wrote: > Is > there no mechanism to throttle requested bandwidth between apps? Take a look at ebtables and the network QOS in 2.6. A friend of mine has set up a small router whose sole purpose in life is to limit BitTorrent traffic so that his ssh sessions aren't painfully slow. He says it works great. -JE From dhollis at davehollis.com Wed Sep 15 17:38:12 2004 From: dhollis at davehollis.com (David Hollis) Date: Wed, 15 Sep 2004 13:38:12 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095268854.9073.20.camel@opus.phy.duke.edu> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267273.9073.6.camel@opus.phy.duke.edu> <1095268424.5860.34.camel@localhost.localdomain> <1095268854.9073.20.camel@opus.phy.duke.edu> Message-ID: <1095269892.6499.12.camel@dhollis-lnx.kpmg.com> On Wed, 2004-09-15 at 13:20 -0400, seth vidal wrote: > I think the word we're going to keep running into trouble on is > 'automatic'. We've got to get the user to leave it the hell alone for > long enough to get the data and you're going to need to tell the user > how long that will be in some sort of progress bar or notification. > > I think a good place to start would be a user-enabled homedir backup > utility. Something graphical, simple but reasonably configurable > (exclusion lists, inclusion lists, etc). Then move on from there on how > to invoke it automatically. > > But we're not really anywhere close to the latter afaict. > I definitely agree here. It can't be an all-or-nothing proposition. And there has to be provisions to exclude certain directories (if I exclude my ~/rpm heirarchy, I cut out quite a few gigs right there). And the ability to 'pause' the sync for those cases where the user knows they aren't going to be up long and/or really need the pipe so they can get that critical file for their boss. -- David Hollis From grmoc at yahoo.com Wed Sep 15 17:40:34 2004 From: grmoc at yahoo.com (Roberto Peon) Date: Wed, 15 Sep 2004 13:40:34 -0400 Subject: "Stateless Linux" project In-Reply-To: <41487A55.3040809@insitesinc.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <41487A55.3040809@insitesinc.com> Message-ID: <200409151340.34369.grmoc@yahoo.com> Yes, use the SFQ or another fair scheduler for the network stuff. -R On Wednesday 15 September 2004 01:22 pm, Michael Favia wrote: > Rudi Chiarito wrote: > >Another problem to worry about is saturation of the link upstream. I'm > >sure the average user wouldn't want the browser choked by rsync. Yes, > >you can tell rsync to use at most N KB/s, but that's not always easy to > >get right, if the user is in the position to estimate it at all - not to > >mention that link speed might change at any time for e.g. mobile users. > > I've always wondered why applications are so greedy individually. Is > there no mechanism to throttle requested bandwidth between apps? I often > run into instances when a bit torrent uplink is saturating my uplink and > crippling my web browsing capabilities because i dont even have enough > space to send requests (id imagine thats the cause any way). Obviously i > could manually divide my bandwidth but it often changes (laptop and on > cable modem with variable up/down at home, bottomless connection speeds > at work). Is the overhead of such a monitoring system too high for the > benefit? Has it been attempted? There seem to be so many advantages to > such a system with the increasing popularity of higbandwidth activities > and the general user (Bittorrent, video on demand, aMule, Music > services) It just seems like a self auditing network interface would > make sense here. > > -- > Michael Favia michael at insitesinc dot com > Insites Incorporated http://michael.insitesinc.com From otaylor at redhat.com Wed Sep 15 17:39:53 2004 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 15 Sep 2004 13:39:53 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095267986.30358.33.camel@dcbw.boston.redhat.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> Message-ID: <1095269993.5860.48.camel@localhost.localdomain> On Wed, 2004-09-15 at 13:06, Dan Williams wrote: > On Wed, 2004-09-15 at 12:09 -0400, Owen Taylor wrote: > > So, you might want to look at it as "backup only when on these > > networks". I think it's pretty reasonable to assume that people > > have lots of bandwidth at home and at work these days. > > Which presents the question, is there any attributes that NetworkManager > can expose about the network that would help this? Time connected so > far attribute (though that wouldn't really tell you anything about what > the user might do 5 seconds from now when they pull the plug and walk > out of the coffee shop)? > > NetworkManager doesn't have a concept of profiles, since that was a > specific exclusion from the beginning (profiles suck). I'm not quite > sure how to go about a "backup only when on these networks", except > perhaps for these two ideas: I don't have a good answer to this, but I do think the concept of a "network" corresponds to a fairly definite idea in the user's head, so it at least potentially something that we can expose in the user interface. And "Do A only on network B" may be something we need more of in the future. > 1) on wired networks, use your hostname as returned via DHCP, match that > against a "home network" sort of thing. But remember, NetworkManager > keeps the hostname of the actual machine constant (because otherwise X > falls over and dies), so NM would save the hostname right before setting > it back and expose that via DBus The hostname that dhcp returns should be the same as a reverse DNS lookup on the network address, right? > 2) On wireless networks, we could key off of the ESSID of the base > station to figure out whether you were on a "home" network or not. > > 3) other, more complicated ways? The best idea that comes to my mind is: - Use a restrictive criterion like MAC address of the router that seldom gives false positives for "am on the same network" - Then have a "bookmark this network" function to give a name to the current network; if the hardware changes or some such, then the user will have to rebookmark the network, which is a little annoying, but managable. We could also try to establish a "Fedora" way to authoritatively identify and name networks so that network administrators who cared could do better. (Extra bit of information from DHCP, extra DNS records, whatever.) Generally, networks probably correspond pretty closely to domains for sufficiently well administered networks... e.g., my current network is "boston.redhat.com", but I don't think you want to rely on that congruence. Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michael at insitesinc.com Wed Sep 15 17:42:47 2004 From: michael at insitesinc.com (Michael Favia) Date: Wed, 15 Sep 2004 12:42:47 -0500 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095268387.9073.15.camel@opus.phy.duke.edu> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095268071.9073.8.camel@opus.phy.duke.edu> <200409151310.32520.grmoc@yahoo.com> <1095268387.9073.15.camel@opus.phy.duke.edu> Message-ID: <41487F17.9060705@insitesinc.com> seth vidal wrote: >you mean 'theoretical uniqueness' > >There are MAC duplicates out there. Trust me. :) > >-sv > > We bet a lot of things on theoretical uniqueness in computing. Short of spoofing and freakish occurances im personally willing to bet my "home" on the uniqueness of a mac address. -- Michael Favia michael at insitesinc dot com Insites Incorporated http://michael.insitesinc.com From carwyn at carwyn.com Wed Sep 15 17:48:38 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Wed, 15 Sep 2004 18:48:38 +0100 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <41487F17.9060705@insitesinc.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095268071.9073.8.camel@opus.phy.duke.edu> <200409151310.32520.grmoc@yahoo.com> <1095268387.9073.15.camel@opus.phy.duke.edu> <41487F17.9060705@insitesinc.com> Message-ID: <41488076.2080401@carwyn.com> Michael Favia wrote: > We bet a lot of things on theoretical uniqueness in computing. Short > of spoofing and freakish occurances im personally willing to bet my > "home" on the uniqueness of a mac address. Really? Even though there is hardware out there that lets the user manually assign the MAC and that there are routers out there that "spoof" MACs for use with broadband ISP access controls? Carwyn From jspaleta at gmail.com Wed Sep 15 17:52:16 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 15 Sep 2004 13:52:16 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095268943.9073.22.camel@opus.phy.duke.edu> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267273.9073.6.camel@opus.phy.duke.edu> <1095268424.5860.34.camel@localhost.localdomain> <1095268854.9073.20.camel@opus.phy.duke.edu> <1095268943.9073.22.camel@opus.phy.duke.edu> Message-ID: <604aa791040915105295c6ac0@mail.gmail.com> On Wed, 15 Sep 2004 13:22:23 -0400, seth vidal wrote: > I could definitely see a good place to start is to make the backup > software nagware. It tracks the lack backup date and throbs like the > rhn-applet until the user runs its until completion. Gee... wouldn't inclusion of rdiff-backup and associated python gui-goodness built on top of it make some sense as a way to flush out some of these /home directory backup issues without layering on the extra complexity of "automatic" "network-aware"? If whatever the stateless solution to backing up and restoring a /home directory actually is... if it can't also be used as a backup and restore for user or admin initiated backups that solution seems too fragile and special purposed to me. Lets cut back on the complexity of autonegotation and just look at the logistics of actually moving syncing the bits over a network and see if this is even plausible, unless your going to demand laptop users not do silly things like dump whole movies onto their disks to watch when they travel. If we can't do user initiated backups with ease..where the user is aware that backup is going on..and is aware of the amount of data and time invovled to complete...we aren't going to come close to being able to doing this when the user is not aware of whats going on. I for one pledge to beat the crap out of any drop-dead easy system-config* styled interface for doing simple "user or admin initiated" home directory backups to disk or to a remote server that shows up in Core. A little applet or notification nagware to inform me of a running backup if initiated by 'me the user' or 'me the admin' and to tell me when the last backup wouldn't be an unwelcomed addition. -jef"preaching to the choir, hoping other people are watching and get the point"spaleta From grmoc at yahoo.com Wed Sep 15 17:55:23 2004 From: grmoc at yahoo.com (Roberto Peon) Date: Wed, 15 Sep 2004 13:55:23 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <41488076.2080401@carwyn.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <41487F17.9060705@insitesinc.com> <41488076.2080401@carwyn.com> Message-ID: <200409151355.23788.grmoc@yahoo.com> Well, the only way I see of uniquely and securely determining if this is the network you want is not an easy problem-- it would require changes in a lot of routing infrastructure... In any case, I can't think of another ID -likely- to be unique on the network. -R On Wednesday 15 September 2004 01:48 pm, Carwyn Edwards wrote: > Michael Favia wrote: > > We bet a lot of things on theoretical uniqueness in computing. Short > > of spoofing and freakish occurances im personally willing to bet my > > "home" on the uniqueness of a mac address. > > Really? Even though there is hardware out there that lets the user > manually assign the MAC and that there are routers out there that > "spoof" MACs for use with broadband ISP access controls? > > Carwyn From michael at insitesinc.com Wed Sep 15 18:04:23 2004 From: michael at insitesinc.com (Michael Favia) Date: Wed, 15 Sep 2004 13:04:23 -0500 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <41488076.2080401@carwyn.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095268071.9073.8.camel@opus.phy.duke.edu> <200409151310.32520.grmoc@yahoo.com> <1095268387.9073.15.camel@opus.phy.duke.edu> <41487F17.9060705@insitesinc.com> <41488076.2080401@carwyn.com> Message-ID: <41488427.10401@insitesinc.com> Carwyn Edwards wrote: > Michael Favia wrote: > >> Short of spoofing > > Really? Even though there is hardware out there that lets the user > manually assign the MAC and that there are routers out there that > "spoof" MACs for use with broadband ISP access controls? > Yes that is why i said short of spoofing. In fact, most comercial routers (Netgear, Cisco, Linksys) and OS's (Windows, linux, mac surely but uncertian?) allow you to spoof your MAC addres these days. The ability to do so is crucial to the redundancy of the internet. However, Consider this: If the MAC address is spoofed *and* it happens to be spoofed with the same 6 byte address as another MAC address you have recorded in your preferences/syncing file there is most likely some sort of relationship present. This is the reason for spoofing (Backup router, etc). I'm not saying this is entirely certian by any means safe but that with my limited understanding i am willing to accept the risks and i believe a resonable person might agree. That after all is the real question. -- Michael Favia michael at insitesinc dot com Insites Incorporated http://michael.insitesinc.com From carwyn at carwyn.com Wed Sep 15 18:15:12 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Wed, 15 Sep 2004 19:15:12 +0100 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095269993.5860.48.camel@localhost.localdomain> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095269993.5860.48.camel@localhost.localdomain> Message-ID: <414886B0.80504@carwyn.com> Stuff about identifying which network we are on to see if we want to do backup. If I'm away at a conference with my laptop and they have WiFi access to the internet, I don't care which network I am on. I still want to back up my home directory though. If I'm working in a multi site corporation that has multiple backup servers (one per site perhaps). I want to use the local backup server not the one back home that's through a thin pipe. I'd want my laptop to discover the local backup server and authenticate it to me and me to it. Ok these ideas don't quite work with the diskless Stateless model but they are still valid when talking about homedir backup. Carwyn From dhollis at davehollis.com Wed Sep 15 18:39:46 2004 From: dhollis at davehollis.com (David Hollis) Date: Wed, 15 Sep 2004 14:39:46 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <41488427.10401@insitesinc.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095268071.9073.8.camel@opus.phy.duke.edu> <200409151310.32520.grmoc@yahoo.com> <1095268387.9073.15.camel@opus.phy.duke.edu> <41487F17.9060705@insitesinc.com> <41488076.2080401@carwyn.com> <41488427.10401@insitesinc.com> Message-ID: <1095273587.6499.18.camel@dhollis-lnx.kpmg.com> On Wed, 2004-09-15 at 13:04 -0500, Michael Favia wrote: > > > Yes that is why i said short of spoofing. In fact, most comercial > routers (Netgear, Cisco, Linksys) and OS's (Windows, linux, mac surely > but uncertian?) allow you to spoof your MAC addres these days. The > ability to do so is crucial to the redundancy of the internet. However, > Consider this: If the MAC address is spoofed *and* it happens to be > spoofed with the same 6 byte address as another MAC address you have > recorded in your preferences/syncing file there is most likely some sort > of relationship present. This is the reason for spoofing (Backup router, > etc). I'm not saying this is entirely certian by any means safe but that > with my limited understanding i am willing to accept the risks and i > believe a resonable person might agree. That after all is the real question. > I think trying to determine location via Layer 2 means is going to be a big mistake. Networks tend to be very amorphous these days and node location is very non-physical. The workstation should not care at all WHERE it is, it's more of a question of "can I get to where I need to?" If contact can be made to the "home directory backup server", it is able to sync. Based on factors such as bandwidth and the like, it may be more or less aggressive in it's backup, but will still be able to attempt it. Many companies have people that may never connect to the local physical network, rather they work from home, client site, starbucks, neighbors wireless hookup, etc. MAC address should play no part in this. Do you really want all of the client systems to stop backing up because you had to change an interface card in the router? Do you want to have to keep the same MAC address on that route forever so that you don't have to change every client in the org that may connect on that subnet? Didn't think so. -- David Hollis From dhollis at davehollis.com Wed Sep 15 18:43:44 2004 From: dhollis at davehollis.com (David Hollis) Date: Wed, 15 Sep 2004 14:43:44 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <414886B0.80504@carwyn.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095269993.5860.48.camel@localhost.localdomain> <414886B0.80504@carwyn.com> Message-ID: <1095273824.29577.2.camel@dhollis-lnx.kpmg.com> On Wed, 2004-09-15 at 19:15 +0100, Carwyn Edwards wrote: > Stuff about identifying which network we are on to see if we > want to do backup. > > If I'm away at a conference with my laptop and they have WiFi access to > the internet, I don't care which network I am on. I still want to back > up my home directory though. > > If I'm working in a multi site corporation that has multiple backup > servers (one per site perhaps). I want to use the local backup server > not the one back home that's through a thin pipe. I'd want my laptop to > discover the local backup server and authenticate it to me and me to it. > > Ok these ideas don't quite work with the diskless Stateless model but > they are still valid when talking about homedir backup. > > Carwyn > If the client is configured to connect to a system via DNS name, that provides the enterprise with some flexibility like this. In Australia, homebackupsvr.corp.org could resolve to a different box than in the UK, etc. On the backend, I could workout how to merge them together on faster pipes. Such merging could get sticky of course and may be more of a 2.0 kind of thing. -- David Hollis From kyrre at solution-forge.net Wed Sep 15 18:44:46 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 15 Sep 2004 20:44:46 +0200 Subject: Stateless Linux -- HTML version of the PDF intro In-Reply-To: <4147861D.4080409@ntlworld.com> References: <4147861D.4080409@ntlworld.com> Message-ID: <1095273886.3220.0.camel@kyrre> ons, 15.09.2004 kl. 02.00 skrev William Merriam's most spammed mbox: > I realize it's a bit late, but here's an HTML version of the > introduction, StatelessLinux.pdf, which Havoc Pennington referred to > at the start of the Stateless Linux project thread. > > http://citethisbook.net/Red_Hat_Introduction_to_Stateless_Linux.html > > Something unusual about the original PDF prevents copying and pasting > in xpdf and, I hear, even in Adobe Acrobat Reader 6.0 under windows. > The problem also affects xpdf-utils, causing pdftotext to print > garbage. > think it is due to OpenOffice - somhow, oo-created pdf's arent copy-paste-able ;) From erik at totalcirculation.com Wed Sep 15 18:47:31 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Wed, 15 Sep 2004 14:47:31 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6591D9752@smith.interlink.local> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Carwyn Edwards > Sent: Wednesday, September 15, 2004 2:15 PM > To: Development discussions related to Fedora Core > Subject: Re: Homedir backup (was Re: "Stateless Linux" project) > > > Stuff about identifying which network we are on to see if we > want to do backup. > > If I'm away at a conference with my laptop and they have WiFi access to > the internet, I don't care which network I am on. I still want to back > up my home directory though. > I've got concur and say for homedir backup, the obvious solution is allowing the user to enable and disable it easily. I like the idea of a taskbar throbber applet, and I'd like to easily be able to run some sort of command to enable backups, backup now, and disable backups as well. Right-click menu options on the throbber or whatever would be nice too. Automatically determining the state based on the network is easily solved once the basics are there. I currently have no easy and efficient solution to backup up my home directory on a stateful machine and sync it back, so I'd prefer to see that happen first. I think the place to tackle this stuff first for both the home directory and system configuration aspects is with regard to choosing files to backup intelligently. Someone pointed out that their rpm folder is monstrous. Mine is too, as are bunches of other folders floating through my home directory and system. Perhaps a simple standardized home directory layout is in order. For instance: One might have a ~/tmp into which ~/rpm/BUILD and other junk accumulators would be linked. It would have a no-backup policy. Then perhaps a ~/static or some such where one could put their music files, movie rips, ~/rpm/SRPMS, random tarball downloads, fedora install tree mirrors, or whatever else they might be hauling around that never changes. Such a folder could (and should) have a different (lower priority, server-wins?) sync policy than, for instance ~/Maildir (high priority, last update wins?). I realize rsync exclude lists can work around more complex layouts, but I think the idea here is to automate and simplify. In addition, I want 2-way sync on at least some part of my home directory. Splitting it up into a few different policies makes automated sync conflict resolution easier. Anyway, just another $0.02. From felipe_alfaro at linuxmail.org Wed Sep 15 18:46:09 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 15 Sep 2004 20:46:09 +0200 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <41488076.2080401@carwyn.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095268071.9073.8.camel@opus.phy.duke.edu> <200409151310.32520.grmoc@yahoo.com> <1095268387.9073.15.camel@opus.phy.duke.edu> <41487F17.9060705@insitesinc.com> <41488076.2080401@carwyn.com> Message-ID: <829BEDBE-0747-11D9-800F-000D9352858E@linuxmail.org> On 15/09/2004, at 19:48, Carwyn Edwards wrote: > Michael Favia wrote: > >> We bet a lot of things on theoretical uniqueness in computing. Short >> of spoofing and freakish occurances im personally willing to bet my >> "home" on the uniqueness of a mac address. > > > Really? Even though there is hardware out there that lets the user > manually assign the MAC and that there are routers out there that > "spoof" MACs for use with broadband ISP access controls? I can manually override the MAC address of my PowerBook's Ethernet ports. Also, in clustering environments, it's pretty normal to have duplicated MAC addresses. From eli.carter at inet.com Wed Sep 15 18:57:23 2004 From: eli.carter at inet.com (Eli Carter) Date: Wed, 15 Sep 2004 13:57:23 -0500 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095267986.30358.33.camel@dcbw.boston.redhat.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> Message-ID: <41489093.9000103@inet.com> Dan Williams wrote: > On Wed, 2004-09-15 at 12:09 -0400, Owen Taylor wrote: > >>So, you might want to look at it as "backup only when on these >>networks". I think it's pretty reasonable to assume that people >>have lots of bandwidth at home and at work these days. > > > Which presents the question, is there any attributes that NetworkManager > can expose about the network that would help this? Time connected so > far attribute (though that wouldn't really tell you anything about what > the user might do 5 seconds from now when they pull the plug and walk > out of the coffee shop)? > > NetworkManager doesn't have a concept of profiles, since that was a > specific exclusion from the beginning (profiles suck). I'm not quite > sure how to go about a "backup only when on these networks", except > perhaps for these two ideas: > > 1) on wired networks, use your hostname as returned via DHCP, match that > against a "home network" sort of thing. But remember, NetworkManager > keeps the hostname of the actual machine constant (because otherwise X > falls over and dies), so NM would save the hostname right before setting > it back and expose that via DBus > > 2) On wireless networks, we could key off of the ESSID of the base > station to figure out whether you were on a "home" network or not. > > 3) other, more complicated ways? I think the way this should work is: Can I make a _secure_ connection to _my_ server? (Think ssh connection with the keys set up to know that the other side is who you think it is.) If so, start the backup process over that link. Do scheduling of the network traffic so user-initiated traffic gets higher priority than the backup. Keep in mind that the backup may be initiated by the user as well and would need to get scheduled as such. The user needs a way to tell the system "Don't do that right now" in case they are on an expensive link, or know something else the computer doesn't know, can't know, or misunderstands. There should also be a user-configurable daemon (or whatever) that can tell the backup system whether it should do its thing right now or not, based on arbitrary factors. For instance: battery life, disk is spun down, we're plugged into power, it's been X hours, we have Y kB of deltas that need to be backed up, certain important files have been modified, etc., etc. Otherwise, you're confusing "where I am" with "what I can do". Sometimes they correlate, but they aren't really the same. Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Inet Technologies, Inc. ------------------------------------------------------------------------ From kyrre at solution-forge.net Wed Sep 15 18:59:57 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 15 Sep 2004 20:59:57 +0200 Subject: Wireless update to ifup and network-functions In-Reply-To: References: Message-ID: <1095274797.3220.3.camel@kyrre> Love to see it. will you post the link here? ons, 15.09.2004 kl. 17.02 skrev Jon Nettleton: > If have put together a function and some new code for > is_wireless_device that uses iwlist to scan available access points > and then ifup a new configuration file if it finds one matching > ifcfg-DEVICE_ESSID. My questions are. > > 1) Is this the correct list? > 2) Is this something that maintainers are interested in adding? > 3) What is prefered format for patches? > > Hope to help out making Fedora Core 3 the best it can be. > > -Jon > From michael at insitesinc.com Wed Sep 15 19:05:20 2004 From: michael at insitesinc.com (Michael Favia) Date: Wed, 15 Sep 2004 14:05:20 -0500 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <414886B0.80504@carwyn.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095269993.5860.48.camel@localhost.localdomain> <414886B0.80504@carwyn.com> Message-ID: <41489270.7080305@insitesinc.com> Carwyn Edwards wrote: > > If I'm away at a conference with my laptop and they have WiFi access > to the internet, I don't care which network I am on. I still want to > back up my home directory though. > And you'd be able to define the choice to do so. This concerned the ability to say: "Only sync when attached Here and Here". I'm sure an always attempt to sync would be available. -- Michael Favia michael at insitesinc dot com Insites Incorporated http://michael.insitesinc.com From skvidal at phy.duke.edu Wed Sep 15 19:08:40 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Sep 2004 15:08:40 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6591D9752@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6591D9752@smith.interlink.local> Message-ID: <1095275320.9073.29.camel@opus.phy.duke.edu> > monstrous. Mine is too, as are bunches of other folders floating through > my home directory and system. Perhaps a simple standardized home > directory layout is in order. There is no such thing as a 'standardized homedir' > For instance: > One might have a ~/tmp into which ~/rpm/BUILD and other junk > accumulators would be linked. It would have a no-backup policy. Then > perhaps a ~/static or some such where one could put their music files, > movie rips, ~/rpm/SRPMS, random tarball downloads, fedora install tree > mirrors, or whatever else they might be hauling around that never > changes. Such a folder could (and should) have a different (lower > priority, server-wins?) sync policy than, for instance ~/Maildir (high > priority, last update wins?). > > I realize rsync exclude lists can work around more complex layouts, but > I think the idea here is to automate and simplify. In addition, I want > 2-way sync on at least some part of my home directory. Splitting it up > into a few different policies makes automated sync conflict resolution > easier. The exclude and include lists are trivial. Open nautilus window or gnome file selector box: drag out the folders you do not want to backup. And we're done. -sv From skvidal at phy.duke.edu Wed Sep 15 19:11:49 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Sep 2004 15:11:49 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <604aa791040915105295c6ac0@mail.gmail.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267273.9073.6.camel@opus.phy.duke.edu> <1095268424.5860.34.camel@localhost.localdomain> <1095268854.9073.20.camel@opus.phy.duke.edu> <1095268943.9073.22.camel@opus.phy.duke.edu> <604aa791040915105295c6ac0@mail.gmail.com> Message-ID: <1095275509.9073.32.camel@opus.phy.duke.edu> > -jef"preaching to the choir, hoping other people are watching and get > the point"spaleta Sadly, I'm in the choir. I'm one of those crazy guys who start small and try to add things on as the idea progresses. So who has the time? Who has the interest? -sv From dhollis at davehollis.com Wed Sep 15 19:13:10 2004 From: dhollis at davehollis.com (David Hollis) Date: Wed, 15 Sep 2004 15:13:10 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6591D9752@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6591D9752@smith.interlink.local> Message-ID: <1095275591.29577.11.camel@dhollis-lnx.kpmg.com> On Wed, 2004-09-15 at 14:47 -0400, Erik LaBianca wrote: > > > I think the place to tackle this stuff first for both the home directory > and system configuration aspects is with regard to choosing files to > backup intelligently. Someone pointed out that their rpm folder is > monstrous. Mine is too, as are bunches of other folders floating through > my home directory and system. Perhaps a simple standardized home > directory layout is in order. > > For instance: > One might have a ~/tmp into which ~/rpm/BUILD and other junk > accumulators would be linked. It would have a no-backup policy. Then > perhaps a ~/static or some such where one could put their music files, > movie rips, ~/rpm/SRPMS, random tarball downloads, fedora install tree > mirrors, or whatever else they might be hauling around that never > changes. Such a folder could (and should) have a different (lower > priority, server-wins?) sync policy than, for instance ~/Maildir (high > priority, last update wins?). I don't think this should be policy pushed from RedHat/Fedora. It seems to be much more of an organizational policy. As long as the user interface presents a reasonable interface for exclusions (I'm not sure that there would be an inclusion option...), with the default 'sync all' concept, it should work fine. Having priority on directories would certainly be interesting, though may have to be tackled at the next pass. It seems to me that rsync makes a great candidate for this purpose, though there are some limitations (unless I'm just not aware of certain command flags): 1 - being in a library would probably be much nicer for this task, rather than spawning a process and trying to parse it's output 2 - Being a seperate process, there isn't the same ability to start/stop/pause from a user interface. 3 - Does not provide easily machine parseable output for a gui to provide status information There is a librsync project at sourceforge (http://librsync.sf.net) though it is listed as not wire compatible with the v2 rsync protocol. It may be sufficient for this purpose however. -- David Hollis From eli.carter at inet.com Wed Sep 15 19:14:08 2004 From: eli.carter at inet.com (Eli Carter) Date: Wed, 15 Sep 2004 14:14:08 -0500 Subject: "Stateless Linux" project In-Reply-To: <1095205721.4127.126.camel@localhost.localdomain> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <1095204673.2701.147.camel@localhost.localdomain> <1095205721.4127.126.camel@localhost.localdomain> Message-ID: <41489480.7080901@inet.com> Havoc Pennington wrote: > Dan's stuff right now keeps incremental backups (it uses rsync with the > option to hardlink a new tree based on an old tree) and so the questions > are e.g. when do you throw out the old backups, etc. > > Maybe the right answer is to make the rsync-to-server thingy dead stupid > (no incremental backup or anything like that, though maybe it should > ensure each sync is atomic by having two copies) and rely on backing up > the server for getting incrementals and so forth. Use rdiff-backup (mentioned in other comments). Set up some simple policy on how long to keep which backups. Provide a simple 'restore lost file from backup' GUI (and commandline) utilities. The "simple" policy I would advocate would be to keep incremental backups on this schedule: One per day for the last week. One per week for the last month[1] One per month for the last N months, where N <= 14 [2], and have N automatically fluctuate as disk space on the server is consumed and freed. (May warn the user when it is about to be decreased.) [1] Define "month" to mean "4 weeks" for simplicity. [2] For a year, N = 52/4 = 13, and add one so you can get last April's tax return you inadvertantly deleted. Regarding rdiff-backup: it keeps the incremental backups as "reverse" deltas from the latest, which works well for aging off the old backups and for disk usage. Backing up data is one of those things that users don't tend to do. And when done, aren't done regularly, kept up to date, etc. Making it automatic, default behavior, and straightforward to restore from would do wonders to improve the state of most users. (Including me!) And, as a bonus, would be a great selling point for folks with a small or home office. Thoughts? Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Inet Technologies, Inc. ------------------------------------------------------------------------ From jon.nettleton at gmail.com Wed Sep 15 19:14:34 2004 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 15 Sep 2004 15:14:34 -0400 Subject: Wireless update to ifup and network-functions In-Reply-To: <1095274797.3220.3.camel@kyrre> References: <1095274797.3220.3.camel@kyrre> Message-ID: On Wed, 15 Sep 2004 20:59:57 +0200, Kyrre Ness Sjobak wrote: > Love to see it. will you post the link here? > > ons, 15.09.2004 kl. 17.02 skrev Jon Nettleton: > > > > If have put together a function and some new code for > > is_wireless_device that uses iwlist to scan available access points > > and then ifup a new configuration file if it finds one matching > > ifcfg-DEVICE_ESSID. My questions are. > > > > 1) Is this the correct list? > > 2) Is this something that maintainers are interested in adding? > > 3) What is prefered format for patches? > > > > Hope to help out making Fedora Core 3 the best it can be. > > > > -Jon > > > > Here is my first set of working patches. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132661 I realize that NetworkManager will eventually help solve this problem. But I think this is a quick and relatively simple way to get booted up and associated with the proper wireless network. From aoliva at redhat.com Wed Sep 15 19:19:52 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 15 Sep 2004 16:19:52 -0300 Subject: "Stateless Linux" project In-Reply-To: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> Message-ID: On Sep 15, 2004, "Bryan K. Wright" wrote: > Back to my original suggestion of a "RAID 1" mirror composed of > a local disk and a network block device: Better do LVM mirroring than RAID 1, otherwise you'll end up having to resync the entire volume every time something changes. I understand LVM mirrors do it on an extent basis. But what would be really appropriate for this application is inter-mezzo: keeping the FS transaction log and using that to tell what to send to the other replica sounds like the right way to do this kind of synchronization. Too bad inter-mezzo is dead :-( -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From michael at insitesinc.com Wed Sep 15 19:20:47 2004 From: michael at insitesinc.com (Michael Favia) Date: Wed, 15 Sep 2004 14:20:47 -0500 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095273587.6499.18.camel@dhollis-lnx.kpmg.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095268071.9073.8.camel@opus.phy.duke.edu> <200409151310.32520.grmoc@yahoo.com> <1095268387.9073.15.camel@opus.phy.duke.edu> <41487F17.9060705@insitesinc.com> <41488076.2080401@carwyn.com> <41488427.10401@insitesinc.com> <1095273587.6499.18.camel@dhollis-lnx.kpmg.com> Message-ID: <4148960F.9040702@insitesinc.com> David Hollis wrote: >I think trying to determine location via Layer 2 means is going to be a >big mistake. > Perhaps you are correct. >Networks tend to be very amorphous these days and node >location is very non-physical. > Very valid point. Floating between wireless access point on same network and all included. >The workstation should not care at all >WHERE it is, it's more of a question of "can I get to where I need to?" >If contact can be made to the "home directory backup server", it is able >to sync. > Yes but the reason someone raised the MAC address issue was a bandwidth concern. For instance you can reach my server from the internet via cellphone infrared internet access (or dialup, public coffeshop) but i wouldnt want to sync from there most of the time. Especially if my work was more sensitive (financial, etc). >MAC address should play no part in this. Do you really want all of the >client systems to stop backing up because you had to change an interface >card in the router? Do you want to have to keep the same MAC address on >that route forever so that you don't have to change every client in the >org that may connect on that subnet? > > I dont really have a problem with eternally spoofing the router address but you convinced me that it isnt necessary or a good reference point to judge ability/willingness to sync. Perhaps what we really want is this: 1. Assume can reach sync server 2. If we are on a acknowledged MAC sync up without asking. 3. If we aren't test bandwidth and assess amount to transfer then present user with a nice throbber (with size of transfer, avg speed and time expected) that allows him/her to decide or perhaps set a rule to decide (e.g. under 5 mins sync auto). Regardless you have raised a good point that MAC addresses are NOT the determining factor in our willingness/desire to sync. Instead bandwidth, expected time on connection and perhaps the security of the connection really determine it. In either case administrators could write rule that prohibit outside syncing if desired (via MAC rules) and normal users could benefit from increased portability. Sound better? -- Michael Favia michael at insitesinc dot com Insites Incorporated http://michael.insitesinc.com From Theodore.Papadopoulo at sophia.inria.fr Wed Sep 15 19:30:26 2004 From: Theodore.Papadopoulo at sophia.inria.fr (Theodore Papadopoulo) Date: Wed, 15 Sep 2004 21:30:26 +0200 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: Your message of "Wed, 15 Sep 2004 12:09:28 EDT." <1095264568.5860.29.camel@localhost.localdomain> Message-ID: <200409151930.i8FJUQ96023726@taquilee.inria.fr> otaylor at redhat.com said: > Well, a bigger problem with rsync is that in many cases, the listing > files part is the biggest time sync. And if that gets interrupted, you > start from the beginning. (*) Maybe I'm incorrect, but this all the more true when rsync is doing checksums. Remove the --checksum from the command line and the listing files starts to be negligible (at least when lots of files are changed). > So, starting a backup via wireless/vpn when you open your laptop for 5 > minutes at the coffee shop doesn't usually make sense. Rigt, but it would make a lot of sense of letting the user decides. There are two things needed: When a backup started, the popup displayed should show that a backup is in progress and ask for what to decide (reboot later or postpone the backup). This should allow At connexion time, let gdm have an option "no backup for this session" and if the computer is connected on a given network for the first time, prompt the user with a choice: - never backup on this network. - always backup on this network [ optionnaly throught a VPN]. - always ask me for this network. That should pretty much cover all the situations, at least for laptops. For workstations, basically all this is not necessary IMHO (configure everything at installation time). One important feature is that a backup should always be interruptible leaving the computer in a coherent state. Another question is who should initiate the backup. Should it be the laptop/workstation, or should it be the network server holding the backup (which makes sense to avoid congestion when everyone is connecting its laptop on the network in the morning). I have heard about dirvish for doing such server initiated backups. Anyone has experience with it ? Theo. -------------------------------------------------------------------- Theodore Papadopoulo Email: Theodore.Papadopoulo at sophia.inria.fr Tel: (33) 04 92 38 76 01 -------------------------------------------------------------------- From aoliva at redhat.com Wed Sep 15 19:31:14 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 15 Sep 2004 16:31:14 -0300 Subject: user data sync (Re: "Stateless Linux" project) In-Reply-To: <1095205312.4127.119.camel@localhost.localdomain> References: <1095164446.11530.204330179@webmail.messagingengine.com> <1095205312.4127.119.camel@localhost.localdomain> Message-ID: On Sep 14, 2004, Havoc Pennington wrote: > In any case, imagine you have two laptops, "Thinkpad" and "Inspiron", > and a workstation "Optiplex". Something you might want to throw into the brain-storming: consider removable disks. I like to keep most of my data in big, fast removable hard drives, such that I can quickly switch from desktop to notebook, by simply moving the disks around. Sure enough, I don't always want to carry the extra weight when I'm on the road, so I have local copies of the home dir that's in the removable disks in the notebook, and I do have a minimal home dir in the desktop as well, such that I can log into it even when the removable storage is connected to the notebook. How would you handle this scenario of having the master home dir in removable storage, with local (partial?) copies of the home dir in each box. > Just having reliable homedir backup, plus the above UI, would be very > useful and dramatically better than what most people use today. The only thing I don't quite like in this idea is the name. To me, backups are snapshots of filesystems that you archive for relatively long periods of time, often in multiple full and incremental copies. In this case, you're only keeping the most-recent snapshot of the filesystem, so I'd rather use a different name. I'm afraid no good suggestion occurs to me. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From jspaleta at gmail.com Wed Sep 15 19:31:15 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 15 Sep 2004 15:31:15 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095275591.29577.11.camel@dhollis-lnx.kpmg.com> References: <4B134FE6AC994B4C99B4D74A8E9EB6591D9752@smith.interlink.local> <1095275591.29577.11.camel@dhollis-lnx.kpmg.com> Message-ID: <604aa7910409151231619a8244@mail.gmail.com> On Wed, 15 Sep 2004 15:13:10 -0400, David Hollis wrote: > It seems to me that rsync makes a great candidate for this purpose, > though there are some limitations (unless I'm just not aware of certain > command flags): > 1 - being in a library would probably be much nicer for this task, > rather than spawning a process and trying to parse it's output > 2 - Being a seperate process, there isn't the same ability to > start/stop/pause from a user interface. > 3 - Does not provide easily machine parseable output for a gui to > provide status information > > There is a librsync project at sourceforge (http://librsync.sf.net) > though it is listed as not wire compatible with the v2 rsync protocol. > It may be sufficient for this purpose however. cough rdiff-backup cough librsync based cough python based... like all good system-config tools should be :-> http://rdiff-backup.stanford.edu/ or if you dont want the "mirror" aspects and want a little more privacy http://www.nongnu.org/duplicity/ -jef"using unattended rdiff-backup cronjobs via ssh on his lan for personal data, and man oh man is it fun to wipe his rawhide test box and do a fresh install and be able to restore is whole home directory from his rdiff-backup created backed on the other machine on the lan by asking rdiff-backup to simply drop the /home as it was 2 days ago right back into place, if rdiff-backup were in Core I could problably kickstart that sort of process with obnoxious ease."spaleta From eli.carter at inet.com Wed Sep 15 19:55:51 2004 From: eli.carter at inet.com (Eli Carter) Date: Wed, 15 Sep 2004 14:55:51 -0500 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <604aa7910409151231619a8244@mail.gmail.com> References: <4B134FE6AC994B4C99B4D74A8E9EB6591D9752@smith.interlink.local> <1095275591.29577.11.camel@dhollis-lnx.kpmg.com> <604aa7910409151231619a8244@mail.gmail.com> Message-ID: <41489E47.2020500@inet.com> Jeff Spaleta wrote: > cough rdiff-backup > cough librsync based > cough python based... like all good system-config tools should be :-> > http://rdiff-backup.stanford.edu/ > or if you dont want the "mirror" aspects and want a little more privacy > http://www.nongnu.org/duplicity/ > > -jef"using unattended rdiff-backup cronjobs via ssh on his lan for > personal data, and man oh man is it fun to wipe his rawhide test box > and do a fresh install and be able to restore is whole home directory > from his rdiff-backup created backed on the other machine on the lan > by asking rdiff-backup to simply drop the /home as it was 2 days ago > right back into place, if rdiff-backup were in Core I could problably > kickstart that sort of process with obnoxious ease."spaleta Preach it, brother! :) Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Inet Technologies, Inc. ------------------------------------------------------------------------ From jspaleta at gmail.com Wed Sep 15 20:06:00 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 15 Sep 2004 16:06:00 -0400 Subject: user data sync (Re: "Stateless Linux" project) In-Reply-To: <1095205312.4127.119.camel@localhost.localdomain> References: <1095164446.11530.204330179@webmail.messagingengine.com> <1095205312.4127.119.camel@localhost.localdomain> Message-ID: <604aa7910409151306bf6edb9@mail.gmail.com> On Tue, 14 Sep 2004 19:41:52 -0400, Havoc Pennington wrote: > So the "Copy of Inspiron" is a read-only backup of your Inspiron homedir > (kept on some network share). The other icons are the actual homedirs on > those systems. If you imagine I now connect the Inspiron, my Optiplex > desktop changes in real time: Yes that's right.. im going to beat the dead horse. "Copy of whatever" sure sounds like a mirror to me... did you know that rdiff-backup can produce a full "up2date" mirror of the incrementally backuped directory, plus a hidden directory tree to store the incremental differences. The UI you describe sounds very much like a slick way to connect to a read-only network shared rdiff-backup'd home directory to me. Now of course.. i dont have skill to make the UI slickness you describe work. But what if... I came up with a stupid hacky way to produce that sort of switching idea using a network mountable share of an rdiff-backup'd directory. A stupid little cronjob to detect if the real read-write mountpoint of interest unmounts, and then mounts the read-only rdiffbackup mountpoint from elsewhere on the network. And i created a dumb...very very very dumb automated rdiffbackup script that would attempt to keep the backup synced with the real mountpoint when it was active on something like a reasonable sync timescale once an hour or less. Would that interest you as a lead in into something more sophisticated? -jef"i think the dead horse likes it"spaleta From kyrre at solution-forge.net Wed Sep 15 20:23:46 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 15 Sep 2004 22:23:46 +0200 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095275320.9073.29.camel@opus.phy.duke.edu> References: <4B134FE6AC994B4C99B4D74A8E9EB6591D9752@smith.interlink.local> <1095275320.9073.29.camel@opus.phy.duke.edu> Message-ID: <1095279826.3220.39.camel@kyrre> Hmm... This could be applied on a (much) smaller case as well (i will use myself as a use case): On my "big" machine, i have an 80 GB disk - and most of what is used is in my home folder. I also have a laptop, which i can bring with me. Imagine that there was a small app that came preinstalled with fedora. It could be written i python or whatever - and it had a nice GUI. When activated, it would start when i booted my laptop (or at least when i logged into GNOME) - in the systray, beside the (pretty usless) RHN-applet. It would then try to connect to my "big" pc when i mount the NFS share (i use NFS to share my big pc's /home/kyrre to my laptop - it has the option "user" in fstab, which makes it possible to mount it from the GNOME gui), and if it detected any differences, it would become red or something - telling me to sync. I could then double-click it, and hit "sync" in order to sync the stuff - and it would sync, displaying nice blue GTK progress bars - one for each individual file, and one for total. Then it would go back to its happy, green/blue state. And ofcourse, if i right-clicked the aplet, it would display a "sync" thing - effectively doing the sync in the background, but allowed me to foreground it to see the nice progress bars, and background it again, and a "properties" option. There i could decide what should trigger an attempt to connect (and check whats new), (manual, connected to net (with some ways to id WHICH net), when fs XX is mounted etc etc), and which folders should be synced. For me, that would be the "documents" folder - not the download, music etc. So simply display a checkbox-list (something like the one in epiphanies bookmarks - but with the ability to dive recursively into directories). Just some small vissions. And it would be extremely usefull as well - i am pretty shure that i am not the only person with a similar use case... Kyrre Ness Sj?b?k ons, 15.09.2004 kl. 21.08 skrev seth vidal: > > monstrous. Mine is too, as are bunches of other folders floating through > > my home directory and system. Perhaps a simple standardized home > > directory layout is in order. > > There is no such thing as a 'standardized homedir' > > > For instance: > > One might have a ~/tmp into which ~/rpm/BUILD and other junk > > accumulators would be linked. It would have a no-backup policy. Then > > perhaps a ~/static or some such where one could put their music files, > > movie rips, ~/rpm/SRPMS, random tarball downloads, fedora install tree > > mirrors, or whatever else they might be hauling around that never > > changes. Such a folder could (and should) have a different (lower > > priority, server-wins?) sync policy than, for instance ~/Maildir (high > > priority, last update wins?). > > > > I realize rsync exclude lists can work around more complex layouts, but > > I think the idea here is to automate and simplify. In addition, I want > > 2-way sync on at least some part of my home directory. Splitting it up > > into a few different policies makes automated sync conflict resolution > > easier. > > The exclude and include lists are trivial. > > Open nautilus window or gnome file selector box: > drag out the folders you do not want to backup. > > And we're done. > > -sv > > From jspaleta at gmail.com Wed Sep 15 20:27:39 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 15 Sep 2004 16:27:39 -0400 Subject: "Stateless Linux" project In-Reply-To: <41489480.7080901@inet.com> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <1095204673.2701.147.camel@localhost.localdomain> <1095205721.4127.126.camel@localhost.localdomain> <41489480.7080901@inet.com> Message-ID: <604aa791040915132739d907b8@mail.gmail.com> On Wed, 15 Sep 2004 14:14:08 -0500, Eli Carter wrote: > Use rdiff-backup (mentioned in other comments). > Set up some simple policy on how long to keep which backups. > Provide a simple 'restore lost file from backup' GUI (and commandline) > utilities. > > The "simple" policy I would advocate would be to keep incremental > backups on this schedule: > One per day for the last week. > One per week for the last month[1] > One per month for the last N months, where N <= 14 [2], and have N > automatically fluctuate as disk space on the server is consumed and > freed. (May warn the user when it is about to be decreased.) > [1] Define "month" to mean "4 weeks" for simplicity. > [2] For a year, N = 52/4 = 13, and add one so you can get last April's > tax return you inadvertantly deleted. rdiff-backup doesn't allow for that finegrained of a policy currently. removing of old incrementals is only exposed with a "remove later than this point" option. You'd have to hook into current rdiff-backup development discussions about the likelyhood of that feature being expanded to allow for culling of increments in dateranges while leaving some. For example i run rdiff-backup nightly, and then tell it to remove increments older than 1 month old. There is no way for me to tell it things like "remove everything older than 1 month except for 1 increment as close to the start of each month as possible" -jef"rdiff-backup --make-me-a-sandwich"spaleta From eli.carter at inet.com Wed Sep 15 20:34:55 2004 From: eli.carter at inet.com (Eli Carter) Date: Wed, 15 Sep 2004 15:34:55 -0500 Subject: "Stateless Linux" project In-Reply-To: <604aa791040915132739d907b8@mail.gmail.com> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <1095204673.2701.147.camel@localhost.localdomain> <1095205721.4127.126.camel@localhost.localdomain> <41489480.7080901@inet.com> <604aa791040915132739d907b8@mail.gmail.com> Message-ID: <4148A76F.5020206@inet.com> Jeff Spaleta wrote: > On Wed, 15 Sep 2004 14:14:08 -0500, Eli Carter wrote: > >>Use rdiff-backup (mentioned in other comments). >>Set up some simple policy on how long to keep which backups. >>Provide a simple 'restore lost file from backup' GUI (and commandline) >>utilities. >> >>The "simple" policy I would advocate would be to keep incremental >>backups on this schedule: >>One per day for the last week. >>One per week for the last month[1] >>One per month for the last N months, where N <= 14 [2], and have N >>automatically fluctuate as disk space on the server is consumed and >>freed. (May warn the user when it is about to be decreased.) >>[1] Define "month" to mean "4 weeks" for simplicity. >>[2] For a year, N = 52/4 = 13, and add one so you can get last April's >>tax return you inadvertantly deleted. > > > rdiff-backup doesn't allow for that finegrained of a policy currently. > removing of old incrementals is only exposed with a "remove later than > this point" option. > You'd have to hook into current rdiff-backup development discussions > about the likelyhood > of that feature being expanded to allow for culling of increments in > dateranges while leaving some. For example i run rdiff-backup nightly, > and then tell it to remove increments older than 1 month old. There is > no way for me to tell it things like "remove everything older than 1 > month except for 1 increment as close to the start of each month as > possible" > -jef"rdiff-backup --make-me-a-sandwich"spaleta Ah, I thought it would support that. Oh well. So a simple policy of "keep a month's worth of incrementals" would be a good start. In my usage of rdiff-backup, I'm still at the "try to make rdiff-backup a habit" stage. :/ Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Inet Technologies, Inc. ------------------------------------------------------------------------ From hattenator at imapmail.org Wed Sep 15 20:37:55 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Wed, 15 Sep 2004 13:37:55 -0700 Subject: [usclug-chat] cyrus-imapd causes hardlock? Message-ID: <4148A823.1080600@imapmail.org> Is it possible for cyrus and postfix to cause a hardlock when no other programs seem to? 1-10 minutes after I start my mail server, the system hardlocks. I can record and transcode gigabytes of tv shows, run a web server, download and upload tons of stuff, and test the system in any way with no problems. Windows has no problems. Yet when I start cyrus, postfix, and saslauthd, the system indexes the mail for a while, then dies. Anyone ever hear of this before? I don't understand it. There's no kernel modules or special syscalls a mail server program runs, right? This is fedora development (2.90) with kernel 2.6.8-1.541 with latest cyrus-imapd, saslauthd, and postfix. I want to figure out whether I should file a bug report, since this almost doesn't make sense... -Eric Hattemer From kyrre at solution-forge.net Wed Sep 15 20:42:48 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 15 Sep 2004 22:42:48 +0200 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <4148960F.9040702@insitesinc.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <1095268071.9073.8.camel@opus.phy.duke.edu> <200409151310.32520.grmoc@yahoo.com> <1095268387.9073.15.camel@opus.phy.duke.edu> <41487F17.9060705@insitesinc.com> <41488076.2080401@carwyn.com> <41488427.10401@insitesinc.com> <1095273587.6499.18.camel@dhollis-lnx.kpmg.com> <4148960F.9040702@insitesinc.com> Message-ID: <1095280967.3220.52.camel@kyrre> There was sombody here who mentioned taking advantage of the auth mecanism in SSH to decide which network we are on Another who mentioned that backupserver.location.organisation.com did not have to be the same machine - what if i was normaly resided in Oslo, (domain oslo.organisation.com - my computer gets this from dhcp - and sice this is my "main" location - my main backupserver is backupserver.oslo.organisation.com) Then i travel to the Sidney office - and the dhcp happily tells me that my domain is "sidney.organisation.com" - which means that the backupserver is backupserver.sidney.organisation.com. Both these backupservers has an alias - "backupserver". And my laptop happily connects to that through the internal LAN (fat pipe). But the best thing is: "something" in my profile tells the server that my main site is oslo - so while i am in flight home - the sidney server slowly sends the backup "back home" throug a small pipe. But what if am in Bangkok - and there are no office there (no backupserver)? Well, then i could tell the machine (manually) to backup anyway - using ssh (it should anyway use ssh in order to establish that it is really on a thrusted network) back to my "home" backupserver. And all this could be managed by the user from a small taskbar applet (se my former mail) Kyrre ons, 15.09.2004 kl. 21.20 skrev Michael Favia: > David Hollis wrote: > > >I think trying to determine location via Layer 2 means is going to be a > >big mistake. > > > Perhaps you are correct. > > >Networks tend to be very amorphous these days and node > >location is very non-physical. > > > Very valid point. Floating between wireless access point on same network > and all included. > > >The workstation should not care at all > >WHERE it is, it's more of a question of "can I get to where I need to?" > >If contact can be made to the "home directory backup server", it is able > >to sync. > > > Yes but the reason someone raised the MAC address issue was a bandwidth > concern. For instance you can reach my server from the internet via > cellphone infrared internet access (or dialup, public coffeshop) but i > wouldnt want to sync from there most of the time. Especially if my work > was more sensitive (financial, etc). > > >MAC address should play no part in this. Do you really want all of the > >client systems to stop backing up because you had to change an interface > >card in the router? Do you want to have to keep the same MAC address on > >that route forever so that you don't have to change every client in the > >org that may connect on that subnet? > > > > > I dont really have a problem with eternally spoofing the router address > but you convinced me that it isnt necessary or a good reference point to > judge ability/willingness to sync. Perhaps what we really want is this: > > 1. Assume can reach sync server > 2. If we are on a acknowledged MAC sync up without asking. > 3. If we aren't test bandwidth and assess amount to transfer then > present user with a nice throbber (with size of transfer, avg speed and > time expected) that allows him/her to decide or perhaps set a rule to > decide (e.g. under 5 mins sync auto). > > Regardless you have raised a good point that MAC addresses are NOT the > determining factor in our willingness/desire to sync. Instead bandwidth, > expected time on connection and perhaps the security of the connection > really determine it. In either case administrators could write rule that > prohibit outside syncing if desired (via MAC rules) and normal users > could benefit from increased portability. Sound better? > > -- > Michael Favia michael at insitesinc dot com > Insites Incorporated http://michael.insitesinc.com > From s.ellis at fastmail.co.uk Wed Sep 15 22:29:53 2004 From: s.ellis at fastmail.co.uk (Stuart Ellis) Date: Wed, 15 Sep 2004 23:29:53 +0100 Subject: user data sync (Re: "Stateless Linux" project) In-Reply-To: <1095205312.4127.119.camel@localhost.localdomain> References: <1095164446.11530.204330179@webmail.messagingengine.com> <1095205312.4127.119.camel@localhost.localdomain> Message-ID: <1095287392.4503.131.camel@hampton.eln.lan> On Wed, 2004-09-15 at 00:41, Havoc Pennington wrote: > On Tue, 2004-09-14 at 13:20 +0100, Stuart Ellis wrote: > > > > Writable shared data stores presumably require some form of > > reconciliation or version control for multiple off-line copies to be > > handled smoothly. I suppose that one solution might be to wrap access > > to a version control system into the standard GUI so that the > > functionality becomes accessible to office workers; another might be to > > use a database-backed system like Storage, which could replicate. > > A sentiment around the office is that the "merge" concept is impossible > to sanely present to users, and so instead we should stick to "master > copy" and "backups" It would certainly require some very hard thinking - I don't think that anybody has a good answer yet. In most cases it probably isn't really necessary, either. For me it just feels unavoidable for those sets of data with multiple authors. > > For a file share used by multiple users, a simple approach is that they > have a read only copy on their laptop, and it changes to the writable > actual share while they are connected. Or just vanishes while > disconnected, if appropriate. Simplicity is definitely a key virtue here, for both the mechanisms and the presentation. This sounds right to me for most cases. > Just having reliable homedir backup, plus the above UI, would be very > useful and dramatically better than what most people use today. Maybe a > complex merge solution would be even better, but those solutions never > seem to catch on even though they've been implemented many times... I agree that integrating paired sync or backup really would be of immense benefit. It can be done with the technology available, and done better than the implementations in other OSes, as well. So I just jumped ahead to the next problem along... As I see it, as technical users we end up using both rsync and CVS because we need both approaches. Or replacing CVS with Subversion, or tla... There also now seems to be a few products attempting to bring version control and file repositories to the nontechnical (IBM Workplace, MS Sharepoint and Volume Shadow Copy). I doubt that they will get it right, and usability will probably be the biggest failing. But there is clearly a present need to manage sets of files with multiple authors and remote or disconnected clients. The popular methods of file sharing right now are pretty awful for meeting those requirements. This feels like the next logical consideration once you talk about client machines as interchangeable hosts for data that are capable of disconnected operation. The amazing thing about Stateless Linux as described is that it can obviously be done; people on this list can go straight to talking about the detail because we know that the necessary fundamentals exist. The issue of data sharing is the one area where I couldn't think of any available technology that actually works well. From s.ellis at fastmail.co.uk Wed Sep 15 23:48:17 2004 From: s.ellis at fastmail.co.uk (Stuart Ellis) Date: Thu, 16 Sep 2004 00:48:17 +0100 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <41489093.9000103@inet.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <41489093.9000103@inet.com> Message-ID: <1095292097.4503.205.camel@hampton.eln.lan> On Wed, 2004-09-15 at 19:57, Eli Carter wrote: > > I think the way this should work is: > > Can I make a _secure_ connection to _my_ server? > (Think ssh connection with the keys set up to know that the other side > is who you think it is.) > If so, start the backup process over that link. > Do scheduling of the network traffic so user-initiated traffic gets > higher priority than the backup. Keep in mind that the backup may be > initiated by the user as well and would need to get scheduled as such. > The user needs a way to tell the system "Don't do that right now" in > case they are on an expensive link, or know something else the computer > doesn't know, can't know, or misunderstands. > There should also be a user-configurable daemon (or whatever) that can > tell the backup system whether it should do its thing right now or not, > based on arbitrary factors. For instance: battery life, disk is spun > down, we're plugged into power, it's been X hours, we have Y kB of > deltas that need to be backed up, certain important files have been > modified, etc., etc. > > Otherwise, you're confusing "where I am" with "what I can do". > Sometimes they correlate, but they aren't really the same. I agree with this. I'm not sure that it ought to matter where the machine is, provided that the link is good. Perhaps the most basic question for an automatic sync is "is the link likely to disappear whilst I'm working ?" We can guess that links with certain qualities are bad (bandwidth too low, connection hasn't been available or stable for a period of x seconds, user specifies that that link should not be used for sync). We can't automatically tell when the user will want to disconnect the link themselves, so the concept of arranging completely automatic (rather than scheduled) backups may be problematic unless the backups can be safely broken up into small sets that can complete quickly. The Windows file sync software can automatically backup on login and logout. It drove me nuts that it would spend several minutes working through my entire home directory after I had decided that I wanted to switch off the laptop. From dhollis at davehollis.com Thu Sep 16 00:09:29 2004 From: dhollis at davehollis.com (David Hollis) Date: Wed, 15 Sep 2004 20:09:29 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095292097.4503.205.camel@hampton.eln.lan> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <41489093.9000103@inet.com> <1095292097.4503.205.camel@hampton.eln.lan> Message-ID: <1095293369.3967.6.camel@dhollis-lnx.kpmg.com> On Thu, 2004-09-16 at 00:48 +0100, Stuart Ellis wrote: > > Perhaps the most basic question for an automatic sync is "is the link > likely to disappear whilst I'm working ?" We can guess that links with > certain qualities are bad (bandwidth too low, connection hasn't been > available or stable for a period of x seconds, user specifies that that > link should not be used for sync). > > We can't automatically tell when the user will want to disconnect the > link themselves, so the concept of arranging completely automatic > (rather than scheduled) backups may be problematic unless the backups > can be safely broken up into small sets that can complete quickly. The > Windows file sync software can automatically backup on login and > logout. It drove me nuts that it would spend several minutes working > through my entire home directory after I had decided that I wanted to > switch off the laptop. > Windows provides a good example of how it should not work. It needs to be something can be performed in the backgroun and can be interrupted and recover gracefully. And it shouldn't be triggered by login/logout. Those are probably the times when the user wants it least. In the morning they boot up and want to get into email/web whatever to start getting stuff done. The last thing you need is the drive sitting there chugging while it determines what it needs to sync. At logout, you're heading home the for the day, trying to beat traffic, etc and the last thing you want is to have to wait for that 650MB iso you just downloaded to sync! -- David Hollis From shiva at sewingwitch.com Thu Sep 16 00:16:07 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 15 Sep 2004 17:16:07 -0700 Subject: Stateless Linux mailing list? Message-ID: Considering how popular the topic is, does it not make sense to start a new mailing list? I ask this not in an attempt to drive the traffic off the Fedora list, but to make it easier for people to break the discussion up into distinct issue threads, which are all currently lumped into the one big thread. For example, the About document talks about a read-only root and the issues that arise, and I'd like to learn more about this. How can we get all services that use transient state from a DHCP client (eg. the resolver and the NTP daemon) to start looking for it somewhere else? (Please start a new thread if you want to tackle that question.) From jamesaharrisonuk at yahoo.co.uk Thu Sep 16 00:42:55 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Wed, 15 Sep 2004 17:42:55 -0700 (PDT) Subject: Gnome 8.0 Message-ID: <20040916004255.13716.qmail@web25301.mail.ukl.yahoo.com> Hi, Is it too late in the FC3 development cycle to use Gnome 8? James __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From jamesaharrisonuk at yahoo.co.uk Thu Sep 16 00:44:50 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Wed, 15 Sep 2004 17:44:50 -0700 (PDT) Subject: Gnome 8.0.... Gnome 2.8 Message-ID: <20040916004450.70367.qmail@web25305.mail.ukl.yahoo.com> Errrrr.. ......Sorry typo : Gnome 2.8....... Not 8 --- James Harrison wrote: > Hi, > > Is it too late in the FC3 development cycle to use Gnome 8? > > James > > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - Send 10MB messages! > http://promotions.yahoo.com/new_mail > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From elanthis at awesomeplay.com Thu Sep 16 00:45:49 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 15 Sep 2004 20:45:49 -0400 Subject: Gnome 8.0 In-Reply-To: <20040916004255.13716.qmail@web25301.mail.ukl.yahoo.com> References: <20040916004255.13716.qmail@web25301.mail.ukl.yahoo.com> Message-ID: <1095295549.10702.7.camel@stargrazer> On Wed, 2004-09-15 at 17:42 -0700, James Harrison wrote: > Hi, > > Is it too late in the FC3 development cycle to use Gnome 8? Given that it's running 2.7 currently, I really hope Fedora upgrades to the stable 2.8 release. ;-) > > James > > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - Send 10MB messages! > http://promotions.yahoo.com/new_mail > > From perbj at stanford.edu Thu Sep 16 01:02:09 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 15 Sep 2004 18:02:09 -0700 Subject: Gnome 8.0.... Gnome 2.8 In-Reply-To: <20040916004450.70367.qmail@web25305.mail.ukl.yahoo.com> References: <20040916004450.70367.qmail@web25305.mail.ukl.yahoo.com> Message-ID: <1095296528.3907.23.camel@localhost.localdomain> On Wed, 2004-09-15 at 17:44, James Harrison wrote: > Errrrr.. > > ......Sorry typo : Gnome 2.8....... Not 8 Should be available as updates soon after FC3test2: http://www.redhat.com/archives/fedora-test-list/2004-September/msg00561.html (So well ahead of FC3 final of course.) /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From jon.nettleton at gmail.com Thu Sep 16 01:06:27 2004 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 15 Sep 2004 21:06:27 -0400 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: References: <1095274797.3220.3.camel@kyrre> Message-ID: Laptop computers are dropping in price and rising in sales. Wireless ( is | is becoming) the de facto standard for home networking. Before Core 3 gets past the point of no return, I have to ask, "Where does Fedora Core 3 development stand on this technology?' For a laptop and even a desktop it seems that a clear cut idea of how this technology should work needs be addressed. I understand that the availibility of drivers is somewhat hampered by the manufacturers. Looking beyond that point, I really see an oversight in how wireless networking is being treated from the configuration standpoint. We are really looking at a dichotomy of viewpoints in how this aspect of networking should work. On the system administration side it is preferable that the administrator has control over the setup. There is no variance from the initial setup, and the networking configurations can be stopped and started but not tampered with. These configurations should benefit from the flexibility of wireless to scan and use network identifiers like the AP hardware address or the ESSID to automagically know how to connect based on existing network configurations. On the other hand, we see the user perspective that wants the simplicity of easily using a coffe shop, or friends wireless connectivity. I see NetworkManager as a solution to the latter of these issues. It gives a nice easy gui, and password/key management for the user. I have proposed a patch as a first stab for the first issue. If there is no immediate plans for moving away from the ifup/ifdown managment of network interfaces, I really feel that the wireless configuration needs to be more dynamic than the existing scripts provide us. As a wireless laptop user, switching wireless configurations from location to location has definitely been less than user-friendly. Setting up multiple profiles to choose from in grub is do-able, but not really what I am looking for. I would really like to see a much more dynamic network boot process that wireless networking really demans when Fedora Core 3 is released. -Jon On Wed, 15 Sep 2004 15:14:34 -0400, Jon Nettleton wrote: > > > On Wed, 15 Sep 2004 20:59:57 +0200, Kyrre Ness Sjobak > wrote: > > Love to see it. will you post the link here? > > > > ons, 15.09.2004 kl. 17.02 skrev Jon Nettleton: > > > > > > > If have put together a function and some new code for > > > is_wireless_device that uses iwlist to scan available access points > > > and then ifup a new configuration file if it finds one matching > > > ifcfg-DEVICE_ESSID. My questions are. > > > > > > 1) Is this the correct list? > > > 2) Is this something that maintainers are interested in adding? > > > 3) What is prefered format for patches? > > > > > > Hope to help out making Fedora Core 3 the best it can be. > > > > > > -Jon > > > > > > > > > Here is my first set of working patches. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132661 > > I realize that NetworkManager will eventually help solve this problem. > But I think this is a quick and relatively simple way to get booted > up and associated with the proper wireless network. > From jon at jonshouse.co.uk Thu Sep 16 01:33:21 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Thu, 16 Sep 2004 02:33:21 +0100 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: References: <1095274797.3220.3.camel@kyrre> Message-ID: <1095298400.16808.3528.camel@jonspc> > I see NetworkManager as a solution to the latter of these issues. It > gives a nice easy gui, and password/key management for the user. I > have proposed a patch as a first stab for the first issue. If there > is no immediate plans for moving away from the ifup/ifdown managment > of network interfaces, I really feel that the wireless configuration > needs to be more dynamic than the existing scripts provide us. > I have to have a gentle go at the kernel people at this point - slap me if you like :-) Wireless discovery in general isn't going to be easy across distributions because for reasons purely political (as far as I can tell???) the promisc mode was left on the cutting room floor !!! WHY !!!! I would have thought that tune, and listen would be the first two things any wireless driver would be able to do. I'm sick of having to patch the wlan drivers before I can run anything other than primitive discovery tools, or sniff...... So how about it guys - complete the API for the wireless so good front end tools and monitoring applications can rely on normal network functionality as part of the base OS. So we can maybe monitor for APs in background when traffic allows and have a truly transparent roaming ... Knoppix ships the patched drivers and I don't see them running scared, so why not make the patched drivers the standard drivers and save us users the tedium :-) Cheers, Jon From hp at redhat.com Thu Sep 16 02:02:26 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 15 Sep 2004 22:02:26 -0400 Subject: Stateless Linux mailing list? In-Reply-To: References: Message-ID: <1095300146.4427.5.camel@localhost.localdomain> On Wed, 2004-09-15 at 17:16 -0700, Kenneth Porter wrote: > Considering how popular the topic is, does it not make sense to start a new > mailing list? I ask this not in an attempt to drive the traffic off the > Fedora list, but to make it easier for people to break the discussion up > into distinct issue threads, which are all currently lumped into the one > big thread. My worry about breaking out a list is that the current huge thread is probably an artifact of the initial announce, and it may be taking up a lot less bandwidth in a week or two. Just wondering if maybe we should wait a couple weeks and see how it goes before making a new list. Havoc From jon.nettleton at gmail.com Thu Sep 16 02:23:35 2004 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 15 Sep 2004 22:23:35 -0400 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <1095298400.16808.3528.camel@jonspc> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> Message-ID: Well, Hallelujah and and Amen to that. Regardless, I am willing to throw the difference between a linux distribution and kernel development. I understand (atleast am informed thanks to lkml ) why the kernel developers choose their stances on driver development and inclusion/exclusion. I am also thankful that there are many side projects that provide the community with drivers that enable us to use hardware and functionality that isn't included in the kernel (I am using a MadWifi supported card right now), and sites the provide packages of these drivers ( dag, fedora.us, etc ). So what is stopping us from enabling use of this functionality, if a user installs kernel driver that supports it? Most of the driver packages,including ndiswrapper ( *cough* opensource community hates them , but they really do a great job giving people support for closed source drivers, *cough* )., support the existing wireless-tools commands. Why not provide the best usability we can using the toolset/funcationality we have.? On Thu, 16 Sep 2004 02:33:21 +0100, Jonathan Andrews wrote: > > > I see NetworkManager as a solution to the latter of these issues. It > > gives a nice easy gui, and password/key management for the user. I > > have proposed a patch as a first stab for the first issue. If there > > is no immediate plans for moving away from the ifup/ifdown managment > > of network interfaces, I really feel that the wireless configuration > > needs to be more dynamic than the existing scripts provide us. > > > > I have to have a gentle go at the kernel people at this point - slap me > if you like :-) > > Wireless discovery in general isn't going to be easy across > distributions because for reasons purely political (as far as I can > tell???) the promisc mode was left on the cutting room floor !!! WHY > !!!! > > I would have thought that tune, and listen would be the first two things > any wireless driver would be able to do. > > I'm sick of having to patch the wlan drivers before I can run anything > other than primitive discovery tools, or sniff...... > > So how about it guys - complete the API for the wireless so good front > end tools and monitoring applications can rely on normal network > functionality as part of the base OS. So we can maybe monitor for APs in > background when traffic allows and have a truly transparent roaming ... > > Knoppix ships the patched drivers and I don't see them running scared, > so why not make the patched drivers the standard drivers and save us > users the tedium :-) > > Cheers, > Jon > > From pekkas at netcore.fi Thu Sep 16 04:45:18 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 16 Sep 2004 07:45:18 +0300 (EEST) Subject: Wireless update to ifup and network-functions In-Reply-To: Message-ID: On Wed, 15 Sep 2004, Jon Nettleton wrote: > Here is my first set of working patches. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132661 > > I realize that NetworkManager will eventually help solve this problem. > But I think this is a quick and relatively simple way to get booted > up and associated with the proper wireless network. Do you sanity-check the input received from the network -- i.e., would it be possible for someone to name their AP for example '*; rm -rf /'? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Sep 16 08:50:30 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 16 Sep 2004 10:50:30 +0200 Subject: Distribution tag change of recent packages Message-ID: <20040916105030.676ba7b1@localhost> Hi, It seems that recently built packages have a distribution tag now different than the "Red Hat Linux" one that has always been used in Red Hat Linux and Fedora Core up to now. Why not, but I see two problems : - It contains the Fedora Core version, which means that packages won't be easily kept between versions (noarch packages that don't need updating for instance) without causing confusion. Are all packages now expected to be rebuilt from one FC version to another? - There are multiple different new strings used! Bad and most confusing... Red Hat FC-3 Red Hat (FC-3) Red Hat (RHEL-3) (yes, FC Dev. yptools .src.rpm has this set!) And glibc and rpmdb-fedora have none set. I think at least reaching an agreement on a single string would be a good start here, and maybe hearing reasons for the change since the last semi-official opinions I really getting on that matter were that distribution, vendor and packager tags weren't concerns, thus just stayed as they were. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.26 0.77 0.75 From harald at redhat.com Thu Sep 16 09:07:38 2004 From: harald at redhat.com (Harald Hoyer) Date: Thu, 16 Sep 2004 11:07:38 +0200 Subject: "Stateless Linux" project In-Reply-To: <20040915114555.GD27854@devserv.devel.redhat.com> References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> <20040914202921.GB4100@devserv.devel.redhat.com> <1095195303.4205.5.camel@localhost.localdomain> <1095229530.10739.183.camel@vigor12> <1095230437.23039.36.camel@binkley> <20040915114555.GD27854@devserv.devel.redhat.com> Message-ID: <414957DA.4070105@redhat.com> Alan Cox wrote: > Sfs is as close as I've seen. > > Alan > > Do you mean this? Self-certifying File System http://www.fs.net/sfswww/ Sounds nice, but haven't managed to compile it yet... too many C++ changes for the new g++. Are there patches available? Harald From d.bradley at imb.uq.edu.au Tue Sep 14 02:32:35 2004 From: d.bradley at imb.uq.edu.au (Daniel Bradley) Date: Tue, 14 Sep 2004 12:32:35 +1000 Subject: "Stateless Linux" project Message-ID: Hi, This seems similar in concept to what I have been working on for a while under the guise of Securizant Linux (sourceforge.net/projects/securizant). An adaption of LFS, but a root file system disk image is built, which is then mounted (via loopback) read-only during the boot process. This image is never modified during the life-cycle of the OS. There are scripts that will build the system currently in the sourceforge CVS that you may care to look at. They make use of a precompiled tools.iso toolchain image (500MB) that I can make available if you want. Feel free to email me for more info. Cheers, Daniel Bradley. From alan at redhat.com Thu Sep 16 11:30:41 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 16 Sep 2004 07:30:41 -0400 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <1095298400.16808.3528.camel@jonspc> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> Message-ID: <20040916113041.GA20759@devserv.devel.redhat.com> On Thu, Sep 16, 2004 at 02:33:21AM +0100, Jonathan Andrews wrote: > distributions because for reasons purely political (as far as I can > tell???) the promisc mode was left on the cutting room floor !!! WHY > !!!! Promisc mode (on those adapters that support it) is actually rather complicated in the wireless world. A lot of the old prism firmware doesn't support it for example. OpenAP has to basically take over the h/w at a much lower level to handle that and that involves a native 802.11 stack - which oddly enough is the direction that stuff is going From jon.nettleton at gmail.com Thu Sep 16 11:50:40 2004 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 16 Sep 2004 07:50:40 -0400 Subject: Wireless update to ifup and network-functions In-Reply-To: References: Message-ID: Very basically at this point. The last thing I do is change all the spaces and -'s to underscores. I could probably expand that list to include ,' and ;' and :s. I will add that to my next set of patches. Thanks for the input. On Thu, 16 Sep 2004 07:45:18 +0300 (EEST), Pekka Savola wrote: > On Wed, 15 Sep 2004, Jon Nettleton wrote: > > Here is my first set of working patches. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132661 > > > > I realize that NetworkManager will eventually help solve this problem. > > But I think this is a quick and relatively simple way to get booted > > up and associated with the proper wireless network. > > Do you sanity-check the input received from the network -- i.e., would > it be possible for someone to name their AP for example '*; rm -rf /'? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From dwmw2 at infradead.org Thu Sep 16 13:12:12 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 16 Sep 2004 14:12:12 +0100 Subject: Wireless update to ifup and network-functions In-Reply-To: References: Message-ID: <1095340332.9144.2356.camel@imladris.demon.co.uk> On Wed, 2004-09-15 at 11:02 -0400, Jon Nettleton wrote: > If have put together a function and some new code for > is_wireless_device that uses iwlist to scan available access points > and then ifup a new configuration file if it finds one matching > ifcfg-DEVICE_ESSID. My questions are. That's nice. I assume it selects the appropriate key based on the ESSID it finds? A while ago I sent patches to Bill (and/or put them in Bugzilla) which added Bluetooth networking support. I moved the tail end of ifup into ifup-eth, then added an 'ifup-wireless' which calls that, as does ifup-bnep. We no longer have to have the wireless (or bluetooth) stuff hacked in to the middle of ifup that way. -- dwmw2 From jon at jonshouse.co.uk Thu Sep 16 14:03:20 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Thu, 16 Sep 2004 15:03:20 +0100 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <20040916113041.GA20759@devserv.devel.redhat.com> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <20040916113041.GA20759@devserv.devel.redhat.com> Message-ID: <1095343400.16808.4261.camel@jonspc> On Thu, 2004-09-16 at 12:30, Alan Cox wrote: > On Thu, Sep 16, 2004 at 02:33:21AM +0100, Jonathan Andrews wrote: > > distributions because for reasons purely political (as far as I can > > tell???) the promisc mode was left on the cutting room floor !!! WHY > > !!!! > > Promisc mode (on those adapters that support it) is actually rather > complicated in the wireless world. A lot of the old prism firmware doesn't > support it for example. OpenAP has to basically take over the h/w at a much > lower level to handle that and that involves a native 802.11 stack - which > oddly enough is the direction that stuff is going Cool :-) Monitor mode is optional as far as I understand it. Users will tolerate a "your hardware wont do that message" more than a "please use xyz wifi_the_bits_we_left_out.diff and recompile the kernel" ;-) I understand its a mess at the hardware level and having raw 802.11 will be cool, but at the moment its getting messy. I find lots like this of threads like this http://kerneltrap.org/node/view/3192 http://kerneltrap.org/node/view/3245 http://www.bastard.net/~kos/wifi/rfmon.html It would be nice to be able to use cool toys without building new kernel or modules :-) Im sure that fedora will be on a lot of laptops, I know its on mine - and wifi even works :-D Cheers, Jon From dcbw at redhat.com Thu Sep 16 14:18:11 2004 From: dcbw at redhat.com (Dan Williams) Date: Thu, 16 Sep 2004 10:18:11 -0400 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <1095298400.16808.3528.camel@jonspc> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> Message-ID: <1095344291.6173.15.camel@dcbw.boston.redhat.com> On Thu, 2004-09-16 at 02:33 +0100, Jonathan Andrews wrote: > Wireless discovery in general isn't going to be easy across > distributions because for reasons purely political (as far as I can > tell???) the promisc mode was left on the cutting room floor !!! WHY > !!!! > > I would have thought that tune, and listen would be the first two things > any wireless driver would be able to do. Having looked a _lot_ at kernel wireless drivers in the past 2 months while developing NetworkManager, I'm not quite sure what the problem here is... Major wireless cards and drivers: Orinoco (Intersil, Wavelan, Airport, etc) Cisco Aironet Atmel Prism54 Intel 2100/2200 Almost all wireless drivers (with the notable exception of the Orinoco drivers, but that's upstream and currently filtering down in the kernel drivers) support wireless scanning (ie, returning a list of access points the card can see) to some degree in the latest kernels, from 2.6.6 and up. That's really what you need for good wireless support of the "it just works" type. What _isn't_ good is the inconsistency of the drivers in supporting the same types of options. For example: (1) signal strength/noise is not normalized between drivers, and the Atmel driver doesn't support signal strength data of scanned access points. Cisco drivers report totally different strength metrics for scanned access points and for the current access point too. (2) WEP/Authentication: Cisco drivers, for example, require a WEP key to be used when using Open System Authentication, which is just plain wrong. You don't need to use encryption when using Open auth. (3) Link detection. Only a few drivers (Orinoco, Intel) use the netif_carrier_on/off kernel interfaces for link detection. However, they use them mostly _wrong_. The general idea of a link-on status should be when the card has authenticated with the base station and traffic can flow (whether or not you're using the correct WEP key doesn't seem to be detectable with Open System Authentication, so that's another problem). What needs to be done? Normalize signal strength, and start using the correct idea of carrier on/off, fix freezes (Cisco drivers seem unstable on more recent kernels), and get Orinoco cards to support scanning (being worked on, albeit not fast). Dan From lfarkas at bppiac.hu Thu Sep 16 14:23:18 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Thu, 16 Sep 2004 16:23:18 +0200 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <1095344291.6173.15.camel@dcbw.boston.redhat.com> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <1095344291.6173.15.camel@dcbw.boston.redhat.com> Message-ID: <4149A1D6.2040807@bppiac.hu> Dan Williams wrote: > On Thu, 2004-09-16 at 02:33 +0100, Jonathan Andrews wrote: > >>Wireless discovery in general isn't going to be easy across >>distributions because for reasons purely political (as far as I can >>tell???) the promisc mode was left on the cutting room floor !!! WHY >>!!!! >> >>I would have thought that tune, and listen would be the first two things >>any wireless driver would be able to do. > > > Having looked a _lot_ at kernel wireless drivers in the past 2 months > while developing NetworkManager, I'm not quite sure what the problem > here is... > > Major wireless cards and drivers: > Orinoco (Intersil, Wavelan, Airport, etc) > Cisco Aironet > Atmel > Prism54 > Intel 2100/2200 may i add Atheros (MADwifi) to this list. -- Levente "Si vis pacem para bellum!" From pp at ee.oulu.fi Thu Sep 16 14:44:51 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Thu, 16 Sep 2004 17:44:51 +0300 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <1095344291.6173.15.camel@dcbw.boston.redhat.com> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <1095344291.6173.15.camel@dcbw.boston.redhat.com> Message-ID: <20040916144451.GA558@ee.oulu.fi> On Thu, Sep 16, 2004 at 10:18:11AM -0400, Dan Williams wrote: > (2) WEP/Authentication: Cisco drivers, for example, require a WEP key to > be used when using Open System Authentication, which is just plain > wrong. You don't need to use encryption when using Open auth. Gets even more messy when you start doing 802.1x/EAP/TKIP/WPA/RSN/whatnot, some cards hide the packets you should be processing from you completely, so xsupplicant breaks. Then there's the problem of setting the right dynamic WEP keys on the chip which also works in mysterious ways. Fortunately the competition is not that much better in this area, things work just about as randomly on XP as they do on Linux ;-) -- Pekka Pietikainen From dcbw at redhat.com Thu Sep 16 15:01:43 2004 From: dcbw at redhat.com (Dan Williams) Date: Thu, 16 Sep 2004 11:01:43 -0400 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <4149A1D6.2040807@bppiac.hu> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <1095344291.6173.15.camel@dcbw.boston.redhat.com> <4149A1D6.2040807@bppiac.hu> Message-ID: <1095346903.6173.22.camel@dcbw.boston.redhat.com> On Thu, 2004-09-16 at 16:23 +0200, Farkas Levente wrote: > > Major wireless cards and drivers: > > Orinoco (Intersil, Wavelan, Airport, etc) > > Cisco Aironet > > Atmel > > Prism54 > > Intel 2100/2200 > > may i add Atheros (MADwifi) to this list. I was more or less only including in-kernel drivers, of which MADwifi isn't one... But point taken. Since I work on Fedora, I can't really invesigate MADwifi since its not fully Open Source (due to the binary HAL and frequency restrictions), and while I understand _why_ its not fully OSS, I am really only going to fix/support in-kernel drivers for NetworkManager. Dan From jon at jonshouse.co.uk Thu Sep 16 15:10:46 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Thu, 16 Sep 2004 16:10:46 +0100 Subject: Wireless signal strength In-Reply-To: <1095344291.6173.15.camel@dcbw.boston.redhat.com> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <1095344291.6173.15.camel@dcbw.boston.redhat.com> Message-ID: <1095347446.16808.4291.camel@jonspc> www.wildpackets.com/elements/ whitepapers/Converting_Signal_Strength.pdf If RSSI is converted to a db scale by the driver and the kernel has the ability to map db back to RSSI then this solves the problems. By doing it this way it wouldn't matter how linear the RSSI on the card is (as the driver can correct). It wouldn't matter how many bits the card used to represent RSSI internally. It also allows devices that have a true db reading to map in without (much?) conversion. The kernel would then make available a meaningful and consistent RSSI derived from the db reading its using internally. The applications can then read one or both of (db) and (RSSI - the new strict linux kernel defined one - not the fluffy manufacturers one). All thats needed is a conversion from RSSI to db for each device, simplest place to stick that is in the driver - why complicate life any further ! Anyone else got any ideas ? Jon From lfarkas at bppiac.hu Thu Sep 16 16:44:51 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Thu, 16 Sep 2004 18:44:51 +0200 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <1095346903.6173.22.camel@dcbw.boston.redhat.com> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <1095344291.6173.15.camel@dcbw.boston.redhat.com> <4149A1D6.2040807@bppiac.hu> <1095346903.6173.22.camel@dcbw.boston.redhat.com> Message-ID: <4149C303.102@bppiac.hu> Dan Williams wrote: > On Thu, 2004-09-16 at 16:23 +0200, Farkas Levente wrote: > >>>Major wireless cards and drivers: >>>Orinoco (Intersil, Wavelan, Airport, etc) >>>Cisco Aironet >>>Atmel >>>Prism54 >>>Intel 2100/2200 >> >>may i add Atheros (MADwifi) to this list. > > > I was more or less only including in-kernel drivers, of which MADwifi > isn't one... But point taken. Since I work on Fedora, I can't really > invesigate MADwifi since its not fully Open Source (due to the binary > HAL and frequency restrictions), and while I understand _why_ its not > fully OSS, I am really only going to fix/support in-kernel drivers for > NetworkManager. in this case it would be _very_ useful to be a "supported hardware" page somewhere in the fedora website. so those who buy something can check before buy. i agree with you if you complain against ndis-wrapper, since it's another story. but those drivers which are not part of the mainstream kernel and _can't_ be part because of FCC etc. but it's still can be shipped by fedora and can be supported by it's kernel (at leaset a separate kernel module), where the "support" means you can help to fix problems with it, if you aware of such problems. as linus use to state a bad driver is still better than nothing. without this the old problems still remains "windows support all kind of hardware, while linux just a few ones" and we can't step forward. -- Levente "Si vis pacem para bellum!" From smoogen at lanl.gov Thu Sep 16 17:10:05 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Thu, 16 Sep 2004 11:10:05 -0600 Subject: Questions about Mozilla RPMS ? Message-ID: <4149C8ED.40907@lanl.gov> I saw Warren has a test RPM for firefox-0.10, but havent seen anyone attempt at thunderbird 0.8 or sunbird.. has anyone tried and is currently failing or just not had time.. my attempts so far have been less than even good. -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From dcbw at redhat.com Thu Sep 16 17:25:04 2004 From: dcbw at redhat.com (Dan Williams) Date: Thu, 16 Sep 2004 13:25:04 -0400 Subject: Wireless driver quality information sucks Message-ID: <1095355504.15587.1.camel@dcbw.boston.redhat.com> On Thu, 2004-09-16 at 16:10 +0100, Jonathan Andrews wrote: > www.wildpackets.com/elements/ whitepapers/Converting_Signal_Strength.pdf > > If RSSI is converted to a db scale by the driver and the kernel has the > ability to map db back to RSSI then this solves the problems. > > By doing it this way it wouldn't matter how linear the RSSI on the card > is (as the driver can correct). It wouldn't matter how many bits the > card used to represent RSSI internally. It also allows devices that have > a true db reading to map in without (much?) conversion. > > The kernel would then make available a meaningful and consistent RSSI > derived from the db reading its using internally. > > The applications can then read one or both of (db) and (RSSI - the new > strict linux kernel defined one - not the fluffy manufacturers one). > > All thats needed is a conversion from RSSI to db for each device, > simplest place to stick that is in the driver - why complicate life any > further ! One particular problem I referred to was with the Cisco drivers. There are two ways to get strength for an access point, one is through the wireless scan (if the drivers support it) and the other is using iw_get_range()/iw_get_stats() for strength info on the currently associated access point. Atmel drivers currently don't return _any_ quality information from wireless scans. Using iw_get_range/stats, the strength value returned is completely different than the value returned when the same access point shows up in the scan, even if you are associated with it right then. Also on the cisco drivers, there doesn't seem to be a good way to actually determine the signal strength from a scan. For both these methods, you get back an iw_quality structure that has: struct iw_quality { uint8 qual; uint8 level; uint8 noise; } ----- snip from iwlib.c /* People are very often confused by the 8 bit arithmetic happening * here. * All the values here are encoded in a 8 bit integer. 8 bit integers * are either unsigned [0 ; 255], signed [-128 ; +127] or * negative [-255 ; 0]. * Further, on 8 bits, 0x100 == 256 == 0. * * Relative/percent values are always encoded unsigned, between 0 and 255. * Absolute/dBm values are always encoded negative, between -255 and 0. * * How do we separate relative from absolute values ? We use the * range to do that. The range allow to specify the real min/max * of the value. As the range struct only specify one bound of the * value, we assume that the other bound is 0 (zero). * For relative values, range is [0 ; range->max]. * For absolute values, range is [range->max ; 0]. * * Let's take two example : * 1) value is 75%. qual->value = 75 ; range->max_qual.value = 100 * 2) value is -54dBm. noise floor of the radio is -104dBm. * qual->value = -54 = 202 ; range->max_qual.value = -104 = 152 * * Jean II */ ------ Now the "qual" field is kind of ambiguous, and drivers seem to put different values in there (Cisco drivers _always_ set this to 0 for wireless scans). What we're interested in is the level/noise structures. All these values are either Relative or Absolute. Absolute values are in dBm/rssi (drivers seem to mix this up a _lot_) while Relative values are 0-100 as a percentage. The application itself has to figure out which is being used. Next, the dBm values are in the range of 0 - 255 which is in actuality -127 - 128. Cisco drivers only return Noise information when calling iw_get_stats() but not for a wireless scan, and I've found you cannot use the noise value from stats() along with the wireless scan data, which is where this problem lies. Cisco drivers also use some magic numbers here and there that don't quite add up (for example, you'll see the RSSI subtracted from 256 in some places, or subtracted from 321 then divided by two in other places). Devices also have "max" and "average" quality information which may or may not get used at various points. If you are using Relative values, then you need to compare the qual.level against the "max" quality level and the qual.noise against the "max" noise. Different drivers use different methods. So here's what we need to do: 1) DEFINE what quality mode drivers should use (ie Relative/Absolute). As in, all values MUST be in dBm (mandating percentages would deprive userspace of useful data) 2) ENSURE that drivers use consistent information between the iw_get_range()/iw_get_stats() calls and wireless scanning quality data 3) ENSURE that drivers don't use any magic numbers Dan From fedora at wir-sind-cool.org Thu Sep 16 17:28:25 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 16 Sep 2004 19:28:25 +0200 Subject: Questions about Mozilla RPMS ? In-Reply-To: <4149C8ED.40907@lanl.gov> References: <4149C8ED.40907@lanl.gov> Message-ID: <20040916192825.40e5b611.fedora@wir-sind-cool.org> On Thu, 16 Sep 2004 11:10:05 -0600, Stephen J Smoogen wrote: > I saw Warren has a test RPM for firefox-0.10, but havent seen anyone > attempt at thunderbird 0.8 or sunbird.. has anyone tried and is > currently failing or just not had time.. my attempts so far have been > less than even good. Since you've not mentioned this one, Thunderbird 0.8 https://bugzilla.fedora.us/show_bug.cgi?id=1765 I add it. Maybe you like to join... -- Fedora Core release 2 (Tettnang) - Linux 2.6.7-1.494.2.2 loadavg: 2.27 2.01 1.52 From dragoran at feuerpokemon.de Thu Sep 16 17:29:16 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 16 Sep 2004 19:29:16 +0200 Subject: Questions about Mozilla RPMS ? In-Reply-To: <4149C8ED.40907@lanl.gov> References: <4149C8ED.40907@lanl.gov> Message-ID: <4149CD6C.1080802@feuerpokemon.de> Stephen J Smoogen schrieb: > I saw Warren has a test RPM for firefox-0.10, but havent seen anyone > attempt at thunderbird 0.8 or sunbird.. has anyone tried and is > currently failing or just not had time.. my attempts so far have been > less than even good. > > > https://bugzilla.fedora.us/show_bug.cgi?id=1765 From dcbw at redhat.com Thu Sep 16 17:29:29 2004 From: dcbw at redhat.com (Dan Williams) Date: Thu, 16 Sep 2004 13:29:29 -0400 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <4149C303.102@bppiac.hu> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <1095344291.6173.15.camel@dcbw.boston.redhat.com> <4149A1D6.2040807@bppiac.hu> <1095346903.6173.22.camel@dcbw.boston.redhat.com> <4149C303.102@bppiac.hu> Message-ID: <1095355769.15587.4.camel@dcbw.boston.redhat.com> On Thu, 2004-09-16 at 18:44 +0200, Farkas Levente wrote: > mainstream kernel and _can't_ be part because of FCC etc. but it's still > can be shipped by fedora and can be supported by it's kernel (at leaset > a separate kernel module), where the "support" means you can help to fix Unfortunately, I don't think we can ship MADwifi due to the HAL. Does Debian ship it in debian-free? Because if they do, then Fedora will almost definitely be able to as well. Note that we don't ship Wireless driver firmware either due to legal issues. Dan From alan at redhat.com Thu Sep 16 17:35:13 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 16 Sep 2004 13:35:13 -0400 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <1095355769.15587.4.camel@dcbw.boston.redhat.com> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <1095344291.6173.15.camel@dcbw.boston.redhat.com> <4149A1D6.2040807@bppiac.hu> <1095346903.6173.22.camel@dcbw.boston.redhat.com> <4149C303.102@bppiac.hu> <1095355769.15587.4.camel@dcbw.boston.redhat.com> Message-ID: <20040916173513.GB13948@devserv.devel.redhat.com> On Thu, Sep 16, 2004 at 01:29:29PM -0400, Dan Williams wrote: > Unfortunately, I don't think we can ship MADwifi due to the HAL. Does > Debian ship it in debian-free? Because if they do, then Fedora will > almost definitely be able to as well. MAdwifi doesn't meet the free software requirements for Fedora, which isn't to say it can't be in a third party repository. Within the limits of their interpretation of the FCC rules and their hardware they've done about as much as they can however. From caillon at redhat.com Thu Sep 16 17:41:29 2004 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 16 Sep 2004 13:41:29 -0400 Subject: Questions about Mozilla RPMS ? In-Reply-To: <4149C8ED.40907@lanl.gov> References: <4149C8ED.40907@lanl.gov> Message-ID: <4149D049.2060008@redhat.com> Stephen J Smoogen wrote: > I saw Warren has a test RPM for firefox-0.10, but havent seen anyone > attempt at thunderbird 0.8 or sunbird.. has anyone tried and is > currently failing or just not had time.. my attempts so far have been > less than even good. I pushed the firefox update to rawhide as soon as it was released. Unfortunately, because of the impending test2 release, it has yet to propogate out to the masses. I'll push a thunderbird update tonight, but again, it might not be readily available for a bit. Sunbird is not going to be in core for now. Someone can have a go at it in extras if they want. From smoogen at lanl.gov Thu Sep 16 17:51:04 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Thu, 16 Sep 2004 11:51:04 -0600 Subject: Questions about Mozilla RPMS ? In-Reply-To: <4149D049.2060008@redhat.com> References: <4149C8ED.40907@lanl.gov> <4149D049.2060008@redhat.com> Message-ID: <4149D288.6070607@lanl.gov> Christopher Aillon wrote: > Stephen J Smoogen wrote: > >> I saw Warren has a test RPM for firefox-0.10, but havent seen anyone >> attempt at thunderbird 0.8 or sunbird.. has anyone tried and is >> currently failing or just not had time.. my attempts so far have been >> less than even good. > > > I pushed the firefox update to rawhide as soon as it was released. > Unfortunately, because of the impending test2 release, it has yet to > propogate out to the masses. I'll push a thunderbird update tonight, > but again, it might not be readily available for a bit. Sunbird is not > going to be in core for now. Someone can have a go at it in extras if > they want. > > Danke to everyone who has replied.. I should have looked at bugzilla first. -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From pekkas at netcore.fi Thu Sep 16 17:59:44 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 16 Sep 2004 20:59:44 +0300 (EEST) Subject: Wireless update to ifup and network-functions In-Reply-To: Message-ID: On Thu, 16 Sep 2004, Jon Nettleton wrote: > Very basically at this point. The last thing I do is change all the > spaces and -'s to underscores. I could probably expand that list to > include ,' and ;' and :s. I will add that to my next set of patches. > > Thanks for the input. It'll always be futile to try to look for illegal characters; there will always be some that are missed. Better just check that the ESSID is alphanumeric (or the like), and ignore otherwise. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From fedora at leemhuis.info Thu Sep 16 18:16:34 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 16 Sep 2004 20:16:34 +0200 Subject: RFC: ipw2100 and ip2200 packages (known as centrino-WLAN) Message-ID: <1095358594.2571.29.camel@localhost.localdomain> Hi *, I currently have two kernel-module-packages locally which contain the drivers for the ipw2[12]00 WLAN-Cards used in Centrino Notebooks. I'm currently a bit undecided were to submit them and in with form. My problem is the firmware that is needed by the driver in order to work. It has a special redistribution license. For details see: http://ipw2100.sourceforge.net/firmware.php?fid=3 http://ipw2200.sourceforge.net/firmware.php?fid=2 This is not acceptable for fedora.us (or fedora core) AFAICS (or am I wrong here?). It is AFAICS for livna.org (not sure). So I have the following options: 1. Submit the ipw2[12]00 packages and the needed firmwares both to livna.org 2a. Submit the drivers to fedora.us and the firmware to livna.org. But the driver can't require the firmwares in this case. Problematic. 2b. Submit the drivers to fedora.us and ignore the firmware. So the user needs to get the firmwares on it's own. I currently tend to 1., but I'd like to here comments from others (you!) on it. Thanks. CU thl P.S.: Yes, I know there is already a (currently outdated) ipw2100 package at: http://bugzilla.fedora.us/show_bug.cgi?id=1494 P.P.S.: Yes, atrpms also has a package AFAIK -- Thorsten Leemhuis From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Sep 16 18:31:26 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 16 Sep 2004 20:31:26 +0200 Subject: RFC: ipw2100 and ip2200 packages (known as centrino-WLAN) In-Reply-To: <1095358594.2571.29.camel@localhost.localdomain> References: <1095358594.2571.29.camel@localhost.localdomain> Message-ID: <20040916203126.5701b1d3@localhost> Thorsten Leemhuis wrote : > P.S.: Yes, I know there is already a (currently outdated) ipw2100 > package at: > http://bugzilla.fedora.us/show_bug.cgi?id=1494 > > P.P.S.: Yes, atrpms also has a package AFAIK Yup, and I have some for ipw2100 too, which use Thomasvs's autotools changes for kernel module packaging. I've also packaged the ipw2100-firmware which is directly available on freshrpms.net. All are easily found by typing "ipw2100" on rpmfind.net for instance ;-) http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/testing/2/kernel-modules/ External kernel modules are things I prefer touching with a 6 feet pole... but I do have an ipw2100 card in my laptop, so... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.84 1.12 1.17 From felipe_alfaro at linuxmail.org Thu Sep 16 19:02:48 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 16 Sep 2004 21:02:48 +0200 Subject: IPv6 and IPv4 resolver preferences Message-ID: <0033326B-0813-11D9-8450-000D9352858E@linuxmail.org> Hi! Now that, officially, IPv6 site-local addresses have been deprecated (RFC3879) and their use not recommended in new deployments, how will glibc resolve the preference problem that arises when both A and AAAA host records are defined for the same host? What will happen when both IPv4 and IPv6 addresses have different scopes (for example, the IPv4 address is private (e.g. 192.168.0.0/24), but the IPv6 is a global address (e.g. a 2000::/64)? Mac OS X seems to always prefer IPv6 addresses over IPv4 addresses, even when the scope of the IPv4 address is lower or nearer wrt the IPv6 address (i.e. site-local or private IPv4 vs a global IPv6). However, FC seems to implement the previous valid algorithm that took into account the scopes of both the IPv4 and IPv6 addresses when sorting the answer returned by the resolver. Will this change anytime soon? Any comments on this? Thanks! From linux_4ever at yahoo.com Thu Sep 16 19:58:22 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 16 Sep 2004 12:58:22 -0700 (PDT) Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <0033326B-0813-11D9-8450-000D9352858E@linuxmail.org> Message-ID: <20040916195822.46190.qmail@web50603.mail.yahoo.com> >Will this change anytime soon? Any comments on this? If you want IPv6 prefered over IPv4, go into /etc/resolv.conf and set options inet6 Does this help? -Steve Grubb _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From jon.nettleton at gmail.com Thu Sep 16 20:12:43 2004 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 16 Sep 2004 16:12:43 -0400 Subject: Wireless update to ifup and network-functions In-Reply-To: <1095340332.9144.2356.camel@imladris.demon.co.uk> References: <1095340332.9144.2356.camel@imladris.demon.co.uk> Message-ID: Is there any chance you could round up those patches for me? Now that most my friends and family have wireless, not having this functionality is really becoming a necessity for me. I am more than willing to spend the time to clean everything up and get it in shape until it meets peoples approval. -Jon On Thu, 16 Sep 2004 14:12:12 +0100, David Woodhouse wrote: > On Wed, 2004-09-15 at 11:02 -0400, Jon Nettleton wrote: > > If have put together a function and some new code for > > is_wireless_device that uses iwlist to scan available access points > > and then ifup a new configuration file if it finds one matching > > ifcfg-DEVICE_ESSID. My questions are. > > That's nice. I assume it selects the appropriate key based on the ESSID > it finds? > > A while ago I sent patches to Bill (and/or put them in Bugzilla) which > added Bluetooth networking support. I moved the tail end of ifup into > ifup-eth, then added an 'ifup-wireless' which calls that, as does > ifup-bnep. We no longer have to have the wireless (or bluetooth) stuff > hacked in to the middle of ifup that way. > > -- > dwmw2 > > From kyrre at solution-forge.net Thu Sep 16 20:50:24 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 16 Sep 2004 22:50:24 +0200 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095293369.3967.6.camel@dhollis-lnx.kpmg.com> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> <1095267986.30358.33.camel@dcbw.boston.redhat.com> <41489093.9000103@inet.com> <1095292097.4503.205.camel@hampton.eln.lan> <1095293369.3967.6.camel@dhollis-lnx.kpmg.com> Message-ID: <1095367823.2722.25.camel@kyrre> tor, 16.09.2004 kl. 02.09 skrev David Hollis: > On Thu, 2004-09-16 at 00:48 +0100, Stuart Ellis wrote: > > > > Perhaps the most basic question for an automatic sync is "is the link > > likely to disappear whilst I'm working ?" We can guess that links with > > certain qualities are bad (bandwidth too low, connection hasn't been > > available or stable for a period of x seconds, user specifies that that > > link should not be used for sync). > > > > We can't automatically tell when the user will want to disconnect the > > link themselves, so the concept of arranging completely automatic > > (rather than scheduled) backups may be problematic unless the backups > > can be safely broken up into small sets that can complete quickly. The > > Windows file sync software can automatically backup on login and > > logout. It drove me nuts that it would spend several minutes working > > through my entire home directory after I had decided that I wanted to > > switch off the laptop. > > > > Windows provides a good example of how it should not work. It needs to > be something can be performed in the backgroun and can be interrupted > and recover gracefully. And it shouldn't be triggered by login/logout. > Those are probably the times when the user wants it least. In the > morning they boot up and want to get into email/web whatever to start > getting stuff done. The last thing you need is the drive sitting there > chugging while it determines what it needs to sync. At logout, you're > heading home the for the day, trying to beat traffic, etc and the last > thing you want is to have to wait for that 650MB iso you just downloaded > to sync! > > > -- > David Hollis > Sounds kinda like the windows network at school - it has a 2-10 minutes login time - and a logout time which is something of the same. This is due to Windows dowloading the WHOLE profile - instead of the Unix model with hiden config file and the desktop as a folder. Makes quite a few use the Linux machines instead - they use 10 sec max - and that is when the server is under high load (it is one of the thick clients that was to old to run XP, no DMA support, while the windows guys got an Xeon with SCSI disks...), and using a slow machine (600 mhz celly/128 MB RAM running fc2). From kyrre at solution-forge.net Thu Sep 16 20:57:39 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 16 Sep 2004 22:57:39 +0200 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <1095343400.16808.4261.camel@jonspc> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <20040916113041.GA20759@devserv.devel.redhat.com> <1095343400.16808.4261.camel@jonspc> Message-ID: <1095368259.2722.28.camel@kyrre> tor, 16.09.2004 kl. 16.03 skrev Jonathan Andrews: > On Thu, 2004-09-16 at 12:30, Alan Cox wrote: > > On Thu, Sep 16, 2004 at 02:33:21AM +0100, Jonathan Andrews wrote: > > > distributions because for reasons purely political (as far as I can > > > tell???) the promisc mode was left on the cutting room floor !!! WHY > > > !!!! > > > > Promisc mode (on those adapters that support it) is actually rather > > complicated in the wireless world. A lot of the old prism firmware doesn't > > support it for example. OpenAP has to basically take over the h/w at a much > > lower level to handle that and that involves a native 802.11 stack - which > > oddly enough is the direction that stuff is going > > Cool :-) > > Monitor mode is optional as far as I understand it. Users will tolerate > a "your hardware wont do that message" more than a "please use xyz > wifi_the_bits_we_left_out.diff and recompile the kernel" ;-) > > I understand its a mess at the hardware level and having raw 802.11 will > be cool, but at the moment its getting messy. > > I find lots like this of threads like this > http://kerneltrap.org/node/view/3192 > http://kerneltrap.org/node/view/3245 > http://www.bastard.net/~kos/wifi/rfmon.html > > It would be nice to be able to use cool toys without building new kernel > or modules :-) Im sure that fedora will be on a lot of laptops, I know > its on mine - and wifi even works :-D > > Cheers, > Jon > > Mine to - i am writing this in evolution forwarded over SSH to my laptop via WLAN from my main machine - with the adm8211 driver :D From lfarkas at bppiac.hu Thu Sep 16 21:04:15 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Thu, 16 Sep 2004 23:04:15 +0200 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <20040916173513.GB13948@devserv.devel.redhat.com> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <1095344291.6173.15.camel@dcbw.boston.redhat.com> <4149A1D6.2040807@bppiac.hu> <1095346903.6173.22.camel@dcbw.boston.redhat.com> <4149C303.102@bppiac.hu> <1095355769.15587.4.camel@dcbw.boston.redhat.com> <20040916173513.GB13948@devserv.devel.redhat.com> Message-ID: <4149FFCF.4010604@bppiac.hu> Alan Cox wrote: > On Thu, Sep 16, 2004 at 01:29:29PM -0400, Dan Williams wrote: > >>Unfortunately, I don't think we can ship MADwifi due to the HAL. Does >>Debian ship it in debian-free? Because if they do, then Fedora will >>almost definitely be able to as well. > > > MAdwifi doesn't meet the free software requirements for Fedora, which isn't > to say it can't be in a third party repository. Within the limits of > their interpretation of the FCC rules and their hardware they've done about > as much as they can however. yes! and that's the point here, in this case no one can ship any driver for wireless devices with atheros chipset which is more free than madwifi. what is the solution (other than use other device:-)? -- Levente "Si vis pacem para bellum!" From jorton at redhat.com Thu Sep 16 21:18:19 2004 From: jorton at redhat.com (Joe Orton) Date: Thu, 16 Sep 2004 22:18:19 +0100 Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <20040916195822.46190.qmail@web50603.mail.yahoo.com> References: <0033326B-0813-11D9-8450-000D9352858E@linuxmail.org> <20040916195822.46190.qmail@web50603.mail.yahoo.com> Message-ID: <20040916211819.GA19834@redhat.com> On Thu, Sep 16, 2004 at 12:58:22PM -0700, Steve G wrote: > >Will this change anytime soon? Any comments on this? > > If you want IPv6 prefered over IPv4, go into /etc/resolv.conf and set > > options inet6 You really don't want to do that, Dave -- it breaks applications using gethostbyname() e.g. /bin/ping. joe From grmoc at yahoo.com Thu Sep 16 21:52:20 2004 From: grmoc at yahoo.com (Roberto Peon) Date: Thu, 16 Sep 2004 17:52:20 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095367823.2722.25.camel@kyrre> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <1095293369.3967.6.camel@dhollis-lnx.kpmg.com> <1095367823.2722.25.camel@kyrre> Message-ID: <200409161752.20293.grmoc@yahoo.com> On Thursday 16 September 2004 04:50 pm, Kyrre Ness Sjobak wrote: > tor, 16.09.2004 kl. 02.09 skrev David Hollis: > > On Thu, 2004-09-16 at 00:48 +0100, Stuart Ellis wrote: > > > Perhaps the most basic question for an automatic sync is "is the link > > > likely to disappear whilst I'm working ?" We can guess that links > > > with certain qualities are bad (bandwidth too low, connection hasn't > > > been available or stable for a period of x seconds, user specifies that > > > that link should not be used for sync). > > > > > > We can't automatically tell when the user will want to disconnect the > > > link themselves, so the concept of arranging completely automatic > > > (rather than scheduled) backups may be problematic unless the backups > > > can be safely broken up into small sets that can complete quickly. The > > > Windows file sync software can automatically backup on login and > > > logout. It drove me nuts that it would spend several minutes working > > > through my entire home directory after I had decided that I wanted to > > > switch off the laptop. > > > > Windows provides a good example of how it should not work. It needs to > > be something can be performed in the backgroun and can be interrupted > > and recover gracefully. And it shouldn't be triggered by login/logout. > > Those are probably the times when the user wants it least. In the > > morning they boot up and want to get into email/web whatever to start > > getting stuff done. The last thing you need is the drive sitting there > > chugging while it determines what it needs to sync. At logout, you're > > heading home the for the day, trying to beat traffic, etc and the last > > thing you want is to have to wait for that 650MB iso you just downloaded > > to sync! > > > > > > -- > > David Hollis > > Sounds kinda like the windows network at school - it has a 2-10 minutes > login time - and a logout time which is something of the same. This is > due to Windows dowloading the WHOLE profile - instead of the Unix model > with hiden config file and the desktop as a folder. Makes quite a few > use the Linux machines instead - they use 10 sec max - and that is when > the server is under high load (it is one of the thick clients that was > to old to run XP, no DMA support, while the windows guys got an Xeon > with SCSI disks...), and using a slow machine (600 mhz celly/128 MB RAM > running fc2). Could we build a files-changed journal using dnotify or FAM, in order to get rid of the scanning time? Ideally, you would know which parts of the file(s) were updated, and only ship those parts, but dnotify and FAM don't have that level of specificity, If we took this approach, then we'd have a near-optimal update time. The merge problem, of course, still exists, but it will -always- exist unless you update from the server on login and to the server on logout. -R From jon.nettleton at gmail.com Thu Sep 16 22:04:47 2004 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 16 Sep 2004 18:04:47 -0400 Subject: Wireless update to ifup and network-functions In-Reply-To: References: <1095340332.9144.2356.camel@imladris.demon.co.uk> Message-ID: Make that having this functionality is really becoming a necessity, or not having this functionality is really becoming a nuisance to me. Not to self, "Must remember to reread before hitting the send button. :-) Jon On Thu, 16 Sep 2004 16:12:43 -0400, Jon Nettleton wrote: > Is there any chance you could round up those patches for me? Now that > most my friends and family have wireless, not having this > functionality is really becoming a necessity for me. I am more than > willing to spend the time to clean everything up and get it in shape > until it meets peoples approval. > > -Jon > > > > On Thu, 16 Sep 2004 14:12:12 +0100, David Woodhouse wrote: > > On Wed, 2004-09-15 at 11:02 -0400, Jon Nettleton wrote: > > > If have put together a function and some new code for > > > is_wireless_device that uses iwlist to scan available access points > > > and then ifup a new configuration file if it finds one matching > > > ifcfg-DEVICE_ESSID. My questions are. > > > > That's nice. I assume it selects the appropriate key based on the ESSID > > it finds? > > > > A while ago I sent patches to Bill (and/or put them in Bugzilla) which > > added Bluetooth networking support. I moved the tail end of ifup into > > ifup-eth, then added an 'ifup-wireless' which calls that, as does > > ifup-bnep. We no longer have to have the wireless (or bluetooth) stuff > > hacked in to the middle of ifup that way. > > > > -- > > dwmw2 > > > > > From felipe_alfaro at linuxmail.org Thu Sep 16 22:10:11 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Fri, 17 Sep 2004 00:10:11 +0200 Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <20040916195822.46190.qmail@web50603.mail.yahoo.com> References: <20040916195822.46190.qmail@web50603.mail.yahoo.com> Message-ID: <2DC892A7-082D-11D9-8450-000D9352858E@linuxmail.org> On 16/09/2004, at 21:58, Steve G wrote: > >> Will this change anytime soon? Any comments on this? > > If you want IPv6 prefered over IPv4, go into /etc/resolv.conf and set > > options inet6 > > Does this help? No, it doesn't. Although the glibc resolver asks first for the AAAA host record, the results returned to the client still map the IPv4 in first place. In fact, the resolver behaves erratically. My scenario: I have a client computer named hostA, and a server computer named hostB. hostB has a IPv4 A RR (resolves to 192.168.0.1) and a IPv6 AAAA RR (resolves to 2000::1). When client hostA tries telnetting hostB, this is what ethereal records if "options inet6" is set in "/etc/resolv.conf": from hostA to nameserver, standard query AAAA hostB from nameserver to hostA, standard query response AAAA 2000::1 from hostA to nameserver, standard query A hostB from nameserver to hostA, standard query response A 192.168.0.1 from hostA to nameserver, standard query A hostB from nameserver to hostA, standard query response A 192.168.0.1 from hostA to nameserver, standard query AAAA hostB from nameserver to hostA, standard query response AAAA 2000::1 from hostA to hostB(192.168.0.1), 32805 > telnet [SYN] Seq=0 Ack=0 Win=5840... As you can see, the hostA resolver is querying twice for A and AAAA RR, which seems completely strange. And this is what ethereal reveals if "options inet6" IS NOT set in "/etc/resolv.conf": from hostA to nameserver, standard query AAAA hostB from nameserver to hostA, standard query response AAAA 2000::1 from hostA to nameserver, standard query A hostB from nameserver to hostA, standard query response A 192.168.0.1 from hostA to nameserver, standard query A hostB from nameserver to hostA, standard query response A 192.168.0.1 from hostA to nameserver, standard query A hostB from nameserver to hostA, standard query response A 192.168.0.1 from hostA to hostB(192.168.0.1), 32806 > telnet [SYN] Seq=0 Ack=0 Win=5840... This time, the resolver is querying three times for the A RR of host B. Also, the telnet connection is done against the IPv4 address, and not the IPv6 address as I expected. What's going on here? From linux_4ever at yahoo.com Thu Sep 16 22:21:49 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 16 Sep 2004 15:21:49 -0700 (PDT) Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <2DC892A7-082D-11D9-8450-000D9352858E@linuxmail.org> Message-ID: <20040916222149.2066.qmail@web50603.mail.yahoo.com> >What's going on here? You told me everything except what you typed on the command line. :) I'm guessing that you typed a name and not a number, so the application looked it up and found multiple records. The application can also set a hint as to what address family to return. The default is in /etc/resolv.conf. If a query returns multiple records, the application must walk through the list and use the right one. I found this out a couple years ago when I was working on xinetd's IPv6 code. While dns queries may work OK, the applications may be broken as Joe suggested. I use IPv6 pretty regular and haven't noticed problems. I'll play with it some more, too. -Steve Grubb _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From jon at jonshouse.co.uk Thu Sep 16 22:31:34 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Thu, 16 Sep 2004 23:31:34 +0100 Subject: Direction of wireless networking in Fedora ( was RE: Wireless update to ifup and network-functions ) In-Reply-To: <4149FFCF.4010604@bppiac.hu> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <1095344291.6173.15.camel@dcbw.boston.redhat.com> <4149A1D6.2040807@bppiac.hu> <1095346903.6173.22.camel@dcbw.boston.redhat.com> <4149C303.102@bppiac.hu> <1095355769.15587.4.camel@dcbw.boston.redhat.com> <20040916173513.GB13948@devserv.devel.redhat.com> <4149FFCF.4010604@bppiac.hu> Message-ID: <1095373894.16808.4296.camel@jonspc> On Thu, 2004-09-16 at 22:04, Farkas Levente wrote: > Alan Cox wrote: > > On Thu, Sep 16, 2004 at 01:29:29PM -0400, Dan Williams wrote: > > > >>Unfortunately, I don't think we can ship MADwifi due to the HAL. Does > >>Debian ship it in debian-free? Because if they do, then Fedora will > >>almost definitely be able to as well. > > > > > > MAdwifi doesn't meet the free software requirements for Fedora, which isn't > > to say it can't be in a third party repository. Within the limits of > > their interpretation of the FCC rules and their hardware they've done about > > as much as they can however. > > yes! and that's the point here, in this case no one can ship any driver > for wireless devices with atheros chipset which is more free than > madwifi. what is the solution (other than use other device:-)? Im not saying its easy !!! but couldn't we errrr reverse engineer the firmware ? :-) Does anyone know is the firmware just the control part of the protocol stack or is it the full modulator demodulator for the waveforms on the atheros ? Jon From felipe_alfaro at linuxmail.org Thu Sep 16 23:02:41 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Fri, 17 Sep 2004 01:02:41 +0200 Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <20040916222149.2066.qmail@web50603.mail.yahoo.com> References: <20040916222149.2066.qmail@web50603.mail.yahoo.com> Message-ID: <82D75976-0834-11D9-8450-000D9352858E@linuxmail.org> On Sep 17, 2004, at 00:21, Steve G wrote: > >> What's going on here? > > You told me everything except what you typed on the command line. :) I typed "telnet hostB" :-) Note this is the "telnet" client from package "krb5-workstation" (not the actual telnet command that is used in non-Kerberized FC installations), which is located in "/usr/kerberos/biin/telnet". > I'm guessing that you typed a name and not a number, so the > application looked it > up and found multiple records. The application can also set a hint as > to what > address family to return. The default is in /etc/resolv.conf. > > If a query returns multiple records, the application must walk through > the list > and use the right one. I found this out a couple years ago when I was > working on > xinetd's IPv6 code. > > While dns queries may work OK, the applications may be broken as Joe > suggested. I > use IPv6 pretty regular and haven't noticed problems. I'll play with > it some > more, too. It could be. Maybe "telnet" from "krb5-workstation" is broken, as "ssh" seems to work correctly: it gives automatic preference to IPv6 over IPv4, even when "options inet6" is *not* set in "/etc/resolv.conf". From drepper at redhat.com Fri Sep 17 00:11:21 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Thu, 16 Sep 2004 17:11:21 -0700 Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <2DC892A7-082D-11D9-8450-000D9352858E@linuxmail.org> References: <20040916195822.46190.qmail@web50603.mail.yahoo.com> <2DC892A7-082D-11D9-8450-000D9352858E@linuxmail.org> Message-ID: <414A2BA9.4020604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Felipe Alfaro Solana wrote: > from hostA to nameserver, standard query AAAA hostB > from nameserver to hostA, standard query response AAAA 2000::1 > from hostA to nameserver, standard query A hostB > from nameserver to hostA, standard query response A 192.168.0.1 > from hostA to nameserver, standard query A hostB > from nameserver to hostA, standard query response A 192.168.0.1 > from hostA to nameserver, standard query AAAA hostB > from nameserver to hostA, standard query response AAAA 2000::1 > from hostA to hostB(192.168.0.1), 32805 > telnet [SYN] Seq=0 Ack=0 > Win=5840... > > As you can see, the hostA resolver is querying twice for A and AAAA RR, > which seems completely strange. It's not strange at all. The second set of lookups is for the canonical host name. Anyway, all this is mood with the current glibc code. Once you get 2.3.3-53 or higher, try it again. And IPv6 addresses are always looked but if requested and there is an IPv6 interface defined on your system. If you don't want any IPv6 lookups, remove all IPv6 interfaces. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBSiup2ijCOnn/RHQRAsO4AJ4z4GTikO7wF/lkXE0I+3Pz3y0iVQCghRvV Wa/xTXEBZc8HVsdshKAMfv4= =hfr1 -----END PGP SIGNATURE----- From Nicolas.Mailhot at laPoste.net Thu Sep 16 08:11:25 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 16 Sep 2004 10:11:25 +0200 Subject: [JPackage-discuss] User jonas In-Reply-To: <414944AF.30504@redhat.com> References: <20040915142709.GB13443@chomsky.suse.de> <414944AF.30504@redhat.com> Message-ID: <1095322285.8726.14.camel@ulysse> Le jeudi 16 septembre 2004 ? 09:45 +0200, Fernando Nasser a ?crit : > Hi, > > This is indeed a good point. I will take it to the jonas community. > > In the meanwhile, please note that the ascii display name of users and groups is > irrelevant. At the inner level Unix is all about numbers. Just rename your > group and user from jonas to jonasrun (or something elese you like) and all will > be well (as long as you don't change the numbers) -- at least until you try > and update... > > It is possible that you run into problems when updating the RPM., as the RPM > will try and install a user called jonas again. If this change is accepted > upstream, then I will add mechanisms for backward compatibility in the RPM scripts. However the problem also exists for amanda for example so before changing jonas a (semi) official RH/Suse/Mdk policy on allowed system user names would be nice (CC-ing fedora-devel) Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pekkas at netcore.fi Fri Sep 17 05:14:36 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 17 Sep 2004 08:14:36 +0300 (EEST) Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <0033326B-0813-11D9-8450-000D9352858E@linuxmail.org> Message-ID: On Thu, 16 Sep 2004, Felipe Alfaro Solana wrote: > What will happen when both > IPv4 and IPv6 addresses have different scopes (for example, the IPv4 > address is private (e.g. 192.168.0.0/24), but the IPv6 is a global > address (e.g. a 2000::/64)? > > Mac OS X seems to always prefer IPv6 addresses over IPv4 addresses, > even when the scope of the IPv4 address is lower or nearer wrt the IPv6 > address (i.e. site-local or private IPv4 vs a global IPv6). However, FC > seems to implement the previous valid algorithm that took into account > the scopes of both the IPv4 and IPv6 addresses when sorting the answer > returned by the resolver. See RFC 3484, glibc should be implementation destination address selection (not sure if it's actually done), and the kernel is doing source address selection. This depends on what kind of source and destination address candidates you have. In short, if matching scope is found (e.g., global v6 source, global v6 destination, or private v4 address source/dest), that's preferable. But if the scopes don't match, it's typically down to "precedence" (v6 is better than v4 by default) or smallest scope. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From tjarls at iee.lu Fri Sep 17 08:24:06 2004 From: tjarls at iee.lu (Charles Lopes) Date: Fri, 17 Sep 2004 10:24:06 +0200 Subject: Wireless update to ifup and network-functions In-Reply-To: <1095340332.9144.2356.camel@imladris.demon.co.uk> References: <1095340332.9144.2356.camel@imladris.demon.co.uk> Message-ID: <414A9F26.5050300@iee.lu> David Woodhouse wrote: >That's nice. I assume it selects the appropriate key based on the ESSID >it finds? > >A while ago I sent patches to Bill (and/or put them in Bugzilla) which >added Bluetooth networking support. I moved the tail end of ifup into >ifup-eth, then added an 'ifup-wireless' which calls that, as does >ifup-bnep. We no longer have to have the wireless (or bluetooth) stuff >hacked in to the middle of ifup that way. > > Splitting out ethernet stuff to ifup-eth sounds like a good idea IMHO. I'm trying to add support for WAN cards (only using the generic hdlc stack and sethdlc at the moment) and I was considering doing the same. The ethernet code is already framed by a "if" statement anyway, splitting it out would just improve readability and consistancy of the ifup/down scripts. Charles -- Charles Lopes Assistant IT Manager IEE SA Luxembourg Tel: +352 424737-515 Fax: +352 424737-200 This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you are not the intended recipient and have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal from your system. Thank you for your co-operation. From felipe_alfaro at linuxmail.org Fri Sep 17 09:46:49 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Fri, 17 Sep 2004 11:46:49 +0200 Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <414A2BA9.4020604@redhat.com> References: <20040916195822.46190.qmail@web50603.mail.yahoo.com> <2DC892A7-082D-11D9-8450-000D9352858E@linuxmail.org> <414A2BA9.4020604@redhat.com> Message-ID: <7F17ED15-088E-11D9-A94E-000D9352858E@linuxmail.org> On Sep 17, 2004, at 02:11, Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Felipe Alfaro Solana wrote: > >> from hostA to nameserver, standard query AAAA hostB >> from nameserver to hostA, standard query response AAAA 2000::1 >> from hostA to nameserver, standard query A hostB >> from nameserver to hostA, standard query response A 192.168.0.1 >> from hostA to nameserver, standard query A hostB >> from nameserver to hostA, standard query response A 192.168.0.1 >> from hostA to nameserver, standard query AAAA hostB >> from nameserver to hostA, standard query response AAAA 2000::1 >> from hostA to hostB(192.168.0.1), 32805 > telnet [SYN] Seq=0 Ack=0 >> Win=5840... >> >> As you can see, the hostA resolver is querying twice for A and AAAA >> RR, >> which seems completely strange. > > It's not strange at all. The second set of lookups is for the > canonical > host name. I think I don't understand you. When running "telnet computer1" and looking at the packets captured by Ethereal, I can see _exactly_ four queries, all of them asking for the RR host record of "computer1.mydomain.com", that is, four queries asking for the same FQDN. Of the four queries, the first one asks for the AAAA RR, while the remaining three ask for the A RR. These three AA RR queries are all identical (except in the Transaction ID field). Thus, I don't understand why the resolver is simply asking three times for the A RR. Even if the resolver does not make any difference between FQDNs and non-FQDNs, I think this can be optimized a little, and simplify it to just, at most, two queries. Isn't this reasonable? > > Anyway, all this is mood with the current glibc code. Once you get > 2.3.3-53 or higher, try it again. > > > And IPv6 addresses are always looked but if requested and there is an > IPv6 interface defined on your system. If you don't want any IPv6 > lookups, remove all IPv6 interfaces. In my case, it's just the other way around. I DO want IPv6 queries, and I DO want IPv6 to always have precedence over IPv4. Anyways, I'll get glibc-2.3.3-53 as soon as it's available. Thanks! From buildsys at redhat.com Fri Sep 17 11:53:24 2004 From: buildsys at redhat.com (Build System) Date: Fri, 17 Sep 2004 07:53:24 -0400 Subject: rawhide report: 20040917 changes Message-ID: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> Removed package raidtools Updated Packages: ImageMagick-6.0.7.1-3 --------------------- * Tue Sep 14 2004 Karsten Hopp 6.0.7.1-3 - move *.mgk files (#132007, #131708, #132397) * Sun Sep 12 2004 Karsten Hopp 6.0.7.1-1 - update to 6.0.7 Patchlevel 1, fixes #132106 MAKEDEV-3.13-1 -------------- * Tue Sep 14 2004 Nalin Dahyabhai 3.13-1 - excise all architecture-specific logic and configuration data -- udev knows no arch-specific details, so they should be irrelevant now - remove build conflicts on older RPM, unnecessary now that dev is gone - remove dev's %post fstab munging - add a short-circuit test for the common non-match cases * Tue Sep 14 2004 Jeremy Katz - 3.12.2-1 - add the vcsa user and floppy group in the MAKEDEV package now * Mon Sep 13 2004 Nalin Dahyabhai 3.12.1-1 - nuke the "dev" subpackage NetworkManager-0.2-3 -------------------- * Mon Sep 13 2004 Dan Williams 0.2-3 - Update from CVS anaconda-10.0.2-4 ----------------- * Mon Sep 13 2004 Jeremy Katz - 10.0.2-4 - add patch for system without a dev package - add patch to fix syntax of mdadm.conf * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode arts-1.3.0-4 ------------ * Wed Sep 15 2004 Than Ngo 1.3.0-4 - fix multilib problem #132576 authconfig-4.6.4-3 ------------------ * Mon Sep 13 2004 Jindrich Novy 4.6.4-3 - corrected package dependencies #132411 - regenerated glade.strings.h #132369 compat-db-4.1.25-5 ------------------ * Mon Sep 13 2004 Bill Nottingham - return of db1 to compat-db - remove: db-3.1, db-3.2 - remove: c++, tcl sublibraries dasher-3.2.11-3 --------------- * Tue Sep 14 2004 GNOME - 3.2.11-3 - fix schemas file and crasher. desktop-backgrounds-2.0-23 -------------------------- * Thu Sep 09 2004 Elliot Lee 2.0-23 - Really update the default background. * Wed Jul 07 2004 Elliot Lee 2.0-21 - Change background for FC3test1 * Thu May 06 2004 Jeremy Katz - 2.0-20 - background from Garrett for FC2 desktop-file-utils-0.8-2 ------------------------ * Mon Sep 13 2004 Dan Williams 0.8-2 - Fix RH #131983 (annoying log message about "entries != NULL") dhcpv6-0.10-6 ------------- * Mon Sep 13 2004 Jason Vas Dias - 0.10-6 - fix bug 132468 for bug 125712: invoke change_resolv_conf * Mon Sep 13 2004 Bill Nottingham - 0.10-5 - don't run by default - add chkconfig prereqs, postun script, etc. exim-4.42-2 ----------- * Mon Sep 13 2004 Thomas Woerner 4.42-2 - update to sa-exim-4.1: fixes spamassassin's new score= string (#131796) glibc-2.3.3-53 -------------- * Tue Sep 14 2004 Jakub Jelinek 2.3.3-53 - restore temporarily old definition of __P()/__PMT() for third party apps * Tue Sep 14 2004 Jakub Jelinek 2.3.3-52 - update from CVS - nscd bi-arch fix - remove all uses of __P()/__PMT() from glibc headers - update and reenable nscd SELinux patch - remove libnss1* and libnss*.so.1 compatibility NSS modules on IA-32, SPARC and Alpha gnome-libs-1.4.1.2.90-43 ------------------------ * Mon Sep 13 2004 Bill Nottingham 1.4.1.2.90-43 - don't package db1 libs gnome-speech-0.3.5-2 -------------------- * Tue Sep 14 2004 GNOME - 0.3.5-2 - require festival, as we're useless without it gtk2-2.4.9-8 ------------ * Mon Sep 13 2004 Matthias Clasen - 2.4.9-8 - bring expanders back to their old size hwdata-0.131-1 -------------- * Thu Sep 09 2004 Kristian H??gsberg 0.131-1 - Add pci ids and cards for new ATI, NVIDIA and Intel cards jwhois-3.2.2-6 -------------- * Mon Sep 13 2004 Miloslav Trmac - 3.2.2-6 - Recognize more redirections at whois.arin.net (#116423) * Mon Sep 13 2004 Miloslav Trmac - 3.2.2-5 - Update config file for .de (#132362, by Robert Scheck) libselinux-1.17.12-1 -------------------- * Tue Sep 14 2004 Dan Walsh 1.17.12-1 - Update from NSA * Add matchmediacon * Tue Sep 14 2004 Dan Walsh 1.17.11-1 - Update from NSA * Merged in matchmediacon changes. * Fri Sep 10 2004 Dan Walsh 1.17.10-1 - Update from NSA * Regenerated headers for new nscd permissions. net-snmp-5.1.2-6 ---------------- * Wed Sep 15 2004 Phil Knirsch 5.1.2-6 - Split out libs package for multilib compatibility pam-0.77-56 ----------- * Mon Sep 13 2004 Jindrich Novy - rebuilt * Mon Sep 13 2004 Tomas Mraz 0.77-56 - #75454 fixed locking when changing password - #127054 - #125653 removed unnecessary getgrouplist call - #124979 added quiet option to pam_succeed_if * Mon Aug 30 2004 Warren Togami 0.77-55 - #126024 /dev/pmu console perms policycoreutils-1.17.5-2 ------------------------ * Thu Sep 09 2004 Dan Walsh 1.17.5-2 - Add Steve Grubb patch to cleanup log files. qt-3.3.3-5 ---------- * Tue Sep 14 2004 Than Ngo 1:3.3.3-4 - update new immodule patch - fix multilib problem #132516 rpmdb-fedora-2.91-0.20040917 ---------------------------- samba-3.0.7-3 ------------- * Mon Sep 13 2004 Jay Fenlason 3.0.7-3 - Upgrade to 3.0.7, which fixes CAN-2004-0807 CAN-2004-0808 This obsoletes the 3.0.6-schema patch. - Update BuildRequires line to include openldap-devel openssl-devel and cups-devel selinux-policy-strict-1.17.16-2 ------------------------------- * Wed Sep 15 2004 Dan Walsh 1.17.16-2 - Cleanup patch * Wed Sep 15 2004 Dan Walsh 1.17.16-1 - Update to match NSA Policy - Added proc_fs attributes * Tue Sep 14 2004 Dan Walsh 1.17.15-3 - More nscd fixes selinux-policy-targeted-1.17.16-2 --------------------------------- * Wed Sep 15 2004 Dan Walsh 1.17.16-2 - Cleanup patch * Wed Sep 15 2004 Dan Walsh 1.17.16-1 - Update to match NSA Policy - Added proc_fs attributes * Tue Sep 14 2004 Dan Walsh 1.17.15-3 - More nscd fixes sysreport-1.3.13-1 ------------------ * Mon Sep 13 2004 Than Ngo 1.3.13-1 - add support dkms #122194 - get rid of dmidecode system-config-packages-1.2.16-2 ------------------------------- * Tue Sep 14 2004 Jeremy Katz - 1.2.16-2 - fix invocation of update-desktop-database to have the right path * Mon Sep 13 2004 Jeremy Katz - 1.2.16-1 - call update-desktop-database in %post * Mon Sep 13 2004 Jeremy Katz - 1.2.15-1 - can't require comps, that breaks during installation - don't traceback on headless (#132241) - update for new MIME setup - replace & with & (#131523) system-config-users-1.2.18-1 ---------------------------- * Mon Sep 13 2004 Nils Philippsen - 1.2.18-1 - use F1 instead of Ctrl+H as accelerator for Help/Contents (#132163) - use "mkdir -p" to fix make install glitch - use absolute paths in *.glade to fix pygtk/pyglade subtleties * Sun Sep 05 2004 Nils Philippsen - 1.2.15-1 - add manpage (Chris Spencer, #115316) system-logviewer-0.9.8-1 ------------------------ * Fri Sep 10 2004 Paul Nasrat 0.9.8-1 - Deprecated methods - i18n desktop tftp-0.38-1 ----------- * Mon Sep 13 2004 Elliot Lee 0.38-1 - Update to new version fixes #131736 udev-030-26 ----------- * Mon Sep 13 2004 Jeremy Katz - 030-26 - require a 2.6 kernel - prereq instead of requires MAKEDEV - obsolete and provide dev - add a trigger for the removal of /dev so that we set things up * Fri Sep 10 2004 Dan Walsh - 030-25 - Use matchmediacon umb-scheme-3.2-35 ----------------- * Mon Sep 13 2004 Jindrich Novy - regenerated slibcat for slib 3a1 (#132290) up2date-4.3.38-1.1 ------------------ * Wed Sep 15 2004 Adrian Likins 4.3.38 - fix a error with accounts with no entitlements that try to use them anyway * Tue Sep 14 2004 Adrian Likins 4.3.37 - more firstboot flow issues - even more firstboot registration fixes - now with 30% more firstboot registration flow fixes - new high protein low card firstboot short username fixes - work around a server bug with entitlement issues * Mon Sep 13 2004 Adrian Likins 4.3.31 - fixes for #132475, #132473, #132472 (firstboot flow issues) usbutils-0.11-6.1 ----------------- * Mon Sep 13 2004 Thomas Woerner 0.11-6.1 - added missing BuildRequires for libtool (#132406) xfig-3.2.4-5 ------------ * Mon Sep 13 2004 Than Ngo 3.2.4-5 - fix desktop file #131983 xorg-x11-6.8.0-4 ---------------- * Tue Sep 14 2004 Bill Nottingham - 6.8.0-4 - buildrequire redhat-rpm-config, use brp-compress from that (fixes file conflicts) * Mon Sep 13 2004 Kristian H??gsberg - 6.8.0-3 - Fix typo in test for xorg.conf (#127711). * Mon Sep 13 2004 Kristian H??gsberg - 6.8.0-2 - Add with_wacom_driver option and set it to 0 (#132438, #132440). zlib-1.2.1.2-1 -------------- * Sun Sep 12 2004 Jeff Johnson 1.2.1.2-1 - update to 1.2.1.2 to fix 2 DoS problems (#131385). From dwmw2 at infradead.org Fri Sep 17 12:42:00 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 17 Sep 2004 13:42:00 +0100 Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <0033326B-0813-11D9-8450-000D9352858E@linuxmail.org> References: <0033326B-0813-11D9-8450-000D9352858E@linuxmail.org> Message-ID: <1095424919.17821.10.camel@hades.cambridge.redhat.com> On Thu, 2004-09-16 at 21:02 +0200, Felipe Alfaro Solana wrote: > Hi! > > Now that, officially, IPv6 site-local addresses have been deprecated > (RFC3879) and their use not recommended in new deployments, how will > glibc resolve the preference problem ... > > Will this change anytime soon? Any comments on this? I assume you'd prefer comments more helpful than 'AAARGH I was hoping sanity would prevail and site-local addresses wouldn't get deprecated'? -- dwmw2 From dwmw2 at infradead.org Fri Sep 17 13:12:37 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 17 Sep 2004 14:12:37 +0100 Subject: Wireless update to ifup and network-functions In-Reply-To: References: <1095340332.9144.2356.camel@imladris.demon.co.uk> Message-ID: <1095426757.17821.73.camel@hades.cambridge.redhat.com> On Thu, 2004-09-16 at 16:12 -0400, Jon Nettleton wrote: > Is there any chance you could round up those patches for me? It probably doesn't work well as a _patch_ since there'll be conflicts as soon as one line in the part which we remove from ifup and put into ifup-eth gets changed. But here it is anyway... -- dwmw2 -------------- next part -------------- An embedded message was scrubbed... From: David Woodhouse Subject: RFC: Splitting ifup into ifup/ifup-eth, Bluetooth networking. Date: Mon, 31 May 2004 09:56:01 +0100 Size: 32588 URL: From csm at redhat.com Fri Sep 17 13:25:40 2004 From: csm at redhat.com (Chuck Mead) Date: Fri, 17 Sep 2004 09:25:40 -0400 Subject: Wireless update to ifup and network-functions In-Reply-To: <414A9F26.5050300@iee.lu> References: <1095340332.9144.2356.camel@imladris.demon.co.uk> <414A9F26.5050300@iee.lu> Message-ID: <414AE5D4.3080102@redhat.com> Charles Lopes wrote: > David Woodhouse wrote: > >> That's nice. I assume it selects the appropriate key based on the ESSID >> it finds? >> A while ago I sent patches to Bill (and/or put them in Bugzilla) which >> added Bluetooth networking support. I moved the tail end of ifup into >> ifup-eth, then added an 'ifup-wireless' which calls that, as does >> ifup-bnep. We no longer have to have the wireless (or bluetooth) stuff >> hacked in to the middle of ifup that way. >> >> > Splitting out ethernet stuff to ifup-eth sounds like a good idea IMHO. > I'm trying to add support for WAN cards (only using the generic hdlc > stack and sethdlc at the moment) and I was considering doing the same. > The ethernet code is already framed by a "if" statement anyway, > splitting it out would just improve readability and consistancy of the > ifup/down scripts. > Doubtless this has already been thought of and discarded but I just wanted to make the comment that there may be lots of stuff on peoples machines that depends on ifup. I know I have written scripts and lots of other stuff over the years that used this script. So if we're going to make changes to support wireless better then why not leave ifup alone and call the wireless script "wifup"? -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" From harald at redhat.com Fri Sep 17 13:32:06 2004 From: harald at redhat.com (Harald Hoyer) Date: Fri, 17 Sep 2004 15:32:06 +0200 Subject: Traffic shaping broken with kernel errata In-Reply-To: <10F77558C46ECE00B809F13A@[10.169.6.246]> References: <20040811042347.GA1221392@hiwaay.net> <1092257150.4813.26.camel@athlon.localdomain> <20040811210302.GC1367132@hiwaay.net> <10F77558C46ECE00B809F13A@[10.169.6.246]> Message-ID: <414AE756.4080803@redhat.com> Kenneth Porter wrote: > Tip: If you use sendmail on your mailbox server, use a plussed address > when subscribing to systems that don't obfuscate your address in their > archives. You can then use a procmail recipe to filter stuff using that > address to a separate folder, and make it easier to track what archive a > spammer is harvesting addresses from. For example: > > shiva+fedora_dev_plussed_example at sewingwitch.com and intelligent robots can remove everything between + and @ also... From fedora at wir-sind-cool.org Fri Sep 17 13:38:35 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 17 Sep 2004 15:38:35 +0200 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <604aa7910409151231619a8244@mail.gmail.com> References: <4B134FE6AC994B4C99B4D74A8E9EB6591D9752@smith.interlink.local> <1095275591.29577.11.camel@dhollis-lnx.kpmg.com> <604aa7910409151231619a8244@mail.gmail.com> Message-ID: <20040917153835.0338ddeb.fedora@wir-sind-cool.org> On Wed, 15 Sep 2004 15:31:15 -0400, Jeff Spaleta wrote: > cough rdiff-backup > cough librsync based > cough python based... like all good system-config tools should be :-> > http://rdiff-backup.stanford.edu/ > or if you dont want the "mirror" aspects and want a little more privacy > http://www.nongnu.org/duplicity/ $ rpm -q rdiff-backup librsync rdiff-backup-0.12.6-0.fdr.1.2 librsync-0.9.6-0.fdr.5.2 ... availability of those rpms at fedora.us should make evaluation even easier. From jorton at redhat.com Fri Sep 17 13:51:52 2004 From: jorton at redhat.com (Joe Orton) Date: Fri, 17 Sep 2004 14:51:52 +0100 Subject: certwatch: SSL certificate expiry warning tool Message-ID: <20040917135152.GA8655@redhat.com> The latest version of the crypto-utils package in Raw Hide includes certwatch(1), which can be used to check whether an X.509 certificate has expired or is about to expire, and issue warning messages as necessary. It's implemented in /etc/cron.daily/certwatch to, by default, check all certificates configured in the mod_ssl configuration, but this can be extended to any other services which use SSL certificates. Regards, joe From jon.nettleton at gmail.com Fri Sep 17 13:58:59 2004 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 17 Sep 2004 09:58:59 -0400 Subject: Wireless update to ifup and network-functions In-Reply-To: <414AE5D4.3080102@redhat.com> References: <1095340332.9144.2356.camel@imladris.demon.co.uk> <414A9F26.5050300@iee.lu> <414AE5D4.3080102@redhat.com> Message-ID: I think the overall intention here is to have ifup/ifdown remain the main command interface for controlling network interfaces. Breaking out the functionality of different types of networking interfaces is more for readability and maintenance. Right now if you are trying to debug ifup or make any changes you need to wade through a lot of varying checks that may not even apply to the type of interface you are dealing with. I have no intention of trying to introduce any changes of how the system interacts with the ifup/ifdown commands. I am more interested in adding some functionality to them, and hopefully making networking a little more flexible to deal with the demands of mobile computing. -Jon On Fri, 17 Sep 2004 09:25:40 -0400, Chuck Mead wrote: > Charles Lopes wrote: > > > David Woodhouse wrote: > > > >> That's nice. I assume it selects the appropriate key based on the ESSID > >> it finds? > >> A while ago I sent patches to Bill (and/or put them in Bugzilla) which > >> added Bluetooth networking support. I moved the tail end of ifup into > >> ifup-eth, then added an 'ifup-wireless' which calls that, as does > >> ifup-bnep. We no longer have to have the wireless (or bluetooth) stuff > >> hacked in to the middle of ifup that way. > >> > >> > > Splitting out ethernet stuff to ifup-eth sounds like a good idea IMHO. > > I'm trying to add support for WAN cards (only using the generic hdlc > > stack and sethdlc at the moment) and I was considering doing the same. > > The ethernet code is already framed by a "if" statement anyway, > > splitting it out would just improve readability and consistancy of the > > ifup/down scripts. > > > Doubtless this has already been thought of and discarded but I just > wanted to make the comment that there may be lots of stuff on peoples > machines that depends on ifup. I know I have written scripts and lots of > other stuff over the years that used this script. So if we're going to > make changes to support wireless better then why not leave ifup alone > and call the wireless script "wifup"? > > -- > Chuck Mead > Instructor II (and resident Postfix bigot), GLS > Disclaimer: "It's Thursday and my name is Locutus of B0rk!" > Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From fedora at wir-sind-cool.org Fri Sep 17 14:04:59 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 17 Sep 2004 16:04:59 +0200 Subject: [fedora.us] More bugzilla ticket reassignments Message-ID: <20040917160459.10f4d645.fedora@wir-sind-cool.org> Yesterday evening I went through bugzilla.fedora.us new package requests, preparing another batch of ticket reassignments. The tickets will be assigned to the packager (i.e. assignee = package owner). That makes it easier to sort http://fedora.us/QA by owner and look for familiar names and e.g. look at who has packaged what. So, don't be surprised when you receive "bugzilla spam" in your mailbox and don't know how to interpret the re-assignments. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Sep 17 14:08:20 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 17 Sep 2004 16:08:20 +0200 Subject: Distribution tag change of recent packages In-Reply-To: <20040916105030.676ba7b1@localhost> References: <20040916105030.676ba7b1@localhost> Message-ID: <20040917160820.11e22205@localhost> Matthias Saou wrote : > - There are multiple different new strings used! Bad and most > confusing... > > Red Hat FC-3 > Red Hat (FC-3) > Red Hat (RHEL-3) (yes, FC Dev. yptools .src.rpm has this set!) > > And glibc and rpmdb-fedora have none set. Seems like no one here is really interested in those minor-but-user-visible annoyances... so let's bugzilla it! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132819 My vote goes for either "Red Hat (FC-3)" if is it clear that _all_ packages will get rebuilt at least once from a Fedora Core release to the next, or "Red Hat (FC)" if not. Maybe it would be even better to just have "Fedora Core 3" or "Fedora Core" instead, since I don't see why "Red Hat" should appear in the "Distribution" tag, unlike "Packager" or "Vendor" where it does make sense. Matthias, picky, picky -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 3.32 3.08 2.90 From bpm at ec-group.com Fri Sep 17 14:18:46 2004 From: bpm at ec-group.com (Brian Millett) Date: Fri, 17 Sep 2004 09:18:46 -0500 (CDT) Subject: rawhide report: 20040917 changes In-Reply-To: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> References: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> Message-ID: <18294.12.41.112.51.1095430726.squirrel@webmail.ec-group.com> > MAKEDEV-3.13-1 > -------------- > * Tue Sep 14 2004 Nalin Dahyabhai 3.13-1 > > - excise all architecture-specific logic and configuration data -- udev > knows > no arch-specific details, so they should be irrelevant now > - remove build conflicts on older RPM, unnecessary now that dev is gone > - remove dev's %post fstab munging > - add a short-circuit test for the common non-match cases > > * Tue Sep 14 2004 Jeremy Katz - 3.12.2-1 > > - add the vcsa user and floppy group in the MAKEDEV package now > > * Mon Sep 13 2004 Nalin Dahyabhai 3.12.1-1 > > - nuke the "dev" subpackage > > > udev-030-26 > ----------- > * Mon Sep 13 2004 Jeremy Katz - 030-26 > > - require a 2.6 kernel > - prereq instead of requires MAKEDEV > - obsolete and provide dev > - add a trigger for the removal of /dev so that we set things up > > * Fri Sep 10 2004 Dan Walsh - 030-25 > > - Use matchmediacon > Ok, right now after updating to this latest, I can not boot. I get to the point of this: Red Hat nash version 4.1.9 starting Mounted /proc filesystem Mounting sysfs Loading jdb.ko module Creating block devices Creating root device Mounting root filesystem kjournald starting. Commit interval 5 seconds EXT3-fs: mounted file system with ordered data mode. Switching to new root Then it just hangs and nothing happens. It doesn't matter if I use older kernels, same behavior. I have no clue. Is it because the dev package was deleted? I had set in /etc/udev/udev.conf UDEV_INITRD="no" to avoid the many error messages at boot time, should that be set to "yes"? Then remake the initrd? I can boot the rescue disk and get to the files, so I know the disk partitions are ok. Thanks, just going through a paradigm shift myself right now. -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From jspaleta at gmail.com Fri Sep 17 14:27:46 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 17 Sep 2004 10:27:46 -0400 Subject: Distribution tag change of recent packages In-Reply-To: <20040917160820.11e22205@localhost> References: <20040916105030.676ba7b1@localhost> <20040917160820.11e22205@localhost> Message-ID: <604aa7910409170727e799755@mail.gmail.com> On Fri, 17 Sep 2004 16:08:20 +0200, Matthias Saou wrote: > Matthias Saou wrote : > My vote goes for either "Red Hat (FC-3)" if is it clear that _all_ packages > will get rebuilt at least once from a Fedora Core release to the next, or > "Red Hat (FC)" if not. Maybe it would be even better to just have "Fedora > Core 3" or "Fedora Core" instead, since I don't see why "Red Hat" should > appear in the "Distribution" tag, unlike "Packager" or "Vendor" where it > does make sense. I would have thought... considering efforts being made in other places to disassociated the Red Hat brand name with Fedora, that Red Hat would NOT be in the Distribution tag as a matter of political/legal policy from on high. However its decided... packages IN core should be doing this consistently...and in a reasonably future proof way. So someone with the power to make the policy...make the policy...and lets use it going forward. I can see arguments for using the release number in the tag and arguments against it... and i doubt those pros/cons will change over time. So whatever the string is, make it consistent. This tag is only useful if its consistently used. -jef From bpm at ec-group.com Fri Sep 17 15:39:22 2004 From: bpm at ec-group.com (Brian Millett) Date: Fri, 17 Sep 2004 10:39:22 -0500 (CDT) Subject: rawhide report: 20040917 changes In-Reply-To: <18294.12.41.112.51.1095430726.squirrel@webmail.ec-group.com> References: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> <18294.12.41.112.51.1095430726.squirrel@webmail.ec-group.com> Message-ID: <21791.12.41.112.51.1095435562.squirrel@webmail.ec-group.com> > >> MAKEDEV-3.13-1 >> -------------- >> * Tue Sep 14 2004 Nalin Dahyabhai 3.13-1 >> >> - excise all architecture-specific logic and configuration data -- >> udev knows >> no arch-specific details, so they should be irrelevant now >> - remove build conflicts on older RPM, unnecessary now that dev is >> gone - remove dev's %post fstab munging >> - add a short-circuit test for the common non-match cases >> >> * Tue Sep 14 2004 Jeremy Katz - 3.12.2-1 >> >> - add the vcsa user and floppy group in the MAKEDEV package now >> >> * Mon Sep 13 2004 Nalin Dahyabhai 3.12.1-1 >> >> - nuke the "dev" subpackage >> >> >> udev-030-26 >> ----------- >> * Mon Sep 13 2004 Jeremy Katz - 030-26 >> >> - require a 2.6 kernel >> - prereq instead of requires MAKEDEV >> - obsolete and provide dev >> - add a trigger for the removal of /dev so that we set things up >> >> * Fri Sep 10 2004 Dan Walsh - 030-25 >> >> - Use matchmediacon >> > > Ok, right now after updating to this latest, I can not boot. I get to > the point of this: > > Red Hat nash version 4.1.9 starting > Mounted /proc filesystem > Mounting sysfs > Loading jdb.ko module > Creating block devices > Creating root device > Mounting root filesystem > kjournald starting. Commit interval 5 seconds > EXT3-fs: mounted file system with ordered data mode. > Switching to new root > > > Then it just hangs and nothing happens. It doesn't matter if I use > older kernels, same behavior. I have no clue. Is it because the dev > package was deleted? I had set in /etc/udev/udev.conf > UDEV_INITRD="no" > to avoid the many error messages at boot time, should that be set to > "yes"? Then remake the initrd? Well, normally I hate to answer my own post, but in this case I'm ecstatic. Setting UDEV_INITRD="yes" and regenerating the initrd fix my situation. kernel=2.6.8-1.549 MAKEDEV-3.13-1 udev-030-26 -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From pekkas at netcore.fi Fri Sep 17 16:51:26 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 17 Sep 2004 19:51:26 +0300 (EEST) Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <1095424919.17821.10.camel@hades.cambridge.redhat.com> Message-ID: On Fri, 17 Sep 2004, David Woodhouse wrote: > On Thu, 2004-09-16 at 21:02 +0200, Felipe Alfaro Solana wrote: > > Hi! > > > > Now that, officially, IPv6 site-local addresses have been deprecated > > (RFC3879) and their use not recommended in new deployments, how will > > glibc resolve the preference problem ... > > > > Will this change anytime soon? Any comments on this? > > I assume you'd prefer comments more helpful than 'AAARGH I was hoping > sanity would prevail and site-local addresses wouldn't get deprecated'? I personally disagree with this, but if you insist, you might be interested in what becomes of draft-ietf-ipv6-unique-local-addr-05.txt and draft-ietf-ipv6-ula-central-00.txt. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From drepper at redhat.com Fri Sep 17 18:08:36 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Fri, 17 Sep 2004 11:08:36 -0700 Subject: IPv6 and IPv4 resolver preferences In-Reply-To: <7F17ED15-088E-11D9-A94E-000D9352858E@linuxmail.org> References: <20040916195822.46190.qmail@web50603.mail.yahoo.com> <2DC892A7-082D-11D9-8450-000D9352858E@linuxmail.org> <414A2BA9.4020604@redhat.com> <7F17ED15-088E-11D9-A94E-000D9352858E@linuxmail.org> Message-ID: <414B2824.1070009@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Felipe Alfaro Solana wrote: > When running "telnet computer1" and looking at the packets captured by > Ethereal, I can see _exactly_ four queries, all of them asking for the > RR host record of "computer1.mydomain.com", that is, four queries asking > for the same FQDN. Of the four queries, the first one asks for the AAAA > RR, while the remaining three ask for the A RR. Look again. There are two and two. And you'll have to look at the so ruces for the old glibc version. It's not important enough to explain in detail here given that all these are implementation details which have changed. > In my case, it's just the other way around. I DO want IPv6 queries, and > I DO want IPv6 to always have precedence over IPv4. Anyways, I'll get > glibc-2.3.3-53 as soon as it's available. getaddrinfo does sorting according to RFC 3484. If the v4 addresses are before the v6 addresses in the list returned by getaddrinfo, then the v4 addresses are deemed preferrable. Usually this is the correct result. There are a few cornercases of RFC 3484 which I cannot implement at userlevel and there are a few places where the RFC 3484 is outdated (wrt to other parts of IPv6), but I hardly think this is a real problem. So, adjust your interfaces so that the address selection prefers the v6 addresses. And read RFC 3484. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBSygk2ijCOnn/RHQRAucZAKCjK3n0dC/FqO+9cHPVIFtNk6tjFQCcDlgd 7WJA4r5l3kifdel7RWkd9Bo= =WVQn -----END PGP SIGNATURE----- From jroyse at gmail.com Fri Sep 17 19:50:36 2004 From: jroyse at gmail.com (Josiah Royse) Date: Fri, 17 Sep 2004 15:50:36 -0400 Subject: Homedir backup (was Re: "Stateless Linux" project) In-Reply-To: <1095264568.5860.29.camel@localhost.localdomain> References: <200409151443.i8FEhwp07789@ayesha.phys.Virginia.EDU> <20040915151325.GU14918@server4.8080.it> <1095264568.5860.29.camel@localhost.localdomain> Message-ID: <1722bf504091712501d836f48@mail.gmail.com> On Wed, 15 Sep 2004 12:09:28 -0400, Owen Taylor wrote: > Well, a bigger problem with rsync is that in many cases, the listing > files part is the biggest time sync. And if that gets interrupted, > you start from the beginning. (*) Hey this is totally different approach: What if each user's home directory was an encrypted file (mounted as a local loopback). These are laptops usually- for the need of occasional sync, so why not also encrypt them also in case of theft, secrets, etc. Then as an option at login you can answer yes/no if you would like your profile (encrypted file) sync'ed before login. Then the rdiff does a compare against one (albeit large) file remotely. Bonuses: encrypted, safe from losing laptop/local computer, at time of login- exactly the same profile/home directory Drawbacks: slow?, container size of encrypted file, version control management difficult? Just a thought! --Josiah (RHCE) From russell at coker.com.au Fri Sep 17 20:28:39 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 18 Sep 2004 06:28:39 +1000 Subject: /dev/dri/* and SE Linux In-Reply-To: <49502.66.151.13.191.1095105139.squirrel@66.151.13.191> References: <200409111934.19937.russell@coker.com.au> <200409140124.10133.russell@coker.com.au> <49502.66.151.13.191.1095105139.squirrel@66.151.13.191> Message-ID: <200409180628.39624.russell@coker.com.au> On Tue, 14 Sep 2004 05:52, "W. Michael Petullo" wrote: > For what its worth, I entered a bug into bugzilla about this a while ago: > > DRI use denied by Red Hat SELinux policy > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124837 The AVC messages in that bugzilla don't reference the DRI device, they indicate that a game was not running in user_games_t domain. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From kyrre at solution-forge.net Fri Sep 17 21:05:29 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 17 Sep 2004 23:05:29 +0200 Subject: [fedora.us] More bugzilla ticket reassignments In-Reply-To: <20040917160459.10f4d645.fedora@wir-sind-cool.org> References: <20040917160459.10f4d645.fedora@wir-sind-cool.org> Message-ID: <1095455128.4904.2.camel@kyrre> There is just one tiny little thing i wonder about: In core 3, will there be an option under install "Do you want to use extras-packages? This may be illegal under current US and EU copyright/patent law" - something like debian does? That would be really great, but i dont know the legal implications. fre, 17.09.2004 kl. 16.04 skrev Michael Schwendt: > Yesterday evening I went through bugzilla.fedora.us new package > requests, preparing another batch of ticket reassignments. The tickets > will be assigned to the packager (i.e. assignee = package owner). That > makes it easier to sort http://fedora.us/QA by owner and look for > familiar names and e.g. look at who has packaged what. > > So, don't be surprised when you receive "bugzilla spam" in your > mailbox and don't know how to interpret the re-assignments. > > > ______________________________________________________________________ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From smoogen at lanl.gov Fri Sep 17 21:50:06 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Fri, 17 Sep 2004 15:50:06 -0600 Subject: [fedora.us] More bugzilla ticket reassignments In-Reply-To: <1095455128.4904.2.camel@kyrre> References: <20040917160459.10f4d645.fedora@wir-sind-cool.org> <1095455128.4904.2.camel@kyrre> Message-ID: <414B5C0E.5080005@lanl.gov> Kyrre Ness Sjobak wrote: > There is just one tiny little thing i wonder about: In core 3, will > there be an option under install "Do you want to use extras-packages? > This may be illegal under current US and EU copyright/patent law" - > something like debian does? That would be really great, but i dont know > the legal implications. > I dont think so. Certain readings of US/EU law is that even advising that it might be illegal but saying you can do it makes you a party to the crime. EG Red Hat would be enabling a criminal enterprise. While it might get thrown out of court eventually... it is probably something RH wants to deal with. -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From enrico.scholz at informatik.tu-chemnitz.de Fri Sep 17 22:06:47 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 18 Sep 2004 00:06:47 +0200 Subject: MIME registration breaks readonly /usr/share Message-ID: <87r7p08s94.fsf@kosh.ultra.csn.tu-chemnitz.de> Hello, the current method to register MIME types ( | update-mime-database "/usr/share/mime" in %post scriptlets) breaks[1] on setups where /usr/share is mounted readonly. This bug seems to affect a lot of recent gnome packages so that a general solution must be found. The "right" thing would be probably to do the needed checks in the %post scriptlets. But: * rpm does not offer simple ways for this[2] * every package whould need this check Last point could be solved by a %__update_mime_database macro incorporating the required tests and actions. But the first issue stays so that a quick hack like checking for EROFS in 'update-mime-database' is perhaps the best solution for now. Enrico Footnotes: [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132847 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=51193 From fedora at wir-sind-cool.org Fri Sep 17 22:14:53 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 18 Sep 2004 00:14:53 +0200 Subject: [fedora.us] More bugzilla ticket reassignments In-Reply-To: <1095455128.4904.2.camel@kyrre> References: <20040917160459.10f4d645.fedora@wir-sind-cool.org> <1095455128.4904.2.camel@kyrre> Message-ID: <20040918001453.3d72aaec.fedora@wir-sind-cool.org> On Fri, 17 Sep 2004 23:05:29 +0200, Kyrre Ness Sjobak wrote: > There is just one tiny little thing i wonder about: In core 3, will > there be an option under install "Do you want to use extras-packages? > This may be illegal under current US and EU copyright/patent law" - > something like debian does? That would be really great, but i dont know > the legal implications. Nothing would be illegal about adding packages offered at fedora.us. You're confusing the situation with software not included by the Fedora Project due to patenting or licencing issues. -- Fedora Core release 2 (Tettnang) - Linux 2.6.7-1.494.2.2 loadavg: 2.14 2.16 2.22 From reuben-fedora-devel at reub.net Fri Sep 17 22:50:29 2004 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Sat, 18 Sep 2004 10:50:29 +1200 Subject: rawhide report: 20040917 changes In-Reply-To: <21791.12.41.112.51.1095435562.squirrel@webmail.ec-group.co m> References: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> <18294.12.41.112.51.1095430726.squirrel@webmail.ec-group.com> <21791.12.41.112.51.1095435562.squirrel@webmail.ec-group.com> Message-ID: <6.1.2.0.2.20040918104434.01a1a690@tornado.reub.net> Hi, At 03:39 a.m. 18/09/2004, Brian Millett wrote: > >> udev-030-26 > >> ----------- > >> * Mon Sep 13 2004 Jeremy Katz - 030-26 > >> > >> - require a 2.6 kernel > >> - prereq instead of requires MAKEDEV > >> - obsolete and provide dev > >> - add a trigger for the removal of /dev so that we set things up > >> > >> * Fri Sep 10 2004 Dan Walsh - 030-25 > >> > >> - Use matchmediacon > >> > > > > Ok, right now after updating to this latest, I can not boot. I get to > > the point of this: > > > > Red Hat nash version 4.1.9 starting > > Mounted /proc filesystem > > Mounting sysfs > > Loading jdb.ko module > > Creating block devices > > Creating root device > > Mounting root filesystem > > kjournald starting. Commit interval 5 seconds > > EXT3-fs: mounted file system with ordered data mode. > > Switching to new root > > > > > > Then it just hangs and nothing happens. It doesn't matter if I use > > older kernels, same behavior. I have no clue. Is it because the dev > > package was deleted? I had set in /etc/udev/udev.conf > > UDEV_INITRD="no" > > to avoid the many error messages at boot time, should that be set to > > "yes"? Then remake the initrd? > >Well, normally I hate to answer my own post, but in this case I'm >ecstatic. Setting UDEV_INITRD="yes" and regenerating the initrd fix my >situation. > >kernel=2.6.8-1.549 >MAKEDEV-3.13-1 >udev-030-26 I was bitten by this too - the removal of dev broke things a bit. However, I'm not using an initrd as I'm compiling my own kernels from kernel.org. What is the best way to work around it in this situation? Am I about to be forced to use an initrd? Reuben From shiva at sewingwitch.com Sat Sep 18 02:17:12 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 17 Sep 2004 19:17:12 -0700 Subject: certwatch: SSL certificate expiry warning tool In-Reply-To: <20040917135152.GA8655@redhat.com> References: <20040917135152.GA8655@redhat.com> Message-ID: <7F7CDAB720CD2DFF65B20E6F@[10.169.6.246]> --On Friday, September 17, 2004 2:51 PM +0100 Joe Orton wrote: > It's implemented in /etc/cron.daily/certwatch to, by default, check all > certificates configured in the mod_ssl configuration, but this can be > extended to any other services which use SSL certificates. Great! How about also pointing it at: /etc/httpd/conf Apache /etc/ipsec.d OpenSwan Any other apps that keep certs in their own directories? I know ntop has one in /etc/ntop but ntop is not yet in Fedora. From mark at mark.mielke.cc Sat Sep 18 02:44:37 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Fri, 17 Sep 2004 22:44:37 -0400 Subject: Probably a given - but udev-030-26 made my system unbootable (detailed) Message-ID: <20040918024436.GA3464@mark.mielke.cc> The first error was "Warning: unable to find a console" or something to that effect. The boot process paused. I manually created: crw------- 1 root root 5, 1 Sep 17 22:18 console Then, it complained about /dev/null not being writable. Sure enough, /dev/null was a regular file with bytes in it. *sigh* Created that as: crw-rw-rw- 1 root root 1, 3 Feb 23 2004 null No luck. Booting still had major trouble. Finally I gave up: To get myself back into working order - I renamed /dev to /dev.udev and copied a working /dev from another partition to /dev. It looks like a lot of things are missing from /dev.udev. The current contents of /dev.udev is (after I added console and null): $ ls -l /dev.udev total 6 lrwxr-xr-x 1 root root 8 Dec 1 2003 cdrom -> /dev/hdc crw------- 1 root root 5, 1 Sep 17 22:18 console crw------- 1 root root 10, 63 Jul 31 09:16 device-mapper crw-rw---- 1 root root 14, 9 Aug 21 00:05 dmmidi prw------- 1 root root 0 Sep 17 22:07 initctl| crw-r----- 1 root kmem 1, 2 Aug 28 14:13 kmem drwxr-xr-x 2 root root 2048 Jul 31 10:55 mapper/ crw------- 1 root root 14, 2 Aug 21 00:05 midi lrwxr-xr-x 1 root root 5 Dec 1 2003 mouse -> psaux crw-rw-rw- 1 root root 1, 3 Feb 23 2004 null crw-rw---- 1 mark root 195, 0 Jul 1 13:57 nvidia0 crw------- 1 mark root 195, 1 Jul 1 13:57 nvidia1 crw------- 1 mark root 195, 2 Jul 1 13:57 nvidia2 crw------- 1 mark root 195, 3 Jul 1 13:57 nvidia3 crw------- 1 mark root 195, 4 Jul 1 13:57 nvidia4 crw------- 1 mark root 195, 5 Jul 1 13:57 nvidia5 crw------- 1 mark root 195, 6 Jul 1 13:57 nvidia6 crw------- 1 mark root 195, 7 Jul 1 13:57 nvidia7 crw-rw---- 1 mark root 195, 255 Jul 1 13:57 nvidiactl lrwxr-xr-x 1 root root 20 Dec 1 2003 ptal-printd -> /var/run/ptal-printd/ drwxr-xr-x 2 root root 2048 Jul 4 2002 pts/ drwxr-xr-x 2 root root 2048 Sep 6 2001 shm/ crw-rw---- 1 root tty 4, 32 Aug 24 15:47 tty32 crw-rw---- 1 root tty 4, 33 Aug 24 15:47 tty33 crw-rw---- 1 root tty 4, 34 Aug 24 15:47 tty34 crw-rw---- 1 root tty 4, 35 Aug 24 15:47 tty35 crw-rw---- 1 root tty 4, 36 Aug 24 15:47 tty36 crw-rw---- 1 root tty 4, 37 Aug 24 15:47 tty37 crw-rw---- 1 root tty 4, 38 Aug 24 15:47 tty38 crw-rw---- 1 root tty 4, 39 Aug 24 15:47 tty39 crw-rw---- 1 root tty 4, 40 Aug 24 15:47 tty40 crw-rw---- 1 root tty 4, 41 Aug 24 15:47 tty41 crw-rw---- 1 root tty 4, 42 Aug 24 15:47 tty42 crw-rw---- 1 root tty 4, 43 Aug 24 15:47 tty43 crw-rw---- 1 root tty 4, 44 Aug 24 15:47 tty44 crw-rw---- 1 root tty 4, 45 Aug 24 15:47 tty45 crw-rw---- 1 root tty 4, 46 Aug 24 15:47 tty46 crw-rw---- 1 root tty 4, 47 Aug 24 15:47 tty47 crw-rw---- 1 root tty 4, 48 Aug 24 15:47 tty48 crw-rw---- 1 root tty 4, 49 Aug 24 15:47 tty49 crw-rw---- 1 root tty 4, 50 Aug 24 15:47 tty50 crw-rw---- 1 root tty 4, 51 Aug 24 15:47 tty51 crw-rw---- 1 root tty 4, 52 Aug 24 15:47 tty52 crw-rw---- 1 root tty 4, 53 Aug 24 15:47 tty53 crw-rw---- 1 root tty 4, 54 Aug 24 15:47 tty54 crw-rw---- 1 root tty 4, 55 Aug 24 15:47 tty55 crw-rw---- 1 root tty 4, 56 Aug 24 15:47 tty56 crw-rw---- 1 root tty 4, 57 Aug 24 15:47 tty57 crw-rw---- 1 root tty 4, 58 Aug 24 15:47 tty58 crw-rw---- 1 root tty 4, 59 Aug 24 15:47 tty59 crw-rw---- 1 root tty 4, 60 Aug 24 15:47 tty60 crw-rw---- 1 root tty 4, 61 Aug 24 15:47 tty61 crw-rw---- 1 root tty 4, 62 Aug 24 15:47 tty62 crw-rw---- 1 root tty 4, 63 Aug 24 15:47 tty63 lrwxrwxrwx 1 root root 4 Aug 28 14:44 XOR -> null Hope this helps somebody in debugging this! :-) mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From j.w.r.degoede at hhs.nl Sat Sep 18 06:23:30 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 18 Sep 2004 08:23:30 +0200 Subject: [fedora.us] More bugzilla ticket reassignments In-Reply-To: <1095455128.4904.2.camel@kyrre> References: <20040917160459.10f4d645.fedora@wir-sind-cool.org> <1095455128.4904.2.camel@kyrre> Message-ID: <414BD462.6070701@hhs.nl> Kyrre Ness Sjobak wrote: > There is just one tiny little thing i wonder about: In core 3, will > there be an option under install "Do you want to use extras-packages? > This may be illegal under current US and EU copyright/patent law" - > something like debian does? That would be really great, but i dont know > the legal implications. > 1) It currently still is totally legal to ship packages which have sw patent issues in the eu, the current eu law clearly forbids sw patents, so although some sw patents have been awarded in the eu this _currently_ is a non issue. The ec (goverment) of the eu however is doing its best to get sw patent legalised in the eu, against the will of the eu parlement (democracy, whats that?) and against the will of many countries parlements. 2) I've been thinking about something more elaborate then this: Change the select your timezone screen to a select your location screen. This way we could also automaticly select the nearest official mirror for up2date and yum, and when we're in a country where it is legal automaticly include livna in the repository list. If this is done before package selection, we could then also ask: You seem to have an internetconnection, would you like to download and install extra available software? And include the extra repositories in the package selection (for example default install xine on a desktop if available). Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From marcel at mesa.nl Sat Sep 18 09:25:00 2004 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Sat, 18 Sep 2004 11:25:00 +0200 Subject: rawhide report: 20040917 changes In-Reply-To: <21791.12.41.112.51.1095435562.squirrel@webmail.ec-group.com> References: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> <18294.12.41.112.51.1095430726.squirrel@webmail.ec-group.com> <21791.12.41.112.51.1095435562.squirrel@webmail.ec-group.com> Message-ID: <20040918092500.GA16380@joshua.mesa.nl> On Fri, Sep 17, 2004 at 10:39:22AM -0500, Brian Millett wrote: > > > > >> MAKEDEV-3.13-1 > >> -------------- > >> * Tue Sep 14 2004 Nalin Dahyabhai 3.13-1 > >> > >> - excise all architecture-specific logic and configuration data -- > >> udev knows > >> no arch-specific details, so they should be irrelevant now > >> - remove build conflicts on older RPM, unnecessary now that dev is > >> gone - remove dev's %post fstab munging > >> - add a short-circuit test for the common non-match cases > >> > >> * Tue Sep 14 2004 Jeremy Katz - 3.12.2-1 > >> > >> - add the vcsa user and floppy group in the MAKEDEV package now > >> > >> * Mon Sep 13 2004 Nalin Dahyabhai 3.12.1-1 > >> > >> - nuke the "dev" subpackage > >> > >> > >> udev-030-26 > >> ----------- > >> * Mon Sep 13 2004 Jeremy Katz - 030-26 > >> > >> - require a 2.6 kernel > >> - prereq instead of requires MAKEDEV > >> - obsolete and provide dev > >> - add a trigger for the removal of /dev so that we set things up > >> > >> * Fri Sep 10 2004 Dan Walsh - 030-25 > >> > >> - Use matchmediacon > >> > > > > Ok, right now after updating to this latest, I can not boot. I get to > > the point of this: > > > > Red Hat nash version 4.1.9 starting > > Mounted /proc filesystem > > Mounting sysfs > > Loading jdb.ko module > > Creating block devices > > Creating root device > > Mounting root filesystem > > kjournald starting. Commit interval 5 seconds > > EXT3-fs: mounted file system with ordered data mode. > > Switching to new root > > > > > > Then it just hangs and nothing happens. It doesn't matter if I use > > older kernels, same behavior. I have no clue. Is it because the dev > > package was deleted? I had set in /etc/udev/udev.conf > > UDEV_INITRD="no" > > to avoid the many error messages at boot time, should that be set to > > "yes"? Then remake the initrd? > > Well, normally I hate to answer my own post, but in this case I'm > ecstatic. Setting UDEV_INITRD="yes" and regenerating the initrd fix my > situation. > > kernel=2.6.8-1.549 > MAKEDEV-3.13-1 > udev-030-26 > Thanks! I was having the same problem and was into the rescue mode too when I read your solution. The only thing now is that the nvidia driver is not autoloaded anymore when starting X... -Marcel -- ======-------- Marcel J.E. Mol MESA Consulting B.V. =======--------- ph. +31-(0)6-54724868 P.O. Box 112 =======--------- marcel at mesa.nl 2630 AC Nootdorp __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ They couldn't think of a number, Linux user 1148 -- counter.li.org so they gave me a name! -- Rupert Hine -- www.ruperthine.com From felipe_alfaro at linuxmail.org Sat Sep 18 10:50:17 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 18 Sep 2004 12:50:17 +0200 Subject: Probably a given - but udev-030-26 made my system unbootable (detailed) In-Reply-To: <20040918024436.GA3464@mark.mielke.cc> References: <20040918024436.GA3464@mark.mielke.cc> Message-ID: <8788673C-0960-11D9-8D68-000D9352858E@linuxmail.org> On Sep 18, 2004, at 04:44, Mark Mielke wrote: > The first error was "Warning: unable to find a console" or something > to that > effect. The boot process paused. I manually created: > > crw------- 1 root root 5, 1 Sep 17 22:18 console > > Then, it complained about /dev/null not being writable. Sure enough, > /dev/null was a regular file with bytes in it. *sigh* Created that as: > > crw-rw-rw- 1 root root 1, 3 Feb 23 2004 null > > No luck. Booting still had major trouble. Finally I gave up: > > To get myself back into working order - I renamed /dev to /dev.udev > and copied a working /dev from another partition to /dev. It looks > like a lot of things are missing from /dev.udev. The current contents > of /dev.udev is (after I added console and null): The same happened to me after upgrading to the new "udev" from RawHide, but instead, I used "/sbin/MAKEDEV" to manually recreate all devices used by IDE, console, linux-2.6.x and so. It seems "udev" is dangerous when not using and INITRD. From felipe_alfaro at linuxmail.org Sat Sep 18 10:58:24 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 18 Sep 2004 12:58:24 +0200 Subject: rawhide report: 20040917 changes In-Reply-To: <6.1.2.0.2.20040918104434.01a1a690@tornado.reub.net> References: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> <18294.12.41.112.51.1095430726.squirrel@webmail.ec-group.com> <21791.12.41.112.51.1095435562.squirrel@webmail.ec-group.com> <6.1.2.0.2.20040918104434.01a1a690@tornado.reub.net> Message-ID: On Sep 18, 2004, at 00:50, Reuben Farrelly wrote: >> kernel=2.6.8-1.549 >> MAKEDEV-3.13-1 >> udev-030-26 > > I was bitten by this too - the removal of dev broke things a bit. > However, I'm not using an initrd as I'm compiling my own kernels from > kernel.org. > > What is the best way to work around it in this situation? Am I about > to be forced to use an initrd? I set USE_UDEV="no" in "/etc/udev/udev.conf" and then used "/sbin/MAKEDEV" to recreate all the device nodes in "/dev". MAKEDEV needs an extra argument, which is the name of a file inside "/etc/makedev.d". For example: /sbin/MAKEDEV console /sbin/MAKEDEV sound /sbin/MAKEDEV ide /sbin/MAKEDEV generic /sbin/MAKEDEV usb From dwmw2 at infradead.org Sat Sep 18 11:21:33 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 18 Sep 2004 12:21:33 +0100 Subject: Gnome 8.0.... Gnome 2.8 In-Reply-To: <20040916004450.70367.qmail@web25305.mail.ukl.yahoo.com> References: <20040916004450.70367.qmail@web25305.mail.ukl.yahoo.com> Message-ID: <1095506494.5065.98.camel@localhost.localdomain> On Wed, 2004-09-15 at 17:44 -0700, James Harrison wrote: > Errrrr.. > > ......Sorry typo : Gnome 2.8....... Not 8 Hmm. I saw that and just assumed the numbering scheme had changed. I was blaming it on Sun's involvement. :) -- dwmw2 From kyrre at solution-forge.net Sat Sep 18 11:34:45 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 18 Sep 2004 13:34:45 +0200 Subject: [fedora.us] More bugzilla ticket reassignments In-Reply-To: <414BD462.6070701@hhs.nl> References: <20040917160459.10f4d645.fedora@wir-sind-cool.org> <1095455128.4904.2.camel@kyrre> <414BD462.6070701@hhs.nl> Message-ID: <1095507285.2680.37.camel@kyrre> Or somhow take advantage of the "do you have any extra cd's" under firstboot. I sombody at Livna/fedora.us/etc made such an iso, and it got widely published where it is to be found, "everybody" would find that and add it to the download. Another thing: Using timezone localisation selection to choose it, might be a bad idea as some people in the US might decide they want it no matter what. I mean - really - how namy here does REALLY care that because of US patent law libdcss is illegal, and therefor boot windows each time they want to watch a dvd on their pc? No, let the users decide. Put a big box there, with warnings and everything, and "yes/no" buttons. Debian does it, SuSE delivers mp3 etc, and many other distros does to. US is not the world ;) BTW. according to Richard Stallman, the EU is going to have a new vote on software patents in the beginning of october. Check out ffii.org for more information. As far as i know, the case is that the parliment voted "no" on sw patents last year, but the council still wants them (backed my multi-billion corps like Nokia, Siemens, and Microsoft), and have demanded a new hearing, in the beginning of October. l?r, 18.09.2004 kl. 08.23 skrev Hans de Goede: > Kyrre Ness Sjobak wrote: > > There is just one tiny little thing i wonder about: In core 3, will > > there be an option under install "Do you want to use extras-packages? > > This may be illegal under current US and EU copyright/patent law" - > > something like debian does? That would be really great, but i dont know > > the legal implications. > > > > 1) It currently still is totally legal to ship packages which have sw > patent issues in the eu, the current eu law clearly forbids sw patents, > so although some sw patents have been awarded in the eu this _currently_ > is a non issue. The ec (goverment) of the eu however is doing its best > to get sw patent legalised in the eu, against the will of the eu > parlement (democracy, whats that?) and against the will of many > countries parlements. > > 2) I've been thinking about something more elaborate then this: > > Change the select your timezone screen to a select your location screen. > This way we could also automaticly select the nearest official mirror > for up2date and yum, and when we're in a country where it is legal > automaticly include livna in the repository list. > > If this is done before package selection, we could then also ask: > You seem to have an internetconnection, would you like to download and > install extra available software? And include the extra repositories in > the package selection (for example default install xine on a desktop if > available). > > Regards, > > Hans > > > > -- > EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es > From buildsys at redhat.com Sat Sep 18 11:59:27 2004 From: buildsys at redhat.com (Build System) Date: Sat, 18 Sep 2004 07:59:27 -0400 Subject: rawhide report: 20040918 changes Message-ID: <200409181159.i8IBxRc03028@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-2.91-0.20040918 ---------------------------- From dhollis at davehollis.com Sat Sep 18 15:06:10 2004 From: dhollis at davehollis.com (David Hollis) Date: Sat, 18 Sep 2004 11:06:10 -0400 Subject: Probably a given - but udev-030-26 made my system unbootable (detailed) In-Reply-To: <8788673C-0960-11D9-8D68-000D9352858E@linuxmail.org> References: <20040918024436.GA3464@mark.mielke.cc> <8788673C-0960-11D9-8D68-000D9352858E@linuxmail.org> Message-ID: <1095519970.3696.8.camel@dhollis-lnx.kpmg.com> On Sat, 2004-09-18 at 12:50 +0200, Felipe Alfaro Solana wrote: > On Sep 18, 2004, at 04:44, Mark Mielke wrote: > > > The first error was "Warning: unable to find a console" or something > > to that > > effect. The boot process paused. I manually created: > > > > crw------- 1 root root 5, 1 Sep 17 22:18 console > > > > Then, it complained about /dev/null not being writable. Sure enough, > > /dev/null was a regular file with bytes in it. *sigh* Created that as: > > > > crw-rw-rw- 1 root root 1, 3 Feb 23 2004 null > > > > No luck. Booting still had major trouble. Finally I gave up: I actually noticed this after I upgraded my udev. Fortunately, I didn't reboot! I checked out my /dev directory and noticed that null was a regular file and there wasn't a heckuva lot in there. I ran /sbin/udevstart and it recreated everything and life was good. When I rebooted later things came up with no problems. -- David Hollis From lukasz at wsisiz.edu.pl Sat Sep 18 15:10:39 2004 From: lukasz at wsisiz.edu.pl (Lukasz Trabinski) Date: Sat, 18 Sep 2004 17:10:39 +0200 (CEST) Subject: Inn Message-ID: Hello What's the reason that inn is still in 2.3.5 version? The latest version of inn is 2.4.1. -- *[ ?ukasz Tr?bi?ski ]* From mattwhiteley at gmail.com Sat Sep 18 16:23:57 2004 From: mattwhiteley at gmail.com (matt whiteley) Date: Sat, 18 Sep 2004 09:23:57 -0700 Subject: kernel sata support Message-ID: <72ae109c0409180923721b3114@mail.gmail.com> I have not been able to boot a kernel since 2.6.6-1.435.2.3 or install from the boot.iso with a later kernel. I filed a bug #129190 about the issue, but the only idea offered was to rebuild the initrd image. I did this to no avail. It appears the sata_nv driver is not in the working 2.6.5 or 2.6.6 initrd anyway. It seems odd that the support for my mobo is worsening but I assume it is an upstream change. Any ideas on how to install the new boot.iso so I can test rawhide out on the machine? mobo is : MSI K8N-Neo Platinum w/ sata thanks, -- matt whiteley From eric at brouhaha.com Sat Sep 18 16:27:50 2004 From: eric at brouhaha.com (Eric Smith) Date: Sat, 18 Sep 2004 09:27:50 -0700 (PDT) Subject: RPM debuginfo problems Message-ID: <32819.64.169.63.74.1095524870.squirrel@64.169.63.74> About two weeks ago, I wrote: > When I try to rebuild Fedora RPMs, I routinely complaints like: > error: Could not open %files file > /home/esmith/rpmbuild/BUILD/kernel-utils-2.4/debugfiles.list: No such > file or directory Michael Schwendt replied: > Never heard about this problem before nor seen it myself. > > $ cat ~/.rpmrc > include: /usr/lib/rpm/redhat/rpmrc > > $ rpm -q redhat-rpm-config > redhat-rpm-config-8.0.28-1.1.1 > > What else does your ~/.rpmmacros contain? That was the problem. My system started with Red Hat 3.0.3, and has been upgraded to every version through RH 9.0, then FC1 and FC2. But it did not have redhat-rpm-config installed, nor did I know of it. I used to rebuild packages just fine without it. Is the need for redhat-rpm-config and the include in .rpmrc documented somewhere? Thanks, Eric From kyrre at solution-forge.net Sat Sep 18 18:44:39 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 18 Sep 2004 20:44:39 +0200 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <1095093448.28790.7.camel@kyrre> References: <1094938008.2715.59.camel@kyrre> <20040911231120.GF4297@rednote.net> <1094944811.4796.7.camel@kyrre> <20040912145741.GB7623@rednote.net> <1095093448.28790.7.camel@kyrre> Message-ID: <1095533078.4253.16.camel@kyrre> Okay. It took a while, but right now i am listening to Time(Pink Floyd).mid in timidity with the "eawpats" patchset, and it sounds quite nice :D Here is what i did: 1. download the eawpats src.rpm (all other links was broken). Try to install it with rpm -ivh, find that it broke timidity (made it only spew a lot of garbage, f.ing up my terminal, and generally not do anything usefull). Reinstall timidity. 2. Open the source-rpm in fileroller. Find a .rar file inside it. Open that in file-roller. 3. Extract the rar. Encountered a bug in file-roller: if i opened a zip file (the src.rpm) in file-roller, and then opened another zip (the RAR archive inside), everything works out well. But if i then close the first window, and THEN try to unzip (unrar acctually) the rar, it simply does nothing. Absolutly nothing - think this might be some of the same case as this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132478 4. Try again, and extract the .rar into /usr/local/eawpats 5. Read "install.txt" carefully, and insert those lines at the end of /usr/share/timidity/timidity.cfg: #extra patches dir /usr/local/eawpats source gravis.cfg source gsdrums.cfg source gssfx.cfg source xgmap2.cfg 6. Play a midifile: [kyrre at kyrre MIDI]$ timidity -int Pink\ Floyd/Time.mid (the -int option gives a nice ncurces "gui" which shows some stats etc) Enjoy! I will now post a RFE to "distribution" on bugzilla. man, 13.09.2004 kl. 18.37 skrev Kyrre Ness Sjobak: > Yes, i have found it, and i am downloading the "eawpats" src.rpm right > now. (hmm... sound-font source-rpm?) I will (as soon as i have figured > out to do with a "source"-rpm... Any help, links etc? I feel ashamed not > knowing how to handle them!) test those patches asap, and will when i > have tested them contact ccrma for licensing information etc. > > And if all goes well, ill find some gui for it - i have found kmid, but > not tested it this far. Maybe find a GTK-based one as well, or persuade > a friend of mine into learning me GTK :P if i cant find one (maybe make > it python-based?). Then i will report back to bugzilla (which version? i > am currently running FC2) with a RFE. > > Does that seem good? First time i acctually do any real work to enchase > Fedora Core :D > > Kyrre Ness Sj?b?k > > s?n, 12.09.2004 kl. 16.57 skrev Janina Sajka: > > Kyrre Ness Sjobak writes: > > > s?n, 12.09.2004 kl. 01.11 skrev Janina Sajka: > > > > Kyrre Ness Sjobak writes: > > > > > Hmm... Does anybody know why Fedora haven't included a simple > > > > > midi-player, which simply sends things to your soundcard for rendering, > > > > > which in turn plays it?? And does anybody know about a good such > > > > > program? > > > > > > > > > Huh? Did timidity++ disappear? Or, am I misunderstanding your question? > > > > > > ... ... > > > > > > Hmm... what if i (as many others) are so lucky to have a HW-based > > > midi-playing soundcard (such as the AWE 64)? Methinks maybe they wants > > > to use it... > > > > > > > Are you aware of Planet CCRMA which is an entire distribution for > > musicians based on Fedora? > > > > http://ccrma.stanford.edu/planetccrma/software/ > > > > I mention CCRMA because it's Fedora and rpm based and aimed at > > professional musicians. > > > > However, I would also agree that support for driving MIDI instruments > > directly is weak on Linux. So, I heartily second Jeff's suggestion to > > get involved adding MIDI support to gstreamer--if that's something > > you're able to contribute. > > > > > Could it be possible to do something like MS does - in the gstreamer > > > setup, give an option to either use timidity (with a full patchset - the > > > patches included don't even rival my old SB16, > > > > The CCRMA repository does have timidity with a better set of > > instruments, fortunately. > > > From walters at redhat.com Sat Sep 18 19:40:33 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 18 Sep 2004 15:40:33 -0400 Subject: please try SELinux again Message-ID: <1095536433.4655.18.camel@nexus.verbum.private> Hi, Talking with a number of people at the office, it seems a high percentage of Fedora developers disabled SELinux during FC2 test2, which was our first attempt at SELinux. Many other users and testers in the Fedora community likely did so as well. I think a lot of people are not aware that things have changed (and generally improved) dramatically since then. Instead of the original "strict" policy which covered everything, a new "targeted" policy has been developed which only applies SELinux restrictions to a few select system daemons. Regular user login sessions are unrestricted. This targeted policy will be enabled by default for FC3. But those of you who are upgrading from existing systems, if you earlier added selinux=0 to your grub config, or disabled it in /etc/sysconfig/selinux, will not be testing the new policy. Please: undo those changes, and give it another try. Be sure that /etc/sysconfig/selinux has these two lines: SELINUX=enforcing SELINUXTYPE=targeted Also be sure you don't have selinux=0 in your grub configuration. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kyrre at solution-forge.net Sat Sep 18 20:27:56 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 18 Sep 2004 22:27:56 +0200 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <1095533078.4253.16.camel@kyrre> References: <1094938008.2715.59.camel@kyrre> <20040911231120.GF4297@rednote.net> <1094944811.4796.7.camel@kyrre> <20040912145741.GB7623@rednote.net> <1095093448.28790.7.camel@kyrre> <1095533078.4253.16.camel@kyrre> Message-ID: <1095539276.6226.3.camel@kyrre> Hmm... forgot something... Step 5.1: chmod -R 755 /usr/local/eawpats l?r, 18.09.2004 kl. 20.44 skrev Kyrre Ness Sjobak: > Okay. It took a while, but right now i am listening to Time(Pink > Floyd).mid in timidity with the "eawpats" patchset, and it sounds quite > nice :D > > Here is what i did: > > 1. download the eawpats src.rpm (all other links was broken). Try to > install it with rpm -ivh, find that it broke timidity (made it only spew > a lot of garbage, f.ing up my terminal, and generally not do anything > usefull). Reinstall timidity. > 2. Open the source-rpm in fileroller. Find a .rar file inside it. Open > that in file-roller. > 3. Extract the rar. Encountered a bug in file-roller: if i opened a zip > file (the src.rpm) in file-roller, and then opened another zip (the RAR > archive inside), everything works out well. But if i then close the > first window, and THEN try to unzip (unrar acctually) the rar, it simply > does nothing. Absolutly nothing - think this might be some of the same > case as this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132478 > 4. Try again, and extract the .rar into /usr/local/eawpats > 5. Read "install.txt" carefully, and insert those lines at the end of > /usr/share/timidity/timidity.cfg: > > #extra patches > dir /usr/local/eawpats > source gravis.cfg > source gsdrums.cfg > source gssfx.cfg > source xgmap2.cfg > > 6. Play a midifile: > [kyrre at kyrre MIDI]$ timidity -int Pink\ Floyd/Time.mid > (the -int option gives a nice ncurces "gui" which shows some stats etc) > Enjoy! > > I will now post a RFE to "distribution" on bugzilla. > > > man, 13.09.2004 kl. 18.37 skrev Kyrre Ness Sjobak: > > Yes, i have found it, and i am downloading the "eawpats" src.rpm right > > now. (hmm... sound-font source-rpm?) I will (as soon as i have figured > > out to do with a "source"-rpm... Any help, links etc? I feel ashamed not > > knowing how to handle them!) test those patches asap, and will when i > > have tested them contact ccrma for licensing information etc. > > > > And if all goes well, ill find some gui for it - i have found kmid, but > > not tested it this far. Maybe find a GTK-based one as well, or persuade > > a friend of mine into learning me GTK :P if i cant find one (maybe make > > it python-based?). Then i will report back to bugzilla (which version? i > > am currently running FC2) with a RFE. > > > > Does that seem good? First time i acctually do any real work to enchase > > Fedora Core :D > > > > Kyrre Ness Sj?b?k > > > > s?n, 12.09.2004 kl. 16.57 skrev Janina Sajka: > > > Kyrre Ness Sjobak writes: > > > > s?n, 12.09.2004 kl. 01.11 skrev Janina Sajka: > > > > > Kyrre Ness Sjobak writes: > > > > > > Hmm... Does anybody know why Fedora haven't included a simple > > > > > > midi-player, which simply sends things to your soundcard for rendering, > > > > > > which in turn plays it?? And does anybody know about a good such > > > > > > program? > > > > > > > > > > > Huh? Did timidity++ disappear? Or, am I misunderstanding your question? > > > > > > > > ... ... > > > > > > > > Hmm... what if i (as many others) are so lucky to have a HW-based > > > > midi-playing soundcard (such as the AWE 64)? Methinks maybe they wants > > > > to use it... > > > > > > > > > > Are you aware of Planet CCRMA which is an entire distribution for > > > musicians based on Fedora? > > > > > > http://ccrma.stanford.edu/planetccrma/software/ > > > > > > I mention CCRMA because it's Fedora and rpm based and aimed at > > > professional musicians. > > > > > > However, I would also agree that support for driving MIDI instruments > > > directly is weak on Linux. So, I heartily second Jeff's suggestion to > > > get involved adding MIDI support to gstreamer--if that's something > > > you're able to contribute. > > > > > > > Could it be possible to do something like MS does - in the gstreamer > > > > setup, give an option to either use timidity (with a full patchset - the > > > > patches included don't even rival my old SB16, > > > > > > The CCRMA repository does have timidity with a better set of > > > instruments, fortunately. > > > > > > From j.w.r.degoede at hhs.nl Sat Sep 18 20:36:37 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 18 Sep 2004 22:36:37 +0200 Subject: [fedora.us] More bugzilla ticket reassignments In-Reply-To: <1095507285.2680.37.camel@kyrre> References: <20040917160459.10f4d645.fedora@wir-sind-cool.org> <1095455128.4904.2.camel@kyrre> <414BD462.6070701@hhs.nl> <1095507285.2680.37.camel@kyrre> Message-ID: <414C9C55.2070704@hhs.nl> > Another thing: Using timezone localisation selection to choose it, might > be a bad idea as some people in the US might decide they want it no > matter what. I mean - really - how namy here does REALLY care that > because of US patent law libdcss is illegal, and therefor boot windows > each time they want to watch a dvd on their pc? > As said, the name of the config screen should then be changed to choose your location. This is a good idea anyways to select: -metrics (I may use en_US as language, but I want european mainland metrics, iow making the language decission based on location is not a good idea, but for 99.9% choosing the metrics which are normal for the location is the right thing todo. This is what windows 9x does anyways, and it makes sense I know lot of people with english windows and dutch metrics. -mirrors for updates and repros -timezone -and also if to automaticly configure patent troubled repros. > No, let the users decide. Put a big box there, with warnings and > everything, and "yes/no" buttons. Debian does it, SuSE delivers mp3 etc, > and many other distros does to. US is not the world ;) > Way to scary for my mother, if you're american just add the repro manually like you have todo now. Besides by doing this automagicly I think (but IANAL) that fedora has a better defense in court, because we can say: -your honor we made our software so that it doesn't download the patented software in countries where there are patents on the software. But because Fedora is internationally used we choise to make it easier to get the patented softwarefor users in countries where there are no patents to get the software. BTW In neither scenario are we distributing the software. > BTW. according to Richard Stallman, the EU is going to have a new vote > on software patents in the beginning of october. Check out ffii.org for > more information. As far as i know, the case is that the parliment voted > "no" on sw patents last year, but the council still wants them (backed > my multi-billion corps like Nokia, Siemens, and Microsoft), and have > demanded a new hearing, in the beginning of October. > I know, everyone please contact your local eu parlement members about this. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From feliciano.matias at free.fr Sat Sep 18 20:48:35 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sat, 18 Sep 2004 22:48:35 +0200 Subject: please try SELinux again In-Reply-To: <1095536433.4655.18.camel@nexus.verbum.private> References: <1095536433.4655.18.camel@nexus.verbum.private> Message-ID: <1095540511.25149.34.camel@one.myworld> Le sam 18/09/2004 ? 21:40, Colin Walters a ?crit : > Hi, > > Talking with a number of people at the office, it seems a high > percentage of Fedora developers disabled SELinux during FC2 test2, I disabled SELinux. > which > was our first attempt at SELinux. Many other users and testers in the > Fedora community likely did so as well. > > I think a lot of people are not aware that things have changed (and > generally improved) dramatically since then. > What about a better documentation ? Release note of the last release tree (FC3t2) : o SELinux -- This includes a new "targeted" policy that monitors specifc daemons with less intrusion than the strict policy in use before. For more information, refer to: [2]https://listman.redhat.com/archives/fedora-selinux-list/2004-May/msg00096.html Is it enough for a newcomer ? From FC2 : Should you decide to enable SELinux, it is *strongly* recommended that you read the *Fedora Core SELinux FAQ*: http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ From http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ (FAQ!): For more information about how SELinux works, how to use SELinux for general and specific Linux distributions, and how to write policy, these resources are useful: NSA SELinux main website ? http://www.nsa.gov/selinux/ NSA SELinux FAQ ? http://www.nsa.gov/selinux/info/faq.cfm UnOfficial FAQ ? http://www.crypt.gen.nz/selinux/faq.html Writing SE Linux policy HOWTO ? https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=21266 Getting Started with SE Linux HOWTO: the new SE Linux (Debian) ? https://sourceforge.net/docman/display_doc.php?docid=20372&group_id=21266 On IRC ? irc.freenode.net, #fedora-selinux Fedora mailing list ? fedora-selinux-list at redhat.com; read the archives or subscribe at http://www.redhat.com/mailman/listinfo/fedora-selinux-list It's intimidating. > Instead of the original "strict" policy which covered everything, a new > "targeted" policy has been developed which only applies SELinux > restrictions to a few select system daemons. Regular user login > sessions are unrestricted. > > This targeted policy will be enabled by default for FC3. But those of > you who are upgrading from existing systems, if you earlier added > selinux=0 to your grub config, or disabled it in /etc/sysconfig/selinux, > will not be testing the new policy. > > Please: undo those changes, and give it another try. Be sure > that /etc/sysconfig/selinux has these two lines: > SELINUX=enforcing > SELINUXTYPE=targeted > > Also be sure you don't have selinux=0 in your grub configuration. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From walters at redhat.com Sat Sep 18 21:08:58 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 18 Sep 2004 17:08:58 -0400 Subject: please try SELinux again In-Reply-To: <1095540511.25149.34.camel@one.myworld> References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> Message-ID: <1095541738.4655.24.camel@nexus.verbum.private> On Sat, 2004-09-18 at 22:48 +0200, Matias Feliciano wrote: > Le sam 18/09/2004 ? 21:40, Colin Walters a ?crit : > > Hi, > > > > Talking with a number of people at the office, it seems a high > > percentage of Fedora developers disabled SELinux during FC2 test2, > > I disabled SELinux. Please try reenabling it, and file bugs against selinux-policy-targeted or send mail to fedora-selinux-list if you run into problems. > What about a better documentation ? > Release note of the last release tree (FC3t2) : > o SELinux -- This includes a new "targeted" policy that monitors > specifc daemons with less intrusion than the strict policy in use > before. For more information, refer to: > [2]https://listman.redhat.com/archives/fedora-selinux-list/2004-May/msg00096.html > > Is it enough for a newcomer ? It's a start, but we do really need a web page that describes the differences between the targeted and strict policies and how they work. > It's intimidating. It's not that bad, really. The new targeted policy should be mostly invisible. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From terraformers at gmx.net Sat Sep 18 21:08:27 2004 From: terraformers at gmx.net (Lars) Date: Sat, 18 Sep 2004 23:08:27 +0200 Subject: Probably a given - but udev-030-26 made my system unbootable (detailed) References: <20040918024436.GA3464@mark.mielke.cc> <8788673C-0960-11D9-8D68-000D9352858E@linuxmail.org> <1095519970.3696.8.camel@dhollis-lnx.kpmg.com> Message-ID: David Hollis wrote: > On Sat, 2004-09-18 at 12:50 +0200, Felipe Alfaro Solana wrote: >> On Sep 18, 2004, at 04:44, Mark Mielke wrote: >> >> > The first error was "Warning: unable to find a console" or something >> > to that >> > effect. The boot process paused. I manually created: >> > >> > crw------- 1 root root 5, 1 Sep 17 22:18 console >> > >> > Then, it complained about /dev/null not being writable. Sure enough, >> > /dev/null was a regular file with bytes in it. *sigh* Created that as: >> > >> > crw-rw-rw- 1 root root 1, 3 Feb 23 2004 null >> > >> > No luck. Booting still had major trouble. Finally I gave up: > > I actually noticed this after I upgraded my udev. Fortunately, I didn't > reboot! I checked out my /dev directory and noticed that null was a > regular file and there wasn't a heckuva lot in there. I > ran /sbin/udevstart and it recreated everything and life was good. When > I rebooted later things came up with no problems. > had the same non-booting problem and fixed it with running udevstart. now the only problem is that the console in rhgb and X (kde) doesn't show up anymore. any hints? thanks lars From terraformers at gmx.net Sat Sep 18 21:19:42 2004 From: terraformers at gmx.net (Lars) Date: Sat, 18 Sep 2004 23:19:42 +0200 Subject: please try SELinux again References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> Message-ID: Colin Walters wrote: > On Sat, 2004-09-18 at 22:48 +0200, Matias Feliciano wrote: >> Le sam 18/09/2004 ? 21:40, Colin Walters a ?crit : >> > Hi, >> > >> > Talking with a number of people at the office, it seems a high >> > percentage of Fedora developers disabled SELinux during FC2 test2, >> >> I disabled SELinux. > > Please try reenabling it, and file bugs against selinux-policy-targeted > or send mail to fedora-selinux-list if you run into problems. > >> What about a better documentation ? >> Release note of the last release tree (FC3t2) : >> o SELinux -- This includes a new "targeted" policy that monitors >> specifc daemons with less intrusion than the strict policy in >> use before. For more information, refer to: >> [2]https://listman.redhat.com/archives/fedora-selinux-list/2004-May/msg00096.html >> >> Is it enough for a newcomer ? > > It's a start, but we do really need a web page that describes the > differences between the targeted and stlirict policies and how they work. > >> It's intimidating. > > It's not that bad, really. The new targeted policy should be mostly > invisible. hi when i try to enable selinux it only boots to the message "setting up local disks" in rhgb and stays there. what i did: installed: libselinux, selinux-policy-targeted, policycoreutils and added to /etc/selinux/config SELINUX=enforcing SELINUXTYPE=targeted then run "fixfiles relabel" rebooted, hangs in rhgb. am i missing something ? cheers lars From walters at redhat.com Sat Sep 18 21:31:10 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 18 Sep 2004 17:31:10 -0400 Subject: please try SELinux again In-Reply-To: References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> Message-ID: <1095543070.4655.30.camel@nexus.verbum.private> On Sat, 2004-09-18 at 23:19 +0200, Lars wrote: > > when i try to enable selinux it only boots to the message > "setting up local disks" in rhgb and stays there. Hmm. Are you running the latest rawhide? Does it work again when you add enforcing=0 to the boot line? [We should move this discussion to fedora-selinux-list] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kyrre at solution-forge.net Sat Sep 18 21:27:48 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 18 Sep 2004 23:27:48 +0200 Subject: Midi-player for FC - an will there be anyone in FC3? In-Reply-To: <1095539276.6226.3.camel@kyrre> References: <1094938008.2715.59.camel@kyrre> <20040911231120.GF4297@rednote.net> <1094944811.4796.7.camel@kyrre> <20040912145741.GB7623@rednote.net> <1095093448.28790.7.camel@kyrre> <1095533078.4253.16.camel@kyrre> <1095539276.6226.3.camel@kyrre> Message-ID: <1095542868.6226.6.camel@kyrre> And once again ill answer myself. Bug is out at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132892 now somebody just has to write a (gtk?) frontend to timidity, as kmidi is dead. l?r, 18.09.2004 kl. 22.27 skrev Kyrre Ness Sjobak: > Hmm... forgot something... > Step 5.1: chmod -R 755 /usr/local/eawpats > > l?r, 18.09.2004 kl. 20.44 skrev Kyrre Ness Sjobak: > > Okay. It took a while, but right now i am listening to Time(Pink > > Floyd).mid in timidity with the "eawpats" patchset, and it sounds quite > > nice :D > > > > Here is what i did: > > > > 1. download the eawpats src.rpm (all other links was broken). Try to > > install it with rpm -ivh, find that it broke timidity (made it only spew > > a lot of garbage, f.ing up my terminal, and generally not do anything > > usefull). Reinstall timidity. > > 2. Open the source-rpm in fileroller. Find a .rar file inside it. Open > > that in file-roller. > > 3. Extract the rar. Encountered a bug in file-roller: if i opened a zip > > file (the src.rpm) in file-roller, and then opened another zip (the RAR > > archive inside), everything works out well. But if i then close the > > first window, and THEN try to unzip (unrar acctually) the rar, it simply > > does nothing. Absolutly nothing - think this might be some of the same > > case as this bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132478 > > 4. Try again, and extract the .rar into /usr/local/eawpats > > 5. Read "install.txt" carefully, and insert those lines at the end of > > /usr/share/timidity/timidity.cfg: > > > > #extra patches > > dir /usr/local/eawpats > > source gravis.cfg > > source gsdrums.cfg > > source gssfx.cfg > > source xgmap2.cfg > > > > 6. Play a midifile: > > [kyrre at kyrre MIDI]$ timidity -int Pink\ Floyd/Time.mid > > (the -int option gives a nice ncurces "gui" which shows some stats etc) > > Enjoy! > > > > I will now post a RFE to "distribution" on bugzilla. > > > > > > man, 13.09.2004 kl. 18.37 skrev Kyrre Ness Sjobak: > > > Yes, i have found it, and i am downloading the "eawpats" src.rpm right > > > now. (hmm... sound-font source-rpm?) I will (as soon as i have figured > > > out to do with a "source"-rpm... Any help, links etc? I feel ashamed not > > > knowing how to handle them!) test those patches asap, and will when i > > > have tested them contact ccrma for licensing information etc. > > > > > > And if all goes well, ill find some gui for it - i have found kmid, but > > > not tested it this far. Maybe find a GTK-based one as well, or persuade > > > a friend of mine into learning me GTK :P if i cant find one (maybe make > > > it python-based?). Then i will report back to bugzilla (which version? i > > > am currently running FC2) with a RFE. > > > > > > Does that seem good? First time i acctually do any real work to enchase > > > Fedora Core :D > > > > > > Kyrre Ness Sj?b?k > > > > > > s?n, 12.09.2004 kl. 16.57 skrev Janina Sajka: > > > > Kyrre Ness Sjobak writes: > > > > > s?n, 12.09.2004 kl. 01.11 skrev Janina Sajka: > > > > > > Kyrre Ness Sjobak writes: > > > > > > > Hmm... Does anybody know why Fedora haven't included a simple > > > > > > > midi-player, which simply sends things to your soundcard for rendering, > > > > > > > which in turn plays it?? And does anybody know about a good such > > > > > > > program? > > > > > > > > > > > > > Huh? Did timidity++ disappear? Or, am I misunderstanding your question? > > > > > > > > > > ... ... > > > > > > > > > > Hmm... what if i (as many others) are so lucky to have a HW-based > > > > > midi-playing soundcard (such as the AWE 64)? Methinks maybe they wants > > > > > to use it... > > > > > > > > > > > > > Are you aware of Planet CCRMA which is an entire distribution for > > > > musicians based on Fedora? > > > > > > > > http://ccrma.stanford.edu/planetccrma/software/ > > > > > > > > I mention CCRMA because it's Fedora and rpm based and aimed at > > > > professional musicians. > > > > > > > > However, I would also agree that support for driving MIDI instruments > > > > directly is weak on Linux. So, I heartily second Jeff's suggestion to > > > > get involved adding MIDI support to gstreamer--if that's something > > > > you're able to contribute. > > > > > > > > > Could it be possible to do something like MS does - in the gstreamer > > > > > setup, give an option to either use timidity (with a full patchset - the > > > > > patches included don't even rival my old SB16, > > > > > > > > The CCRMA repository does have timidity with a better set of > > > > instruments, fortunately. > > > > > > > > > > From feliciano.matias at free.fr Sat Sep 18 21:30:50 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sat, 18 Sep 2004 23:30:50 +0200 Subject: please try SELinux again In-Reply-To: <1095541738.4655.24.camel@nexus.verbum.private> References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> Message-ID: <1095543044.25149.57.camel@one.myworld> Le sam 18/09/2004 ? 23:08, Colin Walters a ?crit : > > It's not that bad, really. The new targeted policy should be mostly > invisible. So, write it somewhere. Describe in few words what is the targeted (and strict?) policy. Example : apache user : /etc/httpd: ro; /var/www: rw, ... id >= 500 : / : rw etc. If you ask me if I know what I am doing by enabling SELinux, right now the answer is : - I don't know. OK, it's also my fault. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From jspaleta at gmail.com Sat Sep 18 21:37:08 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 18 Sep 2004 17:37:08 -0400 Subject: please try SELinux again In-Reply-To: <1095541738.4655.24.camel@nexus.verbum.private> References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> Message-ID: <604aa79104091814374b867522@mail.gmail.com> On Sat, 18 Sep 2004 17:08:58 -0400, Colin Walters wrote: > It's not that bad, really. The new targeted policy should be mostly > invisible. Well for a fresh install of rawhide or the test release... i would agree. But for someone doing an ungrade from a system that did have selinux enabled... does it 'just work'? I thought there was some magic incantations involved with relabeling filesystems even with targetted policy for systems that previously had selinux disabled. -jef From walters at redhat.com Sat Sep 18 22:42:48 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 18 Sep 2004 18:42:48 -0400 Subject: please try SELinux again In-Reply-To: <604aa79104091814374b867522@mail.gmail.com> References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> <604aa79104091814374b867522@mail.gmail.com> Message-ID: <1095547368.4655.35.camel@nexus.verbum.private> On Sat, 2004-09-18 at 17:37 -0400, Jeff Spaleta wrote: > On Sat, 18 Sep 2004 17:08:58 -0400, Colin Walters wrote: > > It's not that bad, really. The new targeted policy should be mostly > > invisible. > > Well for a fresh install of rawhide or the test release... i would agree. > But for someone doing an ungrade from a system that did have selinux > enabled... does it 'just work'? I thought there was some magic > incantations involved with relabeling filesystems even with targetted > policy for systems that previously had selinux disabled. Yes, a relabel will happen the first time you run with SELinux enabled again after having it disabled. It will take a while, but it should work. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ndbecker2 at verizon.net Sat Sep 18 23:03:46 2004 From: ndbecker2 at verizon.net (Neal Becker) Date: Sat, 18 Sep 2004 19:03:46 -0400 Subject: gcc35?? Message-ID: I noticed that rawhide has gcc35. Looking at gcc site, it seems there will not be gcc35, but gcc4. http://gcc.gnu.org/develop.html#timeline From dcbw at redhat.com Sat Sep 18 23:27:30 2004 From: dcbw at redhat.com (Dan Williams) Date: Sat, 18 Sep 2004 19:27:30 -0400 Subject: gcc35?? In-Reply-To: References: Message-ID: <1095550050.5190.5.camel@dcbw.boston.redhat.com> That was only recently decided, but gcc 3.5 development has been going on for a while in parallel with other branches. So its not really surprising that there's a gcc35 package, it should be renamed to gcc4 fairly soon. Dan On Sat, 2004-09-18 at 19:03 -0400, Neal Becker wrote: > I noticed that rawhide has gcc35. Looking at gcc site, it seems there will > not be gcc35, but gcc4. > > http://gcc.gnu.org/develop.html#timeline > > > From terraformers at gmx.net Sat Sep 18 23:57:52 2004 From: terraformers at gmx.net (Lars) Date: Sun, 19 Sep 2004 01:57:52 +0200 Subject: Probably a given - but udev-030-26 made my system unbootable (detailed) References: <20040918024436.GA3464@mark.mielke.cc> <8788673C-0960-11D9-8D68-000D9352858E@linuxmail.org> <1095519970.3696.8.camel@dhollis-lnx.kpmg.com> Message-ID: Lars wrote: > David Hollis wrote: > >> On Sat, 2004-09-18 at 12:50 +0200, Felipe Alfaro Solana wrote: >>> On Sep 18, 2004, at 04:44, Mark Mielke wrote: >>> >>> > The first error was "Warning: unable to find a console" or something >>> > to that >>> > effect. The boot process paused. I manually created: >>> > >>> > crw------- 1 root root 5, 1 Sep 17 22:18 console >>> > >>> > Then, it complained about /dev/null not being writable. Sure enough, >>> > /dev/null was a regular file with bytes in it. *sigh* Created that as: >>> > >>> > crw-rw-rw- 1 root root 1, 3 Feb 23 2004 null >>> > >>> > No luck. Booting still had major trouble. Finally I gave up: >> >> I actually noticed this after I upgraded my udev. Fortunately, I didn't >> reboot! I checked out my /dev directory and noticed that null was a >> regular file and there wasn't a heckuva lot in there. I >> ran /sbin/udevstart and it recreated everything and life was good. When >> I rebooted later things came up with no problems. >> > > > had the same non-booting problem and fixed it with running udevstart. > now the only problem is that the console in rhgb and X (kde) doesn't > show up anymore. > > any hints? > > > thanks > lars > > > update: fixed(!) my x console problem by adding the pts dir to /dev that was missing after running udevstart. lars From feliciano.matias at free.fr Sun Sep 19 03:00:39 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sun, 19 Sep 2004 05:00:39 +0200 Subject: rawhide report: 20040917 changes In-Reply-To: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> References: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> Message-ID: <1095562835.1110.9.camel@one.myworld> Le ven 17/09/2004 ? 13:53, Build System a ?crit : > udev-030-26 > ----------- > * Mon Sep 13 2004 Jeremy Katz - 030-26 > > - require a 2.6 kernel > - prereq instead of requires MAKEDEV > - obsolete and provide dev > - add a trigger for the removal of /dev so that we set things up FC3-re0908.0 on /dev/hdc1. Update to rawhide 20040917. from FC2 : [root at one root]# mount -t ext3 /dev/hdc1 /mnt/hdc1 [root at one root]# rpm -q --dbpath /mnt/hdc1/var/lib/rpm/ dev le paquetage dev n'est pas install? [root at one root]# find /mnt/hdc1/dev | wc -l 19576 [root at one root]# rpm -q --dbpath /mnt/hdc1/var/lib/rpm/ -l -a | grep ^/dev /dev/initctl [root at one root]# rpm -q -f /dev/initctl SysVinit-2.85-25 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From j.w.r.degoede at hhs.nl Sun Sep 19 06:13:37 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 19 Sep 2004 08:13:37 +0200 Subject: please try SELinux again In-Reply-To: <1095547368.4655.35.camel@nexus.verbum.private> References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> <604aa79104091814374b867522@mail.gmail.com> <1095547368.4655.35.camel@nexus.verbum.private> Message-ID: <414D2391.9020400@hhs.nl> Colin Walters wrote: > On Sat, 2004-09-18 at 17:37 -0400, Jeff Spaleta wrote: > >>On Sat, 18 Sep 2004 17:08:58 -0400, Colin Walters wrote: >> >>>It's not that bad, really. The new targeted policy should be mostly >>>invisible. >> >>Well for a fresh install of rawhide or the test release... i would agree. >>But for someone doing an ungrade from a system that did have selinux >>enabled... does it 'just work'? I thought there was some magic >>incantations involved with relabeling filesystems even with targetted >>policy for systems that previously had selinux disabled. > > > Yes, a relabel will happen the first time you run with SELinux enabled > again after having it disabled. It will take a while, but it should > work. > Erm, that didn't happen for me (running the relabel) resulting in a system with a non-working X. Booting in single mode and running fixfiles myself fixed things for me. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From music-cornette at sbcglobal.net Sun Sep 19 06:54:00 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Sun, 19 Sep 2004 02:54:00 -0400 Subject: Probably a given - but udev-030-26 made my system unbootable (detailed) In-Reply-To: <1095519970.3696.8.camel@dhollis-lnx.kpmg.com> References: <20040918024436.GA3464@mark.mielke.cc> <8788673C-0960-11D9-8D68-000D9352858E@linuxmail.org> <1095519970.3696.8.camel@dhollis-lnx.kpmg.com> Message-ID: <414D2D08.90406@sbcglobal.net> David Hollis wrote: >On Sat, 2004-09-18 at 12:50 +0200, Felipe Alfaro Solana wrote: > > >>On Sep 18, 2004, at 04:44, Mark Mielke wrote: >> >> >> >>>The first error was "Warning: unable to find a console" or something >>>to that >>>effect. The boot process paused. I manually created: >>> >>> crw------- 1 root root 5, 1 Sep 17 22:18 console >>> >>>Then, it complained about /dev/null not being writable. Sure enough, >>>/dev/null was a regular file with bytes in it. *sigh* Created that as: >>> >>> crw-rw-rw- 1 root root 1, 3 Feb 23 2004 null >>> >>>No luck. Booting still had major trouble. Finally I gave up: >>> >>> > >I actually noticed this after I upgraded my udev. Fortunately, I didn't >reboot! I checked out my /dev directory and noticed that null was a >regular file and there wasn't a heckuva lot in there. I >ran /sbin/udevstart and it recreated everything and life was good. When >I rebooted later things came up with no problems. > > > When I freshly installed a system using the RC1 candidate isos, I had trouble until I took the advice of an RH employee and ran udestart as root and had trouble until I rebooted the computer. Before running this command manually, I could not burn CDs. This is not as bad as not booting, but a pecularity. Jim -- Ha. For once you're both wrong but not where you are thinking. - Larry McVoy to Linus Torvalds on linux-kernel -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at coker.com.au Sun Sep 19 08:13:35 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 19 Sep 2004 18:13:35 +1000 Subject: [usclug-chat] cyrus-imapd causes hardlock? In-Reply-To: <4148A823.1080600@imapmail.org> References: <4148A823.1080600@imapmail.org> Message-ID: <200409191813.35231.russell@coker.com.au> On Thu, 16 Sep 2004 06:37, Eric Hattemer wrote: > Is it possible for cyrus and postfix to cause a hardlock when no other > programs seem to? 1-10 minutes after I start my mail server, the system > hardlocks. I can record and transcode gigabytes of tv shows, run a web > server, download and upload tons of stuff, and test the system in any > way with no problems. Windows has no problems. Yet when I start cyrus, Mail servers hit the disk harder than most programs. The indexing operation you refer to probably more than most operations. Try running some disk benchmark programs on the system and see if you can reproduce the problem with a simpler program. The simpler the test case that causes it the easier things will be for people who try and work out what the problem is. Incidentally Linux seems to be more intensive in it's use of hard disks. Some years ago a company I worked for was purchasing hard disks from a company that had just bought out a competitor. Due to the purchase there were two different models of disk in each common size (one from each company) that had the same part numbers. One of those disks would work perfectly in Linux systems and the other would predictably lose data after about 1-2 weeks! Both types of disk worked OK in Windows systems. The company shipped their entire stock of bad disks to Windows users (who didn't complain) and I faxed a photo-copy of one of the bad disks to the wholesaler with the message "please send no more disks that look like this". -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From veillard at redhat.com Sun Sep 19 09:16:39 2004 From: veillard at redhat.com (Daniel Veillard) Date: Sun, 19 Sep 2004 05:16:39 -0400 Subject: please try SELinux again In-Reply-To: References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> Message-ID: <20040919091639.GV20796@redhat.com> On Sat, Sep 18, 2004 at 11:19:42PM +0200, Lars wrote: > when i try to enable selinux it only boots to the message > "setting up local disks" in rhgb and stays there. probably unrelated. If you see disk access it's probably fsck'ing one of your disks. Fix for the rhgb problem itself have been pushed to the build system. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alan at redhat.com Sun Sep 19 11:14:44 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 19 Sep 2004 07:14:44 -0400 Subject: [usclug-chat] cyrus-imapd causes hardlock? In-Reply-To: <200409191813.35231.russell@coker.com.au> References: <4148A823.1080600@imapmail.org> <200409191813.35231.russell@coker.com.au> Message-ID: <20040919111444.GA19375@devserv.devel.redhat.com> On Sun, Sep 19, 2004 at 06:13:35PM +1000, Russell Coker wrote: > Incidentally Linux seems to be more intensive in it's use of hard disks. Some > years ago a company I worked for was purchasing hard disks from a company > that had just bought out a competitor. Due to the purchase there were two > different models of disk in each common size (one from each company) that had I think its more differently than harder. Especially with scsi drivers it is often worth looking for firmware updates when you see that kind of problem From buildsys at redhat.com Sun Sep 19 11:53:56 2004 From: buildsys at redhat.com (Build System) Date: Sun, 19 Sep 2004 07:53:56 -0400 Subject: rawhide report: 20040919 changes Message-ID: <200409191153.i8JBrua08133@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-2.91-0.20040919 ---------------------------- From walters at redhat.com Sun Sep 19 15:18:09 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 19 Sep 2004 11:18:09 -0400 Subject: please try SELinux again In-Reply-To: <414D2391.9020400@hhs.nl> References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> <604aa79104091814374b867522@mail.gmail.com> <1095547368.4655.35.camel@nexus.verbum.private> <414D2391.9020400@hhs.nl> Message-ID: <1095607089.4655.51.camel@nexus.verbum.private> On Sun, 2004-09-19 at 08:13 +0200, Hans de Goede wrote: > Erm, that didn't happen for me (running the relabel) resulting in a > system with a non-working X. Booting in single mode and running fixfiles > myself fixed things for me. Ok, it looks like the automatic relabeling only happens if you use system-config-securitylevel to re-enable SELinux. So it's probably a good idea to use that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Sun Sep 19 15:26:03 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 19 Sep 2004 17:26:03 +0200 Subject: please try SELinux again In-Reply-To: <1095607089.4655.51.camel@nexus.verbum.private> References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> <604aa79104091814374b867522@mail.gmail.com> <1095547368.4655.35.camel@nexus.verbum.private> <414D2391.9020400@hhs.nl> <1095607089.4655.51.camel@nexus.verbum.private> Message-ID: <414DA50B.2080202@hhs.nl> Colin Walters wrote: > On Sun, 2004-09-19 at 08:13 +0200, Hans de Goede wrote: > > >>Erm, that didn't happen for me (running the relabel) resulting in a >>system with a non-working X. Booting in single mode and running fixfiles >>myself fixed things for me. > > > Ok, it looks like the automatic relabeling only happens if you use > system-config-securitylevel to re-enable SELinux. So it's probably a > good idea to use that. > > Ok, Will the installer run fixfiles on an upgrade? I really think it should! and not just on the packages, but on all files on the system, so also homedirs etc. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From walters at redhat.com Sun Sep 19 23:20:16 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 19 Sep 2004 19:20:16 -0400 Subject: backups Message-ID: <1095636016.4431.59.camel@nexus.verbum.private> So, it seems to me that our backup software situation is really a mess. One particular feature that I absolutely need is xattr support, because all my machines run SELinux. My personal server also uses ACLs for a few files. As far as I can tell, the *only* software we ship that even supports xattrs at all is "star". However star has the enormous drawback that it doesn't support incremental dumps. This makes it nearly useless for me since my server has various ISO images and the like lying around, and re-archiving them for each backup would quickly eat space. Also, star is written by someone who has displayed a fundamental misunderstanding of the GPL. Now, rsync has an experimental patch for xattr support: http://lists.samba.org/archive/rsync/2003-June/006413.html But we don't apply it. We'd also need an additional SELinux-specific patch to make it use setfscreatecon to avoid a race condition. It doesn't look to me like librsync supports xattrs either, so none of the programs based on it like rdiff-backup will. However, even if we had an xattr+SELinux-capable rsync, I think we'd still need a tar-like archiver (one better than star). I did a bit of searching on this and found "dar": http://dar.linux.free.fr/ Has anyone used this program? It looks to be quite nice; if we can just add the specific SELinux support I think it would be a good replacement for star. I particularly like how its incremental backups support deleting files too. I'm a bit unsure of whether its xattr support implies ACL support. Are there any other programs I missed? Particularly ones that people out there actually use? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwz at jwz.org Mon Sep 20 00:03:51 2004 From: jwz at jwz.org (Jamie Zawinski) Date: Sun, 19 Sep 2004 17:03:51 -0700 Subject: backups References: <1095636016.4431.59.camel@nexus.verbum.private> Message-ID: <414E1E67.5B906EBF@jwz.org> Colin Walters wrote: > > As far as I can tell, the *only* software we ship that even supports > xattrs at all is "star". However star has the enormous drawback ... Wouldn't it be more sensible to extend "tar" to support xattrs? tar file headers are 512 bytes long; "traditional" tar used only 256 of those bytes, and GNU tar added additional fields out to 345 bytes. That leaves 167 bytes left over, and stuffing extra data in there would be backward compatible (both older tar implementations would simply ignore it.) -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ From walters at redhat.com Mon Sep 20 00:10:32 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 19 Sep 2004 20:10:32 -0400 Subject: backups In-Reply-To: <414E1E67.5B906EBF@jwz.org> References: <1095636016.4431.59.camel@nexus.verbum.private> <414E1E67.5B906EBF@jwz.org> Message-ID: <1095639032.4431.90.camel@nexus.verbum.private> On Sun, 2004-09-19 at 17:03 -0700, Jamie Zawinski wrote: > Colin Walters wrote: > > > > As far as I can tell, the *only* software we ship that even supports > > xattrs at all is "star". However star has the enormous drawback ... > > Wouldn't it be more sensible to extend "tar" to support xattrs? My impression was that several people have looked at modifying GNU tar to support xattrs, and ended up running away screaming... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpm at ec-group.com Sun Sep 19 23:32:25 2004 From: bpm at ec-group.com (Brian Millett) Date: Sun, 19 Sep 2004 18:32:25 -0500 (CDT) Subject: please try SELinux again Message-ID: <33045.66.137.209.11.1095636745.squirrel@webmail.ec-group.com> Ok, I used the system-config-securitylevel to turn on the SELinux security. But I noticed a BAD side affect. I am using a custom iptables, Using the securitylevel tool turned off the iptables by deleteing the /etc/sysconfig/iptables file. Good thing for backups :-). So how do I use the securitylevel tool without touching iptables? Can't. Too bad because after turning on SELinux, httpd will not start. I get the following error: Starting httpd: Syntax error on line 68 of /etc/httpd/conf.d/ssl.conf: SSLRandomSeed: source path '/dev/urandom' does not exist [FAILED] Ok, so what does /var/log/messages say.... Nothing because for some reason, nothing is being logged. If I go to tty1 and try it, I get abunch of the following trace messages: audit(1095634287.733:0): avc: denied { read write } for pid=10192 exe=/sbin/minilogd name=tty2 dev=tmpfs ino=1566 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file audit(1095634287.733:0): avc: denied { read write } for pid=10192 exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file audit(1095634287.733:0): avc: denied { read write } for pid=10192 exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file audit(1095634287.734:0): avc: denied { read write } for pid=10192 exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file audit(1095634287.734:0): avc: denied { search } for pid=10192 exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir audit(1095634287.735:0): avc: denied { search } for pid=10192 exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir audit(1095634287.742:0): avc: denied { search } for pid=10192 exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir audit(1095634287.754:0): avc: denied { read write } for pid=10194 exe=/sbin/minilogd name=tty2 dev=tmpfs ino=1566 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file audit(1095634287.762:0): avc: denied { read write } for pid=10194 exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file audit(1095634287.771:0): avc: denied { read write } for pid=10194 exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file audit(1095634287.779:0): avc: denied { read write } for pid=10194 exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file audit(1095634287.787:0): avc: denied { search } for pid=10194 exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir audit(1095634287.795:0): avc: denied { search } for pid=10194 exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir audit(1095634287.803:0): avc: denied { search } for pid=10194 exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir So to get httpd to work, I need to reinvoke the securitylevel gui and select transition->Disable Selinux protection for httpd daemon So, if you count not being able to run httpd and no system logs, it is going ok. -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From perbj at stanford.edu Mon Sep 20 00:30:21 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Sun, 19 Sep 2004 17:30:21 -0700 Subject: "Stateless Linux" project In-Reply-To: <1095210422.2701.215.camel@localhost.localdomain> References: <200409141740.i8EHe7116304@ayesha.phys.Virginia.EDU> <1095195763.4127.74.camel@localhost.localdomain> <1095204673.2701.147.camel@localhost.localdomain> <1095205721.4127.126.camel@localhost.localdomain> <1095210422.2701.215.camel@localhost.localdomain> Message-ID: <1095640221.12517.10.camel@ferrari.localdomain> On Tue, 2004-09-14 at 18:07, Per Bjornsson wrote: > As a side note, I personally actually don't think that the Unison > interface (where you get a list of changed files and can choose in which > direction to propagate conflicting changes or choose to rename one of > the files in case of conflicts) is too bad, but I'm probably way to > geeky to be part of the target audience. Just adding some information here: The two-way synchronizer Unison, which I referred to here, is in the Fedora.us QA queue; I updated the package to the latest beta version (2.10.2). The Bugzilla URL is http://bugzilla.fedora.us/show_bug.cgi?id=1069 for the benefit of anyone who wants to try out two-way sync tools. I find this extremely useful and I think that this might be part of a useful model for cached clients. (I'm not really sure if Unison is the perfect implementation, in part since it's written in the mildly obscure language Ocaml, but I think it's a nice demo of the possibilities.) The Unison home page is located at http://www.cis.upenn.edu/~bcpierce/unison/ . /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From shiva at sewingwitch.com Mon Sep 20 00:39:47 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 19 Sep 2004 17:39:47 -0700 Subject: backups In-Reply-To: <1095636016.4431.59.camel@nexus.verbum.private> References: <1095636016.4431.59.camel@nexus.verbum.private> Message-ID: <686E0A883A76045ABCE09B7D@[10.0.0.4]> --On Sunday, September 19, 2004 7:20 PM -0400 Colin Walters wrote: > One particular feature that I absolutely need is xattr support, because > all my machines run SELinux. My personal server also uses ACLs for a > few files. Are these all features of ext3? If so, wouldn't dump do the job? From i at stingr.net Mon Sep 20 00:58:48 2004 From: i at stingr.net (Paul P Komkoff Jr) Date: Mon, 20 Sep 2004 04:58:48 +0400 Subject: backups In-Reply-To: <1095636016.4431.59.camel@nexus.verbum.private> References: <1095636016.4431.59.camel@nexus.verbum.private> Message-ID: <20040920005848.GE31381@stingr.sgu.ru> Replying to Colin Walters: > It doesn't look to me like librsync supports xattrs either, so none of > the programs based on it like rdiff-backup will. rdiff-backup only uses librsync to calculate increments of file data. By its design stuff like xattr and acl belong to file metadata. It can store them too but if corresponding python modules (pylibacl and pyxattr) available -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From jspaleta at gmail.com Mon Sep 20 01:22:32 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 19 Sep 2004 21:22:32 -0400 Subject: backups In-Reply-To: <20040920005848.GE31381@stingr.sgu.ru> References: <1095636016.4431.59.camel@nexus.verbum.private> <20040920005848.GE31381@stingr.sgu.ru> Message-ID: <604aa79104091918225ee409e3@mail.gmail.com> On Mon, 20 Sep 2004 04:58:48 +0400, Paul P Komkoff Jr wrote: > rdiff-backup only uses librsync to calculate increments of file data. > By its design stuff like xattr and acl belong to file metadata. It can > store them too but if corresponding python modules (pylibacl and > pyxattr) available to be precise... support for pyxattr and pylibacl are in the development 0.13 branch of rdiff-backup and not in the stable 0.12 branch. Maybe if we all make puppy dog faces in Colin's general direction we can guilt him into taking a look at the 0.13.4 rdiff-backup release and seeing how good the xattr support is. -jef"watches as Colin fires a technical bullet at point blank range at rdiff-backup and watches it bounce harmlessly off."spaleta From walters at redhat.com Mon Sep 20 01:48:04 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 19 Sep 2004 21:48:04 -0400 Subject: backups In-Reply-To: <686E0A883A76045ABCE09B7D@[10.0.0.4]> References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> Message-ID: <1095644884.4431.94.camel@nexus.verbum.private> On Sun, 2004-09-19 at 17:39 -0700, Kenneth Porter wrote: > --On Sunday, September 19, 2004 7:20 PM -0400 Colin Walters > wrote: > > > One particular feature that I absolutely need is xattr support, because > > all my machines run SELinux. My personal server also uses ACLs for a > > few files. > > Are these all features of ext3? If so, wouldn't dump do the job? Well, it's not quite the same thing. You can't safely dump a live filesystem, making it unusable for me. Also it's far less granular than an archiver like tar or dar. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwz at jwz.org Mon Sep 20 01:50:27 2004 From: jwz at jwz.org (Jamie Zawinski) Date: Sun, 19 Sep 2004 18:50:27 -0700 Subject: backups References: <1095636016.4431.59.camel@nexus.verbum.private> <414E1E67.5B906EBF@jwz.org> <1095639032.4431.90.camel@nexus.verbum.private> Message-ID: <414E3763.33C96FD5@jwz.org> Colin Walters wrote: > > My impression was that several people have looked at modifying GNU tar > to support xattrs, and ended up running away screaming... That doesn't mean it's the wrong thing to do! Deprecating tar doesn't sound like a winning idea to me. Surely someone will make their sanity saving throw. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ From walters at redhat.com Mon Sep 20 02:06:54 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 19 Sep 2004 22:06:54 -0400 Subject: backups In-Reply-To: <414E3763.33C96FD5@jwz.org> References: <1095636016.4431.59.camel@nexus.verbum.private> <414E1E67.5B906EBF@jwz.org> <1095639032.4431.90.camel@nexus.verbum.private> <414E3763.33C96FD5@jwz.org> Message-ID: <1095646014.4431.101.camel@nexus.verbum.private> On Sun, 2004-09-19 at 18:50 -0700, Jamie Zawinski wrote: > Colin Walters wrote: > > > > My impression was that several people have looked at modifying GNU tar > > to support xattrs, and ended up running away screaming... > > That doesn't mean it's the wrong thing to do! Deprecating tar doesn't > sound like a winning idea to me. Yeah, I agree. On the other hand though some of the newer formats like dar's have more advantages besides xattrs, like handling file deletions, and being indexed. So we might actually want both; tar for people still clinging to their tape drives, and something like dar for people backing up to disk. > Surely someone will make their sanity saving throw. Heh. Maybe, but I think we're talking about a level 50 Cruft here... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Mon Sep 20 02:21:56 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 19 Sep 2004 22:21:56 -0400 Subject: backups In-Reply-To: <604aa79104091918225ee409e3@mail.gmail.com> References: <1095636016.4431.59.camel@nexus.verbum.private> <20040920005848.GE31381@stingr.sgu.ru> <604aa79104091918225ee409e3@mail.gmail.com> Message-ID: <1095646916.4431.105.camel@nexus.verbum.private> On Sun, 2004-09-19 at 21:22 -0400, Jeff Spaleta wrote: > to be precise... support for pyxattr and pylibacl are in the > development 0.13 branch of rdiff-backup and not in the stable 0.12 > branch. Maybe if we all make puppy dog faces in Colin's general > direction we can guilt him into taking a look at the 0.13.4 > rdiff-backup release and seeing how good the xattr support is. Testing beta backup software. My favorite thing to do :) Seriously though, while that is good news, I think we still need a good archiver. For example, I'd like to be able to encrypt my backups and drop them onto untrusted media. Or even just back up to a filesystem without xattr or SELinux support. You can't do that with rdiff-backup. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Mon Sep 20 02:22:03 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 19 Sep 2004 22:22:03 -0400 Subject: backups In-Reply-To: <1095646916.4431.105.camel@nexus.verbum.private> References: <1095636016.4431.59.camel@nexus.verbum.private> <20040920005848.GE31381@stingr.sgu.ru> <604aa79104091918225ee409e3@mail.gmail.com> <1095646916.4431.105.camel@nexus.verbum.private> Message-ID: <1095646923.15450.23.camel@binkley> On Sun, 2004-09-19 at 22:21 -0400, Colin Walters wrote: > On Sun, 2004-09-19 at 21:22 -0400, Jeff Spaleta wrote: > > > to be precise... support for pyxattr and pylibacl are in the > > development 0.13 branch of rdiff-backup and not in the stable 0.12 > > branch. Maybe if we all make puppy dog faces in Colin's general > > direction we can guilt him into taking a look at the 0.13.4 > > rdiff-backup release and seeing how good the xattr support is. > > Testing beta backup software. My favorite thing to do :) > > Seriously though, while that is good news, I think we still need a good > archiver. For example, I'd like to be able to encrypt my backups and > drop them onto untrusted media. Or even just back up to a filesystem > without xattr or SELinux support. You can't do that with rdiff-backup. > look at duplicity. -sv From walters at redhat.com Mon Sep 20 02:34:13 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 19 Sep 2004 22:34:13 -0400 Subject: backups In-Reply-To: <1095646923.15450.23.camel@binkley> References: <1095636016.4431.59.camel@nexus.verbum.private> <20040920005848.GE31381@stingr.sgu.ru> <604aa79104091918225ee409e3@mail.gmail.com> <1095646916.4431.105.camel@nexus.verbum.private> <1095646923.15450.23.camel@binkley> Message-ID: <1095647653.4431.109.camel@nexus.verbum.private> On Sun, 2004-09-19 at 22:22 -0400, seth vidal wrote: > look at duplicity. duplicity uses (presumably GNU) tar, which brings us full-circle :) There is a page where the duplicity people talk about tar's flaws and what a new archive format might look like: http://www.nongnu.org/duplicity/new_format.html But it's just a design, not an implementation. dar is an implementation, which makes it much more interesting :) But so far no one has commented on dar. I was hoping someone out there would at least say "yes, i use it, it rocks!" or "yes, i tried it, it sucks!"... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From shiva at sewingwitch.com Mon Sep 20 03:09:03 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 19 Sep 2004 20:09:03 -0700 Subject: backups In-Reply-To: <1095644884.4431.94.camel@nexus.verbum.private> References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> Message-ID: --On Sunday, September 19, 2004 9:48 PM -0400 Colin Walters wrote: > Well, it's not quite the same thing. You can't safely dump a live > filesystem, making it unusable for me. An explanation of the issue and why it not be an issue, depending on the situation: > Also it's far less granular than an archiver like tar or dar. It sounded like you were doing filesystem-level backups (including incrementals), not archives of isolated directory trees. Dump is very good for that. Do you use any sparely allocated files? How is tar at handling those? Dump's restore will restore all the holes as holes, instead of allocating zero-filled disk blocks. From skvidal at phy.duke.edu Mon Sep 20 03:17:14 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 19 Sep 2004 23:17:14 -0400 Subject: backups In-Reply-To: References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> Message-ID: <1095650234.15450.25.camel@binkley> On Sun, 2004-09-19 at 20:09 -0700, Kenneth Porter wrote: > --On Sunday, September 19, 2004 9:48 PM -0400 Colin Walters > wrote: > > > Well, it's not quite the same thing. You can't safely dump a live > > filesystem, making it unusable for me. > > An explanation of the issue and why it not be an issue, depending on the > situation: > > > > > Also it's far less granular than an archiver like tar or dar. > > It sounded like you were doing filesystem-level backups (including > incrementals), not archives of isolated directory trees. Dump is very good > for that. > > Do you use any sparely allocated files? How is tar at handling those? > Dump's restore will restore all the holes as holes, instead of allocating > zero-filled disk blocks. tar has a flag for handling sparse files. -sv From walters at redhat.com Mon Sep 20 03:32:27 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 19 Sep 2004 23:32:27 -0400 Subject: backups In-Reply-To: References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> Message-ID: <1095651147.4431.121.camel@nexus.verbum.private> On Sun, 2004-09-19 at 20:09 -0700, Kenneth Porter wrote: > --On Sunday, September 19, 2004 9:48 PM -0400 Colin Walters > wrote: > > > Well, it's not quite the same thing. You can't safely dump a live > > filesystem, making it unusable for me. > > An explanation of the issue and why it not be an issue, depending on the > situation: > > If Linus says a program will eat my data and is generally stupid, I tend to believe him :) > > Also it's far less granular than an archiver like tar or dar. > > It sounded like you were doing filesystem-level backups (including > incrementals), not archives of isolated directory trees. Dump is very good > for that. Not really - I'm only interested in backing up a few things like home directories, web sites, and possibly /etc. Right now I just have one big partition so dump would back up e.g. all of /usr, which isn't needed for me. Also, dump's filesystem-specific nature is very annoying. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Mon Sep 20 04:34:06 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 19 Sep 2004 18:34:06 -1000 Subject: What to do about libc-client (imap)? Message-ID: <414E5DBE.1090208@redhat.com> https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=imap&component=libc-client&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&Search=Search imap has been a total disaster in the past, and now we provide both dovecot and cyrus-imapd as robust alternatives. Since FC2, imap was stripped down to the "c-client" library with no server functionality. The only reason we keep libc-client, the library portion of imap, is so php-imap can build. But why do we keep php-imap? NOTHING we ship uses it. squirrelmail long ago decided php-imap was unreliable and made their own implementation. Our forced attempts to get rid of imap in FC2 were done in a confusing manner which remains both a support burden for us, and a huge point of frustration to users. [1] To make matters worse, 'libc-client' is a confusing name which is too similar to 'glibc', and meaningless to all developers. Is this really worth more years of headache? Here are two proposals to deal with this. Proposed Option #1: Rename libc-client to imap-libs =================================================== Bug #120873 outlines a workable alternative where * Package name is no longer misleading. * Installed in such a way to not conflict in files or deps with imap. * imap in Extras, completely unsupported by Red Hat. Pros: Reduced support burden on us as we wont have many more stupid reports [1] from foolish users complaining that we've taken away their ability to use an insecure, buggy and slow mail server. Cons: We still would have responsibility of php-imap, which very few people use. Proposed Option #2: Get rid of imap/libc-client completely ========================================================== * Remove imap and libc-client from all future distributions. * imap in Extras, completely unsupported by Red Hat. Pros: No support burden for us. Foolish users can use it if they really wish. Cons: Difficult (but not impossible) to build php-imap Not our problem. Extras can provide this. I personally would much prefer Option #2 because it reduces the support burden on Red Hat, for software that NONE of us care about. Any other opinions? Warren Togami wtogami at redhat.com [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132928 Some guy complains about imap conflicting with libc-client "for no reason". https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132933 The same guy realizes imap sucks, and says dovecot should Obsolete imap. I point at Bug #120678 below as an example of why this is a bad idea. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120678 libc-client conflicts with cyrus-imapd (Earlier failed attempt to forcefully remove imap) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123580 Confusion due to php-imap... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120873 Rename libc-client to imap-libs. This or removal of libc-client are our best options. From mattdm at mattdm.org Mon Sep 20 04:55:58 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Sep 2004 00:55:58 -0400 Subject: backups In-Reply-To: <1095644884.4431.94.camel@nexus.verbum.private> References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> Message-ID: <20040920045558.GA618@jadzia.bu.edu> On Sun, Sep 19, 2004 at 09:48:04PM -0400, Colin Walters wrote: > Well, it's not quite the same thing. You can't safely dump a live > filesystem, making it unusable for me. Also it's far less granular than > an archiver like tar or dar. Have you looked at making lvm snapshots and dumping those? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From shiva at sewingwitch.com Mon Sep 20 04:58:04 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 19 Sep 2004 21:58:04 -0700 Subject: What to do about libc-client (imap)? In-Reply-To: <414E5DBE.1090208@redhat.com> References: <414E5DBE.1090208@redhat.com> Message-ID: <5B9B3752706488F0A90BEB2D@[10.0.0.4]> --On Sunday, September 19, 2004 6:34 PM -1000 Warren Togami wrote: > Proposed Option #1: Rename libc-client to imap-libs Any reason not to call it uwimap-libs? Why should it get premier naming as implementor of IMAP? (I realize it's a reference implementation of the protocol by the protocol's author, but we don't call BIND "dns".) From mattdm at mattdm.org Mon Sep 20 05:02:26 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 20 Sep 2004 01:02:26 -0400 Subject: What to do about libc-client (imap)? In-Reply-To: <5B9B3752706488F0A90BEB2D@[10.0.0.4]> References: <414E5DBE.1090208@redhat.com> <5B9B3752706488F0A90BEB2D@[10.0.0.4]> Message-ID: <20040920050226.GA1048@jadzia.bu.edu> On Sun, Sep 19, 2004 at 09:58:04PM -0700, Kenneth Porter wrote: > >Proposed Option #1: Rename libc-client to imap-libs > Any reason not to call it uwimap-libs? Why should it get premier naming as > implementor of IMAP? (I realize it's a reference implementation of the > protocol by the protocol's author, but we don't call BIND "dns".) we call Apache "httpd". :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dax at gurulabs.com Mon Sep 20 05:14:56 2004 From: dax at gurulabs.com (Dax Kelson) Date: Sun, 19 Sep 2004 23:14:56 -0600 Subject: backups In-Reply-To: <1095651147.4431.121.camel@nexus.verbum.private> References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> <1095651147.4431.121.camel@nexus.verbum.private> Message-ID: <1095657295.6761.2.camel@mentorng.gurulabs.com> On Sun, 2004-09-19 at 21:32, Colin Walters wrote: > On Sun, 2004-09-19 at 20:09 -0700, Kenneth Porter wrote: > > --On Sunday, September 19, 2004 9:48 PM -0400 Colin Walters > > wrote: > > > > > Well, it's not quite the same thing. You can't safely dump a live > > > filesystem, making it unusable for me. > > > > An explanation of the issue and why it not be an issue, depending on the > > situation: > > > > > > If Linus says a program will eat my data and is generally stupid, I tend > to believe him :) "In the future, dump's problems will be solved by snapshots." The future is now, eh? > > > Also it's far less granular than an archiver like tar or dar. > > > > It sounded like you were doing filesystem-level backups (including > > incrementals), not archives of isolated directory trees. Dump is very good > > for that. > > Not really - I'm only interested in backing up a few things like home > directories, web sites, and possibly /etc. Right now I just have one > big partition so dump would back up e.g. all of /usr, which isn't needed > for me. This is no longer accurate. You can use dump to backup selected directories. You don't have to backup the entire fs. Dax Kelson From bobgus at rcn.com Mon Sep 20 05:25:54 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 20 Sep 2004 00:25:54 -0500 Subject: please try SELinux again In-Reply-To: <33045.66.137.209.11.1095636745.squirrel@webmail.ec-group.com> Message-ID: I too was discouraged at the trailing edge development of SELinux and had it disabled for a few months. However, after getting my system up2date as they say, and doing a 'fixfiles relabel' in single user mode, and running selinuxtype=targeted, it seems to be running fairly well. I am running httpd with no problems. doing 'tail -2000 /var/log/messages | grep audit' shows no lines. BobG On Sun, 19 Sep 2004 18:32:25 -0500 (CDT). Brian Millett wrote: >Ok, I used the system-config-securitylevel to turn on the SELinux >security. But I noticed a BAD side affect. I am using a custom iptables, >Using the securitylevel tool turned off the iptables by deleteing the >/etc/sysconfig/iptables file. Good thing for backups :-). > >So how do I use the securitylevel tool without touching iptables? > >Can't. > >Too bad because after turning on SELinux, httpd will not start. I get the >following error: > >Starting httpd: Syntax error on line 68 of /etc/httpd/conf.d/ssl.conf: >SSLRandomSeed: source path '/dev/urandom' does not exist > [FAILED] >Ok, so what does /var/log/messages say.... Nothing because for some >reason, nothing is being logged. > >If I go to tty1 and try it, I get abunch of the following trace messages: > >audit(1095634287.733:0): avc: denied { read write } for pid=10192 >exe=/sbin/minilogd name=tty2 dev=tmpfs ino=1566 >scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t >tclass=chr_file >audit(1095634287.733:0): avc: denied { read write } for pid=10192 >exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 >scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t >tclass=chr_file >audit(1095634287.733:0): avc: denied { read write } for pid=10192 >exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 >scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t >tclass=chr_file >audit(1095634287.734:0): avc: denied { read write } for pid=10192 >exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 >scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t >tclass=chr_file >audit(1095634287.734:0): avc: denied { search } for pid=10192 >exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t >tcontext=user_u:object_r:tmpfs_t tclass=dir >audit(1095634287.735:0): avc: denied { search } for pid=10192 >exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t >tcontext=user_u:object_r:tmpfs_t tclass=dir >audit(1095634287.742:0): avc: denied { search } for pid=10192 >exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t >tcontext=user_u:object_r:tmpfs_t tclass=dir >audit(1095634287.754:0): avc: denied { read write } for pid=10194 >exe=/sbin/minilogd name=tty2 dev=tmpfs ino=1566 >scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t >tclass=chr_file >audit(1095634287.762:0): avc: denied { read write } for pid=10194 >exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 >scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t >tclass=chr_file >audit(1095634287.771:0): avc: denied { read write } for pid=10194 >exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 >scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t >tclass=chr_file >audit(1095634287.779:0): avc: denied { read write } for pid=10194 >exe=/sbin/minilogd path=/dev/null dev=tmpfs ino=974 >scontext=root:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t >tclass=chr_file >audit(1095634287.787:0): avc: denied { search } for pid=10194 >exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t >tcontext=user_u:object_r:tmpfs_t tclass=dir >audit(1095634287.795:0): avc: denied { search } for pid=10194 >exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t >tcontext=user_u:object_r:tmpfs_t tclass=dir >audit(1095634287.803:0): avc: denied { search } for pid=10194 >exe=/sbin/minilogd dev=tmpfs ino=972 scontext=root:system_r:syslogd_t >tcontext=user_u:object_r:tmpfs_t tclass=dir > > >So to get httpd to work, I need to reinvoke the securitylevel gui and >select transition->Disable Selinux protection for httpd daemon > >So, if you count not being able to run httpd and no system logs, it is >going ok. >-- >Brian Millett >Enterprise Consulting Group "Shifts in paradigms >(314) 205-9030 often cause nose bleeds." >bpmATec-groupDOTcom Greg Glenn > > > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list From jwz at jwz.org Mon Sep 20 05:30:55 2004 From: jwz at jwz.org (Jamie Zawinski) Date: Sun, 19 Sep 2004 22:30:55 -0700 Subject: What to do about libc-client (imap)? References: <414E5DBE.1090208@redhat.com> <5B9B3752706488F0A90BEB2D@[10.0.0.4]> Message-ID: <414E6B0F.E67FF26@jwz.org> Kenneth Porter wrote: > > Any reason not to call it uwimap-libs? Why should it get premier naming as > implementor of IMAP? (I realize it's a reference implementation of the > protocol by the protocol's author, but we don't call BIND "dns".) My recollection is that "c-client" was named that to distinguish it from the *real* IMAP client reference implementation... which was written in Common Lisp. (Yep, IMAP is that old. (And as broken now as then.)) -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ From wtogami at redhat.com Mon Sep 20 06:15:35 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 19 Sep 2004 20:15:35 -1000 Subject: Regarding Extras package announcements Message-ID: <414E7587.6050608@redhat.com> The old fedora-package-announce at fedora.us list has been broken in the past month due to some unknown issue caused by the Legacy 7.3 mailman update. I have spent many hours trying to debug it, but have been unable to fix it. I've been wanting to retire that old mailman server for a while now, but this forces the issue. fedora-extras-announce-list at redhat.com will soon open, and will be used by fedora.us Extras for the short-term. When Extras relaunches at fedora.redhat.com, the list will be used for those announcements. This is no longer far away, as we have servers online NOW, gafton and I are working on CVS structure, and finalizing the Apache-like contributor legal form. You will hear more about our progress within the next weeks here. Unfortunately hundreds of mail sent to the old Extras announce list went into /dev/null due to the legacy mailman problem. Sorry about that. =( Warren Togami wtogami at redhat.com From jorton at redhat.com Mon Sep 20 10:16:40 2004 From: jorton at redhat.com (Joe Orton) Date: Mon, 20 Sep 2004 11:16:40 +0100 Subject: autofs auto.master change Message-ID: <20040920101640.GA17976@redhat.com> Jeff, why has autofs been changed to only read a single auto.master source? All my test machines rely on multiple auto.master sources being used; they are configured to use both the site-wide NIS auto.master along with additional local per-machine mounts defined in /etc/auto.{master,misc}. This will be a serious migration issue for anyone else using such a configuration. joe From dwmw2 at infradead.org Mon Sep 20 10:12:16 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 20 Sep 2004 11:12:16 +0100 Subject: What to do about libc-client (imap)? In-Reply-To: <20040920050226.GA1048@jadzia.bu.edu> References: <414E5DBE.1090208@redhat.com> <5B9B3752706488F0A90BEB2D@[10.0.0.4]> <20040920050226.GA1048@jadzia.bu.edu> Message-ID: <1095675137.5065.291.camel@localhost.localdomain> On Mon, 2004-09-20 at 01:02 -0400, Matthew Miller wrote: > On Sun, Sep 19, 2004 at 09:58:04PM -0700, Kenneth Porter wrote: > > >Proposed Option #1: Rename libc-client to imap-libs > > Any reason not to call it uwimap-libs? Why should it get premier naming as > > implementor of IMAP? (I realize it's a reference implementation of the > > protocol by the protocol's author, but we don't call BIND "dns".) > > we call Apache "httpd". :) Yes. But calling that 'apache-httpd' wouldn't cause people to run screaming from the building instead of actually _using_ it. Whereas calling this 'uwimap-libs' instead of just 'imap-libs' probably _would_ have that effect. Which is probably a good thing for all concerned. -- dwmw2 From buildsys at redhat.com Mon Sep 20 11:59:20 2004 From: buildsys at redhat.com (Build System) Date: Mon, 20 Sep 2004 07:59:20 -0400 Subject: rawhide report: 20040920 changes Message-ID: <200409201159.i8KBxK927790@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-2.91-0.20040920 ---------------------------- From rdieter at math.unl.edu Mon Sep 20 12:05:52 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Sep 2004 07:05:52 -0500 Subject: What to do about libc-client (imap)? In-Reply-To: <5B9B3752706488F0A90BEB2D@[10.0.0.4]> References: <414E5DBE.1090208@redhat.com> <5B9B3752706488F0A90BEB2D@[10.0.0.4]> Message-ID: <414EC7A0.9030309@math.unl.edu> Kenneth Porter wrote: > --On Sunday, September 19, 2004 6:34 PM -1000 Warren Togami > wrote: > >> Proposed Option #1: Rename libc-client to imap-libs > > > Any reason not to call it uwimap-libs? Why should it get premier naming > as implementor of IMAP? (I realize it's a reference implementation of > the protocol by the protocol's author, but we don't call BIND "dns".) Possibly some legacy apps expect it to be named imap (which is what it has historically been named). Besides, IMO, packages should be called by their upstream name/tarball whenever possible, unless there is good reason to do otherwise. Recent examples raised (including yours) validates this: apache: As of 2.0, it's tarball is httpd (and for licensing reasons too ,I believe, Fedora Core can't use the name "apache"). bind: bind is and always has been called "bind". If there is confusion over the name, then I'd be inclined to name it uw-imap possibly. -- Rex From dwmw2 at infradead.org Mon Sep 20 12:23:09 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 20 Sep 2004 13:23:09 +0100 Subject: Wireless signal strength In-Reply-To: <1095347446.16808.4291.camel@jonspc> References: <1095274797.3220.3.camel@kyrre> <1095298400.16808.3528.camel@jonspc> <1095344291.6173.15.camel@dcbw.boston.redhat.com> <1095347446.16808.4291.camel@jonspc> Message-ID: <1095682988.17821.467.camel@hades.cambridge.redhat.com> On Thu, 2004-09-16 at 16:10 +0100, Jonathan Andrews wrote: > All thats needed is a conversion from RSSI to db for each device, > simplest place to stick that is in the driver - why complicate life any > further ! > > Anyone else got any ideas ? Whatever do for signal strength, including the pretty panel applets that display it, please could we try to make them work with Bluetooth too. If there's a WiFi-specific Ethtool op which returns signal strength, perhaps we can make the BNEP code handle that too, returning 'hcitool lq ' results in an appropriate form. -- dwmw2 From jorton at redhat.com Mon Sep 20 12:33:30 2004 From: jorton at redhat.com (Joe Orton) Date: Mon, 20 Sep 2004 13:33:30 +0100 Subject: What to do about libc-client (imap)? In-Reply-To: <414E5DBE.1090208@redhat.com> References: <414E5DBE.1090208@redhat.com> Message-ID: <20040920123330.GA18396@redhat.com> On Sun, Sep 19, 2004 at 06:34:06PM -1000, Warren Togami wrote: > Is this really worth more years of headache? Here are two proposals to > deal with this. I don't think there is strong enough motivation to rename the packages. If Fedora Extras wishes to maintain an "imap" package then they can do so without needing to rename libc-client, modulo bug #132928. So I've built a libc-client package without the "Conflicts: imap" to fix that bug. joe From wtogami at redhat.com Mon Sep 20 12:42:25 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 20 Sep 2004 02:42:25 -1000 Subject: What to do about libc-client (imap)? In-Reply-To: <414EC7A0.9030309@math.unl.edu> References: <414E5DBE.1090208@redhat.com> <5B9B3752706488F0A90BEB2D@[10.0.0.4]> <414EC7A0.9030309@math.unl.edu> Message-ID: <414ED031.6020100@redhat.com> Rex Dieter wrote: > Possibly some legacy apps expect it to be named imap (which is what it > has historically been named). Besides, IMO, packages should be called > by their upstream name/tarball whenever possible, unless there is good > reason to do otherwise. Recent examples raised (including yours) > validates this: I would agree that packages should be called their upstream name, but this should not be an absolute rule. But if some "legacy apps expect it to be named imap", then that is horribly broken and stupid. Except for certain special cases, you should always try to dep on specific versioned libraries (which RPM tries to do automatically) and not the *package* name. Nobody suggested renaming the installed files. imap-libs may very well be called uw-imap-libs just to be perfectly clear. It wouldn't hurt anything. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Sep 20 12:45:47 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 20 Sep 2004 02:45:47 -1000 Subject: What to do about libc-client (imap)? In-Reply-To: <20040920123330.GA18396@redhat.com> References: <414E5DBE.1090208@redhat.com> <20040920123330.GA18396@redhat.com> Message-ID: <414ED0FB.3070603@redhat.com> Joe Orton wrote: > On Sun, Sep 19, 2004 at 06:34:06PM -1000, Warren Togami wrote: > >>Is this really worth more years of headache? Here are two proposals to >>deal with this. > > > I don't think there is strong enough motivation to rename the packages. > If Fedora Extras wishes to maintain an "imap" package then they can do > so without needing to rename libc-client, modulo bug #132928. So I've > built a libc-client package without the "Conflicts: imap" to fix that > bug. I still maintain that "libc-client" is a horrible name for the package, but this is technically acceptable at least. Warren Togami wtogami at redhat.com From pri.rhl3 at iadonisi.to Mon Sep 20 13:18:32 2004 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Mon, 20 Sep 2004 09:18:32 -0400 Subject: What to do about libc-client (imap)? In-Reply-To: <414E6B0F.E67FF26@jwz.org> References: <414E5DBE.1090208@redhat.com> <5B9B3752706488F0A90BEB2D@[10.0.0.4]> <414E6B0F.E67FF26@jwz.org> Message-ID: <1095686311.18930.3.camel@va.local.linuxlobbyist.org> On Mon, 2004-09-20 at 01:30, Jamie Zawinski wrote: [snip] > My recollection is that "c-client" was named that to distinguish it from > the *real* IMAP client reference implementation... which was written in > Common Lisp. (Yep, IMAP is that old. (And as broken now as then.)) Awe, man! I love reading your rants, but, at the risk of this running way off topic, what, pray tell, is wrong with IMAP? I've been becoming more and more of an advocate for IMAP, but I've got to admit that since I don't do a lot of programming these days, I don't know the ins and outs of it the way a programmer would. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From dwmw2 at infradead.org Mon Sep 20 14:02:17 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 20 Sep 2004 15:02:17 +0100 Subject: What to do about libc-client (imap)? In-Reply-To: <1095686311.18930.3.camel@va.local.linuxlobbyist.org> References: <414E5DBE.1090208@redhat.com> <5B9B3752706488F0A90BEB2D@[10.0.0.4]> <414E6B0F.E67FF26@jwz.org> <1095686311.18930.3.camel@va.local.linuxlobbyist.org> Message-ID: <1095688936.17821.480.camel@hades.cambridge.redhat.com> On Mon, 2004-09-20 at 09:18 -0400, Paul Iadonisi wrote: > what, pray tell, is wrong with IMAP? Mostly the caching semantics, I'd imagine. Some people really hate the fact that you can't edit stuff stored on IMAP without changing the UID, and you can't change the UID without also changing the position in the folder. More people hate the fact that you have to re-fetch _all_ flags when you re-SELECT a folder, but the CONDSTORE stuff ought to fix that and make disconnected operation a little saner. I suspect more people hate IMAP due to idiocy in IMAP clients and servers rather than problems with IMAP itself. My main problem, for example, is the way that Evolution will insist on issuing STATUS on all of my hundreds of folders, even the archive folders which are marked inactive, sometimes with a RTT of about three seconds per folder, before it'll actually bother to fetch the mail I just clicked on. But that's not strictly an IMAP problem. Neither is the fact that Evolution will spend ages fetching multi-megabyte attachments over my ISDN line, just in order to run 'file' on them to see what they are, before displaying the text/plain part at the beginning which would have told me I didn't want to bother downloading it :) Sometimes I start up pine just to read my email while Evolution is doing its thing ;) -- dwmw2 From russell at coker.com.au Mon Sep 20 14:09:25 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 21 Sep 2004 00:09:25 +1000 Subject: backups In-Reply-To: <1095644884.4431.94.camel@nexus.verbum.private> References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> Message-ID: <200409210009.25405.russell@coker.com.au> On Mon, 20 Sep 2004 11:48, Colin Walters wrote: > > Are these all features of ext3? If so, wouldn't dump do the job? > > Well, it's not quite the same thing. You can't safely dump a live > filesystem, making it unusable for me. Also it's far less granular than > an archiver like tar or dar. LVM snapshots will allow dump to be used on live file systems. Dump does not work across file systems, so if you want to convert an Ext3 file system to ReiserFS or XFS then dump will not help. Dump is tied to Inode numbers and I believe that this has some implications for restoring deleted files if the machine has continued operation and created other files with the same Inode numbers. We do need a better backup solution, a friend investigated backups some time ago (without regard to SE Linux) and reached the conclusion that extending "dar" offered the best promise of all the Linux backup options. So dar may be worth considering. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From skvidal at phy.duke.edu Mon Sep 20 14:14:21 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 20 Sep 2004 10:14:21 -0400 Subject: backups In-Reply-To: <200409210009.25405.russell@coker.com.au> References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> <200409210009.25405.russell@coker.com.au> Message-ID: <1095689661.14760.0.camel@opus.phy.duke.edu> On Mon, 2004-09-20 at 10:09, Russell Coker wrote: > On Mon, 20 Sep 2004 11:48, Colin Walters wrote: > > > Are these all features of ext3? If so, wouldn't dump do the job? > > > > Well, it's not quite the same thing. You can't safely dump a live > > filesystem, making it unusable for me. Also it's far less granular than > > an archiver like tar or dar. > > LVM snapshots will allow dump to be used on live file systems. > > Dump does not work across file systems, so if you want to convert an Ext3 file > system to ReiserFS or XFS then dump will not help. > > Dump is tied to Inode numbers and I believe that this has some implications > for restoring deleted files if the machine has continued operation and > created other files with the same Inode numbers. > > We do need a better backup solution, a friend investigated backups some time > ago (without regard to SE Linux) and reached the conclusion that extending > "dar" offered the best promise of all the Linux backup options. So dar may > be worth considering. > Has anyone looked into bacula's ability to store extended attributes? Does it have any? -sv From strange at nsk.no-ip.org Mon Sep 20 14:20:49 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Mon, 20 Sep 2004 15:20:49 +0100 Subject: What to do about libc-client (imap)? In-Reply-To: <414ED0FB.3070603@redhat.com> References: <414E5DBE.1090208@redhat.com> <20040920123330.GA18396@redhat.com> <414ED0FB.3070603@redhat.com> Message-ID: <20040920142049.GA4746@nsk.no-ip.org> On Mon, Sep 20, 2004 at 02:45:47AM -1000, Warren Togami wrote: > Joe Orton wrote: > >On Sun, Sep 19, 2004 at 06:34:06PM -1000, Warren Togami wrote: > > > >>Is this really worth more years of headache? Here are two proposals to > >>deal with this. > > > > > >I don't think there is strong enough motivation to rename the packages. > >If Fedora Extras wishes to maintain an "imap" package then they can do > >so without needing to rename libc-client, modulo bug #132928. So I've > >built a libc-client package without the "Conflicts: imap" to fix that > >bug. > > I still maintain that "libc-client" is a horrible name for the package, > but this is technically acceptable at least. Yes, it would be for almost every package in Fedora. Maybe we could rename every package to libc-client-xxx, the kernel to libc-server-yyy, and glibc to libc,the?... libsomething is a common name, why not change to libimap? Regards, Luciano From enrico.scholz at informatik.tu-chemnitz.de Mon Sep 20 15:02:04 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 20 Sep 2004 17:02:04 +0200 Subject: please try SELinux again In-Reply-To: <1095536433.4655.18.camel@nexus.verbum.private> (Colin Walters's message of "Sat, 18 Sep 2004 15:40:33 -0400") References: <1095536433.4655.18.camel@nexus.verbum.private> Message-ID: <87mzzlq903.fsf@kosh.ultra.csn.tu-chemnitz.de> walters at redhat.com (Colin Walters) writes: > Talking with a number of people at the office, it seems a high > percentage of Fedora developers disabled SELinux during FC2 test2, Is there any chance that SELinux will be work again on FC2 (the latest kernel upgrades broke it)? Will be there erratas for critical bugs like mislabeling of e.g. /var/lib as HOMEDIR? Enrico From walters at redhat.com Mon Sep 20 15:21:41 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 20 Sep 2004 11:21:41 -0400 Subject: backups In-Reply-To: <20040920045558.GA618@jadzia.bu.edu> References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> <20040920045558.GA618@jadzia.bu.edu> Message-ID: <1095693701.4431.133.camel@nexus.verbum.private> On Mon, 2004-09-20 at 00:55 -0400, Matthew Miller wrote: > On Sun, Sep 19, 2004 at 09:48:04PM -0400, Colin Walters wrote: > > Well, it's not quite the same thing. You can't safely dump a live > > filesystem, making it unusable for me. Also it's far less granular than > > an archiver like tar or dar. > > Have you looked at making lvm snapshots and dumping those? I haven't, mainly because my server is FC2, and I didn't think to use LVM when setting it up, and I've heard that snapshotting is flaky in the FC2 version anyways. However, since new installs default to being on LVM, this might be a future option. The major problem I see with it though is the granularity and filesystem-specificity. It probably still makes sense to have a filesystem-independent archiver. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Mon Sep 20 15:24:08 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 20 Sep 2004 17:24:08 +0200 Subject: backups In-Reply-To: <20040920045558.GA618@jadzia.bu.edu> (Matthew Miller's message of "Mon, 20 Sep 2004 00:55:58 -0400") References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> <20040920045558.GA618@jadzia.bu.edu> Message-ID: <87isa9q7zb.fsf@kosh.ultra.csn.tu-chemnitz.de> mattdm at mattdm.org (Matthew Miller) writes: >> Well, it's not quite the same thing. You can't safely dump a live >> filesystem, making it unusable for me. Also it's far less granular >> than an archiver like tar or dar. > > Have you looked at making lvm snapshots and dumping those? LVM snapshots are not usably at the moment: for kernel 2.4 they work with a kernel patch only, and for kernel 2.6 they are marked as experimental which is confirmed by my experiences (kernel-panics on creation and manual cleanup required). Enrico From walters at redhat.com Mon Sep 20 15:26:59 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 20 Sep 2004 11:26:59 -0400 Subject: backups In-Reply-To: <200409210009.25405.russell@coker.com.au> References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> <200409210009.25405.russell@coker.com.au> Message-ID: <1095694019.4431.137.camel@nexus.verbum.private> On Tue, 2004-09-21 at 00:09 +1000, Russell Coker wrote: > LVM snapshots will allow dump to be used on live file systems. Ok, LVM snapshots help a lot, although as I mentioned elsewhere I think we probably still need an archiver. > We do need a better backup solution, a friend investigated backups some time > ago (without regard to SE Linux) and reached the conclusion that extending > "dar" offered the best promise of all the Linux backup options. So dar may > be worth considering. Ok. I actually investigated dar a bit more closely last night and found that it needs to be patched to support the "security" xattr namespace. Also we will need a patch to make it use setfscreatecon like the star SELinux patch does. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From daly at rio.sci.ccny.cuny.edu Mon Sep 20 15:29:31 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Mon, 20 Sep 2004 11:29:31 -0400 Subject: "Stateless Linux" project In-Reply-To: <1095231659.10739.205.camel@vigor12> (message from John Hearns on Wed, 15 Sep 2004 08:01:00 +0100) References: <1095100955.5481.14.camel@localhost.localdomain> <5463-61862@sneakemail.com> <1095176159.10739.140.camel@vigor12> <10152-71629@sneakemail.com> <1095183847.10863.32.camel@localhost> <20040914202921.GB4100@devserv.devel.redhat.com> <1095195303.4205.5.camel@localhost.localdomain> <1095229530.10739.183.camel@vigor12> <1095230437.23039.36.camel@binkley> <1095231659.10739.205.camel@vigor12> Message-ID: <200409201529.i8KFTVe31436@rio.sci.ccny.cuny.edu> >> I'm sorry if I sound like a curmudgeon but this is just what happens >> when you hear developers promising the world year after year and the >> world simply never showing up. > >Point(s) taken. I won't argue - you are right. > >However, I'd just like to flag up the popularity of Knoppix. >Who really would have predicted two years ago that it would be common >for people to hand out live CDs at public meetings, or engineers take >along a Knoppix CD to rescue and diagnose sick systems (I do). >At the UKUUG meeting there was a presentation from Sunderland University >on preparing custom Knoppix CDs for their staff and students this year. >Other places will be doing similar. >I fully recognise this is a different scenario. Actually, development of this idea is "in process". See (http://page.axiom-developer.org/zope/mathaction/doyen) The idea is to develop a live CD that can be given out at scientific conferences. These CDs would allow a scientist to share their work by working on a common repository (the mother doyen) using a common platform (the daughter doyen). This would open up a new market for Fedora, building and maintaining a custom scientific ecosystem. Tim Daly daly at idsi.net From kyrre at solution-forge.net Mon Sep 20 16:57:43 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 20 Sep 2004 18:57:43 +0200 Subject: please try SELinux again In-Reply-To: <87mzzlq903.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1095536433.4655.18.camel@nexus.verbum.private> <87mzzlq903.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1095699463.2757.65.camel@kyrre> Is it just me, or was the 2.6.8 release seriously broken in several ways - iv'e heard about cd-burners suddenly refusing to work (but works fine under 2.6.7), among many other things? Hope 2.6.9 is better! man, 20.09.2004 kl. 17.02 skrev Enrico Scholz: > walters at redhat.com (Colin Walters) writes: > > > Talking with a number of people at the office, it seems a high > > percentage of Fedora developers disabled SELinux during FC2 test2, > > Is there any chance that SELinux will be work again on FC2 (the latest > kernel upgrades broke it)? Will be there erratas for critical bugs like > mislabeling of e.g. /var/lib as HOMEDIR? > > > > Enrico > From aravinda_vbhat at rediffmail.com Mon Sep 20 17:57:11 2004 From: aravinda_vbhat at rediffmail.com (Aravinda V) Date: 20 Sep 2004 17:57:11 -0000 Subject: How to configure modem Message-ID: <20040920175711.26032.qmail@webmail18.rediffmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- From smoogen at lanl.gov Mon Sep 20 19:26:32 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Mon, 20 Sep 2004 13:26:32 -0600 Subject: The real news Re: Regarding Extras package announcements In-Reply-To: <414E7587.6050608@redhat.com> References: <414E7587.6050608@redhat.com> Message-ID: <414F2EE8.8090405@lanl.gov> Warren Togami wrote: > This is no longer far away, as we have servers online NOW, gafton and I > are working on CVS structure, and finalizing the Apache-like contributor > legal form. You will hear more about our progress within the next weeks > here. CONGRATS!!!! -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From kyrre at solution-forge.net Mon Sep 20 19:54:30 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 20 Sep 2004 21:54:30 +0200 Subject: The real news Re: Regarding Extras package announcements In-Reply-To: <414F2EE8.8090405@lanl.gov> References: <414E7587.6050608@redhat.com> <414F2EE8.8090405@lanl.gov> Message-ID: <1095710069.28044.31.camel@kyrre> Hmm.. how will this be integrated with core? CONGRATS!! - you have mine to :D One thing i have always wondered about is why is fedora.us named _.US_ when many of the packages are there there just because they are illegal/legaly questionable in the US? man, 20.09.2004 kl. 21.26 skrev Stephen J Smoogen: > Warren Togami wrote: > > > This is no longer far away, as we have servers online NOW, gafton and I > > are working on CVS structure, and finalizing the Apache-like contributor > > legal form. You will hear more about our progress within the next weeks > > here. > > CONGRATS!!!! > > > > > -- > Stephen John Smoogen | CCN-5 Security Team > LANL SIRT Team Leader | SMTP: smoogen at lanl.gov > Los Alamos National Laboratory | Voice: 505.664.0645 > Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 > Los Alamos, NM 87545 | > From perbj at stanford.edu Mon Sep 20 20:04:07 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Mon, 20 Sep 2004 13:04:07 -0700 Subject: The real news Re: Regarding Extras package announcements In-Reply-To: <1095710069.28044.31.camel@kyrre> References: <414E7587.6050608@redhat.com> <414F2EE8.8090405@lanl.gov> <1095710069.28044.31.camel@kyrre> Message-ID: <1095710647.2902.29.camel@localhost.localdomain> On Mon, 2004-09-20 at 12:54, Kyrre Ness Sjobak wrote: > One thing i have always wondered about is why is fedora.us named _.US_ > when many of the packages are there there just because they are > illegal/legaly questionable in the US? There's _nothing_ at fedora.us that is deemed illegal or gray-zone in the US. That stuff is all at rpm.livna.org since after the merge announcement last fall. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From elanthis at awesomeplay.com Mon Sep 20 20:06:17 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 20 Sep 2004 16:06:17 -0400 Subject: The real news Re: Regarding Extras package announcements In-Reply-To: <1095710069.28044.31.camel@kyrre> References: <414E7587.6050608@redhat.com> <414F2EE8.8090405@lanl.gov> <1095710069.28044.31.camel@kyrre> Message-ID: <1095710778.6217.97.camel@support02.civic.twp.ypsilanti.mi.us> On Mon, 2004-09-20 at 21:54 +0200, Kyrre Ness Sjobak wrote: > Hmm.. how will this be integrated with core? > > CONGRATS!! - you have mine to :D > > One thing i have always wondered about is why is fedora.us named _.US_ > when many of the packages are there there just because they are > illegal/legaly questionable in the US? fedora.us doesn't have any packages like that of which I'm aware. Those kinds of packages are found in repositories like livna.org. The original reason for the .us top-level is probably just because that's what was available. Fedora is a dictionary word; finding a free domain based on a dictionary word is nigh near impossible. -- Sean Middleditch AwesomePlay Productions, Inc. From kyrre at solution-forge.net Mon Sep 20 20:06:45 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 20 Sep 2004 22:06:45 +0200 Subject: The real news Re: Regarding Extras package announcements In-Reply-To: <1095710647.2902.29.camel@localhost.localdomain> References: <414E7587.6050608@redhat.com> <414F2EE8.8090405@lanl.gov> <1095710069.28044.31.camel@kyrre> <1095710647.2902.29.camel@localhost.localdomain> Message-ID: <1095710805.28044.34.camel@kyrre> Okay - i did not know that. Make it easy, have as many repos as possible... But anyway, will there be an option (during install or something) to use the extras repo? --Kyrre man, 20.09.2004 kl. 22.04 skrev Per Bjornsson: > On Mon, 2004-09-20 at 12:54, Kyrre Ness Sjobak wrote: > > > One thing i have always wondered about is why is fedora.us named _.US_ > > when many of the packages are there there just because they are > > illegal/legaly questionable in the US? > > There's _nothing_ at fedora.us that is deemed illegal or gray-zone in > the US. That stuff is all at rpm.livna.org since after the merge > announcement last fall. > > /Per > > -- > Per Bjornsson > Ph.D. Candidate, Department of Applied Physics, Stanford University > From fedora at wir-sind-cool.org Mon Sep 20 20:27:09 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 20 Sep 2004 22:27:09 +0200 Subject: Regarding Extras package announcements In-Reply-To: <414E7587.6050608@redhat.com> References: <414E7587.6050608@redhat.com> Message-ID: <20040920222709.63330698.fedora@wir-sind-cool.org> On Sun, 19 Sep 2004 20:15:35 -1000, Warren Togami wrote: > fedora-extras-announce-list at redhat.com will soon open, and will be used > by fedora.us Extras for the short-term. When Extras relaunches at > fedora.redhat.com, the list will be used for those announcements. Available meanwhile... Maybe we can use the chance and discuss the announcements' content and format, for sake of readability. fedora-package-announce at fedora.us has been a bit confusing with its free-form subject lines, message bodies, and various forms of GPG signatures. There's $ /usr/bin/fedora-pkgannfmt Usage: fedora-pkgannfmt in fedora-rpmdevtools, which prints a few RPM package headers and the package changelog. Easy for preparing announcements. But it doesn't know where to cut off the changelog and which target distributions the package has been released for (fc1? FC1? rh9? RHL9?). So, what and how do we announce? For reference, the _old_ list archives are here: http://www.fedora.us/pipermail/fedora-package-announce/ Suggestions? Do we care? -- Fedora Core release 2 (Tettnang) - Linux 2.6.7-1.494.2.2 loadavg: 0.16 0.82 1.07 From dwalsh at redhat.com Mon Sep 20 21:10:46 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Sep 2004 17:10:46 -0400 Subject: please try SELinux again In-Reply-To: References: Message-ID: <414F4756.9050006@redhat.com> Sorry my filters were eating SELinux messages in devel-list or I would have responded sooner. One system-config-securitylevel is creating a file /.autorelabel. Which causes the relabel on the next boot. So if you want to relabel your file system you can just create this file and reboot. It will run the fixfiles in "single user mode" and then boot up in the current policy. Not sure if it will work correctly coming from an upgrade of fc2. system-config-securitylevel, is not supposed to touch the firewall stuff unless you modify something on the front screen. There are a series of checks on the OK button to only apply changes if something changed, so I don't see how the firewall rules got effected by changing SELinux page. Dan From dwalsh at redhat.com Mon Sep 20 21:13:11 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Sep 2004 17:13:11 -0400 Subject: please try SELinux again In-Reply-To: <414DA50B.2080202@hhs.nl> References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> <604aa79104091814374b867522@mail.gmail.com> <1095547368.4655.35.camel@nexus.verbum.private> <414D2391.9020400@hhs.nl> <1095607089.4655.51.camel@nexus.verbum.private> <414DA50B.2080202@hhs.nl> Message-ID: <414F47E7.5060101@redhat.com> Hans de Goede wrote: > > > Colin Walters wrote: > >> On Sun, 2004-09-19 at 08:13 +0200, Hans de Goede wrote: >> >> >>> Erm, that didn't happen for me (running the relabel) resulting in a >>> system with a non-working X. Booting in single mode and running >>> fixfiles myself fixed things for me. >> >> >> >> Ok, it looks like the automatic relabeling only happens if you use >> system-config-securitylevel to re-enable SELinux. So it's probably a >> good idea to use that. >> >> > > Ok, > > Will the installer run fixfiles on an upgrade? I really think it should! > and not just on the packages, but on all files on the system, so also > homedirs etc. > No the installer will leave SELinux turned off, it will not relabel. If you are upgrading from SELinux disabled it will stay disabled, if you are upgrading from enabled, it should upgrade to strict policy. You can change to targeted policy by: 1 Editing the /etc/selinux/config file and relabeling (touch /.autorelabe and reboot). or 2. Run system-config-securitylevel and reboot or 3. Fresh install. > Regards, > > Hans > > From mike at flyn.org Mon Sep 20 21:33:26 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 20 Sep 2004 16:33:26 -0500 (CDT) Subject: please try SELinux again In-Reply-To: <414F4756.9050006@redhat.com> References: <414F4756.9050006@redhat.com> Message-ID: <4187.66.151.13.92.1095716006.squirrel@66.151.13.92> Should one expect a system to boot when SELinux is enforcing Fedora's strict policy and all of the Hollywood hal, udev, etc. is being used? In my experience, the strict policy does not like these sub-systems yet. I was testing the strict policy for quite some time until testing udev and friends became my priority. -- Mike From dwalsh at redhat.com Mon Sep 20 21:35:44 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Sep 2004 17:35:44 -0400 Subject: What is SELinux targeted policy? In-Reply-To: <20040920211657.GA25436@earthlink.net> References: <1095709136.3464.12.camel@junior.yellowhouse> <20040920211657.GA25436@earthlink.net> Message-ID: <414F4D30.6040001@redhat.com> When FC2 was released we attempted to add the NSA strict policy to the operating system. We were able to find hundreds of problems in the policy and we quickly found out that users who customized their environments in unexpected ways caused SELinux and the OS to conflict. We decided at that point to take a step back and go with a strategy where we would lock down a few daemons with SELinux and allow the rest of the system to run in the same manner with or without SELinux. Targeted policy was born. In targeted policy most processes run in a unconfined_t domain, which means for the most part they are not being confined by the SELinux policy. They are still governed by Standard unix security, but not effected by SELinux. Certain network daemons have policy and the unconfined_t policy transitions to those policies when the application starts. So when the system boots init runs in the unconfined_t policy, but when named starts up it transitions to the named_t domain and is locked down. We use the following policies nscd.te apache.te dhcpd.te named.te ntpd.te portmap.te snmpd.te squid.te syslogd.te Also users can select which daemons he want to have SELinux to protect via system-config-securitylevel. So if an admin finds that SELinux will not allow his apache web server to run the way he wants he can turn off the transition. This will drop it back to normal Unix protections, but all other daemons will continue to be protected by SELinux. Through the use of these "boolean" values the admin can increase or decrease the level of protection SELinux provides. In the future we plan on adding additional Domains that SELinux will protect. Strict policy is still available but will be not be installable directly, you can use selinux-config-securitylevel to turn it on and relabel the file system. Dan From dwalsh at redhat.com Mon Sep 20 21:36:55 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Sep 2004 17:36:55 -0400 Subject: please try SELinux again In-Reply-To: <4187.66.151.13.92.1095716006.squirrel@66.151.13.92> References: <414F4756.9050006@redhat.com> <4187.66.151.13.92.1095716006.squirrel@66.151.13.92> Message-ID: <414F4D77.8070908@redhat.com> W. Michael Petullo wrote: >Should one expect a system to boot when SELinux is enforcing Fedora's >strict policy and all of the Hollywood hal, udev, etc. is being used? In >my experience, the strict policy does not like these sub-systems yet. I >was testing the strict policy for quite some time until testing udev and >friends became my priority. > >-- >Mike > > > > It should work, if not we want to know and fix the problems. We have worked to fix all the hal, udev, tmpfs, SELinux problems. Dan From jerone at gmail.com Mon Sep 20 21:49:25 2004 From: jerone at gmail.com (Jerone Young) Date: Mon, 20 Sep 2004 16:49:25 -0500 Subject: What happened to the Kernel Source RPM ? Message-ID: <9f50a7a004092014496810f21d@mail.gmail.com> Looking today into the FC3 dev repository I can nolonger find a rpm for the kernel source. What happened to it ? From bpm at ec-group.com Mon Sep 20 21:47:30 2004 From: bpm at ec-group.com (Brian Millett) Date: Mon, 20 Sep 2004 16:47:30 -0500 (CDT) Subject: please try SELinux again In-Reply-To: <414F4756.9050006@redhat.com> References: <414F4756.9050006@redhat.com> Message-ID: <22065.12.41.112.51.1095716850.squirrel@webmail.ec-group.com> > Sorry my filters were eating SELinux messages in devel-list or I would > have responded sooner. > > One system-config-securitylevel is creating a file /.autorelabel. Which > causes the relabel on the next > boot. So if you want to relabel your file system you can just create > this file and reboot. It will run the > fixfiles in "single user mode" and then boot up in the current policy. > Not sure if it will work correctly > coming from an upgrade of fc2. Great! Thanks. > system-config-securitylevel, is not supposed to touch the firewall stuff > unless you modify something on the > front screen. There are a series of checks on the OK button to only > apply changes if something changed, so > I don't see how the firewall rules got effected by changing SELinux > page. Well it does. I just ran system-config-securitylevel. Did not touch the firewall options, just selected selinux. Toggled a transistion item. Saved. Checked and the /etc/sysconfig/iptables file was gone. -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From pri.rhl3 at iadonisi.to Mon Sep 20 21:59:43 2004 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Mon, 20 Sep 2004 17:59:43 -0400 Subject: What happened to the Kernel Source RPM ? In-Reply-To: <9f50a7a004092014496810f21d@mail.gmail.com> References: <9f50a7a004092014496810f21d@mail.gmail.com> Message-ID: <1095717583.21974.3.camel@va.local.linuxlobbyist.org> On Mon, 2004-09-20 at 17:49, Jerone Young wrote: > Looking today into the FC3 dev repository I can nolonger find a rpm > for the kernel source. What happened to it ? *sigh* Let's not have this discussion again, please. Read the archives (both -devel and -test), as there have been several lengthy, sometimes nasty discussions about this. If you want the source for the kernel, look for the .src.rpm in the SRPMS directory, like you would for any other package in the distribution. If that's not good enough, then please present a solution that is satisfactory for both Red Hat and third party module builders. And if you manage that, you will be honored by all ;-). -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From notting at redhat.com Mon Sep 20 22:13:07 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Sep 2004 18:13:07 -0400 Subject: hotplug change in tomorrow's build Message-ID: <20040920221307.GA3375@nostromo.devel.redhat.com> The default firmware directory for hotplug is being changed to /lib/firmware from /usr/lib/hotplug/firmware. This is being done so that device module loading on boot will work correctly. This will affect those of you with prism54, ipw2100/ipw2200 cards, and other cards that need hotplugged firmware. Bill From jerone at gmail.com Mon Sep 20 22:13:27 2004 From: jerone at gmail.com (Jerone Young) Date: Mon, 20 Sep 2004 17:13:27 -0500 Subject: What happened to the Kernel Source RPM ? In-Reply-To: <1095717583.21974.3.camel@va.local.linuxlobbyist.org> References: <9f50a7a004092014496810f21d@mail.gmail.com> <1095717583.21974.3.camel@va.local.linuxlobbyist.org> Message-ID: <9f50a7a004092015133fe05829@mail.gmail.com> I hadn't seen anything on this. And I don't want to beat a dead horse on this issue. Just comes with change. I'll look in the archives. On Mon, 20 Sep 2004 17:59:43 -0400, Paul Iadonisi wrote: > > > On Mon, 2004-09-20 at 17:49, Jerone Young wrote: > > Looking today into the FC3 dev repository I can nolonger find a rpm > > for the kernel source. What happened to it ? > > *sigh* Let's not have this discussion again, please. Read the > archives (both -devel and -test), as there have been several lengthy, > sometimes nasty discussions about this. If you want the source for the > kernel, look for the .src.rpm in the SRPMS directory, like you would for > any other package in the distribution. > If that's not good enough, then please present a solution that is > satisfactory for both Red Hat and third party module builders. And if > you manage that, you will be honored by all ;-). > > -- > -Paul Iadonisi > Senior System Administrator > Red Hat Certified Engineer / Local Linux Lobbyist > Ever see a penguin fly? -- Try Linux. > GPL all the way: Sell services, don't lease secrets > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From wtogami at redhat.com Mon Sep 20 22:31:36 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 20 Sep 2004 12:31:36 -1000 Subject: The real news Re: Regarding Extras package announcements In-Reply-To: <1095710647.2902.29.camel@localhost.localdomain> References: <414E7587.6050608@redhat.com> <414F2EE8.8090405@lanl.gov> <1095710069.28044.31.camel@kyrre> <1095710647.2902.29.camel@localhost.localdomain> Message-ID: <414F5A48.90301@redhat.com> Per Bjornsson wrote: > On Mon, 2004-09-20 at 12:54, Kyrre Ness Sjobak wrote: > > >>One thing i have always wondered about is why is fedora.us named _.US_ >>when many of the packages are there there just because they are >>illegal/legaly questionable in the US? > > > There's _nothing_ at fedora.us that is deemed illegal or gray-zone in > the US. That stuff is all at rpm.livna.org since after the merge > announcement last fall. > fedora.us was the shortest domain name available back when I was domain shopping. I offered $1,000 cash to fedora.org back then, but they refused. http://fedora.org/ Hmm, they changed away from the amusing annoying badger. Warren Togami wtogami at redhat.com From michel.salim at gmail.com Tue Sep 21 00:26:57 2004 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 20 Sep 2004 19:26:57 -0500 Subject: The real news Re: Regarding Extras package announcements In-Reply-To: <414F2EE8.8090405@lanl.gov> References: <414E7587.6050608@redhat.com> <414F2EE8.8090405@lanl.gov> Message-ID: <883cfe6d04092017265be0d68b@mail.gmail.com> On Mon, 20 Sep 2004 13:26:32 -0600, Stephen J Smoogen wrote: > Warren Togami wrote: > > > This is no longer far away, as we have servers online NOW, gafton and I > > are working on CVS structure, and finalizing the Apache-like contributor > > legal form. You will hear more about our progress within the next weeks > > here. > > CONGRATS!!!! > Can't wait myself.. here's to a smooth relaunch of Extras :) -- Michel Salim ??? http://salimma.livejournal.com From notting at redhat.com Mon Sep 20 14:16:06 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Sep 2004 10:16:06 -0400 Subject: Announcing Fedora Core 3 Test 2 Message-ID: <20040920141606.GA30766@nostromo.devel.redhat.com> Coming soon to a site near you... for the first time, it's the new, digitally remastered, Fedora Core 3 Test 2! Now, you can take home this never before seen four-disc set, chock full of new software and exciting bonus features! Includes hundreds of new and updated packages over the original edition, including: - a minor change to the device model, switching from a static /dev to a dynamic /dev provided by udev - SELinux enablement - the GNOME 2.8 release candidate - KDE 3.3.0 - X.org X11 6.8.0 Please report problems at: http://bugzilla.redhat.com/bugzilla File bugs against product 'Fedora Core', release 'fc3test2'. For more information on just waht the Fedora Project and Fedora Core is, please see: http://fedora.redhat.com/ Fedora Core 3 Test 2 is available at the following sites: * North America: * USA East: * ftp://ftp.linux.ncsu.edu/pub/fedora/linux/core/test/2.91/ * http://ftp.ndlug.nd.edu/pub/fedora/linux/core/test/2.91/ * ftp://ftp.ndlug.nd.edu/pub/fedora/linux/core/test/2.91/ * ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/core/test/2.91/ * http://ftp.dc.aleron.net/linux/fedora/linux/core/test/2.91 * ftp://ftp.dc.aleron.net/linux/fedora/linux/core/test/2.91 * rsync://ftp.dc.aleron.net::fedora-linux-core-test/2.91/ * ftp://redhat.secsup.org/pub/linux/redhat/fedora/core/test/2.91 * http://redhat.secsup.org/fedora/core/test/2.91 * ftp://mirror.clarkson.edu/pub/distributions/fedora/linux/core/test/2.91/ * http://mirror.clarkson.edu/pub/distributions/fedora/linux/core/test/2.91/ * ftp://ftp.cse.buffalo.edu/pub/fedora/linux/core/test/2.91/ * ftp://ftp.ale.org/mirrors/fedora/linux/core/test/2.91 * http://ftp.ale.org/mirrors/fedora/linux/core/test/2.91 * ftp://ftp.gtlib.cc.gatech.edu/pub/fedora.redhat/linux/core/test/2.91 * http://www.gtlib.cc.gatech.edu/pub/fedora.redhat/linux/core/test/2.91 * rsync://rsync.gtlib.cc.gatech.edu/fedora-linux-core/test/2.91 * ftp://mirror.eas.muohio.edu/pub/fedora/linux/core/test/2.91 * http://mirror.hiwaay.net/redhat/fedora/linux/core/test/2.91/ * ftp://mirror.hiwaay.net/redhat/fedora/linux/core/test/2.91/ * rsync://mirror.hiwaay.net/fedora-linux-core-test/2.91/ * http://mirror.linux.duke.edu/pub/fedora/linux/core/test/2.91/ * ftp://mirror.linux.duke.edu/pub/fedora/linux/core/test/2.91/ * rsync://mirror.linux.duke.edu/fedora-linux-core/test/2.91/ * USA West: * http://fedora.cat.pdx.edu/linux/core/test/2.91/ * rsync://fedora.cat.pdx.edu/fedora-linux-core-test/2.91/ * Canada: * ftp://less.cogeco.net/pub/fedora/linux/core/test/2.91/ * http://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/core/test/2.91/ * ftp://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/core/test/2.91/ * rsync://mirror.cpsc.ucalgary.ca/fedora/linux/core/test/2.91/ * http://gulus.USherbrooke.ca/pub/distro/fedora/linux/core/test/2.91/ * South America: * Portugal: * http://tux.cprm.net/pub/ftp.redhat.com/fedora/linux/core/test/2.91 * ftp://tux.cprm.net/pub/ftp.redhat.com/fedora/linux/core/test/2.91 * Europe: * Austria: * ftp://gd.tuwien.ac.at/opsys/linux/fedora/core/test/2.91/ * http://gd.tuwien.ac.at/opsys/linux/fedora/core/test/2.91/ * rsync://gd.tuwien.ac.at/opsys/linux/fedora/core/test/2.91/ * Czech Republic: * ftp://ftp.fi.muni.cz/pub/linux/fedora-core/test/2.91/ * rsync://ftp.fi.muni.cz/pub/linux/fedora-core/test/2.91/ * ftp://ftp6.linux.cz/pub/linux/fedora-core/test/2.91/ (IPv6) * ftp://sunsite.mff.cuni.cz/pub/fedora/test/2.91/ * http://sunsite.mff.cuni.cz/pub/fedora/test/2.91/ * rsync://sunsite.mff.cuni.cz/fedora/fedora/test/2.91/ * ftp://ultra.linux.cz/pub/fedora/test/2.91/ * ftp://ftp1.skynet.cz/pub/linux/fedora/test/2.91 * Denmark: * ftp://klid.dk/fedora/linux/core/test/2.91 * Finland: * http://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/test/2.91/ - i386 only * ftp://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/test/2.91/ - i386 only * http://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/test/2.91/ - i386 only * ftp://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/test/2.91/ - i386 only * France: * ftp://ftp.ciril.fr/pub/linux/fedora/linux/core/test/2.91 * Germany: * ftp://sunsite.informatik.rwth-aachen.de/pub/linux/fedora-core/test/2.91 * http://sunsite.informatik.rwth-aachen.de/ftp/pub/linux/fedora-core/test/2.91 * ftp://ftp.tu-chemnitz.de/pub/linux/fedora-core/test/2.91/ * http://ftp.tu-chemnitz.de/pub/linux/fedora-core/test/2.91/ * http://download.atrpms.net/mirrors/fedoracore/test/2.91/ * ftp://ftp.stw-bonn.de/pub/mirror/fedora/linux/core/test/2.91/ * http://ftp.stw-bonn.de/pub/mirror/fedora/linux/core/test/2.91/ * ftp://ftp.uni-bayreuth.de/pub/linux/fedora/linux/core/test/2.91 * rsync://rsync.uni-bayreuth.de/fedora-linux-core/test/2.91 * ftp://ftp.join.uni-muenster.de/pub/linux/distributions/fedora/linux/core/test/2.91 * rsync://ftp.join.uni-muenster.de/fedora-linux-core-test/2.91/ * Ireland: * http://ftp.esat.net/mirrors/download.fedora.redhat.com/pub/fedora/linux/core/test/2.91 * ftp://ftp.esat.net/mirrors/download.fedora.redhat.com/pub/fedora/linux/core/test/2.91 * rsync://ftp.esat.net/mirrors/download.fedora.redhat.com/pub/fedora/linux/core/test/2.91 * http://ftp.heanet.ie/pub/fedora/linux/core/test/2.91/ * ftp://ftp.heanet.ie/pub/fedora/linux/core/test/2.91/ * rsync://ftp.heanet.ie/pub/fedora/linux/core/test/2.91/ * Netherlands: * ftp://alviss.et.tudelft.nl/pub/fedora/core/test/2.91/ * ftp://ftp.quicknet.nl/pub/Linux/download.fedora.redhat.com/test/2.91/ * ftp://ftp.eu.uu.net/pub/linux/fedora/test/2.91/ * Poland: * ftp://sunsite.icm.edu.pl/pub/Linux/fedora/linux/core/test/2.91/ * http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/core/test/2.91/ * rsync://sunsite.icm.edu.pl/pub/Linux/fedora/linux/core/test/2.91/ * ftp://ftp.wsisiz.edu.pl/pub/Linux/fedora/linux/core/test/2.91/ * Romania: * http://ftp.lug.ro/fedora/linux/core/test/2.91/ * ftp://ftp.lug.ro/fedora/linux/core/test/2.91/ * United Kingdom: * http://zeniiia.linux.org.uk/pub/distributions/fedora/linux/core/test/2.91/ * ftp://zeniiia.linux.org.uk/pub/distributions/fedora/linux/core/test/2.91/ * rsync://zeniiia.linux.org.uk/fedora-linux-core/test/2.91/ * Asia/Pacific: * Australia: * http://planetmirror.com/pub/fedora/linux/core/test/2.91/ * ftp://ftp.planetmirror.com/pub/fedora/linux/core/test/2.91/ * rsync://rsync.planetmirror.com/fedora-linux-core-test/2.91/ * Japan: * ftp://ftp.riken.jp/Linux/fedora/core/test/2.91/ * http://ftp.riken.jp/Linux/fedora/core/test/2.91/ * rsync://ftp.riken.jp/fedora/core/test/2.91/ * ftp://ftp.kddilabs.jp/Linux/packages/fedora/core/test/2.91/ * http://ftp.kddilabs.jp/Linux/packages/fedora/core/test/2.91/ * rsync://ftp.kddilabs.jp/fedora/core/test/2.91/ * Taiwan: * http://ftp.isu.edu.tw/pub/Linux/Fedora/linux/core/test/2.91 * ftp://ftp.isu.edu.tw/pub/Linux/Fedora/linux/core/test/2.91 More mirrors will come online in the near future; check: http://fedora.redhat.com/download/mirrors.html for a list of mirrors that carry Fedora Core. One additional feature provided by the Linux community is the availability of Fedora Core releases via BitTorrent. http://torrent.linux.duke.edu/FC3-test2-binary-i386.torrent http://torrent.linux.duke.edu/FC3-test2-binary-x86_64.torrent See http://torrent.linux.duke.edu/ for other forms, including SRPMS and the DVD iso. RPMS for BitTorrent are available from: http://torrent.linux.duke.edu/btrpms/ Usage is simple: btdownloadcurses.py --url http://URL.torrent Allow incoming TCP 6881 - 6889 to join the torrent swarm. From dax at gurulabs.com Tue Sep 21 03:46:42 2004 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 20 Sep 2004 21:46:42 -0600 Subject: hotplug change in tomorrow's build In-Reply-To: <20040920221307.GA3375@nostromo.devel.redhat.com> References: <20040920221307.GA3375@nostromo.devel.redhat.com> Message-ID: <1095738402.4048.102.camel@mentorng.gurulabs.com> On Mon, 2004-09-20 at 16:13, Bill Nottingham wrote: > The default firmware directory for hotplug is being changed > to /lib/firmware from /usr/lib/hotplug/firmware. This is > being done so that device module loading on boot will work > correctly. > > This will affect those of you with prism54, ipw2100/ipw2200 > cards, and other cards that need hotplugged firmware. > > Bill Ahhh good! I was wondering if there was a bug filed about that, but have been too lazy/overworked to check. It is good to get this working properly, as there has been many, many threads over on the ipw mailing list with people having trouble getting firmware-load-on-bootup working properly. Three questions. 1) Is it worth supporting those with wireless nics requiring firmware and who also want to mount / via NFS? This requires firmware loading in the initial ram disk. 2) Will Fedora/RHEL be shipping with /lib/firmware directory pre-populated with ipw* firmware? 3) Any idea what's the semantics with hotplug vs /etc/dev.d/? What's the defined interaction? Is it possible for hotplug to trigger but not udev or vice versa? Dax From mattwhiteley at gmail.com Tue Sep 21 04:48:15 2004 From: mattwhiteley at gmail.com (matt whiteley) Date: Mon, 20 Sep 2004 21:48:15 -0700 Subject: kernel sata support In-Reply-To: <72ae109c0409180923721b3114@mail.gmail.com> References: <72ae109c0409180923721b3114@mail.gmail.com> Message-ID: <72ae109c040920214847feb009@mail.gmail.com> And so it continues with the fc3t2 boot.iso, my sata controllers are not found. The fc2 cd boots and installs without fail. On Sat, 18 Sep 2004 09:23:57 -0700, matt whiteley wrote: > I have not been able to boot a kernel since 2.6.6-1.435.2.3 or install > from the boot.iso with a later kernel. I filed a bug #129190 about the > issue, but the only idea offered was to rebuild the initrd image. I > did this to no avail. It appears the sata_nv driver is not in the > working 2.6.5 or 2.6.6 initrd anyway. > > It seems odd that the support for my mobo is worsening but I assume it > is an upstream change. Any ideas on how to install the new boot.iso so > I can test rawhide out on the machine? > > mobo is : MSI K8N-Neo Platinum w/ sata > > thanks, > -- > matt whiteley > -- matt whiteley From notting at redhat.com Tue Sep 21 05:34:59 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Sep 2004 01:34:59 -0400 Subject: hotplug change in tomorrow's build In-Reply-To: <1095738402.4048.102.camel@mentorng.gurulabs.com> References: <20040920221307.GA3375@nostromo.devel.redhat.com> <1095738402.4048.102.camel@mentorng.gurulabs.com> Message-ID: <20040921053459.GD5769@nostromo.devel.redhat.com> Dax Kelson (dax at gurulabs.com) said: > 1) Is it worth supporting those with wireless nics requiring firmware > and who also want to mount / via NFS? This requires firmware loading in > the initial ram disk. Well, it's not going to work out of the box, but neither is net booting without hacks. I suppose you'd need to modify mkinitrd. > 2) Will Fedora/RHEL be shipping with /lib/firmware directory > pre-populated with ipw* firmware? Not to the best of my knowledge. > 3) Any idea what's the semantics with hotplug vs /etc/dev.d/? What's the > defined interaction? Is it possible for hotplug to trigger but not udev > or vice versa? hotplug is called by the kernel, hotplug then calls udev, which then calls dev.d scripts. Bill From russell at coker.com.au Tue Sep 21 07:11:44 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 21 Sep 2004 17:11:44 +1000 Subject: initlog and minilogd Message-ID: <200409211711.44395.russell@coker.com.au> At boot time I have initlog being run from a dhclient, and initlog then runs minilogd. Currently the strict SE Linux policy does not permit minilogd to be run. What is needed is the following rule: domain_auto_trans(dhcpc_t, syslogd_exec_t, syslogd_t) However there may be other instances of this problem. It seems that dhclient is run from hotplug or something which makes it start before the main syslogd starts. Do we have any idea of what else might potentially be started in such a manner? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From jorton at redhat.com Tue Sep 21 10:23:58 2004 From: jorton at redhat.com (Joe Orton) Date: Tue, 21 Sep 2004 11:23:58 +0100 Subject: preserving changed directory permissions in RPM Message-ID: <20040921102358.GA23011@redhat.com> I'm just going through some old bugs; there are a couple of reports that the permissions on /var/www/html are not preserved over an apache package update, i.e. if the user changes the permissions, they are reverted to the defaults after an upgrade, which is vageuly undesirable. I presume RPM still behaves like this? Is it possible to change this with an equivalent to %config for directories? joe From dwmw2 at infradead.org Tue Sep 21 10:49:47 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 21 Sep 2004 11:49:47 +0100 Subject: Announcing Fedora Core 3 Test 2 In-Reply-To: <20040920141606.GA30766@nostromo.devel.redhat.com> References: <20040920141606.GA30766@nostromo.devel.redhat.com> Message-ID: <1095763787.31730.4325.camel@imladris.demon.co.uk> On Mon, 2004-09-20 at 10:16 -0400, Bill Nottingham wrote: > Coming soon to a site near you... for the first time, it's the new, > digitally remastered, Fedora Core 3 Test 2! Bah. Still no PPC :) -- dwmw2 From kashif at linuxcraft.co.uk Tue Sep 21 11:44:34 2004 From: kashif at linuxcraft.co.uk (Kashif Ali) Date: Tue, 21 Sep 2004 12:44:34 +0100 Subject: Announcing Fedora Core 3 Test 2 References: <20040920141606.GA30766@nostromo.devel.redhat.com> <1095763787.31730.4325.camel@imladris.demon.co.uk> Message-ID: <000601c49fd0$5ddd1380$82368552@thor> Hi, Just wondering, is it safe to buy a Apple powerbook and install fedora on it , will all the hardware be supported. I was thinking of buying the 12" or 15" powerbook. Your comments on the powerbook are welcome :) Kashif ----- Original Message ----- From: "David Woodhouse" To: "Development discussions related to Fedora Core" Sent: Tuesday, September 21, 2004 11:49 AM Subject: Re: Announcing Fedora Core 3 Test 2 > On Mon, 2004-09-20 at 10:16 -0400, Bill Nottingham wrote: >> Coming soon to a site near you... for the first time, it's the new, >> digitally remastered, Fedora Core 3 Test 2! > > Bah. Still no PPC :) > > -- > dwmw2 > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From bob.deblier at telenet.be Tue Sep 21 11:54:08 2004 From: bob.deblier at telenet.be (Bob Deblier) Date: Tue, 21 Sep 2004 13:54:08 +0200 Subject: Announcing Fedora Core 3 Test 2 In-Reply-To: <000601c49fd0$5ddd1380$82368552@thor> References: <20040920141606.GA30766@nostromo.devel.redhat.com> <1095763787.31730.4325.camel@imladris.demon.co.uk> <000601c49fd0$5ddd1380$82368552@thor> Message-ID: <1095767648.2829.43.camel@orion> The current Fedora development boot.iso image doesn't work on my OldWorld Mac (a 7300; tried the kernel and ramdisk with BootX) since I first tested a couple of weeks ago. The same boot image also doesn't work with the PearPC emulator. I don't have any more recent hardware to test on. Maybe other people have had better results. You may want to take a look at YellowDog Linux, another rpm-based distro. Sincerely, Bob Deblier On Tue, 2004-09-21 at 13:44, Kashif Ali wrote: > Hi, > > Just wondering, is it safe to buy a Apple powerbook and install fedora on it > , will all the hardware be supported. I was thinking of buying the 12" or > 15" powerbook. Your comments on the powerbook are welcome :) > > Kashif From buildsys at redhat.com Tue Sep 21 12:04:36 2004 From: buildsys at redhat.com (Build System) Date: Tue, 21 Sep 2004 08:04:36 -0400 Subject: rawhide report: 20040921 changes Message-ID: <200409211204.i8LC4aE15365@porkchop.devel.redhat.com> New package cscope C source code tree search and browse tool New package gcc4 Preview of GCC version 4.0 New package kdewebdev WEB Development package for the K Desktop Environment. New package thunderbird Mozilla Thunderbird mail/newsgroup client Removed package gtkglarea Updated Packages: 4Suite-1.0-3 ------------ * Tue Sep 14 2004 Miloslav Trmac - 1.0-3 - s/2.2/%pyver/ in spec - Link scripts to /usr/bin - Own created directories HelixPlayer-1.0.gold-4 ---------------------- * Tue Sep 14 2004 Colin Walters 1.0.gold-4 - Add patch from Real to fix math64.h compilation - Invoke update-desktop-database in post and postun, in preparation for fixing .desktop file for mime system - Address some issues from #130744, thanks Ling Li: - Do release build - Install release binary - Fix typo in png installation - Remove hack for installing debug ogg format MAKEDEV-3.12.2-1 ---------------- * Tue Sep 14 2004 Jeremy Katz - 3.12.2-1 - add the vcsa user and floppy group in the MAKEDEV package now * Mon Sep 13 2004 Nalin Dahyabhai 3.12.1-1 - nuke the "dev" subpackage * Tue Sep 07 2004 Nalin Dahyabhai 3.12-1 - add a -a (alwayscreate) flag, to skip checking if the device node is already present with the desired permissions/ownership/context - add a -u (udev permissions) flag, to spit out udev-style permissions settings for whatever nodes we would be creating MagicPoint-1.11a-1 ------------------ * Wed Sep 15 2004 Akira TAGOH - 1.11a-1 - New upstream release. - magicpoint-1.11a-fix-gcc-warnings.patch: updated from 1.10a. - magicpoint-1.10a-fixtypo-opaque.patch: removed, it's no lnger needed. - magicpoint-1.10a-fix-ft2build.patch: removed, it's no longer needed. - magicpoint-1.10a-png.patch: removed, it's no longer needed. - XFree4.0-freetype.patch: removed, freetype1 is no longer available. SysVinit-2.85-33 ---------------- * Fri Sep 17 2004 Bill Nottingham 2.85-33 - updated SELinux patch from Stephen Smalley abiword-2.0.11-3 ---------------- * Tue Sep 14 2004 Caolan McNamara 1:2.0.11-3 - #132389# Add more abiword supported mime types to abiword.desktop acl-2.2.23-5 ------------ * Thu Sep 16 2004 Jeremy Katz - 2.2.23-5 - make the libs executable so that we find their dependencies (#132696) * Fri Sep 10 2004 Stephen C. Tweedie 2.2.23-4 - libacl-devel Requires: libattr-devel for libattr.la * Fri Sep 10 2004 Stephen C. Tweedie 2.2.23-3 - Requires libtool >= 1.5 for building apr-util-0.9.4-17 ----------------- * Fri Sep 17 2004 Joe Orton 0.9.4-17 - add security fix for CAN-2004-0786 attr-2.4.16-3 ------------- * Fri Sep 10 2004 Stephen C. Tweedie 2.4.16-3 - Build requires libtool >= 1.5 automake-1.9.2-2 ---------------- * Mon Sep 20 2004 Daniel Reed - 1.9.2-1 - version bump - Sort rm commands output for mostlyclean-generic, clean-generic, distclean-generic and maintainer-clean-generic, so that the produced Makefile is not sensitive to the way Perl sorts its hashes. - Support `+' in the name of directories given to `include'. - Preserve spaces in the arguments of `compile'. - `missing' will no longer try to emulate a tool that is run with `--version' or `--help' as argument. - There is a new chapter about the history of Automake. bash-3.0-14 ----------- * Fri Sep 10 2004 Tim Waugh 3.0-14 - Don't run tests that read from /dev/tty. - Patchlevel 13. * Wed Sep 08 2004 Tim Waugh 3.0-13 - Check for EINVAL from waitpid() and avoid WCONTINUED in that case. - Fixed jobs4 test. - Applied experimental upstream patch for trap compatibility. - Re-make documentation to reflect source changes. * Tue Sep 07 2004 Tim Waugh 3.0-12 - Remove 'bashbug' from the documentation, because we don't ship it due to biarch concerns. bind-9.2.4rc8-14 ---------------- * Mon Sep 20 2004 Jason Vas Dias - 10:9.2.4rc8-14 - Upgrade to upstream bind-9.2.4rc8 . - Progress: Finally! Hooray! ISC bind now distributes: - o named.conf(5) and nslookup(8) manpages - 'bind-manpages.bz2' source can now disappear - (could this have something to do with ISC bug I raised about this?) - o 'deprecation_msg' global has vanished - bind-9.2.3rc3-deprecation_msg_shut_up.diff.bz2 can disappear * Mon Sep 20 2004 Jason Vas Dias - 10:9.2.4rc8-14 - Fix bug 106572/132385: copy /etc/localtime to chroot on start binutils-2.15.91.0.2-9 ---------------------- * Mon Sep 20 2004 Jakub Jelinek 2.15.91.0.2-9 - avoid almost 1MB (sparse) gaps in the middle of -z relro libraries on x86-64 (Andreas Schwab) - fix -z relro to make sure end of PT_GNU_RELRO segment is always COMMONPAGESIZE aligned booty-0.43-1 ------------ * Mon Sep 13 2004 Jeremy Katz - 0.43-1 - preserve some more consoles (#131301) - add magicboot for Power Mac (from ) bug-buddy-2.8.0-1 ----------------- * Mon Sep 13 2004 Christopher Aillon 1:2.8.0-1 - Update to 2.8.0 - Make sure to update MIME database for core file handling * Sun Aug 22 2004 Christopher Aillon 1:2.7.91-1 - update to 2.7.91 * Tue Aug 03 2004 Christopher Aillon 1:2.7.0-1 - update to 2.7.0 busybox-1.00.rc1-4 ------------------ * Fri Sep 17 2004 Phil Knirsch - 1.00.rc1-4 - Fixed double free in freecon() call (#132809) * Fri Sep 10 2004 Daniel Walsh - 1.00.rc1-3 - Add CONFIG_STATIC=y for static builds cdrtools-2.01.1-2 ----------------- * Mon Sep 13 2004 Harald Hoyer - 8:2.01.1-2 - fixed scsi-globbing * Mon Sep 13 2004 Harald Hoyer - 8:2.01.1-1 - final 2.01 version checkpolicy-1.17.5-1 -------------------- * Sat Sep 04 2004 Dan Walsh 1.17.5-1 - Latest from NSA * Fixed Makefile dependencies (Chris PeBenito). * Sat Sep 04 2004 Dan Walsh 1.17.4-1 - Latest from NSA * Fixed Makefile dependencies (Chris PeBenito). * Sat Sep 04 2004 Dan Walsh 1.17.3-1 - Latest from NSA * Merged fix for role dominance ordering issue from Chad Hanson of TCS. control-center-2.7.1-4 ---------------------- * Mon Sep 20 2004 Ray Strode - 1:2.7.1-4 - remove Preferred Applications entry from Preferences menu coreutils-5.2.1-24 ------------------ * Tue Sep 14 2004 Tim Waugh 5.2.1-24 - SELinux patch fix: don't display '(null)' if getfilecon() fails (bug #131196). createrepo-0.3.8-1 ------------------ * Mon Sep 13 2004 Paul Nasrat - New upstream version - 0.3.8 crontabs-1.10-7 --------------- * Mon Sep 20 2004 Jason Vas Dias - rebuilt under new CVS for dist-fc3 cups-1.1.21-1.rc2.2 ------------------- * Thu Sep 09 2004 Tim Waugh 1:1.1.21-1.rc2.2 - Updated DBUS patch (from Colin Walters). dbus-0.22-7 ----------- * Thu Sep 16 2004 John (J5) Palmieri - reverting BuildRequires: redhat-release because of issues with build system - added precompiled version of the messagebus init script * Thu Sep 16 2004 John (J5) Palmieri - changed /etc/redhat-release to the package redhat-release * Thu Sep 16 2004 John (J5) Palmieri - added python int64 patch from davidz desktop-printing-0.13-1 ----------------------- * Mon Sep 20 2004 Colin Walters 0.13-1 - Update to new upstream 0.13 + Fixes polling of local printers * Tue Sep 14 2004 Colin Walters 0.12-1 - Update to new upstream 0.12 + Fixes several serious bugs in driver prompt + Also installs policy to make sure we do not get kicked off D-BUS - Disable GConf schema install * Tue Sep 07 2004 Colin Walters 0.11 - Update to new upstream 0.11 + Makes printer driver prompt actually work device-mapper-1.00.19-2 ----------------------- * Fri Sep 17 2004 Alasdair Kergon - 1.00.19-2 - Missing BuildRequires. [bz 121133] dhcpv6-0.10-7 ------------- docbook-dtds-1.0-25 ------------------- * Mon Sep 13 2004 Tim Waugh 1.0-25 - DocBook 4.3 SGML and XML (bug #131861). dvgrab-1.6-1 ------------ * Sun Sep 19 2004 Warren Togami 1.6-1 - upgrade to 1.6 e2fsprogs-1.35-11 ----------------- * Fri Sep 17 2004 Thomas Woerner 1.35-11 - extended "-C" option of fsck to pass the file descriptor to the checker (#132543) * Thu Sep 16 2004 Thomas Woerner 1.35-10 - fixed double free in resize2fs (#132707) eel2-2.8.0-1 ------------ * Mon Sep 13 2004 Alexander Larsson - 2.8.0-1 - update to 2.8.0 elinks-0.9.2-0.rc7.4 -------------------- * Mon Sep 20 2004 Jindrich Novy 0.9.2-0.rc7.4 - 0.9.2rc7. * Mon Sep 13 2004 Tim Waugh 0.9.2-0.rc4.3 - Avoid symbol clash (bug #131170). evolution-2.0.0-2 ----------------- * Mon Sep 20 2004 David Malcolm - 2.0.0-2 - rebuilt * Tue Sep 14 2004 David Malcolm - 2.0.0-1 - Update from 1.5.94.1 to 2.0.0 - Change source FTP location from 1.5 to 2.0 - Updated dependency on e-d-s from 0.0.99 to 1.0.0 - Documentation has now moved from 1.5 to 2.0 * Tue Aug 31 2004 David Malcolm - 1.5.94.1-1 - updated tarball from 1.5.93 to 1.5.94.1 - the BASE_VERSION in the configure.in script has finally been updated from 1.5 to 2.0 (affects OAFIIDs, install dirs, binary names etc); updated evo_major and various other parts of the spec-file to reflect this; however documentation is still 1.5 in upstream tarball - updated dependency on libgal2 from 2:2.1.14 to 2:2.2.0 - updated dependency on libsoup from 2.1.13 to 2.2.0 - updated dependency on e-d-s from 0.0.98 to 0.0.99 evolution-connector-2.0.0-2 --------------------------- * Mon Sep 20 2004 David Malcolm - rebuilt * Tue Sep 14 2004 David Malcolm - 2.0.0-1 - update from 1.5.94.1 to 2.0.0 - update source FTP location from 1.5 to 2.0 evolution-data-server-1.0.0-2 ----------------------------- * Mon Sep 20 2004 David Malcolm - 1.0.0-2 - fixed various warnings in the calendar code (filed upstream here: http://bugzilla.ximian.com/show_bug.cgi?id=66383) * Tue Sep 14 2004 David Malcolm - 1.0.0-1 - update from 0.0.99 to 1.0.0 - changed path in FTP source location from 0.0 to 1.0 firefox-0.10.0-1.0PR1.0 ----------------------- * Tue Sep 14 2004 Christopher Aillon 0:0.10.0-1.0PR1.0 - Update to 1.0PR1 - Update man page references to say Firefox instead of Firebird - Remove gcc34 and extensions patch; they are now upstream - Update desktop database - Minor tweaks to the .desktop file firstboot-1.3.25-1 ------------------ * Tue Sep 14 2004 Adrian Likins - 1.3.25-1 - change finish screen to not show default "success" message if were also showing errors - fix forward/back behaviour freeciv-1.14.2-1 ---------------- * Mon Sep 13 2004 Karsten Hopp 1.14.2-1 - update to latest stable version fsh-1.2-5 --------- * Mon Sep 20 2004 David Woodhouse 1.2-5 - Apply Jim Blandy's patch to fix session reuse. Fixes #132659 gaim-1.0.0-3 ------------ * Mon Sep 20 2004 Warren Togami 1.0.0-3 - 141: Jabber chat room list fix * Mon Sep 20 2004 Daniel Reed 1.0.0-2 - #132967 Remove GenericName * Sat Sep 18 2004 Warren Togami 1.0.0-1 - 1.0.0 gcc-3.4.2-2 ----------- * Mon Sep 20 2004 Jakub Jelinek 3.4.2-2 - add .note.GNU-stack marking to ppc64 crtsavres.o and ia64 crt{begin,end,i,n}.o * Wed Sep 08 2004 Jakub Jelinek 3.4.2-1 - update from gcc-3_4-branch - GCC 3.4.2 release - PRs bootstrap/17325, target/17303, rtl-optimization/16408, fortran/17180 - gnu.regexp.* backport (Anthony Green) - java.ext.dirs (Anthony Green) - fix libjava hash synchronization (Hans Boehm, PR libgcj/16662) gdk-pixbuf-0.22.0-14 -------------------- * Wed Sep 15 2004 Matthias Clasen - 1:0.22.0-14 - Fix a bug in the last change which broke the xpm loader - build without gnome support * Wed Sep 15 2004 Matthias Clasen - 1:0.22.0-12 - Rebuild for FC3 * Tue Sep 14 2004 Bill Nottingham - 1:0.22.0-11 - build without gnome support gedit-2.7.92-3 -------------- * Wed Sep 15 2004 John (J5) Palmieri 1:2.7.92-2 - Added the spelling plugin to the default gconf schema so that the tools menu is not empty (RH Bug: 31607) gimp-2.0.4-6 ------------ * Thu Sep 16 2004 Nils Philippsen - rename desktop title (#132548) glibc-2.3.3-54 -------------- * Fri Sep 17 2004 Jakub Jelinek 2.3.3-54 - update from CVS - nscd getaddrinfo caching gnome-kerberos-0.3.3-1 ---------------------- * Thu Sep 16 2004 Nalin Dahyabhai 0.3.3-1 - default to not installing the menu entry (#131604) * Mon Jul 21 2003 Nalin Dahyabhai 0.3.2-1 - update to make newer automake happy * Mon Jan 27 2003 Nalin Dahyabhai 0.3.1-9 - rebuild gnome-keyring-0.4.0-1 --------------------- * Mon Sep 13 2004 Alexander Larsson - 0.4.0-1 - update to 0.4.0 gnome-mag-0.11.7-1 ------------------ * Mon Sep 20 2004 Colin Walters 0.11.7-1 - Update to 0.11.7 gnome-media-2.8.0-1 ------------------- * Mon Sep 13 2004 Colin Walters 2.8.0-1 - Remove upstreamed cd-sink-fix.patch gnome-pilot-2.0.12-2 -------------------- * Mon Sep 20 2004 David Malcolm - rebuilt * Wed Sep 15 2004 David Malcolm - 2.0.12-1 - Update from 2.0.11 to 2.0.12 - Removed patch to fix bx #131560; this is now in the upstream source gnome-pilot-conduits-2.0.12-2 ----------------------------- * Mon Sep 20 2004 David Malcolm - rebuilt * Wed Sep 15 2004 David Malcolm - 2.0.12-1 - update upstream tarball and dependency on gnome-pilot from 2.0.11 to 2.0.12 gnome-session-2.8.0-1 --------------------- * Fri Sep 17 2004 Ray Strode 2.8.0-1 - Update to 2.8.0 - Remove "Session" item from Preferences menu gnome-speech-0.3.5-4 -------------------- * Thu Sep 16 2004 Jonathan Blandford 0.3.5-4 - change ExclusiveArch to Requires festival only on i386 * Wed Sep 15 2004 Tim Powers 0.3.5-3 - ExclusiveArch i386 since festival only exists for i386, otherwise we break deps gnome-vfs2-2.8.0-3 ------------------ * Thu Sep 16 2004 Mark McLoughlin - 2.8.0-3 - Update to desktop-file-utils 0.8 and remove a bunch of upstreamed patches * Tue Sep 14 2004 Alexander Larsson - 2.8.0-2 - Backport some fixes from head, including ftp stuff * Mon Sep 13 2004 Alexander Larsson - 2.8.0-1 - update to 2.8.0 - remove upstreamed patch gnome-volume-manager-1.1.0-1 ---------------------------- * Mon Sep 20 2004 David Zeuthen - Update to upstream version 1.1.0 - Fix requirement for gnome-cd to be the gnome-media package * Mon Sep 20 2004 David Zeuthen - Add locking patch * Fri Sep 17 2004 John (J5) Palmieri - Update to upstream 1.0.2 - Readd patches I took out by accident - Add a requirement for gthumb and gnome-cd gnopernicus-0.9.12-1 -------------------- * Fri Sep 03 2004 Colin Walters 0.9.12-1 - New upstream 0.9.12 * Fri Sep 03 2004 Colin Walters 0.9.11-1 - New upstream 0.9.11 - Kill off desktop file entirely (#132570). * Fri Sep 03 2004 Colin Walters 0.9.10-3 - Use desktop-file-install to install .desktop file, move into Preferences->Accessibility (#131729). gok-0.11.8-1 ------------ * Mon Sep 20 2004 Colin Walters 0.11.8-1 - Update to 0.11.8 groff-1.18.1.1-2 ---------------- * Thu Sep 16 2004 Thomas Woerner 1.18.1.1-2 - fixed DoCharacter calls in xditview (#110812) - fixed fclose called once too often (#132690): thanks to Ulrich Drepper for the bug hunting gthumb-2.4.2-1 -------------- * Mon Sep 13 2004 Christopher Aillon 2.4.2-1 - gthumb.desktop: Add supported mime types (#131740) - gthumb.spec: Run update-desktop-database (#131740) - Update to 2.4.2 gtk2-2.4.9-9 ------------ * Wed Sep 15 2004 Matthias Clasen - 2.4.9-9 - Fix issues in the xpm and ico loaders found by Chris Evans (#130711) gtkhtml3-3.3.2-1 ---------------- * Thu Sep 16 2004 Owen Taylor - 3.3.2-1 - Upgrade to 3.3.2 (Fixes tab display, #132208, ordering issues with IM preedit #130751, Leon Ho) * Fri Sep 03 2004 Owen Taylor - 3.3.1-1 - Upgrade to 3.3.1, includes GtkFileChoose support (#130039) gtksourceview-1.1.0-3 --------------------- * Mon Sep 20 2004 Matthias Clasen - 1.1.0-3 - Fix problem with backspace to delete partial characters gv-3.5.8-29 ----------- * Sun Sep 19 2004 Dan Williams 3.5.8-29 - Fix .desktop file (#125849) hal-0.2.98-4 ------------ * Mon Sep 20 2004 David Zeuthen 0.2.98-4 - Rebuilt * Mon Sep 20 2004 David Zeuthen 0.2.98-3 - Rebuilt * Mon Sep 20 2004 David Zeuthen 0.2.98-2 - Temporarily disable explicit requirement for libselinux hotplug-2004_04_01-5 -------------------- * Mon Sep 20 2004 Bill Nottingham 3:2004_04_01-5 - use /lib/firmware instead of /usr/lib/hotplug/firmware howl-0.9.6-3 ------------ * Tue Sep 14 2004 Alexander Larsson - 0.9.6-3 - checkcfg nifd, but don't start it by default (#130240) htmlview-3.0.0-6 ---------------- * Sat Sep 18 2004 Warren Togami - 3.0.0-6 - #132869 Anvil's exists() fix * Thu Sep 16 2004 GNOME - 3.0.0-5 - remove desktop files. httpd-2.0.51-5 -------------- * Sat Sep 18 2004 Joe Orton 2.0.51-5 - switch to Jeff Trawick's child reclaim timing logic patch - migration guide updates * Thu Sep 16 2004 Joe Orton 2.0.51-4 - fix pcre includes * Thu Sep 16 2004 Joe Orton 2.0.51-3 - update to 2.0.51 hwdata-0.132-1 -------------- * Fri Sep 17 2004 Bill Nottingham - 0.132-1 - fix 3Ware 9000 mapping (#132851) * Tue Sep 14 2004 Kristian H??gsberg - 0.131-1 - Add python script to check sorting of pci.ids im-sdk-12.0.1-7.svn1891 ----------------------- * Wed Sep 15 2004 Akira TAGOH - 1:12.0.1-7.svn1891 - use %{im_dir} macro for htt's home directory instead of /usr/lib/im. (#132632) * Mon Sep 13 2004 Akira TAGOH - im-sdk-12.0.1-canna-calloc.patch: applied to fix the corrupt memory access. (Warren Togami, #132108) - im-sdk-12.0.1-canna-aux-refcount.patch: applied to destroy the aux object when it's not used. (#132508) NOTE: if the process is already running, you have to kill it first to get working properly. * Thu Sep 09 2004 Akira TAGOH 1:12.0.1-6.svn1891 - im-sdk-12.0.1-iiimsf-letool-usage.patch: improve the help message. - contained syscfg.h to iiimf-libs-devel. initscripts-7.82-1 ------------------ * Fri Sep 17 2004 Bill Nottingham - 7.82-1 - fix handling of nonexistent devices (#132839) - rhgb enhancements (, #132665) - initscripts.spec: require nash (#132513) - translation updates * Tue Sep 14 2004 Karsten Hopp 7.81-1 - load iucv device config after /etc/sysconfig/network so that GATEWAY doesn't get overwritten iproute-2.6.9-3 --------------- * Sat Sep 18 2004 Joshua Blanton 2.6.9-3 - added installation of netem module for tc iptables-1.2.11-3.1 ------------------- * Fri Sep 17 2004 Thomas Woerner 1.2.11-3.1 - changed default behaviour for IPTABLES_STATUS_NUMERIC to "yes" (#129731) - modified config file to match this change and un-commented variables with default values * Thu Sep 16 2004 Thomas Woerner 1.2.11-3 - applied second part of cleanup patch from (#131848): thanks to Steve Grubb for the patch jadetex-3.12-11 --------------- * Tue Sep 14 2004 Tim Waugh 3.12-11 - Build requires tetex-fonts (bug #132529). jwhois-3.2.2-5 -------------- * Mon Sep 13 2004 Miloslav Trmac - 3.2.2-5 - Update config file for .de (#132362, by Robert Scheck) * Tue Jun 15 2004 Elliot Lee - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt kdelibs-3.3.0-3 --------------- * Mon Sep 20 2004 Than Ngo 3.3.0-3 - fix a bug in ksslopen #114835 kernel-2.6.8-1.584 ------------------ * Mon Sep 20 2004 Arjan van de Ven - 2.6.9-rc2-bk5 * Thu Sep 16 2004 Arjan van de Ven - fix tux for x86-64 and ppc64 * Tue Sep 14 2004 Arjan van de Ven - 2.6.9-rc2 - add diskdump kernel-utils-2.4-13.1.27 ------------------------ * Wed Sep 15 2004 Arjan van de Ven - refresh smartmontools * Mon Sep 13 2004 Arjan van de Ven - fix missing buildreqs from bug 132410 koffice-1.3.3-1 --------------- * Wed Sep 15 2004 Than Ngo 4:1.3.3-1 - update to 1.3.3 kudzu-1.1.90-1 -------------- * Fri Sep 17 2004 Bill Nottingham - 1.1.90-1 - migrate OSS mixer save/restore lines on upgrade from OSS modules - write 'options snd-card-%d index=%d' for ALSA - clean up sound card removal code libc-client-2002e-8 ------------------- * Mon Sep 20 2004 Joe Orton 2002e-8 - drop conflict with imap (#132928) libcroco-0.6.0-3 ---------------- * Mon Sep 20 2004 Matthias Clasen - 0.6-3 - Don't memset() stack variables libdv-0.103-1 ------------- * Sun Sep 19 2004 Warren Togami - 0:0.103-1 - upgrade to 0.103 libgal2-2.2.1-3 --------------- * Mon Sep 20 2004 David Malcolm - 2:2.2.1-3 - rebuilt * Mon Sep 20 2004 David Malcolm - 2:2.2.1-2 - rebuilt * Tue Sep 14 2004 David Malcolm - 2:2.2.1-1 - 2.2.1; updated source FTP location libgnomecups-0.1.12-1 --------------------- * Mon Sep 13 2004 Colin Walters 0.1.12-1 - New upstream release - Remove upstreamed thread-init patch - Remove upstreamed async-printers patch - Actually apply DBus patch * Thu Sep 09 2004 Colin Walters 0.1.11-5 - Use DBus to get notifications of new printers. libgnomeui-2.7.92-2 ------------------- * Fri Sep 17 2004 Matthias Clasen 2.7.92-2 - make the gnome-vfs file chooser backend work better with ftp: libpng-1.2.7-1 -------------- * Wed Sep 15 2004 Matthias Clasen - 2:1.2.6-1 - Update to 1.2.7 libselinux-1.17.13-1 -------------------- * Mon Sep 20 2004 Dan Walsh 1.17.13-1 - Upgrade to latest from NSA * Thu Sep 16 2004 Dan Walsh 1.17.12-2 - Add selinux_removable_context_path linuxwacom-0.6.4-2 ------------------ * Mon Sep 13 2004 Kristian H??gsberg 0:0.6.4-1 - Add udev rule to create /dev/input/wacom lslk-1.29-12 ------------ * Fri Sep 10 2004 Jindrich Novy - fixed segfault #60866 - readlink patch lvm2-2.00.24-2 -------------- * Fri Sep 17 2004 Alasdair Kergon - 2.00.24-2 - Obsolete old lvm1 packages; refuse install if running kernel 2.4. [bz 128185] * Thu Sep 16 2004 Alasdair Kergon - 2.00.24-1 - More upstream fixes. (Always check WHATS_NEW file for details.) - Add requested BuildRequires. [bz 124916, 132408] * Wed Sep 15 2004 Alasdair Kergon - 2.00.23-1 - Various minor upstream fixes. man-pages-ja-20040915-1 ----------------------- * Wed Sep 15 2004 Akira TAGOH - 20040915-1 - updates to 20040915. mutt-1.4.1-10 ------------- * Wed Sep 15 2004 Nalin Dahyabhai 5:1.4.1-10 - expect the server to prompt for additional auth data if we have some to send (#129961, upstream #1845) - use "pop" as the service name instead of "pop-3" when using SASL for POP, per rfc1734 nautilus-2.8.0-1 ---------------- * Mon Sep 13 2004 Alexander Larsson - 2.8.0-1 - Update to 2.8.0 nautilus-cd-burner-2.8.1-3 -------------------------- * Mon Sep 20 2004 Alexander Larsson - 2.8.1-3 - fix up is_rewritable patch to not change api * Fri Sep 17 2004 Alexander Larsson - 2.8.1-2 - Add patch to detect rewritable discs on older drives * Fri Sep 17 2004 Alexander Larsson - 2.8.1-1 - update to 2.8.1 - Add fixes patch to fix some small details - Add asserts patch to not assert if mmc profiling fails (#132479, #132645) - Add patch that makes n-c-b use hal to get media type - Enable hal support nautilus-media-0.8.1-1 ---------------------- * Mon Sep 20 2004 Colin Walters 0.8.1-1 - New upstream version 0.8.1 nc-1.10-22 ---------- * Tue Sep 21 2004 Radek Vokal 1.10-22 - timeout option patch when SIGALRM blocked (#132973) * Tue Jun 15 2004 Elliot Lee - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt nedit-5.4-3 ----------- * Mon Sep 20 2004 Jindrich Novy - added nedit icon to be present in menus #131601 - updated spec to put it to the right place - icon made by Joor Loohuis (joor at users.sourceforge.net) - the icon processed by Peter Vrabec (pvrabec at usu.cz) nmap-3.70-1 ----------- * Mon Sep 13 2004 Harald Hoyer - 2:3.70-1 - version 3.70 ntp-4.2.0.a.20040617-1 ---------------------- * Mon Sep 13 2004 Harald Hoyer - 4.2.0.a.20040617-1 - version ntp-stable-4.2.0a-20040617 openobex-1.0.1-1 ---------------- * Mon Sep 13 2004 Harald Hoyer 1.0.1-1 - version 1.0.1 openssh-3.9p1-7 --------------- * Mon Sep 20 2004 Bill Nottingham 3.9p1-7 - when using gtk2 for askpass, don't buildprereq gnome-libs-devel * Tue Sep 14 2004 Nalin Dahyabhai 3.9p1-6 - build * Mon Sep 13 2004 Nalin Dahyabhai - disable ACSS support oprofile-0.8.1-6 ---------------- * Wed Sep 15 2004 Will Cohen - Clean up file manifests. * Mon Sep 13 2004 Will Cohen - Rebase on 0.8.1 release. pam-0.77-58 ----------- * Fri Sep 17 2004 Dan Walsh 0.77-58 - rebuild selinux patch using checkPasswdAccess pango-1.6.0-2 ------------- * Mon Sep 20 2004 Owen Taylor - 1.6.0-2 - Add patch from CVS to fix display of U+3000 (#132203, reported upstream by Suresh Chandrasekharan, Federic Zhang) * Mon Sep 20 2004 Owen Taylor - 1.6.0-1 - Version 1.6.0 - Add patch from CVS to fix bitmap-fonts/no-hint problem (#129246) parted-1.6.15-1 --------------- * Mon Sep 20 2004 Jeremy Katz - 1.6.15-1 - 1.6.15 * Fri Sep 10 2004 Jeremy Katz - 1.6.14-1 - update to 1.6.14 pcmcia-cs-3.2.7-1.12 -------------------- * Tue Sep 21 2004 Bill Nottingham - rebuild planner-0.12-5 -------------- * Sun Sep 19 2004 Dan Williams 0.12-5 - Add BuildReq scrollkeeper again (#124184, #111145) - Add Requires shared-mime-info for update-mime-database - Fix up planner's .desktop file (#132566) ppp-2.4.2-5.1 ------------- * Thu Sep 16 2004 Thomas Woerner 2.4.2-5.1 - fixed subscript out of range (#132677) * Wed Sep 15 2004 Thomas Woerner 2.4.2-5 - example scripts are using change_resolv_conf to modify /etc/resolv.conf (#132482) - require new libpcap library (>= 0.8.3-6) with a fix for inbound/outbound filter processing - not using internal libpcap structures anymore, fixes inbound/outbound filter processing (#128053) procps-3.2.3-4 -------------- * Thu Sep 16 2004 Dan Walsh 3.2.3-4 - Fix spec file to use makefile quota-3.12-3 ------------ * Mon Sep 13 2004 Steve Dickson - upgraded to 3.12 redhat-artwork-0.99-1 --------------------- * Mon Sep 13 2004 Alexander Larsson - 0.99-1 - Fix rtl icons - Don't use the iconrc anymore rhgb-0.13.2-1 ------------- * Sat Sep 18 2004 Daniel Veillard 0.13.2 - add support for specific conf file in /etc/rhgb/xorg.conf #131063 - avoid dropping back to text mode between rhgb end and gdm #108665 * Wed Sep 15 2004 Daniel Veillard 0.13.1 - fix vt1 switching #131899 - fix fsck reporting, exporing it to the vte, requires a patch to initscript too #107121, #129881 - move temp fielsystem to /etc/rhgb/temp - provide a mechanism to output to the detailed view - automatically switch to detailed view or vt1 on timeouts rhn-applet-2.1.10-2fc --------------------- * Wed Sep 15 2004 Adrian Likins 2.1.10-1 - we would of nagged people when they shouldnt be nagged, fix * Tue Sep 14 2004 Adrian Likins 2.1.9-1 - implement a friendly reminder to register with Red Hat Network - make sure we do it every three days, not every 5 seconds * Wed Jan 21 2004 Daniel Veillard 2.1.7-1 - trying to fix StopIteration exception on RPM iterators - string update. rhythmbox-0.8.6-2 ----------------- * Sat Sep 18 2004 Colin Walters - 0.8.6-2 - Fix postun to use correct syntax, thanks Nils Philippsen * Sat Sep 18 2004 Colin Walters - 0.8.6-1 - New upstream version - Call update-desktop-database in post and postun rpmdb-fedora-2.91-0.20040921 ---------------------------- s390utils-1.3.1-6 ----------------- * Thu Sep 16 2004 Phil Knirsch 2:1.3.1-6 - Added prompt=1 and timeout=15 to automatically generated menu screen-4.0.2-5 -------------- * Fri Sep 10 2004 Warren Togami 4.0.2-5 - #132321 and some minor spec cleanups selinux-policy-strict-1.17.18-3 ------------------------------- * Fri Sep 17 2004 Dan Walsh 1.17.18-3 - Add associate file_type nfs_t for mv command * Fri Sep 17 2004 Dan Walsh 1.17.18-2 - Change targeted policy to use devfs. * Thu Sep 16 2004 Dan Walsh 1.17.18-1 - Fix rhgb and console selinux-policy-targeted-1.17.18-3 --------------------------------- * Fri Sep 17 2004 Dan Walsh 1.17.18-3 - Add associate file_type nfs_t for mv command * Fri Sep 17 2004 Dan Walsh 1.17.18-2 - Change targeted policy to use devfs. * Thu Sep 16 2004 Dan Walsh 1.17.18-1 - Fix rhgb and console sound-juicer-0.5.12-1 --------------------- * Mon Sep 20 2004 Colin Walters 0.5.12-1 - New upstream version 0.5.12 - Delete upstreamed patch sound-juicer-0.5.9-pref-help.patch - Delete upstreamed patch sound-juicer-0.5.10-gstreamer.patch - Delete call to autoconf * Tue Jun 15 2004 Elliot Lee - rebuilt sox-12.17.5-3 ------------- * Wed Sep 15 2004 Thomas Woerner 12.17.5-3 - moved libst-config to devel package (#132489) spamassassin-3.0-9.rc4 ---------------------- * Sun Sep 12 2004 Warren Togami - 3.0-8.rc3 - 3.0 rc3 switchdesk-4.0.6-2 ------------------ * Thu Sep 16 2004 Than Ngo 4.0.6-2 - add intltool in BuildRequires #132620 - get rid of unneeded automake16 #132631 system-config-date-1.7.8-1 -------------------------- * Fri Sep 17 2004 Nils Philippsen 1.7.8-1 - use pool.ntp.org as first choice of NTP servers (#132787) * Thu Sep 16 2004 Nils Philippsen 1.7.7-2 - buildrequire python * Tue Sep 14 2004 Nils Philippsen 1.7.7-1 - byte-compile python files - first shot at something like an interface for firstboot system-config-httpd-1.3.0-1 --------------------------- * Fri Sep 10 2004 Phil Knirsch 1.3.0-1 - Huge HIG 2 compliance changes by Vladimir Djokic system-config-nfs-1.2.7-1 ------------------------- * Thu Sep 16 2004 Nils Philippsen 1.2.7-1 - close properties dialog when clicking OK button - handle missing /etc/exports gracefully - byte-compile python files * Sat Aug 14 2004 Nils Philippsen 1.2.4-1 - don't barf on optionless hosts - readonly is default system-config-samba-1.2.15-1 ---------------------------- * Wed Sep 15 2004 Nils Philippsen - 1.2.15-1 - write smbpasswd file when adding user (#132084) system-config-soundcard-1.2.9-1 ------------------------------- * Fri Sep 10 2004 Bill Nottingham 1.2.9-1 - build changes into a 1.2.9 release * Sun Aug 01 2004 Bastien Nocera - write a /etc/asound.conf when changing thedefault card * Wed Jul 21 2004 Bastien Nocera - remove useless debug - remove use of deprecated Python functions, - list USB audio devices - don't crash if we can't get the whole maker/model - use aplay to play sounds on 2.6 kernels system-config-users-1.2.19-1 ---------------------------- * Wed Sep 15 2004 Nils Philippsen - 1.2.19-1 - try to use gid as specified in /etc/libuser.conf, only if that fails use next free (#80624) system-switch-im-0.1.2-2 ------------------------ * Thu Sep 16 2004 Leon Ho 0.1.2-2 - fixed Makefile for locale-list * Thu Sep 09 2004 Leon Ho 0.1.2-1 - used locale-list to display more user friendly language names - fixed on the category for .desktop - only display languages who has more than one IM tcpdump-3.8.2-6 --------------- * Wed Sep 15 2004 Harald Hoyer - 14:3.8.2-6 - added libpcap-0.8.3-ppp.patch for ppp (bug 128053) tcsh-6.13-8 ----------- * Wed Sep 15 2004 Miloslav Trmac - 6.13-8 - Fix $HOSTTYPE and $MACHTYPE for ppc64 and s390x, this time for sure * Wed Sep 15 2004 Miloslav Trmac - 6.13-7 - Define $HOSTTYPE and $MACHTYPE for ppc64 and s390 (#115531), I hope that finally covers all architectures. * Wed Sep 15 2004 Miloslav Trmac - 6.13-6 - Define $HOSTTYPE and $MACHTYPE also on IA-64 and s390x (#115531) - Don't close sockets to avoid file descriptor conflits with nss_ldap (#112453) tetex-2.0.2-20 -------------- * Tue Sep 14 2004 Tim Waugh 2.0.2-20 - Update desktop database for XDvi (bug #131627). - Fix xdvi.desktop file (bug #131627). * Fri Sep 10 2004 Tim Waugh - Fix /usr/bin/xdviprint (bug #131915). tree-1.5.0-1 ------------ * Mon Sep 13 2004 Tim Waugh 1.5.0-1 - 1.5.0 (bug #131854). - No longer need utf8 or gcc34 patches. udev-030-27 ----------- * Mon Sep 20 2004 Harald Hoyer - 030-27 - simplified udev.conf - refined close_on_exec patch - added pam_console supply for symlinks, now gives correct permissions, for e.g. later plugged in cdroms - renamed sr? to scd? (see devices.txt; k3b likes that :) usbview-1.0-13 -------------- * Fri Sep 10 2004 John (J5) Palmieri - added patch supplied by David Paschal to fix RH bug 73120 util-linux-2.12a-8 ------------------ * Wed Sep 15 2004 Nalin Dahybhai 2.12a-8 - Fix #132196 - turn on SELinux support at build-time. * Wed Sep 15 2004 Phil Knirsch 2.12a-7 - Fix #91174 with pamstart.patch valgrind-callgrind-0.9.9-1 -------------------------- * Thu Sep 09 2004 Jakub Jelinek 0.9.9-1 - update to 0.9.9 vim-6.3.026-1 ------------- * Tue Sep 14 2004 Karsten Hopp 6.3.026-1 - patchlevel 26 (fixes an endless loop in syntax highlighting) vixie-cron-4.1-12 ----------------- * Fri Sep 17 2004 Jason Vas Dias - 4.1-12 - Merged Dan's patch with vixie-cron-4.1-11 which was not - latest version according to new CVS ?!?! * Fri Sep 17 2004 Dan Walsh - 4.1-12 - Updated SELinux patch to use checkPasswdAccess * Tue Aug 31 2004 Jason Vas Dias - 4.1-11 - Fixed SIGSEGV in free_user when !is_selinux_enabled() and crontab - has no valid jobs (bug 131390). vsftpd-2.0.1-4 -------------- * Thu Sep 16 2004 Radek Vokal 2.0.1-4 - spec file changed, ftp dir change commented (#130119) - added doc files (#113056) * Wed Sep 08 2004 Jan Kratochvil - update for 2.0.1 for SSL * Fri Aug 27 2004 Radek Vokal 2.0.1-2 - vsftpd.conf file changed, default IPv6 support vte-0.11.11-5 ------------- * Thu Sep 16 2004 Ray Strode 0.11.11-5 - Do bottom row snapping yet another way to fix scrolling artifacts (bug 131798) - Add new debugging patch for keeping track of row numbers * Thu Sep 09 2004 Ray Strode 0.11.11-4 - Fix "scroll on output" option (bug 131755) * Wed Sep 01 2004 Ray Strode 0.11.11-3 - A more robust bottom row snapping fix. wget-1.9.1-16 ------------- * Thu Sep 16 2004 Karsten Hopp 1.9.1-16 - more fixes * Tue Sep 14 2004 Karsten Hopp 1.9.1-15 - added strtol fix from Leonid Petrov, reenable LFS * Tue Sep 14 2004 Karsten Hopp 1.9.1-14 - buildrequires gettext (#132519) xcdroast-0.98a15-6 ------------------ * Fri Sep 10 2004 Harald Hoyer - 0.98a15-6 - improved scanning and removed warnings xchat-2.4.0-3 ------------- * Mon Sep 20 2004 Daniel Reed 1:2.4.0-3 - #132967 Remove GenericName xorg-x11-6.8.1-3 ---------------- * Mon Sep 20 2004 Mike A. Harris 6.8.1-3 - Bump to 6.8.1 and rebuild to quell beehive complaining - Disable "parallel_build", as it is still broken * Mon Sep 20 2004 Mike A. Harris 6.8.1-2 - Update main tarball to the final X.Org X11 6.8.1 release via CVS export of CVS tag XORG-6_8_1 - this obsoletes previous 6.8.1 tarball which was a upstream release mixup. - Added xorg-x11-6.8.0-libXdmcp-build-with-PIC.patch to make libXdmcp.a build with PIC flags to fix (#131130) - Fixed changelog dates and made changelog version-release strings consistent - Re-enable "parallel_build 1" to test if it works currently, so we can take advantage of SMP machines better * Wed Sep 15 2004 Kristian H??gsberg 6.8.1-1 - Update to xorg 6.8.1 - Change Source: to use xorg-6.8.1.tar.gz since that is what the tarball from http://freedesktop.org/~xorg/X11R6.8.1/src/single/ is called. ytalk-3.1.2-1 ------------- * Mon Sep 13 2004 Tim Waugh 3.1.2-1 - 3.1.2 (bug #131845). From dennis at ausil.us Tue Sep 21 12:05:27 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 21 Sep 2004 07:05:27 -0500 Subject: Announcing Fedora Core 3 Test 2 In-Reply-To: <1095767648.2829.43.camel@orion> References: <20040920141606.GA30766@nostromo.devel.redhat.com> <000601c49fd0$5ddd1380$82368552@thor> <1095767648.2829.43.camel@orion> Message-ID: <200409210705.27599.dennis@ausil.us> Once upon a time Tuesday 21 September 2004 6:54 am, Bob Deblier wrote: > The current Fedora development boot.iso image doesn't work on my > OldWorld Mac (a 7300; tried the kernel and ramdisk with BootX) since I > first tested a couple of weeks ago. The same boot image also doesn't > work with the PearPC emulator. I don't have any more recent hardware to > test on. Maybe other people have had better results. > > You may want to take a look at YellowDog Linux, another rpm-based > distro. I tried the current boot.iso on a G4 machine and it doesnt get the partitioning right it boots but screws up the system partitioning Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pnasrat at redhat.com Tue Sep 21 12:38:43 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 21 Sep 2004 13:38:43 +0100 Subject: Announcing Fedora Core 3 Test 2 In-Reply-To: <200409210705.27599.dennis@ausil.us> References: <20040920141606.GA30766@nostromo.devel.redhat.com> <000601c49fd0$5ddd1380$82368552@thor> <1095767648.2829.43.camel@orion> <200409210705.27599.dennis@ausil.us> Message-ID: <1095770323.7895.15.camel@anu.eridu> On Tue, 2004-09-21 at 07:05 -0500, Dennis Gilmore wrote: > Once upon a time Tuesday 21 September 2004 6:54 am, Bob Deblier wrote: > > The current Fedora development boot.iso image doesn't work on my > > OldWorld Mac (a 7300; tried the kernel and ramdisk with BootX) since I > > first tested a couple of weeks ago. The same boot image also doesn't > > work with the PearPC emulator. I don't have any more recent hardware to > > test on. Maybe other people have had better results. > > > > You may want to take a look at YellowDog Linux, another rpm-based > > distro. > > I tried the current boot.iso on a G4 machine and it doesnt get the > partitioning right it boots but screws up the system partitioning Same error as here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121384 If so could you add details of what exactly happened and how the partitioning was screwed up. If not new bug please... Paul From kashif at linuxcraft.co.uk Tue Sep 21 12:57:54 2004 From: kashif at linuxcraft.co.uk (Kashif Ali) Date: Tue, 21 Sep 2004 13:57:54 +0100 Subject: Announcing Fedora Core 3 Test 2 References: <20040920141606.GA30766@nostromo.devel.redhat.com><000601c49fd0$5ddd1380$82368552@thor> <1095767648.2829.43.camel@orion><200409210705.27599.dennis@ausil.us> <1095770323.7895.15.camel@anu.eridu> Message-ID: <002b01c49fda$9c6247b0$82368552@thor> Looks like I better stay away from the power book then :( Kashif ----- Original Message ----- From: "Paul Nasrat" To: "Development discussions related to Fedora Core" Sent: Tuesday, September 21, 2004 1:38 PM Subject: Re: Announcing Fedora Core 3 Test 2 > On Tue, 2004-09-21 at 07:05 -0500, Dennis Gilmore wrote: >> Once upon a time Tuesday 21 September 2004 6:54 am, Bob Deblier wrote: >> > The current Fedora development boot.iso image doesn't work on my >> > OldWorld Mac (a 7300; tried the kernel and ramdisk with BootX) since I >> > first tested a couple of weeks ago. The same boot image also doesn't >> > work with the PearPC emulator. I don't have any more recent hardware to >> > test on. Maybe other people have had better results. >> > >> > You may want to take a look at YellowDog Linux, another rpm-based >> > distro. >> >> I tried the current boot.iso on a G4 machine and it doesnt get the >> partitioning right it boots but screws up the system partitioning > > Same error as here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121384 > > If so could you add details of what exactly happened and how the > partitioning was screwed up. If not new bug please... > > Paul > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From pnasrat at redhat.com Tue Sep 21 12:49:19 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 21 Sep 2004 13:49:19 +0100 Subject: Announcing Fedora Core 3 Test 2 In-Reply-To: <002b01c49fda$9c6247b0$82368552@thor> References: <20040920141606.GA30766@nostromo.devel.redhat.com> <000601c49fd0$5ddd1380$82368552@thor> <1095767648.2829.43.camel@orion> <200409210705.27599.dennis@ausil.us> <1095770323.7895.15.camel@anu.eridu> <002b01c49fda$9c6247b0$82368552@thor> Message-ID: <1095770959.7895.18.camel@anu.eridu> On Tue, 2004-09-21 at 13:57 +0100, Kashif Ali wrote: > Looks like I better stay away from the power book then :( No manually partitioning works. Fedora is running on several macs at home and in the Cambridge office - with others outside. There are a few other bugs to hammer out, but autopartitioning is probably the worst atm. Paul From pnasrat at redhat.com Tue Sep 21 12:51:21 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 21 Sep 2004 13:51:21 +0100 Subject: Fedora PPC list moved Message-ID: <1095771081.7895.22.camel@anu.eridu> Please note for everyone who wants to help test and bug report for PPC on rawhide (powermac for the most part) the list is hosted at infradead.org: http://lists.infradead.org/mailman/listinfo/fedora-ppc/ Tracker bug here: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=121179 Paul From dwmw2 at infradead.org Tue Sep 21 15:23:39 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 21 Sep 2004 16:23:39 +0100 Subject: Announcing Fedora Core 3 Test 2 In-Reply-To: <1095770959.7895.18.camel@anu.eridu> References: <20040920141606.GA30766@nostromo.devel.redhat.com> <000601c49fd0$5ddd1380$82368552@thor> <1095767648.2829.43.camel@orion> <200409210705.27599.dennis@ausil.us> <1095770323.7895.15.camel@anu.eridu> <002b01c49fda$9c6247b0$82368552@thor> <1095770959.7895.18.camel@anu.eridu> Message-ID: <1095780218.17821.729.camel@hades.cambridge.redhat.com> On Tue, 2004-09-21 at 13:49 +0100, Paul Nasrat wrote: > On Tue, 2004-09-21 at 13:57 +0100, Kashif Ali wrote: > > Looks like I better stay away from the power book then :( > > No manually partitioning works. Fedora is running on several macs at > home and in the Cambridge office - with others outside. > > There are a few other bugs to hammer out, but autopartitioning is > probably the worst atm. Once it's installed, it's basically fine. I've been running it on my powerbook since FC2 and it's now running rawhide quite happily. Would be nice if suspend-to-ram would work with the newer powerbooks but that's a kernel problem which affects all distributions. And _hopefully_ there might be progress on that soon too. -- dwmw2 From louisg00 at bellsouth.net Tue Sep 21 22:52:22 2004 From: louisg00 at bellsouth.net (Louis Garcia) Date: Tue, 21 Sep 2004 18:52:22 -0400 Subject: FC3T2: unable to do a hard drive install Message-ID: <1095807142.2670.4.camel@tiger> Just got the 4 isos on a vfat partition. burned the boot.iso and booted it. when it comes to entering the partition and directory it can't find the media. I have double checked and it in the location I entered. Any help? --Thanks From seyman at wanadoo.fr Tue Sep 21 23:13:44 2004 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Wed, 22 Sep 2004 01:13:44 +0200 Subject: FC3T2: unable to do a hard drive install In-Reply-To: <1095807142.2670.4.camel@tiger> References: <1095807142.2670.4.camel@tiger> Message-ID: <20040921231343.GA5847@orient.maison.moi> On Tue, Sep 21, 2004 at 06:52:22PM -0400, Louis Garcia wrote: > > Just got the 4 isos on a vfat partition. burned the boot.iso and booted > it. when it comes to entering the partition and directory it can't find > the media. I have double checked and it in the location I entered. Any > help? switch to one of the other terminals to see if you have an error message. I can start the installation but Anaconda blows up halfway through the process. Emmanuel From feliciano.matias at free.fr Wed Sep 22 00:11:21 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 22 Sep 2004 02:11:21 +0200 Subject: rawhide report: 20040921 changes In-Reply-To: <200409211204.i8LC4aE15365@porkchop.devel.redhat.com> References: <200409211204.i8LC4aE15365@porkchop.devel.redhat.com> Message-ID: <1095811875.1148.32.camel@one.myworld> Le mar 21/09/2004 ? 14:04, Build System a ?crit : > New package cscope > ... Can you please sign the packages ? How secure is a selinux kernel if it can come from anywhere ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From notting at redhat.com Wed Sep 22 05:47:36 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 22 Sep 2004 01:47:36 -0400 Subject: initlog and minilogd In-Reply-To: <200409211711.44395.russell@coker.com.au> References: <200409211711.44395.russell@coker.com.au> Message-ID: <20040922054736.GC18721@nostromo.devel.redhat.com> Russell Coker (russell at coker.com.au) said: > At boot time I have initlog being run from a dhclient, and initlog then runs > minilogd. > > Currently the strict SE Linux policy does not permit minilogd to be run. What > is needed is the following rule: > > domain_auto_trans(dhcpc_t, syslogd_exec_t, syslogd_t) > > However there may be other instances of this problem. It seems that dhclient > is run from hotplug or something which makes it start before the main syslogd > starts. Do we have any idea of what else might potentially be started in > such a manner? network starts before syslog, so it's more or less expected. Bill From amrith at programmer.net Wed Sep 22 06:05:14 2004 From: amrith at programmer.net (Amrith ) Date: Wed, 22 Sep 2004 01:05:14 -0500 Subject: Announcing Fedora Core 3 Test 2 Message-ID: <20040922060514.C8E04790055@ws1-14.us4.outblaze.com> what is the kernel version ? thanks amrith ----- Original Message ----- From: Paul Nasrat Date: Tue, 21 Sep 2004 13:49:19 +0100 To: Development discussions related to Fedora Core Subject: Re: Announcing Fedora Core 3 Test 2 > On Tue, 2004-09-21 at 13:57 +0100, Kashif Ali wrote: > > Looks like I better stay away from the power book then :( > > No manually partitioning works. Fedora is running on several macs at > home and in the Cambridge office - with others outside. > > There are a few other bugs to hammer out, but autopartitioning is > probably the worst atm. > > Paul > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From dwmw2 at infradead.org Wed Sep 22 06:48:16 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 22 Sep 2004 07:48:16 +0100 Subject: Announcing Fedora Core 3 Test 2 In-Reply-To: <20040922060514.C8E04790055@ws1-14.us4.outblaze.com> References: <20040922060514.C8E04790055@ws1-14.us4.outblaze.com> Message-ID: <1095835696.31730.4351.camel@imladris.demon.co.uk> On Wed, 2004-09-22 at 01:05 -0500, Amrith wrote somewhere in the vague vicinity of a mail about using Fedora on Macs: > what is the kernel version ? Please don't top-post, and please use a non-broken mailer which actually includes References: headers when you reply to a mail. The kernel on the dual G5 is currently 2.6.8-1.550, and the one last booted on my powerbook is 2.6.8-1.581. The latter will be .584 next time it boots, I think. But they've both run most kernels since FC2. Why do you ask? -- dwmw2 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Sep 22 10:00:46 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 22 Sep 2004 12:00:46 +0200 Subject: Regarding Extras package announcements In-Reply-To: <20040920222709.63330698.fedora@wir-sind-cool.org> References: <414E7587.6050608@redhat.com> <20040920222709.63330698.fedora@wir-sind-cool.org> Message-ID: <20040922120046.205caa3b@localhost> Michael Schwendt wrote : > So, what and how do we announce? For reference, the _old_ list > archives are here: > http://www.fedora.us/pipermail/fedora-package-announce/ > > Suggestions? > Do we care? I think this simply can't be answered until more is known about the Extras process : Will the packages be pushed out individually or will there be batches, for instance a daily one like Rawhide? (this makes it easier for mirrors to keep up to date and consistent) Depending on the answer, individual messages like for erratas will make more sense than a Rawhide update style message or vice-versa. As for the formatting, same thing, will it be sent by the packager (or another individual, like the "moderator" that approved it) or by a build system? If questions like these are already answered somewhere, I don't know were, and would be glad to have someone point me to those details. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.42 0.42 0.39 From john at johnleach.co.uk Wed Sep 22 10:07:54 2004 From: john at johnleach.co.uk (John Leach) Date: Wed, 22 Sep 2004 11:07:54 +0100 Subject: kernel crash removing a bridged tun devices Message-ID: <1095847673.5770.7.camel@john> Hi, I'm bridging a tun device to give my qemu virtual machines network access. My script brings up tun0 and addif's it to br0. When I close qemu the kernel complains severely. If I'm running with an smp kernel my machine hard freezes. Fedora Core 2, fully updated, i686 Linux version 2.6.8-1.521 dmesg log attached. anyone know if this is likely due to Fedora additions to the kernel? Or should I be posting this upstream. (I should really test it with a vanilla kernel of course...) Or is it already know about and I've just missed the reports. John. -- GPG: B89C D450 5B2C 74D8 58FB A360 9B06 B5C2 26F0 3047 WEB: http://johnleach.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: tunbridging.log Type: text/x-log Size: 1883 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Wed Sep 22 10:15:48 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 22 Sep 2004 11:15:48 +0100 Subject: kernel crash removing a bridged tun devices In-Reply-To: <1095847673.5770.7.camel@john> References: <1095847673.5770.7.camel@john> Message-ID: <1095848148.17821.966.camel@hades.cambridge.redhat.com> On Wed, 2004-09-22 at 11:07 +0100, John Leach wrote: > anyone know if this is likely due to Fedora additions to the kernel? Or > should I be posting this upstream. It's a known bug, and it's already fixed upstream. The fix hasn't made it into an FC2 erratum yet. Try a rawhide kernel? -- dwmw2 From fedora at wir-sind-cool.org Wed Sep 22 10:26:04 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 22 Sep 2004 12:26:04 +0200 Subject: Regarding Extras package announcements In-Reply-To: <20040922120046.205caa3b@localhost> References: <414E7587.6050608@redhat.com> <20040920222709.63330698.fedora@wir-sind-cool.org> <20040922120046.205caa3b@localhost> Message-ID: <20040922122604.407d5c8c.fedora@wir-sind-cool.org> On Wed, 22 Sep 2004 12:00:46 +0200, Matthias Saou wrote: > Michael Schwendt wrote : > > > So, what and how do we announce? For reference, the _old_ list > > archives are here: > > http://www.fedora.us/pipermail/fedora-package-announce/ > > > > Suggestions? > > Do we care? > > I think this simply can't be answered until more is known about the Extras > process : Maybe, maybe not. We're supposed to continue with fedora.us releases, and since we have lost fedora-package-announce at fedora.us, there haven't been any package announcements anymore. > As for the formatting, same thing, will it be sent by the packager (or > another individual, like the "moderator" that approved it) or by a build > system? If it could be automated, that would be very good, e.g. like "rawhide report". So far, not every packager has posted announcements. The list archives cover maybe 50% of the published packages and updates. Maybe even less. -- Fedora Core release 2.91 (FC3 Test 2) - Linux 2.6.8-1.541 loadavg: 1.00 0.89 0.49 From NOS at Utel.no Wed Sep 22 11:21:32 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Wed, 22 Sep 2004 13:21:32 +0200 Subject: Regarding Extras package announcements In-Reply-To: <000601c4a08f$2b83ec50$14aaa8c0@utelsystems.local> References: <414E7587.6050608@redhat.com> <20040920222709.63330698.fedora@wir-sind-cool.org> <20040922120046.205caa3b@localhost> <000601c4a08f$2b83ec50$14aaa8c0@utelsystems.local> Message-ID: <1095852092.31078.53.camel@nos-rh.utelsystems.local> On Wed, 2004-09-22 at 12:30, Michael Schwendt wrote: > On Wed, 22 Sep 2004 12:00:46 +0200, Matthias Saou wrote: > > > Michael Schwendt wrote : > > > > > So, what and how do we announce? For reference, the _old_ list > > > archives are here: > > > http://www.fedora.us/pipermail/fedora-package-announce/ > > > > > > Suggestions? > > > Do we care? > > > > I think this simply can't be answered until more is known about the Extras > > process : > > Maybe, maybe not. We're supposed to continue with fedora.us releases, > and since we have lost fedora-package-announce at fedora.us, there > haven't been any package announcements anymore. > > > As for the formatting, same thing, will it be sent by the packager (or > > another individual, like the "moderator" that approved it) or by a build > > system? > > If it could be automated, that would be very good, e.g. like "rawhide > report". So far, not every packager has posted announcements. The > list archives cover maybe 50% of the published packages and updates. > Maybe even less. imho this should be automated. Most people just use fedora-pkgannfmt anyway, which could probably just be run as the bult packages are copied to their respective directories !? From buildsys at redhat.com Wed Sep 22 11:34:30 2004 From: buildsys at redhat.com (Build System) Date: Wed, 22 Sep 2004 07:34:30 -0400 Subject: rawhide report: 20040922 changes Message-ID: <200409221134.i8MBYUi05756@porkchop.devel.redhat.com> New package gnutls A TLS implementation. Removed package gcc35 Removed package commons-digester Removed package commons-dbcp Removed package commons-pool Removed package commons-beanutils Removed package commons-collections Updated Packages: GConf2-2.8.0.1-1 ---------------- * Tue Sep 21 2004 Mark McLoughlin 2.8.0.1-1 - Update to 2.8.0.1 HelixPlayer-1.0.gold-5 ---------------------- * Tue Sep 21 2004 David Woodhouse 1.0.gold-5 - Build on PPC MAKEDEV-3.13-1 -------------- * Tue Sep 14 2004 Nalin Dahyabhai 3.13-1 - excise all architecture-specific logic and configuration data -- udev knows no arch-specific details, so they should be irrelevant now - remove build conflicts on older RPM, unnecessary now that dev is gone - remove dev's %post fstab munging - add a short-circuit test for the common non-match cases ORBit2-2.12.0-1 --------------- * Tue Sep 21 2004 Mark McLoughlin 2.12.0-1 - Update to 2.12.0 anaconda-10.0.3.2-1 ------------------- * Tue Sep 21 2004 Jeremy Katz - 10.0.3.2-1 - some fixes for Arabic (#122228) - support using ksdevice=macaddr (#130605) - add an images/pxeboot directory on ia64 * Tue Sep 21 2004 Jeremy Katz - 10.0.3.1-1 - improve handling of non-physical consoles on some ppc and ia64 machines - add Bengali(India) and Gujarati to the lang-table (#126108) - add support for setting the CTC protocol on s/390 (#132324, #132325) - don't offer to do vnc if we don't have active nwtorking (#132833) - various typo/grammar fixes - add support for 'nostorage' and 'nonet' command line options to avoid auto-loading just network or storage devices - fix editing of pre-existing lvm (#132217) - fix going back from the partitions list on a driver disk (#132096) - don't show login error if silent errors (#132673) * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images autoconf-2.59-5 --------------- * Tue Sep 21 2004 Daniel Reed - 2.59-5 - rebuilt for dist-fc3 cdlabelgen-3.0.0-1 ------------------ * Tue Sep 21 2004 Harald Hoyer 3.0.0 - Updated to new version 3.0.0 cdrdao-1.1.9-5 -------------- * Tue Sep 21 2004 Harald Hoyer - 1.1.9-5 - removed INSTALL from doc (bug 132908) cleanfeed-0.95.7b-21 -------------------- * Tue Sep 21 2004 Than Ngo 0.95.7b-21 - rebuilt db4-4.2.52-6 ------------ * Tue Sep 21 2004 Nalin Dahyabhai 4.2.52-6 - on %{ix86} systems, make the availability of an NPTL-requiring libdb match the availability of an NPTL libpthread in glibc > 2.3.3-48 - run ldconfig in db4-java's %post/%postun - when building java support, assume that libgcj is equivalent enough to 1.3 ddskk-12.2.0-3 -------------- * Wed Sep 22 2004 Jens Petersen - 12.2.0-3 - clean up ddskk-init.el diskcheck-1.6-2 --------------- * Tue Sep 21 2004 Harald Hoyer - 2:1.6-2 - rebuilt elilo-3.4-9 ----------- * Tue Sep 21 2004 Jeremy Katz - 3.4-9 - rebuild * Wed Sep 15 2004 Jeremy Katz - 3.4-8 - add patch from Jesse Barnes for a crash when run from the bootmgr (#132600) fonts-KOI8-R-1.0-7 ------------------ * Tue Sep 21 2004 Than Ngo 1.0-7 - rebuilt gamin-0.0.10-1 -------------- * Tue Sep 21 2004 Daniel Veillard - upstream release 0.0.10 * Tue Sep 21 2004 Daniel Veillard 0.0.10-1 - more documentation - Added support for a configuration file $HOME/.gaminrc - fixes FAM compatibility issues with FAMErrno and FamErrlist #132944 * Wed Sep 01 2004 Daniel Veillard 0.0.9-1 - fix crash with konqueror #130967 - exclude kernel (dnotify) monitoring for /mnt//* /media//* gconf-editor-2.8.0-1 -------------------- * Tue Sep 21 2004 Mark McLoughlin 2.8.0-1 - Update to 2.8.0 gdm-2.6.0.5-1 ------------- * Mon Sep 20 2004 Ray Strode 1:2.6.0.5-1 - update to 2.6.0.5 gimp-data-extras-1.2.0-12 ------------------------- * Tue Sep 21 2004 Than Ngo 1.2.0-12 - rebuilt gnome-applets-2.8.0-2 --------------------- * Tue Sep 21 2004 Mark McLoughlin 2.8.0-2 - Remove the wireless applet and add patch to use the netstatus applet for backwards compat. bug #131652. * Tue Sep 21 2004 Mark McLoughlin 2.8.0-1 - Update to 2.8.0 gnome-desktop-2.8.0-1 --------------------- * Tue Sep 21 2004 Mark McLoughlin 2.8.0-1 - Update to 2.8.0 gnome-netstatus-2.8.0-2 ----------------------- * Tue Sep 21 2004 Mark McLoughlin 2.8.0-2 - Add patch to handle the wireless-applet OAFIID for compatibility. See bug #131652 * Tue Sep 21 2004 Mark McLoughlin 2.8.0-1 - Update to 2.8.0 gnome-nettool-0.99.3-2 ---------------------- * Tue Sep 21 2004 Mark McLoughlin 0.99.3-2 - Move to the System Tools menu from the Internet menu - bug #131619 gnome-panel-2.8.0-1 ------------------- * Tue Sep 21 2004 Mark McLoughlin 2.8.0-1 - Update to 2.8.0 gnome-pilot-2.0.12-3 -------------------- * Tue Sep 21 2004 David Malcolm - 2.0.12-3 - added fix for compile-time warnings (bugzilla 114281) gnome-pilot-conduits-2.0.12-3 ----------------------------- * Tue Sep 21 2004 David Malcolm - 2.0.12-3 - added fix for compile-time warnings (bugzilla 114282) gnome-vfs2-2.8.1-1 ------------------ * Tue Sep 21 2004 Alexander Larsson - 2.8.1-1 - update to 2.8.1 gnu-efi-3.0a-6 -------------- * Tue Sep 21 2004 Jeremy Katz - 3.0a-6 - add fix from Jesse Barnes for newer binutils (#129197) gtk-doc-1.2-2 ------------- * Tue Sep 21 2004 Matthias Clasen 1.2-2 - rebuild gtkhtml3-3.3.2-3 ---------------- * Tue Sep 21 2004 Owen Taylor - 3.3.2-2 - Add a patch to fix input method commit issues (#Bug 130751) hdparm-5.7-2 ------------ * Tue Sep 21 2004 Than Ngo 5.7-2 - rebuilt * Mon Sep 06 2004 Karsten Hopp 5.7-1 - update to latest stable version howl-0.9.6-4 ------------ * Tue Sep 21 2004 Alexander Larsson - 0.9.6-4 - buildrequire libtool (#132873) Patch from Steve Grubb httpd-2.0.51-6 -------------- * Tue Sep 21 2004 Joe Orton 2.0.51-6 - fix 2.0.51 regression in Satisfy merging (CAN-2004-0811) hwbrowser-0.15-5 ---------------- * Tue Sep 21 2004 Than Ngo 0.15-5 - fix typo * Tue May 25 2004 Brent Fox 0.15-4 - add BuildRequires for desktop-file-utils and automake (bug #124178) kdebase-3.3.0-5 --------------- * Tue Sep 21 2004 Than Ngo 6:3.3.0-5 - fix kdm segfault * Mon Sep 20 2004 Than Ngo 6:3.3.0-4 - get rid of requires openssh-client #132148 libwnck-2.8.0-2 --------------- * Tue Sep 21 2004 Mark McLoughlin - 2.8.0-2 - Add patch to fix runtime warning spew - bug #132921 * Tue Sep 21 2004 Mark McLoughlin 2.8.0-1 - Update to 2.8.0 nautilus-cd-burner-2.8.1-4 -------------------------- * Tue Sep 21 2004 Alexander Larsson - 2.8.1-4 - Lock devices using hal when burning openobex-apps-1.0.0-5 --------------------- * Tue Sep 21 2004 Harald Hoyer - 1.0.0-5 - added flush patch - in obex_push call sdptool openswan-2.1.4-7 ---------------- * Tue Sep 21 2004 Harald Hoyer - 2.1.4-7 - added more build reqs (bug 132877) policycoreutils-1.17.5-3 ------------------------ * Tue Sep 21 2004 Dan Walsh 1.17.5-3 - Only display to stdout if logfile not specified postgresql-odbc-7.3-8 --------------------- * Tue Sep 21 2004 Tom Lane 7.3-8 - rebuilt * Tue Jun 15 2004 Elliot Lee - rebuilt * Wed Mar 10 2004 Tom Lane - Correct License: annotation. pump-0.8.21-1 ------------- * Tue Sep 21 2004 Jeremy Katz - 0.8.21-1 - don't bring down the interface when getting a lease, should help with some cases where switch negotiation takes a while. anaconda already takes the interface down before getting a lease and then ensures that the link is present (#131475, #110036) * Tue Jan 06 2004 Jeremy Katz 0.8.20-1 - rebuild with vendor class id patch (#78843) * Thu Aug 14 2003 Bill Nottingham 0.8.19-1 - translations rcs-5.7-26 ---------- * Tue Sep 21 2004 Phil Knirsch 5.7-26 - rebuilt * Tue Jun 15 2004 Elliot Lee 5.7-25 - rebuilt * Fri Feb 13 2004 Elliot Lee 5.7-24 - rebuilt redhat-menus-1.6.1-1 -------------------- * Tue Sep 21 2004 Seth Nickell 1.6.1-1 - release 1.6.1, don't call AC_PROG_LIBTOOL * Tue Sep 21 2004 Seth Nickell 1.6-1 - release 1.6, add a bunch of translations to the build rpmdb-fedora-2.91-0.20040922 ---------------------------- rsync-2.6.3-0.pre2 ------------------ * Tue Sep 21 2004 Jay Fenlason 2.6.3-0.pre2 - new upstream version. selinux-policy-strict-1.17.19-2 ------------------------------- * Tue Sep 21 2004 Dan Walsh 1.17.19-2 - Many fixes for nscd * Tue Sep 21 2004 Dan Walsh 1.17.19-1 - Update to latest from NSA selinux-policy-targeted-1.17.19-2 --------------------------------- * Tue Sep 21 2004 Dan Walsh 1.17.19-2 - Many fixes for nscd * Tue Sep 21 2004 Dan Walsh 1.17.19-1 - Update to latest from NSA skkdic-20040922-1 ----------------- * Wed Sep 22 2004 Jens Petersen - 20040922-1 - update to latest dictionaries - update url - gzip ChangeLog since it is growing fast squirrelmail-1.4.3-3 -------------------- * Tue Sep 21 2004 Gary Benson 1.4.3-3 - rebuilt. stardict-1.31-21 ---------------- * Wed Sep 22 2004 Leon Ho - rebuilt system-config-kickstart-2.5.14-1 -------------------------------- * Tue Sep 21 2004 Paul Nasrat - 2.5.14-1 - ks.cfg parsing errors system-config-securitylevel-1.4.4-1 ----------------------------------- * Tue Sep 21 2004 Dan Walsh 1.4.4-1 - Fix for bad /etc/selinux/config system-config-services-0.8.8-9 ------------------------------ * Wed Jun 16 2004 Brent Fox - 0.8.8-9 - use watch cursor when starting and stopping services (bug #122425) system-switch-mail-0.5.25-2 --------------------------- * Tue Sep 21 2004 Than Ngo 0.5.25-2 - 0.5.25-2 release, cleanup taipeifonts-1.2-26 ------------------ * Wed Sep 22 2004 Leon Ho - rebuilt tcsh-6.13-9 ----------- * Tue Sep 21 2004 Miloslav Trmac - 6.13-9 - Fix invalid argument to xprintf () (#133129) tmake-1.13-1 ------------ * Tue Sep 21 2004 Than Ngo 1.13-1 - update to 1.13 tuxracer-0.61-28 ---------------- * Tue Sep 21 2004 Than Ngo 0.61-28 - rebuilt * Tue Jun 15 2004 Elliot Lee - rebuilt udev-032-1 ---------- * Tue Sep 21 2004 Harald Hoyer - 032-1 - version 032 urw-fonts-2.2-6 --------------- * Tue Sep 21 2004 Than Ngo 2.2-6 - rebuilt * Mon Sep 06 2004 Than Ngo 2.2-5 - remove fonts, which included in new upstream * Mon Sep 06 2004 Than Ngo 2.2-4 - update to 1.0.7pre38 vim-6.3.028-1 ------------- * Tue Sep 21 2004 Than Ngo 6.3.028-1 - add patchlevel 27,28 vino-2.8.0-1 ------------ * Tue Sep 21 2004 Mark McLoughlin 2.8.0-1 - Update to 2.8.0 - Remove upstreamed work-without-gnutls patch wvdial-1.54.0-3 --------------- * Tue Sep 21 2004 Harald Hoyer 1.54.0-3 - added openssl-devel build req (bug 132887) From russell at coker.com.au Wed Sep 22 12:39:36 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 22 Sep 2004 22:39:36 +1000 Subject: backups In-Reply-To: <87isa9q7zb.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1095636016.4431.59.camel@nexus.verbum.private> <20040920045558.GA618@jadzia.bu.edu> <87isa9q7zb.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <200409222239.36973.russell@coker.com.au> On Tue, 21 Sep 2004 01:24, Enrico Scholz wrote: > mattdm at mattdm.org (Matthew Miller) writes: > >> Well, it's not quite the same thing. You can't safely dump a live > >> filesystem, making it unusable for me. Also it's far less granular > >> than an archiver like tar or dar. > > > > Have you looked at making lvm snapshots and dumping those? > > LVM snapshots are not usably at the moment: for kernel 2.4 they work with > a kernel patch only, and for kernel 2.6 they are marked as experimental > which is confirmed by my experiences (kernel-panics on creation and manual > cleanup required). FC2 has kernel 2.6 but doesn't have snapshot support. FC3 has snapshot support, I've just been using it and it works for me. Can you file bug reports about any LVM oops you can get with a Fedora kernel? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From mgarski at post.pl Wed Sep 22 12:55:22 2004 From: mgarski at post.pl (Marcin Garski) Date: Wed, 22 Sep 2004 14:55:22 +0200 Subject: Polishing Fedora's specs Message-ID: <4151763A.5060400@post.pl> Hello I've recently created list of all packages in Fedora Devel tree, their URLs, Sources and Versions. Then i've started to check them if they up-to-date, have correct URL and Sources. I didn't check all packages yet. After some conversation on #fedora-devel, I've decided to write on this list. I can send to this list, all bugs I've already found, and inform you of my progress. What do you think about it? Should I continue my work, or leave it? -- Best Regards Marcin Garski From rdieter at math.unl.edu Wed Sep 22 13:23:32 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Sep 2004 08:23:32 -0500 Subject: Polishing Fedora's specs In-Reply-To: <4151763A.5060400@post.pl> References: <4151763A.5060400@post.pl> Message-ID: <41517CD4.3050506@math.unl.edu> Marcin Garski wrote: > Hello > > I've recently created list of all packages in Fedora Devel tree, their > URLs, Sources and Versions. > Then i've started to check them if they up-to-date, have correct URL and > Sources. > I didn't check all packages yet. > After some conversation on #fedora-devel, I've decided to write on this > list. > I can send to this list, all bugs I've already found, and inform you of > my progress. > What do you think about it? Should I continue my work, or leave it? That's excellent work, IMO, but the bugs should also be reported to bugzilla.redhat.com -- Rex From mgarski at post.pl Wed Sep 22 13:36:36 2004 From: mgarski at post.pl (Marcin Garski) Date: Wed, 22 Sep 2004 15:36:36 +0200 Subject: Polishing Fedora's specs In-Reply-To: <41517CD4.3050506@math.unl.edu> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> Message-ID: <41517FE4.7070404@post.pl> Rex Dieter wrote: >>I've recently created list of all packages in Fedora Devel tree, their >>URLs, Sources and Versions. >>Then i've started to check them if they up-to-date, have correct URL and >>Sources. >>I didn't check all packages yet. >>After some conversation on #fedora-devel, I've decided to write on this >>list. >>I can send to this list, all bugs I've already found, and inform you of >>my progress. >>What do you think about it? Should I continue my work, or leave it? > > > That's excellent work, IMO, but the bugs should also be reported to > bugzilla.redhat.com Should I report bugs one by one (it will be a lot of them), or in one bug all this things? IMHO second resolution is better. -- Best Regards Marcin Garski From hp at redhat.com Wed Sep 22 13:44:36 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 22 Sep 2004 09:44:36 -0400 Subject: Polishing Fedora's specs In-Reply-To: <41517FE4.7070404@post.pl> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> <41517FE4.7070404@post.pl> Message-ID: <1095860676.20861.56.camel@localhost.localdomain> On Wed, 2004-09-22 at 15:36 +0200, Marcin Garski wrote: > Should I report bugs one by one (it will be a lot of them), or in one > bug all this things? > > IMHO second resolution is better. If you do it all in one bug, it's not useful, because each one will need to be assigned to a different person and closed in a separate step. So the purpose of bugzilla (tracking the tasks so they don't get lost) will be defeated if you put multiple tasks in one bug. Havoc From katzj at redhat.com Wed Sep 22 13:44:34 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 22 Sep 2004 09:44:34 -0400 Subject: Polishing Fedora's specs In-Reply-To: <41517FE4.7070404@post.pl> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> <41517FE4.7070404@post.pl> Message-ID: <1095860674.4597.50.camel@bree.local.net> On Wed, 2004-09-22 at 15:36 +0200, Marcin Garski wrote: > Should I report bugs one by one (it will be a lot of them), or in one > bug all this things? > > IMHO second resolution is better. One by one. The second may be easier to begin with, but it's then impossible to track which ones have been fixed and let each individual package maintainer know the appropriate changes to make for their packages. Jeremy From laroche at redhat.com Wed Sep 22 13:55:09 2004 From: laroche at redhat.com (Florian La Roche) Date: Wed, 22 Sep 2004 15:55:09 +0200 Subject: Polishing Fedora's specs In-Reply-To: <41517FE4.7070404@post.pl> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> <41517FE4.7070404@post.pl> Message-ID: <20040922135509.GA27560@dudweiler.stuttgart.redhat.com> > Should I report bugs one by one (it will be a lot of them), or in one > bug all this things? > > IMHO second resolution is better. Probably with a mixture of both we might be able to get some of this stuff in. Can you put diffs somewhere on a web-page? greetings, Florian La Roche From alexl at redhat.com Wed Sep 22 14:45:33 2004 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 22 Sep 2004 16:45:33 +0200 Subject: bugzilla stock replies Message-ID: <1095864333.24266.203.camel@greebo.homeip.net> Taking some ideas from the Gnome bug squad I've created a page with stock responses to bugzilla reports: http://fedora.linux.duke.edu/wiki/StockBugzillaResponses There are just a few reports at the moment, but hopefully people will add new ones there and polish the existing ones as they start being used. Some messages also reference the page http://fedora.linux.duke.edu/wiki/ReportingBugs which isn't written yet. I'll probably spend some time writing an initial version of it later this week. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an unconventional Jewish Green Beret haunted by an iconic dead American confidante She's a mistrustful wisecracking mercenary married to the Mob. They fight crime! From toshio at tiki-lounge.com Wed Sep 22 15:55:06 2004 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 22 Sep 2004 11:55:06 -0400 Subject: Regarding Extras package announcements In-Reply-To: <1095852092.31078.53.camel@nos-rh.utelsystems.local> References: <414E7587.6050608@redhat.com> <20040920222709.63330698.fedora@wir-sind-cool.org> <20040922120046.205caa3b@localhost> <000601c4a08f$2b83ec50$14aaa8c0@utelsystems.local> <1095852092.31078.53.camel@nos-rh.utelsystems.local> Message-ID: <1095868503.11136.4.camel@Madison.badger.com> On Wed, 2004-09-22 at 07:21, Nils O. Sel?sdal wrote: > On Wed, 2004-09-22 at 12:30, Michael Schwendt wrote: > > If it could be automated, that would be very good, e.g. like "rawhide > > report". So far, not every packager has posted announcements. The > > list archives cover maybe 50% of the published packages and updates. > > Maybe even less. > imho this should be automated. Most people just use fedora-pkgannfmt > anyway, which could probably just be run as the bult packages are copied > to their respective directories !? The build system would also need (Well... should) also figure out which changelogs are new since the last package release like the RH Build System Reports. Shouldn't be too hard if the changelog header lines are correctly formatted (QA should be catching that.) -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at wir-sind-cool.org Wed Sep 22 16:31:06 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 22 Sep 2004 18:31:06 +0200 Subject: Regarding Extras package announcements In-Reply-To: <1095868503.11136.4.camel@Madison.badger.com> References: <414E7587.6050608@redhat.com> <20040920222709.63330698.fedora@wir-sind-cool.org> <20040922120046.205caa3b@localhost> <000601c4a08f$2b83ec50$14aaa8c0@utelsystems.local> <1095852092.31078.53.camel@nos-rh.utelsystems.local> <1095868503.11136.4.camel@Madison.badger.com> Message-ID: <20040922183106.66b155a5.fedora@wir-sind-cool.org> On Wed, 22 Sep 2004 11:55:06 -0400, Toshio wrote: > The build system would also need (Well... should) also figure out which > changelogs are new since the last package release like the RH Build > System Reports. Shouldn't be too hard if the changelog header lines are > correctly formatted (QA should be catching that.) Should they? FWIW, I think the package changelog is the packager's area. And unless it breaks the build, e.g. with unescaped % characters, I don't care what the package developer puts there. Okay, I give the hint to add version-release or remind to add a changelog entry if one is missing. But that's all. RPM changelog diff: 1. rpm -qp --changelog OLDPACKAGE > old 2. rpm -qp --changelog NEWPACKAGE > new 3. diff -u -U 9999 old new | grep ^+ | sed 's,^+,,;/^++.*/d' -- Fedora Core release 2.91 (FC3 Test 2) - Linux 2.6.8-1.541 loadavg: 1.58 1.77 1.80 From toshio at tiki-lounge.com Wed Sep 22 17:07:33 2004 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 22 Sep 2004 13:07:33 -0400 Subject: Regarding Extras package announcements In-Reply-To: <20040922183106.66b155a5.fedora@wir-sind-cool.org> References: <414E7587.6050608@redhat.com> <20040920222709.63330698.fedora@wir-sind-cool.org> <20040922120046.205caa3b@localhost> <000601c4a08f$2b83ec50$14aaa8c0@utelsystems.local> <1095852092.31078.53.camel@nos-rh.utelsystems.local> <1095868503.11136.4.camel@Madison.badger.com> <20040922183106.66b155a5.fedora@wir-sind-cool.org> Message-ID: <1095872848.11136.25.camel@Madison.badger.com> On Wed, 2004-09-22 at 12:31, Michael Schwendt wrote: > On Wed, 22 Sep 2004 11:55:06 -0400, Toshio wrote: > > > The build system would also need (Well... should) also figure out which > > changelogs are new since the last package release like the RH Build > > System Reports. Shouldn't be too hard if the changelog header lines are > > correctly formatted (QA should be catching that.) > > Should they? FWIW, I think the package changelog is the packager's > area. And unless it breaks the build, e.g. with unescaped % characters, > I don't care what the package developer puts there. Okay, I give the > hint to add version-release or remind to add a changelog entry if one > is missing. But that's all. > Sure. And it's the version-release info I was referring to. I might also mention something if the older changelogs were changed between revisions but that would depend on the particular change. > RPM changelog diff: > > 1. rpm -qp --changelog OLDPACKAGE > old > 2. rpm -qp --changelog NEWPACKAGE > new > 3. diff -u -U 9999 old new | grep ^+ | sed 's,^+,,;/^++.*/d' > I was thinking of trusting the header to have proper version info and cutting there. Your way looks better to me since it doesn't need that trust. Although it does trust that the previous changelogs won't have been modified for some reason. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mgarski at post.pl Wed Sep 22 17:40:08 2004 From: mgarski at post.pl (Marcin Garski) Date: Wed, 22 Sep 2004 19:40:08 +0200 Subject: Polishing Fedora's specs In-Reply-To: <20040922135509.GA27560@dudweiler.stuttgart.redhat.com> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> <41517FE4.7070404@post.pl> <20040922135509.GA27560@dudweiler.stuttgart.redhat.com> Message-ID: <4151B8F8.8080407@post.pl> Florian La Roche wrote: >>Should I report bugs one by one (it will be a lot of them), or in one >>bug all this things? >> >>IMHO second resolution is better. > > > Probably with a mixture of both we might be able to get some of this stuff > in. Can you put diffs somewhere on a web-page? I don't have diffs for specs. I do all my tasks in HTML table. I think that mixture of both are at one side better, because as I see I'll have to fil about 500 bugs :). Do you want that ;) ? Also I've already fil this kind of bugs, and had quite different replays. At one side very good, but at other eg. #131846 it wasn't so kind :/ Beside still in development tree xerces-j is in old version and probably was in FC2. -- Best Regards Marcin Garski From lnxxprt at arcor.de Wed Sep 22 18:11:33 2004 From: lnxxprt at arcor.de (D. Stolte) Date: Wed, 22 Sep 2004 20:11:33 +0200 Subject: mozilla 1.7.3? Message-ID: <4151C055.4010502@arcor.de> mozilla 1.7.3 has been released some weeks ago and fixes some security problems. when can we expect to see it packaged? /ds From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 22 18:44:39 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 22 Sep 2004 20:44:39 +0200 Subject: backups In-Reply-To: <200409222239.36973.russell@coker.com.au> (Russell Coker's message of "Wed, 22 Sep 2004 22:39:36 +1000") References: <1095636016.4431.59.camel@nexus.verbum.private> <20040920045558.GA618@jadzia.bu.edu> <87isa9q7zb.fsf@kosh.ultra.csn.tu-chemnitz.de> <200409222239.36973.russell@coker.com.au> Message-ID: <87brfyuors.fsf@kosh.ultra.csn.tu-chemnitz.de> russell at coker.com.au (Russell Coker) writes: >> LVM snapshots are not usably at the moment: for kernel 2.4 they work with >> a kernel patch only, and for kernel 2.6 they are marked as experimental >> which is confirmed by my experiences (kernel-panics on creation and manual >> cleanup required). > > FC2 has kernel 2.6 but doesn't have snapshot support. > > FC3 has snapshot support, I've just been using it and it works for me. Can > you file bug reports about any LVM oops you can get with a Fedora > kernel? Sorry; the FC3 kernel is missing some features so that I have to use the vanilla 2.6.8.1 kernel + some patches. FWIW, the stacktrace from the kernel oops is | Sep 22 04:44:18 delenn kernel: lvcreate: page allocation failure. order:0, mode:0xd0 | Sep 22 04:44:18 delenn kernel: [dump_stack+30/32] dump_stack+0x1e/0x20 | Sep 22 04:44:18 delenn kernel: [] dump_stack+0x1e/0x20 | Sep 22 04:44:18 delenn kernel: [__alloc_pages+739/784] __alloc_pages+0x2e3/0x310 | Sep 22 04:44:18 delenn kernel: [] __alloc_pages+0x2e3/0x310 | Sep 22 04:44:18 delenn kernel: [alloc_pl+52/96] alloc_pl+0x34/0x60 | Sep 22 04:44:18 delenn kernel: [] alloc_pl+0x34/0x60 | Sep 22 04:44:18 delenn kernel: [client_alloc_pages+37/112] client_alloc_pages+0x25/0x70 | Sep 22 04:44:18 delenn kernel: [] client_alloc_pages+0x25/0x70 | Sep 22 04:44:18 delenn kernel: [kcopyd_client_create+101/192] kcopyd_client_create+0x65/0xc0 | Sep 22 04:44:18 delenn kernel: [] kcopyd_client_create+0x65/0xc0 | Sep 22 04:44:18 delenn kernel: [pg0+140642617/1069535232] snapshot_ctr+0x329/0x3c0 [dm_snapshot] | Sep 22 04:44:18 delenn kernel: [] snapshot_ctr+0x329/0x3c0 [dm_snapshot] | Sep 22 04:44:18 delenn udev[2296]: PROGRAM execution of '/sbin/devmap_name 254 5' failed | Sep 22 04:44:18 delenn udev[2297]: PROGRAM execution of '/sbin/devmap_name 254 6' failed | Sep 22 04:44:18 delenn kernel: [dm_table_add_target+315/496] dm_table_add_target+0x13b/0x1f0 | Sep 22 04:44:19 delenn udev[2296]: creating device node '/dev/dm-5' | Sep 22 04:44:19 delenn udev[2297]: creating device node '/dev/dm-6' | Sep 22 04:44:19 delenn kernel: [] dm_table_add_target+0x13b/0x1f0 | Sep 22 04:44:19 delenn udev[2314]: PROGRAM execution of '/sbin/devmap_name 254 7' failed | Sep 22 04:44:19 delenn udev[2258]: PROGRAM execution of '/sbin/devmap_name 254 4' failed | Sep 22 04:44:19 delenn kernel: [populate_table+142/240] populate_table+0x8e/0xf0 | Sep 22 04:44:19 delenn udev[2314]: creating device node '/dev/dm-7' | Sep 22 04:44:19 delenn udev[2258]: creating device node '/dev/dm-4' | Sep 22 04:44:19 delenn kernel: [] populate_table+0x8e/0xf0 | Sep 22 04:44:19 delenn kernel: [table_load+102/336] table_load+0x66/0x150 | Sep 22 04:44:19 delenn kernel: [] table_load+0x66/0x150 | Sep 22 04:44:19 delenn kernel: [ctl_ioctl+222/320] ctl_ioctl+0xde/0x140 | Sep 22 04:44:19 delenn kernel: [] ctl_ioctl+0xde/0x140 | Sep 22 04:44:19 delenn kernel: [sys_ioctl+530/1088] sys_ioctl+0x212/0x440 | Sep 22 04:44:19 delenn kernel: [] sys_ioctl+0x212/0x440 | Sep 22 04:44:19 delenn kernel: [syscall_call+7/11] syscall_call+0x7/0xb | Sep 22 04:44:19 delenn kernel: [] syscall_call+0x7/0xb | Sep 22 04:44:19 delenn kernel: device-mapper: : Could not create kcopyd client | Sep 22 04:44:19 delenn kernel: | Sep 22 04:44:19 delenn kernel: device-mapper: error adding target to table It happens perhaps once per week (2 snapshots per day) and is not reproducible. Enrico From perbj at stanford.edu Wed Sep 22 18:50:28 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 22 Sep 2004 11:50:28 -0700 Subject: Polishing Fedora's specs In-Reply-To: <4151B8F8.8080407@post.pl> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> <41517FE4.7070404@post.pl> <20040922135509.GA27560@dudweiler.stuttgart.redhat.com> <4151B8F8.8080407@post.pl> Message-ID: <1095879027.2898.120.camel@localhost.localdomain> On Wed, 2004-09-22 at 10:40, Marcin Garski wrote: > I don't have diffs for specs. I do all my tasks in HTML table. > I think that mixture of both are at one side better, because as I see > I'll have to fil about 500 bugs :). Do you want that ;) ? Probably yes, since the fixes for the individual packages will mostly be done by the package maintainers. Then they can close the bug for that particular package. That is sort of how a bug tracking system is used! :) > Also I've already fil this kind of bugs, and had quite different replays. > At one side very good, but at other eg. #131846 it wasn't so kind :/ > Beside still in development tree xerces-j is in old version and probably > was in FC2. So part of the issue here seems to be that the bug report (should really be an RFE) is mostly about updating to a newer package version; the packager asked that you at least give a reason for why it is urgent to get that package updated and essentially said that an update is planned for FC3. He probably didn't consider it a critical enough update to push it through ahead of other work; likely it will show up sometime soon. The second issue, the missing URL in the spec file, is something you're kind of just mentioning in passing. If you files a separate bug only about that issue I'm sure you'd get a different response. Having many bug reports isn't really a problem as long as they are clear. A concise report that asks that the full URL be added to the spec file is easy to deal with and can be fixed and closed. If you start mixing that up with other issues (be it actual issues with a package or some type of enhancement request) it's much less clear when the bug should be closed; there's a good chance that the developer will close the bug report after the apparent main issues are dealt with, and their idea of "main issues" might not turn out to be the same as yours! Best regards, Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From kyrre at solution-forge.net Wed Sep 22 18:58:37 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 22 Sep 2004 20:58:37 +0200 Subject: bugzilla stock replies - upstream - RFE for Bugzilla? In-Reply-To: <1095864333.24266.203.camel@greebo.homeip.net> References: <1095864333.24266.203.camel@greebo.homeip.net> Message-ID: <1095879516.4034.7.camel@kyrre> While reading your page - was noticing something about upstream reports: The bug is not a packaging bug, you have no plans to work on this in the near future, and there is an upstream bug tracking system other than the redhat bugzilla. Thanks for the bug report. At the moment, the Fedora developers don't have time to work on this particular issue. The best way to make sure your problem will get looked on is to report it to the authors of the program. Most upstream authors use a bug tracking system like bugzilla, and more people who know the code will be looking at the bug report there. The upstream bug tracking system to use is: LINK HERE Please make sure the bug isn't already in the upstream bug tracker before filing it. How hard would it be to interconnect say the bugzilla at redhat and the bugzilla at gnome - so that if you filed a bug at redhat, it would automatically be posted upstream - and vice verca. It is really a pain in the *** to keep track of n bugzilla accounts! Apart from that - great work! ons, 22.09.2004 kl. 16.45 skrev Alexander Larsson: > Taking some ideas from the Gnome bug squad I've created a page with > stock responses to bugzilla reports: > http://fedora.linux.duke.edu/wiki/StockBugzillaResponses > > There are just a few reports at the moment, but hopefully people will > add new ones there and polish the existing ones as they start being > used. > > Some messages also reference the page > http://fedora.linux.duke.edu/wiki/ReportingBugs > which isn't written yet. I'll probably spend some time writing an > initial version of it later this week. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's an unconventional Jewish Green Beret haunted by an iconic dead American > confidante She's a mistrustful wisecracking mercenary married to the Mob. They > fight crime! > From caillon at redhat.com Wed Sep 22 20:33:50 2004 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 22 Sep 2004 16:33:50 -0400 Subject: mozilla 1.7.3? In-Reply-To: <4151C055.4010502@arcor.de> References: <4151C055.4010502@arcor.de> Message-ID: <4151E1AE.1080701@redhat.com> D. Stolte wrote: > mozilla 1.7.3 has been released some weeks ago and fixes some security > problems. when can we expect to see it packaged? For whatever reason, it doesn't build on PPC. I'm trying to work out why, but if I can't figure it out by tonight, I'll just exclude PPC from the build until it gets sorted out. I built FC2 updates last night and those should be pushed soon. From carlos.efr at mail.telepac.pt Wed Sep 22 21:41:46 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Wed, 22 Sep 2004 22:41:46 +0100 Subject: gaim [was Re: mozilla 1.7.3?] In-Reply-To: <4151C055.4010502@arcor.de> References: <4151C055.4010502@arcor.de> Message-ID: <4151F19A.2040604@mail.telepac.pt> D. Stolte wrote: > mozilla 1.7.3 has been released some weeks ago and fixes some security > problems. when can we expect to see it packaged? > > /ds > > And what about gaim 1.0.0? I guess I got spoiled by having an FC update for gaim almost immediately after it being released in the last few months... :) Carlos Rodrigues -- url: http://crodrigues.webhop.net From jorton at redhat.com Wed Sep 22 21:46:02 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 22 Sep 2004 22:46:02 +0100 Subject: autofs auto.master change In-Reply-To: <16720.8212.854302.169742@segfault.boston.redhat.com> References: <20040920101640.GA17976@redhat.com> <16720.8212.854302.169742@segfault.boston.redhat.com> Message-ID: <20040922214602.GA22159@redhat.com> On Tue, Sep 21, 2004 at 08:35:32AM -0400, Jeff Moyer wrote: > Since I've taken over the package, the main pain points I've seen are with > using the Linux automounter in mixed environments. Customers expect it to > operate in the same manner as the Sun automounter. This change was > intended to bring the Linux automounter semantically closer to the > bahaviour of the Sun automounter. Since you are having problems with it, I > will revert the change until such time as I implement the +auto_master > syntax in the master map. Is this an acceptable solution? I'd prefer to > not add another tunable to /etc/sysconfig/autofs, but I will if I must. I'm happy so long as the default behaviour doesn't change. Having a tunable to configure it to behave like Solaris seems reasonable to me, FWIW. joe From jerone at gmail.com Wed Sep 22 23:05:05 2004 From: jerone at gmail.com (Jerone Young) Date: Wed, 22 Sep 2004 18:05:05 -0500 Subject: Sound Check removed from Firstboot ? Message-ID: <9f50a7a00409221605593d9695@mail.gmail.com> In FC3 test 2 I noticed that sound check was no longer in firstboot. Why was the sound check removed from firstboot? From dax at gurulabs.com Wed Sep 22 23:14:45 2004 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 22 Sep 2004 17:14:45 -0600 Subject: backups In-Reply-To: <200409222239.36973.russell@coker.com.au> References: <1095636016.4431.59.camel@nexus.verbum.private> <20040920045558.GA618@jadzia.bu.edu> <87isa9q7zb.fsf@kosh.ultra.csn.tu-chemnitz.de> <200409222239.36973.russell@coker.com.au> Message-ID: <1095894885.4022.86.camel@mentorng.gurulabs.com> On Wed, 2004-09-22 at 06:39, Russell Coker wrote: > On Tue, 21 Sep 2004 01:24, Enrico Scholz > wrote: > > mattdm at mattdm.org (Matthew Miller) writes: > > >> Well, it's not quite the same thing. You can't safely dump a live > > >> filesystem, making it unusable for me. Also it's far less granular > > >> than an archiver like tar or dar. > > > > > > Have you looked at making lvm snapshots and dumping those? > > > > LVM snapshots are not usably at the moment: for kernel 2.4 they work with > > a kernel patch only, and for kernel 2.6 they are marked as experimental > > which is confirmed by my experiences (kernel-panics on creation and manual > > cleanup required). > > FC2 has kernel 2.6 but doesn't have snapshot support. Outdated info. The release kernel and the first few errata kernel didn't have support. Update to a recent/latest errata kernel and you'll be set. find /lib/modules -name dm-snapshot.ko Dax Kelson Guru Labs From dhollis at davehollis.com Wed Sep 22 23:34:09 2004 From: dhollis at davehollis.com (David Hollis) Date: Wed, 22 Sep 2004 19:34:09 -0400 Subject: gaim [was Re: mozilla 1.7.3?] In-Reply-To: <4151F19A.2040604@mail.telepac.pt> References: <4151C055.4010502@arcor.de> <4151F19A.2040604@mail.telepac.pt> Message-ID: <1095896049.6450.0.camel@dhollis-lnx.kpmg.com> On Wed, 2004-09-22 at 22:41 +0100, Carlos Rodrigues wrote: > D. Stolte wrote: > > mozilla 1.7.3 has been released some weeks ago and fixes some security > > problems. when can we expect to see it packaged? > > > > /ds > > > > > > And what about gaim 1.0.0? I guess I got spoiled by having an FC update > for gaim almost immediately after it being released in the last few > months... :) > > Carlos Rodrigues > Already in rawhide: gaim-1.0.0-3 -- David Hollis From walters at redhat.com Thu Sep 23 00:22:21 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 22 Sep 2004 20:22:21 -0400 Subject: backups In-Reply-To: <1095689661.14760.0.camel@opus.phy.duke.edu> References: <1095636016.4431.59.camel@nexus.verbum.private> <686E0A883A76045ABCE09B7D@[10.0.0.4]> <1095644884.4431.94.camel@nexus.verbum.private> <200409210009.25405.russell@coker.com.au> <1095689661.14760.0.camel@opus.phy.duke.edu> Message-ID: <1095898941.4477.31.camel@nexus.verbum.private> On Mon, 2004-09-20 at 10:14 -0400, seth vidal wrote: > Has anyone looked into bacula's ability to store extended attributes? > Does it have any? Wow, so I should have googled for bacula when you mentioned it here, but Michael K. Johnson just mentioned it on IRC and I actually looked: it's quite impressive! Someone should totally package this for Fedora. It claims to have ACL support, so hopefully that implies generic xattr support. It will still require a small SELinux-specific patch though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Thu Sep 23 00:30:55 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 22 Sep 2004 20:30:55 -0400 Subject: jabberd spec Message-ID: <1095899455.4477.37.camel@nexus.verbum.private> Hi, A while ago I spent some free time trying to bang this jabberd .spec file I found into shape, but haven't had time to pick it up again. I think it'd be great though if we got jabberd into Fedora or extras at least. Hopefully someone will be able to take this and fix it up more; it's FHS-incompatible and has some ugly bits like the test for NETWORKING, etc. -------------- next part -------------- ## The following options can be overriden on build from the command line: ## rpmbuild -ba --define 'use_pgsql 1' --define 'storage pgsql' --define "authreg 'anon pipe pgsql'" ## # Include module support %{!?use_db: %define use_db 1} %{!?use_pgsql: %define use_pgsql 0} %{!?use_mysql: %define use_mysql 0} %{!?use_ldap: %define use_ldap 0} # storage modules # SM storage drivers to build, one or more of: # db (requires Berkeley DB) # fs (NOT RECOMMENDED) # mysql (requires MySQL) # pgsql (requires PostgreSQL) # Defaults to "db". #define storage modules %{!?storage:%define storage db} # authreg modules # c2s authentication/registration modules to build, one or more of: # anon # db (requires Berkeley DB) # pipe # ldap (requires OpenLDAP) # mysql (requires MySQL) # pam (requires PAM) # pgsql (requires PostgreSQL) # Defaults to "anon pipe db". #define authreg modules %{!?authreg: %define authreg 'anon pipe db'} Summary: Jabber Server Name: jabberd Version: 2.0s3 Release: 1 License: GPL Group: System Environment/Daemons URL: http://jabberd.jabberstudio.org/ Source0: http://www.jabberstudio.org/projects/jabberd2/releases/download.php?file=/%{name}-%{version}.tar.gz BuildRequires: pam-devel Requires: openssl >= 0.9.6b BuildRequires: krb5-devel BuildRequires: openssl-devel >= 0.9.6b %if %{use_ldap} Requires: openldap BuildRequires: openldap-devel %endif %if %{use_pgsql} Requires: postgresql BuildRequires: postgresql-devel %endif %if %{use_mysql} Requires: mysql BuildRequires: mysql-devel %endif %if %{use_db} Requires: db4 >= 4.1.24 BuildRequires: db4-devel >= 4.1.24 %endif BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot Prefix: %{_prefix} %description jabberd 2 is the next generation of the jabberd server. It has been rewritten from the ground up to be scalable, architecturally sound, and to support the latest protocol extensions coming out of the JSF. %prep %setup -q -n %{name}-%{version} %build CFLAGS="$RPM_OPT_FLAGS `pkg-config --cflags openssl`" LDFLAGS="$LDFLAGS `pkg-config --libs openssl`" export CFLAGS export LDFLAGS %configure \ --enable-db \ --enable-authreg=%{authreg} \ --enable-storage=%{storage} \ --with-openssl=%{_prefix} \ --enable-pam \ --enable-debug \ --disable-mysql \ --disable-idn \ --disable-ldap make %install rm -rf $RPM_BUILD_ROOT #makeinstall make DESTDIR=%{buildroot} install mkdir -p $RPM_BUILD_ROOT/%{_var}/%{name}/{db,pid,log} mkdir -p $RPM_BUILD_ROOT/%{_sysconfdir}/init.d/ cat > $RPM_BUILD_ROOT/%{_sysconfdir}/init.d/%{name} << EOF # # jabberd Jabber Daemon. # chkconfig: - 80 20 # description: Jabber is an XML-based, open-source system and protocol for real-time messaging and presence notification. # processname: jabberd # config: /etc/jabberd/jabber.cfg # Source function library. . /etc/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ X\${NETWORKING} = Xno ] && exit 0 # Check if the Jabber conf file is present [ -f /etc/jabberd/jabberd.cfg ] || exit 0 [ -d /etc/jabberd ] || exit 0 RETVAL=0 LOGDIR=/var/jabberd/log JSERV="router resolver sm s2s c2s" start() { echo -n \$"Starting jabber server: " nohup su jabber -c "/usr/bin/jabberd" >>\$LOGDIR/jabberd.log 2>&1 & RETVAL=\$? if [ \$RETVAL -eq 0 ]; then echo_success echo touch /var/lock/subsys/jabberd else echo_failure echo exit 1 fi chown jabber:jabber \$LOGDIR/jabberd.log } stop() { echo -n \$"Stopping jabberd: " for serv in \$JSERV ; do killproc \$serv > /dev/null [ \$? != 0 ] && RETVAL=\$? done if [ \$RETVAL = 0 ]; then echo_success else echo_failure fi echo [ \$RETVAL = 0 ] && rm -f /var/lock/subsys/jabberd } dostatus() { for serv in \$JSERV; do status \$serv done RETVAL=\$? } restart() { stop start RETVAL=\$? } condrestart() { [ -e /var/lock/subsys/jabberd ] && restart || : } # See how we were called. case "\$1" in start) start ;; stop) stop ;; status) dostatus ;; restart|reload) restart ;; condrestart) condrestart ;; *) echo "Usage: jabberd {start|stop|status|restart|condrestart}" exit 1 esac exit \$RETVAL EOF %clean rm -rf $RPM_BUILD_ROOT %pre # Add jabber user account /usr/sbin/useradd -c 'Jabber daemon' -s /sbin/nologin -r -d %{_datadir}/%{name} jabber 2> /dev/null || : # Add jabber group /usr/sbin/groupadd jabber exit 0 %post chown -R jabber:jabber %{_var}/jabberd /sbin/chkconfig --add jabberd exit 0 %preun if [ $1 = 0 ]; then /sbin/service jabberd stop > /dev/null 2>&1 / sbin/chkconfig --del jabberd fi %files %defattr(-,root,root,-) %dir %{_sysconfdir}/%{name} %config(noreplace) %{_sysconfdir}/%{name}/* %config %{_sysconfdir}/init.d/%{name} %{_bindir} %{_mandir}/man8/* %doc %attr (-,jabber,jabber) %{_var}/%{name} %changelog * Wed Jul 28 2004 Colin Walters 2.0s3-1 - Update to s3 - Always enable PAM - Always enable SSL - Mark config files as noreplace (!!) - Fix chown to use : - Add name for jabberd user and set shell to /sbin/nologin - Disable idn for now * Sat Jun 19 2004 Colin Walters 2.0s1-1 - Update to 2.0s1-1 * Wed Aug 20 2003 - Initial build. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Thu Sep 23 00:29:09 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 22 Sep 2004 20:29:09 -0400 Subject: jabberd spec In-Reply-To: <1095899455.4477.37.camel@nexus.verbum.private> References: <1095899455.4477.37.camel@nexus.verbum.private> Message-ID: <1095899349.26667.0.camel@binkley> On Wed, 2004-09-22 at 20:30 -0400, Colin Walters wrote: > Hi, > > A while ago I spent some free time trying to bang this jabberd .spec > file I found into shape, but haven't had time to pick it up again. I > think it'd be great though if we got jabberd into Fedora or extras at > least. Hopefully someone will be able to take this and fix it up more; > it's FHS-incompatible and has some ugly bits like the test for > NETWORKING, etc. > jabberd 2.0 has stopped development - the primary developer has gone away from it. Moreover it has pretty serious stability problems. I don't think it would be worthwhile to put it in extras. -sv From rjune at bravegnuworld.com Thu Sep 23 00:34:00 2004 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 22 Sep 2004 19:34:00 -0500 Subject: jabberd spec In-Reply-To: <1095899349.26667.0.camel@binkley> References: <1095899455.4477.37.camel@nexus.verbum.private> <1095899349.26667.0.camel@binkley> Message-ID: <200409221934.03310.rjune@bravegnuworld.com> On Wednesday 22 September 2004 19:29, seth vidal wrote: > On Wed, 2004-09-22 at 20:30 -0400, Colin Walters wrote: > > Hi, > > > > A while ago I spent some free time trying to bang this jabberd .spec > > file I found into shape, but haven't had time to pick it up again. I > > think it'd be great though if we got jabberd into Fedora or extras at > > least. Hopefully someone will be able to take this and fix it up more; > > it's FHS-incompatible and has some ugly bits like the test for > > NETWORKING, etc. > > jabberd 2.0 has stopped development - the primary developer has gone > away from it. Moreover it has pretty serious stability problems. > > I don't think it would be worthwhile to put it in extras. > > -sv How about jabberd 1.4.3? it's stable, works, and will authenticate from PAM? http://ftp.bravegnuworld.com/pub/mirror/bgw/SRPMS/jabberd-1.4.3-0.rh9.6.src.rpm -- Public Key available Here: http://www.bravegnuworld.com/~rjune/rjune.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Thu Sep 23 00:37:53 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 22 Sep 2004 20:37:53 -0400 Subject: jabberd spec In-Reply-To: <200409221934.03310.rjune@bravegnuworld.com> References: <1095899455.4477.37.camel@nexus.verbum.private> <1095899349.26667.0.camel@binkley> <200409221934.03310.rjune@bravegnuworld.com> Message-ID: <1095899873.26667.3.camel@binkley> > > -sv > How about jabberd 1.4.3? it's stable, works, and will authenticate from PAM? > > http://ftp.bravegnuworld.com/pub/mirror/bgw/SRPMS/jabberd-1.4.3-0.rh9.6.src.rpm it's not xmpp 1.1 compliant - which isn't all that bad. but the pam auth stack is written entirely in perl which is downright scary. -sv From walters at redhat.com Thu Sep 23 00:49:57 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 22 Sep 2004 20:49:57 -0400 Subject: jabberd spec In-Reply-To: <1095899349.26667.0.camel@binkley> References: <1095899455.4477.37.camel@nexus.verbum.private> <1095899349.26667.0.camel@binkley> Message-ID: <1095900597.4477.41.camel@nexus.verbum.private> On Wed, 2004-09-22 at 20:29 -0400, seth vidal wrote: > On Wed, 2004-09-22 at 20:30 -0400, Colin Walters wrote: > > Hi, > > > > A while ago I spent some free time trying to bang this jabberd .spec > > file I found into shape, but haven't had time to pick it up again. I > > think it'd be great though if we got jabberd into Fedora or extras at > > least. Hopefully someone will be able to take this and fix it up more; > > it's FHS-incompatible and has some ugly bits like the test for > > NETWORKING, etc. > > > > jabberd 2.0 has stopped development - the primary developer has gone > away from it. Hm, I didn't know that. That sucks. Looks like his page says he might pick it up again though. > Moreover it has pretty serious stability problems. It seems to work OK for me, although it was a pain to set up. > I don't think it would be worthwhile to put it in extras. Well, it'd be nice to have either this or 1.4. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rjune at bravegnuworld.com Thu Sep 23 00:56:51 2004 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 22 Sep 2004 19:56:51 -0500 Subject: jabberd spec In-Reply-To: <1095899873.26667.3.camel@binkley> References: <1095899455.4477.37.camel@nexus.verbum.private> <200409221934.03310.rjune@bravegnuworld.com> <1095899873.26667.3.camel@binkley> Message-ID: <200409221956.53209.rjune@bravegnuworld.com> On Wednesday 22 September 2004 19:37, seth vidal wrote: > > > -sv > > > > How about jabberd 1.4.3? it's stable, works, and will authenticate from > > PAM? > > > > http://ftp.bravegnuworld.com/pub/mirror/bgw/SRPMS/jabberd-1.4.3-0.rh9.6.s > >rc.rpm > > it's not xmpp 1.1 compliant - which isn't all that bad. but the pam auth > stack is written entirely in perl which is downright scary. I don't know about xmpp 1.1, so I won't argue with you there. but since I authored the PAM_auth module used by that RPM, I will argue with you about it being written in perl. I wrote it in C myself. I think I have the only PAM auth module for jabber that seems to work as expected. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/rjune.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Thu Sep 23 00:56:38 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 22 Sep 2004 20:56:38 -0400 Subject: jabberd spec In-Reply-To: <200409221956.53209.rjune@bravegnuworld.com> References: <1095899455.4477.37.camel@nexus.verbum.private> <200409221934.03310.rjune@bravegnuworld.com> <1095899873.26667.3.camel@binkley> <200409221956.53209.rjune@bravegnuworld.com> Message-ID: <1095900998.26667.5.camel@binkley> On Wed, 2004-09-22 at 19:56 -0500, Richard June wrote: > On Wednesday 22 September 2004 19:37, seth vidal wrote: > > > > -sv > > > > > > How about jabberd 1.4.3? it's stable, works, and will authenticate from > > > PAM? > > > > > > http://ftp.bravegnuworld.com/pub/mirror/bgw/SRPMS/jabberd-1.4.3-0.rh9.6.s > > >rc.rpm > > > > it's not xmpp 1.1 compliant - which isn't all that bad. but the pam auth > > stack is written entirely in perl which is downright scary. > I don't know about xmpp 1.1, so I won't argue with you there. > but since I authored the PAM_auth module used by that RPM, I will argue with > you about it being written in perl. > I wrote it in C myself. > I think I have the only PAM auth module for jabber that seems to work as > expected. Can you put out a link to that module? I've not seen that one. -sv From notting at redhat.com Thu Sep 23 01:45:56 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 22 Sep 2004 21:45:56 -0400 Subject: Sound Check removed from Firstboot ? In-Reply-To: <9f50a7a00409221605593d9695@mail.gmail.com> References: <9f50a7a00409221605593d9695@mail.gmail.com> Message-ID: <20040923014555.GB9769@nostromo.devel.redhat.com> Jerone Young (jerone at gmail.com) said: > In FC3 test 2 I noticed that sound check was no longer in firstboot. > Why was the sound check removed from firstboot? It's still there, it probably crashed (see bugzilla.) firstboot modules that crash are now silently skipped. Bill From rjune at bravegnuworld.com Thu Sep 23 02:38:13 2004 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 22 Sep 2004 21:38:13 -0500 Subject: jabberd spec In-Reply-To: <1095900998.26667.5.camel@binkley> References: <1095899455.4477.37.camel@nexus.verbum.private> <200409221956.53209.rjune@bravegnuworld.com> <1095900998.26667.5.camel@binkley> Message-ID: <200409222138.19815.rjune@bravegnuworld.com> > Can you put out a link to that module? I've not seen that one. > > -sv http://www.bravegnuworld.com/~rjune/jabber/ Here's the pkg file with the tarball in it and the patch I use to build it in. I've tested / use it on redhat 7.3-9, fedora core 1 and fedora core 2. I suspect it would work on YellowDog, but doesn't build on Gentoo(don't much care about that one), and causes jabberd to crash on SuSE(working on that one) -- Public Key available Here: http://www.bravegnuworld.com/~rjune/rjune.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From adrian at lisas.de Thu Sep 23 05:08:38 2004 From: adrian at lisas.de (Adrian Reber) Date: Thu, 23 Sep 2004 07:08:38 +0200 Subject: jabberd spec In-Reply-To: <1095899455.4477.37.camel@nexus.verbum.private> References: <1095899455.4477.37.camel@nexus.verbum.private> Message-ID: <20040923050838.GA30317@lisas.de> On Wed, Sep 22, 2004 at 08:30:55PM -0400, Colin Walters wrote: > A while ago I spent some free time trying to bang this jabberd .spec jabberd 2 is also in fedora.us: https://bugzilla.fedora.us/show_bug.cgi?id=1875 Adrian From feliciano.matias at free.fr Thu Sep 23 07:00:08 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 23 Sep 2004 09:00:08 +0200 Subject: rawhide report: 20040922 changes In-Reply-To: <200409221134.i8MBYUi05756@porkchop.devel.redhat.com> References: <200409221134.i8MBYUi05756@porkchop.devel.redhat.com> Message-ID: <1095922808.1074.14.camel@one.myworld> Le mer 22/09/2004 ? 13:34, Build System a ?crit : > udev-032-1 > ---------- > * Tue Sep 21 2004 Harald Hoyer - 032-1 > > - version 032 > From the current /sbin/mkinitrd (mkinitrd-4.1.11-1) : inst /sbin/udevstart.static $MNTIMAGE/sbin/udevstart But there is no more udevstart.static. # rpm2cpio udev-032-1.i386.rpm | cpio -tv "./sbin/udev*" -rwxr-xr-x 1 root root 63560 Sep 21 15:11 ./sbin/udev -rwxr-xr-x 1 root root 554496 Sep 21 15:11 ./sbin/udev.static -rwxr-xr-x 1 root root 36732 Sep 21 15:11 ./sbin/udev_volume_id -rwxr-xr-x 1 root root 8808 Sep 21 15:11 ./sbin/udevd -rwxr-xr-x 1 root root 6920 Sep 21 15:11 ./sbin/udevsend lrwxr-xr-x 1 root root 10 Sep 21 15:11 ./sbin/udevstart -> /sbin/udev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From NOS at Utel.no Thu Sep 23 07:08:59 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Thu, 23 Sep 2004 09:08:59 +0200 Subject: jabberd spec In-Reply-To: <000401c4a104$9c2e07e0$14aaa8c0@utelsystems.local> References: <000401c4a104$9c2e07e0$14aaa8c0@utelsystems.local> Message-ID: <1095923339.31078.56.camel@nos-rh.utelsystems.local> On Thu, 2004-09-23 at 02:31, Colin Walters wrote: > Hi, > > A while ago I spent some free time trying to bang this jabberd .spec > file I found into shape, but haven't had time to pick it up again. I > think it'd be great though if we got jabberd into Fedora or extras at > least. Hopefully someone will be able to take this and fix it up more; > it's FHS-incompatible and has some ugly bits like the test for > NETWORKING, etc. > There's thisone as well. https://bugzilla.fedora.us/show_bug.cgi?id=1875 Which just about install'n'run. From feliciano.matias at free.fr Thu Sep 23 08:03:03 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 23 Sep 2004 10:03:03 +0200 Subject: rawhide report: 20040922 changes In-Reply-To: <1095922808.1074.14.camel@one.myworld> References: <200409221134.i8MBYUi05756@porkchop.devel.redhat.com> <1095922808.1074.14.camel@one.myworld> Message-ID: <1095926579.1074.17.camel@one.myworld> Le jeu 23/09/2004 ? 09:00, Matias Feliciano a ?crit : > Le mer 22/09/2004 ? 13:34, Build System a ?crit : > > udev-032-1 > > ---------- > > * Tue Sep 21 2004 Harald Hoyer - 032-1 > > > > - version 032 > > > > From the current /sbin/mkinitrd (mkinitrd-4.1.11-1) : > inst /sbin/udevstart.static $MNTIMAGE/sbin/udevstart > > But there is no more udevstart.static. Fixed in mkinitrd 4.1.12 : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133194 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From harald at redhat.com Thu Sep 23 08:53:20 2004 From: harald at redhat.com (Harald Hoyer) Date: Thu, 23 Sep 2004 10:53:20 +0200 Subject: Polishing Fedora's specs In-Reply-To: <4151B8F8.8080407@post.pl> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> <41517FE4.7070404@post.pl> <20040922135509.GA27560@dudweiler.stuttgart.redhat.com> <4151B8F8.8080407@post.pl> Message-ID: <41528F00.2020105@redhat.com> Marcin Garski wrote: > Florian La Roche wrote: > >>> Should I report bugs one by one (it will be a lot of them), or in one >>> bug all this things? >>> >>> IMHO second resolution is better. >> >> >> >> Probably with a mixture of both we might be able to get some of this >> stuff >> in. Can you put diffs somewhere on a web-page? > > > I don't have diffs for specs. I do all my tasks in HTML table. > I think that mixture of both are at one side better, because as I see > I'll have to fil about 500 bugs :). Do you want that ;) ? > > Also I've already fil this kind of bugs, and had quite different replays. > At one side very good, but at other eg. #131846 it wasn't so kind :/ > Beside still in development tree xerces-j is in old version and probably > was in FC2. Do you have your data in a parsable format? If yes, send it to me, I'll try to automate the bugzilla creation process with perl or python... From wtogami at redhat.com Thu Sep 23 09:02:42 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 22 Sep 2004 23:02:42 -1000 Subject: FYI: Fedora i2o Status Message-ID: <41529132.5040905@redhat.com> http://i2o.shadowconnect.com/fedora.php Status of I2O support ===================== Updated: Wednesday, September 22nd, 2004 Fedora Core 3 Test2 theoretically has fully working I2O support from the installer, tested with most DPT/Adaptec I2O cards. There is one patch for cards with 128MB onboard cache that will be in FC3 Test3, but otherwise we know if no further issues. If you do run into any problems with the kernel of FC3 Test2 with I2O, please discuss I2O kernel problems on linux-scsi mailing list, or Fedora specific problems on fedora-test-list. http://i2o.shadowconnect.com/ Please also test the raidutils RPM available from Markus' i2o homepage. It allows you to monitor and interact with your i2o arrays on a running system. Warren Togami wtogami at redhat.com From laroche at redhat.com Thu Sep 23 09:30:41 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 23 Sep 2004 11:30:41 +0200 Subject: Polishing Fedora's specs In-Reply-To: <4151B8F8.8080407@post.pl> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> <41517FE4.7070404@post.pl> <20040922135509.GA27560@dudweiler.stuttgart.redhat.com> <4151B8F8.8080407@post.pl> Message-ID: <20040923093041.GA13025@dudweiler.stuttgart.redhat.com> On Wed, Sep 22, 2004 at 07:40:08PM +0200, Marcin Garski wrote: > Florian La Roche wrote: > >>Should I report bugs one by one (it will be a lot of them), or in one > >>bug all this things? > >> > >>IMHO second resolution is better. > > > > > >Probably with a mixture of both we might be able to get some of this stuff > >in. Can you put diffs somewhere on a web-page? > > I don't have diffs for specs. I do all my tasks in HTML table. > I think that mixture of both are at one side better, because as I see > I'll have to fil about 500 bugs :). Do you want that ;) ? Well, without seeing the changes I cannot comment really on how to merge them. Maybe some larger parts could be merged by one person at Red Hat, maybe we should just put out all those bugzilla lines. > Also I've already fil this kind of bugs, and had quite different replays. > At one side very good, but at other eg. #131846 it wasn't so kind :/ > Beside still in development tree xerces-j is in old version and probably > was in FC2. Depends on individual developers. Some have their own devel plan and just updating the spec file to a newer version is often not an issue, so having a bugzilla about this doesn't really help. For a few other developers scann your list might give good suggestions on what packages we still want to update. Get your diffs in, more exchange on getting packages updated is certainly something we want to improve. Danger will be that the closer we go to FC3, we will stop updating to newer upstream releases and concentrate more on bug-fixes. greetings, Florian La Roche From russell at coker.com.au Thu Sep 23 10:21:08 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 23 Sep 2004 20:21:08 +1000 Subject: dm-snapshot.ko Message-ID: <200409232021.08781.russell@coker.com.au> Attempts to create a snapshot LV when dm-snapshot is not loaded fail with an obscure error. I think that this is a bug, would it be a kernel bug or an LVM utility bug? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From mgarski at post.pl Thu Sep 23 10:22:26 2004 From: mgarski at post.pl (Marcin Garski) Date: Thu, 23 Sep 2004 12:22:26 +0200 Subject: Polishing Fedora's specs In-Reply-To: <1095879027.2898.120.camel@localhost.localdomain> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> <41517FE4.7070404@post.pl> <20040922135509.GA27560@dudweiler.stuttgart.redhat.com> <4151B8F8.8080407@post.pl> <1095879027.2898.120.camel@localhost.localdomain> Message-ID: <4152A3E2.9040507@post.pl> Per Bjornsson wrote: >>Also I've already fil this kind of bugs, and had quite different replays. >>At one side very good, but at other eg. #131846 it wasn't so kind :/ >>Beside still in development tree xerces-j is in old version and probably >>was in FC2. > > > So part of the issue here seems to be that the bug report (should really > be an RFE) is mostly about updating to a newer package version; the > packager asked that you at least give a reason for why it is urgent to > get that package updated and essentially said that an update is planned > for FC3. He probably didn't consider it a critical enough update to push > it through ahead of other work; likely it will show up sometime soon. > > The second issue, the missing URL in the spec file, is something you're > kind of just mentioning in passing. If you files a separate bug only > about that issue I'm sure you'd get a different response. > > Having many bug reports isn't really a problem as long as they are > clear. A concise report that asks that the full URL be added to the spec > file is easy to deal with and can be fixed and closed. If you start > mixing that up with other issues (be it actual issues with a package or > some type of enhancement request) it's much less clear when the bug > should be closed; there's a good chance that the developer will close > the bug report after the apparent main issues are dealt with, and their > idea of "main issues" might not turn out to be the same as yours! What should I do with bugs like that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130310 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131857 When I only fil bug about bad URL, then when developer close that bug, he'll made another one, because old version of that package isn't available on that new website, so I'll have to fil another bug where I should point that he have to update package to newer version because current URL and Source are invalid for this version? -- Best Regards Marcin Garski From alexl at redhat.com Thu Sep 23 10:47:08 2004 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 23 Sep 2004 12:47:08 +0200 Subject: bugzilla stock replies - upstream - RFE for Bugzilla? In-Reply-To: <1095879516.4034.7.camel@kyrre> References: <1095864333.24266.203.camel@greebo.homeip.net> <1095879516.4034.7.camel@kyrre> Message-ID: <1095936428.24266.229.camel@greebo.homeip.net> On Wed, 2004-09-22 at 20:58 +0200, Kyrre Ness Sjobak wrote: > How hard would it be to interconnect say the bugzilla at redhat and the > bugzilla at gnome - so that if you filed a bug at redhat, it would > automatically be posted upstream - and vice verca. It is really a pain > in the *** to keep track of n bugzilla accounts! I've heard a lot of requests for being able to move bugs between bugzillas and marking duplicates between them, but I'm not sure if anyone has ever started working on it. > Apart from that - great work! I added some more responses today. Check them out! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a suave amnesiac assassin on the hunt for the last specimen of a great and near-mythical creature. She's a time-travelling Buddhist barmaid with an evil twin sister. They fight crime! From fedora.gunnar at hilling.de Thu Sep 23 10:54:51 2004 From: fedora.gunnar at hilling.de (Gunnar Hilling) Date: Thu, 23 Sep 2004 12:54:51 +0200 Subject: httpd/rawhide Message-ID: <1095936891.4119.6.camel@nelson.hilling.de> Hello, after upgrading yesterday, httpd won't start: ..."libdb-4.2.so: failed to map segment from shared object: Permission denied" I have the latest rpm, security policy "targetted" enabled. "messages" says: Sep 23 12:50:45 nelson kernel: audit(1095936645.518:0): avc: denied { execute } for pid=4862 path=/lib/tls/i686/libdb-4.2.so dev=dm-5 ino=234979213 scontext=root:system_r:httpd_t tcontext=system_u:object_r:lib_t tclass=file Anyone could fix this in the policy (cause I can't...). Thanks, -Gunnar BTW: I can't boot the new kernel 2.6.8-1.584, it hangs after "configuring kernel parameters" ... From mandreiana at rdslink.ro Thu Sep 23 11:40:36 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Thu, 23 Sep 2004 14:40:36 +0300 Subject: jabberd spec In-Reply-To: <1095899349.26667.0.camel@binkley> References: <1095899455.4477.37.camel@nexus.verbum.private> <1095899349.26667.0.camel@binkley> Message-ID: <1095939636.2898.7.camel@marte.biciclete.ro> On Wed, 2004-09-22 at 20:29 -0400, seth vidal wrote: > jabberd 2.0 has stopped development - the primary developer has gone > away from it. Moreover it has pretty serious stability problems. Seth, what jabber server do you recommend? -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From buildsys at redhat.com Thu Sep 23 11:50:06 2004 From: buildsys at redhat.com (Build System) Date: Thu, 23 Sep 2004 07:50:06 -0400 Subject: rawhide report: 20040923 changes Message-ID: <200409231150.i8NBo6w08534@porkchop.devel.redhat.com> Updated Packages: alchemist-1.0.34-1 ------------------ * Wed Sep 22 2004 Than Ngo 1.0.34-1 - add Prereq: /sbin/ldconfig atk-1.8.0-1 ----------- * Wed Sep 22 2004 Matthias Clasen - 1.8.0-1 - update to 2.8.0 basesystem-8.0-4 ---------------- * Wed Sep 22 2004 Bill Nottingham - rebuilt bitmap-fonts-0.3-4 ------------------ * Wed Sep 22 2004 Owen Taylor - 0.3-4 - Update BuildRequires to xorg-x11-font-utils (#118428, Mike Harris) bluez-bluefw-1.0-6 ------------------ * Wed Sep 22 2004 David Woodhouse 1.0-6 - Move firmware to /lib/firmware * Tue Jun 15 2004 Elliot Lee 1.0-5 - rebuilt * Tue May 11 2004 David Woodhouse 1.0-4 - Change hotplug script to match new bluefw location. - Move firmware files to /usr/lib/hotplug/firmware bluez-hcidump-1.11-1 -------------------- * Wed Sep 22 2004 David Woodhouse 1.11-1 - update to bluez-hcidump 1.11 boost-1.31.0-9 -------------- * Wed Sep 22 2004 Than Ngo 1.31.0-9 - cleanup specfile - fix multiarch problem cdrtools-2.01.1-3 ----------------- * Wed Sep 22 2004 Harald Hoyer - 8:2.01.1-3 - better globbing - readded O_EXCL opening for the direct device opening case, e.g. dev=/dev/cdrom - removed some debugging messages (bug 82089) comps-extras-9.92-2 ------------------- * Wed Sep 22 2004 Jeremy Katz - 9.92-2 - rebuild control-center-2.8.0-1 ---------------------- * Wed Sep 22 2004 GNOME - 1:2.8.0-1 - new version; disable gstreamer and enable alsa dbus-0.22-9 ----------- * Wed Sep 22 2004 John (J5) Palmieri - Fixed patch to use dbus-1 instead of dbus-1.0 - (configure.in): Exported just the datadir instead of the full path to the dbus datadir for consistency * Wed Sep 22 2004 John (J5) Palmieri - Adding patch to move /usr/lib/dbus-1.0/services to /usr/share/dbus-1.0/services devhelp-0.9.1-4 --------------- * Wed Sep 22 2004 Christopher Aillon 0.9.1-4 - Rebuilt to pick up new mozilla changes - Drop ppc from the build since mozilla doesn't build there anymore. docbook-style-dsssl-1.78-4 -------------------------- * Wed Sep 22 2004 Than Ngo 1.78-4 - rebuilt elilo-3.4-10 ------------ * Wed Sep 22 2004 Jeremy Katz - 3.4-10 - add patch from Jesse Barnes to make warnings less verbose (#130784) eog-2.8.0-1 ----------- * Wed Sep 22 2004 Christopher Aillon 2.8.0-1 - Update to 2.8.0 ethereal-0.10.6-2 ----------------- * Wed Sep 22 2004 Florian La Roche - add post/postun /sbin/ldconfig calls file-roller-2.8.0-1 ------------------- * Wed Sep 22 2004 Christopher Aillon 2.8.0-1 - Update to 2.8.0 fontconfig-2.2.3-4 ------------------ * Wed Sep 22 2004 Owen Taylor - 2.2.3-4 - Update fonts-hebrew names to include CLM suffix * Thu Sep 02 2004 Owen Taylor - 2.2.3-3 - Backport code from head branch of fontconfig CVS to parse names for postscript fonts (fixes #127500, J. J. Ramsey) - Own /usr/share/fonts (#110956, David K. Levine) - Add KacstQura to serif/sans-serif/monospace aliases (#101182) fonts-ISO8859-2-1.0-13 ---------------------- * Wed Sep 22 2004 Owen Taylor - 1.0-13 - Require xorg-x11-font-utils (#125031, Maxim Dzumanenko) fonts-arabic-1.5-3 ------------------ * Wed Sep 22 2004 Owen Taylor - 1.5-3 - Bump and rebuild fonts-bengali-0.1-3 ------------------- * Wed Sep 22 2004 Owen Taylor - 0.1-3 - Bump and rebuild fonts-hebrew-0.100-4 -------------------- * Wed Sep 22 2004 Owen Taylor - 0.100-4 - Upgrade to 0.100 gedit-2.8.0-1 ------------- * Wed Sep 22 2004 Dan Williams 1:2.8.0-1 - Update to 2.8.0 ggv-2.8.0-1 ----------- * Wed Sep 22 2004 Dan Williams 2.8.0-1 - Update to 2.8.0 glibc-2.3.3-55 -------------- * Wed Sep 22 2004 Jakub Jelinek 2.3.3-55 - update from CVS - set{re,e,res}[ug]id now affect the whole process in NPTL - return EAGAIN instead of ENOMEM when not enough memory in pthread_create gnome-games-2.8.0-1 ------------------- * Wed Sep 22 2004 Christopher Aillon 2.8.0-1 - Update to 2.8.0 and gnome-games-extra-data 2.8.0 gnome-icon-theme-2.8.0-1 ------------------------ * Wed Sep 22 2004 Alexander Larsson - 2.8.0-1 - Update to 2.8.0 gnome-themes-2.8.0-1 -------------------- * Wed Sep 22 2004 Alexander Larsson - 2.8.0-1 - update to 2.8.0 gnome-user-docs-2.8.0.1-1 ------------------------- * Wed Sep 22 2004 Christopher Aillon 2.8.0.1-1 - Update to 2.8.0-1 gnome-utils-2.8.0-1 ------------------- * Wed Sep 22 2004 Christopher Aillon 1:2.8.0-1 - Update to 2.8.0 and zenity 2.8.0 gpdf-2.8.0-1 ------------ * Wed Sep 22 2004 Dan Williams 2.8.0-1 - Update to 2.8.0 - Fix Gnome #153153/Red Hat #132469, patch works around a gnome-vfs issue by issuing an error, rather than crashing gtk2-2.4.10-1 ------------- * Wed Sep 15 2004 Matthias Clasen - 2.4.10-1 - update to latest upstream version, drop some patches hpoj-0.91-9 ----------- * Wed Sep 22 2004 Than Ngo 0.91-9 - add Prereq: /sbin/ldconfig * Tue Jun 15 2004 Elliot Lee - rebuilt hwdata-0.134-1 -------------- * Wed Sep 22 2004 Bill Nottingham - 0.134-1 - map ncr53c8xx to sym53c8xx (#133181) initscripts-7.84-1 ------------------ * Wed Sep 22 2004 Bill Nottingham - 7.84-1 - only start udev once * Wed Sep 22 2004 Jeremy Katz - 7.83-1 - conflict with old udev - use udev if it's present * Tue Sep 21 2004 Bill Nottingham - don't mount usbfs without usb. also, at least be consistent in filesystem type kernel-2.6.8-1.541 ------------------ * Tue Aug 31 2004 Arjan van de Ven - fix execshield buglet with legacy binaries - 2.6.9-rc1-bk7 * Mon Aug 30 2004 Arjan van de Ven - 2.6.9-rc1-bk6 * Sat Aug 28 2004 Arjan van de Ven - 2.6.9-rc1-bk4, now with i915 DRM driver libbonobo-2.8.0-1 ----------------- * Wed Sep 22 2004 Alexander Larsson - 2.8.0-1 - update to 2.8.0 * Fri Jul 30 2004 Ray Strode 2.6.2-2 - rebuilt * Fri Jul 30 2004 Ray Strode 2.6.2-1 - Update to 2.6.2 libbonoboui-2.8.0-1 ------------------- * Wed Sep 22 2004 Alexander Larsson - 2.8.0-1 - update to 2.8.0 libcroco-0.6.0-4 ---------------- * Wed Sep 22 2004 Matthias Clasen - 0.6.0-4 - Move croco-config to the devel package libgnome-2.8.0-1 ---------------- * Wed Sep 22 2004 Alexander Larsson - 2.8.0-1 - update to 2.8.0 * Tue Aug 31 2004 Alex Larsson 2.7.92-1 - update to 2.7.92 * Wed Aug 11 2004 Alexander Larsson - 2.7.2-2 - Update default fixes to patch schemas.in files libgnomecanvas-2.8.0-1 ---------------------- * Wed Sep 22 2004 Alexander Larsson - 2.8.0-1 - update to 2.8.0 libgnomeui-2.8.0-1 ------------------ * Wed Sep 22 2004 Alexander Larsson - 2.8.0-1 - update to 2.8.0 libgtop2-2.8.0-1 ---------------- * Wed Sep 22 2004 Alexander Larsson - 2.8.0-1 - update to 2.8.0 libieee1284-0.2.8-4 ------------------- * Wed Sep 22 2004 Than Ngo 0.2.8-4 - add Prereq: /sbin/ldconfig * Tue Jun 15 2004 Elliot Lee - rebuilt libselinux-1.17.13-2 -------------------- * Wed Sep 22 2004 Dan Walsh 1.17.13-2 - Add alpha patch libsoup-2.2.0-2 --------------- * Wed Sep 22 2004 David Malcolm - 2.2.0-2 - added requirement on gnutls, so that we build with SSL support - fixed source download path libuser-0.51.11-1 ----------------- * Thu Sep 23 2004 Miloslav Trmac - 0.51.11-1 - Allow documented optional arguments in Python ADMIN.{addUser,modifyUser,deleteUser} (#119812) - Add man pages for lchfn and lchsh - LDAP fixes, first round - Avoid file conflict on multilib systems - Call ldconfig correctly * Fri Sep 03 2004 Miloslav Trmac - 0.51.10-1 - Don't attempt to lookup using original entity name after entity modification (rename in particular) (#78376, #121252) - Fix copying of symlinks from /etc/skel (#87572, original patch from gLaNDix) - Make --enable-quota work, and fix the quota code to at least compile (#89114) - Fix several bugs (#120168, original patch from Steve Grubb) - Don't hardcode python version in spec file (#130952, from Robert Scheck) - Properly integrate the SELinux patch, it should actually be used now, even though it was "enabled" since 0.51.7-6 * Tue Aug 31 2004 Miloslav Trmac - 0.51.9-1 - Fix various typos - Document library interfaces - Build all shared libraries with -fPIC (#72536) mailcap-2.1.16-1 ---------------- * Thu Sep 23 2004 Bill Nottingham 2.1.16-1 - eog -> gthumb - pdfs -> gpdf mikmod-3.1.6-28 --------------- * Wed Sep 22 2004 Than Ngo 3.1.6-28 - increase release number * Wed Sep 22 2004 Than Ngo 3.1.6-27 - new devel sub package, multiarch problem - add /sbin/ldconfig in Prereq - cleanup specfile mkinitrd-4.1.12-1 ----------------- * Wed Sep 22 2004 Jeremy Katz - 4.1.12-1 - update to work with udev 032, conflict with old udev - if udev is present, use it. trying to avoid the use of udev if it's installed is the road to things not working module-init-tools-3.1-0.pre5.3 ------------------------------ * Wed Sep 22 2004 Bill Nottingham 3.1-0.pre5.3 - add rule for emu10k1 synth (#133280) mozilla-1.7.3-1 --------------- * Wed Sep 15 2004 Christopher Aillon 37:1.7.3-1 - Update to 1.7.3 - Add temporary patch to compile against newer freetype. See bugzilla.mozilla.org 234035 - Remove ppc temporarily; since it doesn't compile. See bugzilla.redhat.com 133316 nautilus-cd-burner-2.8.2-1 -------------------------- * Wed Sep 22 2004 Alexander Larsson - 2.8.2-1 - Update to 2.8.2 - Remove old upstreamed patches - make new cvs backport patch net-snmp-5.1.2-7 ---------------- * Wed Sep 22 2004 Florian La Roche - move ldconfig post/postun to libs subrpm oprofile-0.8.1-8 ---------------- * Wed Sep 22 2004 Will Cohen - Add logic to use preferred symbol names. passivetex-1.25-3 ----------------- * Wed Sep 22 2004 Than Ngo 1.25-3 - rebuilt perl-Archive-Tar-1.08-3 ----------------------- * Wed Sep 22 2004 Chip Turner 1.08-3 - rebuild perl-Convert-ASN1-0.18-3 ------------------------ * Wed Sep 22 2004 Chip Turner 0.18-3 - rebuild perl-DateManip-5.42a-3 ---------------------- * Wed Sep 22 2004 Chip Turner 5.42a-2 - rebuild perl-Digest-HMAC-1.01-13 ------------------------ * Wed Sep 22 2004 Chip Turner 1.01-13 - rebuild perl-File-MMagic-1.21-2 ----------------------- * Wed Sep 22 2004 Chip Turner 1.21-2 - rebuild perl-Filter-Simple-0.79-4 ------------------------- * Wed Sep 22 2004 Chip Turner 0.79-4 - rebuild perl-Frontier-RPC-0.06-38 ------------------------- * Wed Sep 22 2004 Chip Turner 0.06-38 - rebuild perl-HTML-Tagset-3.03-30 ------------------------ * Wed Sep 22 2004 Chip Turner 3.03-30 - rebuild perl-LDAP-0.31-5 ---------------- * Wed Sep 22 2004 Chip Turner 0.31-5 - rebuild perl-Net-DNS-0.45-4 ------------------- * Wed Sep 22 2004 Chip Turner 0.45-4 - rebuild perl-Parse-RecDescent-1.94-4 ---------------------------- * Wed Sep 22 2004 Chip Turner 1.94-4 - rebuild perl-Parse-Yapp-1.05-32 ----------------------- * Wed Sep 22 2004 Chip Turner 1.05-32 - rebuild perl-RPM-Specfile-1.17-2 ------------------------ * Wed Sep 22 2004 Chip Turner 1.17-2 - rebuild perl-SGMLSpm-1.03ii-14 ---------------------- * Wed Sep 22 2004 Than Ngo - rebuilt perl-TimeDate-1.16-2 -------------------- * Wed Sep 22 2004 Chip Turner 1:1.16-2 - rebuild perl-XML-Dumper-0.71-2 ---------------------- * Wed Sep 22 2004 Chip Turner 0.71-2 - rebuild perl-XML-Encoding-1.01-26 ------------------------- * Wed Sep 22 2004 Chip Turner 1.01-26 - rebuild perl-XML-Grove-0.46alpha-27 --------------------------- * Wed Sep 22 2004 Chip Turner 0.46alpha-26 - rebuild perl-XML-NamespaceSupport-1.08-6 -------------------------------- * Wed Sep 22 2004 Chip Turner 1.08-6 - rebuild perl-XML-Twig-3.13-6 -------------------- * Wed Sep 22 2004 Chip Turner 3.13-6 - rebuild perl-libxml-enno-1.02-31 ------------------------ * Wed Sep 22 2004 Chip Turner 1.02-31 - rebuild perl-libxml-perl-0.07-30 ------------------------ * Wed Sep 22 2004 Chip Turner 0.07-30 - rebuild pinfo-0.6.8-6 ------------- * Wed Sep 22 2004 Mike A. Harris 0.6.8-6 - Bump release and rebuild in rawhide for FC3 * Tue Jun 15 2004 Elliot Lee - rebuilt planner-0.12-6 -------------- * Wed Sep 22 2004 Florian La Roche - add ldconfig calls to post/postun ppc64-utils-0.7-5 ----------------- * Wed Sep 22 2004 Jeremy Katz - 0.7-5 - rebuild * Tue Jun 15 2004 Elliot Lee - rebuilt redhat-artwork-0.102-1 ---------------------- * Wed Sep 15 2004 Alexander Larsson - 0.101-2.1E - rhel build * Wed Sep 15 2004 Alexander Larsson - 0.101-2 - Change the way we modify the background color * Tue Sep 14 2004 Alexander Larsson - 0.101-1 - Fix gnome cd audio icon (#119288) redhat-menus-1.6.1-2 -------------------- * Wed Sep 22 2004 Warren Togami 1.6.1-2 - remove ugly hacks so package is easier to maintain rhpl-0.146-1 ------------ * Wed Sep 22 2004 Jeremy Katz - 0.146-1 - add synaptics support (pnasrat) - add arabic and indic keyboards (pnasrat) rootfiles-8-1 ------------- * Wed Sep 22 2004 Bill Nottingham 8-1 - sync files with current /etc/skel stuff - remove Xresources (#75666) rpmdb-fedora-2.91-0.20040923 ---------------------------- setup-2.5.34-1 -------------- * Thu Sep 23 2004 Bill Nottingham 2.5.34-1 - add dict (#107807) - add cyrus services (#118832) - move delete-char binding for csh (#113682) - do the same path munging for csh as for bash (#57708) - add postfix aliases (#117661) - fix bashrc login shell check (#104491) - add odmr to services (#101098) - add distcc to services (#91535) - add xterm forware/backward word bindings (#80860) * Mon May 24 2004 Bill Nottingham - make pathmunge available for profile.d scripts (#123621) * Wed May 19 2004 Joe Orton 2.5.33-2 - add IANA Register Port for svn to /etc/services (#122863) sgml-common-0.6.3-17 -------------------- * Wed Sep 22 2004 Than Ngo 0.6.3-17 - rebuilt spamassassin-3.0-10 ------------------- * Wed Sep 22 2004 Warren Togami - 3.0-10 - 3.0.0 final * Sun Sep 12 2004 Warren Togami - 3.0-9.rc4 - 3.0 rc4 - update krb5 backcompat patch (John Lundin) * Sat Sep 04 2004 Warren Togami - 3.0-8.rc3 - 3.0 rc3 swig-1.3.21-4 ------------- * Wed Sep 22 2004 Florian La Roche - add ldconfig calls to post/postun sysfsutils-1.1.0-3 ------------------ * Wed Sep 22 2004 Florian La Roche - added /sbin/ldconfig calls to post/postun system-config-keyboard-1.2.3-1 ------------------------------ * Wed Sep 22 2004 Jeremy Katz - 1.2.3-1 - fix traceback when using treeview typeahead (#133178) system-logviewer-0.9.9-1 ------------------------ * Wed Sep 22 2004 Paul Nasrat 0.9.9-1 - Makefile fix for about translation (#133135) ttfonts-zh_CN-2.14-8 -------------------- * Wed Sep 22 2004 Yu Shao 2.14-8 - rebuild udev-032-2 ---------- * Wed Sep 22 2004 Harald Hoyer - 032-2 - removed option to turn off udev - udevstart.static now symling to udev.static unixODBC-2.2.9-1 ---------------- * Wed Sep 22 2004 Tom Lane 2.2.9-1 - Update to unixODBC 2.2.9 usermode-1.71-2 --------------- * Mon Sep 20 2004 Jindrich Novy 1.71-2 - added "-I" option to mkfs in the .mkfs patch (#117793) xboard-4.2.7-6 -------------- * Wed Sep 22 2004 Than Ngo 4.2.7-6 - cleanup specfile xmltex-20020625-3 ----------------- * Wed Sep 22 2004 Than Ngo 20020625-3 - rebuilt yelp-2.6.3-1 ------------ * Wed Sep 22 2004 Christopher Aillon 2.6.3-1 - Update to 2.6.3 From ndbecker2 at verizon.net Thu Sep 23 12:08:31 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Thu, 23 Sep 2004 08:08:31 -0400 Subject: rawhide report: 20040923 changes References: <200409231150.i8NBo6w08534@porkchop.devel.redhat.com> Message-ID: Build System wrote: > > boost-1.31.0-9 > -------------- > * Wed Sep 22 2004 Than Ngo 1.31.0-9 > > - cleanup specfile > - fix multiarch problem > FYI, release boost-1.32 is imminent From fedora-devel at camperquake.de Thu Sep 23 12:11:58 2004 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 23 Sep 2004 14:11:58 +0200 Subject: rawhide report: 20040923 changes In-Reply-To: <200409231150.i8NBo6w08534@porkchop.devel.redhat.com> References: <200409231150.i8NBo6w08534@porkchop.devel.redhat.com> Message-ID: <20040923141158.4cdc6c56@nausicaa.camperquake.de> Hi. > kernel-2.6.8-1.541 > ------------------ Is that the version with the slightly broken ext3, or another version that happens to have the same name? In both cases: why? -- Wer andern eine Grube gr?bt, der hat ein Grubengrabger?t From arjanv at redhat.com Thu Sep 23 12:26:36 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 23 Sep 2004 14:26:36 +0200 Subject: rawhide report: 20040923 changes In-Reply-To: <20040923141158.4cdc6c56@nausicaa.camperquake.de> References: <200409231150.i8NBo6w08534@porkchop.devel.redhat.com> <20040923141158.4cdc6c56@nausicaa.camperquake.de> Message-ID: <1095942396.2612.16.camel@laptop.fenrus.com> On Thu, 2004-09-23 at 14:11, Ralf Ertzinger wrote: > Hi. > > > kernel-2.6.8-1.541 > > ------------------ > > Is that the version with the slightly broken ext3, or another version > that happens to have the same name? In both cases: why? the new one broke selinux and the selinux people got very unhappy about that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Thu Sep 23 12:26:45 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 23 Sep 2004 14:26:45 +0200 Subject: rawhide report: 20040923 changes In-Reply-To: <20040923141158.4cdc6c56@nausicaa.camperquake.de> References: <200409231150.i8NBo6w08534@porkchop.devel.redhat.com> <20040923141158.4cdc6c56@nausicaa.camperquake.de> Message-ID: <1095942405.2612.18.camel@laptop.fenrus.com> On Thu, 2004-09-23 at 14:11, Ralf Ertzinger wrote: > Hi. > > > kernel-2.6.8-1.541 > > ------------------ > > Is that the version with the slightly broken ext3, or another version > that happens to have the same name? In both cases: why? > > -- > Wer andern eine Grube gr?bt, der hat ein Grubengrabger?t -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buytenh at wantstofly.org Thu Sep 23 12:29:36 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 23 Sep 2004 14:29:36 +0200 Subject: BUG: dst underflow 0: 3bcf9a80 at 42350024 Message-ID: <20040923122936.GA12053@xi.wantstofly.org> Hi, The message "BUG: dst underflow 0: 3bcf9a80 at 42350024" seems to have appeared in my syslog somewhere last night. I'm using kernel-smp-2.6.8-1.521. I've not seen this before so far. Anyone else seen this happening? --L From fedora-devel at camperquake.de Thu Sep 23 12:32:45 2004 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 23 Sep 2004 14:32:45 +0200 Subject: rawhide report: 20040923 changes In-Reply-To: <1095942396.2612.16.camel@laptop.fenrus.com> References: <200409231150.i8NBo6w08534@porkchop.devel.redhat.com> <20040923141158.4cdc6c56@nausicaa.camperquake.de> <1095942396.2612.16.camel@laptop.fenrus.com> Message-ID: <20040923143245.5091e7d8@nausicaa.camperquake.de> Hi. Arjan van de Ven wrote: > the new one broke selinux and the selinux people got very unhappy about > that. So this version does not have the ext3 bug anymore, although it has the same relase tag? -- Each year it takes less time to cross the country and more time to get to work. -- Mary Waldrip From russell at coker.com.au Thu Sep 23 12:38:09 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 23 Sep 2004 22:38:09 +1000 Subject: httpd/rawhide In-Reply-To: <1095936891.4119.6.camel@nelson.hilling.de> References: <1095936891.4119.6.camel@nelson.hilling.de> Message-ID: <200409232238.09803.russell@coker.com.au> On Thu, 23 Sep 2004 20:54, Gunnar Hilling wrote: > Sep 23 12:50:45 nelson kernel: audit(1095936645.518:0): avc: denied { > execute } for pid=4862 path=/lib/tls/i686/libdb-4.2.so dev=dm-5 > ino=234979213 scontext=root:system_r:httpd_t > tcontext=system_u:object_r:lib_t tclass=file > > Anyone could fix this in the policy (cause I can't...). The attached patch to the policy source fixes the problem. If you don't use the policy source then just append the following line to /etc/selinux/targeted/contexts/files/file_contexts and then use restorecon to fix the context of the file. /lib(64)?/tls/i.86/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-diff Size: 510 bytes Desc: not available URL: From russell at coker.com.au Thu Sep 23 13:26:43 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 23 Sep 2004 23:26:43 +1000 Subject: please try SELinux again In-Reply-To: <4187.66.151.13.92.1095716006.squirrel@66.151.13.92> References: <414F4756.9050006@redhat.com> <4187.66.151.13.92.1095716006.squirrel@66.151.13.92> Message-ID: <200409232326.43315.russell@coker.com.au> On Tue, 21 Sep 2004 07:33, "W. Michael Petullo" wrote: > Should one expect a system to boot when SELinux is enforcing Fedora's > strict policy and all of the Hollywood hal, udev, etc. is being used? In SE Linux should work no matter what you do. When a major new feature is added (EG tmpfs for /dev) it may take some time (weeks even) to get SE Linux support. Apart from that everything should work all the time. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From aoliva at redhat.com Thu Sep 23 14:45:26 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 23 Sep 2004 11:45:26 -0300 Subject: dm-snapshot.ko In-Reply-To: <200409232021.08781.russell@coker.com.au> References: <200409232021.08781.russell@coker.com.au> Message-ID: On Sep 23, 2004, Russell Coker wrote: > Attempts to create a snapshot LV when dm-snapshot is not loaded fail with an > obscure error. I think that this is a bug, would it be a kernel bug or an > LVM utility bug? LVM utility. BZ#122991 covers this problem. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Thu Sep 23 14:49:29 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 23 Sep 2004 11:49:29 -0300 Subject: rawhide report: 20040923 changes In-Reply-To: <20040923143245.5091e7d8@nausicaa.camperquake.de> References: <200409231150.i8NBo6w08534@porkchop.devel.redhat.com> <20040923141158.4cdc6c56@nausicaa.camperquake.de> <1095942396.2612.16.camel@laptop.fenrus.com> <20040923143245.5091e7d8@nausicaa.camperquake.de> Message-ID: On Sep 23, 2004, Ralf Ertzinger wrote: > So this version does not have the ext3 bug anymore, although it has the > same relase tag? It never had an ext3 bug. It was a previous release that did, but people got confused because the bug corrupted ext3 meta-data, and upgrading the kernel wouldn't fix that; you had to actually run fsck. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From byte at aeon.com.my Thu Sep 23 05:33:01 2004 From: byte at aeon.com.my (Colin Charles) Date: Thu, 23 Sep 2004 15:33:01 +1000 Subject: Announcing Fedora Core 3 Test 2 In-Reply-To: <000601c49fd0$5ddd1380$82368552@thor> References: <20040920141606.GA30766@nostromo.devel.redhat.com> <1095763787.31730.4325.camel@imladris.demon.co.uk> <000601c49fd0$5ddd1380$82368552@thor> Message-ID: <1095917581.21380.135.camel@albus.aeon.com.my> On Tue, 2004-09-21 at 21:44, Kashif Ali wrote: > Just wondering, is it safe to buy a Apple powerbook and install fedora on it > , will all the hardware be supported. I was thinking of buying the 12" or > 15" powerbook. Your comments on the powerbook are welcome :) Everything should be supported minus Airport Extreme and sleep for the newer Powerbooks/iBooks. We have a list: fedora-ppc at lists.infradead.org - please subscribe to it and we can continue further discussion there We also have the "install guide" at http://www.bytebot.net/geekdocs/ibook/fedorappc.html (and who knows, when you actually read this, it'll be Rawhide ready) -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From skvidal at phy.duke.edu Thu Sep 23 16:57:44 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 23 Sep 2004 12:57:44 -0400 Subject: jabberd spec In-Reply-To: <1095939636.2898.7.camel@marte.biciclete.ro> References: <1095899455.4477.37.camel@nexus.verbum.private> <1095899349.26667.0.camel@binkley> <1095939636.2898.7.camel@marte.biciclete.ro> Message-ID: <1095958664.28615.3.camel@binkley> On Thu, 2004-09-23 at 14:40 +0300, Marius Andreiana wrote: > On Wed, 2004-09-22 at 20:29 -0400, seth vidal wrote: > > jabberd 2.0 has stopped development - the primary developer has gone > > away from it. Moreover it has pretty serious stability problems. > Seth, what jabber server do you recommend? > 1.4.3 works ok - but it's not xmpp spec compliant. -sv From lex at fixedpoint.org Thu Sep 23 18:31:14 2004 From: lex at fixedpoint.org (Alexander Holt) Date: 23 Sep 2004 20:31:14 +0200 Subject: "Stateless Linux" project In-Reply-To: <1095100955.5481.14.camel@localhost.localdomain> References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Havoc Pennington wrote: > Red Hat engineering is starting a new project we're calling "stateless > Linux" ... Good stuff. The "ideal properties" of an OS (recreating state bit-for-bit on new hardware, modifying groups of machines in a single step): absolutely. Further, I'd say, it should be straightforward to rapidly modify single machines (or groups) for specialized purposes. To me, this emphasizes is the need for smart configuration management technology. Thin/cached/fat clients: largely orthogonal. Home directory syncing/backup strategies: almost entirely orthogonal. What we want are good ways to keep large numbers of diverse machines configured as required -- once we have that, implementing specific policies is mostly secondary. As the document says, it's enough to reconstruct all client state from a central location. John Hearns and Josh England have already pointed out that there are substantial mechanisms around for doing a good chunk of this. I'm not familiar with oneSIS beyond reading the documentation, but can maybe briefly describe how LCFG (and to a large extent, Quattor ) do things. LCFG can be used to control any category of machine. It's in use at Edinburgh University's School of Informatics to manage around 1000 nodes, comprising desktops, laptops, servers & cluster machines. To each node you add a collection of small init-like scripts, called components, responsible for controlling daemons and config files. You don't need a read-only root. Components read a per-node "profile" telling them, eg, what the current mail hub is. The mail component is responsible for creating/modifying the local MTA's config file so that it specifies that mail hub -- and if there's a daemon, (re)starting it as appropriate. (Compare with oneSIS where, say, /etc/mail/sendmail.cf would be linked to the per-node/group/cluster master copy via a RAM disk - -- if I've got it right.) The per-node profile -- much like a long list of key-value pairs -- is compiled centrally from a declarative description of what each node should look like. This description permits machine grouping and prototypes via a #include-type mechanism. So it's easy to make small per-machine or per-node tweaks. The same description is used to specify the complete RPM list for each node (all non-config files on nodes come from RPMs). Profiles are distributed to nodes by HTTP(S). A node gets a UDP notification when its profile has changed, or can just poll the config server. There's also a way to make controlled changes to the local profile without the need to talk to the config server -- eg, on a laptop when it moves between networks. And nodes can be built entirely automatically from bare metal (but no magical solution to bootstrapping host keys in, eg, a Kerberos environment). Couple of other thoughts: (*) Mobility -- and disconnected operation -- is an important architectural constraint. (For instance, the current Edinburgh LCFG deployment integrates laptops & desktops, and ends up replicating DNS & LDAP servers on *all* nodes.) (*) The central location that stores client state doesn't ultimately have to be a central location. It could be that intended client state is assembled from various kinds of config data distributed around the net -- perhaps via peer-to-peer or service discovery type mechanisms -- leading to improved resilience & autonomy. This is just another take on "dynamic/automatic configuration", I guess. Lex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 iD8DBQFBUxZrZnhMljHa7tgRAoZOAJ9EJ5Cx68/Orfct1b8amat/vya8AACfX2mg ajEbcygyypPGLMzgtQD7Aug= =vocE -----END PGP SIGNATURE----- From notting at redhat.com Thu Sep 23 19:00:38 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 23 Sep 2004 15:00:38 -0400 Subject: FC3 Bug Status - 2004-09-23 Message-ID: <20040923190038.GA9183@nostromo.devel.redhat.com> Based on bug #123268 ('FC3Target') and bug #130887 ('FC3Blocker') 2004-09-23 Severity Total Closed Need Testing BLOCKER 74 43 ( 58.11 %) 9 ( 20.93 %) TARGET 703 286 ( 40.68 %) 38 ( 13.29 %) Overall 777 329 ( 42.34 %) 47 ( 14.00 %) 2004-09-08 Severity Total Closed Need Testing BLOCKER 35 14 ( 40.00 %) 3 ( 21.43 %) TARGET 591 194 ( 32.83 %) 33 ( 17.01 %) Overall 626 208 ( 33.23 %) 36 ( 17.00 %) 2004-08-18 Severity Total Closed Need Testing TARGET 415 61 ( 14.70 %) 16 ( 26.23 %) From kewley at cns.caltech.edu Thu Sep 23 19:06:14 2004 From: kewley at cns.caltech.edu (David Kewley) Date: Thu, 23 Sep 2004 12:06:14 -0700 Subject: the fate of firewire In-Reply-To: <1095124195.21264.2.camel@binkley> References: <1095124195.21264.2.camel@binkley> Message-ID: <200409231206.14375.kewley@cns.caltech.edu> seth vidal wrote on Monday 13 September 2004 18:09: > > On the one hand, you can't have kernel depend on an > > optional kernel-firewire package. On the other hand, > > people's systems might depend on it... > > > > AFAIK Yum can't handle situations like this right. > > you want to track the version of the kernel and update another package > based on what the latest kernel version is. > > No, that's not something yum can do. How about making kernel-firewire depend on the exact version of the kernel? Then make sure the updated kernel-firewire package is release before or simultaneously with the new kernel package. In this case, if you do 'yum update kernel', won't yum see that that kernel-firewire needs to be upgraded also? If yum can't do this, how hard would it be to add the logic? I've not thought this through in any depth, so I won't be surprised, Set, if there's a good reason you can't easily do this. :) David From jjengla at sandia.gov Thu Sep 23 21:02:16 2004 From: jjengla at sandia.gov (Josh England) Date: Thu, 23 Sep 2004 14:02:16 -0700 Subject: "Stateless Linux" project In-Reply-To: References: <1095100955.5481.14.camel@localhost.localdomain> Message-ID: <1095973336.11390.96.camel@localhost> On Thu, 2004-09-23 at 11:31, Alexander Holt wrote: > LCFG can be used to control any category of machine. > [....] > (*) Mobility -- and disconnected operation -- is an important > architectural constraint. [....] > > (*) The central location that stores client state doesn't ultimately > have to be a central location. [....] LCFG does indeed sound like a highly capable configuration deployment engine (how does it compare with cfengine, in your opinion?). I believe there are several key differences, however, between the approach that a configuration deployment engine uses, and the approach that oneSIS takes. Any configuration engine (LCFG and cfengine it seems at least) centrally manage clients by shipping/creating configuration files to each client, which can then act independently from the server. Each client potentially has its own singular configuration, and every client potentially differs from every other. With oneSIS, every client is always bit-for-bit identical with every other client. Independent configuration is done by editing the config files for the particular node/class (ie: /etc/fstab.myclass), making administration of a large group of machines a natural extension of administering a single machine without the need for a configuration language. When the rootFS is guaranteed to be bit-for-bit identical, every (diskful) node can in turn serve its root image to any number of other client nodes. This can be used to create a hierarchical tree where every node remains bit-for-bit identical with the server it synchronizes from, and each (diskful) node can operate stand-alone, disconnected from the network. Any diskful node can mount its root filesystem read-write if desired, with the knowledge that any local changes will be lost if it fully synchronizes itself with its master (bi-directional sync is a no-no). Every node is exactly identical, with the node's configuration determined at boot-time. This means any node can essentially 'become' any other node simply by rebooting (though there are plans to extend this to allow run-time re-configuration). The most striking benefit though, in my opinion, is the ability to boot any machine 'diskless' into the exact same environment as the diskful nodes. Client machines don't even need to have a disk to boot into the system. However, a client node with a local disk (a laptop for instance), can boot into a diskless environment without affecting its own local OS installation in any way. This would be desirable for those who don't like to have others control the OS on their machine. The user can afterwards reboot back into his/her own local OS and resume life like normal. Everything is completely stateless. When collaborating with visitors with their own laptops, a single root image can be exported for everyone to run in (diskless) for the duration of the collaboration, and then they can return to their own OS setup by rebooting from their local disk. Alternatively, any single machine can deploy (or just copy) the image to a local disk, move it anywhere, and export it to an number of client nodes in turn. There are several other benefits of diskless operation (ie: instantaneous updates) that make it very attractive. oneSIS only handles the management/deployment of a master root image. The behavior of the machine is near-indistinguishable from a normal Fedora installation. It is simple in design, and IMO astoundingly easy to administer a oneSIS system (everything is identical!). The bootstrap mechanisms in place (initrd generation from a template) provide a framework for creating unique (key-based/Kerberos ?) methods for authenticating client nodes if desired. The probably not suited for every conceivable environment, in all I believe oneSIS can be an excellent starting point to accomplish the goals of the "Stateless Linux" project. -JE ----------------------------------------------- Josh England Sandia National Laboratory, Livermore, CA Visualization and Scientific Computing email: jjengla at sandia.gov phone: (925) 294-2076 From carwyn at carwyn.com Thu Sep 23 22:09:43 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Thu, 23 Sep 2004 23:09:43 +0100 Subject: "Stateless Linux" project In-Reply-To: <1095973336.11390.96.camel@localhost> References: <1095100955.5481.14.camel@localhost.localdomain> <1095973336.11390.96.camel@localhost> Message-ID: <415349A7.1060306@carwyn.com> Josh England wrote: > LCFG does indeed sound like a highly capable configuration deployment > engine (how does it compare with cfengine, in your opinion?). They are very similar in terms of what happens - central configuration is "enacted" in some way on the clients via a number of agents. But their methods and models differ somewhat. LCFG (there are others that can explain cfengine better) for example is entirely declarative in terms of the central database. Nothing procedural is encoded in the profile for a machine as doing so means having to deal with ordering of configuration changes (A->a->B->b->C vs A->C, where upper = states and lower = transitional procedures). It's left to the agents to work out the procedures making disconnected operation simpler (it doesn't matter if a laptop misses the update from A to B as A->B->C "should" give you the same as A->C. Procedural models often mean that all the intermediary transformations have to be applied. One thing that is particularly powerful about LCFG is the idea of spanning maps. Client configuration descriptions can export collections of information into a global namespace that other conponents can then subscribe to. For example in the client config for the web server I'd put: firewall.holes 80 443 .. then because the schema for the firewall component says that the "holes" property is to be a member of a spanning map, on the firewall host itself the firewall component automatically gathers the information and opens the holes. The definition of the "hole" though is in the same config file as the configuration for the web server. This can be extended to: # In a file called i-want-to-be-a-web-server.h apache.port 80 firewall.holes <%apache.port%> # reference to above. .. then in the source profile for each member of a web cluster: #include As soon as I write the file packets fly all over the place and a few seconds later the firewall has holes to all the machines in the cluster on port 80. Edit i-want-to-be-a-web-server.h to add 443, write it and again a few seconds later you have those holes too. If we add an extra gateway firewall for redundancy it can be told to subscribe to that particular map and add the holes too. We can do the same for which rpms are installed on machines. One minute a lab full of machines could be a fedora minimal install, a few mins later they are all members of a beowulf cluster, software installed and configuration applied (assuming you've prepared the config template earlier obviously). Uninclude the header file for being in the beowulf and a few mins later again they are back to being fedora minimal installs. Part of the research effort here is to extend this idea so that the description is even more abstract. I.e. be able to take a group of machines and write the equivalent of: "I want a workgroup setup with a file server, web server, firewall and special laptop to control the bluetooth light in the fishtank." The configuration engine should then go off and work out which machine the printer is connected to, which one is the laptop and just make it all happen (I did say research effort!). Carwyn From ezannoni at redhat.com Thu Sep 23 22:04:03 2004 From: ezannoni at redhat.com (Elena Zannoni) Date: Thu, 23 Sep 2004 18:04:03 -0400 Subject: [ANNOUNCE] New mailing list: fedora-tools-list Message-ID: <16723.18515.99062.946342@localhost.redhat.com> This is to announce the availability of a new Fedora mailing list for tools specific discussions. The term "tools" includes packages like gcc, gdb, binutils, glibc, oprofile, libstdc++, elfutils, etc... The list is for users and developers posting bug reports, usage questions and answers, patches and test results, etc. For subscription details see: http://www.redhat.com/mailman/listinfo/fedora-tools-list From carwyn at carwyn.com Thu Sep 23 22:46:44 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Thu, 23 Sep 2004 23:46:44 +0100 Subject: "Stateless Linux" project In-Reply-To: <1095973336.11390.96.camel@localhost> References: <1095100955.5481.14.camel@localhost.localdomain> <1095973336.11390.96.camel@localhost> Message-ID: <41535254.6060600@carwyn.com> Josh England wrote: >making administration of a large > group of machines a natural extension of administering a single machine > without the need for a configuration language. [Devil's advocate mode.] While this is good in terms of teaching existing sysadmins to use OneSiS, the single language model allows less skilled staff (front line support in our case) to edit a single common format that they understand and have the agents do the hard part of understanting dhcpd.conf, DNS zone files or sendmail.cf (yes you can get impedence mismatches). Making a GUI that can then edit this single declarative language is then significantly simpler than one per format. The agents only need to write the native per daemon/application config files with a template engine. The read phase to show the user the current state of the configuration data comes from the profile that's in the single declarative language. (Yes this means that you can't jump in and edit the native files by hand, yes it's annoying at times). Metadata in the schema details for a component could even be used to triger daemon specific help (or even GUI layout) in the GUI (no we don't have one that does this yet but it could be done). In the end it depends what you are trying to do. Existing sysadmins will probably like the OneSiS model, new Sysadmins coming from something like Windows server admin might have a different view. > I believe oneSIS can be an excellent starting point to > accomplish the goals of the "Stateless From what I can see there are maybe a handful of projects out there that have made significant progress in this area which is great. Hopefully the lessons learned from each project can be carried forward. I certainly think this is an area were different options and approaches is very imporant. Vendor lockin to configuration engines/methods is horrible. Carwyn From jjengla at sandia.gov Fri Sep 24 00:09:21 2004 From: jjengla at sandia.gov (Josh England) Date: Thu, 23 Sep 2004 17:09:21 -0700 Subject: "Stateless Linux" project In-Reply-To: <41535254.6060600@carwyn.com> References: <1095100955.5481.14.camel@localhost.localdomain> <1095973336.11390.96.camel@localhost> <41535254.6060600@carwyn.com> Message-ID: <1095984561.10072.27.camel@localhost> On Thu, 2004-09-23 at 15:46, Carwyn Edwards wrote: > Vendor lockin to configuration engines/methods is > horrible. I certainly agree. I would like to point out though that oneSIS operates at the filesystem level (files/directories, not VFS) and is completely oblivious to anything that is actually running on the machine. I configuration engine such as LCFG could peacefully coexist and from the sounds of it even complement the functionality provided by oneSIS. Instead of modifying the configs of remote files, it would simply be modifying the different variations of a file in the master image (ie: /etc/fstab.myclass). That way you could have the functionality provided by LCFG alongside the flexibility of using oneSIS. "Stateless" to me indirectly implies bit-for-bit identicality of the root filesystem. The ability is there to deploy a diskful node and diverge from the master image, but doing so, in my experience, only tends to complicate rather than simplify. -JE From carwyn at carwyn.com Fri Sep 24 00:47:46 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Fri, 24 Sep 2004 01:47:46 +0100 Subject: "Stateless Linux" project In-Reply-To: <1095984561.10072.27.camel@localhost> References: <1095100955.5481.14.camel@localhost.localdomain> <1095973336.11390.96.camel@localhost> <41535254.6060600@carwyn.com> <1095984561.10072.27.camel@localhost> Message-ID: <41536EB2.6090006@carwyn.com> Josh England wrote: > A configuration engine such as LCFG could peacefully coexist > and from the sounds of it even complement the functionality provided by > oneSIS. Instead of modifying the configs of remote files, it would > simply be modifying the different variations of a file in the master > image (ie: /etc/fstab.myclass). Yes this would be possible - LCFG doesn't care what the agents actually do. We have ones that run as pseudo components on "network controller hosts" that then talk to the switches/routers in whatever language they talk. VLAN/routing config on the switches changes based on the client host's profile (Yes it's scary). In theory you could also use it do things like create and start/stop UML images that in turn used LCFG/OneSiS inside the images. We've had experimental versions running on Windows and OS X too. Don't get me wrong, it's no silver bullet though. It has its flaws. People interested in this stuff might want to take a look at this: http://www.usenix.org/events/lisa04/ Carwyn From leonard at den.ottolander.nl Fri Sep 24 07:26:31 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 24 Sep 2004 09:26:31 +0200 Subject: FC3 Bug Status - 2004-09-23 In-Reply-To: <20040923190038.GA9183@nostromo.devel.redhat.com> References: <20040923190038.GA9183@nostromo.devel.redhat.com> Message-ID: <1096010790.4780.1.camel@athlon.localdomain> Hi Bill, On Thu, 2004-09-23 at 21:00, Bill Nottingham wrote: > Based on bug #123268 ('FC3Target') and bug #130887 ('FC3Blocker') > > 2004-09-23 > Severity Total Closed Need Testing > BLOCKER 74 43 ( 58.11 %) 9 ( 20.93 %) > TARGET 703 286 ( 40.68 %) 38 ( 13.29 %) > Overall 777 329 ( 42.34 %) 47 ( 14.00 %) Hm. Something 's odd about these "need testing" percentages... Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Fri Sep 24 07:34:56 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 24 Sep 2004 09:34:56 +0200 Subject: rawhide report: 20040923 changes In-Reply-To: References: <200409231150.i8NBo6w08534@porkchop.devel.redhat.com> <20040923141158.4cdc6c56@nausicaa.camperquake.de> <1095942396.2612.16.camel@laptop.fenrus.com> <20040923143245.5091e7d8@nausicaa.camperquake.de> Message-ID: <1096011296.4780.3.camel@athlon.localdomain> Hi Alexandre, On Thu, 2004-09-23 at 16:49, Alexandre Oliva wrote: > It never had an ext3 bug. It was a previous release that did, but > people got confused because the bug corrupted ext3 meta-data, and > upgrading the kernel wouldn't fix that; you had to actually run fsck. 538 to be precise: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131782 Leonard. -- mount -t life -o ro /dev/dna /genetic/research From laroche at redhat.com Fri Sep 24 07:56:19 2004 From: laroche at redhat.com (Florian La Roche) Date: Fri, 24 Sep 2004 09:56:19 +0200 Subject: FC3 Bug Status - 2004-09-23 In-Reply-To: <1096010790.4780.1.camel@athlon.localdomain> References: <20040923190038.GA9183@nostromo.devel.redhat.com> <1096010790.4780.1.camel@athlon.localdomain> Message-ID: <20040924075619.GA5758@dudweiler.stuttgart.redhat.com> On Fri, Sep 24, 2004 at 09:26:31AM +0200, Leonard den Ottolander wrote: > Hi Bill, > > On Thu, 2004-09-23 at 21:00, Bill Nottingham wrote: > > Based on bug #123268 ('FC3Target') and bug #130887 ('FC3Blocker') > > > > 2004-09-23 > > Severity Total Closed Need Testing > > BLOCKER 74 43 ( 58.11 %) 9 ( 20.93 %) > > TARGET 703 286 ( 40.68 %) 38 ( 13.29 %) > > Overall 777 329 ( 42.34 %) 47 ( 14.00 %) > > Hm. Something 's odd about these "need testing" percentages... "need testing" percentage is part of the closed bugs. So from the 43 closed bugs we have 9 which still need to be tested to be sure the bugs are indeed fixed, that is 20.93% from the 43 closed bugs. greetings, Florian La Roche From Axel.Thimm at ATrpms.net Fri Sep 24 08:13:42 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 24 Sep 2004 10:13:42 +0200 Subject: Request for FC3Blocker: #132947 (kernel memory leak on x86_64 in 32/64 mixed mode) Message-ID: <20040924081342.GA4894@neu.nirvana> According to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130887: > This is the master Fedora Core 3 "BLOCKER" bug. Any bug in > Red Hat bugzilla which would be considered a "stop ship" bug > a.k.a. a "ultra brown paper bag" bug, can be marked for consideration > to be a release BLOCKER by adding this bug to it's "Blocks:" field. > > Anyone in the community who wishes to nominate bugs for FC3Blocker > status, should discuss them on the fedora-devel-list at redhat.com, > and once concensus has been reached, someone can flag them as > FC3Blocker, or alternatively as FC3Target. > > This bug has the bug alias "FC3Blocker" for easy access and > blocker flagging. I think https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132947 is a definite candidate: > Running 32 bits applications on x86_64 FC distributions with kernels > based on 2.6.8 (2.6.8-1.521 and 2.6.8-1.541 currently) generate > continuous memory leaks. Returning to the previous 2.6.7 based > kernels turns this behaviour off. The bug comes from FC2 (so testers need not run FC3t2 to verify). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at redhat.com Fri Sep 24 12:02:20 2004 From: buildsys at redhat.com (Build System) Date: Fri, 24 Sep 2004 08:02:20 -0400 Subject: rawhide report: 20040924 changes Message-ID: <200409241202.i8OC2KD27297@porkchop.devel.redhat.com> Removed package gtkam Updated Packages: anaconda-10.0.3.3-1 ------------------- * Wed Sep 22 2004 Jeremy Katz - 10.0.3.3-1 - fix going back unmount of /dev/pts (#133301) - fix SRPMs disc (#122737) - add localboot option to isolinux.cfg (#120687) - fix tree build on ia64 and x86_64 - fix a syntax error for text mode selinux config at-spi-1.6.0-1 -------------- * Thu Sep 23 2004 Jonathan Blandford 1.6.0-1 - bump version autoconf213-2.13-9 ------------------ * Thu Sep 23 2004 Daniel Reed - 2.13-9 - rebuilt for dist-fc3 automake14-1.4p6-10 ------------------- * Thu Sep 23 2004 Daniel Reed - 1.4p6-10 - rebuilt for dist-fc3 automake15-1.5-11 ----------------- * Thu Sep 23 2004 Daniel Reed - 1.5-11 - rebuilt for dist-fc3 automake16-1.6.3-3 ------------------ * Thu Sep 23 2004 Daniel Reed - 1.6.3-3 - rebuilt for dist-fc3 automake17-1.7.9-3 ------------------ * Thu Sep 23 2004 Daniel Reed - 1.7.9-3 - rebuilt for dist-fc3 bash-3.0-15 ----------- * Fri Sep 24 2004 Tim Waugh 3.0-15 - Minor fix for job handling. * Mon Sep 13 2004 Tim Waugh - Add bashbug back in (with suffix). * Mon Sep 13 2004 Tim Waugh - Remove bash2. bind-9.2.4-1 ------------ * Thu Sep 23 2004 Jason Vas Dias - 20:9.2.4-1 - BIND 9.2.4 (final release) released - source code actually - identical to 9.2.4rc8, with only version number change. control-center-2.8.0-3 ---------------------- * Thu Sep 23 2004 Ray Strode - 1:2.8.0-3 - Require a working version of desktop-file-install * Thu Sep 23 2004 Ray Strode - 1:2.8.0-2 - add everything but Preferred Applications entry back to Preferences menu (woops) cups-1.1.21-2 ------------- * Thu Sep 23 2004 Tim Waugh 1:1.1.21-2 - 1.1.21. desktop-file-utils-0.8-4 ------------------------ * Thu Sep 23 2004 Ray Strode 0.8-4 - Fix the fix for --remove-show-in option * Thu Sep 23 2004 Ray Strode 0.8-3 - Fix --remove-show-in option desktop-printing-0.14-1 ----------------------- * Thu Sep 23 2004 Colin Walters 0.14-1 - Update to new upstream 0.14 + Try to re-set drivers on startup + Avoid multiple copies by using DBus activation dietlibc-0.27-2 --------------- * Thu Sep 23 2004 Jeremy Katz - 0.27-2 - support __nonnull attribute firstboot-1.3.26-1 ------------------ * Thu Sep 23 2004 Adrian Likins - 1.3.26-1 - applied patch from #132736 foomatic-3.0.2-1 ---------------- * Fri Sep 24 2004 Tim Waugh 3.0.2-1 - Updated filters to 3.0.2. - Updated db-engine to 3.0.2. - No longer need Omni PageSize patch or lvalue patch. gail-1.8.0-1 ------------ * Thu Sep 23 2004 Jonathan Blandford 1.8.0-1 - new release gpm-1.20.1-54 ------------- * Thu Sep 23 2004 Adrian Havill 1.20.1-54 - change init so that MOUSECFG fallsback to /etc/sysconfig/gpm if /etc/sysconfig/mouse doesn't exist (#133141) - fixed compile vs new kernheaders (#131783) * Tue May 04 2004 Adrian Havill 1.20.1-49 - remove superfluous "i die" msg (#121845) * Tue May 04 2004 Adrian Havill 1.20.1-48 - restore gpmopen() NULL check that was removed with the evdev superpatch (#118554) gtk2-2.4.10-4 ------------- * Thu Sep 23 2004 Matthias Clasen - 2.4.10-4 - Make arrows in path bar larger. * Wed Sep 22 2004 Matthias Clasen - 2.4.10-3 - Make SELECT_FOLDER work better in the file chooser. * Wed Sep 15 2004 Matthias Clasen - 2.4.10-2 - don't install .la files. (#132792) hal-0.2.98.cvs20040923-1 ------------------------ * Fri Sep 24 2004 David Zeuthen 0.2.98.cvs20040923-1 - Update to upstream CVS release - Include libhal-storage library - Should close bug #132876 hwbrowser-0.16-1 ---------------- * Thu Sep 23 2004 Nils Philippsen 0.16-1 - include updated translations (#133231) - appease make distcheck hwdata-0.135-1 -------------- * Thu Sep 23 2004 Bill Nottingham - 0.135-1 - megaraid -> megaraid_mbox intltool-0.31.2-1 ----------------- * Thu Sep 23 2004 Jonathan Blandford 0.31.2-1 - bump version kdegraphics-3.3.0-2 ------------------- * Thu Sep 23 2004 Than Ngo 7:3.3.0-2 - only show kcmkmrml in KDE - set variables before use kdenetwork-3.3.0-3 ------------------ * Thu Sep 23 2004 Than Ngo 7:3.3.0-3 - add OnlyShowIn=KDE * Thu Sep 16 2004 Than Ngo 3.3.0-2 - fix memmove warning in ksirc #132676 librsvg2-2.8.1-1 ---------------- * Thu Sep 23 2004 Alexander Larsson - 2.8.1-1 - update to 2.8.1 metacity-2.8.5-1 ---------------- * Thu Sep 23 2004 Alexander Larsson - 2.8.5-1 - update to 2.8.5 mod_auth_pgsql-2.0.1-6 ---------------------- * Thu Sep 23 2004 Joe Orton 2.0.1-5 - merge from Taroon: * don't re-use database connections (#115496) * make functions static * downgrade "not configured" log message from warning to debug nautilus-cd-burner-2.8.3-1 -------------------------- * Thu Sep 23 2004 Alexander Larsson - 2.8.3-1 - Upgrade to 2.8.3 to get rid of cvs backport patch netpbm-10.24-3 -------------- * Thu Sep 23 2004 Jindrich Novy 10.24-3 - added patch to suppress installation of doc.url to /usr/bin #133346 openoffice.org-1.1.2-5 ---------------------- * Mon Sep 20 2004 Dan Williams - 1.1.2-5 - Update to latest ooo-build CVS - Include WordPerfect filters (Writer Perfect module by Will L.) - Have to disable PPC builds for now due to GCC/toolchain bugs with -fPIC in compat-gcc Should fix: 126088 (Arabic fonts are not displayed correctly under ooo) 131660 (openoffice.org-kde contains files owned by bhcompile) 130131 (CAN-2004-0752 temporary file information leakage) 84777 (OpenOffice should provide basic templates) 132074 (calc now improperly imports xls spreadsheets) 129538 (OO Impress crashes when editing text) 129770 (OpenOffice crashes on copying spreadsheet cell) 130734 (oocalc segfaults when saving) 130216 (pt_BR locale not supported in OOo) 129087 (Tabs and buttons in dialogs flicker) 128709 (Syntax error in ooo-1.2 setup script) 129771 (Warnings from ooffice starting up) 130973 (OOo upgrade removes files in user ${HOME}) 132063 (reproducible segfault in oowriter) 131350 (openoffice.org 1.1.x should Obsolete: openoffice.org-style-gnome) 129459 (no german umlauts in staroffice) 129262 (The copy function (Ctrl-C) doesn't work in Calc) 127447 (ooffice hangs when printing to file or exporting to PDF) 129401 (Draw: Using Stylist (no individual styles, cpu load, flickering)) 126791 (Loading templates in OpenOffice.org Writer doesn't work) 126708 (pdf export problem with openoffice.org.i386 0:1.1.0-16) 126371 (openoffice send document as email does not attach document) 126149 (Can't see hebrew fonts in openoffice1.1.1) 124801 (Tab key in save document acts as Enter) 110689 (Unable to launch any OOo components after initial ws install with LANG=et_EE.UTF-8) 116176 (Czech localization is not included) 118508 (Open File Dialog broken) 132863 (Redlining crash in Writer) 123865 (Default font for zh_* locale) * Thu Sep 09 2004 Ray Strode 1.1.2-4 - Run update-desktop-database to register MIME type associations. openssl096b-0.9.6b-19 --------------------- * Mon Sep 20 2004 Mike McLean 0.9.6b-19 - rebuilt pam-0.77-59 ----------- * Thu Sep 23 2004 Phil Knirsch 0.77-59 - Fixed bug in pam_env where wrong initializer was used perl-URI-1.30-4 --------------- * Thu Sep 23 2004 Chip Turner 1.30-3 - rebuild * Wed Sep 22 2004 Chip Turner 1.30-2 - rebuild planner-0.12.1-1 ---------------- * Thu Sep 23 2004 Jonathan Blandford 0.12.1-1 - new version policycoreutils-1.17.5-4 ------------------------ * Thu Sep 23 2004 Dan Walsh 1.17.5-4 - Change to only display to terminal if tty is specified redhat-artwork-0.103-1 ---------------------- * Thu Sep 23 2004 Chris Lee - 0.103-1 - Fixes for the Qt style * Wed Sep 22 2004 Matthias Clasen - 0.102-1 - Improve drawing of expanders rhn-applet-2.1.11-1 ------------------- * Thu Sep 23 2004 Adrian Likins 2.1.11-1 - more content changes rpmdb-fedora-2.91-0.20040924 ---------------------------- selinux-policy-strict-1.17.20-3 ------------------------------- * Thu Sep 23 2004 Dan Walsh 1.17.20-3 - Apply Russell's patch * Thu Sep 23 2004 Dan Walsh 1.17.20-2 - Change nfs tunables into booleans for reading exported file systems * Thu Sep 23 2004 Dan Walsh 1.17.20-1 - Update with NSA fixes. selinux-policy-targeted-1.17.20-2 --------------------------------- * Thu Sep 23 2004 Dan Walsh 1.17.20-2 - Change nfs tunables into booleans for reading exported file systems * Thu Sep 23 2004 Dan Walsh 1.17.20-1 - Update with NSA fixes. spamassassin-3.0.0-1 -------------------- * Thu Sep 23 2004 Warren Togami - 3.0.0-1 - match upstream version - #133422 Future proof krb5 back compat (Milan Kerslager) subversion-1.0.8-2 ------------------ * Thu Sep 23 2004 Joe Orton 1.0.8-2 - update to 1.0.8 - remove -neonver patch - update psvn.el to 11062 system-config-packages-1.2.17-1 ------------------------------- * Thu Sep 23 2004 Jeremy Katz - 1.2.17-1 - use HAL for cd device discovery and locking - replace use of deprecated pygtk functions - remove OnlyShowIn from desktop file (#132804) - fix ftp tree for new rpm api (#133059) system-config-samba-1.2.16-1 ---------------------------- * Thu Sep 23 2004 Nils Philippsen - 1.2.16-1 - fix up translation of about window text (#133234) system-config-securitylevel-1.4.5-1 ----------------------------------- * Thu Sep 23 2004 Dan Walsh 1.4.5-1 - Fix for missing /etc/selinux system-config-services-0.8.8.1-1 -------------------------------- * Thu Sep 23 2004 Nils Philippsen - 0.8.8.1-1 - get in updated translations (#133137) - appease make distcheck - pick up updated autofoo scripts up2date-4.3.40-1 ---------------- * Thu Sep 23 2004 Adrian Likins 4.3.40 - various firstboot related fixes - add a button/dialog to configure proxy/serverURL - various firstboot content changes From leonard at den.ottolander.nl Fri Sep 24 13:14:22 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 24 Sep 2004 15:14:22 +0200 Subject: FC3 Bug Status - 2004-09-23 In-Reply-To: <20040924075619.GA5758@dudweiler.stuttgart.redhat.com> References: <20040923190038.GA9183@nostromo.devel.redhat.com> <1096010790.4780.1.camel@athlon.localdomain> <20040924075619.GA5758@dudweiler.stuttgart.redhat.com> Message-ID: <1096031662.4750.4.camel@athlon.localdomain> Hello Florian, On Fri, 2004-09-24 at 09:56, Florian La Roche wrote: > "need testing" percentage is part of the closed bugs. > So from the 43 closed bugs we have 9 which still need to be tested > to be sure the bugs are indeed fixed, that is 20.93% from the > 43 closed bugs. So people practice closing bugs before their solution is actually verified to be correct? I thought bugs should only be closed after the fix was verified and pushed. How are those "need testing" bugs tagged so they can be used in these stats? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From laroche at redhat.com Fri Sep 24 13:44:37 2004 From: laroche at redhat.com (Florian La Roche) Date: Fri, 24 Sep 2004 15:44:37 +0200 Subject: FC3 Bug Status - 2004-09-23 In-Reply-To: <1096031662.4750.4.camel@athlon.localdomain> References: <20040923190038.GA9183@nostromo.devel.redhat.com> <1096010790.4780.1.camel@athlon.localdomain> <20040924075619.GA5758@dudweiler.stuttgart.redhat.com> <1096031662.4750.4.camel@athlon.localdomain> Message-ID: <20040924134437.GA14756@dudweiler.stuttgart.redhat.com> On Fri, Sep 24, 2004 at 03:14:22PM +0200, Leonard den Ottolander wrote: > Hello Florian, > > On Fri, 2004-09-24 at 09:56, Florian La Roche wrote: > > "need testing" percentage is part of the closed bugs. > > So from the 43 closed bugs we have 9 which still need to be tested > > to be sure the bugs are indeed fixed, that is 20.93% from the > > 43 closed bugs. > > So people practice closing bugs before their solution is actually > verified to be correct? I thought bugs should only be closed after the > fix was verified and pushed. This is more complex. We certainly don't test for the development tree. > > How are those "need testing" bugs tagged so they can be used in these > stats? MODIFIED or CLOSED/QA_READY are two such states. From lfarkas at bppiac.hu Fri Sep 24 15:03:36 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 24 Sep 2004 17:03:36 +0200 Subject: why nss_ldap still use db-4.0? Message-ID: <41543748.6020704@bppiac.hu> hi, nss_ldap in the development dir still use db-4.0.14. is there any good reason for this? -- Levente "Si vis pacem para bellum!" From kyrre at solution-forge.net Fri Sep 24 15:21:33 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 24 Sep 2004 17:21:33 +0200 Subject: "Stateless Linux" project In-Reply-To: <41536EB2.6090006@carwyn.com> References: <1095100955.5481.14.camel@localhost.localdomain> <1095973336.11390.96.camel@localhost> <41535254.6060600@carwyn.com> <1095984561.10072.27.camel@localhost> <41536EB2.6090006@carwyn.com> Message-ID: <1096039292.2786.2.camel@kyrre> There is a smaller (smaller as in ca. one page of BASH code) project, which i personally use to keep my thick clients in shape. It relies on an initially identical installation, and should be relatively easy to extend. You may find it at: http://solution-forge.net/source/unprotected/admin-script/admin-script-final.tar.gz Kyrre fre, 24.09.2004 kl. 02.47 skrev Carwyn Edwards: > Josh England wrote: > > A configuration engine such as LCFG could peacefully coexist > > and from the sounds of it even complement the functionality provided by > > oneSIS. Instead of modifying the configs of remote files, it would > > simply be modifying the different variations of a file in the master > > image (ie: /etc/fstab.myclass). > > Yes this would be possible - LCFG doesn't care what the agents actually > do. We have ones that run as pseudo components on "network controller > hosts" that then talk to the switches/routers in whatever language they > talk. VLAN/routing config on the switches changes based on the client > host's profile (Yes it's scary). In theory you could also use it do > things like create and start/stop UML images that in turn used > LCFG/OneSiS inside the images. > > We've had experimental versions running on Windows and OS X too. > > Don't get me wrong, it's no silver bullet though. It has its flaws. > > People interested in this stuff might want to take a look at this: > > http://www.usenix.org/events/lisa04/ > > > Carwyn > From jgorny at aurox.org Fri Sep 24 15:57:30 2004 From: jgorny at aurox.org (Jaroslaw Gorny) Date: Fri, 24 Sep 2004 17:57:30 +0200 Subject: rawhide report: 20040917 changes In-Reply-To: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> References: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> Message-ID: <20040924175730.0c619bb9@pro8000x.aurox.org> On Fri, 17 Sep 2004 07:53:24 -0400 Build System wrote: > > dasher-3.2.11-3 > --------------- > * Tue Sep 14 2004 GNOME - 3.2.11-3 > > - fix schemas file and crasher. > Hmmm. It looks that not everything is ok. In *src.rpm there's a file: dasher.scheme It should be present in /etc/* but is not. The %post script tries to register this scheme, but reports error of course. BTW. how is it possible to buid an RPM package with unpackaged files? Always when I've got a wrong spec, rpmbuild finishes with sth. like "unpackaged files found..." and *.rpm is not created. Thanks, Jarek From arekm at pld-linux.org Fri Sep 24 16:18:39 2004 From: arekm at pld-linux.org (Arkadiusz Miskiewicz) Date: Fri, 24 Sep 2004 18:18:39 +0200 Subject: jabberd spec In-Reply-To: <1095939636.2898.7.camel@marte.biciclete.ro> References: <1095899455.4477.37.camel@nexus.verbum.private> <1095899349.26667.0.camel@binkley> <1095939636.2898.7.camel@marte.biciclete.ro> Message-ID: <200409241818.39645.arekm@pld-linux.org> On Thursday 23 of September 2004 13:40, Marius Andreiana wrote: > On Wed, 2004-09-22 at 20:29 -0400, seth vidal wrote: > > jabberd 2.0 has stopped development - the primary developer has gone > > away from it. Moreover it has pretty serious stability problems. > > Seth, what jabber server do you recommend? http://ejabberd.jabberstudio.org/, xmpp compilant (mostly) as webpage says, written in erlang. -- Arkadiusz Mi?kiewicz PLD/Linux Team http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/ From perbj at stanford.edu Fri Sep 24 16:30:30 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Fri, 24 Sep 2004 09:30:30 -0700 Subject: Unpackaged files in RPM In-Reply-To: <20040924175730.0c619bb9@pro8000x.aurox.org> References: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> <20040924175730.0c619bb9@pro8000x.aurox.org> Message-ID: <1096043430.2722.34.camel@localhost.localdomain> On Fri, 2004-09-24 at 08:57, Jaroslaw Gorny wrote: > BTW. how is it possible to buid an RPM package with unpackaged files? > Always when I've got a wrong spec, rpmbuild finishes with sth. like > "unpackaged files found..." and *.rpm is not created. That's a feature, not a bug! ;) http://www.rpm.org/hintskinks/unpackaged/ Leaving installed files unpackaged is often an indication that the packager screwed up so recent versions of rpmbuild (>= 4.1 I think) don't allow this by default. This is useful for finding packaging bugs. However, if you can't get past this and really, really want the package build to finish you can stick this in the spec file: %define _unpackaged_files_terminate_build 0 %define _missing_doc_files_terminate_build 0 But really, if there are no packaging bugs this just shouldn't be the case, so in the general case doing this is a really Bad Idea. (See Mike Harris's explanation in the link above.) /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From notting at redhat.com Fri Sep 24 17:03:35 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 24 Sep 2004 13:03:35 -0400 Subject: FC3 Bug Status - 2004-09-23 In-Reply-To: <1096031662.4750.4.camel@athlon.localdomain> References: <20040923190038.GA9183@nostromo.devel.redhat.com> <1096010790.4780.1.camel@athlon.localdomain> <20040924075619.GA5758@dudweiler.stuttgart.redhat.com> <1096031662.4750.4.camel@athlon.localdomain> Message-ID: <20040924170334.GA15999@nostromo.devel.redhat.com> Leonard den Ottolander (leonard at den.ottolander.nl) said: > > "need testing" percentage is part of the closed bugs. > > So from the 43 closed bugs we have 9 which still need to be tested > > to be sure the bugs are indeed fixed, that is 20.93% from the > > 43 closed bugs. > > So people practice closing bugs before their solution is actually > verified to be correct? I thought bugs should only be closed after the > fix was verified and pushed. > > How are those "need testing" bugs tagged so they can be used in these > stats? "Needs Testing" are bugs in MODIFIED state. Fixed/Closed includes CLOSED, RESOLVED, and MODIFIED. RESOLVED->NOTABUG and RESOLVED->DUPLICATE are dropped out of the stats entirely. Bill From erik at totalcirculation.com Fri Sep 24 17:12:43 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Fri, 24 Sep 2004 13:12:43 -0400 Subject: extras for RH9 / RHEL3 / CEntOS3 Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6591D975B@smith.interlink.local> I've been playing with CentOS 3.1 a bit recently since following fedora development on production servers is just more work than I have the time to do and RHEL sales doesn't seem to want to return my calls. In any case, I'd like to continue using packages from fedora.us. I've pointed yum at the redhat9 repo, and things seem to work mostly ok. But I have some questions. 1. Is an explicit RHEL extras repository planned? It seems like at least adding the keywords to bugzilla and the buildsystem would be a good goal. I see Dag Wieers is managing to do it. OTOH, the rh9 repo is pretty close to fully compatible. 2. Some packages for FC2 (amavisd comes to mind) have dependencies on packages that are not included in rh9 or rhel, but have been included in more recent (fc1, fc2) core revisions. Would it be appropriate to include them in extras, tagged for the os's which don't include them only? perl-MailTools and perl-TimeDate are a couple of the offending packages. There are also a few packages that are marked only for FC1 or FC2, but are working fine on centos. What is procedure for adding platforms to existing extras packages, file a bug against them? Thanks --erik From riel at redhat.com Fri Sep 24 19:27:12 2004 From: riel at redhat.com (Rik van Riel) Date: Fri, 24 Sep 2004 15:27:12 -0400 (EDT) Subject: FC3 Bug Week - HELP WANTED Message-ID: The Fedora Core 3 freeze is coming soon, so it's time again for the frantic activities of a Bug Week. This time with community participation. The idea is to fix as many bugs as possible in the week from Sunday, September 26th till Friday, October 1st. Yes, it starts this weekend... The goal of Bug Week is to fix as many of the annoying bugs out there as possible, so Fedora Core 3 ends up being a nice distribution without rough edges. We're going for quantity here, trying to fix all the easily fixable bugs that annoy users. Of course, if you have a fix for a harder to resolve problem, you're more than welcome to contribute it! Developers: you can help by fixing bugs and reviewing the proposed fixes that other people mail to the fedora-patches-list, or that get attached to bugzilla. Packaging bugs are another category where we can use your help. Testers: you can help by verifying whether old bugs are still present in rawhide, as well as by testing proposed fixes sent in by developers. Bug triagers: you can help by gathering information on NEEDINFO bugs, as well as by helping assess the importance of bugs. Everybody: this is a chance to get the bugs fixed that you care about! Developers from all engineering groups in Red Hat are standing by to fix bugs together with you, to apply submitted bug fixes and to make test RPMs available on the Bug Week repositories. To participate in Bug Week, you can use the normal channels of communication: - For discussion: fedora-devel-list, fedora-tools-list, fedora-test-list - For proposed patches: fedora-patches-list (so others have a chance of reviewing the proposed patches and verifying that they are ok) - For verified patches: bugzilla (to keep track of the patch) - IRC: #fedora-bugweek on irc.freenode.net If you want to nominate a bug for being fixed this Bug Week, please send an email to me (riel at redhat.com) and the owner of the bug that you want to nominate for the Bug Week must-fix list. Note that bugs will only be accepted for the Bug Week must-fix list if there is a realistic chance of fixing them this week. More information will be available soon, on: http://bugweek.fedora.redhat.com/ Developers, remember to subscribe to fedora-patches-list: http://www.redhat.com/mailman/listinfo/fedora-patches-list You can track our progress on the FC3 Bug Week Tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FC3BugWeekTracker From skvidal at phy.duke.edu Fri Sep 24 19:31:11 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 24 Sep 2004 15:31:11 -0400 Subject: FC3 Bug Week - HELP WANTED In-Reply-To: References: Message-ID: <1096054271.6256.2.camel@opus.phy.duke.edu> > Developers: you can help by fixing bugs and reviewing the proposed > fixes that other people mail to the fedora-patches-list, > or that get attached to bugzilla. Packaging bugs are > another category where we can use your help. > Testers: you can help by verifying whether old bugs are still present > in rawhide, as well as by testing proposed fixes sent in by > developers. > Bug triagers: you can help by gathering information on NEEDINFO bugs, as > well as by helping assess the importance of bugs. > Everybody: this is a chance to get the bugs fixed that you care about! > I hope that the bugs people will be filing will be BUGS and not RFEs. Bugweek should not be about ranting about your most desired feature. -sv From russell at coker.com.au Fri Sep 24 19:37:36 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 25 Sep 2004 05:37:36 +1000 Subject: sendmail, procmail, and SE Linux Message-ID: <200409250537.36121.russell@coker.com.au> avc: denied { read } for pid=10387 exe=/usr/bin/procmail path=/var/spool/mqueue/dfi8OJTVmq010385 dev=dm-2 ino=452872 scontext=system_u:system_r:procmail_t tcontext=system_u:object_r:mqueue_spool_t tclass=file I have done a fairly default install of FC3T2 and upgraded it to the latest rawhide and then installed the strict SE Linux policy. In terms of email configuration it's all default. I get the above AVC message when I run the command "ls | mail root", but the result seems to be OK (mail is delivered in /var/spool/mail and has the correct contents). Now I would like advice from someone who knows Sendmail well, is giving procmail an open file handle to a file under /var/spool/mqueue the right thing to do? IE is this a bug in sendmail or is there some good reason for allowing such access which only becomes apparent in usage scenarios different to mine? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From smoogen at lanl.gov Fri Sep 24 20:04:43 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Fri, 24 Sep 2004 14:04:43 -0600 Subject: FC3 Bug Week - HELP WANTED In-Reply-To: <1096054271.6256.2.camel@opus.phy.duke.edu> References: <1096054271.6256.2.camel@opus.phy.duke.edu> Message-ID: <41547DDB.4020909@lanl.gov> seth vidal wrote: >>Developers: you can help by fixing bugs and reviewing the proposed >> fixes that other people mail to the fedora-patches-list, >> or that get attached to bugzilla. Packaging bugs are >> another category where we can use your help. >>Testers: you can help by verifying whether old bugs are still present >> in rawhide, as well as by testing proposed fixes sent in by >> developers. >>Bug triagers: you can help by gathering information on NEEDINFO bugs, as >> well as by helping assess the importance of bugs. >>Everybody: this is a chance to get the bugs fixed that you care about! >> > > > I hope that the bugs people will be filing will be BUGS and not RFEs. > Bugweek should not be about ranting about your most desired feature. > Is having pam_krb5 not kill your login process when you have a local password and pam_krb5 is listed as optional... a bug or an RFE? > -sv > > > -- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen at lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 | From riel at redhat.com Fri Sep 24 20:12:00 2004 From: riel at redhat.com (Rik van Riel) Date: Fri, 24 Sep 2004 16:12:00 -0400 (EDT) Subject: FC3 Bug Week - HELP WANTED In-Reply-To: <41547DDB.4020909@lanl.gov> Message-ID: On Fri, 24 Sep 2004, Stephen J Smoogen wrote: > Is having pam_krb5 not kill your login process when you have a local > password and pam_krb5 is listed as optional... a bug or an RFE? Not sure. Nalin ? -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From sig at netdot.net Fri Sep 24 20:29:19 2004 From: sig at netdot.net (Aaron VanDevender) Date: Fri, 24 Sep 2004 15:29:19 -0500 Subject: USB Rescue Image Message-ID: <1096057759.3614.18.camel@vandvndr.physics.uiuc.edu> I would like to create a rescue image similar to rescue.iso, except formatted to go on a USB pen drive. I took all the files in the rescue.iso image and copied all of the files over to the pen drive. Then I reconfigured the isolinux part to use syslinux instead and installed syslinux on the drive. It seems simple enough, and it *almost* works. The drive boots, and asks for language and keyboard information but then asks for the location of the rescue image. I assume its looking for an iso-9660 filesystem where it can get the stage2.img ext2 filesytem which is to become the root filesystem during the rescue operation. Of course there is no rescue iso filesystem and giving it the location of the FAT filesystem with the same contents dosen't make it very happy. So what should I change to make it look for a FAT filesystem. I assume that it would be in the linuxrc executable in the initrd.img that gets loaded by syslinux, but I don't know where to look for the source for that. Any hints would be appreciated. cya .sig From nalin at redhat.com Fri Sep 24 20:32:01 2004 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 24 Sep 2004 16:32:01 -0400 Subject: FC3 Bug Week - HELP WANTED In-Reply-To: References: <41547DDB.4020909@lanl.gov> Message-ID: <20040924203200.GC7464@redhat.com> On Fri, Sep 24, 2004 at 04:12:00PM -0400, Rik van Riel wrote: > On Fri, 24 Sep 2004, Stephen J Smoogen wrote: > > > Is having pam_krb5 not kill your login process when you have a local > > password and pam_krb5 is listed as optional... a bug or an RFE? > > Not sure. Nalin ? In all seriousness, that depends on what you mean by "kill". Crash? Bug. Access denied? If it's a legitimate denial, not a bug because the alternative could be far worse. I did a spot-check with today's Raw Hide and 'login', and it worked for me (I had to give pam_unix the "use_first_pass" argument to avoid getting two password prompts), so please include as much about your configuration as you can. Nalin From mail.sw.rh.rhl.devel at spam.fi.basen.net Fri Sep 24 20:52:20 2004 From: mail.sw.rh.rhl.devel at spam.fi.basen.net (Kaj J.Niemi) Date: Fri, 24 Sep 2004 23:52:20 +0300 (EEST) Subject: rawhide report: 20040924 changes References: <200409241202.i8OC2KD27297@porkchop.devel.redhat.com> Message-ID: <20040924205220.A553E2F4175@Aurora.A51.ORG> > bind-9.2.4-1 > ------------ > * Thu Sep 23 2004 Jason Vas Dias - 20:9.2.4-1 > > - BIND 9.2.4 (final release) released - source code actually > - identical to 9.2.4rc8, with only version number change. How come the epoch on bind has increased from none set to 20 in less than two months? Are you using the epoch as a release number or what? I think I asked this earlier when it went from none set to 10. // kaj From smooge at gmail.com Fri Sep 24 21:07:56 2004 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 24 Sep 2004 15:07:56 -0600 Subject: FC3 Bug Week - HELP WANTED In-Reply-To: <20040924203200.GC7464@redhat.com> References: <41547DDB.4020909@lanl.gov> <20040924203200.GC7464@redhat.com> Message-ID: <80d7e409040924140771b319ed@mail.gmail.com> On Fri, 24 Sep 2004 16:32:01 -0400, Nalin Dahyabhai wrote: > On Fri, Sep 24, 2004 at 04:12:00PM -0400, Rik van Riel wrote: > > On Fri, 24 Sep 2004, Stephen J Smoogen wrote: > > > > > Is having pam_krb5 not kill your login process when you have a local > > > password and pam_krb5 is listed as optional... a bug or an RFE? > > > > Not sure. Nalin ? > > In all seriousness, that depends on what you mean by "kill". Crash? > Bug. Access denied? If it's a legitimate denial, not a bug because the > alternative could be far worse. > Ok the original bug was 79853. I dont remember closing it.. but it looks like I did. I also thought I answered Nalins question on that bug.. but I cant find that either.. my apologies Nalin. To give you an answer, I get a hang that does not return and login finally kills itself. What I have been trying to do is get our laptops set up so that they can get kerberos tickets if they are on the domain, and not to get them if they are not. The problem is currently most seen in #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account [default=bad success=ok user_unknown=ignore service_err=ignore syste m_err=ignore] /lib/security/$ISA/pam_krb5.so password required /lib/security/$ISA/pam_cracklib.so retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_krb5.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so When the laptop is plugged into the network and a local password is used the access occurs. When I unplug the box but move the settings to even optional.. it just sits for 2 minutes and login times out. This is really a RHEL-4/Fedora issue with us as it not working in RHEL-3 has been a 'reason to use something not so broken' as others have put it. I have been told that Fedora-Core Beta 2 is showing it too.. but I have to go through some paperwork to bring up a non-beta machine on our network. I will know on Monday. -- Stephen J Smoogen. Professional System Administrator From nalin at redhat.com Fri Sep 24 21:23:09 2004 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 24 Sep 2004 17:23:09 -0400 Subject: FC3 Bug Week - HELP WANTED In-Reply-To: <80d7e409040924140771b319ed@mail.gmail.com> References: <41547DDB.4020909@lanl.gov> <20040924203200.GC7464@redhat.com> <80d7e409040924140771b319ed@mail.gmail.com> Message-ID: <20040924212309.GF7464@redhat.com> On Fri, Sep 24, 2004 at 03:07:56PM -0600, Stephen J. Smoogen wrote: > On Fri, 24 Sep 2004 16:32:01 -0400, Nalin Dahyabhai wrote: > > On Fri, Sep 24, 2004 at 04:12:00PM -0400, Rik van Riel wrote: > > > On Fri, 24 Sep 2004, Stephen J Smoogen wrote: > > > > > > > Is having pam_krb5 not kill your login process when you have a local > > > > password and pam_krb5 is listed as optional... a bug or an RFE? > > > > > > Not sure. Nalin ? > > > > In all seriousness, that depends on what you mean by "kill". Crash? > > Bug. Access denied? If it's a legitimate denial, not a bug because the > > alternative could be far worse. > > Ok the original bug was 79853. I dont remember closing it.. but it > looks like I did. I also thought I answered Nalins question on that > bug.. but I cant find that either.. my apologies Nalin. No worries. It may have been happened in a private email, I think we've exchanged a few of those. > To give you an answer, I get a hang that does not return and login > finally kills itself. Given the configuration file you listed, I'd suspect a network timeout in the account management check (either attempting to resolve the KDC's host name, or in contacting the KDC). Disabling such a check adds the risk of not denying access to someone for whom access should be denied, so that's not something I can recommend as a general solution -- unlike the authentication check, where any module can give the user a thumbs-up, for account management you need for any module to be able to torpedo the user's login attempt. The timeouts in libkrb5 aren't adjustable, either, at least not if you're playing by the rules (and maybe not at all in 1.3 -- I last looked at this part of it in 1.2), so I don't really have a good answer for this problem. HTH, Nalin From xose at astures.jazztel.es Fri Sep 24 21:27:22 2004 From: xose at astures.jazztel.es (Xose Vazquez Perez) Date: Fri, 24 Sep 2004 23:27:22 +0200 Subject: extras for RH9 / RHEL3 / CEntOS Message-ID: <4154913A.5020705@astures.jazztel.es> Erik LaBianca wrote: > [...] > 1. Is an explicit RHEL extras repository planned? It seems like at least > [...] > 2. Some packages for FC2 (amavisd comes to mind) have dependencies on > packages that are not included in rh9 or rhel, but have been included in > [...] RHL 9 is maintained by fedoralegacy, and RHL 7.3 too. They are old technology ;-) [ http://fedoralegacy.org ] and *Fedora* is _only_ for *Fedora* not for Red_Hat_Enterprise_Linux. There are several projects(clones) for RHEL, try it in: TaoLinux [ http://www.taolinux.org ] White Box Linux [ http://whiteboxlinux.org ] cAos [ http://caosity.org ] Rocks [ http://www.rocksclusters.org/Rocks ] Fermi Linux LTS [ http://www-oss.fnal.gov/projects/fermilinux ] Lineox [ http://www.lineox.com ] regards, From nutello at sweetness.com Fri Sep 24 21:56:10 2004 From: nutello at sweetness.com (Rudi Chiarito) Date: Fri, 24 Sep 2004 23:56:10 +0200 Subject: Xinerama & tasklist Was: FC3 Bug Week - HELP WANTED In-Reply-To: <41547DDB.4020909@lanl.gov> References: <1096054271.6256.2.camel@opus.phy.duke.edu> <41547DDB.4020909@lanl.gov> Message-ID: <20040924215610.GB32353@server4.8080.it> On Fri, Sep 24, 2004 at 02:04:43PM -0600, Stephen J Smoogen wrote: > Is having pam_krb5 not kill your login process when you have a local > password and pam_krb5 is listed as optional... a bug or an RFE? In the same vein, is preventing the tasklist (wnck) from showing windows that are on other monitors a bug or an RFE? I could only find a report upstream - and it seems to be fixed in CVS for 2.8.1: http://bugzilla.gnome.org/show_bug.cgi?id=98698 The current behaviour can become truely unnerving. -- Rudi From jdennis at redhat.com Fri Sep 24 22:12:45 2004 From: jdennis at redhat.com (John Dennis) Date: Fri, 24 Sep 2004 18:12:45 -0400 Subject: Disconnect Login (Was: FC3 Bug Week - HELP WANTED) In-Reply-To: <80d7e409040924140771b319ed@mail.gmail.com> References: <41547DDB.4020909@lanl.gov> <20040924203200.GC7464@redhat.com> <80d7e409040924140771b319ed@mail.gmail.com> Message-ID: <1096063965.27301.33.camel@finch.boston.redhat.com> On Fri, 2004-09-24 at 17:07, Stephen J. Smoogen wrote: > What I have been trying to do is get our laptops set up so that they > can get kerberos tickets if they are on the domain, and not to get > them if they are not. The problem is currently most seen in > When the laptop is plugged into the network and a local password is > used the access occurs. When I unplug the box but move the settings to > even optional.. it just sits for 2 minutes and login times out. We added a new pam module in FC3 called pam_ccreds from PADL software. "CCreds" stands for "Cached Credentials". This may do what you want. The pam ccreds (Cached Credentials) is an optional pam module that would only be turned on by explicit root configuration. It works by caching in an encrypted form the credentials from a successful login. The encrypted cache is readable only by root making it equivalent to the shadow mechanism. The idea is that if an organization is using server based authentication (e.g. NIS or LDAP) and the user disconnects from his network he should still be able to login to his notebook. The cache is only consulted if a server based pam module reports its server is unavailable. If a server while connected ever reports a positive NAK on authentication the users cached credentials are immediately flushed, this means a user does not have unlimited future ability to authenticate if his privileges are revoked on his network. He can only authenticate while disconnected and only if the previous connected authentication was successful. This provides a good trade off between security and practical real world access for mobile users. There are few additional issues you will need to take into account: 1) authconfig needs to be patched to support ccreds, I don't think that patch made it into FC3. 2) User id information (e.g. nsswitch) still has to come from some place. If its currently network served you'll have problems. Rumor has it that FC3 picked up support for caching this, but at the immediate moment I'd don't have the details at my fingertips. 3) Home dirs will have to be local (we are in the process of adding support for home dir caching). 4) The network timeouts for the krb server won't occur if the network is turned off as opposed to unavailable (e.g. service network stop). There was a bug in the pam_krb5 which returned the wrong error code when the krb server was unavailable, it used to return "authentication failure" instead of the correct "server unavailable". That was fixed and I'm pretty sure is in FC3. -- John Dennis From smooge at gmail.com Fri Sep 24 22:19:48 2004 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 24 Sep 2004 16:19:48 -0600 Subject: FC3 Bug Week - HELP WANTED In-Reply-To: <80d7e409040924140771b319ed@mail.gmail.com> References: <41547DDB.4020909@lanl.gov> <20040924203200.GC7464@redhat.com> <80d7e409040924140771b319ed@mail.gmail.com> Message-ID: <80d7e40904092415196f8500dc@mail.gmail.com> Talked to Nalin off-line. This is definately an RFE because of the basic ideas behind kerberos account management. -- Stephen J Smoogen. Professional System Administrator From jdennis at redhat.com Fri Sep 24 22:20:37 2004 From: jdennis at redhat.com (John Dennis) Date: Fri, 24 Sep 2004 18:20:37 -0400 Subject: Disconnect Login (Was: FC3 Bug Week - HELP WANTED) In-Reply-To: <1096063965.27301.33.camel@finch.boston.redhat.com> References: <41547DDB.4020909@lanl.gov> <20040924203200.GC7464@redhat.com> <80d7e409040924140771b319ed@mail.gmail.com> <1096063965.27301.33.camel@finch.boston.redhat.com> Message-ID: <1096064436.27301.36.camel@finch.boston.redhat.com> On Fri, 2004-09-24 at 18:12, John Dennis wrote: > 2) User id information (e.g. nsswitch) still has to come from some > place. If its currently network served you'll have problems. Rumor has > it that FC3 picked up support for caching this, but at the immediate > moment I'd don't have the details at my fingertips. opps ... pardon me, not nsswitch, but rather nscd, and yes the caching support is in FC3. -- John Dennis From fedora at wir-sind-cool.org Fri Sep 24 23:30:05 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 25 Sep 2004 01:30:05 +0200 Subject: extras for RH9 / RHEL3 / CEntOS In-Reply-To: <4154913A.5020705@astures.jazztel.es> References: <4154913A.5020705@astures.jazztel.es> Message-ID: <20040925013005.417b25ec.fedora@wir-sind-cool.org> On Fri, 24 Sep 2004 23:27:22 +0200, Xose Vazquez Perez wrote: > Erik LaBianca wrote: > > > [...] > > 1. Is an explicit RHEL extras repository planned? It seems like at least > > [...] > > 2. Some packages for FC2 (amavisd comes to mind) have dependencies on > > packages that are not included in rh9 or rhel, but have been included in > > [...] > > RHL 9 is maintained by fedoralegacy, and RHL 7.3 too. They are old > technology ;-) > > [ http://fedoralegacy.org ] > > and *Fedora* is _only_ for *Fedora* not for Red_Hat_Enterprise_Linux. Well, that's not entirely correct. Erik referred to Fedora.us (http://fedora.us -- previously known as Fedora Linux), which had started as an add-on packages project for Red Hat Linux and later has continued to release extras for Fedora Core. Fedora.us still releases updated extra packages for Red Hat Linux 9 and 8.0. Theoretically, it would be possible to also prepare and build the extra packages for Red Hat Enterprise Linux. But that has been--and still is--beyond the scope and infrastructure of Fedora.us. First of all, it would need a build system which can build for Red Hat Enterprise Linux, possibly 2.1 and 3. Second, it would need packagers who are interested in creating unsupported extra packages for Red Hat Enterprise Linux and, btw, maintaining them and possibly doing security fixes for a period of seven years. With Fedora.us moving into Fedora Extras, activity at fedora.us will fade away and probably focus on continuing to release updates for extra packages for Red Hat Linux 9 and 8.0. Probably just 9, as I think with no Fedora Legacy support for 8.0, fedora.us should announce extras-end-of-life for 8.0, too. > There are several projects(clones) for RHEL, try it in: Yes, and I think besides Dag Wieers, one or a few of those projects also build extra packages. -- Fedora Core release 2 (Tettnang) - Linux 2.6.7-1.494.2.2 loadavg: 1.00 1.03 1.00 From rjune at bravegnuworld.com Sat Sep 25 05:14:33 2004 From: rjune at bravegnuworld.com (Richard June) Date: Sat, 25 Sep 2004 00:14:33 -0500 Subject: jabberd spec In-Reply-To: <1095900998.26667.5.camel@binkley> References: <1095899455.4477.37.camel@nexus.verbum.private> <200409221956.53209.rjune@bravegnuworld.com> <1095900998.26667.5.camel@binkley> Message-ID: <200409250014.36734.rjune@bravegnuworld.com> You got the PAM module for jabber? have you had any problems with it? -- Public Key available Here: http://www.bravegnuworld.com/~rjune/rjune.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kyrre at solution-forge.net Sat Sep 25 13:01:59 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 25 Sep 2004 15:01:59 +0200 Subject: FC3 and printing from Mozilla Message-ID: <1096117319.2720.5.camel@kyrre> Will there be a real print dialog (one which do allow you to select printers) in FC3? - it is no such thing (as far as i can see - i havent ran yum update due to that i am on an ISDN dialup, and the volume is... enormous) in test 2, but ive heard some rumours of it in desktop-list. Not having support for multiple printers (unless you know the syntax of lpr) is really a huge handicap for end-user-friendlyness IMO Kyrre From mgarski at post.pl Sat Sep 25 14:56:46 2004 From: mgarski at post.pl (Marcin Garski) Date: Sat, 25 Sep 2004 16:56:46 +0200 Subject: FC3 and printing from Mozilla In-Reply-To: <1096117319.2720.5.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> Message-ID: <200409251656.46676.mgarski@post.pl> On Saturday 25 September 2004 15:01, Kyrre Ness Sjobak wrote: > Will there be a real print dialog (one which do allow you to select > printers) in FC3? - it is no such thing (as far as i can see - i > havent ran yum update due to that i am on an ISDN dialup, and the > volume is... enormous) in test 2, but ive heard some rumours of it in > desktop-list. > > Not having support for multiple printers (unless you know the syntax > of lpr) is really a huge handicap for end-user-friendlyness IMO You can change "Print command" in "Print Properties" from: lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME} to: kprinter Then if you click print a KPrinter dialog appear when you could have/set multiple printers, etc. I know it's some kind of workaround, but the best I know. You could also do the same in Adobe Reader. -- Best Regards Marcin Garski From kyrre at solution-forge.net Sat Sep 25 15:03:16 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 25 Sep 2004 17:03:16 +0200 Subject: FC3 and printing from Mozilla In-Reply-To: <200409251656.46676.mgarski@post.pl> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> Message-ID: <1096124596.2720.11.camel@kyrre> I know about that little dirty trick, but it seems like a problem to me when the standard browsing app can't handle more that one printer. Even gedit does that! Is it possible to make epiphany, firefox and mozilla to skip the first dialog, and go straigth to kprinter? Or would that imply a dependency on KDE? There must be some way to solve this... Kyrre l?r, 25.09.2004 kl. 16.56 skrev Marcin Garski: > On Saturday 25 September 2004 15:01, Kyrre Ness Sjobak wrote: > > Will there be a real print dialog (one which do allow you to select > > printers) in FC3? - it is no such thing (as far as i can see - i > > havent ran yum update due to that i am on an ISDN dialup, and the > > volume is... enormous) in test 2, but ive heard some rumours of it in > > desktop-list. > > > > Not having support for multiple printers (unless you know the syntax > > of lpr) is really a huge handicap for end-user-friendlyness IMO > > You can change "Print command" in "Print Properties" from: > lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME} > to: > kprinter > > Then if you click print a KPrinter dialog appear when you could have/set > multiple printers, etc. > > I know it's some kind of workaround, but the best I know. > You could also do the same in Adobe Reader. From walters at redhat.com Sat Sep 25 15:11:10 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 25 Sep 2004 11:11:10 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096124596.2720.11.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> Message-ID: <1096125070.4478.25.camel@nexus.verbum.private> On Sat, 2004-09-25 at 17:03 +0200, Kyrre Ness Sjobak wrote: > I know about that little dirty trick, but it seems like a problem to me > when the standard browsing app can't handle more that one printer. Even > gedit does that! > > Is it possible to make epiphany, firefox and mozilla to skip the first > dialog, and go straigth to kprinter? Or would that imply a dependency on > KDE? The right way is to make mozilla and family use the native print dialog, for which work is still in progress. Not sure if it will make FC3 or not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kyrre at solution-forge.net Sat Sep 25 15:11:13 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 25 Sep 2004 17:11:13 +0200 Subject: FC3 and printing from Mozilla In-Reply-To: <1096125070.4478.25.camel@nexus.verbum.private> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096125070.4478.25.camel@nexus.verbum.private> Message-ID: <1096125073.2720.14.camel@kyrre> Im not a great coder, but if there is anything i could do to help, please say so. The current state is horrendous, and even a hackishly assaoult would be better. Kyrre l?r, 25.09.2004 kl. 17.11 skrev Colin Walters: > On Sat, 2004-09-25 at 17:03 +0200, Kyrre Ness Sjobak wrote: > > I know about that little dirty trick, but it seems like a problem to me > > when the standard browsing app can't handle more that one printer. Even > > gedit does that! > > > > Is it possible to make epiphany, firefox and mozilla to skip the first > > dialog, and go straigth to kprinter? Or would that imply a dependency on > > KDE? > > The right way is to make mozilla and family use the native print dialog, > for which work is still in progress. Not sure if it will make FC3 or > not. > > > ______________________________________________________________________ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From linux_4ever at yahoo.com Sat Sep 25 13:27:48 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 25 Sep 2004 06:27:48 -0700 (PDT) Subject: FC3 Bug Week - HELP WANTED In-Reply-To: <1096095017.17155.0.camel@laptop.fenrus.com> Message-ID: <20040925132749.43314.qmail@web50604.mail.yahoo.com> Hi, This is similar to what I was wanting: These block FC3 from being released ("most wanted"): https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=130887 These are annoyances that need fixing but at a lower priority: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=123268 It would be nice if these were listed on the bugweek status page for ease of use. These links give the problem summary and a hyperlink to the detailed report. -Steve Grubb _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From russell at coker.com.au Sat Sep 25 15:15:45 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 26 Sep 2004 01:15:45 +1000 Subject: rc.sysinit creating device nodes Message-ID: <200409260115.45710.russell@coker.com.au> echo mkdmnod | /sbin/nash rc.sysinit runs the above command to create /dev/mapper/control. Now that we have udev managing /dev we have no need to have nash do that. Is it time to remove that line from rc.sysinit? I ask because it requires undesirable access to be granted in the SE Linux policy. Also in rc.sysinit we have "echo raidautorun /dev/md0 | nash", but in that case /dev/md0 does not already exist. Can we change things such that udev creates /dev/md0? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From johnp at redhat.com Sat Sep 25 15:18:12 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Sat, 25 Sep 2004 11:18:12 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096125070.4478.25.camel@nexus.verbum.private> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096125070.4478.25.camel@nexus.verbum.private> Message-ID: <1096125491.25333.39.camel@localhost.localdomain> On Sat, 2004-09-25 at 11:11, Colin Walters wrote: > On Sat, 2004-09-25 at 17:03 +0200, Kyrre Ness Sjobak wrote: > > I know about that little dirty trick, but it seems like a problem to me > > when the standard browsing app can't handle more that one printer. Even > > gedit does that! > > > > Is it possible to make epiphany, firefox and mozilla to skip the first > > dialog, and go straigth to kprinter? Or would that imply a dependency on > > KDE? > > The right way is to make mozilla and family use the native print dialog, > for which work is still in progress. Not sure if it will make FC3 or > not. > > > ______________________________________________________________________ I think Chris Allon is working on getting support for the gnome print dialog in Mozilla. The file dialog is there and I think he said that the print dialog was on his hit list. -- J5 From dhollis at davehollis.com Sat Sep 25 15:52:36 2004 From: dhollis at davehollis.com (David Hollis) Date: Sat, 25 Sep 2004 11:52:36 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096124596.2720.11.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> Message-ID: <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> On Sat, 2004-09-25 at 17:03 +0200, Kyrre Ness Sjobak wrote: > I know about that little dirty trick, but it seems like a problem to me > when the standard browsing app can't handle more that one printer. Even > gedit does that! > > Is it possible to make epiphany, firefox and mozilla to skip the first > dialog, and go straigth to kprinter? Or would that imply a dependency on > KDE? > > There must be some way to solve this... > It seems to work fine for me in Firefox. I get a dropdown of my available printers and I can select which one I want to print to. -- David Hollis From kyrre at solution-forge.net Sat Sep 25 16:02:17 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 25 Sep 2004 18:02:17 +0200 Subject: FC3 and printing from Mozilla In-Reply-To: <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> Message-ID: <1096128136.2720.19.camel@kyrre> Strange - i don't. In firefox, i get exactly the same print-dialog as in mozilla. The firefox that is delivered with fc3t2, that is - even if i must admit that i have not ran "yum update" due to the enormous volume + i am on a ISDN dialup line... Chris Allon? Who is that? AFIK, this should be a blocker, or at least a target. *goes to enter it into bugzilla, if its not allready there* Kyrre l?r, 25.09.2004 kl. 17.52 skrev David Hollis: > On Sat, 2004-09-25 at 17:03 +0200, Kyrre Ness Sjobak wrote: > > I know about that little dirty trick, but it seems like a problem to me > > when the standard browsing app can't handle more that one printer. Even > > gedit does that! > > > > Is it possible to make epiphany, firefox and mozilla to skip the first > > dialog, and go straigth to kprinter? Or would that imply a dependency on > > KDE? > > > > There must be some way to solve this... > > > It seems to work fine for me in Firefox. I get a dropdown of my > available printers and I can select which one I want to print to. > > -- > David Hollis > From kyrre at solution-forge.net Sat Sep 25 16:25:27 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 25 Sep 2004 18:25:27 +0200 Subject: FC3 and printing from Mozilla In-Reply-To: <1096128136.2720.19.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> Message-ID: <1096129527.2720.21.camel@kyrre> Bugzilla entry: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133645 l?r, 25.09.2004 kl. 18.02 skrev Kyrre Ness Sjobak: > Strange - i don't. In firefox, i get exactly the same print-dialog as in > mozilla. The firefox that is delivered with fc3t2, that is - even if i > must admit that i have not ran "yum update" due to the enormous volume + > i am on a ISDN dialup line... > > Chris Allon? Who is that? > > AFIK, this should be a blocker, or at least a target. > > *goes to enter it into bugzilla, if its not allready there* > > Kyrre > > l?r, 25.09.2004 kl. 17.52 skrev David Hollis: > > On Sat, 2004-09-25 at 17:03 +0200, Kyrre Ness Sjobak wrote: > > > I know about that little dirty trick, but it seems like a problem to me > > > when the standard browsing app can't handle more that one printer. Even > > > gedit does that! > > > > > > Is it possible to make epiphany, firefox and mozilla to skip the first > > > dialog, and go straigth to kprinter? Or would that imply a dependency on > > > KDE? > > > > > > There must be some way to solve this... > > > > > It seems to work fine for me in Firefox. I get a dropdown of my > > available printers and I can select which one I want to print to. > > > > -- > > David Hollis > > > From feliciano.matias at free.fr Sat Sep 25 17:14:52 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sat, 25 Sep 2004 19:14:52 +0200 Subject: rc.sysinit creating device nodes In-Reply-To: <200409260115.45710.russell@coker.com.au> References: <200409260115.45710.russell@coker.com.au> Message-ID: <1096132482.3819.88.camel@localhost.localdomain> Le sam 25/09/2004 ? 17:15, Russell Coker a ?crit : > echo mkdmnod | /sbin/nash > > rc.sysinit runs the above command to create /dev/mapper/control. Now that we > have udev managing /dev we have no need to have nash do that. > > Is it time to remove that line from rc.sysinit? I ask because it requires > undesirable access to be granted in the SE Linux policy. > > > Also in rc.sysinit we have "echo raidautorun /dev/md0 | nash", but in that > case /dev/md0 does not already exist. Can we change things such that udev > creates /dev/md0? > Sorry for my poor English. There is no more /etc/raidtab (raidtools package) in FC3. in rc.sysinit : update_boot_stage RCraid if [ -f /etc/raidtab ]; then (~85 lines) fi Bugzilla ? "somewhere" at boot time, /dev/loop[0-7] are created even if loop module is not loaded. it's weird. Example here : # grep loop /proc/modules (loop not loaded) # grep loop /etc/modprobe.conf options loop max-loop=32 # cd /dev # ls loop* | wc -w 8 # modprobe loop # ls loop* | wc -w 32 # rmmod loop # ls loop* | wc -w ls: loop*: No such file or directory 0 Bugzilla ? As far as I understand udev, only udev can "touch" /dev. The user "populate" /dev with modprobe or hotplug. This depends on his hardware and need. kudzu, do a part of that jobs. I think it's time to provide a way to preload modules (ala Mandrake). Perhaps /etc/sysconfig/preload_modules with : loop dm-mod rtc third-party driver unknown by kudzu etc... btw, I would like to know what append with /etc/security/console.perms . I'll give you a "real" example : I built a custom kernel (I have a binary-only module that don't like CONFIG_REGPARM). As usual when i build a custom kernel, ide_cd is a module. grubby .... reboot .... I connect to the system and try "mount /mnt/cdrom" : mount: only root can mount /dev/cdrom on /mnt/cdrom Normal, ide_cd is not automagically loaded as with a static /dev. "su -l -c 'modprobe ide_cd'" . New try "mount /mnt/cdrom/" : mount: only root can mount /dev/cdrom on /mnt/cdrom Permissions and owner should be set according to /etc/udev/permissions.d/ _and_ /etc/security/console.perms . I know that hal/g-v-m can do the trick. But what can do hal for rtc (use by mplayer) for example ? This is my rtc part in console.perms : =/dev/rtc 0600 0600 root With a static /dev this work even if the modules is not already loaded. I am sure we will see other problems of that kind... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From zcerza at redhat.com Sat Sep 25 17:29:22 2004 From: zcerza at redhat.com (Zack Cerza) Date: Sat, 25 Sep 2004 13:29:22 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096128136.2720.19.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> Message-ID: <1096133362.10453.22.camel@localhost> On Sat, 2004-09-25 at 18:02 +0200, Kyrre Ness Sjobak wrote: > Strange - i don't. In firefox, i get exactly the same print-dialog as > in > mozilla. The firefox that is delivered with fc3t2, that is - even if i > must admit that i have not ran "yum update" due to the enormous volume > + > i am on a ISDN dialup line... eew, evolution wrapped the quoted text above horribly. I hope it's only on my end. > Chris Allon? Who is that? Chris Aillon is one of our Mozilla hackers. J5 dropped the 'i' :) > AFIK, this should be a blocker, or at least a target. Hard to say, as it seems like an RFE and not a 'real' bug - that doesn't mean I don't hate having to use 2 different browsers [0] on my Fedora desktop because of various bugs. > *goes to enter it into bugzilla, if its not allready there* I found your report and added it to the FC3 Desktop target bug [1] which is aliased 'YellowPad'. Here's the state of printing in GNOME-y browsers. I'm pasting this here and in your report [2] for some odd reason. firefox-0.10.0-1.0PR1.0 has a nice dropdown listing all my network printers now. mozilla-1.7.2-0.3.0 has a dropdown but only 'Postscript/default' is listed. epiphany-1.3.8-0.3.1 still has the field with 'lpr.cups' in it - useless to me. [0] Firefox for browsing and printing (before we shipped it, it was konqueror) and epiphany for those times when I'd clicked an https link in something like evolution. The URL handlers are a little borked: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109738 [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131589 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133645 Zack From johnp at redhat.com Sat Sep 25 17:36:11 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Sat, 25 Sep 2004 13:36:11 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096133362.10453.22.camel@localhost> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> <1096133362.10453.22.camel@localhost> Message-ID: <1096133771.25998.1.camel@localhost.localdomain> On Sat, 2004-09-25 at 13:29, Zack Cerza wrote: > On Sat, 2004-09-25 at 18:02 +0200, Kyrre Ness Sjobak wrote: > > Strange - i don't. In firefox, i get exactly the same print-dialog as > > in > > mozilla. The firefox that is delivered with fc3t2, that is - even if i > > must admit that i have not ran "yum update" due to the enormous volume > > + > > i am on a ISDN dialup line... > eew, evolution wrapped the quoted text above horribly. I hope it's only on my end. > > > Chris Allon? Who is that? > Chris Aillon is one of our Mozilla hackers. J5 dropped the 'i' :) Hey there is no "I" in Team. Umm, ya, ok. Sorry Chris ;) -- J5 From walters at redhat.com Sat Sep 25 17:42:43 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 25 Sep 2004 13:42:43 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096133362.10453.22.camel@localhost> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> <1096133362.10453.22.camel@localhost> Message-ID: <1096134163.4452.34.camel@nexus.verbum.private> On Sat, 2004-09-25 at 13:29 -0400, Zack Cerza wrote: > > *goes to enter it into bugzilla, if its not allready there* > I found your report and added it to the FC3 Desktop target bug [1] which > is aliased 'YellowPad'. We decided the YellowPad bug is only for bugs that, to quote Havoc, "we will be here until 3am fixing if it isn't done the day before the deadline". I don't think we can classify changing Mozilla's print dialog as one of those, unless Chris is already very close to finishing it. Bugs that are "would be nice but not critical" should go on FC3Target. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From zcerza at redhat.com Sat Sep 25 17:55:00 2004 From: zcerza at redhat.com (Zack Cerza) Date: Sat, 25 Sep 2004 13:55:00 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096134163.4452.34.camel@nexus.verbum.private> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> <1096133362.10453.22.camel@localhost> <1096134163.4452.34.camel@nexus.verbum.private> Message-ID: <1096134900.10453.28.camel@localhost> On Sat, 2004-09-25 at 13:42 -0400, Colin Walters wrote: > On Sat, 2004-09-25 at 13:29 -0400, Zack Cerza wrote: > > > > *goes to enter it into bugzilla, if its not allready there* > > I found your report and added it to the FC3 Desktop target bug [1] which > > is aliased 'YellowPad'. > > We decided the YellowPad bug is only for bugs that, to quote Havoc, "we > will be here until 3am fixing if it isn't done the day before the > deadline". I don't think we can classify changing Mozilla's print > dialog as one of those, unless Chris is already very close to finishing > it. Oh. Re-assigned. I was under the impression it just the desktop target bug; I've been wrongly tacking tons of bugs onto YellowPad, I guess. D'oh. > Bugs that are "would be nice but not critical" should go on FC3Target. In fact I wasn't even aware of 'FC3Target'. :( Zack From kyrre at solution-forge.net Sat Sep 25 18:41:05 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 25 Sep 2004 20:41:05 +0200 Subject: FC3 and printing from Mozilla In-Reply-To: <1096134900.10453.28.camel@localhost> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> <1096133362.10453.22.camel@localhost> <1096134163.4452.34.camel@nexus.verbum.private> <1096134900.10453.28.camel@localhost> Message-ID: <1096137665.4176.4.camel@kyrre> Shouldt fixing somthing like proper printer support in the main browser be something flagged as important? If this also goes into RHEL, that could be bad. Not mentioning that a number of schools etc. does use fedora, and they probably have more than one printer. It is indeed a little dull printing a more or less confidential document to the wrong site due to it is not possible to select where it is going to come out... So really - mozillas print dialog is quite important, even if it might not seem like it. Kyrre l?r, 25.09.2004 kl. 19.55 skrev Zack Cerza: > On Sat, 2004-09-25 at 13:42 -0400, Colin Walters wrote: > > On Sat, 2004-09-25 at 13:29 -0400, Zack Cerza wrote: > > > > > > *goes to enter it into bugzilla, if its not allready there* > > > I found your report and added it to the FC3 Desktop target bug [1] which > > > is aliased 'YellowPad'. > > > > We decided the YellowPad bug is only for bugs that, to quote Havoc, "we > > will be here until 3am fixing if it isn't done the day before the > > deadline". I don't think we can classify changing Mozilla's print > > dialog as one of those, unless Chris is already very close to finishing > > it. > Oh. Re-assigned. I was under the impression it just the desktop target > bug; I've been wrongly tacking tons of bugs onto YellowPad, I guess. > D'oh. > > > Bugs that are "would be nice but not critical" should go on FC3Target. > In fact I wasn't even aware of 'FC3Target'. :( > > Zack > From walters at redhat.com Sat Sep 25 18:53:20 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 25 Sep 2004 14:53:20 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096137665.4176.4.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> <1096133362.10453.22.camel@localhost> <1096134163.4452.34.camel@nexus.verbum.private> <1096134900.10453.28.camel@localhost> <1096137665.4176.4.camel@kyrre> Message-ID: <1096138400.4452.51.camel@nexus.verbum.private> On Sat, 2004-09-25 at 20:41 +0200, Kyrre Ness Sjobak wrote: > So really - mozillas print dialog is quite important, even if it might > not seem like it. I absolutely agree it's important. Not being on YellowPad doesn't mean it's not important, it just means that it's not realistic to be able to fix it before the FC3 release. We should absolutely shoot for getting this fixed for FC4, maybe even a FC3 update. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Sat Sep 25 18:55:51 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 25 Sep 2004 14:55:51 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096134163.4452.34.camel@nexus.verbum.private> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> <1096133362.10453.22.camel@localhost> <1096134163.4452.34.camel@nexus.verbum.private> Message-ID: <1096138551.4452.54.camel@nexus.verbum.private> On Sat, 2004-09-25 at 13:42 -0400, Colin Walters wrote: > On Sat, 2004-09-25 at 13:29 -0400, Zack Cerza wrote: > > > > *goes to enter it into bugzilla, if its not allready there* > > I found your report and added it to the FC3 Desktop target bug [1] which > > is aliased 'YellowPad'. > > We decided the YellowPad bug is only for bugs that, to quote Havoc, "we > will be here until 3am fixing if it isn't done the day before the > deadline". I don't think we can classify changing Mozilla's print > dialog as one of those, unless Chris is already very close to finishing > it. > > Bugs that are "would be nice but not critical" should go on FC3Target. This was a bad phrasing. Bugs that are somewhat realistic to get fixed for FC3 but aren't absolutely critical should go on FC3Target. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kyrre at solution-forge.net Sat Sep 25 18:57:19 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 25 Sep 2004 20:57:19 +0200 Subject: FC3 and printing from Mozilla In-Reply-To: <1096138400.4452.51.camel@nexus.verbum.private> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> <1096133362.10453.22.camel@localhost> <1096134163.4452.34.camel@nexus.verbum.private> <1096134900.10453.28.camel@localhost> <1096137665.4176.4.camel@kyrre> <1096138400.4452.51.camel@nexus.verbum.private> Message-ID: <1096138639.4176.7.camel@kyrre> Okay, so where is it? Target? Blocker? Where? First you say that it is realistical to have it in ordnung by FC3, then "we should try to get it in before fc4"? *confused* Kyrre l?r, 25.09.2004 kl. 20.53 skrev Colin Walters: > On Sat, 2004-09-25 at 20:41 +0200, Kyrre Ness Sjobak wrote: > > > So really - mozillas print dialog is quite important, even if it might > > not seem like it. > > I absolutely agree it's important. Not being on YellowPad doesn't mean > it's not important, it just means that it's not realistic to be able to > fix it before the FC3 release. > > We should absolutely shoot for getting this fixed for FC4, maybe even a > FC3 update. > > > > ______________________________________________________________________ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From kyrre at solution-forge.net Sat Sep 25 19:24:02 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 25 Sep 2004 21:24:02 +0200 Subject: Which component is buggy when dns isn't working right? Message-ID: <1096140241.4176.21.camel@kyrre> I have always before been able to run dnsmasq on my smoothwall, and if i then put a host in its /etc/hosts, all (Linux - it has never worked for my fathers laptop, so he has to use ip adresses...) computers wich use that as a dns-server will get it. F.ex. i have a host called "kyrre". If i want cups to be able to print to the printer shared on that machine, i have to have a dns lookup for "kyrre" - either on the local /ets/hosts, or in DNS. So the smoothwalls hosts file look like this: 127.0.0.1 localhost 192.168.0.1 smoothwall 192.168.0.200 kyrre And it works great. On all my fc2 (and earlier) linux-computers, i am able to f.ex type "ssh kyrre", and it looks up kyrre from dns, dnsmasq on the smoothwall reads the hosts file on the smoothwall, and returns "192.168.0.200". And i am able to start my evolution over encrypted X, or print my document (much printing today :-) ) from the laptop. But with fc3t2, which has a hosts and resolve file which are identical to the fc2 laptops, this dont work. That means - "host kyrre" returns the correct IP, but "ssh kyrre" or printing on kyrre dont work (acctually, hitting "print test page" in the cups web-interfafe just gives me a google seach for "kyrre"). I would call this a bug. But where should i post it? Which component does handle DNS lookups? Kyrre From qralston+ml.redhat-fedora-devel at andrew.cmu.edu Sat Sep 25 19:43:20 2004 From: qralston+ml.redhat-fedora-devel at andrew.cmu.edu (James Ralston) Date: Sat, 25 Sep 2004 15:43:20 -0400 Subject: upgrade to bind 9.3.0 for FC3? Message-ID: <837BAE52D5268618D4437339@shieldbreaker.l33tskillz.org> Or at least in development, maybe? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133654 -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From kyrre at solution-forge.net Sat Sep 25 19:49:57 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 25 Sep 2004 21:49:57 +0200 Subject: Maching paper size with locale Message-ID: <1096141797.4176.30.camel@kyrre> Just being curious - why is not the default paper size matched with what is most common in the country you select in timezone setup? Ex. in Norway, Letter is something only known from the "select paper size" in printer drivers - A4 is the _only_ format used. And as default paper setting in many programs - such as firefox - while ex. OpenOffice uses A4. Why is there no common setting of this - one file where all programs read what the standard papersize/orientation etc should be? Having it wrong is bad, but inconsistent is almost worse... Kyrre From drepper at redhat.com Sat Sep 25 19:57:04 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 25 Sep 2004 12:57:04 -0700 Subject: Maching paper size with locale In-Reply-To: <1096141797.4176.30.camel@kyrre> References: <1096141797.4176.30.camel@kyrre> Message-ID: <4155CD90.30208@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kyrre Ness Sjobak wrote: > Why is there no common setting of this - one file where all programs > read what the standard papersize/orientation etc should be? There is, the paper size information is part of the locale. It's just that not all programs use that information. And of course they can only use those values for an initial setup. I.e., firefox could only use the information when it creates a new profile. The setting in existing profiles must be accepted. If you find a program not respecting the information in the initial setup, file a bug for that program. Point to the LC_PAPER locale category. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD4DBQFBVc2Q2ijCOnn/RHQRAkTcAJ0Zfp5bDsus1Uv9DtyZnZYqfCcrjwCVGlqB iR233l0JZDN4FuEpEaOXBw== =IgE7 -----END PGP SIGNATURE----- From walters at redhat.com Sat Sep 25 20:20:47 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 25 Sep 2004 16:20:47 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096138639.4176.7.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> <1096133362.10453.22.camel@localhost> <1096134163.4452.34.camel@nexus.verbum.private> <1096134900.10453.28.camel@localhost> <1096137665.4176.4.camel@kyrre> <1096138400.4452.51.camel@nexus.verbum.private> <1096138639.4176.7.camel@kyrre> Message-ID: <1096143647.4452.66.camel@nexus.verbum.private> On Sat, 2004-09-25 at 20:57 +0200, Kyrre Ness Sjobak wrote: > Okay, so where is it? Target? Blocker? Where? It's not tracked at the moment, but once we get a FC4 blocker we could nominate it. > First you say that it is realistical to have it in ordnung by FC3, then > "we should try to get it in before fc4"? I was saying (from my current knowledge, Chris will know more) that it doesn't seem realistic to do for FC3, and therefore shouldn't be YellowPad or FC3Target. Again, not having the bug blocking a tracker bug doesn't mean it's not important. Really it's a feature. It would be nice if we had a "feature" tracking system for Fedora that this could be filed under. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Sat Sep 25 21:09:42 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 25 Sep 2004 23:09:42 +0200 Subject: [bugweek] A script to detect -mtune=i386 libraries Message-ID: <1096146582.17155.14.camel@laptop.fenrus.com> Hi, in theory we compile all of fedora core with -mtune=i686 (or -mtune=pentium4 nowadays). however that only actually happens if packages propagate the RPM_OPT_FLAGS into the CFLAGS properly; almost all but not quite not all packages actually do this. The script at can be used to check if a shared libary is compiled with -mtune=i386 or -mtune=i686. If it detects i386 then most likely there is a packaging bug with not propagating the compiler flags properly. Usage is like this: objdump -d sharelibraryfilename.so | perl detecti686.pl known bugs: If a shared library is really small with say only 1 function, it is possible that the heuristics fail. Greetings, Arjan van de Ven -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Sat Sep 25 21:14:09 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 25 Sep 2004 23:14:09 +0200 Subject: [bugweek] A script to detect -mtune=i386 libraries In-Reply-To: <1096146582.17155.14.camel@laptop.fenrus.com> References: <1096146582.17155.14.camel@laptop.fenrus.com> Message-ID: <1096146849.17155.16.camel@laptop.fenrus.com> > The script at > can be used to check if a shared libary is compiled with -mtune=i386 or and evil evolution ate my email. the script is at http://people.redhat.com/arjanv/detecti686.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hp at redhat.com Sat Sep 25 23:17:09 2004 From: hp at redhat.com (Havoc Pennington) Date: Sat, 25 Sep 2004 19:17:09 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096137665.4176.4.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> <1096133362.10453.22.camel@localhost> <1096134163.4452.34.camel@nexus.verbum.private> <1096134900.10453.28.camel@localhost> <1096137665.4176.4.camel@kyrre> Message-ID: <1096154230.13448.19.camel@localhost.localdomain> On Sat, 2004-09-25 at 20:41 +0200, Kyrre Ness Sjobak wrote: > Shouldt fixing somthing like proper printer support in the main browser > be something flagged as important? If this also goes into RHEL, that > could be bad. > > Not mentioning that a number of schools etc. does use fedora, and they > probably have more than one printer. It is indeed a little dull printing > a more or less confidential document to the wrong site due to it is not > possible to select where it is going to come out... > > So really - mozillas print dialog is quite important, even if it might > not seem like it. > We agree, but basically what happened is that there was wave after wave of Mozilla security errata, which doomed caillon to working on that instead of the print dialog. So, it may have to get postponed. Havoc From alan at redhat.com Sun Sep 26 00:09:00 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 25 Sep 2004 20:09:00 -0400 Subject: [bugweek] A script to detect -mtune=i386 libraries In-Reply-To: <1096146582.17155.14.camel@laptop.fenrus.com> References: <1096146582.17155.14.camel@laptop.fenrus.com> Message-ID: <20040926000900.GP25483@devserv.devel.redhat.com> On Sat, Sep 25, 2004 at 11:09:42PM +0200, Arjan van de Ven wrote: > in theory we compile all of fedora core with -mtune=i686 (or > -mtune=pentium4 nowadays). however that only actually happens if > packages propagate the RPM_OPT_FLAGS into the CFLAGS properly; almost > all but not quite not all packages actually do this. I noticed a curiosity playing with this that perhaps the gcc folks can explain the right choice for - on Dothan -mtune=i686 is a lot faster than tuning for pentium4. From felipe_alfaro at linuxmail.org Sun Sep 26 00:22:40 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sun, 26 Sep 2004 02:22:40 +0200 Subject: Which component is buggy when dns isn't working right? In-Reply-To: <1096140241.4176.21.camel@kyrre> References: <1096140241.4176.21.camel@kyrre> Message-ID: <2D3FFC24-0F52-11D9-9CAA-000D9352858E@linuxmail.org> On Sep 25, 2004, at 21:24, Kyrre Ness Sjobak wrote: > I have always before been able to run dnsmasq on my smoothwall, and if > i > then put a host in its /etc/hosts, all (Linux - it has never worked for > my fathers laptop, so he has to use ip adresses...) computers wich use > that as a dns-server will get it. > > F.ex. i have a host called "kyrre". If i want cups to be able to print > to the printer shared on that machine, i have to have a dns lookup for > "kyrre" - either on the local /ets/hosts, or in DNS. So the smoothwalls > hosts file look like this: > > 127.0.0.1 localhost > 192.168.0.1 smoothwall > 192.168.0.200 kyrre > > And it works great. On all my fc2 (and earlier) linux-computers, i am > able to f.ex type "ssh kyrre", and it looks up kyrre from dns, dnsmasq > on the smoothwall reads the hosts file on the smoothwall, and returns > "192.168.0.200". And i am able to start my evolution over encrypted X, > or print my document (much printing today :-) ) from the laptop. > > But with fc3t2, which has a hosts and resolve file which are identical > to the fc2 laptops, this dont work. That means - "host kyrre" returns > the correct IP, but "ssh kyrre" or printing on kyrre dont work > (acctually, hitting "print test page" in the cups web-interfafe just > gives me a google seach for "kyrre"). > > I would call this a bug. But where should i post it? Which component > does handle DNS lookups? One note: "host" does _not_ use the resolver library (which is part of glibc). Instead, "host" queries any configured DNS server directly, that is, "host" will _never_ look up "/etc/hosts", but instead performs lookup against the configured DNS servers. However, "ssh", "ping" and family _do_ use the resolver. Thus, normal tools use the resolver. Thus bugs depending on the resolver should go against "glibc". However, "host" is part of "bind-tools". From mandreiana at rdslink.ro Sun Sep 26 08:14:03 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Sun, 26 Sep 2004 11:14:03 +0300 Subject: Rant on LABELs In-Reply-To: References: Message-ID: <1096186444.3062.4.camel@marte.biciclete.ro> On Sat, 2004-09-25 at 16:06 +0100, Timothy Murphy wrote: > Just got caught again by this LABEL nonsense. > I was mounting my laptop hard disk on my desktop - > both running Fedora- > and the whole thing was thrown into confusion > because there were two partitions LABELed "/", > on my desktop hard disk and on the laptop hard disk. > > I had to start again in single mode, > and change all the entries in /etc/fstab and /etc/grub.conf . That's a common problem when adding hdd's with other fedora installs. How about generating a random integer at install time, and use it to label partitions like /_5643 /home_5643 /boot_5643 ... and reference these in fstab / grub.conf? Could this create problems? -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From nphilipp at redhat.com Sun Sep 26 10:48:15 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Sun, 26 Sep 2004 12:48:15 +0200 Subject: Rant on LABELs In-Reply-To: <1096186444.3062.4.camel@marte.biciclete.ro> References: <1096186444.3062.4.camel@marte.biciclete.ro> Message-ID: <1096195694.25963.12.camel@gibraltar.stuttgart.redhat.com> On Sun, 2004-09-26 at 10:14, Marius Andreiana wrote: > On Sat, 2004-09-25 at 16:06 +0100, Timothy Murphy wrote: > > Just got caught again by this LABEL nonsense. > > I was mounting my laptop hard disk on my desktop - > > both running Fedora- > > and the whole thing was thrown into confusion > > because there were two partitions LABELed "/", > > on my desktop hard disk and on the laptop hard disk. > > > > I had to start again in single mode, > > and change all the entries in /etc/fstab and /etc/grub.conf . > That's a common problem when adding hdd's with other fedora installs. > > How about generating a random integer at install time, and use it to > label partitions like > /_5643 > /home_5643 > /boot_5643 > ... > and reference these in fstab / grub.conf? Could this create problems? Well, volume labels can only be 16 characters long on ext2/ext3 filesystems which basically clashes with the requirement that you'd need to ensure that the random number would be virtually unique which means long numbers ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From dhollis at davehollis.com Sun Sep 26 11:41:49 2004 From: dhollis at davehollis.com (David Hollis) Date: Sun, 26 Sep 2004 07:41:49 -0400 Subject: Rant on LABELs In-Reply-To: <1096186444.3062.4.camel@marte.biciclete.ro> References: <1096186444.3062.4.camel@marte.biciclete.ro> Message-ID: <1096198909.12047.2.camel@dhollis-lnx.centricconsulting.com> On Sun, 2004-09-26 at 11:14 +0300, Marius Andreiana wrote: > On Sat, 2004-09-25 at 16:06 +0100, Timothy Murphy wrote: > > Just got caught again by this LABEL nonsense. > > I was mounting my laptop hard disk on my desktop - > > both running Fedora- > > and the whole thing was thrown into confusion > > because there were two partitions LABELed "/", > > on my desktop hard disk and on the laptop hard disk. > > > > I had to start again in single mode, > > and change all the entries in /etc/fstab and /etc/grub.conf . > That's a common problem when adding hdd's with other fedora installs. > > How about generating a random integer at install time, and use it to > label partitions like > /_5643 > /home_5643 > /boot_5643 > ... > and reference these in fstab / grub.conf? Could this create problems? > > I think this would largely remove any of the benefits of labeling. Yes, if you have two partitions labeled "/" or "/boot", you get conflicts. This is expected and the sysadmin should be aware of this, boot into single user and re-label one of the partitions to something else. Thats just how life goes. In other cases, it's a beautiful thing. Now I don't have to remember if it's /dev/hda2, /dev/sdc5, or whatever, it's just LABEL=/. -- David Hollis From russell at coker.com.au Sun Sep 26 11:47:53 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 26 Sep 2004 21:47:53 +1000 Subject: fsck.ext3 on bootup In-Reply-To: <4c4ba15304092421194618e27f@mail.gmail.com> References: <4149DA4C.6030409@comcast.net> <200409250220.15285.russell@coker.com.au> <4c4ba15304092421194618e27f@mail.gmail.com> Message-ID: <200409262147.53832.russell@coker.com.au> On Sat, 25 Sep 2004 14:19, Tom London wrote: > OK. I made a new initrd using mkinitrd-4.1.12-1, rebooted, but the > result is the same. > > Sorry.... Anything else I can try? It seems that a device node /dev/root is created when you boot from a non-LVM device. This is probably a bug in the boot scripts which may tie in with the following bugzilla (about root= parameter being ignored in the case of LVM systems). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133236 Anyway I have attached a policy patch that will work around the SE Linux aspects of this issue. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-diff Size: 588 bytes Desc: not available URL: From dwmw2 at infradead.org Sun Sep 26 11:45:27 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 26 Sep 2004 12:45:27 +0100 Subject: Rant on LABELs In-Reply-To: <1096198909.12047.2.camel@dhollis-lnx.centricconsulting.com> References: <1096186444.3062.4.camel@marte.biciclete.ro> <1096198909.12047.2.camel@dhollis-lnx.centricconsulting.com> Message-ID: <1096199128.5048.6.camel@localhost.localdomain> On Sun, 2004-09-26 at 07:41 -0400, David Hollis wrote: > I think this would largely remove any of the benefits of labeling. Yes, > if you have two partitions labeled "/" or "/boot", you get conflicts. There are benefits of labelling? Maybe on big systems with lots of SCSI devices which get moved around, but I've only ever seen it cause problems on most of the desktop and laptop machines I've used. One of the first things I do after an install, just after disabling kudzu, is to turn off mount-by-label. > This is expected and the sysadmin should be aware of this, boot into > single user and re-label one of the partitions to something else. Thats > just how life goes. In other cases, it's a beautiful thing. Now I > don't have to remember if it's /dev/hda2, /dev/sdc5, or whatever, it's > just LABEL=/. Personally I find /etc/yaboot.conf remembers that for me quite effectively. :) -- dwmw2 From buytenh at wantstofly.org Sun Sep 26 11:56:16 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Sun, 26 Sep 2004 13:56:16 +0200 Subject: Rant on LABELs In-Reply-To: <1096199128.5048.6.camel@localhost.localdomain> References: <1096186444.3062.4.camel@marte.biciclete.ro> <1096198909.12047.2.camel@dhollis-lnx.centricconsulting.com> <1096199128.5048.6.camel@localhost.localdomain> Message-ID: <20040926115616.GA16046@xi.wantstofly.org> On Sun, Sep 26, 2004 at 12:45:27PM +0100, David Woodhouse wrote: > There are benefits of labelling? Maybe on big systems with lots of SCSI > devices which get moved around, It's useful for me on a box that has two dozen USB disks attached to it, since the disk-to-device-node mapping changes on every boot for USB (and IIRC also for firewire) disks, and each disk has its own filesystem. Yeah, that's pretty much the only case where it has benefits. --L From arjanv at redhat.com Sun Sep 26 12:08:54 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 26 Sep 2004 14:08:54 +0200 Subject: Rant on LABELs In-Reply-To: <1096195694.25963.12.camel@gibraltar.stuttgart.redhat.com> References: <1096186444.3062.4.camel@marte.biciclete.ro> <1096195694.25963.12.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1096200533.2804.3.camel@laptop.fenrus.com> > to ensure that the random number would be virtually unique which means > long numbers ;-). well but ext2/3 do have UUID's; there's no reason we can't do mount-by-UUID as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mgarski at post.pl Sun Sep 26 14:23:02 2004 From: mgarski at post.pl (Marcin Garski) Date: Sun, 26 Sep 2004 16:23:02 +0200 Subject: Polishing Fedora's specs In-Reply-To: <41528F00.2020105@redhat.com> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> <41517FE4.7070404@post.pl> <20040922135509.GA27560@dudweiler.stuttgart.redhat.com> <4151B8F8.8080407@post.pl> <41528F00.2020105@redhat.com> Message-ID: <4156D0C6.303@post.pl> Harald Hoyer wrote: >>I don't have diffs for specs. I do all my tasks in HTML table. >>I think that mixture of both are at one side better, because as I see >>I'll have to fil about 500 bugs :). Do you want that ;) ? >> >>Also I've already fil this kind of bugs, and had quite different replays. >>At one side very good, but at other eg. #131846 it wasn't so kind :/ >>Beside still in development tree xerces-j is in old version and probably >>was in FC2. > > > > Do you have your data in a parsable format? If yes, send it to me, I'll > try to automate the bugzilla creation process with perl or python... What format would you like? Name URL Source If example "URL" is correct then it will be # at the beginning. Name # Source -- Best Regards Marcin Garski From ggw at wolves.durham.nc.us Sun Sep 26 15:14:51 2004 From: ggw at wolves.durham.nc.us (Gregory Woodbury) Date: Sun, 26 Sep 2004 11:14:51 -0400 Subject: Build system hung up? Message-ID: <20040926151451.GA18990@wolves.durham.nc.us> We haven't had any rawhide reports for a day or two now. Is the build system hung up again? Is there a URL for checking the status of the build system? -- G.Wolfe Woodbury `- -' RHCT U The Line Eater is a boojum! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kyrre at solution-forge.net Sun Sep 26 15:19:42 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 26 Sep 2004 17:19:42 +0200 Subject: [bugweek] A script to detect -mtune=i386 libraries In-Reply-To: <20040926000900.GP25483@devserv.devel.redhat.com> References: <1096146582.17155.14.camel@laptop.fenrus.com> <20040926000900.GP25483@devserv.devel.redhat.com> Message-ID: <1096211981.2691.11.camel@kyrre> Am i the only guy here who's running Fedora on pentium 3's? What about AMD folks? Or those who simply wants to use their old pentium 1's to run some sort of httpd, ftpd or simply a sshd for irissi etc? Yes, optimization is great, but don't leave people unable to use your distro. Hmm... Make separate i686 and i386 optimized ISO's? Kyrre s?n, 26.09.2004 kl. 02.09 skrev Alan Cox: > On Sat, Sep 25, 2004 at 11:09:42PM +0200, Arjan van de Ven wrote: > > in theory we compile all of fedora core with -mtune=i686 (or > > -mtune=pentium4 nowadays). however that only actually happens if > > packages propagate the RPM_OPT_FLAGS into the CFLAGS properly; almost > > all but not quite not all packages actually do this. > > I noticed a curiosity playing with this that perhaps the gcc folks can > explain the right choice for - on Dothan -mtune=i686 is a lot faster than > tuning for pentium4. > From walters at redhat.com Sun Sep 26 15:28:39 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 26 Sep 2004 11:28:39 -0400 Subject: [bugweek] A script to detect -mtune=i386 libraries In-Reply-To: <1096211981.2691.11.camel@kyrre> References: <1096146582.17155.14.camel@laptop.fenrus.com> <20040926000900.GP25483@devserv.devel.redhat.com> <1096211981.2691.11.camel@kyrre> Message-ID: <1096212519.4452.163.camel@nexus.verbum.private> On Sun, 2004-09-26 at 17:19 +0200, Kyrre Ness Sjobak wrote: > Am i the only guy here who's running Fedora on pentium 3's? What about > AMD folks? Or those who simply wants to use their old pentium 1's to run > some sort of httpd, ftpd or simply a sshd for irissi etc? > > Yes, optimization is great, but don't leave people unable to use your > distro. This has been discussed innumerable times here and on other mailing lists. Executive summary: -mtune=i686 doesn't make you unable to run these binaries on i586 or below, it just makes it "tuned" for i686, hence the name. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kyrre at solution-forge.net Sun Sep 26 15:35:45 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 26 Sep 2004 17:35:45 +0200 Subject: Which component is buggy when dns isn't working right? In-Reply-To: <2D3FFC24-0F52-11D9-9CAA-000D9352858E@linuxmail.org> References: <1096140241.4176.21.camel@kyrre> <2D3FFC24-0F52-11D9-9CAA-000D9352858E@linuxmail.org> Message-ID: <1096212944.2691.30.camel@kyrre> s?n, 26.09.2004 kl. 02.22 skrev Felipe Alfaro Solana: > On Sep 25, 2004, at 21:24, Kyrre Ness Sjobak wrote: > > > I have always before been able to run dnsmasq on my smoothwall, and if > > i > > then put a host in its /etc/hosts, all (Linux - it has never worked for > > my fathers laptop, so he has to use ip adresses...) computers wich use > > that as a dns-server will get it. > > > > F.ex. i have a host called "kyrre". If i want cups to be able to print > > to the printer shared on that machine, i have to have a dns lookup for > > "kyrre" - either on the local /ets/hosts, or in DNS. So the smoothwalls > > hosts file look like this: > > > > 127.0.0.1 localhost > > 192.168.0.1 smoothwall > > 192.168.0.200 kyrre > > > > And it works great. On all my fc2 (and earlier) linux-computers, i am > > able to f.ex type "ssh kyrre", and it looks up kyrre from dns, dnsmasq > > on the smoothwall reads the hosts file on the smoothwall, and returns > > "192.168.0.200". And i am able to start my evolution over encrypted X, > > or print my document (much printing today :-) ) from the laptop. > > > > But with fc3t2, which has a hosts and resolve file which are identical > > to the fc2 laptops, this dont work. That means - "host kyrre" returns > > the correct IP, but "ssh kyrre" or printing on kyrre dont work > > (acctually, hitting "print test page" in the cups web-interfafe just > > gives me a google seach for "kyrre"). > > > > I would call this a bug. But where should i post it? Which component > > does handle DNS lookups? > > One note: "host" does _not_ use the resolver library (which is part of > glibc). Instead, "host" queries any configured DNS server directly, > that is, "host" will _never_ look up "/etc/hosts", but instead performs > lookup against the configured DNS servers. However, "ssh", "ping" and > family _do_ use the resolver. > > Thus, normal tools use the resolver. Thus bugs depending on the > resolver should go against "glibc". However, "host" is part of > "bind-tools". > I know that host has its own resolver - and it works (eg. no firewall issues etc.) I go file a bug against glibc: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133645 Thanks. Kyrre From alan at redhat.com Sun Sep 26 16:05:16 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 26 Sep 2004 12:05:16 -0400 Subject: [bugweek] A script to detect -mtune=i386 libraries In-Reply-To: <1096211981.2691.11.camel@kyrre> References: <1096146582.17155.14.camel@laptop.fenrus.com> <20040926000900.GP25483@devserv.devel.redhat.com> <1096211981.2691.11.camel@kyrre> Message-ID: <20040926160516.GK18568@devserv.devel.redhat.com> On Sun, Sep 26, 2004 at 05:19:42PM +0200, Kyrre Ness Sjobak wrote: > Am i the only guy here who's running Fedora on pentium 3's? What about > AMD folks? Or those who simply wants to use their old pentium 1's to run > some sort of httpd, ftpd or simply a sshd for irissi etc? The benches seem to show that Athlons really don't care too much what you feed them, pentium i would beefit a tiny bit, most others are in the noise. If you want to rebuild an FC3 for pentium I go ahead. Mach should be able to build all the bits for you. From kyrre at solution-forge.net Sun Sep 26 16:14:44 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 26 Sep 2004 18:14:44 +0200 Subject: [bugweek] A script to detect -mtune=i386 libraries In-Reply-To: <20040926160516.GK18568@devserv.devel.redhat.com> References: <1096146582.17155.14.camel@laptop.fenrus.com> <20040926000900.GP25483@devserv.devel.redhat.com> <1096211981.2691.11.camel@kyrre> <20040926160516.GK18568@devserv.devel.redhat.com> Message-ID: <1096215283.2691.56.camel@kyrre> s?n, 26.09.2004 kl. 18.05 skrev Alan Cox: > On Sun, Sep 26, 2004 at 05:19:42PM +0200, Kyrre Ness Sjobak wrote: > > Am i the only guy here who's running Fedora on pentium 3's? What about > > AMD folks? Or those who simply wants to use their old pentium 1's to run > > some sort of httpd, ftpd or simply a sshd for irissi etc? > > The benches seem to show that Athlons really don't care too much what you > feed them, pentium i would beefit a tiny bit, most others are in the noise. > > If you want to rebuild an FC3 for pentium I go ahead. Mach should be able > to build all the bits for you. > ISDN + my thrusty old pentium3 650 mhz of which looses power if online after 23:00 (due to my techo-fobic mother...)? No thanks ;) From b.j.smith at ieee.org Sun Sep 26 18:10:16 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Sun, 26 Sep 2004 14:10:16 -0400 Subject: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support) Message-ID: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> Is there a document or page that details all of the changes in how recent Fedora Core kernels are built? I've noticed several changes, and I want to verify I understand them all. I apologize as I've seen some traffic, but I can't seem to find a definite answer (I'm sure I just passed over it). Specifically: 1. The "sourcecode" package, which is now ARCH="noarch" Assumption: I assume the package name change was because the ARCH has changed. Additional Q: Why is the "sourcecode" package not built by default when "--target=noarch" is passed? I.e., %ifarch noarch %define builddoc 1 %define buildsource 0 ^^^ 2. There is another variable in EXTRAVERSIONS, defaults to "root" Assumption: I assume this is to differentiate between UML (User Mode Linux) kernels (so the same build system can be used)? Additional Q: Is this a stock kernel change? Or Red Hat only? 3. Athlon no longer a build option at all in the SPEC file Assumption: Are there support issues with this? Or was it another reasoning?** Additional Q: Is there any reason why we can't "patch back in" just the few changes into the SPEC so one can build Athlon kernels easily with "--target=athlon"? [ **BTW, I'm fully aware that the i686 kernel runs fairly optimized on Athlon. But turning off the generic support, and optimizing for K7 makes a significant difference for me in engineering applications. ] Also, to add in Athlon support, you don't have to make it part of the "all_x86" set. In fact, I made Athlon a separate build conditional on its own in my own spec file (for 2.6.8-1.541) here (along with a few other changes): http://www.vaporwarelabs.com/files/temp/kernel-2.6.8-1.541BS.spec And for those that want to build Athlon optimized kernels, the .config files are here: http://www.vaporwarelabs.com/files/temp/kernel-2.6.8-athlon.config http://www.vaporwarelabs.com/files/temp/kernel-2.6.8-athlon-smp.config -- Bryan J. Smith b.j.smith at ieee.org ------------------------------------------------------------------ "Communities don't have rights. Only individuals in the community have rights. ... That idea of community rights is firmly rooted in the 'Communist Manifesto.'" -- Michael Badnarik From cra at WPI.EDU Sun Sep 26 18:18:09 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sun, 26 Sep 2004 14:18:09 -0400 Subject: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support) In-Reply-To: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> References: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> Message-ID: <20040926181809.GD24689@angus.ind.WPI.EDU> On Sun, Sep 26, 2004 at 02:10:16PM -0400, Bryan J. Smith wrote: > 1. The "sourcecode" package, which is now ARCH="noarch" > I assume the package name change was because the ARCH has changed. Yes. > Why is the "sourcecode" package not built by default when > "--target=noarch" is passed? I.e., There is no need to duplicate the files derivable from the src.rpm in another package. Kernel modules can now be built with just the kernel package. There is no need to have the kernel-sourcecode package to build kernel modules. > 2. There is another variable in EXTRAVERSIONS, defaults to "root" > I assume this is to differentiate between UML (User Mode Linux) > kernels (so the same build system can be used)? > Is this a stock kernel change? Or Red Hat only? I don't know this one. > 3. Athlon no longer a build option at all in the SPEC file > Are there support issues with this? Or was it another reasoning?** The reason is the one you give below: > [ **BTW, I'm fully aware that the i686 kernel runs fairly optimized on > Athlon. > But turning off the generic support, and optimizing for K7 > makes a significant difference for me in engineering applications. ] How significant? Is this something most users are going to notice in their use of the system? From buytenh at wantstofly.org Sun Sep 26 18:23:47 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Sun, 26 Sep 2004 20:23:47 +0200 Subject: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support) In-Reply-To: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> References: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> Message-ID: <20040926182347.GB19060@xi.wantstofly.org> On Sun, Sep 26, 2004 at 02:10:16PM -0400, Bryan J. Smith wrote: > 2. There is another variable in EXTRAVERSIONS, defaults to "root" I assume to distinguish Red Hat-blessed kernels from home-built kernels. There's a comment in the spec file indicating something along those lines: # # Polite request for people who spin their own kernel rpms: # please modify the "release" field in a way that identifies # that the kernel isn't the stock distribution kernel, for example by # adding some text to the end of the version number. # [...] %define rhbsys %([ -r /etc/beehive-root ] && echo || echo .`whoami`) %define release %(R="$Revision: 1.339 $"; RR="${R##: }"; echo ${RR%%?})%{rhbsys} --L From alexander.dalloz at uni-bielefeld.de Sun Sep 26 18:28:59 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Sun, 26 Sep 2004 20:28:59 +0200 Subject: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support) In-Reply-To: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> References: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> Message-ID: <1096223339.22484.24.camel@serendipity.dogma.lan> Am So, den 26.09.2004 schrieb Bryan J. Smith um 20:10: > Is there a document or page that details all of the changes in how > recent Fedora Core kernels are built? I've noticed several changes, and > I want to verify I understand them all. I apologize as I've seen some > traffic, but I can't seem to find a definite answer (I'm sure I just > passed over it). > Additional Q: > Why is the "sourcecode" package not built by default when > "--target=noarch" is passed? I.e., > %ifarch noarch > %define builddoc 1 > %define buildsource 0 > Bryan J. Smith b.j.smith at ieee.org You are not speaking about current FC2 kernels. 2.6.8-1.541 is the current development kernel. The topic about a separate kernel-sourcecode "missing" has been discussed to extend on the development / test list. And Arjan recently posted a short instruction on how to rpmbuild the kernel source rpm from the src.rpm. As this is not topic for the stable FC list you should look at the other lists mentioned. Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp Serendipity 20:24:49 up 5 days, 22:28, load average: 1.92, 1.58, 1.34 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From alexander.dalloz at uni-bielefeld.de Sun Sep 26 18:42:15 2004 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Sun, 26 Sep 2004 20:42:15 +0200 Subject: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support) In-Reply-To: <1096223339.22484.24.camel@serendipity.dogma.lan> References: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> <1096223339.22484.24.camel@serendipity.dogma.lan> Message-ID: <1096224135.22484.39.camel@serendipity.dogma.lan> Am So, den 26.09.2004 schrieb Alexander Dalloz um 20:28: > > Is there a document or page that details all of the changes in how > > recent Fedora Core kernels are built? I've noticed several changes, and > > I want to verify I understand them all. I apologize as I've seen some > > traffic, but I can't seem to find a definite answer (I'm sure I just > > passed over it). > > > Additional Q: > > Why is the "sourcecode" package not built by default when > > "--target=noarch" is passed? I.e., > > %ifarch noarch > > %define builddoc 1 > > %define buildsource 0 > > > Bryan J. Smith b.j.smith at ieee.org > > You are not speaking about current FC2 kernels. 2.6.8-1.541 is the > current development kernel. The topic about a separate kernel-sourcecode > "missing" has been discussed to extend on the development / test list. > And Arjan recently posted a short instruction on how to rpmbuild the > kernel source rpm from the src.rpm. As this is not topic for the stable > FC list you should look at the other lists mentioned. > > Alexander Sorry, this should have gone to the fedora-list at redhat.com list, but the OP managed to puzzle the reply-to address to be this devel list while the posting went to the fedora-list at redhat.com list. Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp Serendipity 20:40:29 up 5 days, 22:44, load average: 1.32, 1.43, 1.34 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From arjanv at redhat.com Sun Sep 26 19:24:39 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 26 Sep 2004 21:24:39 +0200 Subject: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support) In-Reply-To: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> References: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> Message-ID: <1096226679.14655.3.camel@laptop.fenrus.com> On Sun, 2004-09-26 at 20:10, Bryan J. Smith wrote: > 1. The "sourcecode" package, which is now ARCH="noarch" > > Assumption: > I assume the package name change was because the ARCH has changed. correct; this was during a fc2 update > > Additional Q: > Why is the "sourcecode" package not built by default when > "--target=noarch" is passed? I.e., > %ifarch noarch > %define builddoc 1 > %define buildsource 0 > ^^^ yes the plan is to not ship the sourcecode package at all for fc3 but release note how to get the sourcecode from the src.rpm > 2. There is another variable in EXTRAVERSIONS, defaults to "root" > > Assumption: > I assume this is to differentiate between UML (User Mode Linux) > kernels (so the same build system can be used)? actually it is to differentiate local builds vs buildsystem builds; mostly that is for my own sanity so that I know my own local builds and know that they don't match exact CVS tags > Additional Q: > Is this a stock kernel change? Or Red Hat only? EXTRAVERSION is strictly defined by Red Hat, in upstream it's designed for free use for packagers ;) > 3. Athlon no longer a build option at all in the SPEC file the gain Athlon gave previously is, in 2.6 kernels, now a runtime option not a compiletime option, so no need to have different kernels for athlon anymore. > Additional Q: > Is there any reason why we can't "patch back in" just the few changes > into the SPEC so one can build Athlon kernels easily with > "--target=athlon"? why bother ? > > [ **BTW, I'm fully aware that the i686 kernel runs fairly optimized on > Athlon. But turning off the generic support, and optimizing for K7 > makes a significant difference for me in engineering applications. ] even in 2.6? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at wir-sind-cool.org Sun Sep 26 19:42:32 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 26 Sep 2004 21:42:32 +0200 Subject: gqview removed from rawhide In-Reply-To: <411C3CA0.1000608@sbcglobal.net> References: <411BB751.5050902@redhat.com> <411C3CA0.1000608@sbcglobal.net> Message-ID: <20040926214232.28f79cc9.fedora@wir-sind-cool.org> On Thu, 12 Aug 2004 23:59:28 -0400, Jim Cornette wrote: > Christopher Aillon wrote: > > > Just a note that gqview just got removed from rawhide. It has the > > same mission statement as gthumb and uses raster code internally. > > Yes, I know there are people who use it still. I suggest this can > > move over to Fedora Extras if people really want it. > > > > > I feel that gqview is a great program for dealing with graphics. I hate > to have it leave the fold of programs provided within core. I hope that > this program enriches the Fedora Extras fold. https://bugzilla.fedora.us/show_bug.cgi?id=2084 From notting at redhat.com Sun Sep 26 20:44:44 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 26 Sep 2004 16:44:44 -0400 Subject: rc.sysinit creating device nodes In-Reply-To: <200409260115.45710.russell@coker.com.au> References: <200409260115.45710.russell@coker.com.au> Message-ID: <20040926204444.GB14872@nostromo.devel.redhat.com> Russell Coker (russell at coker.com.au) said: > echo mkdmnod | /sbin/nash > > rc.sysinit runs the above command to create /dev/mapper/control. Now that we > have udev managing /dev we have no need to have nash do that. Sorry, try again. Yes, we do. Bill From notting at redhat.com Sun Sep 26 20:46:15 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 26 Sep 2004 16:46:15 -0400 Subject: rc.sysinit creating device nodes In-Reply-To: <20040926204444.GB14872@nostromo.devel.redhat.com> References: <200409260115.45710.russell@coker.com.au> <20040926204444.GB14872@nostromo.devel.redhat.com> Message-ID: <20040926204615.GC14872@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Russell Coker (russell at coker.com.au) said: > > echo mkdmnod | /sbin/nash > > > > rc.sysinit runs the above command to create /dev/mapper/control. Now that we > > have udev managing /dev we have no need to have nash do that. > > Sorry, try again. Yes, we do. Whoops, yes *that* one may go away. But there's still other device creation code in rc.sysinit that is still needed. (See: raid.) Bill From rdieter at math.unl.edu Sun Sep 26 21:18:24 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 26 Sep 2004 16:18:24 -0500 Subject: FC3 and printing from Mozilla In-Reply-To: <1096117319.2720.5.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> Message-ID: <41573220.2090403@math.unl.edu> Kyrre Ness Sjobak wrote: > Will there be a real print dialog (one which do allow you to select > printers) in FC3? ... > Not having support for multiple printers (unless you know the syntax of > lpr) is really a huge handicap for end-user-friendlyness IMO I thought I'd at leaste mention that by using xprint (http://www.mozilla.org/projects/xprint/) one can get this feature *now*. Unfortunately, redhat has been reluctant to provide the support in their build of mozilla for it to work. For the record, here's my fedora Extras xprint submission: http://bugzilla.fedora.us/show_bug.cgi?id=1851 -- Rex From russell at coker.com.au Sun Sep 26 21:20:03 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 27 Sep 2004 07:20:03 +1000 Subject: rc.sysinit creating device nodes In-Reply-To: <20040926204615.GC14872@nostromo.devel.redhat.com> References: <200409260115.45710.russell@coker.com.au> <20040926204444.GB14872@nostromo.devel.redhat.com> <20040926204615.GC14872@nostromo.devel.redhat.com> Message-ID: <200409270720.03917.russell@coker.com.au> On Mon, 27 Sep 2004 06:46, Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: > > Russell Coker (russell at coker.com.au) said: > > > echo mkdmnod | /sbin/nash > > > > > > rc.sysinit runs the above command to create /dev/mapper/control. Now > > > that we have udev managing /dev we have no need to have nash do that. > > > > Sorry, try again. Yes, we do. > > Whoops, yes *that* one may go away. But there's still other device > creation code in rc.sysinit that is still needed. (See: raid.) Yes, I'm still trying to work out how to solve the raid problem. Any ideas? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From kyrre at solution-forge.net Sun Sep 26 21:27:29 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 26 Sep 2004 23:27:29 +0200 Subject: Hotplugging, usb mass storage devices, and mountpoints... Message-ID: <1096234048.2691.355.camel@kyrre> Just wondering about something: When i plugged in my camera (which is a usb mass storage device), mountpoints are automatically created (one for /dev/sda and another for /dev/sda1), and /dev/sda1 is mounted. (so why is sda1 created? sda is nothing...) Great work. (but why are they named floppy? My camera isn't a floppy - and who hotplugs scsi floppy disks using the mass storage driver on the usb port?!?) But then, when i decide "enough", i pull the plug (which is ok, since it is mounted with "sync"), and it gets umounted. So far, so good. But the mountpoints are still there - so according to gnome's "my computer" - i now have tree floppy discs. So i decided to upgrade hal and dbus, just to see if anything happens. "yum upgrade hal" and "yum upgrade dbus". Done. Log in (i was doing this over ssh) to see the effects. Quite astonishing - it had "cleaned up" all of my removable media stuff - ie. my cdrom, floppy, and all the extra floppys are gone. Okay... So i try to "hotplug" a cd into the drive. It spinns up for about a minute, and nothing happens. I then try to connect the camera. The usb activity light flashes a bit, but no new mountpoints... Thats... bad. Maybe kudzu could make a difference. So i start kudzu. And all it tries to do, is to remove the printer which are conected to the paralell port (it is switched of. I hate that behaviour - made me deactivate kudzu in the past. But it has'nt pestered me during boot due to the printer been switched off. Thats good!) So what to do? "yum update kudzu" is the answer. Or not. Reboot then, and see what happens. No. No luck... And no dbus/hal messages in the console when plugging in the camera - just that the device was found and identified. Arg. I smell bugs... Kyrre From notting at redhat.com Sun Sep 26 21:36:17 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 26 Sep 2004 17:36:17 -0400 Subject: rc.sysinit creating device nodes In-Reply-To: <200409270720.03917.russell@coker.com.au> References: <200409260115.45710.russell@coker.com.au> <20040926204444.GB14872@nostromo.devel.redhat.com> <20040926204615.GC14872@nostromo.devel.redhat.com> <200409270720.03917.russell@coker.com.au> Message-ID: <20040926213617.GA15207@nostromo.devel.redhat.com> Russell Coker (russell at coker.com.au) said: > > > > rc.sysinit runs the above command to create /dev/mapper/control. Now > > > > that we have udev managing /dev we have no need to have nash do that. > > > > > > Sorry, try again. Yes, we do. > > > > Whoops, yes *that* one may go away. But there's still other device > > creation code in rc.sysinit that is still needed. (See: raid.) > > Yes, I'm still trying to work out how to solve the raid problem. Any ideas? You can't cfreate /dev/md0 on array discovery, since you need ioctl on the device to activate it. What would be required is scanning of all the block devices for *potential* raid arrays, and then guessing what devices those were from the raid superblocks. It's a good chunk of code that's not in udev ATM. Bill From jspaleta at gmail.com Sun Sep 26 21:48:57 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 26 Sep 2004 17:48:57 -0400 Subject: Hotplugging, usb mass storage devices, and mountpoints... In-Reply-To: <1096234048.2691.355.camel@kyrre> References: <1096234048.2691.355.camel@kyrre> Message-ID: <604aa79104092614482e72fc87@mail.gmail.com> On Sun, 26 Sep 2004 23:27:29 +0200, Kyrre Ness Sjobak wrote: > Just wondering about something: I think you a very very confused as to what pieces of technology do what in the now hal-fied world. You also haven't stated which versions of the packages you are using. Its vital to state clearly which version of packages you have installed. In this case which version: hal dbus kudzu gnome-valume-manager gamin > But the mountpoints are still there - so according to gnome's "my > computer" - i now have tree floppy discs. According to gnome? how about according /etc/fstab? are the mountpoints under /media still there? Its important when trying to narrow down the problem if /etc/fstab and the /media mountpoints being updated correctly or not. Hal interacts with /etc/fstab and /media/ mountpints. The gnome filemanager,nautilus, should be noticing changes in /etc/fstab and updating the My Computer pane accordingly via the gamin daemon. But without knowing if /etc/fstab is updating correctly you can't know where in the software stack the problm actually is. Is this a hal problem? or is this a gnome problem? So far I don't have enough information to make a reasonable guess. > > So i decided to upgrade hal and dbus, just to see if anything happens. > "yum upgrade hal" and "yum upgrade dbus". Done. Log in (i was doing this > over ssh) to see the effects. Quite astonishing - it had "cleaned up" > all of my removable media stuff - ie. my cdrom, floppy, and all the > extra floppys are gone. Okay... So i try to "hotplug" a cd into the > drive. It spinns up for about a minute, and nothing happens. This is where the gnome-volume-manager comes in to play. You can configure gnome to either automount cds or not automount cds. Did you make sure gnome is configured to automount the cd? gnome-volume-properties is the command that corresponds to the Preference Menu item "Removable Storage." I have a development tree synced test box and when i have gnome configured to automount data cds... it worksforme. > I then try > to connect the camera. The usb activity light flashes a bit, but no new > mountpoints... Thats... bad. Again is gnome-volume-manager configured correct to mount removable drives/media? These are different setting than automounting cds in gnome-volume-propeties. And again automounting both my camera and my compact flash reader worksforme on my rawhide synced test box. > Maybe kudzu could make a difference. So i start kudzu. Kudzu is not invovled. In fact running kudzu while logged into X might have detrimental affects considering the hardware probing kudzu might be doing. And all it tries I will reinterate that automounting cds usb-storage devices on my test box fully updated to currently available development packages is working for me. -jef From david at fubar.dk Sun Sep 26 22:35:46 2004 From: david at fubar.dk (David Zeuthen) Date: Mon, 27 Sep 2004 00:35:46 +0200 Subject: Hotplugging, usb mass storage devices, and mountpoints... In-Reply-To: <1096234048.2691.355.camel@kyrre> References: <1096234048.2691.355.camel@kyrre> Message-ID: <1096238147.3371.123.camel@localhost.localdomain> On Sun, 2004-09-26 at 23:27 +0200, Kyrre Ness Sjobak wrote: > Just wondering about something: > When i plugged in my camera (which is a usb mass storage device), > mountpoints are automatically created (one for /dev/sda and another for > /dev/sda1), and /dev/sda1 is mounted. (so why is sda1 created? sda is > nothing...) Great work. (but why are they named floppy? My camera isn't > a floppy - and who hotplugs scsi floppy disks using the mass storage > driver on the usb port?!?) > I actually have a USB floppy drive FWIW. But hal shouldn't be detecting your camera as a floppy; please file a bug against hal and state the versions of hal, udev, kernel, gamin and gnome-vfs. Please provide the information stated here http://hal.freedesktop.org/Software/HalTraces if applicable. > But then, when i decide "enough", i pull the plug (which is ok, since it > is mounted with "sync"), and it gets umounted. So far, so good. You still need to unmount; it's not safe otherwise. > But the mountpoints are still there - so according to gnome's "my > computer" - i now have tree floppy discs. > I've seen bugs in gamin that shows this; you need to look at your /etc/fstab to be 100% sure that it is a bug in hal. > So i decided to upgrade hal and dbus, just to see if anything happens. > "yum upgrade hal" and "yum upgrade dbus". Done. Log in (i was doing this > over ssh) to see the effects. Quite astonishing - it had "cleaned up" > all of my removable media stuff - ie. my cdrom, floppy, and all the > extra floppys are gone. The /etc/fstab is sanitized; e.g. all entries marked with 'kudzu' are removed and new entries are added as appropriate. Btw, the reason it's called 'kudzu' is that updfstab from kudzu used to do all this. This will probably change to 'managed'. > Okay... So i try to "hotplug" a cd into the > drive. It spinns up for about a minute, and nothing happens. I then try > to connect the camera. The usb activity light flashes a bit, but no new > mountpoints... Thats... bad. > Look at /etc/fstab > Maybe kudzu could make a difference. So i start kudzu. And all it tries > to do, is to remove the printer which are conected to the paralell port > (it is switched of. I hate that behaviour - made me deactivate kudzu in > the past. But it has'nt pestered me during boot due to the printer been > switched off. Thats good!) > > So what to do? "yum update kudzu" is the answer. Or not. Reboot then, > and see what happens. No. No luck... And no dbus/hal messages in the > console when plugging in the camera - just that the device was found and > identified. > kudzu has nothing to do with mount points and storage devices anymore. > Arg. I smell bugs... > If you can reproduce any of this, then please file bugs. Thanks, David From caillon at redhat.com Mon Sep 27 00:38:39 2004 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 26 Sep 2004 20:38:39 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096117319.2720.5.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> Message-ID: <4157610F.701@redhat.com> Kyrre Ness Sjobak wrote: >Will there be a real print dialog (one which do allow you to select >printers) in FC3? - it is no such thing (as far as i can see - i havent >ran yum update due to that i am on an ISDN dialup, and the volume is... >enormous) in test 2, but ive heard some rumours of it in desktop-list. > > I hope to get it in. I had intended to start work on it, but a bunch of other more important bugs came up that I've been spending time on. I've got them pretty much put out now and should be able to resume work here. >Not having support for multiple printers (unless you know the syntax of >lpr) is really a huge handicap for end-user-friendlyness IMO > > Is this really an issue still? https://bugzilla.mozilla.org/show_bug.cgi?id=251754 should have fixed it so we query CUPS for the list of printers. From buildsys at redhat.com Mon Sep 27 00:49:17 2004 From: buildsys at redhat.com (Build System) Date: Sun, 26 Sep 2004 20:49:17 -0400 Subject: rawhide report: 20040926 changes Message-ID: <200409270049.i8R0nH532096@porkchop.devel.redhat.com> Updated Packages: From caillon at redhat.com Mon Sep 27 01:25:26 2004 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 26 Sep 2004 21:25:26 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096125491.25333.39.camel@localhost.localdomain> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096125070.4478.25.camel@nexus.verbum.private> <1096125491.25333.39.camel@localhost.localdomain> Message-ID: <41576C06.10709@redhat.com> John (J5) Palmieri wrote: >On Sat, 2004-09-25 at 11:11, Colin Walters wrote: > > >> The right way is to make mozilla and family use the native print dialog, >> >>for which work is still in progress. Not sure if it will make FC3 or >>not. >> >> >I think Chris Allon is working on getting support for the gnome print >dialog in Mozilla. The file dialog is there and I think he said that >the print dialog was on his hit list. > > Yeah. Hopefully I can get it done for FC3. Time is somewhat short though so it might end up getting pushed as an update. From caillon at redhat.com Mon Sep 27 01:34:22 2004 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 26 Sep 2004 21:34:22 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <1096128136.2720.19.camel@kyrre> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096127556.2396.1.camel@dhollis-lnx.centricconsulting.com> <1096128136.2720.19.camel@kyrre> Message-ID: <41576E1E.9090102@redhat.com> Kyrre Ness Sjobak wrote: >Chris Allon? Who is that? > > http://people.redhat.com/caillon/ From jerone at gmail.com Mon Sep 27 03:36:13 2004 From: jerone at gmail.com (Jerone Young) Date: Sun, 26 Sep 2004 22:36:13 -0500 Subject: Suggestion to cutoff "EFI GUID Partion Support" in the kernel so that Ipod & others will be mountable Message-ID: <9f50a7a004092620362b523224@mail.gmail.com> Before I think about filing a bug I'd though I would start a discussion on this. EFI GUID Partition support is currently only supported on IA-64. Intel is eventually supposed to support this on future platforms. But today it is causing havoc, and I would very much like this off in FC3. The Apple Ipod (4th Generation) , Ipod Mini, as well as some USB and Firewire drives are no longer mountable under Linux with this option on. The 37th post at this link gives a good explination. http://www.linuxquestions.org/questions/showthread.php?s=&threadid=213012&perpage=15&highlight=ipod&pagenumber=3 Seeing how nothing today or foreseeable in the next year is using this, I don't see why this cannot be cut off for both the X86, X86_64, and PPC kernels. Just in case the link breaks here is cut and paste job of the post below: Okay, I've been following this thread and I've been having the same problem. I have a mini iPod. It works really well with my desktop maching running redhat-9 (2.4 kernel). I recently got a new laptop running SUSE 9.1 (2.6 kernel) and on the laptop I have the problem described by others in the thread: when plugged-in the kernel will find the device but quickly have an I/O error and the device is unreadable at that point: code: Sep 24 21:14:26 t42p kernel: usb 4-3: new high speed USB device using address 4 Sep 24 21:14:26 t42p kernel: usb 4-3: Product: iPod mini Sep 24 21:14:26 t42p kernel: usb 4-3: Manufacturer: Apple Sep 24 21:14:26 t42p kernel: usb 4-3: SerialNumber: 0000008638BA Sep 24 21:14:26 t42p kernel: scsi2 : SCSI emulation for USB Mass Storage devices Sep 24 21:14:26 t42p kernel: Vendor: Apple Model: iPod Rev: 1.61 Sep 24 21:14:26 t42p kernel: Type: Direct-Access ANSI SCSI revision: 02 Sep 24 21:14:27 t42p kernel: SCSI device sda: 7999488 512-byte hdwr sectors (4096 MB) Sep 24 21:14:27 t42p kernel: sda: assuming Write Enabled Sep 24 21:14:27 t42p kernel: sda: assuming drive cache: write through Sep 24 21:14:27 t42p kernel: sda:end_request: I/O error, dev sda, sector 7999480 Sep 24 21:14:27 t42p kernel: Buffer I/O error on device sda, logical block 999935 Sep 24 21:14:27 t42p kernel: end_request: I/O error, dev sda, sector 7999480 Sep 24 21:14:27 t42p kernel: Buffer I/O error on device sda, logical block 999935 Sep 24 21:14:27 t42p kernel: sda1 sda2 Sep 24 21:14:27 t42p kernel: Attached scsi generic sg0 at scsi2, channel 0, id 0, lun 0, type 0 Sep 24 21:14:27 t42p kernel: USB Mass Storage device found at 4 In my case I'm using a mini iPod with USB2, but the same problem (and solution) probably applies to the firewire interface or newer generation large iPods, but I don't have either of these to test. To make a long story short, you can solve the problem by disabling the feature CONFIG_EFI_PARTITION in your kernel and rebuilding the kernel. This problem could potentially happen with both 2.4 and 2.6 kernels. A longer story follows and perhaps someone can come up with a more sensible solution for the long run. The iPod looks like a removable disk drive to the host computer. When it is attached to the computer, the mini iPod reports a capacity of 7999488 512-byte sectors (or about 4GB). This turns out to be wrong for whatever reason. The mini iPod only really has 7999376 sectors and it exaggerates by 112 sectors. The other quality of the iPod is that if the computer attempts to read a sector greater than the actual capacity but less than the reported capacity, the iPod will dutifully report an I/O error, but it won't respond to any future requests until you unplug/plug the iPod. This creates a fragile situation where the host computer can croak the iPod by reading one of these 112 tacitly illegal sectors. If you ask me, this is an Apple bug (or maybe a bug of their disk supplier or firewire/USB interface supplier), but a bug nonetheless. So, when a new disk is presented to the linux kernel, linux first goes out and tries to find the partition table for the disk. Usually this is the first sectors of the disk (traditional microsoft partition table we've been using for 20 years), but there are also a number of other types of partition tables. The kernel uses a heuristic to look for different types of partition tables and the kernel configuration specifies which partition types are attempted. The "EFI" partition table is a new type of partition table that is part of the "extensible firmware initiative", this is a good thing for the future. I don't know anything about EFI partition tables, except that as part of looking for an EFI table linux goes out and reads the last few sectors of the disk (sector 7999480 in the case of a mini iPod). The kernel looks for an EFI partition before looking for an old fashioned MSDOS partition table and this croaks the iPod. If you disable support for EFI partition tables (CONFIG_EFI_PARTITION) the mini iPod will work fine. I don't know of a quick fix short of rebuilding the kernel. Of course, once it's working, previous advice about setting up hotplug correctly and having the right /etc/fstab entries and such apply, but the iPod is just great under linux and gtkpod is a fantastic program for managing the iPod. From notting at redhat.com Mon Sep 27 03:52:22 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 26 Sep 2004 23:52:22 -0400 Subject: Suggestion to cutoff "EFI GUID Partion Support" in the kernel so that Ipod & others will be mountable In-Reply-To: <9f50a7a004092620362b523224@mail.gmail.com> References: <9f50a7a004092620362b523224@mail.gmail.com> Message-ID: <20040927035222.GA16310@nostromo.devel.redhat.com> Jerone Young (jerone at gmail.com) said: > Before I think about filing a bug I'd though I would start a > discussion on this. EFI GUID Partition support is currently only > supported on IA-64. Intel is eventually supposed to support this on > future platforms. But today it is causing havoc, and I would very much > like this off in FC3. > > The Apple Ipod (4th Generation) , Ipod Mini, as well as some USB and > Firewire drives are no longer mountable under Linux with this option > on. The 37th post at this link gives a good explination. > http://www.linuxquestions.org/questions/showthread.php?s=&threadid=213012&perpage=15&highlight=ipod&pagenumber=3 GPT partitioning supports > 2TB disks (including logical disks created on RAID adapters.) DOS-style partitioning does not. Bill From jerone at gmail.com Mon Sep 27 05:15:36 2004 From: jerone at gmail.com (Jerone Young) Date: Mon, 27 Sep 2004 00:15:36 -0500 Subject: Suggestion to cutoff "EFI GUID Partion Support" in the kernel so that Ipod & others will be mountable In-Reply-To: <20040927035222.GA16310@nostromo.devel.redhat.com> References: <9f50a7a004092620362b523224@mail.gmail.com> <20040927035222.GA16310@nostromo.devel.redhat.com> Message-ID: <9f50a7a004092622153a310e74@mail.gmail.com> Is there a way to actually create a GPT partion on a non IA64 system? Everything I read from google involving GPT is really only used with IA64 sytem (oh may it rest in peace). The help in the kernel for EFI GPT even has "Presently only useful on the IA-64 platform". So there is a feature that is not useful on any other platform (currently), and is causing havok. On Sun, 26 Sep 2004 23:52:22 -0400, Bill Nottingham wrote: > Jerone Young (jerone at gmail.com) said: > > Before I think about filing a bug I'd though I would start a > > discussion on this. EFI GUID Partition support is currently only > > supported on IA-64. Intel is eventually supposed to support this on > > future platforms. But today it is causing havoc, and I would very much > > like this off in FC3. > > > > The Apple Ipod (4th Generation) , Ipod Mini, as well as some USB and > > Firewire drives are no longer mountable under Linux with this option > > on. The 37th post at this link gives a good explination. > > http://www.linuxquestions.org/questions/showthread.php?s=&threadid=213012&perpage=15&highlight=ipod&pagenumber=3 > > GPT partitioning supports > 2TB disks (including logical disks > created on RAID adapters.) > > DOS-style partitioning does not. > > Bill > From david at fubar.dk Mon Sep 27 07:26:45 2004 From: david at fubar.dk (David Zeuthen) Date: Mon, 27 Sep 2004 09:26:45 +0200 Subject: Suggestion to cutoff "EFI GUID Partion Support" in the kernel so that Ipod & others will be mountable In-Reply-To: <9f50a7a004092620362b523224@mail.gmail.com> References: <9f50a7a004092620362b523224@mail.gmail.com> Message-ID: <1096270005.3371.140.camel@localhost.localdomain> On Sun, 2004-09-26 at 22:36 -0500, Jerone Young wrote: > The Apple Ipod (4th Generation) , Ipod Mini, as well as some USB and > Firewire drives are no longer mountable under Linux with this option > on. The 37th post at this link gives a good explination. > http://www.linuxquestions.org/questions/showthread.php?s=&threadid=213012&perpage=15&highlight=ipod&pagenumber=3 > Interesting read; here's another data point. FWIW, I recently got myself an iPod mini and it was sort of bizarro world - it worked on Linux with IEEE1394 but not with USB; usually the opposite is true; USB Mass Storage support seems to be better supported than IEEE1394 SBP2 in my view. This was on my Fedora Rawhide system on a PB 12". I also saw this problem with the new ub driver that appeared in the .532 kernel. Perhaps this problem can be fixed with the unusual devs file in the kernel source (file drivers/usb/storage/unusual_devs.h)? David From leonard at den.ottolander.nl Mon Sep 27 07:28:57 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 27 Sep 2004 09:28:57 +0200 Subject: Polishing Fedora's specs In-Reply-To: <4151763A.5060400@post.pl> References: <4151763A.5060400@post.pl> Message-ID: <1096270137.4750.8.camel@athlon.localdomain> Hello Marcin, On Wed, 2004-09-22 at 14:55, Marcin Garski wrote: > I've recently created list of all packages in Fedora Devel tree, their > URLs, Sources and Versions. Filing bugs to tell the package maintainer there's a newer version of a package for every package is probably not a good idea. They are usually aware of this, but might not want to update in the current stage of development. If you do have good reasons why a package should be updated you could file an RFE. However, this is probably not very useful at the end of test phase 1 and test phases 2 and 3. Try filing such reports outside the test phase, or early in the first. Fixes to the SPEC file like incorrect URLs are another matter, and usually worth filing. This would significantly reduce the number of bugs you'll have to file. Timing is not as critical in this case, although a maintainer might have more time to look (and fix) your report (which is only a minor enhancement) outside or early in the test phase. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From caillon at redhat.com Mon Sep 27 07:31:43 2004 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 27 Sep 2004 03:31:43 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <41573220.2090403@math.unl.edu> References: <1096117319.2720.5.camel@kyrre> <41573220.2090403@math.unl.edu> Message-ID: <4157C1DF.4090602@redhat.com> Rex Dieter wrote: > Kyrre Ness Sjobak wrote: > >> Not having support for multiple printers (unless you know the syntax of >> lpr) is really a huge handicap for end-user-friendlyness IMO > > > I thought I'd at leaste mention that by using xprint > (http://www.mozilla.org/projects/xprint/) > one can get this feature *now*. Mozilla 1.7.3, Firefox 1.0PR1, and Thunderbird 0.8 query cups for the printer list. All of which are in rawhide. Now. Without xprint. See https://bugzilla.mozilla.org/show_bug.cgi?id=251754 for the bug and all its wondrous details. > Unfortunately, redhat has been reluctant to provide the support in > their build of mozilla for it to work. I'd say s/reluctant/strongly opposed/ to xprint but that has been discussed elsewhere and no need for d?j? vu all over again. From harald at redhat.com Mon Sep 27 07:47:54 2004 From: harald at redhat.com (Harald Hoyer) Date: Mon, 27 Sep 2004 09:47:54 +0200 Subject: Polishing Fedora's specs In-Reply-To: <4156D0C6.303@post.pl> References: <4151763A.5060400@post.pl> <41517CD4.3050506@math.unl.edu> <41517FE4.7070404@post.pl> <20040922135509.GA27560@dudweiler.stuttgart.redhat.com> <4151B8F8.8080407@post.pl> <41528F00.2020105@redhat.com> <4156D0C6.303@post.pl> Message-ID: <4157C5AA.6030809@redhat.com> Marcin Garski wrote: > Harald Hoyer wrote: > >>> I don't have diffs for specs. I do all my tasks in HTML table. >>> I think that mixture of both are at one side better, because as I see >>> I'll have to fil about 500 bugs :). Do you want that ;) ? >>> >>> Also I've already fil this kind of bugs, and had quite different >>> replays. >>> At one side very good, but at other eg. #131846 it wasn't so kind :/ >>> Beside still in development tree xerces-j is in old version and >>> probably was in FC2. >> >> >> >> >> Do you have your data in a parsable format? If yes, send it to me, >> I'll try to automate the bugzilla creation process with perl or python... > > > What format would you like? > > Name > URL > Source > > If example "URL" is correct then it will be # at the beginning. > Name > # > Source Sure, no problem.. python/perl can do that fine :) From feliciano.matias at free.fr Mon Sep 27 07:59:29 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Mon, 27 Sep 2004 09:59:29 +0200 Subject: rc.sysinit creating device nodes In-Reply-To: <1096132482.3819.88.camel@localhost.localdomain> References: <200409260115.45710.russell@coker.com.au> <1096132482.3819.88.camel@localhost.localdomain> Message-ID: <1096271544.3284.1.camel@localhost.localdomain> Le sam 25/09/2004 ? 19:14, Matias Feliciano a ?crit : > Permissions and owner should be set according to > /etc/udev/permissions.d/ _and_ /etc/security/console.perms . Ooops, it seems udev take care about console.perms. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From feliciano.matias at free.fr Mon Sep 27 08:52:26 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Mon, 27 Sep 2004 10:52:26 +0200 Subject: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support) In-Reply-To: <1096226679.14655.3.camel@laptop.fenrus.com> References: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> <1096226679.14655.3.camel@laptop.fenrus.com> Message-ID: <1096275142.3284.25.camel@localhost.localdomain> Le dim 26/09/2004 ? 21:24, Arjan van de Ven a ?crit : > yes the plan is to not ship the sourcecode package at all for fc3 but > release note how to get the sourcecode from the src.rpm > It will be good if "rpmbuild -bb --target noarch kernel-2.6.spec" and "rpmbuild -bp --target noarch kernel-2.6.spec" provide the same source tree. Some examples : No COPYING.modules file : diff -urN linux-2.6.8-1.541.admin/COPYING.modules linux-2.6.8/COPYING.modules --- linux-2.6.8-1.541.admin/COPYING.modules 2004-09-27 10:15:05.000000000 +0200 +++ linux-2.6.8/COPYING.modules 1970-01-01 01:00:00.000000000 +0100 crypto/signature/key.h is not generated : diff -urN linux-2.6.8-1.541.admin/crypto/signature/key.h linux-2.6.8/crypto/signature/key.h --- linux-2.6.8-1.541.admin/crypto/signature/key.h 2004-09-27 10:13:43.000000000 +0200 +++ linux-2.6.8/crypto/signature/key.h 2004-09-27 10:21:45.485961926 +0200 @@ -1,27 +1,7 @@ -const char ksign_def_public_key[] __initdata= - "\x98\xe2\x04\x41\x57\xcb\xb7\x11\x02\x00\xb6\x09\x28\x26\x53\xf0" - "\xd8\x20\x04\xff\x00\x94\x58\x12\x44\xbd\x34\x0f\x93\x51\x89\x5d" Bad (or missing) EXTRAVERSION : diff -urN linux-2.6.8-1.541.admin/Makefile linux-2.6.8/Makefile --- linux-2.6.8-1.541.admin/Makefile 2004-09-27 10:15:04.000000000 +0200 +++ linux-2.6.8/Makefile 2004-09-27 10:22:03.019462154 +0200 @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 8 -EXTRAVERSION = -1.541.admincustom +EXTRAVERSION = -prep NAME=Zonked Quokka The diffstat : .config | 2264 +++++++++++++++++++ .config.cmd | 173 + .config.old | 2444 ++++++++++++++++++++ COPYING.modules | 707 ----- Makefile | 2 configs/kernel-2.6.8-i586-smp.config | 12 configs/kernel-2.6.8-i586.config | 12 configs/kernel-2.6.8-i686-smp.config | 12 configs/kernel-2.6.8-i686.config | 12 configs/kernel-2.6.8-ia64.config | 12 configs/kernel-2.6.8-ppc.config | 10 configs/kernel-2.6.8-ppc32dy4.config | 10 configs/kernel-2.6.8-ppc64.config | 8 configs/kernel-2.6.8-ppc64iseries.config | 8 configs/kernel-2.6.8-ppc8260.config | 10 configs/kernel-2.6.8-ppc8560.config | 10 configs/kernel-2.6.8-s390.config | 10 configs/kernel-2.6.8-s390x.config | 10 configs/kernel-2.6.8-x86_64-smp.config | 12 configs/kernel-2.6.8-x86_64.config | 12 crypto/signature/key.h | 32 include/linux/autoconf.h | 2265 +++++++++++++++++++ scripts/basic/.docproc.cmd | 66 scripts/basic/.fixdep.cmd | 76 scripts/basic/.split-include.cmd | 55 scripts/basic/docproc | 14 scripts/basic/fixdep | 25 scripts/basic/split-include | 14 scripts/kconfig/.conf.cmd | 1 scripts/kconfig/.conf.o.cmd | 53 scripts/kconfig/.libkconfig.so.cmd | 1 scripts/kconfig/.mconf.o.cmd | 86 scripts/kconfig/.zconf.tab.o.cmd | 71 scripts/kconfig/conf | 44 scripts/kconfig/conf.o | 93 scripts/kconfig/lex.zconf.c | 3688 +++++++++++++++++++++++++++++++ scripts/kconfig/libkconfig.so | 661 +++++ scripts/kconfig/mconf.o | 65 scripts/kconfig/zconf.tab.c | 2127 +++++++++++++++++ scripts/kconfig/zconf.tab.h | 125 + scripts/kconfig/zconf.tab.o | 363 +++ 41 files changed, 14861 insertions(+), 814 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From arjanv at redhat.com Mon Sep 27 09:03:36 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 27 Sep 2004 11:03:36 +0200 Subject: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support) In-Reply-To: <1096275142.3284.25.camel@localhost.localdomain> References: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> <1096226679.14655.3.camel@laptop.fenrus.com> <1096275142.3284.25.camel@localhost.localdomain> Message-ID: <20040927090335.GA18785@devserv.devel.redhat.com> On Mon, Sep 27, 2004 at 10:52:26AM +0200, Matias Feliciano wrote: > Le dim 26/09/2004 ? 21:24, Arjan van de Ven a ?crit : > > yes the plan is to not ship the sourcecode package at all for fc3 but > > release note how to get the sourcecode from the src.rpm > > > > It will be good if "rpmbuild -bb --target noarch kernel-2.6.spec" and > "rpmbuild -bp --target noarch kernel-2.6.spec" provide the same source > tree. it's not entirely reasonable to expect that; just like kernel-sourcecode isn't identical. > crypto/signature/key.h is not generated : I don't see this as a problem; the file that does exist is supposed to be valid enough for building your own kernel. > Bad (or missing) EXTRAVERSION : > -EXTRAVERSION = -1.541.admincustom > +EXTRAVERSION = -prep ok I can see the point of changing this to be more informative > > The diffstat : > .config | 2264 +++++++++++++++++++ > .config.cmd | 173 + > .config.old | 2444 ++++++++++++++++++++ not reasonable to be expected; simply because of the "which config" question alone. > configs/kernel-2.6.8-i586-smp.config | 12 > configs/kernel-2.6.8-i586.config | 12 > configs/kernel-2.6.8-i686-smp.config | 12 > configs/kernel-2.6.8-i686.config | 12 > configs/kernel-2.6.8-ia64.config | 12 > configs/kernel-2.6.8-ppc.config | 10 > configs/kernel-2.6.8-ppc32dy4.config | 10 > configs/kernel-2.6.8-ppc64.config | 8 > configs/kernel-2.6.8-ppc64iseries.config | 8 > configs/kernel-2.6.8-ppc8260.config | 10 > configs/kernel-2.6.8-ppc8560.config | 10 > configs/kernel-2.6.8-s390.config | 10 > configs/kernel-2.6.8-s390x.config | 10 > configs/kernel-2.6.8-x86_64-smp.config | 12 > configs/kernel-2.6.8-x86_64.config | 12 make oldconfig reorders stuff somewhat. yawn :) In addition the kernel-sourcecode configs are not the configs used during binary rpm build (for example the kernel-sourcode configs turn things like generating debuginfo into binaries since while the rpm build will strip this properly, people who build their own generally don't and end up with HUGE binary files which gives problems in several other places) > crypto/signature/key.h | 32 different key; not too interesting > include/linux/autoconf.h | 2265 +++++++++++++++++++ > scripts/basic/.docproc.cmd | 66 > scripts/basic/.fixdep.cmd | 76 > scripts/basic/.split-include.cmd | 55 > scripts/basic/docproc | 14 > scripts/basic/fixdep | 25 > scripts/basic/split-include | 14 > scripts/kconfig/.conf.cmd | 1 > scripts/kconfig/.conf.o.cmd | 53 > scripts/kconfig/.libkconfig.so.cmd | 1 > scripts/kconfig/.mconf.o.cmd | 86 > scripts/kconfig/.zconf.tab.o.cmd | 71 > scripts/kconfig/conf | 44 > scripts/kconfig/conf.o | 93 > scripts/kconfig/lex.zconf.c | 3688 +++++++++++++++++++++++++++++++ > scripts/kconfig/libkconfig.so | 661 +++++ > scripts/kconfig/mconf.o | 65 > scripts/kconfig/zconf.tab.c | 2127 +++++++++++++++++ > scripts/kconfig/zconf.tab.h | 125 + > scripts/kconfig/zconf.tab.o | 363 +++ these are all autogenerated files during the build and thus don't belong in a source tree really. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kyrre at solution-forge.net Mon Sep 27 09:30:48 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 27 Sep 2004 11:30:48 +0200 Subject: Hotplugging, usb mass storage devices, and mountpoints... In-Reply-To: <604aa79104092614482e72fc87@mail.gmail.com> References: <1096234048.2691.355.camel@kyrre> <604aa79104092614482e72fc87@mail.gmail.com> Message-ID: <1096277448.2722.14.camel@kyrre> s?n, 26.09.2004 kl. 23.48 skrev Jeff Spaleta: > On Sun, 26 Sep 2004 23:27:29 +0200, Kyrre Ness Sjobak > wrote: > > Just wondering about something: > I think you a very very confused as to what pieces of technology do > what in the now hal-fied world. You also haven't stated which versions > of the packages you are using. Its vital to state clearly which > version of packages you have installed. In this case which version: > hal > dbus > kudzu > gnome-valume-manager > gamin > Yes, i'm confused. Admitted. The versions are (according to rpm): hal-0.2.98.cvs20040923-1 dbus-0.22-9 kudzu-1.1.90-1 gnome-volume-manager-0.9.10-2 gamin-0.0.9-1 (hmm... how could i have a kudzu-devel package with different versioning than kudzu?!?) > > But the mountpoints are still there - so according to gnome's "my > > computer" - i now have tree floppy discs. > > According to gnome? how about according /etc/fstab? are the > mountpoints under /media still there? Its important when trying to > narrow down the problem if /etc/fstab and the /media mountpoints being > updated correctly or not. Hal interacts with /etc/fstab and /media/ > mountpints. The gnome filemanager,nautilus, should be noticing changes > in /etc/fstab and updating the My Computer pane accordingly via the > gamin daemon. But without knowing if /etc/fstab is updating correctly > you can't know where in the software stack the problm actually is. Is > this a hal problem? or is this a gnome problem? So far I don't have > enough information to make a reasonable guess. This is /etc/fstab: /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 So yes they are gone. All removable media are gone. Both /media and /mnt are empty (what happened to /mnt?). => probably not a gnome problem. How the fstab etc. looked when i had 3 floppy disks, i dont know. But since it seems like gnome is telling the truth, i think there must have been 3 fstab entries. I didnt think the upgrade would kill off every removable storage mountpoint, but i was hoping that the bug was fixed in later versions. Always upgrade to the latest and greatest before hitting bugzilla... > > > > > So i decided to upgrade hal and dbus, just to see if anything happens. > > "yum upgrade hal" and "yum upgrade dbus". Done. Log in (i was doing this > > over ssh) to see the effects. Quite astonishing - it had "cleaned up" > > all of my removable media stuff - ie. my cdrom, floppy, and all the > > extra floppys are gone. Okay... So i try to "hotplug" a cd into the > > drive. It spinns up for about a minute, and nothing happens. > > This is where the gnome-volume-manager comes in to play. You can > configure gnome to either automount cds or not automount cds. Did you > make sure gnome is configured to automount the cd? > gnome-volume-properties is the command that corresponds to the > Preference Menu item "Removable Storage." I have a development tree > synced test box and when i have gnome configured to automount data > cds... it worksforme. > Yup, it used to work for me too... The config about "what should happen to what media" etc. in gnome is completely untouched. > > I then try > > to connect the camera. The usb activity light flashes a bit, but no new > > mountpoints... Thats... bad. > Again is gnome-volume-manager configured correct to mount removable > drives/media? These are different setting than automounting cds in > gnome-volume-propeties. And again automounting both my camera and my > compact flash reader worksforme on my rawhide synced test box. > > > Maybe kudzu could make a difference. So i start kudzu. > Kudzu is not invovled. In fact running kudzu while logged into X might > have detrimental affects considering the hardware probing kudzu might > be doing. > And all it tries > > I will reinterate that automounting cds usb-storage devices on my test > box fully updated to currently available development packages is > working for me. > 300+ packages is a bit much to download of a 64 kbps dial-up line. So i only update what seems interesting to test. That might make me run into some packaging bugs... > -jef > From feliciano.matias at free.fr Mon Sep 27 09:36:44 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Mon, 27 Sep 2004 11:36:44 +0200 Subject: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support) In-Reply-To: <20040927090335.GA18785@devserv.devel.redhat.com> References: <1096222216.3779.73.camel@bitman.oviedo.smithconcepts.com> <1096226679.14655.3.camel@laptop.fenrus.com> <1096275142.3284.25.camel@localhost.localdomain> <20040927090335.GA18785@devserv.devel.redhat.com> Message-ID: <1096277801.3284.53.camel@localhost.localdomain> Le lun 27/09/2004 ? 11:03, Arjan van de Ven a ?crit : > On Mon, Sep 27, 2004 at 10:52:26AM +0200, Matias Feliciano wrote: > > It will be good if "rpmbuild -bb --target noarch kernel-2.6.spec" and > > "rpmbuild -bp --target noarch kernel-2.6.spec" provide the same source > > tree. > > it's not entirely reasonable to expect that; just like kernel-sourcecode > isn't identical. > > > crypto/signature/key.h is not generated : > > I don't see this as a problem; the file that does exist is supposed to be > valid enough for building your own kernel. It's not : const int ksign_def_public_key_size = 0; /* automatically generated by bin2hex */ static unsigned char ksign_def_public_key[] __initdata = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; > > configs/kernel-2.6.8-i586-smp.config | 12 > > configs/kernel-2.6.8-i586.config | 12 > > configs/kernel-2.6.8-i686-smp.config | 12 > > configs/kernel-2.6.8-i686.config | 12 > > configs/kernel-2.6.8-ia64.config | 12 > > configs/kernel-2.6.8-ppc.config | 10 > > configs/kernel-2.6.8-ppc32dy4.config | 10 > > configs/kernel-2.6.8-ppc64.config | 8 > > configs/kernel-2.6.8-ppc64iseries.config | 8 > > configs/kernel-2.6.8-ppc8260.config | 10 > > configs/kernel-2.6.8-ppc8560.config | 10 > > configs/kernel-2.6.8-s390.config | 10 > > configs/kernel-2.6.8-s390x.config | 10 > > configs/kernel-2.6.8-x86_64-smp.config | 12 > > configs/kernel-2.6.8-x86_64.config | 12 > > make oldconfig reorders stuff somewhat. yawn :) > In addition the kernel-sourcecode configs are not the configs used during > binary rpm build (for example the kernel-sourcode configs turn things like > generating debuginfo into binaries since while the rpm build will strip this > properly, people who build their own generally don't and end up with HUGE > binary files which gives problems in several other places) > --- linux-2.6.8-1.541.admin/configs/kernel-2.6.8-i686.config 2004-09-27 10:15:05.000000000 +0200 +++ linux-2.6.8/configs/kernel-2.6.8-i686.config 2004-09-27 10:21:54.000000000 +0200 @@ -49,8 +49,8 @@ # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set -# CONFIG_MODULE_SIG is not set -# CONFIG_MODULE_SIG is not set +CONFIG_MODULE_SIG=y +# CONFIG_MODULE_SIG_FORCE is not set CONFIG_KMOD=y # CONFIG_MODULE_SIG is not set. Normal, there is no key :-) It should be nice if a "make modules_install" sign modules like the .spec file do : # gpg sign the modules %if %{signmodules} for i in ` find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f` ; do sh ./scripts/modsign/modsign.sh $i mv -f $i.signed $i done %endif I know I can build the i686.rpm with my custom .config file (as I do right now :-)). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From markmc at redhat.com Mon Sep 27 09:56:25 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 27 Sep 2004 10:56:25 +0100 Subject: Xinerama & tasklist Was: FC3 Bug Week - HELP WANTED In-Reply-To: <20040924215610.GB32353@server4.8080.it> References: <1096054271.6256.2.camel@opus.phy.duke.edu> <41547DDB.4020909@lanl.gov> <20040924215610.GB32353@server4.8080.it> Message-ID: <1096278984.4211.101.camel@localhost.localdomain> Hi, On Fri, 2004-09-24 at 22:56, Rudi Chiarito wrote: > On Fri, Sep 24, 2004 at 02:04:43PM -0600, Stephen J Smoogen wrote: > > Is having pam_krb5 not kill your login process when you have a local > > password and pam_krb5 is listed as optional... a bug or an RFE? > > In the same vein, is preventing the tasklist (wnck) from showing windows > that are on other monitors a bug or an RFE? > > I could only find a report upstream - and it seems to be fixed in CVS > for 2.8.1: > > http://bugzilla.gnome.org/show_bug.cgi?id=98698 I'll do a release upstream of libwnck and include it before the next freeze. Cheers, Mark. From jgorny at aurox.org Mon Sep 27 10:48:19 2004 From: jgorny at aurox.org (Jaroslaw Gorny) Date: Mon, 27 Sep 2004 12:48:19 +0200 Subject: Unpackaged files in RPM In-Reply-To: <1096043430.2722.34.camel@localhost.localdomain> References: <200409171153.i8HBrOT30928@porkchop.devel.redhat.com> <20040924175730.0c619bb9@pro8000x.aurox.org> <1096043430.2722.34.camel@localhost.localdomain> Message-ID: <20040927124819.21096015@pro8000x.aurox.org> On Fri, 24 Sep 2004 09:30:30 -0700 Per Bjornsson wrote: > On Fri, 2004-09-24 at 08:57, Jaroslaw Gorny wrote: > > > BTW. how is it possible to buid an RPM package with unpackaged > > files? Always when I've got a wrong spec, rpmbuild finishes with > > sth. like"unpackaged files found..." and *.rpm is not created. > > That's a feature, not a bug! ;) Yes, I know ;) But I just wanted to know how to do it... > > http://www.rpm.org/hintskinks/unpackaged/ Thanks, > But really, if there are no packaging bugs this just shouldn't be the > case, so in the general case doing this is a really Bad Idea. (See > Mike Harris's explanation in the link above.) Yes, it's obvious. Thanks again, Jarek From kyrre at solution-forge.net Mon Sep 27 10:45:59 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 27 Sep 2004 12:45:59 +0200 Subject: FC3 and printing from Mozilla In-Reply-To: <41576C06.10709@redhat.com> References: <1096117319.2720.5.camel@kyrre> <200409251656.46676.mgarski@post.pl> <1096124596.2720.11.camel@kyrre> <1096125070.4478.25.camel@nexus.verbum.private> <1096125491.25333.39.camel@localhost.localdomain> <41576C06.10709@redhat.com> Message-ID: <1096281959.2722.84.camel@kyrre> man, 27.09.2004 kl. 03.25 skrev Christopher Aillon: > John (J5) Palmieri wrote: > > >On Sat, 2004-09-25 at 11:11, Colin Walters wrote: > > > > > >> The right way is to make mozilla and family use the native print dialog, > >> > >>for which work is still in progress. Not sure if it will make FC3 or > >>not. > >> > >> > >I think Chris Allon is working on getting support for the gnome print > >dialog in Mozilla. The file dialog is there and I think he said that > >the print dialog was on his hit list. > > > > > Yeah. Hopefully I can get it done for FC3. Time is somewhat short > though so it might end up getting pushed as an update. > That would be just as nice - we are planning to give FC3 accounts to a whole school (400 people) not far after the release of FC3 - and one of the blockers so far has been support for selecting which printer it should come out on. Apart from that, mozilla, firefox, and my personal favourite - epiphany, are the fastest browsers out there producing the nicest output on screen and in print. Keep up the good work! I have just updated epiphany, mozilla and firefox to these versions: mozilla-1.7.3-1 firefox-0.10.0-1.0PR1.0 epiphany-1.4.0-0.3.6 and the status is: -Firefox has a dropdown in which you may select printer -Mozilla has a dropdown - the print dialog box is identical with firefoxe's - but the only choice is "default". -Epiphany still only got the field "lpr" Kyrre From buildsys at redhat.com Mon Sep 27 11:43:57 2004 From: buildsys at redhat.com (Build System) Date: Mon, 27 Sep 2004 07:43:57 -0400 Subject: rawhide report: 20040927 changes Message-ID: <200409271143.i8RBhv905639@porkchop.devel.redhat.com> Updated Packages: MagicPoint-1.11b-1 ------------------ * Mon Sep 27 2004 Akira TAGOH - 1.11b-1 - New upstream release. VFlib2-2.25.6-23 ---------------- * Mon Sep 27 2004 Akira TAGOH - 2.25.6-23 - VFlib2-2.25.6-fix-gcc-warnings.patch: applied to fix the gcc warnings (#133400) apel-10.6-3 ----------- * Mon Sep 27 2004 Akira TAGOH - 10.6-3 - rebuilt dos2unix-3.1-19 --------------- * Sun Sep 26 2004 Rik van Riel 3.1-19 - safer conversion w/ mac2unix (fix from bz #57508) firefox-0.10.0-1.0PR1.1 ----------------------- * Fri Sep 24 2004 Christopher Aillon 0:0.10.0-1.0PR1.1 - Add a BR for desktop-file-utils - Update default configuration options to use the firefox mozconfig (#132916) - Use Red Hat bookmarks (#133262) - Update default homepage (#132721) - Fix JS math on AMD64 (#133226) - Build with MOZILLA_OFICIAL (#132917) hwbrowser-0.17-1 ---------------- * Mon Sep 27 2004 Nils Philippsen 0.17-1 - enable Arabic translation (#133723) jisksp14-0.1-15 --------------- * Mon Sep 27 2004 Akira TAGOH - 0.1-15 - rebuilt jisksp16-1990-0.1-16 -------------------- * Mon Sep 27 2004 Akira TAGOH - 0.1-16 - rebuilt kappa20-0.3-15 -------------- * Mon Sep 27 2004 Akira TAGOH - 0.3-15 - rebuilt knm_new-1.1-15 -------------- * Mon Sep 27 2004 Akira TAGOH - 1.1-15 - rebuilt mew-3.3-3 --------- * Mon Sep 27 2004 Akira TAGOH - 3.3-3 - rebuilt rpmdb-fedora-2.91-0.20040927 ---------------------------- system-config-services-0.8.9-1 ------------------------------ * Mon Sep 27 2004 Nils Philippsen - 0.8.9-1 - enable Arabic translation (#133722) From kyrre at solution-forge.net Mon Sep 27 12:24:22 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 27 Sep 2004 14:24:22 +0200 Subject: Hotplugging, usb mass storage devices, and mountpoints... In-Reply-To: <604aa79104092705166660a925@mail.gmail.com> References: <1096234048.2691.355.camel@kyrre> <604aa79104092614482e72fc87@mail.gmail.com> <1096277448.2722.14.camel@kyrre> <604aa79104092705166660a925@mail.gmail.com> Message-ID: <1096287862.2722.89.camel@kyrre> I will. But first there is a need to find the bug wich removed every single removable storage from my fstab ;) CC'ing to fedora-devel, since there is where the discussion started... I have now created a bug report on the new problem - that every removable storage thing is nuked. When that is fixed, ill see if i can reproduce the original error. Maybee ask for imput from fedora-test-list? There might be somebody who has had the same troubles. Kyrre man, 27.09.2004 kl. 14.16 skrev Jeff Spaleta: > On Mon, 27 Sep 2004 11:30:48 +0200, Kyrre Ness Sjobak > wrote: > > => probably not a gnome problem. > > > > How the fstab etc. looked when i had 3 floppy disks, i dont know. But > > since it seems like gnome is telling the truth, i think there must have > > been 3 fstab entries. > > That is an absolutely horrible assumption to make. I have run into > bugs with gamin in the past which left devices listing in my computer > even though fstab was being propoerly updated. You need to attempt to > reproduce this and you need to narrow it down for the bugreport to > have any meaningful value. > > -jef > From rdieter at math.unl.edu Mon Sep 27 12:26:31 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 27 Sep 2004 07:26:31 -0500 Subject: FC3 and printing from Mozilla In-Reply-To: <4157C1DF.4090602@redhat.com> References: <1096117319.2720.5.camel@kyrre> <41573220.2090403@math.unl.edu> <4157C1DF.4090602@redhat.com> Message-ID: <415806F7.4040405@math.unl.edu> Christopher Aillon wrote: > Rex Dieter wrote: > >> Kyrre Ness Sjobak wrote: >> >>> Not having support for multiple printers (unless you know the syntax of >>> lpr) is really a huge handicap for end-user-friendlyness IMO >> I thought I'd at leaste mention that by using xprint >> (http://www.mozilla.org/projects/xprint/) >> one can get this feature *now*. > Mozilla 1.7.3, Firefox 1.0PR1, and Thunderbird 0.8 query cups for the > printer list. All of which are in rawhide. Now. Without xprint. I'm using mozilla-1.7.3 on my box right now (and without xprint), the only printer listed for me is "Postscript/default". Am I missing something? >> Unfortunately, redhat has been reluctant to provide the support in >> their build of mozilla for it to work. ... > I'd say s/reluctant/strongly opposed/ to xprint but that has been > discussed elsewhere and no need for d?j? vu all over again. The only responses I've ever seen/heard from redhat regarding xprint is a curt replies like yours. I don't know about your deja-vu, but all I know is that xprint has worked for me personally going back to the mozilla-1.4 days. What's troublesome to me is that I see no harm in simply enabling xprint support in the mozilla builds, since it does nothing if xprint isn't installed and running, yet redhat *still* refuses to even allow that. -- Rex From kyrre at solution-forge.net Mon Sep 27 12:25:30 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 27 Sep 2004 14:25:30 +0200 Subject: Hotplugging, usb mass storage devices, and mountpoints... In-Reply-To: <1096287862.2722.89.camel@kyrre> References: <1096234048.2691.355.camel@kyrre> <604aa79104092614482e72fc87@mail.gmail.com> <1096277448.2722.14.camel@kyrre> <604aa79104092705166660a925@mail.gmail.com> <1096287862.2722.89.camel@kyrre> Message-ID: <1096287929.2722.91.camel@kyrre> Arg... The bugzilla report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133775 man, 27.09.2004 kl. 14.24 skrev Kyrre Ness Sjobak: > I will. But first there is a need to find the bug wich removed every > single removable storage from my fstab ;) > > CC'ing to fedora-devel, since there is where the discussion started... > > I have now created a bug report on the new problem - that every > removable storage thing is nuked. When that is fixed, ill see if i can > reproduce the original error. > > Maybee ask for imput from fedora-test-list? There might be somebody who > has had the same troubles. > > Kyrre > > man, 27.09.2004 kl. 14.16 skrev Jeff Spaleta: > > On Mon, 27 Sep 2004 11:30:48 +0200, Kyrre Ness Sjobak > > wrote: > > > => probably not a gnome problem. > > > > > > How the fstab etc. looked when i had 3 floppy disks, i dont know. But > > > since it seems like gnome is telling the truth, i think there must have > > > been 3 fstab entries. > > > > That is an absolutely horrible assumption to make. I have run into > > bugs with gamin in the past which left devices listing in my computer > > even though fstab was being propoerly updated. You need to attempt to > > reproduce this and you need to narrow it down for the bugreport to > > have any meaningful value. > > > > -jef > > > From kyrre at solution-forge.net Mon Sep 27 12:27:16 2004 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 27 Sep 2004 14:27:16 +0200 Subject: FC3 and printing from Mozilla In-Reply-To: <415806F7.4040405@math.unl.edu> References: <1096117319.2720.5.camel@kyrre> <41573220.2090403@math.unl.edu> <4157C1DF.4090602@redhat.com> <415806F7.4040405@math.unl.edu> Message-ID: <1096288036.2722.93.camel@kyrre> Yes. Why is xprint so evil? I if works, it must be better with half-broken than 100% broken? man, 27.09.2004 kl. 14.26 skrev Rex Dieter: > Christopher Aillon wrote: > > Rex Dieter wrote: > > > >> Kyrre Ness Sjobak wrote: > >> > >>> Not having support for multiple printers (unless you know the syntax of > >>> lpr) is really a huge handicap for end-user-friendlyness IMO > > >> I thought I'd at leaste mention that by using xprint > >> (http://www.mozilla.org/projects/xprint/) > >> one can get this feature *now*. > > > Mozilla 1.7.3, Firefox 1.0PR1, and Thunderbird 0.8 query cups for the > > printer list. All of which are in rawhide. Now. Without xprint. > > I'm using mozilla-1.7.3 on my box right now (and without xprint), the > only printer listed for me is "Postscript/default". Am I missing something? > > >> Unfortunately, redhat has been reluctant to provide the support in > >> their build of mozilla for it to work. > ... > > I'd say s/reluctant/strongly opposed/ to xprint but that has been > > discussed elsewhere and no need for d?j? vu all over again. > > The only responses I've ever seen/heard from redhat regarding xprint is > a curt replies like yours. > > I don't know about your deja-vu, but all I know is that xprint has > worked for me personally going back to the mozilla-1.4 days. What's > troublesome to me is that I see no harm in simply enabling xprint > support in the mozilla builds, since it does nothing if xprint isn't > installed and running, yet redhat *still* refuses to even allow that. > > -- Rex > From rdieter at math.unl.edu Mon Sep 27 12:31:18 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 27 Sep 2004 07:31:18 -0500 Subject: FC3 and printing from Mozilla In-Reply-To: <4157C1DF.4090602@redhat.com> References: <1096117319.2720.5.camel@kyrre> <41573220.2090403@math.unl.edu> <4157C1DF.4090602@redhat.com> Message-ID: <41580816.2060300@math.unl.edu> Christopher Aillon wrote: > Mozilla 1.7.3, Firefox 1.0PR1, and Thunderbird 0.8 query cups for the > printer list. All of which are in rawhide. Now. Without xprint. See > https://bugzilla.mozilla.org/show_bug.cgi?id=251754 for the bug and all > its wondrous details. I just looked at the mozilla-1.7.3-1.src.rpm in rawhide, and it appears that the patch in question from bugzilla.mozilla.org didn't make it into mozilla-1.7.3. -- Rex From rdieter at math.unl.edu Mon Sep 27 14:01:08 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 27 Sep 2004 09:01:08 -0500 Subject: FC3 and printing from Mozilla In-Reply-To: <41580816.2060300@math.unl.edu> References: <1096117319.2720.5.camel@kyrre> <41573220.2090403@math.unl.edu> <4157C1DF.4090602@redhat.com> <41580816.2060300@math.unl.edu> Message-ID: <41581D24.2000708@math.unl.edu> Rex Dieter wrote: > Christopher Aillon wrote: > >> Mozilla 1.7.3, Firefox 1.0PR1, and Thunderbird 0.8 query cups for the >> printer list. All of which are in rawhide. Now. Without xprint. >> See https://bugzilla.mozilla.org/show_bug.cgi?id=251754 for the bug >> and all its wondrous details. > > > I just looked at the mozilla-1.7.3-1.src.rpm in rawhide, and it appears > that the patch in question from bugzilla.mozilla.org didn't make it into > mozilla-1.7.3. Good news. I snagged the patch from bugzilla (fixed a typo), and rebuilt mozilla and viola! I get a cups printer list! http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133787 -- Rex From katzj at redhat.com Mon Sep 27 14:29:19 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Sep 2004 10:29:19 -0400 Subject: Suggestion to cutoff "EFI GUID Partion Support" in the kernel so that Ipod & others will be mountable In-Reply-To: <9f50a7a004092622153a310e74@mail.gmail.com> References: <9f50a7a004092620362b523224@mail.gmail.com> <20040927035222.GA16310@nostromo.devel.redhat.com> <9f50a7a004092622153a310e74@mail.gmail.com> Message-ID: <1096295359.4636.29.camel@bree.local.net> On Mon, 2004-09-27 at 00:15 -0500, Jerone Young wrote: > Is there a way to actually create a GPT partion on a non IA64 system? > Everything I read from google involving GPT is really only used with > IA64 sytem (oh may it rest in peace). The help in the kernel for EFI > GPT even has "Presently only useful on the IA-64 platform". So there > is a feature that is not useful on any other platform (currently), and > is causing havok. Sure, parted will create it for you if you ask it to. You just have to do so on a non-bootable disk (as your BIOS won't be able to boot from it) Jeremy From P at draigBrady.com Mon Sep 27 15:16:03 2004 From: P at draigBrady.com (P at draigBrady.com) Date: Mon, 27 Sep 2004 16:16:03 +0100 Subject: Maching paper size with locale In-Reply-To: <4155CD90.30208@redhat.com> References: <1096141797.4176.30.camel@kyrre> <4155CD90.30208@redhat.com> Message-ID: <41582EB3.3000004@draigBrady.com> Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Kyrre Ness Sjobak wrote: > >>Why is there no common setting of this - one file where all programs >>read what the standard papersize/orientation etc should be? > > > There is, the paper size information is part of the locale. > > It's just that not all programs use that information. And of course > they can only use those values for an initial setup. I.e., firefox > could only use the information when it creates a new profile. The > setting in existing profiles must be accepted. > > If you find a program not respecting the information in the initial > setup, file a bug for that program. Point to the LC_PAPER locale category. As a side note, I find it useful to lookup the locale database for various things using the local util. For e.g.: LANG=fr_FR locale int_prefix So what's the corresponding command for paper size? Why doesn't the locale command have a --list-all-fields option? cheers, P?draig. From dmalcolm at redhat.com Mon Sep 27 15:51:25 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 27 Sep 2004 11:51:25 -0400 Subject: [bugweek] A script to detect -mtune=i386 libraries In-Reply-To: <1096146849.17155.16.camel@laptop.fenrus.com> References: <1096146582.17155.14.camel@laptop.fenrus.com> <1096146849.17155.16.camel@laptop.fenrus.com> Message-ID: <1096300286.13844.2.camel@cassandra.boston.redhat.com> On Sat, 2004-09-25 at 23:14 +0200, Arjan van de Ven wrote: > > The script at > > can be used to check if a shared libary is compiled with -mtune=i386 or > > and evil evolution ate my email. Which versions of evolution and gtkhtml3? Want to file a bug? > > the script is at http://people.redhat.com/arjanv/detecti686.pl > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From sopwith at redhat.com Mon Sep 27 16:03:49 2004 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 27 Sep 2004 12:03:49 -0400 (EDT) Subject: Rant on LABELs In-Reply-To: <1096200533.2804.3.camel@laptop.fenrus.com> References: <1096186444.3062.4.camel@marte.biciclete.ro> <1096195694.25963.12.camel@gibraltar.stuttgart.redhat.com> <1096200533.2804.3.camel@laptop.fenrus.com> Message-ID: On Sun, 26 Sep 2004, Arjan van de Ven wrote: > > > to ensure that the random number would be virtually unique which means > > long numbers ;-). > > well but ext2/3 do have UUID's; there's no reason we can't do > mount-by-UUID as well. We do have mount-by-UUID: mount UUID=b04a5cd1-3f15-45d3-8c25-3ef732eb3d82 /mnt/point Cheers, -- Elliot We're so busy putting out fires that we don't take time to stop kids from playing with matches. From otaylor at redhat.com Mon Sep 27 16:07:57 2004 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 27 Sep 2004 12:07:57 -0400 Subject: FC3 and printing from Mozilla In-Reply-To: <415806F7.4040405@math.unl.edu> References: <1096117319.2720.5.camel@kyrre> <41573220.2090403@math.unl.edu> <4157C1DF.4090602@redhat.com> <415806F7.4040405@math.unl.edu> Message-ID: <1096301277.30432.9.camel@localhost.localdomain> On Mon, 2004-09-27 at 07:26 -0500, Rex Dieter wrote: > > I'd say s/reluctant/strongly opposed/ to xprint but that has been > > discussed elsewhere and no need for d?j? vu all over again. > > The only responses I've ever seen/heard from redhat regarding xprint is > a curt replies like yours. > > I don't know about your deja-vu, but all I know is that xprint has > worked for me personally going back to the mozilla-1.4 days. What's > troublesome to me is that I see no harm in simply enabling xprint > support in the mozilla builds, since it does nothing if xprint isn't > installed and running, yet redhat *still* refuses to even allow that. To summarize briefly: - xprint doesn't use the font system that we use everywhere else (fontconfig) - xprint can't use the layout system we use everywhere else (Pango) - xprint doesn't integrate well with the printing system that we use everywhere else (CUPS) - xprint can't use the desktop-wide printing dialog (libgnomeprintui) The first and last are important ones for why enabling Xprint support in the build is a bad idea; we can't provide as good a font or printer selection user interface if the printing backend might be incompatible with our standard technologies rather than closely integrated with our standard technologies. Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dax at gurulabs.com Mon Sep 27 16:50:01 2004 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 27 Sep 2004 10:50:01 -0600 Subject: [bugweek] A script to detect -mtune=i386 libraries In-Reply-To: <20040926000900.GP25483@devserv.devel.redhat.com> References: <1096146582.17155.14.camel@laptop.fenrus.com> <20040926000900.GP25483@devserv.devel.redhat.com> Message-ID: <1096303801.4075.19.camel@mentorng.gurulabs.com> On Sat, 2004-09-25 at 18:09, Alan Cox wrote: > On Sat, Sep 25, 2004 at 11:09:42PM +0200, Arjan van de Ven wrote: > > in theory we compile all of fedora core with -mtune=i686 (or > > -mtune=pentium4 nowadays). however that only actually happens if > > packages propagate the RPM_OPT_FLAGS into the CFLAGS properly; almost > > all but not quite not all packages actually do this. > > I noticed a curiosity playing with this that perhaps the gcc folks can > explain the right choice for - on Dothan -mtune=i686 is a lot faster than > tuning for pentium4. AFAIK there's a -march=pentium-m in gcc 3.4.x. Does that imply that -mtune=pentium-m exists? Dax From vmakarov at redhat.com Mon Sep 27 17:20:06 2004 From: vmakarov at redhat.com (Vladimir Makarov) Date: Mon, 27 Sep 2004 13:20:06 -0400 Subject: [bugweek] A script to detect -mtune=i386 libraries In-Reply-To: <1096303801.4075.19.camel@mentorng.gurulabs.com> References: <1096146582.17155.14.camel@laptop.fenrus.com> <20040926000900.GP25483@devserv.devel.redhat.com> <1096303801.4075.19.camel@mentorng.gurulabs.com> Message-ID: <41584BC6.4020206@redhat.com> Dax Kelson wrote: >On Sat, 2004-09-25 at 18:09, Alan Cox wrote: > > >>On Sat, Sep 25, 2004 at 11:09:42PM +0200, Arjan van de Ven wrote: >> >> >>>in theory we compile all of fedora core with -mtune=i686 (or >>>-mtune=pentium4 nowadays). however that only actually happens if >>>packages propagate the RPM_OPT_FLAGS into the CFLAGS properly; almost >>>all but not quite not all packages actually do this. >>> >>> >>I noticed a curiosity playing with this that perhaps the gcc folks can >>explain the right choice for - on Dothan -mtune=i686 is a lot faster than >>tuning for pentium4. >> >> I don't think that -mtune=i686 is a lot faster in average (as I remeber the difference was 1-2% for SPECInt2000). Although some benchmarks (with few hot spots in loops) could be a lot faster. E.g. the difference between -mtune=nocona (em64t) and -mtune=k8 (amd64) on Xeon (nocona core) is really big (up to 20% for SPECInt2000). -mtune=i686 means tunning for pentiumpro core (core of pentium2 and pentium3 processors). As I know pentium-m design was based on this core (although intel used some implementations from P4 cores too). Of course the code tunned with -mtune=i686 will work better for pentium-m than code tunned with -mtune=pentium4. The factor which has the biggest impact is that Pentium-M is more sensitive to code alignment (function, loop, label alignment) than pentium4. Therefore code generated with -mtune=i686 has bigger alignments and as consequence the generated code with this option is bigger. Also latency time of pentium4 and pentium-m are differrent. Penium-M has more constraints in issuing several insns on the same cycle than pentium4 does. Therefore insn scheduling is more important for pentium-m than pentium4. There are a few other different parameters which gcc takes into account when it tunnes code for pentium-m. >AFAIK there's a -march=pentium-m in gcc 3.4.x. Does that imply that >-mtune=pentium-m exists? > > There is no difference between tunning for pentium-m and i686 (or pentiumpro) in gcc-3.4. It is just another alias. Vlad From shane at geeklords.org Mon Sep 27 17:15:17 2004 From: shane at geeklords.org (shane at geeklords.org) Date: Mon, 27 Sep 2004 10:15:17 -0700 (PDT) Subject: Installing kernel source in FC3? Message-ID: Can this be done with up2date in FC3? up2date --showall does not report any package that contains kernel source, noarch included. -- "Given enough time, all legal battles in the tech industry will invoke the DMCA. This generally means that all constructive arguments have ended." -NialScorva From redhat at olen.net Mon Sep 27 18:27:28 2004 From: redhat at olen.net (Ola Thoresen) Date: Mon, 27 Sep 2004 18:27:28 +0000 (UTC) Subject: Rant on LABELs References: Message-ID: Mon, 27 Sep 2004 at 16:05 GMT Elliot Lee wrote > On Sun, 26 Sep 2004, Arjan van de Ven wrote: > >> >> > to ensure that the random number would be virtually unique which means >> > long numbers ;-). >> >> well but ext2/3 do have UUID's; there's no reason we can't do >> mount-by-UUID as well. > > We do have mount-by-UUID: > > mount UUID=b04a5cd1-3f15-45d3-8c25-3ef732eb3d82 /mnt/point I think it's easier to remember hda1 or hdc5 than b04a5cd1-3f15-45d3-8c25-3ef732eb3d82 ... But how about some kind of "fallback" to mount by uid if duplicate labels are found? At install time or any time the admin wants, a script is run, writing something like /etc/sysconfig/mountpoints with