From vd at paradigma.pt Sat Oct 1 08:41:00 2005 From: vd at paradigma.pt (Vitor Domingos) Date: Sat, 01 Oct 2005 09:41:00 +0100 Subject: rawhide report: 20050930 changes In-Reply-To: <433DB851.1040704@paradigma.pt> References: <200509301131.j8UBVcZj009304@porkchop.devel.redhat.com> <433DB851.1040704@paradigma.pt> Message-ID: <433E4B9C.9050702@paradigma.pt> Just answering to myself :) http://paradigma.pt/~vd/wlog/index.php?entry=entry051001-010559 - Fetch from James Ketrenos these versions: ipw2100-1.1.3[1] and ieee80211-1.1.4[2] - Apply this patch[3] or download my patched version of ipw2100-1.1.3.[4] - Just follow these instructions[5]. Change the kernel and driver versions to your own. [1] - http://ketrenos.com/patches/ipw2100-1.1.3.tgz [2] - http://ketrenos.com/patches/ieee80211-1.1.4.tgz [3] - http://sourceforge.net/mailarchive/message.php?msg_id=13023990 [4] - http://paradigma.pt/~vd/software/ipw2100-1.1.3.tar.bz2 [5] - http://www.ces.clemson.edu/linux/fc2-ipw2200.shtml //VD Vitor Domingos wrote on 09/30/2005 11:12 PM: > Any ideias on how / when ipw2100/2200 drivers will be fixed? > > I'm getting the same old message: > eth1 (WE) : Driver using old /proc/net/wireless support, please fix driver ! > > //VD > > Build System wrote on 09/30/2005 12:31 PM: >> >> >> >> Updated Packages: >> >> bg5ps-1.3.0-22 >> -------------- >> * Thu Sep 29 2005 Qian Shen >> - rebuilt >> >> bug-buddy-1:2.12.0-2 >> -------------------- >> * Thu Sep 29 2005 Matthias Clasen - 2.12.0-2 >> - Fix a few bugs >> >> cpuspeed-1:1.2.1-1.23 >> --------------------- >> * Thu Sep 29 2005 Dave Jones >> - On shutdown, restore speed to maximum before daemon exit. >> >> gcc-4.0.2-1 >> ----------- >> * Thu Sep 29 2005 Jakub Jelinek 4.0.2-1 >> - update from CVS >> - GCC 4.0.2 release >> - PRs c++/23993, libstdc++/19265, rtl-optimization/23043, >> rtl-optimization/23941, target/24102 >> - fix a bug which caused undefined __compound_literal.* symbols >> on Linux kernel (PR middle-end/24109) >> - add LIBGCJ_LICENSE file to %doc (#163922) >> - fix Fortran EQUIVALENCE interaction with SAVE (PR fortran/18518, #168252) >> - fix Fortran -fno-automatic (PR fortran/23677, #168355) >> - fix ppc64 libffi (Tom Tromey, #166657) >> >> glade2-2.12.0-1 >> --------------- >> * Thu Sep 29 2005 Matthias Clasen - 2.12.0-1 >> - Update to 2.12.0 >> >> gnome-doc-utils-0.4.2-1 >> ----------------------- >> * Thu Sep 29 2005 Matthias Clasen - 0.4.2-1 >> - Update to 0.4.2 >> >> gnome-keyring-0.4.5-1 >> --------------------- >> * Thu Sep 29 2005 Matthias Clasen 0.4.5-1 >> - Update to 0.4.5 >> >> * Wed Sep 07 2005 Matthias Clasen 0.4.4-1 >> - Update to 0.4.4 >> >> * Tue Aug 16 2005 David Zeuthen 0.4.3-2 >> - Rebuilt >> >> gnome-utils-1:2.12.0-2 >> ---------------------- >> * Thu Sep 29 2005 Matthias Clasen - 1:2.12.0-2 >> - Make gnome-system-log use consolehelper (#169535) >> >> grep-2.5.1-51 >> ------------- >> * Thu Sep 29 2005 Tim Waugh 2.5.1-51 >> - Prevent 'grep -Fw ""' from busy-looping (bug #169524). >> >> gthumb-2.6.8-1 >> -------------- >> * Thu Sep 29 2005 Matthias Clasen - 2.6.8-1 >> - Update to 2.6.8 >> >> iputils-20020927-28 >> ------------------- >> * Fri Sep 30 2005 Radek Vokal 20020927-28 >> - memset structure before using it (#168166) >> >> kdebase-6:3.4.91-2 >> ------------------ >> * Thu Sep 29 2005 Than Ngo 6:3.4.91-2 >> - fix typo >> >> kdepim-6:3.4.91-1 >> ----------------- >> * Thu Sep 29 2005 Than Ngo 6:3.4.91-1 >> - update to KDE 3.5 beta1 >> >> kernel-2.6.13-1.1586_FC5 >> ------------------------ >> * Fri Sep 30 2005 Dave Jones >> - 2.6.14-rc2-git8 >> >> * Thu Sep 29 2005 Dave Jones >> - 2.6.14-rc2-git7 >> - Fix up module aliases for firedire. (#134047) >> - rebuild. >> >> libgnome-2.12.0.1-1 >> ------------------- >> * Thu Sep 29 2005 Matthias Clasen - 2.12.0.1-1 >> - Update to 2.12.0.1 >> >> * Thu Sep 22 2005 Jeremy Katz - 2.12.0-2 >> - fix broken translation in schema >> >> * Thu Sep 08 2005 Matthias Clasen - 2.12.0-1 >> - Update to 2.12.0 >> >> libgnomecups-0.2.2-1 >> -------------------- >> * Thu Sep 29 2005 Matthias Clasen - 0.2.2-1 >> - Update to 0.2.2 >> >> libgnomeprint22-2.12.1-1 >> ------------------------ >> * Thu Sep 29 2005 Matthias Clasen - 2.12.1-1 >> - Update to 2.12.1 >> >> libgnomeprintui22-2.12.1-1 >> -------------------------- >> * Fri Sep 30 2005 Matthias Clasen - 2.12.1-1 >> - Update to 2.12.1 >> >> librsvg2-2.12.3-1 >> ----------------- >> * Thu Sep 29 2005 Matthias Clasen - 2.12.3-1 >> - New upstream version >> >> libselinux-1.27.1-3 >> ------------------- >> * Thu Sep 29 2005 Dan Walsh 1.27.1-3 >> - Fix patch to satisfy upstream >> >> libtiff-3.7.4-1 >> --------------- >> * Thu Sep 29 2005 Matthias Clasen - 3.7.4-1 >> - Update to 3.7.4 >> - Drop upstreamed patches >> >> libtool-1.5.20-4 >> ---------------- >> * Thu Sep 29 2005 Jakub Jelinek 1.5.20-4 >> - rebuilt with GCC 4.0.2 >> >> logwatch-6.1.2-6 >> ---------------- >> * Fri Sep 30 2005 Ivana Varekova 6.1.2-6 >> - add audit script patch to recognize number of unmatched entries >> >> man-pages-2.07-7 >> ---------------- >> * Thu Sep 29 2005 Ivana Varekova 2.07-7 >> - fix typo in nsswitch.conf man page (bug 169309) >> >> * Thu Sep 29 2005 Ivana Varekova 2.07-6 >> - man pages updated for new audit system (added missing man-pages >> of some syscalls) (see bug 159225) >> >> * Tue Sep 13 2005 Ivana Varekova 2.07-5 >> - change termcap SEE ALSO part - bug 168131 >> >> mc-1:4.6.1a-0.16 >> ---------------- >> * Thu Sep 29 2005 Jindrich Novy 4.6.1a-0.16 >> - fix memory leak in mc-utf8 patch, thanks to Marcin Garski (#169549) >> - fix mc-find patch to support UTF-8, thanks to Victor Abramoff (#169531) >> - remove bogus condition from mc-symcrash patch >> >> mkinitrd-5.0.2-1 >> ---------------- >> * Thu Sep 29 2005 Peter Jones - 5.0.2-1 >> - add error and quiet printf functions >> - use them instead of testing quiet and typing stderr everywhere >> - actually make _all_ errors use eprintf (and thus stderr) >> - print strerror in errors instead of raw errno >> - make "getKernelCmdLine use readFD >> - make "getKernelArg" picky about if you've got the right command vs >> just one that starts with the same string >> - make "getKernelArg" handle "=" for you, so it either gives you the value >> when there is one, '\0' when there's not and it's EOL, or whitespace. >> - reformat some two-space-indent spots >> - check for short reads in catCommand >> - kill pivotroot >> - cleaned up resume messages >> - make mkrootdev use readFD >> - combine mkdevies and makedevs into mkblkdevs, no longer >> using /proc/partitions >> - don't use callocs+memcpy/strcpy+strcat when we can use asprintf >> - make setQuietCommand use getKenrelArg >> - make runStartup use readFD >> - patch from Alexandre Oliva to fix LVM-on-RAID1 /root and swap-on-LVM >> (bz #169059) >> - reorder device creation for easier maintenance create /dev/rtc >> - change fixme comment about lvm vgs >> - use cemit at some places we used a lot of emits before >> - reorder device node creation for clarity >> - use mkblkdevs instead of makedevs and mkdevices >> - decouple loopback root and lvm >> >> * Wed Sep 28 2005 Peter Jones - 5.0.1-1 >> - create /dev/rtc >> - create /dev/tty, /dev/tty{0..11}, and /dev/ttyS{0..4} >> - tweak the messages output in loud mode during device node creation >> >> pkgconfig-1:0.19-1 >> ------------------ >> * Thu Sep 29 2005 Matthias Clasen 1:0.19-1 >> - Update to 0.19 >> - Take ownership of /usr/share/pkgconfig (#169335) >> >> scim-anthy-0.7.0-1.fc5 >> ---------------------- >> * Thu Sep 29 2005 Akira TAGOH - 0.7.0-1 >> - New upstream release. >> >> * Tue Aug 16 2005 Akira TAGOH - 0.6.1-1 >> - New upstream release. >> >> * Tue Aug 09 2005 Akira TAGOH >> - added dist tag in Release. >> >> selinux-policy-strict-1.27.1-11 >> ------------------------------- >> * Thu Sep 29 2005 Dan Walsh 1.27.1-11 >> - Allow reading of public_content_rw_t without setting boolean >> - Fix man pages >> - Fix pppd >> >> selinux-policy-targeted-1.27.1-12 >> --------------------------------- >> * Thu Sep 29 2005 Dan Walsh 1.27.1-12 >> - Allow reading of public_content_rw_t without setting boolean >> - Fix man pages >> - Fix pppd >> >> squid-7:2.5.STABLE11-2 >> ---------------------- >> * Thu Sep 29 2005 Martin Stransky 7:2.5.STABLE11-2 >> - added patch for delay pools and some minor fixes >> >> unixODBC-2.2.11-3 >> ----------------- >> * Thu Sep 29 2005 Tom Lane 2.2.11-3 >> - Force update of yac.h because the copy in the distributed tarball does not >> match bison 2.0's numbering of symbols (bz #162676) >> - Include documentation of text-file driver >> - Use private libltdl so we can omit RTLD_GLOBAL from dlopen flags (bz #161399) >> >> yelp-2.12.1-1 >> ------------- >> * Thu Sep 29 2005 Matthias Clasen - 2.12.1-1 >> - Update to 2.12.1 >> >> Broken deps for i386 >> ---------------------------------------------------------- >> apr-devel - 0.9.6-6.i386 requires gcc = 0:4.0.1 >> >> >> >> Broken deps for x86_64 >> ---------------------------------------------------------- >> apr-devel - 0.9.6-6.x86_64 requires gcc = 0:4.0.1 >> >> >> >> Broken deps for s390 >> ---------------------------------------------------------- >> apr-devel - 0.9.6-6.s390 requires gcc = 0:4.0.1 >> >> >> >> Broken deps for ppc64 >> ---------------------------------------------------------- >> apr-devel - 0.9.6-6.ppc64 requires gcc = 0:4.0.1 >> >> >> >> Broken deps for ppc >> ---------------------------------------------------------- >> apr-devel - 0.9.6-6.ppc requires gcc = 0:4.0.1 >> >> >> >> Broken deps for ia64 >> ---------------------------------------------------------- >> apr-devel - 0.9.6-6.ia64 requires gcc = 0:4.0.1 >> >> >> >> Broken deps for s390x >> ---------------------------------------------------------- >> apr-devel - 0.9.6-6.s390x requires gcc = 0:4.0.1 >> >> >> > -- Vitor Domingos Paradigma.pt From buildsys at redhat.com Sat Oct 1 11:22:21 2005 From: buildsys at redhat.com (Build System) Date: Sat, 1 Oct 2005 07:22:21 -0400 Subject: rawhide report: 20051001 changes Message-ID: <200510011122.j91BML1j023829@porkchop.devel.redhat.com> Updated Packages: Pyrex-0:0.9.3.1-1 ----------------- * Fri Sep 30 2005 John (J5) Palmieri - 0.9.3.1-1 - update to 0.9.3.1 - remove gcc4 patch which is incorporated in this release anaconda-10.3.0.27-1 -------------------- * Fri Sep 30 2005 Chris Lumens 10.3.0.27-1 - More kickstart script fixes. apr-0.9.6-7 ----------- * Fri Sep 30 2005 Florian La Roche - rebuild for new gcc at-3.1.8-79 ----------- * Fri Sep 30 2005 Tomas Mraz - 3.1.8-79 - use include instead of pam_stack in pam config * Fri Jun 03 2005 Jason Vas Dias 3.1.8-78 - fix bug 159220: add pam_loginuid to pam session stack in /etc/pam.d/atd - fix bug 102341: add '-r' synonym for '-d' / atrm for POSIX / SuS conformance * Fri Apr 08 2005 Jason Vas Dias 3.1.8-77 - always call pam_setcred(pamh, PAM_DELETE_CRED) before session - close coreutils-5.2.1-56 ------------------ * Fri Sep 30 2005 Tomas Mraz - 5.2.1-56 - use include instead of pam_stack in pam config cups-1:1.1.23-19 ---------------- * Fri Sep 30 2005 Tim Waugh 1:1.1.23-19 - Use upstream patch for STR #1284. * Fri Sep 30 2005 Tomas Mraz - use include instead of pam_stack in pam config db4-4.3.28-4 ------------ * Fri Sep 30 2005 Paul Nasrat 4.3.28-4 - Re-enable java for ppc64 dovecot-0.99.14-8.fc5 --------------------- * Fri Sep 30 2005 Tomas Mraz - 0.99.14-8.fc5 - use include instead of pam_stack in pam config * Wed Jul 27 2005 John Dennis - 0.99.14-7.fc5 - fix bug #150888, log authenication failures with ip address ethereal-0.10.12-9 ------------------ * Fri Sep 30 2005 Radek Vokal 0.10.12-9 - use include instead of pam_stack in pam config freeradius-1.0.4-3 ------------------ * Fri Sep 30 2005 Tomas Mraz - 1.0.4-3 - use include instead of pam_stack in pam config gnome-netstatus-2.12.0-1 ------------------------ * Thu Sep 08 2005 Matthias Clasen - 2.12.0-1 - Update to 2.12.0 - handle figures being absent gnome-panel-2.12.0-3 -------------------- * Fri Sep 30 2005 Mark McLoughlin 2.12.0-3 - Remove hacks to add battery applet to default panel configuration where ACPI/APM is available (#169621) and GIMLET in CJK locales (#169430) gnome-themes-2.12.0-2 --------------------- * Fri Sep 30 2005 Matthias Clasen - 2.12.0-2 - Fix pixmap paths - Actually apply the redmond patch gtk2-2.8.4-2 ------------ * Fri Sep 30 2005 Matthias Clasen 2.8.4-2 - Prevent an overflow in size hints handling kdemultimedia-6:3.4.91-1 ------------------------ * Fri Sep 30 2005 Than Ngo 6:3.4.91-1 - update to KDE 3.5 beta1 * Mon Aug 15 2005 Than Ngo 6:3.4.2-2 - apply CVS patch to fix kscd crash kdeutils-6:3.4.91-1 ------------------- * Fri Sep 30 2005 Than Ngo 6:3.4.91-1 - update to 3.5 beta1 kernel-2.6.13-1.1588_FC5 ------------------------ man-pages-ja-20050915-2 ----------------------- * Fri Sep 30 2005 Florian La Roche - remove man-page now part of shadow-utils mkinitrd-5.0.3-1 ---------------- * Fri Sep 30 2005 Peter Jones - 5.0.3-1 - fix root dev discovery to give us "hda3" and such again, rather than a full sysfs path ncurses-5.4-19 -------------- * Fri Sep 30 2005 5.4-19 5.4-19 - Clear window after: filter()+initscr()+endwin()+refresh() See bug #2966, patch ncurses-5.4-filter.patch newt-0.52.1-0 ------------- * Fri Sep 30 2005 Petr Rockai - 0.52.1-0 - revert bidi patch, objections by Jeremy Katz about anaconda breaking - this version still only exists as a "ghastly" upstream tarball; the patches are now cleaned up and will be integrated into rhlinux cvs unless some more breakage akin to bidi occurs - the if1close patch is now part of upstream tarball too * Wed Sep 21 2005 Petr Rockai - 0.52.0-0 - new upstream version openldap-2.2.28-2 ----------------- * Thu Sep 29 2005 Jay Fenlason 2.2.28-2 - Upgrade to nev upstream version. This makes the 2.2.*-hop patch obsolete. * Mon Aug 22 2005 Jay Fenlason 2.2.26-2 - Move the slapd.pem file to /etc/pki/tls/certs and edit the -config patch to match to close bz#143393 Creates certificates + keys at an insecure/bad place - also use _sysconfdir instead of hard-coding /etc * Thu Aug 11 2005 Jay Fenlason - Add the tls-fix-connection-test patch to close bz#161991 openldap password disclosure issue - add the hop patches to prevent infinite looping when chasing referrals. OpenLDAP ITS #3578 pam-0.80-9 ---------- * Fri Sep 30 2005 Tomas Mraz 0.80-9 - don't include ps and pdf docs (#168823) - new common config file for configuration utilities - remove glib2 dependency (#166979) pm-utils-0.05-1 --------------- * Fri Sep 30 2005 Bill Nottingham - 0.05-1 - check for presence of various tools/files before using them (#169560, #196562) redhat-artwork-0.128-2 ---------------------- * Fri Sep 30 2005 Matthias Clasen 0.128-2 - Only call gtk-update-icon-cache for directories which have an index.theme file. (#16795) stunnel-4.12-1 -------------- * Fri Sep 30 2005 Miloslav Trmac - 4.12-1 - Update to stunnel-4.12 system-config-users-1.2.40-2 ---------------------------- * Fri Sep 30 2005 Nils Philippsen - 1.2.40 - initialize shadow variables only if shadow passwords are used (#168524, #168529, patch by Josef Whiter) udev-069-6 ---------- * Fri Sep 30 2005 Harald Hoyer - 069-6 - special handling of IEEE1394 firewire devices (bug #168093) yum-2.4.0-5 ----------- * Tue Sep 27 2005 Jeremy Katz - 2.4.0-5 - add yum-cli dir (#169334) Broken deps for s390x ---------------------------------------------------------- ntsysv - 1.3.20-1.s390x requires libnewt.so.0.51()(64bit) netconfig - 0.8.22-1.s390x requires libnewt.so.0.51()(64bit) newt-perl - 1.08-8.s390x requires libnewt.so.0.51()(64bit) crypto-utils - 2.2-6.s390x requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.s390x requires libnewt.so.0.51()(64bit) setuptool - 1.17.1-1.s390x requires libnewt.so.0.51()(64bit) Broken deps for ppc64 ---------------------------------------------------------- newt-perl - 1.08-8.ppc64 requires libnewt.so.0.51()(64bit) ntsysv - 1.3.20-1.ppc64 requires libnewt.so.0.51()(64bit) crypto-utils - 2.2-6.ppc64 requires libnewt.so.0.51()(64bit) setuptool - 1.17.1-1.ppc64 requires libnewt.so.0.51()(64bit) netconfig - 0.8.22-1.ppc64 requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.ppc64 requires libnewt.so.0.51()(64bit) Broken deps for s390 ---------------------------------------------------------- system-config-securitylevel-tui - 1.6.4-1.s390 requires libnewt.so.0.51 newt-perl - 1.08-8.s390 requires libnewt.so.0.51 crypto-utils - 2.2-6.s390 requires libnewt.so.0.51 setuptool - 1.17.1-1.s390 requires libnewt.so.0.51 netconfig - 0.8.22-1.s390 requires libnewt.so.0.51 ntsysv - 1.3.20-1.s390 requires libnewt.so.0.51 Broken deps for ia64 ---------------------------------------------------------- netconfig - 0.8.22-1.ia64 requires libnewt.so.0.51()(64bit) ntsysv - 1.3.20-1.ia64 requires libnewt.so.0.51()(64bit) setuptool - 1.17.1-1.ia64 requires libnewt.so.0.51()(64bit) newt-perl - 1.08-8.ia64 requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.ia64 requires libnewt.so.0.51()(64bit) crypto-utils - 2.2-6.ia64 requires libnewt.so.0.51()(64bit) Broken deps for i386 ---------------------------------------------------------- system-config-securitylevel-tui - 1.6.4-1.i386 requires libnewt.so.0.51 setuptool - 1.17.1-1.i386 requires libnewt.so.0.51 netconfig - 0.8.22-1.i386 requires libnewt.so.0.51 newt-perl - 1.08-8.i386 requires libnewt.so.0.51 crypto-utils - 2.2-6.i386 requires libnewt.so.0.51 ntsysv - 1.3.20-1.i386 requires libnewt.so.0.51 Broken deps for ppc ---------------------------------------------------------- ntsysv - 1.3.20-1.ppc requires libnewt.so.0.51 crypto-utils - 2.2-6.ppc requires libnewt.so.0.51 system-config-securitylevel-tui - 1.6.4-1.ppc requires libnewt.so.0.51 netconfig - 0.8.22-1.ppc requires libnewt.so.0.51 newt-perl - 1.08-8.ppc requires libnewt.so.0.51 setuptool - 1.17.1-1.ppc requires libnewt.so.0.51 Broken deps for x86_64 ---------------------------------------------------------- setuptool - 1.17.1-1.x86_64 requires libnewt.so.0.51()(64bit) netconfig - 0.8.22-1.x86_64 requires libnewt.so.0.51()(64bit) ntsysv - 1.3.20-1.x86_64 requires libnewt.so.0.51()(64bit) newt-perl - 1.08-8.x86_64 requires libnewt.so.0.51()(64bit) crypto-utils - 2.2-6.x86_64 requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.x86_64 requires libnewt.so.0.51()(64bit) From laroche at redhat.com Sat Oct 1 13:48:40 2005 From: laroche at redhat.com (Florian La Roche) Date: Sat, 1 Oct 2005 15:48:40 +0200 Subject: announce: rpmdb checker, machine status checker In-Reply-To: <20050907122536.GA2876@dudweiler.stuttgart.redhat.com> References: <20050907122536.GA2876@dudweiler.stuttgart.redhat.com> Message-ID: <20051001134840.GA7571@dudweiler.stuttgart.redhat.com> On Wed, Sep 07, 2005 at 12:25:36PM +0000, Florian La Roche wrote: > Here is a python script that can analyse a rpmdb and also help > determining the status of an installed machine: A more complete docu (thanks to asciidoc) for the PyRPM scripts is now available at: http://people.redhat.com/laroche/pyrpm/ > Let me know if you have questions about this tool, have ideas > about further checks that can be added or have problems using > it. (Especially if you have real broken rpmdb files on some of > your machines, I'd like to hear if some checks could be improved. ;-) The checkrpmdb parts should be fairly well tested by now. Dependency checks and further checks are also added now. See above link for more detailed information. greetings, Florian La Roche From buildsys at redhat.com Sun Oct 2 11:28:08 2005 From: buildsys at redhat.com (Build System) Date: Sun, 2 Oct 2005 07:28:08 -0400 Subject: rawhide report: 20051002 changes Message-ID: <200510021128.j92BS8X5000782@porkchop.devel.redhat.com> Updated Packages: gnome-icon-theme-2.12.0-2 ------------------------- * Sat Oct 01 2005 Matthias Clasen - 2.12.0-2 - Only call gtk-update-icon-cache on directories which have a theme index file gnome-screensaver-0.0.14-1 -------------------------- * Thu Sep 29 2005 Matthias Clasen 0.0.14-1 - Update to 0.0.14 - Drop upstreamed patches kernel-2.6.13-1.1589_FC5 ------------------------ * Sun Oct 02 2005 Dave Jones - 2.6.14-rc3-git1 memtest86+-1.65-1 ----------------- * Sat Oct 01 2005 Warren Togami - 1.65-1 - 1.65 * Wed Jun 29 2005 Warren Togami - 1.60-1 - 1.60 * Mon Mar 28 2005 Warren Togami - 1.55.1-1 - 1.55.1 fixes K8 openoffice.org-1:2.0.0-1.2.2 ---------------------------- * Thu Sep 29 2005 Caolan McNamara - 1:2.0.0-1.2 - add mmeeks workspace.atkbridge for rh#169323# acessibility perl-PDL-2.4.2-2.fc5 -------------------- * Sun Sep 25 2005 Warren Togami - 2.4.2-2 - Ship pdldoc.db, tune build dependencies and file permissions (#163219 scop) * Fri May 27 2005 Warren Togami - 2.4.2-1 - 2.4.2 - filter perl(Inline) from provides (#158733) tsclient-0.140-1 ---------------- * Sun Oct 02 2005 Matthias Clasen 0.140-1 - Update to newer upstream version - Fix a segfault (#169694) Broken deps for x86_64 ---------------------------------------------------------- crypto-utils - 2.2-6.x86_64 requires libnewt.so.0.51()(64bit) newt-perl - 1.08-8.x86_64 requires libnewt.so.0.51()(64bit) netconfig - 0.8.22-1.x86_64 requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.x86_64 requires libnewt.so.0.51()(64bit) setuptool - 1.17.1-1.x86_64 requires libnewt.so.0.51()(64bit) ntsysv - 1.3.20-1.x86_64 requires libnewt.so.0.51()(64bit) Broken deps for ppc ---------------------------------------------------------- system-config-securitylevel-tui - 1.6.4-1.ppc requires libnewt.so.0.51 ntsysv - 1.3.20-1.ppc requires libnewt.so.0.51 newt-perl - 1.08-8.ppc requires libnewt.so.0.51 crypto-utils - 2.2-6.ppc requires libnewt.so.0.51 netconfig - 0.8.22-1.ppc requires libnewt.so.0.51 setuptool - 1.17.1-1.ppc requires libnewt.so.0.51 Broken deps for ia64 ---------------------------------------------------------- ntsysv - 1.3.20-1.ia64 requires libnewt.so.0.51()(64bit) setuptool - 1.17.1-1.ia64 requires libnewt.so.0.51()(64bit) newt-perl - 1.08-8.ia64 requires libnewt.so.0.51()(64bit) crypto-utils - 2.2-6.ia64 requires libnewt.so.0.51()(64bit) netconfig - 0.8.22-1.ia64 requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.ia64 requires libnewt.so.0.51()(64bit) Broken deps for ppc64 ---------------------------------------------------------- setuptool - 1.17.1-1.ppc64 requires libnewt.so.0.51()(64bit) netconfig - 0.8.22-1.ppc64 requires libnewt.so.0.51()(64bit) newt-perl - 1.08-8.ppc64 requires libnewt.so.0.51()(64bit) ntsysv - 1.3.20-1.ppc64 requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.ppc64 requires libnewt.so.0.51()(64bit) crypto-utils - 2.2-6.ppc64 requires libnewt.so.0.51()(64bit) Broken deps for s390x ---------------------------------------------------------- ntsysv - 1.3.20-1.s390x requires libnewt.so.0.51()(64bit) setuptool - 1.17.1-1.s390x requires libnewt.so.0.51()(64bit) netconfig - 0.8.22-1.s390x requires libnewt.so.0.51()(64bit) crypto-utils - 2.2-6.s390x requires libnewt.so.0.51()(64bit) newt-perl - 1.08-8.s390x requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.s390x requires libnewt.so.0.51()(64bit) Broken deps for i386 ---------------------------------------------------------- crypto-utils - 2.2-6.i386 requires libnewt.so.0.51 ntsysv - 1.3.20-1.i386 requires libnewt.so.0.51 system-config-securitylevel-tui - 1.6.4-1.i386 requires libnewt.so.0.51 setuptool - 1.17.1-1.i386 requires libnewt.so.0.51 newt-perl - 1.08-8.i386 requires libnewt.so.0.51 netconfig - 0.8.22-1.i386 requires libnewt.so.0.51 Broken deps for s390 ---------------------------------------------------------- setuptool - 1.17.1-1.s390 requires libnewt.so.0.51 newt-perl - 1.08-8.s390 requires libnewt.so.0.51 system-config-securitylevel-tui - 1.6.4-1.s390 requires libnewt.so.0.51 netconfig - 0.8.22-1.s390 requires libnewt.so.0.51 crypto-utils - 2.2-6.s390 requires libnewt.so.0.51 ntsysv - 1.3.20-1.s390 requires libnewt.so.0.51 From kyrre at solution-forge.net Sun Oct 2 11:34:34 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 02 Oct 2005 13:34:34 +0200 Subject: Installing Rawhide Message-ID: <1128252873.31386.7.camel@localhost.localdomain> What is the currently recomended method of installing Rawhide? I have previously used the boot.iso image to boot the computer, and then install it from a local (another machine on the LAN) copy of the rawhide three, but i can't find the boot.iso image. I know i can install fc4 and yum update, but i want to test anaconda + get an as "pure" as possible install. Kyrre From mike at miketc.com Sun Oct 2 12:44:38 2005 From: mike at miketc.com (Mike Chambers) Date: Sun, 02 Oct 2005 07:44:38 -0500 Subject: Installing Rawhide In-Reply-To: <1128252873.31386.7.camel@localhost.localdomain> References: <1128252873.31386.7.camel@localhost.localdomain> Message-ID: <1128257078.27460.2.camel@scrappy.miketc.com> On Sun, 2005-10-02 at 13:34 +0200, Kyrre Ness Sjobak wrote: > What is the currently recomended method of installing Rawhide? I have > previously used the boot.iso image to boot the computer, and then > install it from a local (another machine on the LAN) copy of the rawhide > three, but i can't find the boot.iso image. > > I know i can install fc4 and yum update, but i want to test anaconda + > get an as "pure" as possible install. It's in the images dir. And I tried to install it yesterday, but it kept erring out during it, and in different places. Might want to give it a few days. Also, the part I saw where you select the type of install (desktop, workstation, etc..) was still in it's infant stages and has work to do. I'd say just do an FC4 install + rawhide updates immediately after and that gets you as close as possible, which is what I did yesterday. -- Mike Chambers Madisonville, KY "Everything is always harder, before it gets easier!" From ggw at wolves.durham.nc.us Sun Oct 2 16:11:44 2005 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Sun, 02 Oct 2005 12:11:44 -0400 Subject: Installing Rawhide In-Reply-To: <1128257078.27460.2.camel@scrappy.miketc.com> References: <1128252873.31386.7.camel@localhost.localdomain> <1128257078.27460.2.camel@scrappy.miketc.com> Message-ID: <20051002161144.GA27856@wolves.durham.nc.us> On Sun, Oct 02, 2005 at 07:44:38AM -0500, Mike Chambers wrote: > On Sun, 2005-10-02 at 13:34 +0200, Kyrre Ness Sjobak wrote: > > What is the currently recomended method of installing Rawhide? I have > > previously used the boot.iso image to boot the computer, and then > > install it from a local (another machine on the LAN) copy of the rawhide > > three, but i can't find the boot.iso image. > > > > I know i can install fc4 and yum update, but i want to test anaconda + > > get an as "pure" as possible install. > > It's in the images dir. And I tried to install it yesterday, but it > kept erring out during it, and in different places. Might want to give > it a few days. Also, the part I saw where you select the type of install > (desktop, workstation, etc..) was still in it's infant stages and has > work to do. > > I'd say just do an FC4 install + rawhide updates immediately after and > that gets you as close as possible, which is what I did yesterday. Actually, last night (this morning) I installed rawhide from the boot.iso and it worked as long as I didn't try to do anything special (like use http of customize my partitions.) The current supported method is nfs-based trees (IIRC) so you need to nfs-export your rawhide tree so the test machine can see it. The package select stuff is quite "primitive" and undergoing heavy modifications. -- 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 laroche at redhat.com Mon Oct 3 10:25:32 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 3 Oct 2005 12:25:32 +0200 Subject: adding more information to repo metadata Message-ID: <20051003102532.GA24262@dudweiler.stuttgart.redhat.com> I've added the below text to http://people.redhat.com/laroche/pyrpm/README.html Adding the "flag" part of dependencies also as integer into the repodata would make it more complete and useful for new tasks. greetings, Florian La Roche Notes about the Repo-Metadata ----------------------------- The following things should be noted about the repo metadata. yum is using the repodata only within the resolver part, then downloads the rpm headers and passes all the headers on to rpmlib to verify again if the resolver of rpmlib is ok as well as doing e.g. the installation ordering part within rpmlib. If the repodata would be more complete, more steps could be done only based on the repodata being available: - Even if no epoch is specified, the metadata still specifies this as "0". For most code paths this is no problem as for all comparisons of version data, a missing epoch is the same as a "0" epoch. This should not be a huge problem and would be only a cleanup item for the repodata. - For dependency information the `flag` part is only partially copied into the repodata. Just adding the `flag` information as integer would make sure all information is present in any case. Extending the repodata to have `intflag` added alongside the old information would be good. - Repo data adds a "pre" flag if the RPMSENSE_PREREQ flag is set. That information is actually not complete to identify install prereq and we need the more complete flag information as requested above to be able todo correct installation ordering based on repodata. - There is a fixed regex string which specifies the filelist information for the primary.xml file. In addition also all files are listed if they appear in any file requires from the same repository. This means that you need to download the full filelist once you work on more than one repository and you have file requirements outside of the fixed regex list. (Detecting the need for full filelists could be done per-repo to give a quite good detection algorithm.) Only possible path for this is to identify problems for several repos where the full filelists need to be downloaded and to add such a requirement into that repo or otherwise add a command line option to add such additional requirements (which should then get also written into the repodata). From laroche at redhat.com Mon Oct 3 10:31:12 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 3 Oct 2005 12:31:12 +0200 Subject: repo metadata written in deterministic order Message-ID: <20051003103112.GA24287@dudweiler.stuttgart.redhat.com> The following patch for createrepo-0.4.3 makes the creation of the xml content more deterministic. The last patches also remove a few newlines, otherwise no data change at all. greetings, Florian La Roche --- createrepo-0.4.1/dumpMetadata.py.lr 2005-10-03 09:25:21.917352873 +0200 +++ createrepo-0.4.1/dumpMetadata.py 2005-10-03 09:25:33.789511255 +0200 @@ -326,7 +326,9 @@ except TypeError: del u # move on to the next method else: - return u.keys() + ret = u.keys() + ret.sort() + return ret # We can't hash all the elements. Second fastest is to sort, # which brings the equal elements together; then duplicates are @@ -421,7 +423,7 @@ for glob in self.filerc: if glob.match(item): returns[item] = 1 - return returns + return returns.keys() def usefulGhosts(self): """search for useful ghost file names""" @@ -432,7 +434,7 @@ for glob in self.filerc: if glob.match(item): returns[item] = 1 - return returns + return returns.keys() def usefulDirs(self): @@ -590,16 +592,22 @@ if prereq == 1: entry.newProp('pre', str(prereq)) - for file in rpmObj.usefulFiles(): + ff = rpmObj.usefulFiles() + ff.sort() + for file in ff: files = format.newChild(None, 'file', None) file = utf8String(file) files.addContent(file) - for directory in rpmObj.usefulDirs(): + ff = rpmObj.usefulDirs() + ff.sort() + for directory in ff: files = format.newChild(None, 'file', None) directory = utf8String(directory) files.addContent(directory) files.newProp('type', 'dir') - for directory in rpmObj.usefulGhosts(): + ff = rpmObj.usefulGhosts() + ff.sort() + for directory in ff: files = format.newChild(None, 'file', None) directory = utf8String(directory) files.addContent(directory) --- createrepo-0.4.1/genpkgmetadata.py.lr 2005-10-03 09:25:28.464337299 +0200 +++ createrepo-0.4.1/genpkgmetadata.py 2005-10-03 09:25:37.454942670 +0200 @@ -238,6 +238,7 @@ files = [] files = getFileList('./', '.rpm', files) files = trimRpms(files, cmds['excludes']) + files.sort() pkgcount = len(files) # setup the base metadata doc @@ -338,19 +339,19 @@ # save them up to the tmp locations: if not cmds['quiet']: print _('Saving Primary metadata') - basefile.write('\n') + basefile.write('\n') basefile.close() basedoc.freeDoc() if not cmds['quiet']: print _('Saving file lists metadata') - flfile.write('\n') + flfile.write('\n') flfile.close() filesdoc.freeDoc() if not cmds['quiet']: print _('Saving other metadata') - otherfile.write('\n') + otherfile.write('\n') otherfile.close() otherdoc.freeDoc() From buildsys at redhat.com Mon Oct 3 11:21:25 2005 From: buildsys at redhat.com (Build System) Date: Mon, 3 Oct 2005 07:21:25 -0400 Subject: rawhide report: 20051003 changes Message-ID: <200510031121.j93BLPcC011819@porkchop.devel.redhat.com> Updated Packages: crypto-utils-2.2-7 ------------------ * Mon Oct 03 2005 Petr Rockai - 2.2-7 - rebuild against newt 0.52 newt-perl-1.08-9 ---------------- * Tue Sep 27 2005 Petr Rockai - 1.08-9 - rebuild against newt 0.52.0 pump-0.8.22-2 ------------- * Mon Oct 03 2005 Petr Rockai - 0.8.22-2 - rebuild against newt 0.52 ruby-1.8.3-3 ------------ * Mon Oct 03 2005 Akira TAGOH - 1.8.3-3 - fixed the wrong file list. the external library for tcl/tk was included in ruby-libs unexpectedly. Broken deps for s390x ---------------------------------------------------------- ntsysv - 1.3.20-1.s390x requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.s390x requires libnewt.so.0.51()(64bit) setuptool - 1.17.1-1.s390x requires libnewt.so.0.51()(64bit) Broken deps for ia64 ---------------------------------------------------------- ntsysv - 1.3.20-1.ia64 requires libnewt.so.0.51()(64bit) setuptool - 1.17.1-1.ia64 requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.ia64 requires libnewt.so.0.51()(64bit) Broken deps for ppc ---------------------------------------------------------- ntsysv - 1.3.20-1.ppc requires libnewt.so.0.51 system-config-securitylevel-tui - 1.6.4-1.ppc requires libnewt.so.0.51 setuptool - 1.17.1-1.ppc requires libnewt.so.0.51 Broken deps for ppc64 ---------------------------------------------------------- ntsysv - 1.3.20-1.ppc64 requires libnewt.so.0.51()(64bit) system-config-securitylevel-tui - 1.6.4-1.ppc64 requires libnewt.so.0.51()(64bit) setuptool - 1.17.1-1.ppc64 requires libnewt.so.0.51()(64bit) Broken deps for s390 ---------------------------------------------------------- system-config-securitylevel-tui - 1.6.4-1.s390 requires libnewt.so.0.51 ntsysv - 1.3.20-1.s390 requires libnewt.so.0.51 setuptool - 1.17.1-1.s390 requires libnewt.so.0.51 Broken deps for i386 ---------------------------------------------------------- ntsysv - 1.3.20-1.i386 requires libnewt.so.0.51 setuptool - 1.17.1-1.i386 requires libnewt.so.0.51 system-config-securitylevel-tui - 1.6.4-1.i386 requires libnewt.so.0.51 Broken deps for x86_64 ---------------------------------------------------------- system-config-securitylevel-tui - 1.6.4-1.x86_64 requires libnewt.so.0.51()(64bit) setuptool - 1.17.1-1.x86_64 requires libnewt.so.0.51()(64bit) ntsysv - 1.3.20-1.x86_64 requires libnewt.so.0.51()(64bit) From katzj at redhat.com Mon Oct 3 17:29:01 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 03 Oct 2005 13:29:01 -0400 Subject: Installing Rawhide In-Reply-To: <1128252873.31386.7.camel@localhost.localdomain> References: <1128252873.31386.7.camel@localhost.localdomain> Message-ID: <1128360541.2944.12.camel@bree.local.net> On Sun, 2005-10-02 at 13:34 +0200, Kyrre Ness Sjobak wrote: > What is the currently recomended method of installing Rawhide? I have > previously used the boot.iso image to boot the computer, and then > install it from a local (another machine on the LAN) copy of the rawhide > three, but i can't find the boot.iso image. The boot.iso should generally be there, unless the compose happens to break for a day or so. NFS installs are likely to work a little better than HTTP/FTP, although I think HTTP/FTP _should_ work at this point (there's a bug about them in text mode, though). Jeremy From kyrre at solution-forge.net Mon Oct 3 17:48:00 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 03 Oct 2005 19:48:00 +0200 Subject: Installing Rawhide In-Reply-To: <20051002161144.GA27856@wolves.durham.nc.us> References: <1128252873.31386.7.camel@localhost.localdomain> <1128257078.27460.2.camel@scrappy.miketc.com> <20051002161144.GA27856@wolves.durham.nc.us> Message-ID: <1128361679.6251.4.camel@localhost.localdomain> s?n, 02.10.2005 kl. 18.11 skrev G.Wolfe Woodbury: > On Sun, Oct 02, 2005 at 07:44:38AM -0500, Mike Chambers wrote: > > On Sun, 2005-10-02 at 13:34 +0200, Kyrre Ness Sjobak wrote: > > > What is the currently recomended method of installing Rawhide? I have > > > previously used the boot.iso image to boot the computer, and then > > > install it from a local (another machine on the LAN) copy of the rawhide > > > three, but i can't find the boot.iso image. > > > > > > I know i can install fc4 and yum update, but i want to test anaconda + > > > get an as "pure" as possible install. > > > > It's in the images dir. And I tried to install it yesterday, but it > > kept erring out during it, and in different places. Might want to give > > it a few days. Also, the part I saw where you select the type of install > > (desktop, workstation, etc..) was still in it's infant stages and has > > work to do. > > > > I'd say just do an FC4 install + rawhide updates immediately after and > > that gets you as close as possible, which is what I did yesterday. > > Actually, last night (this morning) I installed rawhide from the > boot.iso and it worked as long as I didn't try to do anything special > (like use http of customize my partitions.) The current supported > method is nfs-based trees (IIRC) so you need to nfs-export your rawhide > tree so the test machine can see it. > > The package select stuff is quite "primitive" and undergoing heavy > modifications. > > Okey-dokey. Just wait for the first unbroken rawhide three to come along, and install it, then. Anyway, ill be doing a "as tiny as possible while still getting gnome" install and then just yum in the rest so some fringe breaking won't really hurt me... I hope... Kyrre From skvidal at phy.duke.edu Mon Oct 3 17:50:24 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 03 Oct 2005 13:50:24 -0400 Subject: [Yum-devel] adding more information to repo metadata In-Reply-To: <20051003102532.GA24262@dudweiler.stuttgart.redhat.com> References: <20051003102532.GA24262@dudweiler.stuttgart.redhat.com> Message-ID: <1128361825.21665.10.camel@cutter> > - Even if no epoch is specified, the metadata still specifies this as "0". > For most code paths this is no problem as for all comparisons of version > data, a missing epoch is the same as a "0" epoch. This should not be > a huge problem and would be only a cleanup item for the repodata. what does removing 0-epoch items buy us? -sv From laroche at redhat.com Mon Oct 3 17:53:49 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 3 Oct 2005 19:53:49 +0200 Subject: [Rpm-metadata] Re: [Yum-devel] adding more information to repo metadata In-Reply-To: <1128361825.21665.10.camel@cutter> References: <20051003102532.GA24262@dudweiler.stuttgart.redhat.com> <1128361825.21665.10.camel@cutter> Message-ID: <20051003175349.GA1786@dudweiler.stuttgart.redhat.com> On Mon, Oct 03, 2005 at 01:50:24PM -0400, seth vidal wrote: > > - Even if no epoch is specified, the metadata still specifies this as "0". > > For most code paths this is no problem as for all comparisons of version > > data, a missing epoch is the same as a "0" epoch. This should not be > > a huge problem and would be only a cleanup item for the repodata. > > what does removing 0-epoch items buy us? Hello Seth, You can change all algorithms looking at epochs to also first convert all empty epochs to "0" to have things working, then we don't have to change repodata again. It is just something you have to keep in mind if working with repodata compared to data from rpm headers. Keeping to repodata as deployed right now does make lots of sense, that's why things are worded as done above. greetings, Florian La Roche From buildsys at redhat.com Tue Oct 4 11:19:22 2005 From: buildsys at redhat.com (Build System) Date: Tue, 4 Oct 2005 07:19:22 -0400 Subject: rawhide report: 20051004 changes Message-ID: <200510041119.j94BJMBM011742@porkchop.devel.redhat.com> Updated Packages: alsa-lib-1.0.10rc1-2 -------------------- * Tue Sep 27 2005 Martin Stransky 1.0.10rc1-2 - fixes in config files, new ainit (for #166086) checkpolicy-1.27.5-2 -------------------- * Mon Oct 03 2005 Dan Walsh 1.27.5-2 - Rebuild to get latest libsepol chkconfig-1.3.20-2 ------------------ * Mon Oct 03 2005 Petr Rockai - 1.3.20-2 - rebuild against newt 0.52 file-4.15-4 ----------- * Mon Oct 03 2005 Radek Vokal - 4.15-4 - file output for Berkeley DB gains Cracklib (#168917) glib2-2.8.3-1 ------------- * Mon Oct 03 2005 Matthias Clasen - 2.8.3-1 - New upstream version gnome-power-manager-0.2.6-1 --------------------------- gtk2-2.8.5-1 ------------ * Mon Oct 03 2005 Matthias Clasen 2.8.5-1 - New upstream version hexedit-1.2.12-1 ---------------- * Mon Oct 03 2005 Jindrich Novy 1.2.12-1 - update to 1.2.12 - new upstream release introduces "fruit salad" colored hexeditor ;-) (try --color) kernel-2.6.13-1.1592_FC5 ------------------------ * Mon Oct 03 2005 Dave Jones - silence silly debug message in cx88. (#168931) * Mon Oct 03 2005 Dave Jones - bring back ac97 sliders on emu10k1 * Mon Oct 03 2005 Dave Jones - 2.6.14-rc3-git3 libselinux-1.27.2-1 ------------------- * Mon Oct 03 2005 Dan Walsh 1.27.2-1 - Update to latest from NSA * Merged getseuserbyname patch from Dan Walsh. libsemanage-1.3.7-1 ------------------- * Mon Oct 03 2005 Dan Walsh 1.3.7-1 - Update from NSA * Merged patch series from Ivan Gyurdiev. (pointer typedef elimination, file renames, dbase work, backend separation) * Split interfaces from semanage.[hc] into handle.[hc], modules.[hc]. * Separated handle create from connect interface. * Added a constructor for initialization. * Moved up src/include/*.h to src. * Created a symbol map file; dropped dso.h and hidden markings. libsepol-1.9.8-1 ---------------- * Mon Oct 03 2005 Dan Walsh 1.9.8-1 - Upgrade to latest from NSA * Merged pointer typedef elimination patch from Ivan Gyurdiev. * Merged user list function, new mls functions, and bugfix patch from Ivan Gyurdiev. logwatch-6.1.2-7 ---------------- * Mon Oct 03 2005 Ivana Varekova 6.1.2-7 - add audit script patch recognized other unmatched logs - add cron script patch - change sshd script patch mc-1:4.6.1a-0.17 ---------------- * Sun Oct 02 2005 Jindrich Novy 4.6.1a-0.17 - fix duplicated keyboard shortcuts in menus for Czech locale (#169734) - fix ctrl-t page code recoding for Russian locale, thanks to Andy Shevchenko (#163594) pango-1.10.1-1 -------------- * Mon Oct 03 2005 Matthias Clasen - 1.10.1-1 - Newer upstream version - Use the docs which are included in the tarball ruby-1.8.3-4 ------------ * Tue Oct 04 2005 Akira TAGOH - 1.8.3-4 - moved the documents from ruby-libs to ruby-docs, which contains the arch specific thing and to be multilib support. (#168826) setools-2.1.2-2 --------------- setuptool-1.17.2-1 ------------------ * Mon Oct 03 2005 Nalin Dahyabhai 1.17.2-1 - clean up a compiler warning - add a new config file so that the system-config-authentication-tui shows up in the menu now that it's been moved shared-mime-info-0.16-5 ----------------------- * Mon Oct 03 2005 Matthias Clasen - 0.16-5 - Make sure Type1 fonts are recognized as such (#160909) system-config-securitylevel-1.6.4-3 ----------------------------------- * Tue Sep 27 2005 Petr Rockai - 1.6.4-3 - rebuild against newt 0.52.0 tog-pegasus-2:2.5-1 ------------------- From arjanv at redhat.com Tue Oct 4 17:51:20 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 04 Oct 2005 19:51:20 +0200 Subject: tune2fs -m "reserved space?" In-Reply-To: References: Message-ID: <1128448280.2922.25.camel@laptopd505.fenrus.org> On Tue, 2005-10-04 at 12:24 -0500, Justin Conover wrote: > tune2fs > -m reserved-blocks-percentage > -r reserved-blocks-count > > If what I have read is correct, -m by default uses 5% of the disk > space for "reserved root use" On my server at home with a /home of > 1TB thats about 50GB of wasted space. > > Is this reserved space actually used by ANYTHING? Like LVM, some kind > of fragmentation? well for emergency root stuff; logging in without any disk space is hard; lots of stuff wants to make temporary files etc. but your second point it true too: most filesystems (ext3 but most others) start to fragment like hell if they go over about 95% full. Think of it this way: if you have half your disk empty, the filesystem can do a proper job of finding non-fragmented space. If only 0.0001% is free, it has almost no freedom of choice, resulting in "you get it in whatever order some things become free". Those are sort of extremes; there's been a bunch of research and the outcome was that 5% free seems to be sort of the turning point in this respect. I suspect that research predates the Tb sized volumes, so I don't know if it maybe is 1% on such volumes, but then again to some extend the freedom needed will scale with the FS size -------------- 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 Tue Oct 4 17:51:20 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 04 Oct 2005 19:51:20 +0200 Subject: tune2fs -m "reserved space?" In-Reply-To: References: Message-ID: <1128448280.2922.25.camel@laptopd505.fenrus.org> On Tue, 2005-10-04 at 12:24 -0500, Justin Conover wrote: > tune2fs > -m reserved-blocks-percentage > -r reserved-blocks-count > > If what I have read is correct, -m by default uses 5% of the disk > space for "reserved root use" On my server at home with a /home of > 1TB thats about 50GB of wasted space. > > Is this reserved space actually used by ANYTHING? Like LVM, some kind > of fragmentation? well for emergency root stuff; logging in without any disk space is hard; lots of stuff wants to make temporary files etc. but your second point it true too: most filesystems (ext3 but most others) start to fragment like hell if they go over about 95% full. Think of it this way: if you have half your disk empty, the filesystem can do a proper job of finding non-fragmented space. If only 0.0001% is free, it has almost no freedom of choice, resulting in "you get it in whatever order some things become free". Those are sort of extremes; there's been a bunch of research and the outcome was that 5% free seems to be sort of the turning point in this respect. I suspect that research predates the Tb sized volumes, so I don't know if it maybe is 1% on such volumes, but then again to some extend the freedom needed will scale with the FS size -------------- 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: -------------- next part -------------- -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From fedora at camperquake.de Tue Oct 4 17:55:31 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 4 Oct 2005 19:55:31 +0200 Subject: tune2fs -m "reserved space?" In-Reply-To: <1128448280.2922.25.camel@laptopd505.fenrus.org> References: <1128448280.2922.25.camel@laptopd505.fenrus.org> Message-ID: <20051004195531.0f4e9860@nausicaa.camperquake.de> Hi. Arjan van de Ven wrote: > I suspect that research predates the Tb sized volumes, so I don't know > if it maybe is 1% on such volumes, but then again to some extend the > freedom needed will scale with the FS size With current disk sizes being what they are maybe we ought to default to "5% or 1GB, whichever is less"? -- "HELO. My $name is sendmail.cf. Prepare to vi." -- Peter Gutmann From pjones at redhat.com Tue Oct 4 18:49:16 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 04 Oct 2005 14:49:16 -0400 Subject: tune2fs -m "reserved space?" In-Reply-To: <1128448280.2922.25.camel@laptopd505.fenrus.org> References: <1128448280.2922.25.camel@laptopd505.fenrus.org> Message-ID: <1128451756.3361.18.camel@localhost.localdomain> On Tue, 2005-10-04 at 19:51 +0200, Arjan van de Ven wrote: > Think of it this way: if you have half your disk empty, the filesystem > can do a proper job of finding non-fragmented space. > If only 0.0001% is free, it has almost no freedom of choice, resulting > in "you get it in whatever order some things become free". > Those are sort of extremes; there's been a bunch of research and the > outcome was that 5% free seems to be sort of the turning point in this > respect. > > I suspect that research predates the Tb sized volumes, so I don't know > if it maybe is 1% on such volumes, but then again to some extend the > freedom needed will scale with the FS size Obviously I've not done real research on the subject, but wouldn't you expect it to scale according to the write pattern when you're under low space pressure? Or, to put it differently, if I've got a 100MB disk with 5MB free and I'm trying to write a 4kB file, the fs has a similar degree of freedom to the case of a 100GB disk with 5GB free where I'm trying to do a 4MB write, doesn't it? Whereas obviously it has much less freedom on the smaller disk with a 4MB write. It seems like the necessary free space percentage varies according to your data and IO pattern rather than according to the FS size. (Granted, the requirements of people who have terabytes of storage probably dictate larger files, larger IOs, and lower relative latencies than that of people with mere tens of gigs, so I would expect some *correlation* to filesystem size.) -- Peter From petro at mail.ru Wed Oct 5 03:39:03 2005 From: petro at mail.ru (Peter Lemenkov) Date: Tue, 4 Oct 2005 23:39:03 -0400 Subject: Self-introduction: Peter Lemenkov Message-ID: Hello All! Full legal name: Peter Lemenkov Country, City: Russia, Moscow Profession: Programmer. Company: Elecsnet. *Which packages do you want to see published?* I want to see more games (most important! :), GIS-related stuff, some scientific softwate and cross-compiling tools (MinGW, Wine-related, etc). *Do you want to do QA?* Yes, I do. *Anything else special?* My current personal interests are: * Porting software from different OS to Linux * GIS-related softwate. * Alternate window-managers * Tools for software-engineering. * all i forget to mention :) *What other projects have you worked on in the past?* Publicly available are: * Monkey's Audio mligin for AlsaPlayer http://sourceforge.net/projects/mac-engine * OpenSoundServer, opensource-platform for building multizone high-end multimedia-servers (incomplete for some reasons). http://sourceforge.net/projects/freesoundserver * Miranda-IM for Linux http://paula.comtv.ru/miranda.index.html *What computer languages and other skills do you know?* C/C++, shell-scripting (Bash), Python. 4 years of Linux-programming. About 7 years of Windows-programming. *Why should we trust you?* Trust me? No more or less than trust others in over-the-world Opensource Community :). [petro at Petro ~]$ gpg --fingerprint BDF90694 pub 1024D/BDF90694 2005-10-05 Key fingerprint = 9151 A26B B7C9 0026 ED5D 9DB1 E5C2 33FA BDF9 0694 uid Peter Lemenkov (Petro) sub 2048g/5F06C540 2005-10-05 -- With best regards, Peter Lemenkov. From aoliva at redhat.com Wed Oct 5 04:16:01 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 05 Oct 2005 01:16:01 -0300 Subject: OT: SCALE 4x -- Call For Papers In-Reply-To: <200509062052.27136.loony@loonybin.org> (Peter Arremann's message of "Tue, 6 Sep 2005 20:52:27 -0400") References: <200509062051.30109.loony@loonybin.org> <200509062052.27136.loony@loonybin.org> Message-ID: On Sep 6, 2005, Peter Arremann wrote: > Sorry guys - Just trying to prove what a moron I can be when I'm on cold > medicine... :-) Nah, you're just another victim of the broken Reply-To setting in this list, that causes both replies and follow-ups to go to the list. :-/ -- Alexandre Oliva http://www.lsd.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 admin at ramshacklestudios.com Wed Oct 5 05:38:08 2005 From: admin at ramshacklestudios.com (Peter Gordon) Date: Tue, 04 Oct 2005 22:38:08 -0700 Subject: OT: SCALE 4x -- Call For Papers In-Reply-To: References: <200509062051.30109.loony@loonybin.org> <200509062052.27136.loony@loonybin.org> Message-ID: <1128490688.3103.3.camel@localhost.localdomain> On Wed, 2005-10-05 at 01:16 -0300, Alexandre Oliva wrote: > Nah, you're just another victim of the broken Reply-To setting in this > list, that causes both replies and follow-ups to go to the list. :-/ Or it could be a case of accidentally hitting "Reply to all" instead of "Reply." I do that sometimes when I haven't had my caffeine yet. :O -- () The ASCII Ribbon Campaign - against HTML Email, /\ vCards, and proprietary formats. --------------------------------------------------- Peter A. Gordon (codergeek42) E-Mail: admin at ramshacklestudios.com GnuPG Public Key ID: 0x87C59026 Encrypted and/or Signed correspondence preffered. My blog: http://peter.ramshacklestudios.com/blog/ --------------------------------------------------- -------------- 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 redhat at olen.net Wed Oct 5 07:06:35 2005 From: redhat at olen.net (Ola Thoresen) Date: Wed, 5 Oct 2005 07:06:35 +0000 (UTC) Subject: 32/64 bit ints Message-ID: I think some numers are confused on 64bit archs. Two examples: $ uptime 08:47:02 up 1 day, 23:43, 11 users, load average: -374899.72, 142375.93, -198031.55 $ /sbin/ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2909367160314717 errors:0 dropped:0 overruns:0 frame:0 TX packets:2955499303130049 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2955499304287395 (2.6 PiB) TX bytes:12715341303619034882 (1.4 EiB) Not sure what packages are involved here, but this is i fully updated RawHide. (I do have both i686 and x86_64 glibc and several other libs). $ rpm -qf procps procps-3.2.5-7 $ uname -rvm 2.6.13-1.1589_FC5 #1 SMP Sun Oct 2 01:12:26 EDT 2005 x86_64 Rgds. Ola Thoresen From mihai at xcyb.org Wed Oct 5 06:13:03 2005 From: mihai at xcyb.org (Mihai Maties) Date: Wed, 5 Oct 2005 09:13:03 +0300 Subject: OT: SCALE 4x -- Call For Papers In-Reply-To: References: <200509062052.27136.loony@loonybin.org> Message-ID: <200510050913.03869.mihai@xcyb.org> On Wednesday 05 October 2005 07:16, Alexandre Oliva wrote: > On Sep 6, 2005, Peter Arremann wrote: > > Sorry guys - Just trying to prove what a moron I can be when I'm on cold > > medicine... :-) > > Nah, you're just another victim of the broken Reply-To setting in this > list, that causes both replies and follow-ups to go to the list. :-/ Not quite. As opposed to other mailing list managers Mailman _does the right thing_ i.e. not overriding the Reply-To header that your MUA set (but adding the list address to the header). A quick usefull example: I am subscribed to a list, I post an urgent issue but I want the reply to go to some other email address (that uses an SMS gateway so I'll receive the reply on my cellphone). The fact that the SMS service I use is not free I do not want to receive all the list traffic, but only the part that covers my issue. If I want to do this I set the Reply-To header to user at sms-gateway.com and wait... It's actually a matter of choice: for the initial poster - if he wants to set the Reply-To header or not and to you (the one who reply) - if you want to keep his personal email address as a recipient or not. But again: Mailman does the _right thing_. Mihai From tmus at tmus.dk Wed Oct 5 10:44:16 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 05 Oct 2005 12:44:16 +0200 Subject: glib g_return_val_if_fail problems with gcc4 (__PRETTY_FUNCTION__??) Message-ID: Hi... I have a small piece of code that utilizes the g_return_val_if_fail macro from glib... that macro wraps the g_return_if_fail_warning function, but building with gcc4 -Wall -Werror -ansi makes it spew the following error at every call to g_return_val_if_fail warning: passing argument 2 of 'g_return_if_fail_warning' discards qualifiers from pointer target type i'm not calling g_return_if_fail_warning directly from anywhere within my code. this is all very strange to me... if i do the exact same build with gcc32, I have no problems... Could anyone advise if this is a bug or if perhaps i need some gcc4 specific options to make this work properly? thanks in advance /Thomas From fedora at camperquake.de Wed Oct 5 10:47:57 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 5 Oct 2005 12:47:57 +0200 Subject: 32/64 bit ints In-Reply-To: References: Message-ID: <20051005104757.GA11109@ryoko.camperquake.de> On Wed, Oct 05, 2005 at 07:06:35AM +0000, Ola Thoresen wrote: > TX packets:2955499303130049 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:2955499304287395 (2.6 PiB) TX bytes:12715341303619034882 (1.4 EiB) I think it is fascinating that someone went though the trouble to add prefixes for Peta and Exa. From buildsys at redhat.com Wed Oct 5 11:17:14 2005 From: buildsys at redhat.com (Build System) Date: Wed, 5 Oct 2005 07:17:14 -0400 Subject: rawhide report: 20051005 changes Message-ID: <200510051117.j95BHEm4001846@porkchop.devel.redhat.com> Updated Packages: audit-1.0.5-1 ------------- * Tue Oct 04 2005 Steve Grubb 1.0.5-1 - ausearch can now search on SE Linux contexts - added aureport program to analyse logs - aureport added report option for each log's start and end time - increased random number selected for initial seq number in auditd - add new user space defines to libaudit.h - add add standard logging functions to libaudit * Fri Sep 23 2005 Steve Grubb 1.0.4-1 - Make rate & backlog 32 bit unsigned int in auditctl - In auditctl, if -F arch is given with -t option, don't require list - Update auditd man page - Add size check to audit_send - Update message for audit_open failure when kernel doesn't support audit * Mon Aug 22 2005 Steve Grubb 1.0.3-1 - adjust file perms of newly created log file in auditd - fix 2 memory leaks and an out of bounds access in auditd - fix case where auditd was closing netlink descriptor too early - fix watch rules not to take field arguments in auditctl - fix bug where inode, devmajor, devminor, exit, and success fields in auditctl rules were not getting the correct value stored checkpolicy-1.27.6-1 -------------------- * Tue Oct 04 2005 Dan Walsh 1.27.6-1 - Latest upgrade from NSA * Merged MLS in modules patch from Joshua Brindle (Tresys). gtkhtml3-3.8.1-1 ---------------- * Tue Oct 04 2005 David Malcolm - 3.8.1-1 - 3.8.1 kdeadmin-7:3.4.91-1 ------------------- * Tue Oct 04 2005 Than Ngo 7:3.4.91-1 - update to 3.5 Beta 1 kdesdk-3.4.91-1 --------------- * Tue Oct 04 2005 Than Ngo 2:3.4.91-1 - update to 3.5 Beta 1 kernel-2.6.13-1.1594_FC5 ------------------------ * Tue Oct 04 2005 Dave Jones - 2.6.14-rc3-git4 * Tue Oct 04 2005 Dave Jones - canonicalise getxattr results. libselinux-1.27.3-1 ------------------- * Tue Oct 04 2005 Dan Walsh 1.27.3-1 - Update to latest from NSA * Changed getseuserbyname to not require (and ignore if present) the MLS level in seusers.conf if MLS is disabled, setting *level to NULL in this case. libsemanage-1.3.8-1 ------------------- * Tue Oct 04 2005 Dan Walsh 1.3.8-1 - Update from NSA * Merged iterate, redistribute, and dbase split patches from Ivan Gyurdiev. libsepol-1.9.10-1 ----------------- * Tue Oct 04 2005 Dan Walsh 1.9.10-1 - Upgrade to latest from NSA * Merged iterate patch from Ivan Gyurdiev. * Merged MLS in modules patch from Joshua Brindle (Tresys). ncpfs-2.2.4-10 -------------- * Tue Oct 04 2005 Martin Stransky 2.2.4-10 - fix for #169080 (buffer overflow detected: ncplogin terminated) netdump-0.7.14-1 ---------------- * Tue Oct 04 2005 Dave Anderson 0.7.14-1 - Fix for a redundant data structure declaration for the ia64 build. - Cleaned up numerous compiler warnings. * Tue Oct 04 2005 Dave Anderson 0.7.12-1 - Close vmcore before netdump-reboot script is run, allowing unimpeded usage of the file by a custom script. (BZ #165100) - Creates target /var/crash/ directory on the fly if it does not exist or has been removed. (BZ #162586, BZ #162587) - Made /etc/sysconfig/netdump %config(noreplace) (BZ #168601) - Generate syslog messages if any script fails to execute. - Use sparse file space in vmcore if page is zero-filled. - Update README.client re: usage of alt-sysrq-c for forced crashes. (BZ #159261) nss_ldap-243-1 -------------- * Tue Oct 04 2005 Nalin Dahyabhai 243-1 - update to nss_ldap 243 postgresql-8.0.4-2 ------------------ * Tue Oct 04 2005 Tom Lane 8.0.4-2 - Add rpath to plperl.so (bug #162198) * Tue Oct 04 2005 Tom Lane 8.0.4-1 - Update to PostgreSQL 8.0.4, PyGreSQL 3.6.2, and jdbc driver build 312 - Adjust pgtcl link command to ensure it binds to correct libpq (bug #166665) - Remove obsolete Conflicts: against other python versions (bug #166754) - Add /etc/pam.d/postgresql (bug #167040) - Include contrib/xml2 in build (bug #167492) selinux-policy-strict-1.27.1-13 ------------------------------- * Tue Oct 04 2005 Dan Walsh 1.27.1-13 - Fixes for pegasus, add newrole policy for targeted - Fixes for postgres selinux-policy-targeted-1.27.1-13 --------------------------------- * Tue Oct 04 2005 Dan Walsh 1.27.1-13 - Fixes for pegasus, add newrole policy for targeted - Fixes for postgres sqlite-3.2.7-2 -------------- * Tue Oct 04 2005 Jeremy Katz - 3.2.7-2 - no more static file or libtool archive (#169874) sysreport-1.4.2-2 ----------------- * Tue Oct 04 2005 Than Ngo 1.4.2-2 - add missing man pages #165622 * Tue Jul 12 2005 Than Ngo 1.4.2-1 - 1.4.2 release * Tue Jul 12 2005 Than Ngo 1.4.1-5 - security fix #162978, CAN-2005-2104 system-config-users-1.2.41-1 ---------------------------- * Tue Oct 04 2005 Nils Philippsen - 1.2.41 - fix variable names to prevent hangs when adding a group (#169730) vsftpd-2.0.3-11 --------------- * Tue Oct 04 2005 Radek Vokal 2.0.3-11 - use include instead of pam_stack in pam config From roe at liveglobalbid.com Wed Oct 5 16:38:06 2005 From: roe at liveglobalbid.com (Roe Peterson) Date: Wed, 05 Oct 2005 10:38:06 -0600 Subject: kernel-2.6.13-1.1526_FC4smp can't see my mptscsi controller... Message-ID: <4344016E.4090803@liveglobalbid.com> I hope this is the right list. Apologies in advance if not; anyway, here we go. I've just recently installed FC4 "everything" on a Dell Precision 650 w/ dual xeons CPUS. Everything worked perfectly running kernel-2.6.11-1.1369_FC4smp. After running a complete "yum update" - and going through a few hoops to satisfy dependencies - kernel-2.6.13-1.1526_FC4smp was installed. Unfortunately, the new kernel simply doesn't see my scsi controller. I've manually rebuilt the initrd for the kernel, and verified that the necessary modules are included (scsi, mptbase, mptscsi, etc). Before I start digging, I wonder if anyone has seen this yet; if so, I'd really appreciate a pointer in the right direction. If not, a pointer in the right direction would still be very nice :-) Thanks in advance. From pjones at redhat.com Wed Oct 5 17:25:38 2005 From: pjones at redhat.com (Peter Jones) Date: Wed, 05 Oct 2005 13:25:38 -0400 Subject: kernel-2.6.13-1.1526_FC4smp can't see my mptscsi controller... In-Reply-To: <4344016E.4090803@liveglobalbid.com> References: <4344016E.4090803@liveglobalbid.com> Message-ID: <1128533139.14097.20.camel@localhost.localdomain> On Wed, 2005-10-05 at 10:38 -0600, Roe Peterson wrote: > I hope this is the right list. Apologies in advance if not; anyway, here > we go. Probably better to file a bugzilla. > I've just recently installed FC4 "everything" on a Dell Precision 650 w/ > dual xeons CPUS. Everything worked perfectly running > kernel-2.6.11-1.1369_FC4smp. > > After running a complete "yum update" - and going through a few > hoops to satisfy dependencies - kernel-2.6.13-1.1526_FC4smp was > installed. > > Unfortunately, the new kernel simply doesn't see my scsi controller. > > I've manually rebuilt the initrd for the kernel, and verified that the > necessary modules are included (scsi, mptbase, mptscsi, etc). > > Before I start digging, I wonder if anyone has seen this yet; if so, > I'd really appreciate a pointer in the right direction. If not, a > pointer in the right direction would still be very nice :-) I see the same thing on my HP xw9300 (viper). As another datapoint, it's a PCI-X device. In older kernels, the PCI-X controller is the second nVidia CK804 Memory Controller listed by "lspci", 01.0, and normal pci is the first, 00.0. With current kernels the second controller doesn't show up at all, nor do any of the devices underneath it. -- Peter From davej at redhat.com Wed Oct 5 19:03:09 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 5 Oct 2005 15:03:09 -0400 Subject: 32/64 bit ints In-Reply-To: References: Message-ID: <20051005190309.GA10640@redhat.com> On Wed, Oct 05, 2005 at 07:06:35AM +0000, Ola Thoresen wrote: > I think some numers are confused on 64bit archs. > Two examples: > > $ uptime > 08:47:02 up 1 day, 23:43, 11 users, load average: -374899.72, 142375.93, -198031.55 > .... > $ uname -rvm > 2.6.13-1.1589_FC5 #1 SMP Sun Oct 2 01:12:26 EDT 2005 x86_64 Someone filed a bug on this last week, and then reported it 'went away' a day or so later. Can you retry with the latest rawhide ? Dave From davej at redhat.com Wed Oct 5 20:56:26 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 5 Oct 2005 16:56:26 -0400 Subject: kernel-2.6.13-1.1526_FC4smp can't see my mptscsi controller... In-Reply-To: <1128533139.14097.20.camel@localhost.localdomain> References: <4344016E.4090803@liveglobalbid.com> <1128533139.14097.20.camel@localhost.localdomain> Message-ID: <20051005205626.GC10640@redhat.com> On Wed, Oct 05, 2005 at 01:25:38PM -0400, Peter Jones wrote: > On Wed, 2005-10-05 at 10:38 -0600, Roe Peterson wrote: > > I hope this is the right list. Apologies in advance if not; anyway, here > > we go. > > Probably better to file a bugzilla. Sounds like https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169610 Dave From vd at paradigma.pt Thu Oct 6 00:54:40 2005 From: vd at paradigma.pt (Vitor Domingos) Date: Thu, 06 Oct 2005 01:54:40 +0100 Subject: USB camera on kernel 2.6.13-1.1586_FC5 Message-ID: <434475D0.6050604@paradigma.pt> While using my camera with fedora, I've got this problem and cannot use nautilus on the device (computer, camera), but rather on the mount point (/media/usbdisk). Here's the output: usb 3-1: new full speed USB device using uhci_hcd and address 2 SCSI subsystem initialized Initializing USB Mass Storage driver... scsi0 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usbcore: registered new driver usb-storage USB Mass Storage support registered. Vendor: NIKON Model: NIKON DSC E3700 Rev: 1.00 Type: Direct-Access ANSI SCSI revision: 02 usb-storage: device scan complete SCSI device sda: 498176 512-byte hdwr sectors (255 MB) sda: Write Protect is off sda: Mode Sense: 18 00 00 08 sda: assuming drive cache: write through SCSI device sda: 498176 512-byte hdwr sectors (255 MB) sda: Write Protect is off sda: Mode Sense: 18 00 00 08 sda: assuming drive cache: write through sda: sda1 Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 usb 3-1: USB disconnect, address 2 scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda1, logical block 1 lost page write due to I/O error on sda1 scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda1, logical block 62 lost page write due to I/O error on sda1 scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda1, logical block 123 lost page write due to I/O error on sda1 scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda1, logical block 251 lost page write due to I/O error on sda1 scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda1, logical block 6203 lost page write due to I/O error on sda1 scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 123) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 124) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 125) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 126) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 127) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 128) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 129) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 130) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 131) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 132) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 133) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 134) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 135) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 136) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 137) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 138) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 139) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 140) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 141) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 142) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 143) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 144) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 145) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 146) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 147) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 148) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 149) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 150) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 151) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 152) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 153) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 154) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 123) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 124) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 125) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 126) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 127) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 128) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 129) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 130) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 131) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 132) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 133) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 134) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 135) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 136) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 137) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 138) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 139) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 140) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 141) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 142) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 143) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 144) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 145) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 146) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 147) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 148) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 149) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 150) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 151) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 152) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 153) failed scsi0 (0:0): rejecting I/O to dead device FAT: Directory bread(block 154) failed Also, on fstab and after the unplug the /sda1 device is still mounted: [root at morpheus log]# grep 'vfat' /etc/fstab /dev/sda1 /media/usbdisk vfat pamconsole,exec,noauto,managed 0 0 [root at morpheus log]# -- Vitor Domingos Paradigma.pt From bernie at develer.com Thu Oct 6 03:03:16 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 06 Oct 2005 05:03:16 +0200 Subject: rawhide report: 20050928 changes In-Reply-To: <604aa7910509280755be263b6@mail.gmail.com> References: <200509281138.j8SBceR9006901@porkchop.devel.redhat.com> <433A83D8.1070908@redhat.com> <604aa7910509280755be263b6@mail.gmail.com> Message-ID: <434493F4.9060209@develer.com> Jeff Spaleta wrote: > Of course, the harder problem of handling permissions on > peripherals in a sane way when 2+ user session where at the console > would still be unresolved. What about using POSIX ACLs to make the devices available to both users at the same time? OK, not all filesystems support them, and many people don't have the acl flag in fstab. But nowadays you can even mount /dev from a tmpfs, which would be also desiderable for other reasons. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From ankit644 at yahoo.com Thu Oct 6 11:20:54 2005 From: ankit644 at yahoo.com (Ankit Patel) Date: Thu, 6 Oct 2005 04:20:54 -0700 (PDT) Subject: A new utility "System Control Center (system-config-control)" ! Message-ID: <20051006112054.37961.qmail@web33603.mail.mud.yahoo.com> Hi all, I have tried to make one utility called "system-config-control" for Fedora. Downloads (RPM, SRPM, zipped source) and Snapshots are awailable on http://www.indianoss.org . Right now it's available in only one language (Gujarati-India). Downloads: RPM :- http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0-1.noarch.rpm?download SRPM :- http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0-1.src.rpm?download Source .bz2 :- http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0.tar.bz2?download Please try it out and give me some feedback on it. Thanks In Advance ! Regards, Ankit Patel (www.indianoss.org) __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From buildsys at redhat.com Thu Oct 6 11:31:40 2005 From: buildsys at redhat.com (Build System) Date: Thu, 6 Oct 2005 07:31:40 -0400 Subject: rawhide report: 20051006 changes Message-ID: <200510061131.j96BVeZP007457@porkchop.devel.redhat.com> New package pykickstart A python library for manipulating kickstart files Updated Packages: ORBit2-2.12.4-2 --------------- * Wed Oct 05 2005 Matthias Clasen 2.12.4-2 - Use gmodule-no-export in the .pc file am-utils-5:6.1.2.1-1 -------------------- * Tue Oct 04 2005 Peter Vrabec 6.1.2.1-1 - upgrade - fix amd shutdown(#158268,#54246) - enhancement, /host/localhost and /host/ are symlinks to / (#11843) * Thu Aug 25 2005 Peter Vrabec 6.1.1-2 - use generic linux/nfs_mount.h check * Fri Aug 19 2005 Peter Vrabec 6.1.1-1 - upgrade 6.1.1 anaconda-10.3.0.28-1 -------------------- * Wed Oct 05 2005 Chris Lumens 10.3.0.28-1 - Add yuminstall (katzj, #169228) - Skip bootloader screen unless modifying partitions (katzj, #169817) - Don't skip manual partitioning on custom (katzj, #169001) - Partitioning UI fixes (katzj) - Don't overwrite empty strings in ksdata with None. - Move kickstart file handling into pykickstart package. - Kickstart LVM and RAID partitioning fixes. bind-24:9.3.1-16 ---------------- * Wed Oct 05 2005 Jason Vas Dias - 24:9.3.1-16 - Fix reconnecting to dbus-daemon after it stops & restarts . cairo-java-1.0.0-9 ------------------ * Wed Oct 05 2005 Igor Foox - 1.0.0-8 - Imported released 1.0.0 sources from upstream. cups-1:1.1.23-21 ---------------- * Thu Oct 06 2005 Tim Waugh 1:1.1.23-21 - Apply patch to fix STR #1290. * Wed Oct 05 2005 Tim Waugh 1:1.1.23-20 - Apply upstream patch for STR #1249. eel2-2.12.1-1 ------------- * Thu Oct 06 2005 Matthias Clasen 2.12.1-1 - Update to 2.12.1 eog-2.12.1-1 ------------ * Thu Oct 06 2005 Matthias Clasen 2.12.1-1 - Update to 2.12.1 file-roller-2.12.1-1 -------------------- * Thu Oct 06 2005 Matthias Clasen 2.12.1-1 - Update to 2.12.1 gedit-1:2.12.1-1 ---------------- * Thu Oct 06 2005 Matthias Clasen - 2.12.1-1 - Update to 2.12.1 glib-java-0.2.0-6 ----------------- gnome-desktop-2.12.1-1 ---------------------- * Thu Oct 06 2005 Matthias Clasen - 2.12.1-1 - Update to 2.12.1 gnome-mag-0.12.2-1 ------------------ * Wed Oct 05 2005 Matthias Clasen 0.12.2-1 - Update to 0.12.2 gnome-system-monitor-2.12.1-1 ----------------------------- * Thu Oct 06 2005 Matthias Clasen 2.12.1-1 - Update to 2.12.1 gnome-themes-2.12.1-1 --------------------- * Wed Oct 05 2005 Matthias Clasen - 2.12.1-1 - Update to 2.12.1 gnome-vfs2-2.12.1.1-1 --------------------- * Thu Oct 06 2005 Matthias Clasen 2.12.1.1-1 - Update to 2.12.1.1 - Drop upstreamed patches gnopernicus-0.11.7-1 -------------------- * Wed Oct 05 2005 Matthias Clasen 0.11.7-1 - Update to 0.11.7 gstreamer-0.8.11-2 ------------------ * Fri Sep 09 2005 John (J5) Palmieri 0.8.11-1 - Update to upstream 0.8.11 - We still need the docbook hack - make it a bit more flexible by asking the catalog where we should get the dtd - Nothing is installed to _libexecdir anymore so removed those entries * Tue May 03 2005 John (J5) Palmieri 0.8.10-1 - Update to upstream 0.8.10 * Thu Mar 17 2005 Colin Walters 0.8.9-4 - Rebuild to make it through beehive gtk2-2.8.6-1 ------------ * Wed Oct 05 2005 Matthias Clasen 2.8.6-1 - New upstream version initscripts-8.17-1 ------------------ * Wed Oct 05 2005 Bill Nottingham 8.17-1 - make sure corefile limiting works for user processes as well (#166511, ) - ifup-routes: handle no EOF in the route file (#156972) - rc.sysinit: tweak mesage (#156972) - ifdown-eth: clean up error message (#135167) - rc.sysinit: call kpartx on multipath devices (#160227) - ifup-eth: move wireless options before bridge options (#122801) - ifup-wireless: silence error (#90601) - init.d/functions: change translated string (#54682) kernel-2.6.13-1.1597_FC5 ------------------------ * Thu Oct 06 2005 Dave Jones - fix suspend to sbp devices. (#166452) * Wed Oct 05 2005 Dave Jones - 2.6.14-rc3-git5 libgconf-java-2.12.0-2 ---------------------- * Wed Oct 05 2005 Igor Foox - 2.12.0-2 - Imported released 2.12.0 source from upstream. - Changed optional installation prefix to /opt/frysk from /opt. - Added dependency for libgtk-java. libgcrypt-1.2.2-1 ----------------- * Wed Oct 05 2005 Nalin Dahyabhai 1.2.2-1 - update to 1.2.2 * Wed Mar 16 2005 Nalin Dahyabhai 1.2.1-1 - update to 1.2.1 * Fri Jul 30 2004 Florian La Roche - another try to package the symlink libglade-java-2.12.0-5 ---------------------- * Wed Oct 05 2005 Igor Foox - 2.12.0-5 - Imported released 2.12.0 sources from upstream. - Changed optional installation prefix to /opt/frysk from /opt. - Changed build depenedency on libgtk-java and libgnome-java to -devel. libgnome-java-2.12.0-2 ---------------------- * Wed Oct 05 2005 Igor Foox - 2.12.0-2 - Import released 2.12.0 sources from upstream. - Change optional installation path to /opt/frysk from /opt. - Change build dependency on glib-java and libgtk-java to -devel. libgnomeprint22-2.12.1-2 ------------------------ * Wed Oct 05 2005 Matthias Clasen - 2.12.1-2 - Use gmodule-no-export in the .pc file libgtk-java-2.8.0-7 ------------------- * Wed Oct 05 2005 Igor Foox - 2.8.0-7 - Changed build dependency on cairo-java and glib-java to -devel. * Wed Oct 05 2005 Igor Foox - 2.8.0-6 - Imported released 2.8.0 sources from upstream. - Changed optional installation prefix to /opt/frysk from /opt. librsvg2-2.12.4-1 ----------------- * Thu Oct 06 2005 Matthias Clasen - 2.12.4-1 - New upstream version libuser-0.54-2 -------------- * Wed Oct 05 2005 Matthias Clasen - 0.54-2 - Use gmodule-no-export in the .pc file mysql-4.1.14-1 -------------- * Wed Oct 05 2005 Tom Lane 4.1.14-1 - Update to MySQL 4.1.14 nautilus-2.12.1-1 ----------------- * Thu Oct 06 2005 Matthias Clasen 2.12.1-1 - Update to 2.12.1 * Wed Sep 07 2005 Matthias Clasen 2.12.0-1 - Update to 2.12.0 * Tue Aug 16 2005 Matthias Clasen - New upstream release nautilus-cd-burner-2.12.1-1 --------------------------- * Thu Oct 06 2005 Matthias Clasen 2.12.1-1 - Update to 2.12.1 pam_krb5-2.1.9-2 ---------------- * Wed Oct 05 2005 Nalin Dahyabhai - 2.1.9-2 - rebuild * Wed Oct 05 2005 Nalin Dahyabhai - 2.1.9-1 - fix ccache initialization after the password is changed (#169966) policycoreutils-1.27.3-2 ------------------------ * Wed Oct 05 2005 Dan Walsh 1.27.3-2 - Rebuild with newer libararies * Wed Sep 28 2005 Dan Walsh 1.27.3-1 - Update to match NSA * Merged patch to update semodule to the new libsemanage API and improve the user interface from Karl MacMillan (Tresys). * Modified semodule for the create/connect API split. psmisc-21.7-1.cvs20051005 ------------------------- * Wed Oct 05 2005 Karel Zak 21.7-1.cvs20051005 - sync with upstream CVS - use old version of fuser selinux-policy-strict-1.27.1-13.1 --------------------------------- * Wed Oct 05 2005 Dan Walsh 1.27.1-13.1 - fix selinux.csh and selinux.sh udev-069-7 ---------- * Thu Oct 06 2005 Harald Hoyer - 069-7 - added edd_id Broken deps for ia64 ---------------------------------------------------------- selinux-policy-strict - 1.27.1-13.1.noarch requires libselinux >= 0:1.27.3-2 Broken deps for i386 ---------------------------------------------------------- selinux-policy-strict - 1.27.1-13.1.noarch requires libselinux >= 0:1.27.3-2 Broken deps for x86_64 ---------------------------------------------------------- selinux-policy-strict - 1.27.1-13.1.noarch requires libselinux >= 0:1.27.3-2 Broken deps for ppc ---------------------------------------------------------- selinux-policy-strict - 1.27.1-13.1.noarch requires libselinux >= 0:1.27.3-2 Broken deps for s390 ---------------------------------------------------------- selinux-policy-strict - 1.27.1-13.1.noarch requires libselinux >= 0:1.27.3-2 Broken deps for ppc64 ---------------------------------------------------------- selinux-policy-strict - 1.27.1-13.1.noarch requires libselinux >= 0:1.27.3-2 Broken deps for s390x ---------------------------------------------------------- selinux-policy-strict - 1.27.1-13.1.noarch requires libselinux >= 0:1.27.3-2 From danfr at matrix.co.il Thu Oct 6 11:40:01 2005 From: danfr at matrix.co.il (Dan Fruehauf) Date: Thu, 06 Oct 2005 14:40:01 +0300 Subject: A new utility "System Control Center (system-config-control)" ! In-Reply-To: <20051006112054.37961.qmail@web33603.mail.mud.yahoo.com> References: <20051006112054.37961.qmail@web33603.mail.mud.yahoo.com> Message-ID: <1128598803.3367.8.camel@isz> On Thu, 2005-10-06 at 04:20 -0700, Ankit Patel wrote: > Hi all, > > I have tried to make one utility called > "system-config-control" for Fedora. Downloads (RPM, > SRPM, zipped source) and Snapshots are awailable on > http://www.indianoss.org . Right now it's available in > only one language (Gujarati-India). It looks like a good idea indeed although it needs some UI work - I'd like to see this in a form of a tree rather than tabs - but that's my own personal taste. However a very quick improvement that could be done is that system-config-control will ask for a root password and all the other utilities won't - that might simplify things for the end user. I didn't have the time to go into the source code, but a question that rises is - how modular is that utility? if we have a new system-config utility - how much will we have to work in order to configure it to work with system-config-control? Perhaps we would also like to first probe which system-config utilities are installed and then let the user choose only between them? - The end user might be frightened to see a kickstart icon without knowing what is it at all... Otherwise - keep up the good work - as I previously said - it's a good idea. Regards, Dan. From sundaram at redhat.com Thu Oct 6 11:47:58 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 06 Oct 2005 17:17:58 +0530 Subject: A new utility "System Control Center (system-config-control)" ! In-Reply-To: <20051006112054.37961.qmail@web33603.mail.mud.yahoo.com> References: <20051006112054.37961.qmail@web33603.mail.mud.yahoo.com> Message-ID: <43450EEE.6000003@redhat.com> Ankit Patel wrote: >Hi all, > >I have tried to make one utility called >"system-config-control" for Fedora. Downloads (RPM, >SRPM, zipped source) and Snapshots are awailable on >http://www.indianoss.org . Right now it's available in >only one language (Gujarati-India). > >Downloads: >RPM :- >http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0-1.noarch.rpm?download >SRPM :- >http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0-1.src.rpm?download >Source .bz2 :- >http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0.tar.bz2?download > >Please try it out and give me some feedback on it. > >Thanks In Advance ! > > Just checked it out and a few comments. Looks like you are trying to provide a centralized control panel which is a approach worth trying out. You could rename the tool as system-config-controlpanel(/center) to make this more obvious. The categorization of tabs could be improved. An icon list (Similar to Korganiser for example) instead of tabs might be worth trying out as a mock up. A icon view can be provided as a alternative. The buttons needs to be spaced better. System-config-logviewer is no longer including FC4 and above. Gnome utils includes a logviewer which has been enabled in the development tree instead. Disable the buttons if the particular tools are not available. When system-config-packages is rewritten on top of yum to understand repositories it would be quite useful to call that with the appropriate options to install the tools on demand. I would suggest including this in Fedora Extras and propose them for core later if its found to be useful and after the rest of the UI interactions and other wrinkles are sorted out. Might consider getting the help of the design team for that http://fedoraproject.org/wiki/Extras http://fedoraproject.org/wiki/FedoraArt regards Rahul From ankit644 at yahoo.com Thu Oct 6 12:15:23 2005 From: ankit644 at yahoo.com (Ankit Patel) Date: Thu, 6 Oct 2005 05:15:23 -0700 (PDT) Subject: A new utility "System Control Center (system-config-control)" ! In-Reply-To: <1128598803.3367.8.camel@isz> Message-ID: <20051006121523.3205.qmail@web33612.mail.mud.yahoo.com> Hi, --- Dan Fruehauf wrote: > On Thu, 2005-10-06 at 04:20 -0700, Ankit Patel > wrote: > > Hi all, > > > > I have tried to make one utility called > > "system-config-control" for Fedora. Downloads > (RPM, > > SRPM, zipped source) and Snapshots are awailable > on > > http://www.indianoss.org . Right now it's > available in > > only one language (Gujarati-India). > > It looks like a good idea indeed although it needs > some UI work - I'd > like to see this in a form of a tree rather than > tabs - but that's my > own personal taste. I will try improve it in that way also. > However a very quick improvement that could be done > is that > system-config-control will ask for a root password > and all the other > utilities won't - that might simplify things for the > end user. > I didn't have the time to go into the source code, > but a question that > rises is - how modular is that utility? if we have a > new system-config > utility - how much will we have to work in order to > configure it to work > with system-config-control? Just add one button in the used glade file and give it a name which the actual command uses to run that utility. > Perhaps we would also like to first probe which > system-config utilities > are installed and then let the user choose only > between them? - The end > user might be frightened to see a kickstart icon > without knowing what is > it at all... really good suggestion ! :) > > Otherwise - keep up the good work - as I previously > said - it's a good > idea. > > Regards, > Dan. Thanks for your helpful suggestions ! Regards, Ankit Patel (www.indianoss.org) __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From roe at liveglobalbid.com Thu Oct 6 14:18:36 2005 From: roe at liveglobalbid.com (Roe Peterson) Date: Thu, 06 Oct 2005 08:18:36 -0600 Subject: kernel-2.6.13-1.1526_FC4smp can't see my mptscsi controller... In-Reply-To: <20051005205626.GC10640@redhat.com> References: <4344016E.4090803@liveglobalbid.com> <1128533139.14097.20.camel@localhost.localdomain> <20051005205626.GC10640@redhat.com> Message-ID: <4345323C.9000504@liveglobalbid.com> Dave Jones wrote: >On Wed, Oct 05, 2005 at 01:25:38PM -0400, Peter Jones wrote: > > On Wed, 2005-10-05 at 10:38 -0600, Roe Peterson wrote: > > > I hope this is the right list. Apologies in advance if not; anyway, here > > > we go. > > > > Probably better to file a bugzilla. > >Sounds like https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169610 > > Dave > > > Right you are; thanks very much. From pemboa at gmail.com Thu Oct 6 16:00:44 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 6 Oct 2005 11:00:44 -0500 Subject: A new utility "System Control Center (system-config-control)" ! In-Reply-To: <20051006112054.37961.qmail@web33603.mail.mud.yahoo.com> References: <20051006112054.37961.qmail@web33603.mail.mud.yahoo.com> Message-ID: <16de708d0510060900n7d9be66ai71811aeafa0412b7@mail.gmail.com> I have considered such an app before, but haven't had the time or drive to do it myself. I am not currently on a machine I would like to compile too many programs on, so do you have any screenshots, and what language did you code this in? On 10/6/05, Ankit Patel wrote: > > Hi all, > > I have tried to make one utility called > "system-config-control" for Fedora. Downloads (RPM, > SRPM, zipped source) and Snapshots are awailable on > http://www.indianoss.org . Right now it's available in > only one language (Gujarati-India). > > Downloads: > RPM :- > > http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0-1.noarch.rpm?download > SRPM :- > > http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0-1.src.rpm?download > Source .bz2 :- > > http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0.tar.bz2?download > > Please try it out and give me some feedback on it. > > Thanks In Advance ! > > Regards, > Ankit Patel (www.indianoss.org ) > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hpa at zytor.com Thu Oct 6 22:18:48 2005 From: hpa at zytor.com (H. Peter Anvin) Date: Thu, 06 Oct 2005 15:18:48 -0700 Subject: Self-introduction: Peter Lemenkov In-Reply-To: References: Message-ID: <4345A2C8.5090504@zytor.com> Peter Lemenkov wrote: > > I want to see more games (most important! :), GIS-related stuff, > some scientific softwate and cross-compiling tools (MinGW, Wine-related, > etc). > Way back when I did an RPM port of the MinGW tools. I still use them to build the Win32 version of syslinux from the same tree. Having a 'doze cross-compilation environment is a great boon for avoiding having to actually use 'doze, and being able to build everything from one tree in one build. I have desperate looking for someone to take these over and modernize them, and I would absolutely *LOVE* to see them get into Fedora Extras. See http://www.kernel.org/pub/linux/utils/boot/syslinux/mingw/ -hpa From vd at paradigma.pt Thu Oct 6 23:24:29 2005 From: vd at paradigma.pt (Vitor Domingos) Date: Fri, 07 Oct 2005 00:24:29 +0100 Subject: Is: fstab automount and nautlius Was: USB camera on kernel 2.6.13-1.1586_FC5 In-Reply-To: <434475D0.6050604@paradigma.pt> References: <434475D0.6050604@paradigma.pt> Message-ID: <4345B22D.10404@paradigma.pt> in reply to self it seems that the problem is related with some automount on fstab-sync/hotplug (?) that nautilus/gnome tries to override. in fstab i've got: /dev/sdc1 /media/usbdisk4 ext3 pamconsole,exec,noauto,managed 0 0 /dev/sdc2 /media/usbdisk5 ext3 pamconsole,exec,noauto,managed 0 0 but when I try to access the drive on nautilus, i've got this message: mount: /dev/sdc2 already mounted or /media/usbdisk5 busy mount: according to mtab, /dev/sdc2 is already mounted on /media/usbdisk5 Anyone with the same problem? //VD Vitor Domingos wrote on 10/06/2005 01:54 AM: > While using my camera with fedora, I've got this problem and cannot use > nautilus on the device (computer, camera), but rather on the mount point > (/media/usbdisk). > > Here's the output: > > usb 3-1: new full speed USB device using uhci_hcd and address 2 > SCSI subsystem initialized > Initializing USB Mass Storage driver... > scsi0 : SCSI emulation for USB Mass Storage devices > usb-storage: device found at 2 > usb-storage: waiting for device to settle before scanning > usbcore: registered new driver usb-storage > USB Mass Storage support registered. > Vendor: NIKON Model: NIKON DSC E3700 Rev: 1.00 > Type: Direct-Access ANSI SCSI revision: 02 > usb-storage: device scan complete > SCSI device sda: 498176 512-byte hdwr sectors (255 MB) > sda: Write Protect is off > sda: Mode Sense: 18 00 00 08 > sda: assuming drive cache: write through > SCSI device sda: 498176 512-byte hdwr sectors (255 MB) > sda: Write Protect is off > sda: Mode Sense: 18 00 00 08 > sda: assuming drive cache: write through > sda: sda1 > Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 > usb 3-1: USB disconnect, address 2 > scsi0 (0:0): rejecting I/O to device being removed > Buffer I/O error on device sda1, logical block 1 > lost page write due to I/O error on sda1 > scsi0 (0:0): rejecting I/O to device being removed > Buffer I/O error on device sda1, logical block 62 > lost page write due to I/O error on sda1 > scsi0 (0:0): rejecting I/O to device being removed > Buffer I/O error on device sda1, logical block 123 > lost page write due to I/O error on sda1 > scsi0 (0:0): rejecting I/O to device being removed > Buffer I/O error on device sda1, logical block 251 > lost page write due to I/O error on sda1 > scsi0 (0:0): rejecting I/O to device being removed > Buffer I/O error on device sda1, logical block 6203 > lost page write due to I/O error on sda1 > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 123) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 124) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 125) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 126) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 127) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 128) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 129) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 130) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 131) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 132) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 133) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 134) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 135) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 136) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 137) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 138) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 139) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 140) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 141) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 142) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 143) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 144) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 145) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 146) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 147) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 148) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 149) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 150) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 151) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 152) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 153) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 154) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 123) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 124) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 125) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 126) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 127) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 128) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 129) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 130) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 131) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 132) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 133) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 134) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 135) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 136) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 137) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 138) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 139) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 140) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 141) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 142) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 143) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 144) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 145) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 146) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 147) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 148) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 149) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 150) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 151) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 152) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 153) failed > scsi0 (0:0): rejecting I/O to dead device > FAT: Directory bread(block 154) failed > > Also, on fstab and after the unplug the /sda1 device is still mounted: > [root at morpheus log]# grep 'vfat' /etc/fstab > /dev/sda1 /media/usbdisk vfat > pamconsole,exec,noauto,managed 0 0 > [root at morpheus log]# > -- Vitor Domingos Paradigma.pt From ankit644 at yahoo.com Fri Oct 7 04:07:34 2005 From: ankit644 at yahoo.com (Ankit Patel) Date: Thu, 6 Oct 2005 21:07:34 -0700 (PDT) Subject: A new utility "System Control Center (system-config-control)" ! In-Reply-To: <16de708d0510060900n7d9be66ai71811aeafa0412b7@mail.gmail.com> Message-ID: <20051007040734.9577.qmail@web33613.mail.mud.yahoo.com> Hi, --- Arthur Pemberton wrote: > I have considered such an app before, but haven't > had the time or drive to > do it myself. I am not currently on a machine I > would like to compile too > many programs on, so do you have any screenshots, > and what language did you > code this in? > Screenshots are already available on the "MyAlbum" section of the http://www.indianoss.org/ And i have used Python + Glade to make this utility. > On 10/6/05, Ankit Patel wrote: > > > > Hi all, > > > > I have tried to make one utility called > > "system-config-control" for Fedora. Downloads > (RPM, > > SRPM, zipped source) and Snapshots are awailable > on > > http://www.indianoss.org . Right now it's > available in > > only one language (Gujarati-India). > > > > Downloads: > > RPM :- > > > > > http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0-1.noarch.rpm?download > > SRPM :- > > > > > http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0-1.src.rpm?download > > Source .bz2 :- > > > > > http://prdownloads.sourceforge.net/indianoss/system-config-control-1.0.tar.bz2?download > > > > Please try it out and give me some feedback on it. > > > > Thanks In Advance ! > > > > Regards, > > Ankit Patel (www.indianoss.org > ) > > > > > > > > __________________________________ > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > http://mail.yahoo.com > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > As a boy I jumped through Windows, as a man I play > with Penguins. > > -- Regards, Ankit Patel (www.indianoss.org) __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From zcerza at redhat.com Fri Oct 7 06:28:36 2005 From: zcerza at redhat.com (Zack Cerza) Date: Fri, 07 Oct 2005 02:28:36 -0400 Subject: Announcing dogtail: a GUI automation and test framework Message-ID: <43461594.3080707@redhat.com> Announcing Dogtail: a GUI automation and test framework A crack team of QA and desktop specialists working at Red Hat is pleased to announce the public release of "Dogtail". Dogtail is a GUI test automation framework written in Python that uses Accessibility (a11y) technologies to communicate with desktop applications. Dogtail scripts are written in Python and executed like any other Python program. The Dogtail website is at: http://people.redhat.com/zcerza/dogtail/index.html Movies of Dogtail in action can be found at: http://people.redhat.com/zcerza/dogtail/media.html Dogtail has a number of features that aid in the automation and testing of desktop applications. These include: * Scripts written in Python - Since Dogtail uses Python as its scripting language, scriptwriters gain enormous power and flexibility in what they can do with Dogtail. If you can do it in Python, you can do it with Dogtail. * Procedural API - A procedural scripting API allows for fast and easy blackbox tests to be written. Ace programmer credentials are not necessary to write useful automated scripts. * Easily Extensible - Dogtail is object-oriented "under the covers" so more advanced users can write custom classes and helper libraries simply. * Results and debug reporting - Test case comparisons are written to a tab-delimited results file for easy processing. Debug information is written to its own log for detailed analysis of what happened during script execution. Dogtail is Free Software, released under the GPL. We are also releasing a set of Python bindings for AT-SPI under the LGPL; these are used by Dogtail and can be found in GNOME CVS in the "pyspi" module. Our initial focus has been to get the project working with GNOME, but we hope to support KDE when its acessibility support has solidified. From nicu_fedora at nicubunu.ro Fri Oct 7 06:48:34 2005 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 07 Oct 2005 09:48:34 +0300 Subject: Announcing dogtail: a GUI automation and test framework In-Reply-To: <43461594.3080707@redhat.com> References: <43461594.3080707@redhat.com> Message-ID: <43461A42.9000107@nicubunu.ro> Zack Cerza wrote: > > Movies of Dogtail in action can be found at: > http://people.redhat.com/zcerza/dogtail/media.html Can I suggest to publish the movies in Ogg Theora format instead of Flash, so people using Fedora can actually play them? A nice package for creating such movies is named 'istanblul' and is part of Fedora Extras. -- nicu my hats collection: http://fedora.nicubunu.ro/hats Open Clip Art Library: http://www.openclipart.org From symbiont at berlios.de Fri Oct 7 07:30:24 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 7 Oct 2005 15:30:24 +0800 Subject: .la files deps Message-ID: <200510071530.24873.symbiont@berlios.de> I couldn't get php compiled with libxml2-devel including its respective .la lib. I'm not sure how it leaked in .. maybe I had an old version of the libtools? But, as stated here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154142#c2 Would an effort to remove /usr/lib/*.la and see what builds okay, be something important to do for FC5? Or not? -- -jeff From eric.tanguy at univ-nantes.fr Fri Oct 7 06:55:12 2005 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Fri, 07 Oct 2005 08:55:12 +0200 Subject: Announcing dogtail: a GUI automation and test framework In-Reply-To: <43461A42.9000107@nicubunu.ro> References: <43461594.3080707@redhat.com> <43461A42.9000107@nicubunu.ro> Message-ID: <1128668112.2909.1.camel@bureau.maison> Le vendredi 07 octobre 2005 ? 09:48 +0300, Nicu Buculei a ?crit : > Zack Cerza wrote: > > > > Movies of Dogtail in action can be found at: > > http://people.redhat.com/zcerza/dogtail/media.html > > Can I suggest to publish the movies in Ogg Theora format instead of > Flash, so people using Fedora can actually play them? > A nice package for creating such movies is named 'istanblul' and is part > of Fedora Extras. Istanbul seems to still be only in extras-devel! When this package will be in extras ? -- Eric Tanguy | Nantes, France Key : A4B8368F | Key Server : subkeys.pgp.net Fedora Core release 4 (Stentz) sur athlon kernel 2.6.13-1.1526_FC4 From james-p at moving-picture.com Fri Oct 7 09:13:13 2005 From: james-p at moving-picture.com (James Pearson) Date: Fri, 07 Oct 2005 10:13:13 +0100 Subject: Anaconda, grub and XFS Message-ID: <43463C29.80203@moving-picture.com> There has been an on going issue with installing grub on an XFS partition - anaconda will hang at the installing boot loader stage as grub 'spins'. The attached patch for 'booty' works round this problem by remounting the XFS file system that contains /boot as read-only and then as read-write before running the grub install command. This patch replaces the current XFS freeze/thaw work round that fails to work (a lot) more often than not. James Pearson -------------- next part -------------- A non-text attachment was scrubbed... Name: booty-xfs_remount.patch Type: text/x-patch Size: 2329 bytes Desc: not available URL: From buildsys at redhat.com Fri Oct 7 11:34:27 2005 From: buildsys at redhat.com (Build System) Date: Fri, 7 Oct 2005 07:34:27 -0400 Subject: rawhide report: 20051007 changes Message-ID: <200510071134.j97BYRB7004291@porkchop.devel.redhat.com> New package giflib Library for manipulating GIF format image files New package rhpxl Python library for configuring and running X. Removed package libungif Updated Packages: bash-3.0-35 ----------- * Thu Oct 06 2005 Tim Waugh 3.0-35 - Fixed memory allocation bug in multibyteifs patch (bug #169996). * Fri Sep 23 2005 Tim Waugh - Use 'volatile' in sighandler patch. bind-24:9.3.1-18 ---------------- * Thu Oct 06 2005 Jason Vas Dias - 24:9.3.1-18 - fix bug 169969: do NOT call dbus_svc_dispatch() in dbus_mgr_init_dbus() - task->state != task_ready and will cause Abort in task.c if process is waiting for NameOwnerChanged to do a SetForwarders bug-buddy-1:2.12.1-1 -------------------- * Thu Oct 06 2005 Matthias Clasen - 2.12.1-1 - Update to 2.12.1 - Drop upstreamed patches cairo-1.0.2-1 ------------- * Thu Oct 06 2005 Kristian H??gsberg - 1.0.2-1 - Update to cairo-1.0.2. * Wed Aug 24 2005 Kristian H??gsberg - 1.0.0-1 - Update to cairo-1.0.0. - Drop cairo-0.9.2-cache-eviction-fix.patch and cairo-0.9.2-dont-hash-null-string.patch. * Fri Aug 19 2005 Kristian H??gsberg 0.9.2-3 - Add cairo-0.9.2-dont-hash-null-string.patch to avoid crash when creating a cairo font from a FT_Face. checkpolicy-1.27.7-1 -------------------- * Thu Oct 06 2005 Dan Walsh 1.27.7-1 - Latest upgrade from NSA * Merged several bug fixes from Joshua Brindle (Tresys). control-center-1:2.12.1-1 ------------------------- * Thu Oct 06 2005 Matthias Clasen - 1:2.12.1-1 - Update to 2.12.1 * Fri Sep 23 2005 Ray Strode - 1:2.12.1-4 - remove explicit dependency on xscreensaver desktop-backgrounds-2.0-30 -------------------------- * Thu Oct 06 2005 Matthias Clasen 2.0-30 - Replace earth_from_space.jpg with a non-mirrored version (#163345) dhcdbd-1.9-1 ------------ * Thu Oct 06 2005 Jason Vas Dias 1.9-1 - fix bug 169937: do 'chkconfig --add dhcdbd' in %post - Add CHANGES changelog file to %doc generated from this changelog - Rebuild with new dbus / gcc / glibc epiphany-1.8.2-1 ---------------- * Thu Oct 06 2005 Christopher Aillon - 1.8.2-1 - Update to 1.8.2 fedora-release-4-99.rawhide --------------------------- gnome-applets-1:2.12.1-1 ------------------------ * Thu Oct 06 2005 Matthias Clasen - 1:2.12.1-1 - Update to 2.12.1 gnome-games-1:2.12.1-1 ---------------------- * Thu Oct 06 2005 Matthias Clasen 1:2.12.1-1 - Update to 2.12.1 gnome-icon-theme-2.12.1-1 ------------------------- * Thu Oct 06 2005 Matthias Clasen - 2.12.1-2 - Update to 2.12.1 gnome-panel-2.12.1-1 -------------------- * Thu Oct 06 2005 Matthias Clasen 2.12.1-1 - Update to 2.12.1 - Update patches gnome-speech-0.3.8-1 -------------------- * Thu Oct 06 2005 Matthias Clasen 0.3.8-1 - Update to 0.3.8 gnome-utils-1:2.12.1-1 ---------------------- * Thu Oct 06 2005 Matthias Clasen - 1:2.12.1-1 - Update to gnome-utils 2.12.1 and zenity 2.12.1 gnome-volume-manager-1.5.2-1 ---------------------------- * Thu Oct 06 2005 Matthias Clasen - 1.5.2-1 - update to 1.5.2 gtksourceview-1.4.2-1 --------------------- * Thu Oct 06 2005 Matthias Clasen - 1.4.2-1 - Update to 1.4.2 iproute-2.6.14-5 ---------------- * Fri Oct 07 2005 Radek Vokal 2.6.14-5 - update from upstream - fixed host_len size for memcpy (#168903) iputils-20020927-29 ------------------- * Wed Oct 05 2005 Radek Vokal 20020927-29 - add ping6 and tracepath6 manpages, fix attributes. kdeaddons-3.4.91-1 ------------------ * Thu Oct 06 2005 Than Ngo 3.4.91-1 - update to KDE 3.5 beta 1 kdeartwork-3.4.91-1 ------------------- * Thu Oct 06 2005 Than Ngo 3.4.91-1 - update tp 3.5 Beta 1 kdeedu-3.4.91-1 --------------- * Thu Oct 06 2005 Than Ngo 3.4.91-1 - update to 3.5 beta 1 kdegames-6:3.4.91-1 ------------------- * Wed Oct 05 2005 Than Ngo 6:3.4.91-1 - update to 3.5 Beta1 kdegraphics-7:3.4.91-1 ---------------------- * Wed Oct 05 2005 Than Ngo 7:3.4.91-1 - update to 3.5 Beta1 kdevelop-9:3.2.91-1 ------------------- * Thu Oct 06 2005 Than Ngo 9:3.2.91-1 - update to KDE 3.5 beta 1 kernel-2.6.13-1.1598_FC5 ------------------------ librsvg2-2.12.5-1 ----------------- * Thu Oct 06 2005 Matthias Clasen - 2.12.5-1 - New upstream version libselinux-1.27.6-1 ------------------- * Thu Oct 06 2005 Dan Walsh 1.27.6-1 - Update to latest from NSA * Added selinux_init_load_policy() function as an even higher level interface for the initial policy load by /sbin/init. This obsoletes the load_policy() function in the sysvinit-selinux.patch. * Added selinux_mkload_policy() function as a higher level interface for loading policy than the security_load_policy() interface. * Thu Oct 06 2005 Dan Walsh 1.27.4-1 - Update to latest from NSA * Merged fix for matchpathcon (regcomp error checking) from Johan Fischer. Also added use of regerror to obtain the error string for inclusion in the error message. libsepol-1.9.11-1 ----------------- * Thu Oct 06 2005 Dan Walsh 1.9.11-1 - Upgrade to latest from NSA * Merged bug fix for check_assertions handling of no assertions from Joshua Brindle (Tresys). libwnck-2.12.1-1 ---------------- * Thu Oct 06 2005 Matthias Clasen - 2.12.1-1 - Update to 2.12.1 mc-1:4.6.1a-0.18 ---------------- * Tue Oct 04 2005 Jindrich Novy 4.6.1a-0.18 - fix off-by-one highlighting when searching backwards in mcedit (#169823) - fix yet another duplicates in menus for Czech locale * Mon Oct 03 2005 Jindrich Novy 4.6.1a-0.17 - fix duplicated keyboard shortcuts in menus for Czech locale (#169734) - fix ctrl-t page code recoding for Russian locale, thanks to Andy Shevchenko (#163594) * Thu Sep 29 2005 Jindrich Novy 4.6.1a-0.16 - fix memory leak in mc-utf8 patch, thanks to Marcin Garski (#169549) - fix mc-find patch to support UTF-8, thanks to Victor Abramoff (#169531) - remove bogus condition from mc-symcrash patch metacity-2.12.1-1 ----------------- * Thu Oct 06 2005 Matthias Clasen 2.12.1-1 - Update to 2.12.1 netpbm-10.29-2 -------------- * Thu Oct 06 2005 Jindrich Novy 10.29-2 - fix segfault in pnmtopng caused by referencing a NULL pointer (#169532) openoffice.org-1:2.0.0-2.1.2 ---------------------------- * Thu Oct 06 2005 Caolan McNamara - 1:2.0.0-2.1 - release candidate 2 - workspace.cmcfixes17 integrated policycoreutils-1.27.5-1 ------------------------ * Thu Oct 06 2005 Dan Walsh 1.27.5-1 - Update to match NSA * Fixed warnings in load_policy. * Rewrote load_policy to use the new selinux_mkload_policy() interface provided by libselinux. python-2.4.1-14 --------------- * Mon Sep 26 2005 Peter Jones 2.4.1-14 - Once more -- this time, to fix -EPERM when you run it in a directory you can't read from. scim-1.4.2-5 ------------ * Thu Oct 06 2005 Jens Petersen - 1.4.2-5 - fixing quoting in scim-restart - make post and postun scripts for scim-libs * Thu Sep 22 2005 Jens Petersen - 1.4.2-4 - make scim-devel require scim-libs - add xinput.d entries for Indic langs * Thu Sep 15 2005 Jens Petersen - 1.4.2-3 - move libs and the gtk immodule to scim-libs for multilib scim-anthy-0.7.0-3.fc5 ---------------------- * Thu Oct 06 2005 Jens Petersen - 0.7.0-3 - require scim * Thu Oct 06 2005 Akira TAGOH - 0.7.0-2 - added Requires: kasumi. scim-chewing-0.2.1-2 -------------------- * Thu Oct 06 2005 Jens Petersen - 0.2.1-2 - require scim explicitly scim-hangul-0.2.0-6.fc5 ----------------------- * Thu Oct 06 2005 Jens Petersen - 0.2.0-6.fc5 - require scim scim-pinyin-0.5.91-2 -------------------- * Thu Oct 06 2005 Jens Petersen - 0.5.91-2 - require scim * Tue Aug 16 2005 Jens Petersen - 0.5.91-1 - update to 0.5.91 test release - scim-pinyin-0.5.0-setup-ambiguity-cast.patch no longer needed * Mon Aug 08 2005 Jens Petersen - 0.5.0-5 - initial build for Fedora Core scim-tables-0.5.3-6 ------------------- * Thu Oct 06 2005 Jens Petersen - 0.5.3-6 - require scim system-config-printer-0.6.143-1 ------------------------------- * Thu Oct 06 2005 Tim Waugh 0.6.143-1 - 0.6.143: - KRB5 and WINS support from Richard Renard (bug #169764, bug #169932). yum-2.4.0-6 ----------- * Thu Oct 06 2005 Paul Nasrat - 2.4.0-6 - Backport transaction constants - Allow setting anaconda flag * Tue Oct 04 2005 Jeremy Katz - add dirs for plugins Broken deps for ppc64 ---------------------------------------------------------- rhpxl - 0.1-1.noarch requires pyxf86config >= 0:0.3.2 Broken deps for s390x ---------------------------------------------------------- rhpxl - 0.1-1.noarch requires pyxf86config >= 0:0.3.2 Broken deps for s390 ---------------------------------------------------------- rhpxl - 0.1-1.noarch requires pyxf86config >= 0:0.3.2 From rdieter at math.unl.edu Fri Oct 7 12:34:00 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 07 Oct 2005 07:34:00 -0500 Subject: .la files deps In-Reply-To: <200510071530.24873.symbiont@berlios.de> References: <200510071530.24873.symbiont@berlios.de> Message-ID: Jeff Pitman wrote: > Would an effort to remove /usr/lib/*.la and see what builds okay, be > something important to do for FC5? Or not? Absolutely. For shared libraries, in most(90%?) cases, the /usr/lib/lib*.la files packaged are superfluous. The are also a sort of cancer, that infects other .la files, causing library dependancy bloat (ie, adding extra Requires to -devel packages that include the infected .la files) Here's a start of my efforts to help in this area: SDL: http://bugzilla.redhat.com/bugzilla/145974 rpm: http://bugzilla.redhat.com/bugzilla/145978 subversion: http://bugzilla.redhat.com/bugzila/170029 svn is tricky, it has lots of sublibraries expat: http://bugzilla.redhat.com/bugzilla/170031 db4: http://bugzilla.redhat.com/bugzilla/170032 libjpeg: http://bugzilla.redhat.com/bugzilla/170046 neon: http://bugzilla.redhat.com/bugzilla/170049 apr: http://bugzilla.redhat.com/bugzilla/170050 apr-util: http://bugzilla.redhat.com/bugzilla/170051 -- Rex From tmraz at redhat.com Fri Oct 7 13:01:05 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 07 Oct 2005 15:01:05 +0200 Subject: Deprecating pam_stack.so Message-ID: <1128690065.3156.29.camel@perun.redhat.usu> Linux-PAM 0.78 and later contains include directive which obsoletes using the pam_stack module. This module is rather a hack as it requires access to pam library internals for its operation and will never be accepted to upstream. The include directive implementation is much cleaner although its semantics are subtly different. The include works as a real include so the base file and the included one are processed as if they were first flattened into one file. The pam_stack module however works as if the pam was recursively called again with the stacked service. Arguably the pam_stack model is little bit more "user friendly" as "sufficient" entries in the stacked service don't bypass modules in the primary service which came after the pam_stack module. This means that all existing configuration files for services cannot be blindly modified but they have to be carefully examinated and modified with the above in mind. The pam_stack module probably won't be removed too soon because it would break upgrades with modified pam configs however I'll probably add some deprecation message in the system log when it will be used. Also big warning for people which modify the /etc/pam.d/system-auth file by hand - never remove the "auth required pam_deny.so" as it will make some pamified services open to anyone (depending on preceding modules in the system-auth and the pam config which includes it). -- Tomas Mraz From ellson at research.att.com Fri Oct 7 13:37:41 2005 From: ellson at research.att.com (John Ellson) Date: Fri, 07 Oct 2005 09:37:41 -0400 Subject: WARNING - iproute breaks networking (Re: rawhide report: 20051007 changes) In-Reply-To: <200510071134.j97BYRB7004291@porkchop.devel.redhat.com> References: <200510071134.j97BYRB7004291@porkchop.devel.redhat.com> Message-ID: <43467A25.10502@research.att.com> Build System wrote: > > iproute-2.6.14-5 > ---------------- > * Fri Oct 07 2005 Radek Vokal 2.6.14-5 > - update from upstream > - fixed host_len size for memcpy (#168903) > Upgrading this today broke networking on my machine. Reverting to iproute-2.6.14-4 whilst keeping all the rest of today's upgrades fixed the problem. Bug reported: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170111 John From pnasrat at redhat.com Fri Oct 7 14:17:42 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 07 Oct 2005 10:17:42 -0400 Subject: Anaconda, grub and XFS In-Reply-To: <43463C29.80203@moving-picture.com> References: <43463C29.80203@moving-picture.com> Message-ID: <1128694663.2870.8.camel@enki.eridu> On Fri, 2005-10-07 at 10:13 +0100, James Pearson wrote: > There has been an on going issue with installing grub on an XFS > partition - anaconda will hang at the installing boot loader stage as > grub 'spins'. > > The attached patch for 'booty' works round this problem by remounting > the XFS file system that contains /boot as read-only and then as > read-write before running the grub install command. > > This patch replaces the current XFS freeze/thaw work round that fails to > work (a lot) more often than not. Please file a bug/rfe with a unified diff attached against booty. Paul From sundaram at redhat.com Fri Oct 7 14:18:37 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 07 Oct 2005 19:48:37 +0530 Subject: Announcing dogtail: a GUI automation and test framework In-Reply-To: <1128668112.2909.1.camel@bureau.maison> References: <43461594.3080707@redhat.com> <43461A42.9000107@nicubunu.ro> <1128668112.2909.1.camel@bureau.maison> Message-ID: <434683BD.1010108@redhat.com> Eric Tanguy wrote: >Le vendredi 07 octobre 2005 ? 09:48 +0300, Nicu Buculei a ?crit : > > >>Zack Cerza wrote: >> >> >>>Movies of Dogtail in action can be found at: >>>http://people.redhat.com/zcerza/dogtail/media.html >>> >>> >>Can I suggest to publish the movies in Ogg Theora format instead of >>Flash, so people using Fedora can actually play them? >>A nice package for creating such movies is named 'istanblul' and is part >>of Fedora Extras. >> >> >Istanbul seems to still be only in extras-devel! When this package will >be in extras ? > > IIUC, It requires a very recent version of gstreamer only found in the development tree regards Rahul From katzj at redhat.com Fri Oct 7 14:28:55 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 07 Oct 2005 10:28:55 -0400 Subject: Anaconda, grub and XFS In-Reply-To: <43454FD3.4000400@moving-picture.com> References: <43454FD3.4000400@moving-picture.com> Message-ID: <1128695335.12602.59.camel@bree.local.net> On Thu, 2005-10-06 at 17:24 +0100, James Pearson wrote: > There has been an on going issue with installing grub on an XFS > partition - anaconda will hang at the installing boot loader stage as > grub 'spins'. > > The attached patch for 'booty' works round this problem by remounting > the XFS file system that contains /boot as read-only and then as > read-write before running the grub install command. > > This patch replaces the current XFS freeze/thaw work round that fails to > work (a lot) more often than not. This feels like a hack for the fact that xfs_freeze doesn't work as it was designed to -- it is specifically for things which need the contents on disk to actually be what the kernel thinks is there. And the continued need of random hacks like this make me more and more inclined to just disallow the use of XFS as a bootable filesystem. Jeremy From dennis at ausil.us Fri Oct 7 14:39:34 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 7 Oct 2005 09:39:34 -0500 Subject: Anaconda, grub and XFS In-Reply-To: <1128695335.12602.59.camel@bree.local.net> References: <43454FD3.4000400@moving-picture.com> <1128695335.12602.59.camel@bree.local.net> Message-ID: <200510070939.34388.dennis@ausil.us> On Friday 07 October 2005 09:28, Jeremy Katz wrote: > On Thu, 2005-10-06 at 17:24 +0100, James Pearson wrote: > > There has been an on going issue with installing grub on an XFS > > partition - anaconda will hang at the installing boot loader stage as > > grub 'spins'. > > > > The attached patch for 'booty' works round this problem by remounting > > the XFS file system that contains /boot as read-only and then as > > read-write before running the grub install command. > > > > This patch replaces the current XFS freeze/thaw work round that fails to > > work (a lot) more often than not. > > This feels like a hack for the fact that xfs_freeze doesn't work as it > was designed to -- it is specifically for things which need the contents > on disk to actually be what the kernel thinks is there. And the > continued need of random hacks like this make me more and more inclined > to just disallow the use of XFS as a bootable filesystem. > > Jeremy I regularly use XFS as a filesystem for / and /home and other areas but because of this bug i always use ext3 for / and really for the use of boot and the size of the files in there /boot is much better off being on ext3 so i would say make it so /boot has to be ext3. then you should only hit this issue if someone decides to forgo a /boot partition Dennis From nicu_fedora at nicubunu.ro Fri Oct 7 14:46:06 2005 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 07 Oct 2005 17:46:06 +0300 Subject: Announcing dogtail: a GUI automation and test framework In-Reply-To: <434683BD.1010108@redhat.com> References: <43461594.3080707@redhat.com> <43461A42.9000107@nicubunu.ro> <1128668112.2909.1.camel@bureau.maison> <434683BD.1010108@redhat.com> Message-ID: <43468A2E.1070608@nicubunu.ro> Rahul Sundaram wrote: > Eric Tanguy wrote: > >> Istanbul seems to still be only in extras-devel! When this package will >> be in extras ? >> >> > IIUC, It requires a very recent version of gstreamer only found in the > development tree Istanbul was just an example, the exact package used does not matter that much, the main idea is a format which could be read by free players (preferably by the player included in the default install) would just make sense to be used. -- nicu my hats collection: http://fedora.nicubunu.ro/hats Open Clip Art Library: http://www.openclipart.org From tdiehl at rogueind.com Fri Oct 7 14:55:01 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 7 Oct 2005 10:55:01 -0400 (EDT) Subject: Announcing dogtail: a GUI automation and test framework In-Reply-To: <43468A2E.1070608@nicubunu.ro> References: <43461594.3080707@redhat.com> <43461A42.9000107@nicubunu.ro> <1128668112.2909.1.camel@bureau.maison> <434683BD.1010108@redhat.com> <43468A2E.1070608@nicubunu.ro> Message-ID: On Fri, 7 Oct 2005, Nicu Buculei wrote: > Rahul Sundaram wrote: > > Eric Tanguy wrote: > > > >> Istanbul seems to still be only in extras-devel! When this package will > >> be in extras ? > >> > >> > > IIUC, It requires a very recent version of gstreamer only found in the > > development tree > > Istanbul was just an example, the exact package used does not matter > that much, the main idea is a format which could be read by free players > (preferably by the player included in the default install) would just > make sense to be used. +1 Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From sundaram at redhat.com Fri Oct 7 14:55:04 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 07 Oct 2005 20:25:04 +0530 Subject: Announcing dogtail: a GUI automation and test framework In-Reply-To: <43468A2E.1070608@nicubunu.ro> References: <43461594.3080707@redhat.com> <43461A42.9000107@nicubunu.ro> <1128668112.2909.1.camel@bureau.maison> <434683BD.1010108@redhat.com> <43468A2E.1070608@nicubunu.ro> Message-ID: <43468C48.8000507@redhat.com> Nicu Buculei wrote: > Rahul Sundaram wrote: > >> Eric Tanguy wrote: >> >>> Istanbul seems to still be only in extras-devel! When this package will >>> be in extras ? >>> >>> >> IIUC, It requires a very recent version of gstreamer only found in >> the development tree > > > Istanbul was just an example, the exact package used does not matter > that much, the main idea is a format which could be read by free > players (preferably by the player included in the default install) > would just make sense to be used. I was answering the reason why Istanbul in only in the development tree. While Ogg theora formats are indeed preferrable it has been a ongoing struggle to create them on many occasions. Perhaps you would want to check out this software and try creating such videos. regards Rahul From lamont at gurulabs.com Fri Oct 7 16:01:49 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 7 Oct 2005 10:01:49 -0600 Subject: openssl-devel depends on e2fsprogs-devel ? Message-ID: <200510071001.54056.lamont@gurulabs.com> All, Just did "yum install openssl-devel" and was surprised to find out that it depends on e2fsprogs-devel. On the surface, this doesn't make sense to me. Anyone in the know care to explain why? Is this a case of a dependency that should be removed? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Oct 7 16:37:52 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 07 Oct 2005 11:37:52 -0500 Subject: krb5-devel depends on e2fsprogs-devel ? In-Reply-To: <200510071001.54056.lamont@gurulabs.com> References: <200510071001.54056.lamont@gurulabs.com> Message-ID: <4346A460.1060508@math.unl.edu> Lamont R. Peterson wrote: > Just did "yum install openssl-devel" and was surprised to find out that it > depends on e2fsprogs-devel. Actually it's openssl-devel depends on krb5-devel which depends on e2fsprogs-devel. So, why does krb5-devel depend on e2fsprogs-devel? Looking at krb5's changelog, rpm -q --changelog krb5 I see the entry: * Wed Jun 18 2003 Nalin Dahyabhai 1.3-0.beta.4 - test update to 1.3 beta 4 - ditch statglue build option - krb5-devel requires e2fsprogs-devel, which now provides libss and libcom_err -- Rex From skvidal at phy.duke.edu Fri Oct 7 16:43:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 07 Oct 2005 12:43:33 -0400 Subject: openssl-devel depends on e2fsprogs-devel ? In-Reply-To: <200510071001.54056.lamont@gurulabs.com> References: <200510071001.54056.lamont@gurulabs.com> Message-ID: <1128703413.25539.9.camel@cutter> On Fri, 2005-10-07 at 10:01 -0600, Lamont R. Peterson wrote: > All, > > Just did "yum install openssl-devel" and was surprised to find out that it > depends on e2fsprogs-devel. > > On the surface, this doesn't make sense to me. Anyone in the know care to > explain why? Is this a case of a dependency that should be removed? I'd guess b/c of: /usr/lib/libcom_err.so which LOTS of things end up needing. -sv From jspaleta at gmail.com Fri Oct 7 16:52:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 7 Oct 2005 12:52:53 -0400 Subject: Announcing dogtail: a GUI automation and test framework In-Reply-To: <1128668112.2909.1.camel@bureau.maison> References: <43461594.3080707@redhat.com> <43461A42.9000107@nicubunu.ro> <1128668112.2909.1.camel@bureau.maison> Message-ID: <604aa7910510070952o7df3c47dsf2b320a82508fd82@mail.gmail.com> On 10/7/05, Eric Tanguy wrote: > Istanbul seems to still be only in extras-devel! When this package will > be in extras ? If the gstreamer-plugins in fc4 are ever updated to include the necessary plugin... i'll push istanbul for extras fc4. Istanbul is essentially just a gui wrapper over a gst pipeline. But the gst plugin that makes the magic work was introduced in a version of gst later than what is in fc4... so until fc4 gst is updated istanbul in fc4 extras is particularly pointless. If you want to play with it.... http://www.fedoraproject.org/wiki/ScreenCasting -jef From johnp at redhat.com Fri Oct 7 17:11:10 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Fri, 07 Oct 2005 13:11:10 -0400 Subject: Announcing dogtail: a GUI automation and test framework In-Reply-To: <604aa7910510070952o7df3c47dsf2b320a82508fd82@mail.gmail.com> References: <43461594.3080707@redhat.com> <43461A42.9000107@nicubunu.ro> <1128668112.2909.1.camel@bureau.maison> <604aa7910510070952o7df3c47dsf2b320a82508fd82@mail.gmail.com> Message-ID: <1128705071.10700.137.camel@localhost.localdomain> I'm hesitant to upgrade to the latest as some plug-ins can be fragile. If someone provided me with a patch to the spec and sources which added the one screen capture plug-in needed I might be convinced to push an update. On Fri, 2005-10-07 at 12:52 -0400, Jeff Spaleta wrote: > On 10/7/05, Eric Tanguy wrote: > > Istanbul seems to still be only in extras-devel! When this package will > > be in extras ? > > If the gstreamer-plugins in fc4 are ever updated to include the > necessary plugin... i'll push istanbul for extras fc4. Istanbul is > essentially just a gui wrapper over a gst pipeline. But the gst plugin > that makes the magic work was introduced in a version of gst later > than what is in fc4... so until fc4 gst is updated istanbul in fc4 > extras is particularly pointless. > > If you want to play with it.... http://www.fedoraproject.org/wiki/ScreenCasting > > -jef > -- John (J5) Palmieri From jspaleta at gmail.com Fri Oct 7 17:39:05 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 7 Oct 2005 13:39:05 -0400 Subject: Announcing dogtail: a GUI automation and test framework In-Reply-To: <43468A2E.1070608@nicubunu.ro> References: <43461594.3080707@redhat.com> <43461A42.9000107@nicubunu.ro> <1128668112.2909.1.camel@bureau.maison> <434683BD.1010108@redhat.com> <43468A2E.1070608@nicubunu.ro> Message-ID: <604aa7910510071039x1161862fq9f14b80f3de5cbc8@mail.gmail.com> On 10/7/05, Nicu Buculei wrote: > Istanbul was just an example, the exact package used does not matter > that much, the main idea is a format which could be read by free players > (preferably by the player included in the default install) would just > make sense to be used. Yes... ideally...it would be very nice to have. Feel free to suggest another alternative other than istanbul. Perhaps its simple a matter of not having the tools available on the system being used to develop dogtail. Right now... its a hell of a lot easier to get the flash video creation working than to get video captures to theora working, the tools for that have been usable for over a year now. The gst plugin istanbul relies on in rawhide still has some gratuitous performance problems with frame dropping that make screen capturing..tedious. I went through the trouble of packaging istanbul in Extras developer in the hopes that more people interesting in this sort of video production beat the crap out of it and start working with the upstream developers to make the gst video capture more robust. If you know of a better way to screencapture directly into theora.. or if you have a procedure by which we can convert the flash video into theora after-the-fact.. I'm all ears. -jef"if wishes were fishes"spaleta From lamont at gurulabs.com Fri Oct 7 18:30:49 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 7 Oct 2005 12:30:49 -0600 Subject: krb5-devel depends on e2fsprogs-devel ? In-Reply-To: <4346A460.1060508@math.unl.edu> References: <200510071001.54056.lamont@gurulabs.com> <4346A460.1060508@math.unl.edu> Message-ID: <200510071230.53556.lamont@gurulabs.com> On Friday 07 October 2005 10:37am, Rex Dieter wrote: > Lamont R. Peterson wrote: > > Just did "yum install openssl-devel" and was surprised to find out that > > it depends on e2fsprogs-devel. Argh..I should have checked that one :) . > Actually it's openssl-devel depends on krb5-devel which depends on > e2fsprogs-devel. > > So, why does krb5-devel depend on e2fsprogs-devel? Looking at krb5's > changelog, > rpm -q --changelog krb5 > I see the entry: > > * Wed Jun 18 2003 Nalin Dahyabhai 1.3-0.beta.4 > - test update to 1.3 beta 4 > - ditch statglue build option > - krb5-devel requires e2fsprogs-devel, which now provides libss and > libcom_err Ah...so now my question is, "should the libss and libcom_err headers (and/or others) be moved into a separate package from e2fsprogs-devel?" -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zcerza at redhat.com Fri Oct 7 18:36:02 2005 From: zcerza at redhat.com (Zack Cerza) Date: Fri, 07 Oct 2005 14:36:02 -0400 Subject: Theora screencasts are on the way. (was: Re: Announcing dogtail: a GUI automation and test framework) In-Reply-To: <43461A42.9000107@nicubunu.ro> References: <43461594.3080707@redhat.com> <43461A42.9000107@nicubunu.ro> Message-ID: <4346C012.70000@redhat.com> Nicu Buculei wrote: > Zack Cerza wrote: > >> >> Movies of Dogtail in action can be found at: >> http://people.redhat.com/zcerza/dogtail/media.html > > > Can I suggest to publish the movies in Ogg Theora format instead of > Flash, so people using Fedora can actually play them? > A nice package for creating such movies is named 'istanblul' and is part > of Fedora Extras. We do plan on getting Theora versions up on the site soon. Unfortunately, the only screencast format we were able to get working in time for release was Flash - none of us were thrilled about that, but we made the decision not to hold up the release for that one issue, annoying as it may be. Thanks, Zack From daniel.spratlen at cox.net Fri Oct 7 19:51:31 2005 From: daniel.spratlen at cox.net (Daniel Spratlen) Date: Fri, 07 Oct 2005 15:51:31 -0400 Subject: Anaconda, grub and XFS In-Reply-To: <200510070939.34388.dennis@ausil.us> References: <43454FD3.4000400@moving-picture.com> <1128695335.12602.59.camel@bree.local.net> <200510070939.34388.dennis@ausil.us> Message-ID: <1128714691.4256.7.camel@boo> On Fri, 2005-10-07 at 09:39 -0500, Dennis Gilmore wrote: > On Friday 07 October 2005 09:28, Jeremy Katz wrote: > > On Thu, 2005-10-06 at 17:24 +0100, James Pearson wrote: > > > There has been an on going issue with installing grub on an XFS > > > partition - anaconda will hang at the installing boot loader stage as > > > grub 'spins'. > > > > > > The attached patch for 'booty' works round this problem by remounting > > > the XFS file system that contains /boot as read-only and then as > > > read-write before running the grub install command. > > > > > > This patch replaces the current XFS freeze/thaw work round that fails to > > > work (a lot) more often than not. > > > > This feels like a hack for the fact that xfs_freeze doesn't work as it > > was designed to -- it is specifically for things which need the contents > > on disk to actually be what the kernel thinks is there. And the > > continued need of random hacks like this make me more and more inclined > > to just disallow the use of XFS as a bootable filesystem. > > > > Jeremy > I regularly use XFS as a filesystem for / and /home and other areas but > because of this bug i always use ext3 for / and really for the use of boot > and the size of the files in there /boot is much better off being on ext3 > so i would say make it so /boot has to be ext3. then you should only hit > this issue if someone decides to forgo a /boot partition > > Dennis > I disagree. XFS can be used as a filesystem for /boot and there is no reason that Fedora should impose artificial limitations on the use of XFS. Don't limit the use of a filesystem because GRUB makes some incorrect assumptions about being able to read a block device image while a filesystem is mounted and actively being written to. Why not have anaconda force users who want to use XFS for /boot to setup grub post install rather than have anaconda not allow /boot to be XFS. Daniel Spratlen From lamont at gurulabs.com Fri Oct 7 21:35:46 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 7 Oct 2005 15:35:46 -0600 Subject: Anaconda, grub and XFS In-Reply-To: <1128714691.4256.7.camel@boo> References: <43454FD3.4000400@moving-picture.com> <200510070939.34388.dennis@ausil.us> <1128714691.4256.7.camel@boo> Message-ID: <200510071535.50452.lamont@gurulabs.com> On Friday 07 October 2005 01:51pm, Daniel Spratlen wrote: > On Fri, 2005-10-07 at 09:39 -0500, Dennis Gilmore wrote: [SNIP] > > I regularly use XFS as a filesystem for / and /home and other areas > > but because of this bug i always use ext3 for / and really for the use > > of boot and the size of the files in there /boot is much better off > > being on ext3 so i would say make it so /boot has to be ext3. then you > > should only hit this issue if someone decides to forgo a /boot partition > > > > Dennis > > I disagree. XFS can be used as a filesystem for /boot and there is no > reason that Fedora should impose artificial limitations on the use of > XFS. Don't limit the use of a filesystem because GRUB makes some > incorrect assumptions about being able to read a block device image > while a filesystem is mounted and actively being written to. Why not > have anaconda force users who want to use XFS for /boot to setup grub > post install rather than have anaconda not allow /boot to be XFS. Or, better yet, why not fix GRUB to not make such assumptions? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.f.h at web.de Sat Oct 8 07:55:56 2005 From: m.f.h at web.de (Marcus Hartig) Date: Sat, 08 Oct 2005 03:55:56 -0400 Subject: WARNING - iproute breaks networking (Re: rawhide report: 20051007 changes) Message-ID: <43477B8C.2090201@web.de> > Upgrading this today broke networking on my machine. Too late. My loopback activating loops endless.... Sorry, I ask me really how that can be? Its a error where the system do not more boot here. Do the maintainer(s) not testing this before uploading their new package to rawhide? Marcus From james-p at moving-picture.com Sat Oct 8 11:00:47 2005 From: james-p at moving-picture.com (James Pearson) Date: Sat, 8 Oct 2005 12:00:47 +0100 Subject: Anaconda, grub and XFS In-Reply-To: <1128695335.12602.59.camel@bree.local.net> References: <43454FD3.4000400@moving-picture.com> <1128695335.12602.59.camel@bree.local.net> Message-ID: On 10/7/05, Jeremy Katz wrote: > On Thu, 2005-10-06 at 17:24 +0100, James Pearson wrote: > > There has been an on going issue with installing grub on an XFS > > partition - anaconda will hang at the installing boot loader stage as > > grub 'spins'. > > > > The attached patch for 'booty' works round this problem by remounting > > the XFS file system that contains /boot as read-only and then as > > read-write before running the grub install command. > > > > This patch replaces the current XFS freeze/thaw work round that fails to > > work (a lot) more often than not. > > This feels like a hack for the fact that xfs_freeze doesn't work as it > was designed to -- it is specifically for things which need the contents > on disk to actually be what the kernel thinks is there. And the > continued need of random hacks like this make me more and more inclined > to just disallow the use of XFS as a bootable filesystem. But this is a 'hack' that replaces a 'hack' that doesn't work ... so the total number of hacks in anaconda won't increase :-) Anyway, as suggested, I've submitted a bug/rfe (#170127) Thanks James Pearson From buildsys at redhat.com Sat Oct 8 11:14:55 2005 From: buildsys at redhat.com (Build System) Date: Sat, 8 Oct 2005 07:14:55 -0400 Subject: rawhide report: 20051008 changes Message-ID: <200510081114.j98BEthf022616@porkchop.devel.redhat.com> Updated Packages: anaconda-10.3.0.29-1 -------------------- * Fri Oct 07 2005 Chris Lumens 10.3.0.29-1 - Deal with new load_policy. (katzj) - Create an SELinux config. (katzj) - Use rhpxl instead of rhpl for X configuration. - Use pykickstart. checkpolicy-1.27.7-2 -------------------- * Fri Oct 07 2005 Dan Walsh 1.27.7-2 - Rebuild to get latest libsepol db4-4.3.29-1 ------------ * Fri Oct 07 2005 Paul Nasrat 4.3.29-1 - New upstream release firstboot-1.3.49-1 ------------------ * Fri Oct 07 2005 Chris Lumens 1.3.49-1 - Use rhpxl instead of rhpl for X stuff. freetype-2.1.10-1 ----------------- * Fri Oct 07 2005 Matthias Clasen 2.1.10-1 - Update to 2.1.10 - Add necessary fixes gcc-4.0.2-3 ----------- * Fri Oct 07 2005 Jakub Jelinek 4.0.2-3 - update from CVS - PRs fortran/18568, debug/24070, middle-end/15855, target/22585, target/23570 - fix libjava configury, broken by recent gkt+-2.0 pkg-config changes - fix clearing of MMX registers (#169765) * Wed Oct 05 2005 Jakub Jelinek 4.0.2-2 - update from CVS - PRs ada/19382, c++/17609, c++/17775, c++/18368, c++/22621, c++/23513, c++/23840, c++/23965, c/21419, c/23576, fortran/24005, fortran/24176, java/19870, java/20338, java/21418, java/21844, java/23891, java/24120, libffi/24148, libfortran/23380, libfortran/23802, libfortran/23803, libgcj/23182, libstdc++/23956, libstdc++/23978, libstdc++/24054, libstdc++/24064, middle-end/23125, middle-end/24069, tree-optimization/21419, tree-optimization/24146, tree-optimization/24151 gnome-bluetooth-0.6.0-2 ----------------------- * Fri Oct 07 2005 Harald Hoyer - 0.6.0-2 - Fix relative path for the icons in desktop files which no longer works with the icon cache. hwbrowser-0.23-1 ---------------- * Fri Oct 07 2005 Nils Philippsen 0.23 - don't use pam_stack in PAM hwbrowser.pam (#169649) - appease "make distcheck" * Thu May 19 2005 Nils Philippsen 0.22 - avoid DeprecationWarnings iproute-2.6.14-6 ---------------- * Fri Oct 07 2005 Bill Nottingham 2.6.14-6 - update from upstream (appears to fix #170111) kernel-2.6.13-1.1600_FC5 ------------------------ * Fri Oct 07 2005 Dave Jones - 2.6.14-rc3-git7 libselinux-1.27.7-1 ------------------- * Fri Oct 07 2005 Dan Walsh 1.27.7-1 - Update to latest from NSA * Changed getseuserbyname to fall back to the Linux username and NULL level if seusers config file doesn't exist unless REQUIRESEUSERS=1 is set in /etc/selinux/config. * Moved seusers.conf under $SELINUXTYPE and renamed to seusers. libsemanage-1.3.9-1 ------------------- * Fri Oct 07 2005 Dan Walsh 1.3.9-1 - Update from NSA * Merged further database work from Ivan Gyurdiev. libsepol-1.9.12-1 ----------------- * Fri Oct 07 2005 Dan Walsh 1.9.12-1 - Upgrade to latest from NSA * Merged function renaming and static cleanup from Ivan Gyurdiev. mkinitrd-5.0.4-1 ---------------- * Fri Oct 07 2005 Peter Jones - 5.0.4-1 - split switchroot into setuproot and switchroot, with presetuproot in between - make preswitchroot and setuproot execute through symlinks, so they may be replaced by a second initramfs image - add logic to mount filesystems specified in /etc/fstab.sys during setuproot - general code cleanups mtr-2:0.69-5 ------------ * Fri Oct 07 2005 Tomas Mraz 2:0.69-5 - use include instead of pam_stack in pam config openssh-4.2p1-2 --------------- * Fri Oct 07 2005 Tomas Mraz 4.2p1-2 - use include instead of pam_stack in pam config - use fork+exec instead of system in scp (#168167) - upstream patch for displaying authentication errors passwd-0.71-1 ------------- * Fri Oct 07 2005 Tomas Mraz 0.71-1 - use include instead of pam_stack in pam config policycoreutils-1.27.5-3 ------------------------ * Thu Oct 06 2005 Dan Walsh 1.27.5-3 - Update newrole pam file to remove pam-stack - Update run_init pam file to remove pam-stack pykickstart-0.3-1 ----------------- rhpl-0.175-1 ------------ * Fri Oct 07 2005 Chris Lumens 0.175-1 - Move X-related chunks into rhpxl, replace with deprecation warnings. - Fix rhpl requires. rhpxl-0.1-2 ----------- scim-anthy-0.7.0-4.fc5 ---------------------- * Fri Oct 07 2005 Akira TAGOH - 0.7.0-4 - scim-0.7.0-fix_crash_bug.diff: a patch to fix a crash issue. selinux-policy-strict-1.27.1-14 ------------------------------- * Fri Oct 07 2005 Dan Walsh 1.27.1-14 - Increase sensitivities to 16 - Increase Capabilities to 256 selinux-policy-targeted-1.27.1-14 --------------------------------- * Fri Oct 07 2005 Dan Walsh 1.27.1-14 - Increase sensitivities to 16 - Increase Capabilities to 256 sysstat-6.0.1-1 --------------- * Fri Oct 07 2005 Ivana Varekova 6.0.1-1 - version 6.0.1 system-config-date-1.7.99.2-1 ----------------------------- * Fri Oct 07 2005 Nils Philippsen 1.7.99.2 - write comment about the ZONE parameter into /etc/sysconfig/clock (#123101) - handle comments when reading /etc/sysconfig/clock - consistently use spaces for indentation in timezoneBackend.py ttmkfdir-3.0.9-19 ----------------- * Sat Oct 08 2005 LingNing Zhang -3.0.9-19 - add ttmkfdir-3.0.9-segfaults.patch to fix bug #164969 util-linux-2.13-0.4.pre4 ------------------------ * Fri Oct 07 2005 Karel Zak 2.13-0.4.pre4 - fix #169628 - /usr/bin/floppy doesn't work with /dev/fd0 - fix #168436 - login will attempt to run if it has no read/write access to its terminal - fix #168434 - login's timeout can fail - needs to call siginterrupt(SIGALRM,1) - fix #165253 ??? losetup missing option -a [new feature] - update PAM files (replace pam_stack with new "include" PAM directive) - remove kbdrate from src.rpm - update to 2.13pre4 * Fri Oct 07 2005 Steve Dickson 2.13-0.3.pre3 - fix #170110 - Documentation for 'rsize' and 'wsize' NFS mount options is misleading xpdf-1:3.01-2 ------------- * Fri Oct 07 2005 Than Ngo 3.01-2 - apply upstream patch to fix resize/redraw bug #166569 Broken deps for s390x ---------------------------------------------------------- rhpl - 0.175-1.s390x requires rhpxl rhpl - 0.175-1.s390x requires firstboot anaconda - 10.3.0.29-1.s390x requires rhpxl Broken deps for ppc64 ---------------------------------------------------------- rhpl - 0.175-1.ppc64 requires rhpxl rhpl - 0.175-1.ppc64 requires firstboot anaconda - 10.3.0.29-1.ppc64 requires rhpxl Broken deps for s390 ---------------------------------------------------------- anaconda - 10.3.0.29-1.s390 requires rhpxl rhpl - 0.175-1.s390 requires firstboot rhpl - 0.175-1.s390 requires rhpxl From wrrhdev at riede.org Sat Oct 8 14:50:33 2005 From: wrrhdev at riede.org (Willem Riede) Date: Sat, 08 Oct 2005 14:50:33 +0000 Subject: rawhide report: 20051006 changes In-Reply-To: <200510061131.j96BVeZP007457@porkchop.devel.redhat.com> (from buildsys@redhat.com on Thu Oct 6 07:31:40 2005) References: <200510061131.j96BVeZP007457@porkchop.devel.redhat.com> Message-ID: <1128783033l.32027l.0l@serve.riede.org> On 10/06/2005 07:31:40 AM, Build System wrote: > > anaconda-10.3.0.28-1 > -------------------- > * Wed Oct 05 2005 Chris Lumens 10.3.0.28-1 > > - Don't skip manual partitioning on custom (katzj, #169001) Confirmed. However, I now crash when trying to create a raid volume, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170189 Traceback (most recent call last): File "/usr/lib/anaconda/iw/partition_gui.py", line 1240, in makeraidCB lbltxt = _("Software RAID allows you to combine " NameError: global name 'constants' is not defined ... Regards, Willem Riede. From philipp_subx at redfish-solutions.com Sat Oct 8 20:39:31 2005 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sat, 08 Oct 2005 14:39:31 -0600 Subject: Question about configure and auto-detecting fedora Message-ID: <43482E83.3000104@redfish-solutions.com> I'm running FC3 (updated) on an x86_64 machine, and I see: checking for x86_64-redhat-linux-gnu-gcc... no when running configure building various source RPMs. Any idea why this is, or if there's a bug filled for it? Perhaps even a fix? Thanks, -Philip From nmiell at comcast.net Sat Oct 8 20:52:50 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Sat, 08 Oct 2005 13:52:50 -0700 Subject: Question about configure and auto-detecting fedora In-Reply-To: <43482E83.3000104@redfish-solutions.com> References: <43482E83.3000104@redfish-solutions.com> Message-ID: <1128804770.2784.0.camel@entropy> On Sat, 2005-10-08 at 14:39 -0600, Philip Prindeville wrote: > I'm running FC3 (updated) on an x86_64 machine, and I see: > > checking for x86_64-redhat-linux-gnu-gcc... no > > > when running configure building various source RPMs. > > Any idea why this is, or if there's a bug filled for it? Perhaps even > a fix? > Do you have an x86_64-redhat-linux-gnu-gcc somewhere in your $PATH that you expect configure to find? If not, configure is behaving exactly as expected. -- Nicholas Miell From ivazquez at ivazquez.net Sat Oct 8 20:55:14 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 08 Oct 2005 16:55:14 -0400 Subject: Question about configure and auto-detecting fedora In-Reply-To: <43482E83.3000104@redfish-solutions.com> References: <43482E83.3000104@redfish-solutions.com> Message-ID: <1128804914.1308.1.camel@ignacio.lan> On Sat, 2005-10-08 at 14:39 -0600, Philip Prindeville wrote: > I'm running FC3 (updated) on an x86_64 machine, and I see: > > checking for x86_64-redhat-linux-gnu-gcc... no > > > when running configure building various source RPMs. > > Any idea why this is, or if there's a bug filled for it? Perhaps even > a fix? A fully-qualified filename like that is usually used for cross-compiling. On an actual x86_64 machine it would just be called "gcc". -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 casimiro.barreto at gmail.com Sat Oct 8 21:03:37 2005 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Sat, 08 Oct 2005 18:03:37 -0300 Subject: Dependency problems in Rawhide... Message-ID: <43483429.8020106@gmail.com> Dependency Problems in Rawhide (i already know that it eats babies...) Error: Missing Dependency: nspr >= %{nspr_devel} is needed by package thunderbird Error: Missing Dependency: libnautilus-burn.so.1 is needed by package totem Error: Missing Dependency: libnautilus-burn.so.1 is needed by package gnome-media Error: Missing Dependency: mozilla = 37:1.7.11 is needed by package devhelp Error: Missing Dependency: libwnck-1.so.16 is needed by package usermode-gtk Error: Missing Dependency: nspr >= 4.6 is needed by package firefox Error: Missing Dependency: libnautilus-burn.so.1 is needed by package sound-juicer Error: Missing Dependency: libwnck-1.so.16 is needed by package gok Error: Missing Dependency: nspr is needed by package xmlsec1-nss From jspaleta at gmail.com Sat Oct 8 21:39:26 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 8 Oct 2005 17:39:26 -0400 Subject: Dependency problems in Rawhide... In-Reply-To: <43483429.8020106@gmail.com> References: <43483429.8020106@gmail.com> Message-ID: <604aa7910510081439ka199083y9b35b01c848bcb8b@mail.gmail.com> On 10/8/05, Casimiro de Almeida Barreto wrote: > Dependency Problems in Rawhide (i already know that it eats babies...) Uhm... these all look like dependancy problems on your machine or with a mirror you are attempting to use and not problems on rawhide itself. Please read over the daily rawhide build reports either in fedora-test-list or fedora-devel-list to get a summary of known dependancy problems for that day's rawhide tree. The fact that none of these problems are listed in today's report is a good indication that the problems you are seeing are most likely not in the rawhide tree and that you should look carefully at the package set you have installed or attempt to use a different mirror. In fact I can't reproduce any of these errors. Simple inspection with the repoquery tool indicates that rawhide, at least for the i386 tree is not to blame for these errors. * in rawhide right now we have usermode-gtk-1.81-1 which requires libwnck-1.so.18. There error you give below is being generated from a version of usermode-gtk that does not exist in the most recent rawhide tree. You should grab yum-utils from fedora extras and play with the repoquery. Its a pretty good tool for diagnosing these sorts of things. * the latest mozilla in rawhide is mozilla-1.7.11-5 which satifies the devhelp package requirement you have listed. * rawhide no longer contains any package that provides libnautilus-burn.so.1 libnautilus-burn.so.2 is now provided. totem and gnome-media in rawhide both require libnautilus-burn.so.2 now * nspr-4.6-4 exists in rawhide and provides nspr >= 4.6 -jef > > Error: Missing Dependency: nspr >= %{nspr_devel} is needed by package > thunderbird > Error: Missing Dependency: libnautilus-burn.so.1 is needed by package totem > Error: Missing Dependency: libnautilus-burn.so.1 is needed by package > gnome-media > Error: Missing Dependency: mozilla = 37:1.7.11 is needed by package devhelp > Error: Missing Dependency: libwnck-1.so.16 is needed by package usermode-gtk > Error: Missing Dependency: nspr >= 4.6 is needed by package firefox > Error: Missing Dependency: libnautilus-burn.so.1 is needed by package > sound-juicer > Error: Missing Dependency: libwnck-1.so.16 is needed by package gok > Error: Missing Dependency: nspr is needed by package xmlsec1-nss > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From tgl at redhat.com Sat Oct 8 21:49:09 2005 From: tgl at redhat.com (Tom Lane) Date: Sat, 08 Oct 2005 17:49:09 -0400 Subject: Deprecating pam_stack.so In-Reply-To: <1128690065.3156.29.camel@perun.redhat.usu> References: <1128690065.3156.29.camel@perun.redhat.usu> Message-ID: <1209.1128808149@sss.pgh.pa.us> Tomas Mraz writes: > Linux-PAM 0.78 and later contains include directive which obsoletes > using the pam_stack module. What does that version translate into in terms of RHEL/Fedora releases? What would be an appropriate replacement for a trivial default config file, eg #%PAM-1.0 auth required pam_stack.so service=system-auth account required pam_stack.so service=system-auth regards, tom lane From nicolas.mailhot at laposte.net Sat Oct 8 21:52:12 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 08 Oct 2005 23:52:12 +0200 Subject: Dependency problems in Rawhide... In-Reply-To: <604aa7910510081439ka199083y9b35b01c848bcb8b@mail.gmail.com> References: <43483429.8020106@gmail.com> <604aa7910510081439ka199083y9b35b01c848bcb8b@mail.gmail.com> Message-ID: <1128808332.3051.25.camel@rousalka.dyndns.org> Le samedi 08 octobre 2005 ? 17:39 -0400, Jeff Spaleta a ?crit : > On 10/8/05, Casimiro de Almeida Barreto wrote: > > Dependency Problems in Rawhide (i already know that it eats babies...) > > Uhm... these all look like dependancy problems on your machine or with > a mirror you are attempting to use and not problems on rawhide itself. The only problems I have on this box is the ghostscript update blocking on gimp-print and libgnome having different versions in i386 and x86_64 trees. Are these local artifacts ? Or real problems ? Error: Missing Dependency: libijs.so()(64bit) is needed by package gimp-print Transaction Check Error: file /etc/gconf/schemas/desktop_gnome_interface.schemas from install of libgnome-2.12.0.1-1 conflicts with file from package libgnome-2.12.0-2 -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From reuben-fedora-devel at reub.net Sat Oct 8 22:31:11 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Sun, 09 Oct 2005 11:31:11 +1300 Subject: Dependency problems in Rawhide... In-Reply-To: <1128808332.3051.25.camel@rousalka.dyndns.org> References: <43483429.8020106@gmail.com> <604aa7910510081439ka199083y9b35b01c848bcb8b@mail.gmail.com> <1128808332.3051.25.camel@rousalka.dyndns.org> Message-ID: <434848AF.3000505@reub.net> Hi, On 10/09/2005 10:52 AM, Nicolas Mailhot wrote: > Le samedi 08 octobre 2005 ? 17:39 -0400, Jeff Spaleta a ?crit : >> On 10/8/05, Casimiro de Almeida Barreto wrote: >>> Dependency Problems in Rawhide (i already know that it eats babies...) >> Uhm... these all look like dependancy problems on your machine or with >> a mirror you are attempting to use and not problems on rawhide itself. > > The only problems I have on this box is the ghostscript update blocking > on gimp-print and libgnome having different versions in i386 and x86_64 > trees. Are these local artifacts ? Or real problems ? > > Error: Missing Dependency: libijs.so()(64bit) is needed by package > gimp-print > > > Transaction Check Error: > file /etc/gconf/schemas/desktop_gnome_interface.schemas from install of > libgnome-2.12.0.1-1 conflicts with file from package libgnome-2.12.0-2 Since the latest change to rhpl in current rawhide which now has in it's specfile {Requires: firstboot, rhpxl} my box was trying to pull in about 40MB of other gui-related stuff such as system-config-* via the dependency on firstboot. This is a server type box with no GUI, so I just uninstalled authconfig, system-config-printer and hal-cups-utils for now. Maybe I don't need them anyway. Reuben From fedora at camperquake.de Sun Oct 9 10:07:47 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 9 Oct 2005 12:07:47 +0200 Subject: WARNING - iproute breaks networking (Re: rawhide report: 20051007 changes) In-Reply-To: <43477B8C.2090201@web.de> References: <43477B8C.2090201@web.de> Message-ID: <20051009100747.GA30028@ryoko.camperquake.de> On Sat, Oct 08, 2005 at 03:55:56AM -0400, Marcus Hartig wrote: > Sorry, I ask me really how that can be? Happens. Rawhide breaks things, you get to keep all the pieces, though. > Its a error where the system do > not more boot here. Do the maintainer(s) not testing this before > uploading their new package to rawhide? That's what beta testers are for. In other words, we :) From buildsys at redhat.com Sun Oct 9 11:15:58 2005 From: buildsys at redhat.com (Build System) Date: Sun, 9 Oct 2005 07:15:58 -0400 Subject: rawhide report: 20051009 changes Message-ID: <200510091115.j99BFw6R006747@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.4.1-4.cvs20051009 ---------------------------------- * Sun Oct 09 2005 Dan Williams - 0.4.1-4.cvs20051009 - Update to latest CVS o Integrate connection progress with applet icon (Chris Aillon) o More information in "Connection Information" dialog (Robert Love) o Shorten time taken to sleep o Make applet icon wireless strength levels a bit more realistic o Talk to named using DBUS rather than spawning our own - You need to add "-D" to the OPTIONS line in /etc/sysconfig/named - You need to set named to start as a service on startup firefox-1.5-0.5.0.beta2 ----------------------- * Sat Oct 08 2005 Christopher Aillon - 1.5-0.5.0.beta2 - Update to 1.5 beta 2 rhgb-0.16.2-5 ------------- * Sun Oct 09 2005 Florian La Roche - fix rebuild problems * Mon Jan 31 2005 Bill Nottingham 0.16.2 - fix resetting of init's console on exit (#141953) * Fri Nov 19 2004 Daniel Veillard 0.16.1 - switch to display :9 to fix #139704 - delay creation of the fifo after X initialization to avoid deadlock with initscripts if X fails to start #135574 - cleanup in case of deadly signal received - improved the debugging layer to chase aformentioned bugs. - po/*: update the translations rpm-4.4.2-6 ----------- * Sun Oct 09 2005 Florian La Roche - rebuild for sqlite changes thunderbird-0:1.5-0.5.0.beta2 ----------------------------- * Sat Oct 08 2005 Christopher Aillon 1.5-0.5.0.beta2 - Update to 1.5 beta2 Broken deps for ppc64 ---------------------------------------------------------- anaconda - 10.3.0.29-1.ppc64 requires rhpxl rhpl - 0.175-1.ppc64 requires rhpxl rhpl - 0.175-1.ppc64 requires firstboot Broken deps for s390x ---------------------------------------------------------- rhpl - 0.175-1.s390x requires rhpxl rhpl - 0.175-1.s390x requires firstboot anaconda - 10.3.0.29-1.s390x requires rhpxl Broken deps for s390 ---------------------------------------------------------- rhpl - 0.175-1.s390 requires firstboot rhpl - 0.175-1.s390 requires rhpxl anaconda - 10.3.0.29-1.s390 requires rhpxl From tgl at redhat.com Sun Oct 9 15:56:31 2005 From: tgl at redhat.com (Tom Lane) Date: Sun, 09 Oct 2005 11:56:31 -0400 Subject: WARNING - iproute breaks networking (Re: rawhide report: 20051007 changes) In-Reply-To: <20051009100747.GA30028@ryoko.camperquake.de> References: <43477B8C.2090201@web.de> <20051009100747.GA30028@ryoko.camperquake.de> Message-ID: <6567.1128873391@sss.pgh.pa.us> Ralf Ertzinger writes: > On Sat, Oct 08, 2005 at 03:55:56AM -0400, Marcus Hartig wrote: >> Its a error where the system do >> not more boot here. Do the maintainer(s) not testing this before >> uploading their new package to rawhide? > That's what beta testers are for. In other words, we :) Rawhide is not beta testing. Rawhide is alpha testing. If you're not prepared for occasional breakage, you should be using a Fedora release not the rawhide feed. regards, tom lane From tmraz at redhat.com Mon Oct 10 07:58:46 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 10 Oct 2005 09:58:46 +0200 Subject: Deprecating pam_stack.so In-Reply-To: <1209.1128808149@sss.pgh.pa.us> References: <1128690065.3156.29.camel@perun.redhat.usu> <1209.1128808149@sss.pgh.pa.us> Message-ID: <1128931126.3128.10.camel@perun.redhat.usu> On Sat, 2005-10-08 at 17:49 -0400, Tom Lane wrote: > Tomas Mraz writes: > > Linux-PAM 0.78 and later contains include directive which obsoletes > > using the pam_stack module. > > What does that version translate into in terms of RHEL/Fedora releases? > > What would be an appropriate replacement for a trivial default > config file, eg > > #%PAM-1.0 > auth required pam_stack.so service=system-auth > account required pam_stack.so service=system-auth Such a simple config file is replaced with: #%PAM-1.0 auth include system-auth account include system-auth However things get more complicated if in the existing config there are modules AFTER the pam_stack in the auth, account or password phases. Basically they cannot be there if include is used because in the included file there may be "sufficient" entries. So the new config files must be rearranged so these modules are moved up before the include. But sometimes (for example with pam_nologin) it is not possible because it would change semantics a little bit so it's better to move the pam_nologin to account phase. I'm also introducing a new common config file (config-util) which should be used for all system-config-... utilities which use userhelper. So all these utilities should have the same config: #%PAM-1.0 auth include config-util account include config-util session include config-util -- Tomas Mraz From jfrieben at freesurf.fr Mon Oct 10 09:00:53 2005 From: jfrieben at freesurf.fr (jfrieben at freesurf.fr) Date: Mon, 10 Oct 2005 11:00:53 +0200 (CEST) Subject: Modular X server build issues Message-ID: <13772.194.94.224.254.1128934853.squirrel@arlette.freesurf.fr> I have rebuilt Mike Harris' experimental modular xorg-x11 RPMs on a base FC4 system. The following issues surfaced during the build (not restricted to FC4, they apply to "rawhide" as well): 1. Conflicting files "/usr/include/GL/glx.h" for "mesa-GL-devel" and "xorg-x11-proto-devel". 2. Conflicting files "/usr/include/GL/glu.h" for "mesa-GLU-devel" and "xorg-x11-proto-devel". 2. Wrong requirement "xorg-x11-server" when the right package name was "xorg-x11-server-Xorg", applies to "xorg-x11-server-Xvfb" and "xorg-x11-server-Xnest" spec files 3. drv packages do not build because 'pkg-config xorg-x11-server --variable=driverdir' and 'pkg-config xorg-x11-server --variable=inputdir' are nil whereas 'pkg-config xorg-x11-server --variable=moduledir' yields "/usr/lib/xorg/modules". "moduledir" and "inputdir" are apparently undefined. A workaround is to set "driverdir" and "inputdir" in the spec file to "%(moduledir)/drivers" and "%(moduledir)/input" respectively. 4. xorg-x11-drv-mouse: "/usr/shar/man/man4/mouse.4.gz" conflicts with file from package "man-pages". From gajownik at fedora.pl Mon Oct 10 09:45:09 2005 From: gajownik at fedora.pl (Dawid Gajownik) Date: Mon, 10 Oct 2005 11:45:09 +0200 Subject: Modular X server build issues In-Reply-To: <13772.194.94.224.254.1128934853.squirrel@arlette.freesurf.fr> References: <13772.194.94.224.254.1128934853.squirrel@arlette.freesurf.fr> Message-ID: <434A3825.9030606@fedora.pl> Dnia 10/10/2005 11:00 AM, U?ytkownik jfrieben at freesurf.fr napisa?: > 1. Conflicting files "/usr/include/GL/glx.h" for "mesa-GL-devel" > and "xorg-x11-proto-devel". > > 2. Conflicting files "/usr/include/GL/glu.h" for "mesa-GLU-devel" and > "xorg-x11-proto-devel". This is fixed in CVS ? https://bugs.freedesktop.org/show_bug.cgi?id=4036 You'll need to make your own glproto tarball or wait for X.org X11R7.0-RC1 release. Hope that helps. -- ^_* From buildsys at redhat.com Mon Oct 10 11:13:31 2005 From: buildsys at redhat.com (Build System) Date: Mon, 10 Oct 2005 07:13:31 -0400 Subject: rawhide report: 20051010 changes Message-ID: <200510101113.j9ABDVZD016566@porkchop.devel.redhat.com> Updated Packages: festival-1.95-4 --------------- * Mon Oct 10 2005 Florian La Roche - another try to get it to compile again ntp-4.2.0.a.20050816-2 ---------------------- * Tue Sep 27 2005 Petr Raszyk 4.2.0.a.20050816-2 - A cosmetic patch. There are some comments and braces '{' '}' added. - One unprintable character was converted to octal-form . - It can be removed anytime (conversion of the cvs-projets for C-Frame 121, - (auto-debug, auto-trace for cfr-printnet server). perl-3:5.8.7-0.5.fc5 -------------------- * Sun Oct 09 2005 Warren Togami - 3:5.8.7-0.4 - rebuild for db4 (#170235) * Mon Sep 05 2005 Warren Togami - 3:5.8.7-0.3 - convert docs to UTF-8 (#140871) * Sat Sep 03 2005 Warren Togami - 3:5.8.7-0.2 - scriptdir to /usr/bin (#167205) udev-069-9 ---------- * Mon Oct 10 2005 Harald Hoyer - 069-9 - added libsepol-devel BuildReq - refined persistent rules * Mon Oct 10 2005 Harald Hoyer - 069-8 - corrected c&p edd_id rule, symlink for js devices - added -lsepol xsane-0.97-1 ------------ * Tue Oct 04 2005 Nils Philippsen 0.97-1 - version 0.97 Broken deps for s390x ---------------------------------------------------------- anaconda - 10.3.0.29-1.s390x requires rhpxl rhpl - 0.175-1.s390x requires rhpxl rhpl - 0.175-1.s390x requires firstboot Broken deps for ppc64 ---------------------------------------------------------- rhpl - 0.175-1.ppc64 requires rhpxl rhpl - 0.175-1.ppc64 requires firstboot anaconda - 10.3.0.29-1.ppc64 requires rhpxl Broken deps for s390 ---------------------------------------------------------- anaconda - 10.3.0.29-1.s390 requires rhpxl rhpl - 0.175-1.s390 requires firstboot rhpl - 0.175-1.s390 requires rhpxl From mpeters at mac.com Mon Oct 10 11:32:07 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 10 Oct 2005 04:32:07 -0700 Subject: OpenType .otf fonts and printing Message-ID: <1128943927.17311.11.camel@locolhost.localdomain> Type 1 outline OpenType fonts work very well through fontconfig, but it seems that they do not print. Evolution will just leave the space blank, Firefox will substitute (seems to pick a generic font - IE my monospace sans-serif font is substituted with a variable serif font when firefox prints). AbiWord won't even load the font (apparently intentionally) so that you don't pick a font you can't print. Virtually all Adobe fonts are now only available in this format, and many other foundries are at least headed that direction (though often makey type1 and/or ttf available as well). I can use fontforge to change them to a format that does print (though I'm not sure if the licenses that forbid decompiling would like that) so its not a huge issue, but I'm curious as to what work (if any) is going on in the Fedora/Gnome world to bring proper type1 otf printing support to Fedora. The ttf outline opentype fonts (which seem to have a .ttf extension) such as Palatino Linotype seem to work just fine. It's only the .otf fonts that don't print (but look absolutely gorgeous on screen). From j.underwood at open.ac.uk Mon Oct 10 17:37:22 2005 From: j.underwood at open.ac.uk (Jonathan Underwood) Date: Mon, 10 Oct 2005 18:37:22 +0100 Subject: A new utility "System Control Center (system-config-control)" ! In-Reply-To: <20051006112054.37961.qmail@web33603.mail.mud.yahoo.com> References: <20051006112054.37961.qmail@web33603.mail.mud.yahoo.com> Message-ID: Ankit Patel wrote: > Hi all, > > I have tried to make one utility called > "system-config-control" for Fedora. Downloads (RPM, > SRPM, zipped source) and Snapshots are awailable on > http://www.indianoss.org . Right now it's available in > only one language (Gujarati-India). I wonder - what does this offer that gnome-system-tools doesn't? I also idley wonder why Fedora sticks with system-config-* rather than gnome-system-tools and friends, given the push for upstream compatibilitiy, but that's another thread :). Jonathan. From sundaram at redhat.com Mon Oct 10 17:51:22 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 10 Oct 2005 23:21:22 +0530 Subject: A new utility "System Control Center (system-config-control)" ! In-Reply-To: References: <20051006112054.37961.qmail@web33603.mail.mud.yahoo.com> Message-ID: <434AAA1A.4030104@redhat.com> Jonathan Underwood wrote: > Ankit Patel wrote: > >> Hi all, >> >> I have tried to make one utility called >> "system-config-control" for Fedora. Downloads (RPM, >> SRPM, zipped source) and Snapshots are awailable on >> http://www.indianoss.org . Right now it's available in >> only one language (Gujarati-India). > > > I wonder - what does this offer that gnome-system-tools doesn't? > This tool attempts to provide a centralized collection of the existing system config tools in Fedora. You are free to package gnome-system-tools in Fedora Extras repository. There are feature differences between the set of tools. The current set of tools in core are better integrated with what Fedora wants to provide on the whole. SELinux or LVM functionality for example > I also idley wonder why Fedora sticks with system-config-* rather than > gnome-system-tools and friends, given the push for upstream > compatibilitiy, but that's another thread :). In the longer run, we might want to merge these features but things like SELinux are Linux specific obviously and gnome-system-tools supports other operating systems too so there is likely to be differences. regards Rahul From fedora at wir-sind-cool.org Mon Oct 10 18:14:40 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 10 Oct 2005 20:14:40 +0200 Subject: [Bug 170291] New: GNOME cannot find kile icon In-Reply-To: References: Message-ID: <20051010201440.5af97674.fedora@wir-sind-cool.org> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170291 > After installing kile GNOME is not able to find the kile icon. The kile entry in > the Application/Office menu shows no icon. > > This problem can be solved by deleting /usr/share/icons/hicolor/icon-theme.cache > and executing "gtk-update-icon-cache /usr/share/icons/hicolor". Without the > deletion gtk-update-icon-cache doesn't update the cache file. > > > Version-Release number of selected component (if applicable): > kile-1.8.1-3.fc4 Since I think this has come up a few times occasionally, to me it still sounds like GNOME brokeness. What kind of icon caching concept is this? If the cache file gets out-of-date and an icon is not found within the cache, the desktop system doesn't search the file system? Huh? Or maybe this is configurable in some place? Why should a KDE application maintain a GTK icon theme cache file? -- Michael Schwendt Fedora Core release 4 (Rawhide) - Linux 2.6.13-1.1600_FC5 loadavg: 1.00 1.09 1.37 From rdieter at math.unl.edu Mon Oct 10 19:34:22 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 10 Oct 2005 14:34:22 -0500 Subject: [Bug 170291] New: GNOME cannot find kile icon In-Reply-To: <20051010201440.5af97674.fedora@wir-sind-cool.org> References: <20051010201440.5af97674.fedora@wir-sind-cool.org> Message-ID: <434AC23E.8040204@math.unl.edu> Michael Schwendt wrote: >>This problem can be solved by deleting /usr/share/icons/hicolor/icon-theme.cache >>and executing "gtk-update-icon-cache /usr/share/icons/hicolor". Without the >>deletion gtk-update-icon-cache doesn't update the cache file. > Since I think this has come up a few times occasionally, to me it still > sounds like GNOME brokeness. What kind of icon caching concept is > this? If the cache file gets out-of-date and an icon is not found within > the cache, the desktop system doesn't search the file system? Huh? Or > maybe this is configurable in some place? Why should a KDE application > maintain a GTK icon theme cache file? Amen. "gtk-update-icon-cache automatic" http://bugzilla.redhat.com/bugzilla/170335 -- Rex From rdieter at math.unl.edu Mon Oct 10 19:36:07 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 10 Oct 2005 14:36:07 -0500 Subject: OpenType .otf fonts and printing In-Reply-To: <1128943927.17311.11.camel@locolhost.localdomain> References: <1128943927.17311.11.camel@locolhost.localdomain> Message-ID: <434AC2A7.8070705@math.unl.edu> Michael A. Peters wrote: > It's only the .otf > fonts that don't print (but look absolutely gorgeous on screen). I could swear I've used at least several .otf fonts just fine in the past. How many different fonts did you try? (And, if you don't mind, which ones were they?) -- Rex From jkeating at j2solutions.net Mon Oct 10 20:35:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 10 Oct 2005 13:35:51 -0700 Subject: Generic PCL6 driver to print Duplex Message-ID: <1128976551.7991.115.camel@prometheus.gamehouse.com> Where can I start looking to modify the generic PCL6 driver to be able to print Duplex? Seems strange to me that this driver doesn't have the option... -- 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 From mpeters at mac.com Mon Oct 10 20:36:35 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 10 Oct 2005 13:36:35 -0700 Subject: OpenType .otf fonts and printing In-Reply-To: <434AC2A7.8070705@math.unl.edu> References: <1128943927.17311.11.camel@locolhost.localdomain> <434AC2A7.8070705@math.unl.edu> Message-ID: <1128976595.17311.76.camel@locolhost.localdomain> On Mon, 2005-10-10 at 14:36 -0500, Rex Dieter wrote: > Michael A. Peters wrote: > > It's only the .otf > > fonts that don't print (but look absolutely gorgeous on screen). > > I could swear I've used at least several .otf fonts just fine in the > past. How many different fonts did you try? (And, if you don't mind, > which ones were they?) They work just fine for display - and some apps substitute others when printing. These are the fonts - 1) Helvetica LT Std (from Adobe) 2) Courier Std (from Adobe - free with Acroread in their Fonts directory) 3) LucidaMonoEFOP (Elsner+Flake) Lucida Mono is an exceptionally beautiful (imho) monospace font, reminds me a lot of Monaco on Mac OS. From kyrre at solution-forge.net Mon Oct 10 21:29:19 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 10 Oct 2005 23:29:19 +0200 Subject: OpenType .otf fonts and printing In-Reply-To: <1128976595.17311.76.camel@locolhost.localdomain> References: <1128943927.17311.11.camel@locolhost.localdomain> <434AC2A7.8070705@math.unl.edu> <1128976595.17311.76.camel@locolhost.localdomain> Message-ID: <1128979759.8521.8.camel@localhost.localdomain> Could there be print driver differences? man, 10.10.2005 kl. 22.36 skrev Michael A. Peters: > On Mon, 2005-10-10 at 14:36 -0500, Rex Dieter wrote: > > Michael A. Peters wrote: > > > It's only the .otf > > > fonts that don't print (but look absolutely gorgeous on screen). > > > > I could swear I've used at least several .otf fonts just fine in the > > past. How many different fonts did you try? (And, if you don't mind, > > which ones were they?) > > They work just fine for display - and some apps substitute others when > printing. > > These are the fonts - > > 1) Helvetica LT Std (from Adobe) > 2) Courier Std (from Adobe - free with Acroread in their Fonts > directory) > 3) LucidaMonoEFOP (Elsner+Flake) > > Lucida Mono is an exceptionally beautiful (imho) monospace font, reminds > me a lot of Monaco on Mac OS. From mpeters at mac.com Mon Oct 10 22:47:41 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 10 Oct 2005 15:47:41 -0700 Subject: OpenType .otf fonts and printing In-Reply-To: <1128979759.8521.8.camel@localhost.localdomain> References: <1128943927.17311.11.camel@locolhost.localdomain> <434AC2A7.8070705@math.unl.edu> <1128976595.17311.76.camel@locolhost.localdomain> <1128979759.8521.8.camel@localhost.localdomain> Message-ID: <1128984461.17311.82.camel@locolhost.localdomain> On Mon, 2005-10-10 at 23:29 +0200, Kyrre Ness Sjobak wrote: > Could there be print driver differences? OK - it seems to be a evolution issue. Mozilla is printing them correctly now, which makes me think that when I tested (shortly after installing) it had a font cache issue with its print driver. Evolution though - prints blank to printer and to pdf. However, gedit prints just fine - I believe both use gnomeprint. I'll find a free Type1 outline font and repeat it and file a bugzilla. From katzj at redhat.com Tue Oct 11 01:45:02 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 10 Oct 2005 21:45:02 -0400 Subject: Anaconda, grub and XFS In-Reply-To: References: <43454FD3.4000400@moving-picture.com> <1128695335.12602.59.camel@bree.local.net> Message-ID: <1128995102.2826.43.camel@bree.local.net> On Sat, 2005-10-08 at 12:00 +0100, James Pearson wrote: > On 10/7/05, Jeremy Katz wrote: > > On Thu, 2005-10-06 at 17:24 +0100, James Pearson wrote: > > > There has been an on going issue with installing grub on an XFS > > > partition - anaconda will hang at the installing boot loader stage as > > > grub 'spins'. > > > > > > The attached patch for 'booty' works round this problem by remounting > > > the XFS file system that contains /boot as read-only and then as > > > read-write before running the grub install command. > > > > > > This patch replaces the current XFS freeze/thaw work round that fails to > > > work (a lot) more often than not. > > > > This feels like a hack for the fact that xfs_freeze doesn't work as it > > was designed to -- it is specifically for things which need the contents > > on disk to actually be what the kernel thinks is there. And the > > continued need of random hacks like this make me more and more inclined > > to just disallow the use of XFS as a bootable filesystem. > > But this is a 'hack' that replaces a 'hack' that doesn't work ... so > the total number of hacks in anaconda won't increase :-) Yes, but it's a hack that was added at the explicit request of the XFS developers with a "this will fix the problems". And having to constantly change it because they don't want to have the same semantics as all of the other filesystems which are even pseudo-supported is a waste of time. Jeremy From mclasen at redhat.com Tue Oct 11 03:04:04 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 10 Oct 2005 23:04:04 -0400 Subject: [Bug 170291] New: GNOME cannot find kile icon In-Reply-To: <20051010201440.5af97674.fedora@wir-sind-cool.org> References: <20051010201440.5af97674.fedora@wir-sind-cool.org> Message-ID: <1128999845.2435.0.camel@c-24-218-204-47.hsd1.ma.comcast.net> On Mon, 2005-10-10 at 20:14 +0200, Michael Schwendt wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170291 > > > After installing kile GNOME is not able to find the kile icon. The kile entry in > > the Application/Office menu shows no icon. > > > > This problem can be solved by deleting /usr/share/icons/hicolor/icon-theme.cache > > and executing "gtk-update-icon-cache /usr/share/icons/hicolor". Without the > > deletion gtk-update-icon-cache doesn't update the cache file. > > > > > > Version-Release number of selected component (if applicable): > > kile-1.8.1-3.fc4 > > Since I think this has come up a few times occasionally, to me it still > sounds like GNOME brokeness. What kind of icon caching concept is > this? If the cache file gets out-of-date and an icon is not found within > the cache, the desktop system doesn't search the file system? Huh? Or > maybe this is configurable in some place? Why should a KDE application > maintain a GTK icon theme cache file? They don't have to. It would be enough if they actually followed the icon theme spec they claim to be using, and touched the toplevel theme directory when installing a new icon. Matthias From cloos+redhat-fedora-devel at jhcloos.com Tue Oct 11 08:23:39 2005 From: cloos+redhat-fedora-devel at jhcloos.com (James Cloos) Date: Tue, 11 Oct 2005 04:23:39 -0400 Subject: OpenType .otf fonts and printing In-Reply-To: <1128943927.17311.11.camel@locolhost.localdomain> (Michael A. Peters's message of "Mon, 10 Oct 2005 04:32:07 -0700") References: <1128943927.17311.11.camel@locolhost.localdomain> Message-ID: >>>>> "Michael" == Michael A Peters writes: Michael> Type 1 outline OpenType fonts work very well through Michael> fontconfig, but it seems that they do not print. As you've found support for sfnt/cff fonts is not as exhaustive as it ought to be. Part of the problem is that not everyone knows how to embed them into a postscript or pdf stream (or file). There are just enough differences that it takes new code, and there is no library yet providing that code. (Actually the latest versions of QT may have such library level support, but even there many packages -- including kde 3.x -- are written to the QT3.x api and need to be ported to QT4.x.) Some packages have added support (eg scribus 1.3.x) and some will eventually (eg Abiword). If libgnomeprint-2.12 has support for embedding sfnt/cff then many more applications will, too. An interm solution is to follow what is being done for TeX. The lcdf type tools (available at http://www.lcdf.org/type/) now include several tools for otf (aka sfnt/cff) fonts. Specifically you want to use cfftot1 to convert either raw cff fonts or sfnt/cff fonts into type1 fonts. This will be more robust than using fontforge and probably less likely to cause licensing problems. (Embedding a sfnt/cff font into level 1 or 'early' level 2 postscript requires doing this anyway, so leaving the type1 representation on disk shouldn't be an issue, but of course ymmv....) Note though that converting to t1 format looses all of the opentype features. All of the glyphs are still there but you may not be able to access them. So this is only an *interm* solution. -JimC -- James H. Cloos, Jr. From twaugh at redhat.com Tue Oct 11 08:40:52 2005 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 11 Oct 2005 09:40:52 +0100 Subject: Generic PCL6 driver to print Duplex In-Reply-To: <1128976551.7991.115.camel@prometheus.gamehouse.com> References: <1128976551.7991.115.camel@prometheus.gamehouse.com> Message-ID: <20051011084052.GF2628@redhat.com> On Mon, Oct 10, 2005 at 01:35:51PM -0700, Jesse Keating wrote: > Where can I start looking to modify the generic PCL6 driver to be able > to print Duplex? Seems strange to me that this driver doesn't have the > option... You need to modify foomatic to do that. A good place to start is to ask on the foomatic-devel mailing list: http://www.linuxprinting.org/cgi-bin/mailman/listinfo/foomatic-devel Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From james-p at moving-picture.com Tue Oct 11 09:50:02 2005 From: james-p at moving-picture.com (James Pearson) Date: Tue, 11 Oct 2005 10:50:02 +0100 Subject: Anaconda, grub and XFS In-Reply-To: <434B21BA.3080401@sgi.com> References: <43454FD3.4000400@moving-picture.com> <1128695335.12602.59.camel@bree.local.net> <1128995102.2826.43.camel@bree.local.net> <434B21BA.3080401@sgi.com> Message-ID: <434B8ACA.6080907@moving-picture.com> Eric Sandeen wrote: > Jeremy Katz wrote: > >> Yes, but it's a hack that was added at the explicit request of the XFS >> developers with a "this will fix the problems". And having to >> constantly change it because they don't want to have the same semantics >> as all of the other filesystems which are even pseudo-supported is a >> waste of time. > > > Jeremy, I do apologize for the previous workaround which ... didn't work. > > But I have to take issue with the "semantics" you mentioned. Nothing in > the linux kernel guarantees that the block device address space will be > coherent with the filesystem address space - so what grub is trying to > do here (write through the filesystem, read back via the block device > with fs still mounted) is fundamentally broken. > > ext2 seems less prone to problems, I'm not sure why. But there is no > guarantee or mechanism in the kernel to make what grub is doing > bulletproof. (last I looked there were lots of wishful "syncs" in the > grub code, along with comments that did not inspire confidence!) So, if as Eric says, the previous workaround doesn't work, can we have the remount workaround (that works) instead? Thanks James Pearson From mpeters at mac.com Tue Oct 11 10:03:14 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 11 Oct 2005 03:03:14 -0700 Subject: OpenType .otf fonts and printing In-Reply-To: References: <1128943927.17311.11.camel@locolhost.localdomain> Message-ID: <1129024994.28326.23.camel@locolhost.localdomain> On Tue, 2005-10-11 at 04:23 -0400, James Cloos wrote: > > An interm solution is to follow what is being done for TeX. The lcdf > type tools (available at http://www.lcdf.org/type/) lcdf-typetools is now in Fedora Extras and in fact is what I have been using to use otf fonts in LaTeX quite succesfully. I have used it to make Type1 fonts for system use - though I ran into some oddities with some fonts - such as Helvetica having some numbers (1 and 2) superscript when they shouldn't be. Same thing with the superscript happens with fontforge -c 'open($1); generate($2)' HelveticaLTStd-Roman.otf HelveticaLTStd-Roman.pfb However, using fontforge to generate a .ttf works just fine. I suspect that (at least with Helvetica) I need to tell it more about which glyphs it is suppose to use. I'm guessing the font has a superscript 1 and 2 and when making the more limited glyph set .pfb - it guesses wrong about which 1 and 2 it should use. Interestingly, the Helvetica LT Std font generated for LaTeX using otftotfm works just fine, it's just generated .pfb's for outside latex that have the issue. > Note though that converting to t1 format looses all of the opentype > features. All of the glyphs are still there but you may not be able > to access them. So this is only an *interm* solution. The support is actually better than I thought. When Mozilla couldn't print them I thought support just wasn't there at all - but it seems now that was just the print font cache wasn't updated so it used the fallback. From buildsys at redhat.com Tue Oct 11 11:15:27 2005 From: buildsys at redhat.com (Build System) Date: Tue, 11 Oct 2005 07:15:27 -0400 Subject: rawhide report: 20051011 changes Message-ID: <200510111115.j9BBFRmr009853@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.4.1-5.cvs20051010 ---------------------------------- * Mon Oct 10 2005 Dan Williams - 0.4.1-5.cvs20051010 - Fix automatic wireless connections - Remove usage of NMLoadModules callout, no longer needed - Try to fix deadlock when menu is down and keyring dialog pops up anaconda-10.3.0.30-1 -------------------- * Mon Oct 10 2005 Chris Lumens 10.3.0.30-1 - Fix requirements for s390, s390x, ppc64. - Fix typo in scripts/upd-instroot. audit-1.0.6-1 ------------- * Mon Oct 10 2005 Steve Grubb 1.0.6-1 - in aureport, add column labels to reports - added watch report to aureport - added interpreting mode to aureport - added user space avc standard message to libaudit - aureport & ausearch now use builtin log locations when bad config file - add email alert to low disk space warning actions in auditd eclipse-1:3.1.0_fc-15 --------------------- * Sat Oct 08 2005 Andrew Overholt 3.1.0_fc-15 - Bump mozilla requirement. - Re-enable org.eclipse.ui.forms_3.1.0.jar.so, org.eclipse.osgi_3.1.0.jar.so, and org.eclipse.ui.workbench_3.1.0.jar.so (rh#146463, rh#158137, rh#151919) - Add patch for /etc/gre64.conf (for 64-bit systems, rh#168040, e.o#109253). - Remove MOZILLA_FIVE_HOME magic from eclipse.script. - Remove jdtCompilerAdapter.jar due to aot-compile-rpm smarts. - Bump gcc and java-gcj-compat requirements. - Remove lucene-1.4.3-src.zip (rh#170343). * Wed Aug 24 2005 Andrew Overholt 3.1.0_fc-14 - /usr/lib -> /usr/lib64 in eclipse.script (rh#159031). * Tue Aug 23 2005 Andrew Overholt 3.1.0_fc-13 - Bump mozilla requirement. efax-0.9-25 ----------- * Mon Oct 10 2005 Than Ngo 0.9-25 - use pnmtoxwd instead xloadimage which is not in the core anymore #169413 gawk-3.1.5-4 ------------ * Sun Oct 09 2005 Karel Zak 3.1.5-4 - fix off-by-one error in assignment of sentinel value at end of FIELDWIDTHS array. (patch by - upstream - Aharon Robbins) gd-2.0.33-4 ----------- * Mon Oct 10 2005 Phil Knirsch 2.0.33-4 - Fixed possible gd crash when drawing AA line near image borders (#167843) * Wed Sep 07 2005 Phil Knirsch 2.0.33-3 - Fixed broken freetype-config --libs flags in configure (#165875) * Sun Apr 17 2005 Warren Togami 2.0.33-2 - devel reqs (#155183 thias) glibc-2.3.90-14 --------------- * Mon Oct 10 2005 Jakub Jelinek 2.3.90-14 - update from CVS - fix malloc bug after fork introduced in the last update - fix getent hosts IP for IPv4 IPs (#169831) * Mon Oct 03 2005 Jakub Jelinek 2.3.90-13 - update from CVS - fix setuid etc. hangs if some thread exits during the call (#167766) - fix innetgr memory leak (#169051) - support > 2GB nscd log files (#168851) - too many other changes to list here - include errno in nscd message if audit_open failed (#169148) kdeaccessibility-1:3.4.91-1 --------------------------- * Mon Oct 10 2005 Than Ngo 1:3.4.91-1 - update to 3.5 beta 1 kdebindings-3.4.91-1 -------------------- * Mon Oct 10 2005 Than Ngo 3.4.91-1 - update to 3.5 beta 1 kdenetwork-7:3.4.91-1 --------------------- * Mon Oct 10 2005 Than Ngo 7:3.4.91-1 - update to 3.5 Beta 1 kdewebdev-6:3.4.91-1 -------------------- * Mon Oct 10 2005 Than Ngo 6:3.4.91-1 - update to 3.5 beta 1 libsepol-1.9.14-1 ----------------- * Mon Oct 10 2005 Dan Walsh 1.9.14-1 - Upgrade to latest from NSA * Fixed use of policydb_from_image/to_image to ensure proper init of policydb. * Isolated policydb internal headers under . These headers should only be used by users of the static libsepol. Created new with new public types and interfaces for shared libsepol. Created new with public types and interfaces moved or wrapped from old module.h, link.h, and expand.h, adjusted for new public types for policydb and policy_file. Added public interfaces to libsepol.map. Some implementation changes visible to users of the static libsepol: 1) policydb_read no longer calls policydb_init. Caller must do so first. 2) policydb_init no longer takes policy_type argument. Caller must set policy_type separately. 3) expand_module automatically enables the global branch. Caller no longer needs to do so. 4) policydb_write uses the policy_type and policyvers from the policydb itself, and sepol_set_policyvers() has been removed. libuser-0.54.1-1 ---------------- * Tue Oct 11 2005 Miloslav Trmac - 0.54.1-1 - Support importing of configuration from shadow-utils (/etc/login.defs and /etc/default/useradd) - Add libuser.conf(5) man page logrotate-3.7.2-5 ----------------- * Mon Oct 10 2005 Peter Vrabec 3.7.2-5 - fix bug introduced in logrotate 3.7.2-3(#169858) - fix some memory leaks (#169888) man-pages-2.08-1 ---------------- * Mon Oct 10 2005 Ivana Varekova 2.08-1 - update to 2.08 * Thu Sep 29 2005 Ivana Varekova 2.07-7 - fix typo in nsswitch.conf man page (bug 169309) * Thu Sep 29 2005 Ivana Varekova 2.07-6 - man pages updated for new audit system (added missing man-pages of some syscalls) (see bug 159225) mtr-2:0.69-6 ------------ * Mon Oct 10 2005 Phil Knirsch 2:0.69-6 - Added missing gtk+-devel BuildPreReq (#168215) openldap-2.2.29-2 ----------------- * Mon Oct 10 2005 Jay Fenlason 2.2.29-2 - New upstream version. ppp-2.4.3-4 ----------- * Fri Oct 07 2005 Tomas Mraz 2.4.3-4 - use include instead of pam_stack in pam config rcs-5.7-29 ---------- * Mon Oct 10 2005 Phil Knirsch 5.7-29 - Fixed bug with obsolete and changed -u option for diff (#165071) rhpl-0.175-2 ------------ * Mon Oct 10 2005 Chris Lumens 0.175-2 - Remove rhpxl and firstboot requires. screen-4.0.2-10 --------------- * Mon Oct 10 2005 Tomas Mraz - 4.0.2-10 - use include instead of pam_stack in pam config setools-2.1.2-3 --------------- * Mon Oct 10 2005 Tomas Mraz 2.1.2-3 - use include instead of pam_stack in pam config * Thu Sep 01 2005 Dan Walsh 2.1.2-2 - Fix spec file setuptool-1.17.3-1 ------------------ * Mon Oct 10 2005 Nalin Dahyabhai 1.17.3-1 - update PAM configuration to use "include" directive (#170265_ - conflict with versions of the pam package (< 0.78) which don't support the "include" directive slocate-2.7-28 -------------- * Mon Oct 10 2005 Miloslav Trmac - 2.7-28 - Don't allow root to see all files (#170201) star-1.5a68-1 ------------- * Mon Oct 10 2005 Peter Vrabec 1.5a68-1 - upgrade sysstat-6.0.1-2 --------------- * Mon Oct 10 2005 Ivana Varekova 6.0.1-2 - fix chkconfig problem system-config-nfs-1.3.12-1 -------------------------- * Tue Oct 11 2005 Nils Philippsen 1.3.12 - allow user to set networking ports to be used (#151166) - separate code concerning the NFS server, its settings and NFS exports - some code cleanup * Mon Oct 10 2005 Nils Philippsen - make Properties/Delete menu entries insensitive if nothing is selected * Fri Aug 12 2005 Nils Philippsen - use GtkFileChooser instead of GtkFileSelection (#165768) udev-069-10 ----------- * Mon Oct 10 2005 Harald Hoyer - 069-10 - removed group usb vim-1:6.3.090-1 --------------- * Mon Oct 10 2005 Karsten Hopp 6.3.090-1 - patchlevel 90 - next attempt to fix perl requirements, add perl-epoch (#145475) xorg-x11-6.8.2-55 ----------------- * Mon Oct 10 2005 Mike A. Harris 6.8.2-55 - Fix inverted logic in xorg-x11-6.8.2-ati-radeon-7000-disable-dri.patch, to properly disable DRI on 7000. From rdieter at math.unl.edu Tue Oct 11 12:15:06 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 11 Oct 2005 07:15:06 -0500 Subject: [Bug 170291] New: GNOME cannot find kile icon In-Reply-To: <1128999845.2435.0.camel@c-24-218-204-47.hsd1.ma.comcast.net> References: <20051010201440.5af97674.fedora@wir-sind-cool.org> <1128999845.2435.0.camel@c-24-218-204-47.hsd1.ma.comcast.net> Message-ID: <434BACCA.7060207@math.unl.edu> Matthias Clasen wrote: > On Mon, 2005-10-10 at 20:14 +0200, Michael Schwendt wrote: >>Since I think this has come up a few times occasionally, to me it still >>sounds like GNOME brokeness. What kind of icon caching concept is >>this? If the cache file gets out-of-date and an icon is not found within >>the cache, the desktop system doesn't search the file system? Huh? Or >>maybe this is configurable in some place? Why should a KDE application >>maintain a GTK icon theme cache file? > > > They don't have to. It would be enough if they actually followed the > icon theme spec they claim to be using, and touched the toplevel theme > directory when installing a new icon. The toplevel theme directory being /usr/share/icons or /usr/share/icons/__theme__? -- Rex From mclasen at redhat.com Tue Oct 11 13:16:33 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 11 Oct 2005 09:16:33 -0400 Subject: [Bug 170291] New: GNOME cannot find kile icon In-Reply-To: <434BACCA.7060207@math.unl.edu> References: <20051010201440.5af97674.fedora@wir-sind-cool.org> <1128999845.2435.0.camel@c-24-218-204-47.hsd1.ma.comcast.net> <434BACCA.7060207@math.unl.edu> Message-ID: <1129036593.4177.2.camel@golem.boston.redhat.com> On Tue, 2005-10-11 at 07:15 -0500, Rex Dieter wrote: > Matthias Clasen wrote: > > On Mon, 2005-10-10 at 20:14 +0200, Michael Schwendt wrote: > > >>Since I think this has come up a few times occasionally, to me it still > >>sounds like GNOME brokeness. What kind of icon caching concept is > >>this? If the cache file gets out-of-date and an icon is not found within > >>the cache, the desktop system doesn't search the file system? Huh? Or > >>maybe this is configurable in some place? Why should a KDE application > >>maintain a GTK icon theme cache file? > > > > > > They don't have to. It would be enough if they actually followed the > > icon theme spec they claim to be using, and touched the toplevel theme > > directory when installing a new icon. > > The toplevel theme directory being /usr/share/icons or > /usr/share/icons/__theme__? > > -- Rex > The one containing the index.theme file, ie /usr/share/icons/ From brads at redhat.com Tue Oct 11 20:30:14 2005 From: brads at redhat.com (Brad Smith) Date: Tue, 11 Oct 2005 16:30:14 -0400 Subject: Developers Needed!! : Fedora Tracker Message-ID: <1129062615.4693.111.camel@satsuki.geekdome.lan> Hello all, Once upon a time, around the time FC2 came out, I released a web tool called Fedora Tracker (http://www.fedoratracker.org), which indexes the various apt and yum repositories out there into a single searchable database. It enjoyed some popularity and I was happy to contribute to the usability of Fedora. However, some of you may have noticed that Fedora Tracker indexes far, far fewer repositories for FC4 than it did for previous versions. This is because, having been under the impression that most yum repos wouldn't adopt the new xml metadata format until FC5, I didn't include support for it in the most recent update. Obviously this proved to be a mistake and as a result Fedora Tracker has become significantly less useful. I've been waiting ever since that last update (around the time FC4 came out) for my work load to relax enough to give me time for another one. Alas, this doesn't seem to be happening. My responsibilities here at Red Hat are different than they were when I started Fedora Tracker and I just can't devote the same amount of time to it that I used to. In previous emails I have casually invited people from the community to peruse the code and offer updates if they so desired, but now Fedora Tracker really needs outside help. It's been sitting there, more or less useless, for months now and I want to see it back up to snuff. So, if you are a python developer with some time to contribute to a worthy project, here are the details: Code is at http://sourceforge.net/cvs/?group_id=105932 - trackerClass.py contains most of the front-end code - tpClass.py contains most of the back-end code - repo.py contains most of the package-handling code Major tasks that are currently TODO Top Priority: --------------------------------------------------- - Add support for yum xml repos The ideal way to do this would be to alter the yumRepo class definition in repo.py (in particular the retrieve() and update() methods) to check for and handle xml metadata before looking for traditional header.*info files. The object would be to pull down the relevant xml files and use them to build repo.rpmInfo objects, which are used as a generic representation of package metadata within Tracker. Lower priority --------------------------------------------------- - Switch to a templating engine for html I will be the first to admit that the way the frontend html is managed is horrendous. We need to move to some sort of templating engine. I've never used one before, so if you have a favorite and are willing to devote the time, please write me with a proposal. - Performance enhancements Searches still run a lot slower than I would like. Optimizing database queries is not something I have much experience with. I've figured out a trick here and trick there, but I'm sure there is more that can be done. Effort here will be hindered by the fact that I'm currently the only one with direct access to the database (see next item) - Move to more flexible hosting My current webhost is great, but they seem to be designed around the assumption that only one person manages each site that they host. As such, a lot of the above tasks will be more difficult since I'm the only one who will have actual shell access to the system. I'm currently working with them to try and find an alternative, but if that fails I'd be interested in hearing from anyone who thinks they could offer web/python/mysql access to a larger group of developers. If anyone has the time and expertise to offer on one or more of these tasks, please drop me an email, take a look at the code and feel free to ask me any questions (I can arrange to meet on irc as well). If this email actually generates some interest, then we can look into setting up a mailing list, wiki or similar. I've never actually maintained a project with multiple developers before, so general advice about how I might approach this better would also be great. Thanks, --Brad -------------- 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 cloos+redhat-fedora-devel at jhcloos.com Tue Oct 11 21:47:19 2005 From: cloos+redhat-fedora-devel at jhcloos.com (James Cloos) Date: Tue, 11 Oct 2005 17:47:19 -0400 Subject: OpenType .otf fonts and printing In-Reply-To: <1129024994.28326.23.camel@locolhost.localdomain> (Michael A. Peters's message of "Tue, 11 Oct 2005 03:03:14 -0700") References: <1128943927.17311.11.camel@locolhost.localdomain> <1129024994.28326.23.camel@locolhost.localdomain> Message-ID: >>>>> "Michael" == Michael A Peters writes: Michael> lcdf-typetools is now in Fedora Extras and in fact is what I Michael> have been using to use otf fonts in LaTeX quite Michael> succesfully. I have used it to make Type1 fonts for system Michael> use - though I ran into some oddities with some fonts - such Michael> as Helvetica having some numbers (1 and 2) superscript when Michael> they shouldn't be. Adobe's Std series of otf fonts should have glyphs named /one.superior, /two.superior and /three.superior in additon to the /one, /two and /three glyphs since those superiors exist in the latin1 and adobestandard encoding vectors. Why anything should be using the superior when the lining are requested is a good question. W/o the fonts I cannot make a guess. What version of the typetools is in extras? 2.35 is current. -JimC -- James H. Cloos, Jr. From bernie at develer.com Wed Oct 12 00:06:15 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Wed, 12 Oct 2005 02:06:15 +0200 Subject: Deprecating pam_stack.so In-Reply-To: <1128690065.3156.29.camel@perun.redhat.usu> References: <1128690065.3156.29.camel@perun.redhat.usu> Message-ID: <434C5377.7080501@develer.com> Tomas Mraz wrote: > Linux-PAM 0.78 and later contains include directive which obsoletes > using the pam_stack module. This module is rather a hack as it requires > access to pam library internals for its operation and will never be > accepted to upstream. Thank you. Simplifying PAM configuration was badly needed. I have a few wishlist entries to submit, if you have time to consider them: - For some reason, pam_ldap interacts strangely with pam_unix. Even tough pam_unix comes before it and is "sufficient", nobody can login when the network is down or slapd is down. Also, you can login as root with root's password from ldap even tough there's a valid root entry in /etc/passwd. - Many pam.d files still use the absolute path "/lib/security/$ISA/" that doesn't seem to be useful anymore and looks weird on bi-arch systems such as x86_64. - Something similar of pam_ssh would be much cleaner than the current hack of running ssh-agent in GDM's session. gpg-agent support would also be welcome. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From lamont at gurulabs.com Wed Oct 12 00:39:47 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 11 Oct 2005 18:39:47 -0600 Subject: Deprecating pam_stack.so In-Reply-To: <434C5377.7080501@develer.com> References: <1128690065.3156.29.camel@perun.redhat.usu> <434C5377.7080501@develer.com> Message-ID: <200510111839.52118.lamont@gurulabs.com> On Tuesday 11 October 2005 06:06pm, Bernardo Innocenti wrote: > Tomas Mraz wrote: > > Linux-PAM 0.78 and later contains include directive which obsoletes > > using the pam_stack module. This module is rather a hack as it requires > > access to pam library internals for its operation and will never be > > accepted to upstream. > > Thank you. Simplifying PAM configuration was badly needed. > > I have a few wishlist entries to submit, if you have time to > consider them: > > - For some reason, pam_ldap interacts strangely with pam_unix. > Even tough pam_unix comes before it and is "sufficient", Not sure how to explain that. > nobody can login when the network is down or slapd is down. That is normal...unless you have configured your systems to cache authentication credentials locally so that they can authenticate disconnected. > Also, you can login as root with root's password from ldap > even tough there's a valid root entry in /etc/passwd. Yup. That's normal, because, when the pam_unix.so check for root fails, the "sufficient" line will not affect the overall outcome of the authentication attempt, then PAM moves on to the next line and succeeds with the sufficient pam_ldap.so line. This is part of the reason why having root credentials in your central authentication store is a BIG NO-NO. You should *only* have root credentials locally on each machine. [SNIP] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Wed Oct 12 01:35:38 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 11 Oct 2005 19:35:38 -0600 Subject: Deprecating pam_stack.so In-Reply-To: <200510111839.52118.lamont@gurulabs.com> References: <1128690065.3156.29.camel@perun.redhat.usu> <434C5377.7080501@develer.com> <200510111839.52118.lamont@gurulabs.com> Message-ID: <80d7e4090510111835n49d51af1h5dd099b8c13d591f@mail.gmail.com> On 10/11/05, Lamont R. Peterson wrote: > On Tuesday 11 October 2005 06:06pm, Bernardo Innocenti wrote: > > Tomas Mraz wrote: > > > Linux-PAM 0.78 and later contains include directive which obsoletes > > > using the pam_stack module. This module is rather a hack as it requires > > > access to pam library internals for its operation and will never be > > > accepted to upstream. > > > > Thank you. Simplifying PAM configuration was badly needed. > > > > I have a few wishlist entries to submit, if you have time to > > consider them: > > > > - For some reason, pam_ldap interacts strangely with pam_unix. > > Even tough pam_unix comes before it and is "sufficient", > > Not sure how to explain that. > > > nobody can login when the network is down or slapd is down. > > That is normal...unless you have configured your systems to cache > authentication credentials locally so that they can authenticate > disconnected. > I think the problem comes with outside expectations. The idea would be that if the pam_unix comes back with a correct passwd as "sufficient" etc it then you shouldn't need pam_krb/pam_ldap. The problem is that the pam model seems to try to check the ones below even when not needed (possibly because something lower in the stack could invalidate it?) So when the network is down, it acts like a show-stopper (either through a network timeout longer than the login timeout) or coming back as a failure and pam counting it. Putting in timeout modes and such didnt seem to help me when I tried this back in RHL 7.3 days.. It has been a problem with our laptop users because it effectively requires them to re-run authconfig whenever they go off the wire. -- Stephen J Smoogen. CSIRT/Linux System Administrator From mpeters at mac.com Wed Oct 12 02:06:13 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 11 Oct 2005 19:06:13 -0700 Subject: OpenType .otf fonts and printing In-Reply-To: References: <1128943927.17311.11.camel@locolhost.localdomain> <1129024994.28326.23.camel@locolhost.localdomain> Message-ID: <1129082774.3782.35.camel@locolhost.localdomain> On Tue, 2005-10-11 at 17:47 -0400, James Cloos wrote: > > What version of the typetools is in extras? 2.35 is current. 2.34 but 2.35 should be there real soon ;) From rdieter at math.unl.edu Wed Oct 12 02:20:53 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 11 Oct 2005 21:20:53 -0500 Subject: [Bug 170291] New: GNOME cannot find kile icon In-Reply-To: <1129036593.4177.2.camel@golem.boston.redhat.com> References: <20051010201440.5af97674.fedora@wir-sind-cool.org> <1128999845.2435.0.camel@c-24-218-204-47.hsd1.ma.comcast.net> <434BACCA.7060207@math.unl.edu> <1129036593.4177.2.camel@golem.boston.redhat.com> Message-ID: <434C7305.3080708@math.unl.edu> Matthias Clasen wrote: > On Tue, 2005-10-11 at 07:15 -0500, Rex Dieter wrote: >>>They don't have to. It would be enough if they actually followed the >>>icon theme spec they claim to be using, and touched the toplevel theme >>>directory when installing a new icon. >>The toplevel theme directory being /usr/share/icons or >>/usr/share/icons/__theme__? > The one containing the index.theme file, ie /usr/share/icons/ Thanks. -- Rex From shiva at sewingwitch.com Wed Oct 12 05:09:59 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 11 Oct 2005 22:09:59 -0700 Subject: Deprecating pam_stack.so In-Reply-To: <434C5377.7080501@develer.com> References: <1128690065.3156.29.camel@perun.redhat.usu> <434C5377.7080501@develer.com> Message-ID: <562EC9AF0003F6351E9329A7@[10.169.6.233]> --On Wednesday, October 12, 2005 2:06 AM +0200 Bernardo Innocenti wrote: > - For some reason, pam_ldap interacts strangely with pam_unix. > Even tough pam_unix comes before it and is "sufficient", > nobody can login when the network is down or slapd is down. > Also, you can login as root with root's password from ldap > even tough there's a valid root entry in /etc/passwd. I thought I had a misconfiguration when I was seeing this. I'd also like to get pam_smbpass into system_config_authentication, and just filed an RFE Bugzilla for it. Rather than customize SCA for each new PAM module, perhaps it should have some separate config where one can list the available modules. I just found a module from Microsoft for sending password changes to Win32 systems. (With source!) I wrapped it in an RPM and will be testing it shortly. From tmraz at redhat.com Wed Oct 12 09:05:55 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 12 Oct 2005 11:05:55 +0200 Subject: Deprecating pam_stack.so In-Reply-To: <434C5377.7080501@develer.com> References: <1128690065.3156.29.camel@perun.redhat.usu> <434C5377.7080501@develer.com> Message-ID: <1129107955.3158.6.camel@perun.redhat.usu> On Wed, 2005-10-12 at 02:06 +0200, Bernardo Innocenti wrote: > Tomas Mraz wrote: > > > Linux-PAM 0.78 and later contains include directive which obsoletes > > using the pam_stack module. This module is rather a hack as it requires > > access to pam library internals for its operation and will never be > > accepted to upstream. > > Thank you. Simplifying PAM configuration was badly needed. > > I have a few wishlist entries to submit, if you have time to > consider them: > > - For some reason, pam_ldap interacts strangely with pam_unix. > Even tough pam_unix comes before it and is "sufficient", > nobody can login when the network is down or slapd is down. The pam_ldap module will reject login in the account phase. You can use pam_localuser (supported by authconfig) to make pam_unix authorization of local users sufficient. > Also, you can login as root with root's password from ldap > even tough there's a valid root entry in /etc/passwd. That's expected as both pam_ldap and pam_unix are sufficient entries. If you want to prevent that you can insert pam_succeed_if > - Many pam.d files still use the absolute path "/lib/security/$ISA/" > that doesn't seem to be useful anymore and looks weird on > bi-arch systems such as x86_64. They will be converted during the change to use include instead of pam_stack. > - Something similar of pam_ssh would be much cleaner than the > current hack of running ssh-agent in GDM's session. gpg-agent > support would also be welcome. This is a problem as the passphrases for ssh keys can be different from the user's system password. So the pam_ssh is definitely not a replacement for ssh-agent. -- Tomas Mraz From tmraz at redhat.com Wed Oct 12 09:10:56 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 12 Oct 2005 11:10:56 +0200 Subject: Deprecating pam_stack.so In-Reply-To: <1129107955.3158.6.camel@perun.redhat.usu> References: <1128690065.3156.29.camel@perun.redhat.usu> <434C5377.7080501@develer.com> <1129107955.3158.6.camel@perun.redhat.usu> Message-ID: <1129108256.3158.10.camel@perun.redhat.usu> On Wed, 2005-10-12 at 11:05 +0200, Tomas Mraz wrote: > On Wed, 2005-10-12 at 02:06 +0200, Bernardo Innocenti wrote: > > Also, you can login as root with root's password from ldap > > even tough there's a valid root entry in /etc/passwd. > That's expected as both pam_ldap and pam_unix are sufficient entries. > If you want to prevent that you can insert pam_succeed_if I've forgot to finish this. You can insert pam_succeed_if in between pam_unix and pam_ldap. auth sufficient pam_unix.so ..... auth required pam_succeed_if.so uid != 0 quiet auth sufficient pam_ldap.so ..... This way only the local unix password will work for root. -- Tomas Mraz From pertusus at free.fr Wed Oct 12 10:17:17 2005 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 12 Oct 2005 12:17:17 +0200 Subject: Deprecating pam_stack.so In-Reply-To: <1129107955.3158.6.camel@perun.redhat.usu> References: <1128690065.3156.29.camel@perun.redhat.usu> <434C5377.7080501@develer.com> <1129107955.3158.6.camel@perun.redhat.usu> Message-ID: <20051012101717.GB13435@free.fr> > This is a problem as the passphrases for ssh keys can be different from > the user's system password. So the pam_ssh is definitely not a > replacement for ssh-agent. This is not an issue for pam_ssh, as pam_ssh may ask for the passphrase. There is a difference, though. Indeed with pam_ssh the passphrase is always asked for, with ssh-agent the passphrase is only asked for if the user launch ssh-add. With the following /etc/pam.d/gdm I login using a password checked by service=system-auth, then give the passphrase to pam_ssh in the auth phase, and the login succeed even if I give a bad passphrase. If the passphrase was right, the agent is launched in the session phase: #%PAM-1.0 auth required pam_env.so auth required pam_stack.so service=system-auth auth required pam_nologin.so auth optional pam_ssh.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth session optional pam_console.so session optional pam_ssh.so Of course there are other usages of pam_ssh, for example it may be required in the auth phase. -- Pat From buildsys at redhat.com Wed Oct 12 11:17:40 2005 From: buildsys at redhat.com (Build System) Date: Wed, 12 Oct 2005 07:17:40 -0400 Subject: rawhide report: 20051012 changes Message-ID: <200510121117.j9CBHeeK026950@porkchop.devel.redhat.com> Updated Packages: OpenIPMI-1.4.14-10 ------------------ * Tue Oct 11 2005 Phil Knirsch 1.4.14-10 - Updated initscript to fix missing redhat-lsb bug (#169901) boost-1.33.0-4 -------------- * Tue Oct 11 2005 Nils Philippsen 1.33.0-4 - build require bzip2-devel and zlib-devel bug-buddy-1:2.12.1-2 -------------------- * Tue Oct 11 2005 Nils Philippsen - 2.12.1-2 - add missing build requirements libbonobo-devel, glib2-devel, libgnome-devel, gnome-menus-devel, libglade2-devel cairo-1.0.2-2 ------------- * Tue Oct 11 2005 Kristian H??gsberg 1.0.2-2 - Rebuild against freetype-2.10 to pick up FT_GlyphSlot_Embolden. cups-1:1.1.23-22 ---------------- * Tue Oct 11 2005 Tim Waugh 1:1.1.23-22 - Apply patch to fix STR #1301 (bug #169979). eclipse-1:3.1.1-1jpp_1fc ------------------------ * Tue Oct 11 2005 Andrew Overholt 3.1.1-1jpp_1fc - 3.1.1. - Patch around gij failing for the doc plug-in generation. - Make /usr/bin/ecj a script (allows all jvms to call it). findutils-1:4.2.25-3 -------------------- * Tue Oct 11 2005 Dan Walsh 1:4.2.25-3 - Fix selinux patch firstboot-1.3.50-1 ------------------ * Tue Oct 11 2005 Chris Lumens 1.3.50-1 - Decrease blank space on finished screen (#144496). - Fix import of rhpxl.videocard. glade2-2.12.1-1 --------------- * Wed Oct 12 2005 Matthias Clasen - 2.12.1-1 - Update to 2.12.1 gnome-volume-manager-1.5.3-1 ---------------------------- * Wed Oct 12 2005 Matthias Clasen - 1.5.3-1 - update to 1.5.3 gnopernicus-0.12.0-1 -------------------- * Wed Oct 12 2005 Matthias Clasen 0.12.0-1 - Update to 0.12.0 icu-3.4-5 --------- * Tue Oct 11 2005 Caolan McNamara - 3.4-5 - clear execstack requirement for libicudata kde-i18n-1:3.4.91-1 ------------------- * Mon Oct 10 2005 Than Ngo 1:3.4.91-1 - update to 3.5 beta 1 kdeutils-6:3.4.91-2 ------------------- * Tue Oct 11 2005 Karsten Hopp 3.4.91-2 - add libacl-devel buildrequirement kernel-2.6.13-1.1601_FC5 ------------------------ * Tue Oct 11 2005 Dave Jones - 2.6.14-rc4 librsvg2-2.12.7-1 ----------------- * Wed Oct 12 2005 Matthias Clasen - 2.12.7-1 - Newer upstream version pump-0.8.24-1 ------------- * Tue Oct 11 2005 Jeremy Katz - 0.8.24-1 - a few more warnings * Tue Oct 11 2005 Jeremy Katz - 0.8.23-1 - fix warnings (#111081) rhpl-0.176-1 ------------ * Tue Oct 11 2005 Chris Lumens 0.176-1 - Make deprecated module warnings more useful. - Move data files and ddcprobe to rhpxl. rhpxl-0.3-1 ----------- * Tue Oct 11 2005 Chris Lumens 0.3-1 - Moved data files and ddcprobe here from rhpl. selinux-policy-strict-1.27.1-15 ------------------------------- * Tue Oct 11 2005 Dan Walsh 1.27.1-15 - Allow ftpd to upload to homedirs selinux-policy-targeted-1.27.1-15 --------------------------------- * Tue Oct 11 2005 Dan Walsh 1.27.1-15 - Allow ftpd to upload to homedirs sudo-1.6.8p9-5 -------------- * Tue Oct 11 2005 Karel Zak 1.6.8p9-5 - enable interfaces in selinux patch - merge sudo-1.6.8p8-sesh-stopsig.patch to selinux patch sysstat-6.0.1-3 --------------- * Tue Oct 11 2005 Ivana Varekova 6.0.1-3 - add FAQ to documentation (bug 170158) vim-1:6.3.090-2 --------------- * Tue Oct 11 2005 Karsten Hopp 6.3.090-2 - don't try to run cscope if cscope binary doesn't exist (#170371) - another attempt to fix perl requirements (#145475) From Matt_Domsch at dell.com Wed Oct 12 14:13:19 2005 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 12 Oct 2005 09:13:19 -0500 Subject: OpenIPMI initscript, package dep on OpenIPMI-libs and net-snmp-libs Message-ID: <20051012141319.GA17896@lists.us.dell.com> Phil, Now that the OpenIPMI-1.4.x package includes the ipmi initscript and config file, this makes it easy to get the initscript installed, and I want to drop them out of my DKMSified ipmi driver package. However, the OpenIPMI-1.4.x package includes a couple applications, which in turn requires libraries from OpenIPMI-libs (430KB), and libnetsnmp.so.5, which then pulls in the net-snmp-libs package (1.9MB) to provide that. My OMSA team is pushing back, because now the thing they need, the initscript and config file (a few KB), is now pulling in a couple more MB of stuff that isn't strictly required for the initscript. Could we put the initscripts into their own tiny package, e.g. OpenIPMI-initscript? How would that work for upgrades, when going from a system with OpenIPMI-1.4.x to OpenIPMI-1.4.(x+1) plus OpenIPMI-initscript-1.4.(x+1)? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From bmillett at gmail.com Wed Oct 12 14:30:10 2005 From: bmillett at gmail.com (Brian Millett) Date: Wed, 12 Oct 2005 09:30:10 -0500 Subject: system-config-display errors Message-ID: <1129127411.3906.3.camel@localhost.localdomain> Hi, I'm running rawhide, updated as of 2005-10-12. when I try to run system-config-display I get the following: [bpm]$ system-config-display /usr/share/system-config-display/xconf.py:32: DeprecationWarning: rhpl.monitor is deprecated; import rhpxl.monitor instead. import rhpl.monitor Traceback (most recent call last): File "/usr/share/system-config-display/xconf.py", line 32, in ? import rhpl.monitor File "/usr/lib/python2.4/site-packages/rhpl/monitor.py", line 6, in ? from rhpxl.monitor import * File "/usr/lib/python2.4/site-packages/rhpxl/monitor.py", line 427, in ? read_modes("vesamodes") File "/usr/lib/python2.4/site-packages/rhpxl/monitor.py", line 404, in read_modes fd = open("/usr/share/rhpl/" + filename, 'r') IOError: [Errno 2] No such file or directory: '/usr/share/rhpl/vesamodes' Filed as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170508 -- Brian Millett - [ Harriman Gray and Col. Ari Ben Zayn, "Eyes"] "When do we begin?" 'As always, Mr. Gray, when the time is right...' From arjanv at redhat.com Wed Oct 12 14:36:26 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 12 Oct 2005 16:36:26 +0200 Subject: OpenIPMI initscript, package dep on OpenIPMI-libs and net-snmp-libs In-Reply-To: <20051012141319.GA17896@lists.us.dell.com> References: <20051012141319.GA17896@lists.us.dell.com> Message-ID: <1129127787.3082.48.camel@laptopd505.fenrus.org> > Could we put the initscripts into their own tiny package, e.g. OpenIPMI-initscript? that sounds really odd.... surely the initscript needs to go with the apps and libs. -------------- 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 tomo.vuckovic at nis.yu Wed Oct 12 15:06:14 2005 From: tomo.vuckovic at nis.yu (Tomo Vuckovic) Date: Wed, 12 Oct 2005 17:06:14 +0200 Subject: system-config-display errors In-Reply-To: <1129127411.3906.3.camel@localhost.localdomain> References: <1129127411.3906.3.camel@localhost.localdomain> Message-ID: <434D2666.70301@nis.yu> Brian Millett wrote: > Hi, I'm running rawhide, updated as of 2005-10-12. > > when I try to run system-config-display I get the following: > > [bpm]$ system-config-display > /usr/share/system-config-display/xconf.py:32: DeprecationWarning: > rhpl.monitor is deprecated; import rhpxl.monitor instead. > import rhpl.monitor > Traceback (most recent call last): > File "/usr/share/system-config-display/xconf.py", line 32, in ? > import rhpl.monitor > File "/usr/lib/python2.4/site-packages/rhpl/monitor.py", line 6, in ? > from rhpxl.monitor import * > File "/usr/lib/python2.4/site-packages/rhpxl/monitor.py", line 427, > in ? > read_modes("vesamodes") > File "/usr/lib/python2.4/site-packages/rhpxl/monitor.py", line 404, in > read_modes > fd = open("/usr/share/rhpl/" + filename, 'r') > IOError: [Errno 2] No such file or directory: > '/usr/share/rhpl/vesamodes' > > Filed as: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170508 > -- > Brian Millett - [ Harriman Gray and Col. Ari Ben Zayn, "Eyes"] > "When do we begin?" > 'As always, Mr. Gray, when the time is right...' > > > change line : fd = open("/usr/share/rhpl/" + filename, 'r') to : fd = open("/usr/share/rhpxl/" + filename, 'r') -------------- next part -------------- A non-text attachment was scrubbed... Name: tomo.vuckovic.vcf Type: text/x-vcard Size: 437 bytes Desc: not available URL: From katzj at redhat.com Wed Oct 12 15:20:49 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Oct 2005 11:20:49 -0400 Subject: OpenIPMI initscript, package dep on OpenIPMI-libs and net-snmp-libs In-Reply-To: <20051012141319.GA17896@lists.us.dell.com> References: <20051012141319.GA17896@lists.us.dell.com> Message-ID: <1129130449.28394.24.camel@bree.local.net> On Wed, 2005-10-12 at 09:13 -0500, Matt Domsch wrote: > Could we put the initscripts into their own tiny package, e.g. OpenIPMI-initscript? > How would that work for upgrades, when going from a system with > OpenIPMI-1.4.x to OpenIPMI-1.4.(x+1) plus > OpenIPMI-initscript-1.4.(x+1)? That's going to lead to pain on upgrades. And what does the initscript even do if you don't have the application available? Jeremy From clumens at redhat.com Wed Oct 12 15:23:54 2005 From: clumens at redhat.com (Chris Lumens) Date: Wed, 12 Oct 2005 11:23:54 -0400 (EDT) Subject: system-config-display errors In-Reply-To: <1129127411.3906.3.camel@localhost.localdomain> References: <1129127411.3906.3.camel@localhost.localdomain> Message-ID: > [bpm]$ system-config-display > /usr/share/system-config-display/xconf.py:32: DeprecationWarning: > rhpl.monitor is deprecated; import rhpxl.monitor instead. > import rhpl.monitor > Traceback (most recent call last): > File "/usr/share/system-config-display/xconf.py", line 32, in ? > import rhpl.monitor > File "/usr/lib/python2.4/site-packages/rhpl/monitor.py", line 6, in ? > from rhpxl.monitor import * > File "/usr/lib/python2.4/site-packages/rhpxl/monitor.py", line 427, > in ? > read_modes("vesamodes") > File "/usr/lib/python2.4/site-packages/rhpxl/monitor.py", line 404, in > read_modes > fd = open("/usr/share/rhpl/" + filename, 'r') > IOError: [Errno 2] No such file or directory: > '/usr/share/rhpl/vesamodes' Argh, okay. I think I've killed all incorrect references to rhpl in rhpxl at this point. I'll test this out and commit it. - Chris From Matt_Domsch at dell.com Wed Oct 12 15:46:42 2005 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 12 Oct 2005 10:46:42 -0500 Subject: OpenIPMI initscript, package dep on OpenIPMI-libs and net-snmp-libs In-Reply-To: <1129130449.28394.24.camel@bree.local.net> References: <20051012141319.GA17896@lists.us.dell.com> <1129130449.28394.24.camel@bree.local.net> Message-ID: <20051012154642.GA20950@lists.us.dell.com> On Wed, Oct 12, 2005 at 11:20:49AM -0400, Jeremy Katz wrote: > On Wed, 2005-10-12 at 09:13 -0500, Matt Domsch wrote: > > Could we put the initscripts into their own tiny package, e.g. OpenIPMI-initscript? > > How would that work for upgrades, when going from a system with > > OpenIPMI-1.4.x to OpenIPMI-1.4.(x+1) plus > > OpenIPMI-initscript-1.4.(x+1)? > > That's going to lead to pain on upgrades. That's why I'm asking. > And what does the initscript even do if you don't have the > application available? The initscript loads kernel drivers, based on the hardware you've got and the driver features you want. The hardware isn't PCI or USB-based, so there's no hot plug mechanisms invoked to autoload them. The OpenIPMI tools and libraries open /dev/ipmi0 and issue ioctls. Other tools not packaged with OpenIPMI (read: OMSA) can do the same thing. The initscript loads several things: 1) low-level hardware drivers (ipmi_si, or ipmi_smb) 2) optional: the device interface module (ipmi_devintf which creates /dev/ipmi0) 3) optional: ipmi_watchdog hardware watchdog module 4) optional: ipmi_powercycle reboot notifier, which triggers the BMC to powercycle or power off the system as requested. ipmi_watchdog and ipmi_powercycle can be loaded, and provide useful features, in the absense of other userspace libraries and apps. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From ang3l0 at katamail.com Wed Oct 12 16:43:27 2005 From: ang3l0 at katamail.com (Angelo) Date: Wed, 12 Oct 2005 18:43:27 +0200 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels Message-ID: <434D3D2F.4000507@katamail.com> Quoting myself from an year ago: (19 October 2004) -------------------------------------------------------- Hi all, Linux TCP/IP protocol stack is well built but it lacks a bit in performance. To give you an idea, my box has a 10MBit connection to the internet, and if I try to transfer a file to a little lagged but high bandwidth host (50ms / 100MBit) this lack of optimization will begin showing. Even if my link will permit to transfer from this host at about 900-1000KB/s I will get only 600-650KB/s. Even using windows tuned to broadband connection I will get 900KB/s. This seems to be related to the tcp window scaling, and even if i try to tune the kernel related parameters (receive/send buffer) logging the traffic the tcp window seems to be left too small for this transfers. Web100 (www.web100.org) is a project that has solved this issue creating a patch that will tune every tcp/ip connection to get the best performance. I hope this patch will be inserted in the fedora stock kernels. Regards, Angelo ----------------------------------------------------- In a year not a single reply.. i'm still hoping to get this in Any idea, comment, reason to disagree, something ? Regards, Angelo From sundaram at redhat.com Wed Oct 12 16:49:10 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 12 Oct 2005 22:19:10 +0530 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434D3D2F.4000507@katamail.com> References: <434D3D2F.4000507@katamail.com> Message-ID: <434D3E86.3010307@redhat.com> Hi > > Web100 (www.web100.org) is a project that has solved this issue creating > a patch that will tune every tcp/ip connection to get the best > performance. > > I hope this patch will be inserted in the fedora stock kernels. Have you tried submitting the patch to the upstream kernel?. regards Rahul From j.w.r.degoede at hhs.nl Wed Oct 12 17:31:06 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 12 Oct 2005 19:31:06 +0200 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434D3E86.3010307@redhat.com> References: <434D3D2F.4000507@katamail.com> <434D3E86.3010307@redhat.com> Message-ID: <434D485A.5030202@hhs.nl> To quote from the web100 page: The Web100 project was created to address these problems. The first is addressed with automatic TCP buffer tuning. The Web100 work in this area has been merged with main-line Linux kernel, and is contained in recent releases. So, it is merged already, next time check first, complain later. Regards, Hans Rahul Sundaram wrote: > Hi > >> >> Web100 (www.web100.org) is a project that has solved this issue creating >> a patch that will tune every tcp/ip connection to get the best >> performance. >> >> I hope this patch will be inserted in the fedora stock kernels. > > > Have you tried submitting the patch to the upstream kernel?. > > regards > Rahul > From jam at zoidtechnologies.com Wed Oct 12 17:49:15 2005 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Wed, 12 Oct 2005 13:49:15 -0400 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434D485A.5030202@hhs.nl> References: <434D3D2F.4000507@katamail.com> <434D3E86.3010307@redhat.com> <434D485A.5030202@hhs.nl> Message-ID: <1129139355.3442.196.camel@eros.zoidtechnologies.com> On Wed, 2005-10-12 at 19:31 +0200, Hans de Goede wrote: > So, it is merged already, next time check first, complain later. > > Regards, > > Hans right, but is it turned on in rawhide, and will it be in production fc5? regards, J -- Jeff MacDonald Zoid Technologies GPG Fingerprint: 0831 879E B6B4 C4CC D3C9 419F B12D E3CE B927 04B2 -------------- 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 ang3l0 at katamail.com Wed Oct 12 16:08:06 2005 From: ang3l0 at katamail.com (Angelo) Date: Wed, 12 Oct 2005 18:08:06 +0200 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels Message-ID: <434D34E6.8020105@katamail.com> Quoting myself from an year ago: (19 October 2004) -------------------------------------------------------- Hi all, Linux TCP/IP protocol stack is well built but it lacks a bit in performance. To give you an idea, my box has a 10MBit connection to the internet, and if I try to transfer a file to a little lagged but high bandwidth host (50ms / 100MBit) this lack of optimization will begin showing. Even if my link will permit to transfer from this host at about 900-1000KB/s I will get only 600-650KB/s. Even using windows tuned to broadband connection I will get 900KB/s. This seems to be related to the tcp window scaling, and even if i try to tune the kernel related parameters (receive/send buffer) logging the traffic the tcp window seems to be left too small for this transfers. Web100 (www.web100.org) is a project that has solved this issue creating a patch that will tune every tcp/ip connection to get the best performance. I hope this patch will be inserted in the fedora stock kernels. Regards, Angelo ----------------------------------------------------- In a year not a single reply.. i'm still hoping to get this in Any idea, comment, reason to disagree, something ? Regards, Angelo From alan at redhat.com Wed Oct 12 18:54:10 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 12 Oct 2005 14:54:10 -0400 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434D34E6.8020105@katamail.com> References: <434D34E6.8020105@katamail.com> Message-ID: <20051012185410.GA27139@devserv.devel.redhat.com> On Wed, Oct 12, 2005 at 06:08:06PM +0200, Angelo wrote: > In a year not a single reply.. i'm still hoping to get this in > Any idea, comment, reason to disagree, something ? Try netdev at oss.sgi.com. Fedora tracks the base kernel. From lmacken at redhat.com Wed Oct 12 19:13:55 2005 From: lmacken at redhat.com (Luke Macken) Date: Wed, 12 Oct 2005 15:13:55 -0400 Subject: Developers Needed!! : Fedora Tracker In-Reply-To: <1129062615.4693.111.camel@satsuki.geekdome.lan> References: <1129062615.4693.111.camel@satsuki.geekdome.lan> Message-ID: <1129144435.2164.5.camel@localhost> On Tue, 2005-10-11 at 16:30 -0400, Brad Smith wrote: > Lower priority > --------------------------------------------------- > - Switch to a templating engine for html > I will be the first to admit that the way the frontend html > is managed is horrendous. We need to move to some sort of > templating engine. I've never used one before, so if you have > a favorite and are willing to devote the time, please write > me with a proposal. Whoever ends up working on this, I recommend checking out the python-myghty[0] templating framework. luke [0]: http://www.myghty.org/ From skvidal at phy.duke.edu Wed Oct 12 19:14:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 12 Oct 2005 15:14:49 -0400 Subject: Developers Needed!! : Fedora Tracker In-Reply-To: <1129144435.2164.5.camel@localhost> References: <1129062615.4693.111.camel@satsuki.geekdome.lan> <1129144435.2164.5.camel@localhost> Message-ID: <1129144489.20213.34.camel@cutter> On Wed, 2005-10-12 at 15:13 -0400, Luke Macken wrote: > On Tue, 2005-10-11 at 16:30 -0400, Brad Smith wrote: > > Lower priority > > --------------------------------------------------- > > - Switch to a templating engine for html > > I will be the first to admit that the way the frontend html > > is managed is horrendous. We need to move to some sort of > > templating engine. I've never used one before, so if you have > > a favorite and are willing to devote the time, please write > > me with a proposal. > > Whoever ends up working on this, I recommend checking out the > python-myghty[0] templating framework. > > luke > > [0]: http://www.myghty.org/ > or python-kid, which is in extras. -sv From patmans at us.ibm.com Wed Oct 12 20:12:35 2005 From: patmans at us.ibm.com (Patrick Mansfield) Date: Wed, 12 Oct 2005 13:12:35 -0700 Subject: trying to update or install rawhide on x86 system Message-ID: <20051012201235.GA24249@us.ibm.com> Hi - I've been trying to get rawhide working on an x86 box. rawhide installs have been failing (in different ways, the latest try hit the No such file or directory: '/usr/share/rhpl/vesamodes', sounds like that has been fixed already). So I installed FC4, and yum update-d to latest FC4. Now I'm trying to yum update to rawhide, but I am hitting conflict / dependency problems. Is there a way around these? I've been searching but haven't found an answer, I'm using internal mirrors of rawhide, and disabled all but the yum development repos. The yum update output, other data available on request: [ ... ] --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. --> Running transaction check Error: Unable to satisfy dependencies Error: Package initscripts needs kernel < 2.6.12, this is not available. Error: Package kudzu needs kernel < 2.6.13, this is not available. And the full output: Setting up Update Process Setting up repositories Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package pyxf86config.i386 0:0.3.19-6 set to be updated ---> Package SysVinit.i386 0:2.85-40 set to be updated ---> Package GConf2.i386 0:2.12.0-1 set to be updated ---> Package device-mapper.i386 0:1.01.05-1.0 set to be updated ---> Package gphoto2.i386 0:2.1.6-2 set to be updated ---> Package tcl.i386 0:8.4.11-1 set to be updated ---> Package xorg-x11-Mesa-libGL.i386 0:6.8.2-55 set to be updated ---> Package libgcrypt.i386 0:1.2.2-1 set to be updated ---> Package libgsf.i386 0:1.12.3-1 set to be updated ---> Package oprofile.i386 0:0.9.1-2 set to be updated ---> Package gnome-mag.i386 0:0.12.2-1 set to be updated ---> Package hal.i386 0:0.5.4-3 set to be updated ---> Package dbus.i386 0:0.50-1 set to be updated ---> Package krb5-libs.i386 0:1.4.2-4 set to be updated ---> Package gcc-gfortran.i386 0:4.0.2-3 set to be updated ---> Package man-pages.noarch 0:2.08-1 set to be updated ---> Package gnome-applets.i386 1:2.12.1-1 set to be updated ---> Package samba-client.i386 0:3.0.20-2 set to be updated ---> Package grub.i386 0:0.95-15 set to be updated ---> Package poppler.i386 0:0.4.2-1 set to be updated ---> Package rp-pppoe.i386 0:3.5-30 set to be updated ---> Package chkconfig.i386 0:1.3.20-2 set to be updated ---> Package festival.i386 0:1.95-4 set to be updated ---> Package e2fsprogs-devel.i386 0:1.38-1 set to be updated ---> Package openldap-devel.i386 0:2.2.29-2 set to be updated ---> Package nscd.i386 0:2.3.90-14 set to be updated ---> Package tmpwatch.i386 0:2.9.4-1 set to be updated ---> Package yum.noarch 0:2.4.0-6 set to be updated ---> Package patchutils.i386 0:0.2.31-2 set to be updated ---> Package gtksourceview.i386 0:1.4.2-1 set to be updated ---> Package system-config-securitylevel-tui.i386 0:1.6.4-3 set to be updated ---> Package samba-common.i386 0:3.0.20-2 set to be updated ---> Package finger.i386 0:0.17-29 set to be updated ---> Package nc.i386 0:1.82-1 set to be updated ---> Package kudzu.i386 0:1.2.9-1 set to be updated ---> Package rpm.i386 0:4.4.2-6 set to be updated ---> Package libstdc++-devel.i386 0:4.0.2-3 set to be updated ---> Package neon.i386 0:0.24.7-8 set to be updated ---> Package perl-DateManip.noarch 0:5.44-1 set to be updated ---> Package tcsh.i386 0:6.14-5 set to be updated ---> Package libtermcap-devel.i386 0:2.0.8-42 set to be updated ---> Package autofs.i386 1:4.1.4-9 set to be updated ---> Package hardlink.i386 1:1.0-1.14 set to be updated ---> Package rdist.i386 1:6.1.5-42 set to be updated ---> Package bluez-libs.i386 0:2.20-1 set to be updated ---> Package xorg-x11-Mesa-libGLU.i386 0:6.8.2-55 set to be updated ---> Package metacity.i386 0:2.12.1-1 set to be updated ---> Package gnome-media.i386 0:2.12.0-1 set to be updated ---> Package iputils.i386 0:20020927-29 set to be updated ---> Package mgetty.i386 0:1.1.33-3_FC5 set to be updated ---> Package openssl.i686 0:0.9.7f-9 set to be updated ---> Package system-config-date.noarch 0:1.7.99.2-1 set to be updated ---> Package minicom.i386 0:2.1-1 set to be updated ---> Package xorg-x11.i386 0:6.8.2-55 set to be updated ---> Package glib2.i386 0:2.8.3-1 set to be updated ---> Package system-config-printer.i386 0:0.6.143-1 set to be updated ---> Package atk.i386 0:1.10.3-1 set to be updated ---> Package qt.i386 1:3.3.5-3 set to be updated ---> Package eel2.i386 0:2.12.1-1 set to be updated ---> Package MAKEDEV.i386 0:3.19-4 set to be updated ---> Package libmng.i386 0:1.0.9-2 set to be updated ---> Package pyOpenSSL.i386 0:0.6-1.p24.6 set to be updated ---> Package libIDL.i386 0:0.8.6-1 set to be updated ---> Package cyrus-sasl-md5.i386 0:2.1.21-5 set to be updated ---> Package system-config-soundcard.noarch 0:1.2.12-5 set to be updated ---> Package ppp.i386 0:2.4.3-4 set to be updated ---> Package gnome-themes.noarch 0:2.12.1-1 set to be updated ---> Package libxslt.i386 0:1.1.15-1 set to be updated ---> Package freeglut.i386 0:2.4.0-1 set to be updated ---> Package fetchmail.i386 0:6.2.5.2-1 set to be updated ---> Package pam_krb5.i386 0:2.1.9-2 set to be updated ---> Package sysreport.noarch 0:1.4.2-2 set to be updated ---> Package gimp-print.i386 0:4.2.7-12 set to be updated ---> Package lsof.i386 0:4.76-1 set to be updated ---> Package perl.i386 3:5.8.7-0.5.fc5 set to be updated ---> Package giflib.i386 0:4.1.3-5 set to be updated ---> Package pam.i386 0:0.80-9 set to be updated ---> Package gnome-python2.i386 0:2.11.3-2 set to be updated ---> Package NetworkManager.i386 0:0.4.1-5.cvs20051010 set to be updated ---> Package libuser.i386 0:0.54.1-1 set to be updated ---> Package libtool.i386 0:1.5.20-4 set to be updated ---> Package psmisc.i386 0:21.7-1.cvs20051005 set to be updated ---> Package kernel.i686 0:2.6.13-1.1601_FC5 set to be installed ---> Package libselinux.i386 0:1.27.7-1 set to be updated ---> Package openldap.i386 0:2.2.29-2 set to be updated ---> Package bzip2.i386 0:1.0.3-1 set to be updated ---> Package system-config-keyboard.noarch 0:1.2.6-3 set to be updated ---> Package slrn.i386 0:0.9.8.1-5 set to be updated ---> Package openssl-devel.i386 0:0.9.7f-9 set to be updated ---> Package dump.i386 0:0.4b40-4 set to be updated ---> Package pyparted.i386 0:1.6.9-4 set to be updated ---> Package curl.i386 0:7.14.0-1 set to be updated ---> Package xterm.i386 0:200-9 set to be updated ---> Package glibc-common.i386 0:2.3.90-14 set to be updated ---> Package mkisofs.i386 8:2.01.1-10 set to be updated ---> Package gdb.i386 0:6.3.0.0-1.65 set to be updated ---> Package openssh.i386 0:4.2p1-2 set to be updated ---> Package xorg-x11-tools.i386 0:6.8.2-55 set to be updated ---> Package gnome-python2-extras.i386 0:2.11.4-9 set to be updated ---> Package syslinux.i386 0:3.10-2 set to be updated ---> Package ncurses-devel.i386 0:5.4-19 set to be updated ---> Package bluez-hcidump.i386 0:1.24-1 set to be updated ---> Package nano.i386 0:1.3.8-1 set to be updated ---> Package evince.i386 0:0.4.0-2 set to be updated ---> Package slocate.i386 0:2.7-28 set to be updated ---> Package util-linux.i386 0:2.13-0.4.pre4 set to be updated ---> Package bluez-utils.i386 0:2.20-1 set to be updated ---> Package xorg-x11-xauth.i386 0:6.8.2-55 set to be updated ---> Package docbook-dtds.noarch 0:1.0-27 set to be updated ---> Package gconf-editor.i386 0:2.12.0-1 set to be updated ---> Package vim-minimal.i386 1:6.3.090-2 set to be updated ---> Package gnome-doc-utils.noarch 0:0.4.2-1 set to be updated ---> Package hwbrowser.noarch 0:0.23-1 set to be updated ---> Package libglade2.i386 0:2.5.1-3 set to be updated ---> Package pcmciautils.i386 0:007-1 set to be updated ---> Package at-spi.i386 0:1.6.6-1 set to be updated ---> Package gcc-c++.i386 0:4.0.2-3 set to be updated ---> Package foomatic.i386 0:3.0.2-28 set to be updated ---> Package e2fsprogs.i386 0:1.38-1 set to be updated ---> Package gnome-icon-theme.noarch 0:2.12.1-1 set to be updated ---> Package binutils.i386 0:2.16.91.0.2-4 set to be updated ---> Package redhat-menus.noarch 0:5.0.1-1 set to be updated ---> Package libattr-devel.i386 0:2.4.23-1 set to be updated ---> Package libidn-devel.i386 0:0.5.19-1 set to be updated ---> Package db4-utils.i386 0:4.3.29-1 set to be updated ---> Package krbafs-devel.i386 0:1.2.2-9 set to be updated ---> Package redhat-rpm-config.noarch 0:8.0.39-1 set to be updated ---> Package python-devel.i386 0:2.4.1-14 set to be updated ---> Package tk.i386 0:8.4.11-1 set to be updated ---> Package rcs.i386 0:5.7-29 set to be updated ---> Package gnome-speech.i386 0:0.3.8-1 set to be updated ---> Package logwatch.noarch 0:6.1.2-7 set to be updated ---> Package emacs-leim.i386 0:21.4-7 set to be updated ---> Package gtk2-engines.i386 0:2.6.5-1 set to be updated ---> Package info.i386 0:4.8-6 set to be updated ---> Package udev.i386 0:069-10 set to be updated ---> Package emacs-common.i386 0:21.4-7 set to be updated ---> Package gnome-panel.i386 0:2.12.1-1 set to be updated ---> Package gedit.i386 1:2.12.1-1 set to be updated ---> Package vim-enhanced.i386 1:6.3.090-2 set to be updated ---> Package mtr.i386 2:0.69-6 set to be updated ---> Package gcc.i386 0:4.0.2-3 set to be updated ---> Package freetype.i386 0:2.1.10-1 set to be updated ---> Package eject.i386 0:2.1.2-1 set to be updated ---> Package ksh.i386 0:20050202-3 set to be updated ---> Package nss_db.i386 0:2.2-34 set to be updated ---> Package glibc.i686 0:2.3.90-14 set to be updated ---> Package pax.i386 0:3.4-1 set to be updated ---> Package wget.i386 0:1.10.1-7 set to be updated ---> Package gnupg.i386 0:1.4.2-3 set to be updated ---> Package perl-XML-NamespaceSupport.noarch 0:1.09-1 set to be updated ---> Package xorg-x11-font-utils.i386 0:6.8.2-55 set to be updated ---> Package grep.i386 0:2.5.1-51 set to be updated ---> Package libxml2-python.i386 0:2.6.22-1 set to be updated ---> Package cpio.i386 0:2.6-8 set to be updated ---> Package bash.i386 0:3.0-35 set to be updated ---> Package libbonoboui.i386 0:2.10.1-1 set to be updated ---> Package rpm-libs.i386 0:4.4.2-6 set to be updated ---> Package gamin.i386 0:0.1.6-3 set to be updated ---> Package krb5-devel.i386 0:1.4.2-4 set to be updated ---> Package kernel-smp-devel.i686 0:2.6.13-1.1601_FC5 set to be installed ---> Package rpm-build.i386 0:4.4.2-6 set to be updated ---> Package vim-common.i386 1:6.3.090-2 set to be updated ---> Package gnome-terminal.i386 0:2.12.0-1 set to be updated ---> Package patch.i386 0:2.5.4-29 set to be updated ---> Package elfutils.i386 0:0.115-1 set to be updated ---> Package libgnomecups.i386 0:0.2.2-1 set to be updated ---> Package zlib.i386 0:1.2.3-1 set to be updated ---> Package gok.i386 0:1.0.5-4 set to be updated ---> Package neon-devel.i386 0:0.24.7-8 set to be updated ---> Package pango.i386 0:1.10.1-1 set to be updated ---> Package selinux-policy-targeted.noarch 0:1.27.1-15 set to be updated ---> Package libpcap.i386 14:0.9.3-3 set to be updated ---> Package nss_ldap.i386 0:243-1 set to be updated ---> Package mkinitrd.i386 0:5.0.4-1 set to be updated ---> Package pkgconfig.i386 1:0.19-1 set to be updated ---> Package dbus-devel.i386 0:0.50-1 set to be updated ---> Package xinitrc.noarch 0:4.0.19-1 set to be updated ---> Package at.i386 0:3.1.8-79 set to be updated ---> Package aspell-en.i386 50:6.0-1 set to be updated ---> Package krbafs.i386 0:1.2.2-9 set to be updated ---> Package gnome-vfs2.i386 0:2.12.1.1-1 set to be updated ---> Package ghostscript.i386 0:8.15.1-1 set to be updated ---> Package system-config-printer-gui.i386 0:0.6.143-1 set to be updated ---> Package gthumb.i386 0:2.6.8-1 set to be updated ---> Package dbus-python.i386 0:0.50-1 set to be updated ---> Package file.i386 0:4.15-4 set to be updated ---> Package cups-libs.i386 1:1.1.23-22 set to be updated ---> Package libgnomeprintui22.i386 0:2.12.1-1 set to be updated ---> Package rmt.i386 0:0.4b40-4 set to be updated ---> Package pam-devel.i386 0:0.80-9 set to be updated ---> Package elinks.i386 0:0.10.6-1 set to be updated ---> Package quota.i386 1:3.12-7 set to be updated ---> Package strace.i386 0:4.5.13-1 set to be updated ---> Package sqlite.i386 0:3.2.7-2 set to be updated ---> Package iproute.i386 0:2.6.14-6 set to be updated ---> Package python-urlgrabber.noarch 0:2.9.6-4 set to be updated ---> Package switchdesk.noarch 0:4.0.7-1 set to be updated ---> Package bzip2-devel.i386 0:1.0.3-1 set to be updated ---> Package zlib-devel.i386 0:1.2.3-1 set to be updated ---> Package gstreamer.i386 0:0.8.11-2 set to be updated ---> Package cyrus-sasl.i386 0:2.1.21-5 set to be updated ---> Package libgcc.i386 0:4.0.2-3 set to be updated ---> Package pstack.i386 0:1.2-7 set to be updated ---> Package gnopernicus.i386 0:0.12.0-1 set to be updated ---> Package valgrind.i386 1:3.0.1-1 set to be updated ---> Package sendmail.i386 0:8.13.5-1 set to be updated ---> Package vixie-cron.i386 4:4.1-36.FC5 set to be updated ---> Package gnome-pilot.i386 0:2.0.13-7.fc5 set to be updated ---> Package make.i386 1:3.80-8 set to be updated ---> Package intltool.i386 0:0.34.1-1 set to be updated ---> Package libacl-devel.i386 0:2.2.31-1 set to be updated ---> Package xorg-x11-libs.i386 0:6.8.2-55 set to be updated ---> Package stunnel.i386 0:4.12-1 set to be updated ---> Package tzdata.noarch 0:2005m-2 set to be updated ---> Package libxml2.i386 0:2.6.22-1 set to be updated ---> Package db4-devel.i386 0:4.3.29-1 set to be updated ---> Package bzip2-libs.i386 0:1.0.3-1 set to be updated ---> Package gtk2.i386 0:2.8.6-1 set to be updated ---> Package gdm.i386 1:2.8.0.4-3 set to be updated ---> Package alsa-utils.i386 0:1.0.10rc1-1 set to be updated ---> Package cdrecord.i386 8:2.01.1-10 set to be updated ---> Package popt.i386 0:1.10.2-6 set to be updated ---> Package gettext.i386 0:0.14.5-2 set to be updated ---> Package kernel-smp.i686 0:2.6.13-1.1601_FC5 set to be installed ---> Package jwhois.i386 0:3.2.3-2 set to be updated ---> Package gnome-volume-manager.i386 0:1.5.3-1 set to be updated ---> Package libgnomecanvas.i386 0:2.12.0-1 set to be updated ---> Package gnome-python2-gtkhtml2.i386 0:2.11.4-9 set to be updated ---> Package lvm2.i386 0:2.01.14-2 set to be updated ---> Package initscripts.i386 0:8.17-1 set to be updated ---> Package ntsysv.i386 0:1.3.20-2 set to be updated ---> Package isdn4k-utils.i386 0:3.2-32 set to be updated ---> Package elfutils-libelf.i386 0:0.115-1 set to be updated ---> Package libgtop2.i386 0:2.12.0-1 set to be updated ---> Package fontconfig.i386 0:2.3.2-1 set to be updated ---> Package evolution-data-server.i386 0:1.4.0-2 set to be updated ---> Package NetworkManager-gnome.i386 0:0.4.1-5.cvs20051010 set to be updated ---> Package rpm-python.i386 0:4.4.2-6 set to be updated ---> Package nautilus.i386 0:2.12.1-1 set to be updated ---> Package less.i386 0:382-8 set to be updated ---> Package system-config-securitylevel.i386 0:1.6.4-3 set to be updated ---> Package bind.i386 24:9.3.1-18 set to be updated ---> Package man.i386 0:1.5p-6 set to be updated ---> Package glibc-headers.i386 0:2.3.90-14 set to be updated ---> Package passwd.i386 0:0.71-1 set to be updated ---> Package desktop-backgrounds-basic.noarch 0:2.0-30 set to be updated ---> Package ntp.i386 0:4.2.0.a.20050816-2 set to be updated ---> Package unzip.i386 0:5.51-12 set to be updated ---> Package hotplug.i386 3:2004_09_23-10 set to be updated ---> Package desktop-printing.i386 0:0.19-2 set to be updated ---> Package lftp.i386 0:3.3.0-1 set to be updated ---> Package pilot-link.i386 1:0.12.0-0.pre4.5 set to be updated ---> Package system-config-display.noarch 0:1.0.32-1 set to be updated ---> Package netdump.i386 0:0.7.14-1 set to be updated ---> Package gnome-vfs2-smb.i386 0:2.12.1.1-1 set to be updated ---> Package curl-devel.i386 0:7.14.0-1 set to be updated ---> Package dbus-glib.i386 0:0.50-1 set to be updated ---> Package pygtk2.i386 0:2.8.0-1 set to be updated ---> Package openssh-askpass.i386 0:4.2p1-2 set to be updated ---> Package boost.i386 0:1.33.0-4 set to be updated ---> Package prelink.i386 0:0.3.6-1 set to be updated ---> Package gnome-python2-gnomevfs.i386 0:2.11.3-2 set to be updated ---> Package vnc-server.i386 0:4.1.1-17 set to be updated ---> Package system-config-users.noarch 0:1.2.41-1 set to be updated ---> Package filesystem.i386 0:2.3.5-1 set to be updated ---> Package libgfortran.i386 0:4.0.2-3 set to be updated ---> Package cyrus-sasl-devel.i386 0:2.1.21-5 set to be updated ---> Package cracklib-dicts.i386 0:2.8.5-2 set to be updated ---> Package system-config-services.noarch 0:0.8.26-1 set to be updated ---> Package m4.i386 0:1.4.3-2 set to be updated ---> Package tcpdump.i386 14:3.9.3-3 set to be updated ---> Package policycoreutils.i386 0:1.27.5-3 set to be updated ---> Package sudo.i386 0:1.6.8p9-5 set to be updated ---> Package firstboot.noarch 0:1.3.50-1 set to be updated ---> Package libstdc++.i386 0:4.0.2-3 set to be updated ---> Package a2ps.i386 0:4.13b-47 set to be updated ---> Package gstreamer-plugins.i386 0:0.8.11-1 set to be updated ---> Package nspr.i386 0:4.6-4 set to be updated ---> Package openssh-askpass-gnome.i386 0:4.2p1-2 set to be updated ---> Package vino.i386 0:2.12.0-2 set to be updated ---> Package authconfig.i386 0:5.0.1-1 set to be updated ---> Package gnome-session.i386 0:2.12.0-1 set to be updated ---> Package ncurses.i386 0:5.4-19 set to be updated ---> Package gnome-desktop.i386 0:2.12.1-1 set to be updated ---> Package usermode-gtk.i386 0:1.81-1 set to be updated ---> Package libxml2-devel.i386 0:2.6.22-1 set to be updated ---> Package sqlite-devel.i386 0:3.2.7-2 set to be updated ---> Package gail.i386 0:1.8.5-1 set to be updated ---> Package newt.i386 0:0.52.1-0 set to be updated ---> Package audit.i386 0:1.0.6-1 set to be updated ---> Package module-init-tools.i386 0:3.2-0.pre7.3 set to be updated ---> Package pam_passwdqc.i386 0:1.0.2-1 set to be updated ---> Package iptables.i386 0:1.3.2-1 set to be updated ---> Package control-center.i386 1:2.12.1-1 set to be updated ---> Package openssh-clients.i386 0:4.2p1-2 set to be updated ---> Package gimp-print-utils.i386 0:4.2.7-12 set to be updated ---> Package net-tools.i386 0:1.60-56 set to be updated ---> Package rhnlib.noarch 0:1.8-6.p24.11 set to be updated ---> Package setools.i386 0:2.1.2-3 set to be updated ---> Package nautilus-cd-burner.i386 0:2.12.1-1 set to be updated ---> Package gnome-keyring.i386 0:0.4.5-1 set to be updated ---> Package aspell.i386 12:0.60.3-2 set to be updated ---> Package cyrus-sasl-plain.i386 0:2.1.21-5 set to be updated ---> Package dhclient.i386 11:3.0.3-7 set to be updated ---> Package shared-mime-info.i386 0:0.16-5 set to be updated ---> Package authconfig-gtk.i386 0:5.0.1-1 set to be updated ---> Package gnome-netstatus.i386 0:2.12.0-1 set to be updated ---> Package lockdev.i386 0:1.0.1-9 set to be updated ---> Package gnome-utils.i386 1:2.12.1-1 set to be updated ---> Package krb5-auth-dialog.i386 0:0.2-6 set to be updated ---> Package libattr.i386 0:2.4.23-1 set to be updated ---> Package lockdev-devel.i386 0:1.0.1-9 set to be updated ---> Package automake.noarch 0:1.9.6-1 set to be updated ---> Package libtermcap.i386 0:2.0.8-42 set to be updated ---> Package pm-utils.i386 0:0.05-1 set to be updated ---> Package glibc-kernheaders.i386 0:2.4-9.1.95 set to be updated ---> Package setuptool.i386 0:1.17.3-1 set to be updated ---> Package libgnomeprint22.i386 0:2.12.1-2 set to be updated ---> Package ctags.i386 0:5.5.4-4 set to be updated ---> Package parted.i386 0:1.6.24-1 set to be updated ---> Package pcre.i386 0:6.3-1 set to be updated ---> Package rhn-applet.i386 0:2.1.17-4 set to be updated ---> Package libuser-devel.i386 0:0.54.1-1 set to be updated ---> Package glib2-devel.i386 0:2.8.3-1 set to be updated ---> Package ORBit2.i386 0:2.12.4-2 set to be updated ---> Package file-roller.i386 0:2.12.1-1 set to be updated ---> Package libsepol.i386 0:1.9.14-1 set to be updated ---> Package libgnomeui.i386 0:2.12.0-2 set to be updated ---> Package libraw1394.i386 0:1.2.0-1.fc5 set to be updated ---> Package desktop-file-utils.i386 0:0.10-3 set to be updated ---> Package coreutils.i386 0:5.2.1-56 set to be updated ---> Package openssh-server.i386 0:4.2p1-2 set to be updated ---> Package bind-libs.i386 24:9.3.1-18 set to be updated ---> Package slang.i386 0:1.4.9-19 set to be updated ---> Package usermode.i386 0:1.81-1 set to be updated ---> Package gnome-python2-bonobo.i386 0:2.11.3-2 set to be updated ---> Package logrotate.i386 0:3.7.2-5 set to be updated ---> Package ftp.i386 0:0.17-29 set to be updated ---> Package gd.i386 0:2.0.33-4 set to be updated ---> Package hpijs.i386 1:0.9.5-3 set to be updated ---> Package arts.i386 8:1.4.91-1 set to be updated ---> Package gnome-system-monitor.i386 0:2.12.1-1 set to be updated ---> Package numactl.i386 0:0.6.4-1.23 set to be updated ---> Package ttmkfdir.i386 0:3.0.9-19 set to be updated ---> Package dbus-x11.i386 0:0.50-1 set to be updated ---> Package cups.i386 1:1.1.23-22 set to be updated ---> Package findutils.i386 1:4.2.25-3 set to be updated ---> Package texinfo.i386 0:4.8-6 set to be updated ---> Package perl-Compress-Zlib.i386 0:1.37-1.fc5 set to be updated ---> Package pygtk2-libglade.i386 0:2.8.0-1 set to be updated ---> Package cvs.i386 0:1.11.19-10 set to be updated ---> Package rsync.i386 0:2.6.6-2 set to be updated ---> Package attr.i386 0:2.4.23-1 set to be updated ---> Package librsvg2.i386 0:2.12.7-1 set to be updated ---> Package cpp.i386 0:4.0.2-3 set to be updated ---> Package newt-devel.i386 0:0.52.1-0 set to be updated ---> Package bind-utils.i386 24:9.3.1-18 set to be updated ---> Package gnome-keyring-manager.i386 0:2.12.0-1 set to be updated ---> Package wireless-tools.i386 1:28-0.pre9.5 set to be updated ---> Package emacs.i386 0:21.4-7 set to be updated ---> Package alsa-lib.i386 0:1.0.10rc1-2 set to be updated ---> Package glibc-devel.i386 0:2.3.90-14 set to be updated ---> Package db4.i386 0:4.3.29-1 set to be updated ---> Package xscreensaver-base.i386 1:4.22-18 set to be updated ---> Package fedora-logos.noarch 0:1.1.31-2 set to be updated ---> Package krb5-workstation.i386 0:1.4.2-4 set to be updated ---> Package xorg-x11-xfs.i386 0:6.8.2-55 set to be updated ---> Package gnutls.i386 0:1.2.6-1 set to be updated ---> Package nfs-utils.i386 0:1.0.7-18.FC5 set to be updated ---> Package gnome-python2-canvas.i386 0:2.11.3-2 set to be updated ---> Package boost-devel.i386 0:1.33.0-4 set to be updated ---> Package procps.i386 0:3.2.5-7 set to be updated ---> Package setup.noarch 0:2.5.47-1.1 set to be updated ---> Package libsoup.i386 0:2.2.6.1-1 set to be updated ---> Package perl-Crypt-SSLeay.i386 0:0.51-8 set to be updated ---> Package sysklogd.i386 0:1.4.1-33 set to be updated ---> Package python.i386 0:2.4.1-14 set to be updated ---> Package vte.i386 0:0.11.15-1.fc5 set to be updated ---> Package gawk.i386 0:3.1.5-4 set to be updated ---> Package libselinux-devel.i386 0:1.27.7-1 set to be updated ---> Package hdparm.i386 0:6.1-1 set to be updated ---> Package libidn.i386 0:0.5.19-1 set to be updated ---> Package checkpolicy.i386 0:1.27.7-2 set to be updated ---> Package gnome-menus.i386 0:2.12.0-1 set to be updated ---> Package cracklib.i386 0:2.8.5-2 set to be updated ---> Package system-config-lvm.noarch 0:1.0.7-1.0 set to be updated ---> Package audit-libs.i386 0:1.0.6-1 set to be updated ---> Package redhat-artwork.i386 0:0.128-2 set to be updated ---> Package esound.i386 1:0.2.36-1 set to be updated ---> Package slang-devel.i386 0:1.4.9-19 set to be updated ---> Package vsftpd.i386 0:2.0.3-11 set to be updated ---> Package mutt.i386 5:1.4.2.1-3 set to be updated ---> Package libwnck.i386 0:2.12.1-1 set to be updated ---> Package rhpl.i386 0:0.176-1 set to be updated ---> Package libgnome.i386 0:2.12.0.1-1 set to be updated ---> Package libacl.i386 0:2.2.31-1 set to be updated ---> Package libbonobo.i386 0:2.10.1-2 set to be updated ---> Package pam_ccreds.i386 0:1-7 set to be updated ---> Package libtiff.i386 0:3.7.4-1 set to be updated ---> Package traceroute.i386 0:1.4a12-27 set to be updated ---> Package acl.i386 0:2.2.31-1 set to be updated ---> Package diffstat.i386 0:1.38-4 set to be updated ---> Package fedora-release.noarch 0:4-99.rawhide set to be updated ---> Package doxygen.i386 1:1.4.4-2 set to be updated ---> Package yelp.i386 0:2.12.1-1 set to be updated ---> Package hwdata.noarch 0:0.169-1 set to be updated ---> Package rpm-devel.i386 0:4.4.2-6 set to be updated --> Running transaction check --> Processing Dependency: libcairo.so.2 for package: libbonoboui --> Processing Dependency: libcairo.so.2 for package: vte --> Processing Dependency: cyrus-sasl-lib = 2.1.21-5 for package: cyrus-sasl-md5 --> Processing Conflict: initscripts conflicts kernel < 2.6.12 --> Processing Dependency: libcairo.so.2 for package: gnome-python2-gtkhtml2 --> Processing Dependency: libsasl2.so.2 for package: cyrus-sasl-devel --> Processing Dependency: libcairo.so.2 for package: gnome-panel --> Processing Dependency: rhpxl for package: firstboot --> Processing Dependency: libcairo.so.2 for package: libglade2 --> Processing Dependency: cryptsetup-luks >= 1.0.1-2 for package: hal --> Processing Dependency: libcairo.so.2 for package: gnopernicus --> Processing Dependency: libsemanage.so.1(LIBSEMANAGE_1.0) for package: policycoreutils --> Processing Dependency: cyrus-sasl-lib = 2.1.21-5 for package: cyrus-sasl-plain --> Processing Dependency: libcairo.so.2 for package: gnome-system-monitor --> Processing Dependency: cyrus-sasl-lib = 2.1.21-5 for package: cyrus-sasl-devel --> Processing Dependency: libcairo.so.2 for package: xscreensaver-base --> Processing Dependency: elfutils-libs = 0.115-1 for package: elfutils --> Processing Dependency: libcairo.so.2 for package: nautilus-cd-burner --> Processing Dependency: libcairo.so.2 for package: nautilus --> Processing Dependency: libsasl2.so.2 for package: cyrus-sasl --> Processing Dependency: libsemanage for package: policycoreutils --> Processing Dependency: libcairo.so.2 for package: GConf2 --> Processing Dependency: libcairo.so.2 for package: gnome-python2 --> Processing Dependency: libcairo.so.2 for package: libwnck --> Processing Dependency: libcairo.so.2 for package: gnome-utils --> Processing Dependency: libcairo.so.2 for package: yelp --> Processing Dependency: libcairo.so.2 for package: gtk2 --> Processing Dependency: libcairo.so.2 for package: metacity --> Processing Dependency: libcairo.so.2 for package: desktop-printing --> Processing Dependency: libmysqlclient.so.14 for package: cyrus-sasl-devel --> Processing Dependency: elfutils-libelf-devel for package: rpm-devel --> Processing Dependency: libcairo.so.2 for package: NetworkManager-gnome --> Processing Dependency: libcairo.so.2 for package: gconf-editor --> Processing Dependency: libcairo.so.2 for package: vino --> Processing Dependency: libsemanage.so.1 for package: policycoreutils --> Processing Dependency: libcairo.so.2 for package: gnome-terminal --> Processing Dependency: libcairo.so.2 for package: evince --> Processing Dependency: libcairo.so.2 for package: pango --> Processing Dependency: libsasl2.so.2 for package: openldap --> Processing Dependency: libcairo.so.2 for package: gnome-python2-bonobo --> Processing Dependency: libcairo.so.2 for package: at-spi --> Processing Dependency: libsasl2.so.2 for package: python-ldap --> Processing Dependency: libcairo.so.2 for package: gnome-applets --> Processing Dependency: libcairo.so.2 for package: krb5-auth-dialog --> Processing Dependency: libcairo.so.2 for package: openssh-askpass-gnome --> Processing Dependency: libcairo.so.2 for package: libgnomecanvas --> Processing Dependency: libcairo.so.2 for package: librsvg2 --> Processing Dependency: cairo >= 0.9.2 for package: pango --> Processing Dependency: libpq.so.4 for package: cyrus-sasl --> Processing Dependency: libdw.so.1(ELFUTILS_0.115) for package: elfutils --> Processing Dependency: libcairo.so.2 for package: gnome-mag --> Processing Dependency: libdw.so.1 for package: elfutils --> Processing Dependency: libcairo.so.2 for package: gok --> Processing Dependency: libcairo.so.2 for package: file-roller --> Processing Dependency: libcairo.so.2 for package: gtk2-engines --> Processing Dependency: libcairo.so.2 for package: gnome-keyring-manager --> Processing Dependency: libcairo.so.2 for package: gstreamer-plugins --> Processing Dependency: libcairo.so.2 for package: gnome-media --> Processing Dependency: libcairo.so.2 for package: gedit --> Processing Dependency: libcairo.so.2 for package: usermode-gtk --> Processing Dependency: libpq.so.4 for package: cyrus-sasl-devel --> Processing Dependency: libsasl2.so.2 for package: sendmail --> Processing Dependency: libcairo.so.2 for package: gdm --> Processing Dependency: libmysqlclient.so.14 for package: cyrus-sasl --> Processing Dependency: cyrus-sasl-lib = 2.1.21-5 for package: cyrus-sasl --> Processing Dependency: libcairo.so.2 for package: pygtk2 --> Processing Conflict: kudzu conflicts kernel < 2.6.13 --> Processing Dependency: libcairo.so.2 for package: rhn-applet --> Processing Dependency: libcairo.so.2 for package: control-center --> Processing Dependency: dhcdbd for package: NetworkManager --> Processing Dependency: libcairo.so.2 for package: pygtk2-libglade --> Processing Dependency: libcairo.so.2 for package: gnome-python2-canvas --> Processing Dependency: libcairo.so.2 for package: libgnomeprintui22 --> Processing Dependency: libcairo.so.2 for package: gthumb --> Processing Dependency: libcairo.so.2 for package: eel2 --> Processing Dependency: libcairo.so.2 for package: gnome-pilot --> Processing Dependency: libcairo.so.2 for package: poppler --> Processing Dependency: libsetrans for package: libselinux --> Processing Dependency: libcairo.so.2 for package: evolution-data-server --> Processing Dependency: libcairo.so.2 for package: gail --> Processing Dependency: libcairo.so.2 for package: gnome-keyring --> Processing Dependency: libcairo.so.2 for package: gnome-volume-manager --> Processing Dependency: libcairo.so.2 for package: gnome-netstatus --> Processing Dependency: libcairo.so.2 for package: gtksourceview --> Processing Dependency: libcairo.so.2 for package: gnome-desktop --> Processing Dependency: libcairo.so.2 for package: libgnomeui --> Processing Dependency: libcairo.so.2 for package: gnome-session --> Processing Dependency: libsasl2.so.2 for package: mutt --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package cryptsetup-luks.i386 0:1.0.1-2 set to be updated ---> Package mysql.i386 0:4.1.14-1 set to be updated ---> Package dhcdbd.i386 0:1.9-1 set to be updated ---> Package postgresql-libs.i386 0:8.0.4-2 set to be updated ---> Package libsetrans.i386 0:0.1.7-1 set to be updated ---> Package cyrus-sasl-lib.i386 0:2.1.21-5 set to be updated ---> Package rhpxl.noarch 0:0.3-1 set to be updated ---> Package elfutils-libelf-devel.i386 0:0.115-1 set to be updated ---> Package libsemanage.i386 0:1.3.9-1 set to be updated ---> Package cairo.i386 0:1.0.2-2 set to be updated ---> Package elfutils-libs.i386 0:0.115-1 set to be updated --> Running transaction check --> Processing Conflict: initscripts conflicts kernel < 2.6.12 --> Processing Dependency: perl(DBI) for package: mysql --> Processing Conflict: kudzu conflicts kernel < 2.6.13 --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package perl-DBI.i386 0:1.48-4 set to be updated --> Running transaction check --> Processing Conflict: initscripts conflicts kernel < 2.6.12 --> Processing Conflict: kudzu conflicts kernel < 2.6.13 --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. --> Running transaction check --> Processing Conflict: initscripts conflicts kernel < 2.6.12 --> Processing Conflict: kudzu conflicts kernel < 2.6.13 --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. --> Running transaction check Error: Unable to satisfy dependencies Error: Package initscripts needs kernel < 2.6.12, this is not available. Error: Package kudzu needs kernel < 2.6.13, this is not available. Thanks ... -- Patrick Mansfield From likwidv at rochester.rr.com Wed Oct 12 20:30:31 2005 From: likwidv at rochester.rr.com (Sean Plantz) Date: Wed, 12 Oct 2005 16:30:31 -0400 Subject: trying to update or install rawhide on x86 system In-Reply-To: <20051012201235.GA24249@us.ibm.com> References: <20051012201235.GA24249@us.ibm.com> Message-ID: <1129149031.7745.2.camel@nighthawk.neonetwork> I had the same issue, and removing the older kernels worked (all pre 2.6.13 kernels) easiest way to do it is rpm -e kernel-2.6.12* and append to what versions you still have.. hope that helps. On Wed, 2005-10-12 at 13:12 -0700, Patrick Mansfield wrote: > Hi - > > I've been trying to get rawhide working on an x86 box. > > rawhide installs have been failing (in different ways, the latest try hit > the No such file or directory: '/usr/share/rhpl/vesamodes', sounds like > that has been fixed already). > > So I installed FC4, and yum update-d to latest FC4. > > Now I'm trying to yum update to rawhide, but I am hitting conflict / > dependency problems. > > Is there a way around these? > > I've been searching but haven't found an answer, I'm using internal > mirrors of rawhide, and disabled all but the yum development repos. > > The yum update output, other data available on request: > > [ ... ] > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > --> Running transaction check > Error: Unable to satisfy dependencies > Error: Package initscripts needs kernel < 2.6.12, this is not available. > Error: Package kudzu needs kernel < 2.6.13, this is not available. > > And the full output: > > Setting up Update Process > Setting up repositories > Reading repository metadata in from local files > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package pyxf86config.i386 0:0.3.19-6 set to be updated > ---> Package SysVinit.i386 0:2.85-40 set to be updated > ---> Package GConf2.i386 0:2.12.0-1 set to be updated > ---> Package device-mapper.i386 0:1.01.05-1.0 set to be updated > ---> Package gphoto2.i386 0:2.1.6-2 set to be updated > ---> Package tcl.i386 0:8.4.11-1 set to be updated > ---> Package xorg-x11-Mesa-libGL.i386 0:6.8.2-55 set to be updated > ---> Package libgcrypt.i386 0:1.2.2-1 set to be updated > ---> Package libgsf.i386 0:1.12.3-1 set to be updated > ---> Package oprofile.i386 0:0.9.1-2 set to be updated > ---> Package gnome-mag.i386 0:0.12.2-1 set to be updated > ---> Package hal.i386 0:0.5.4-3 set to be updated > ---> Package dbus.i386 0:0.50-1 set to be updated > ---> Package krb5-libs.i386 0:1.4.2-4 set to be updated > ---> Package gcc-gfortran.i386 0:4.0.2-3 set to be updated > ---> Package man-pages.noarch 0:2.08-1 set to be updated > ---> Package gnome-applets.i386 1:2.12.1-1 set to be updated > ---> Package samba-client.i386 0:3.0.20-2 set to be updated > ---> Package grub.i386 0:0.95-15 set to be updated > ---> Package poppler.i386 0:0.4.2-1 set to be updated > ---> Package rp-pppoe.i386 0:3.5-30 set to be updated > ---> Package chkconfig.i386 0:1.3.20-2 set to be updated > ---> Package festival.i386 0:1.95-4 set to be updated > ---> Package e2fsprogs-devel.i386 0:1.38-1 set to be updated > ---> Package openldap-devel.i386 0:2.2.29-2 set to be updated > ---> Package nscd.i386 0:2.3.90-14 set to be updated > ---> Package tmpwatch.i386 0:2.9.4-1 set to be updated > ---> Package yum.noarch 0:2.4.0-6 set to be updated > ---> Package patchutils.i386 0:0.2.31-2 set to be updated > ---> Package gtksourceview.i386 0:1.4.2-1 set to be updated > ---> Package system-config-securitylevel-tui.i386 0:1.6.4-3 set to be updated > ---> Package samba-common.i386 0:3.0.20-2 set to be updated > ---> Package finger.i386 0:0.17-29 set to be updated > ---> Package nc.i386 0:1.82-1 set to be updated > ---> Package kudzu.i386 0:1.2.9-1 set to be updated > ---> Package rpm.i386 0:4.4.2-6 set to be updated > ---> Package libstdc++-devel.i386 0:4.0.2-3 set to be updated > ---> Package neon.i386 0:0.24.7-8 set to be updated > ---> Package perl-DateManip.noarch 0:5.44-1 set to be updated > ---> Package tcsh.i386 0:6.14-5 set to be updated > ---> Package libtermcap-devel.i386 0:2.0.8-42 set to be updated > ---> Package autofs.i386 1:4.1.4-9 set to be updated > ---> Package hardlink.i386 1:1.0-1.14 set to be updated > ---> Package rdist.i386 1:6.1.5-42 set to be updated > ---> Package bluez-libs.i386 0:2.20-1 set to be updated > ---> Package xorg-x11-Mesa-libGLU.i386 0:6.8.2-55 set to be updated > ---> Package metacity.i386 0:2.12.1-1 set to be updated > ---> Package gnome-media.i386 0:2.12.0-1 set to be updated > ---> Package iputils.i386 0:20020927-29 set to be updated > ---> Package mgetty.i386 0:1.1.33-3_FC5 set to be updated > ---> Package openssl.i686 0:0.9.7f-9 set to be updated > ---> Package system-config-date.noarch 0:1.7.99.2-1 set to be updated > ---> Package minicom.i386 0:2.1-1 set to be updated > ---> Package xorg-x11.i386 0:6.8.2-55 set to be updated > ---> Package glib2.i386 0:2.8.3-1 set to be updated > ---> Package system-config-printer.i386 0:0.6.143-1 set to be updated > ---> Package atk.i386 0:1.10.3-1 set to be updated > ---> Package qt.i386 1:3.3.5-3 set to be updated > ---> Package eel2.i386 0:2.12.1-1 set to be updated > ---> Package MAKEDEV.i386 0:3.19-4 set to be updated > ---> Package libmng.i386 0:1.0.9-2 set to be updated > ---> Package pyOpenSSL.i386 0:0.6-1.p24.6 set to be updated > ---> Package libIDL.i386 0:0.8.6-1 set to be updated > ---> Package cyrus-sasl-md5.i386 0:2.1.21-5 set to be updated > ---> Package system-config-soundcard.noarch 0:1.2.12-5 set to be updated > ---> Package ppp.i386 0:2.4.3-4 set to be updated > ---> Package gnome-themes.noarch 0:2.12.1-1 set to be updated > ---> Package libxslt.i386 0:1.1.15-1 set to be updated > ---> Package freeglut.i386 0:2.4.0-1 set to be updated > ---> Package fetchmail.i386 0:6.2.5.2-1 set to be updated > ---> Package pam_krb5.i386 0:2.1.9-2 set to be updated > ---> Package sysreport.noarch 0:1.4.2-2 set to be updated > ---> Package gimp-print.i386 0:4.2.7-12 set to be updated > ---> Package lsof.i386 0:4.76-1 set to be updated > ---> Package perl.i386 3:5.8.7-0.5.fc5 set to be updated > ---> Package giflib.i386 0:4.1.3-5 set to be updated > ---> Package pam.i386 0:0.80-9 set to be updated > ---> Package gnome-python2.i386 0:2.11.3-2 set to be updated > ---> Package NetworkManager.i386 0:0.4.1-5.cvs20051010 set to be updated > ---> Package libuser.i386 0:0.54.1-1 set to be updated > ---> Package libtool.i386 0:1.5.20-4 set to be updated > ---> Package psmisc.i386 0:21.7-1.cvs20051005 set to be updated > ---> Package kernel.i686 0:2.6.13-1.1601_FC5 set to be installed > ---> Package libselinux.i386 0:1.27.7-1 set to be updated > ---> Package openldap.i386 0:2.2.29-2 set to be updated > ---> Package bzip2.i386 0:1.0.3-1 set to be updated > ---> Package system-config-keyboard.noarch 0:1.2.6-3 set to be updated > ---> Package slrn.i386 0:0.9.8.1-5 set to be updated > ---> Package openssl-devel.i386 0:0.9.7f-9 set to be updated > ---> Package dump.i386 0:0.4b40-4 set to be updated > ---> Package pyparted.i386 0:1.6.9-4 set to be updated > ---> Package curl.i386 0:7.14.0-1 set to be updated > ---> Package xterm.i386 0:200-9 set to be updated > ---> Package glibc-common.i386 0:2.3.90-14 set to be updated > ---> Package mkisofs.i386 8:2.01.1-10 set to be updated > ---> Package gdb.i386 0:6.3.0.0-1.65 set to be updated > ---> Package openssh.i386 0:4.2p1-2 set to be updated > ---> Package xorg-x11-tools.i386 0:6.8.2-55 set to be updated > ---> Package gnome-python2-extras.i386 0:2.11.4-9 set to be updated > ---> Package syslinux.i386 0:3.10-2 set to be updated > ---> Package ncurses-devel.i386 0:5.4-19 set to be updated > ---> Package bluez-hcidump.i386 0:1.24-1 set to be updated > ---> Package nano.i386 0:1.3.8-1 set to be updated > ---> Package evince.i386 0:0.4.0-2 set to be updated > ---> Package slocate.i386 0:2.7-28 set to be updated > ---> Package util-linux.i386 0:2.13-0.4.pre4 set to be updated > ---> Package bluez-utils.i386 0:2.20-1 set to be updated > ---> Package xorg-x11-xauth.i386 0:6.8.2-55 set to be updated > ---> Package docbook-dtds.noarch 0:1.0-27 set to be updated > ---> Package gconf-editor.i386 0:2.12.0-1 set to be updated > ---> Package vim-minimal.i386 1:6.3.090-2 set to be updated > ---> Package gnome-doc-utils.noarch 0:0.4.2-1 set to be updated > ---> Package hwbrowser.noarch 0:0.23-1 set to be updated > ---> Package libglade2.i386 0:2.5.1-3 set to be updated > ---> Package pcmciautils.i386 0:007-1 set to be updated > ---> Package at-spi.i386 0:1.6.6-1 set to be updated > ---> Package gcc-c++.i386 0:4.0.2-3 set to be updated > ---> Package foomatic.i386 0:3.0.2-28 set to be updated > ---> Package e2fsprogs.i386 0:1.38-1 set to be updated > ---> Package gnome-icon-theme.noarch 0:2.12.1-1 set to be updated > ---> Package binutils.i386 0:2.16.91.0.2-4 set to be updated > ---> Package redhat-menus.noarch 0:5.0.1-1 set to be updated > ---> Package libattr-devel.i386 0:2.4.23-1 set to be updated > ---> Package libidn-devel.i386 0:0.5.19-1 set to be updated > ---> Package db4-utils.i386 0:4.3.29-1 set to be updated > ---> Package krbafs-devel.i386 0:1.2.2-9 set to be updated > ---> Package redhat-rpm-config.noarch 0:8.0.39-1 set to be updated > ---> Package python-devel.i386 0:2.4.1-14 set to be updated > ---> Package tk.i386 0:8.4.11-1 set to be updated > ---> Package rcs.i386 0:5.7-29 set to be updated > ---> Package gnome-speech.i386 0:0.3.8-1 set to be updated > ---> Package logwatch.noarch 0:6.1.2-7 set to be updated > ---> Package emacs-leim.i386 0:21.4-7 set to be updated > ---> Package gtk2-engines.i386 0:2.6.5-1 set to be updated > ---> Package info.i386 0:4.8-6 set to be updated > ---> Package udev.i386 0:069-10 set to be updated > ---> Package emacs-common.i386 0:21.4-7 set to be updated > ---> Package gnome-panel.i386 0:2.12.1-1 set to be updated > ---> Package gedit.i386 1:2.12.1-1 set to be updated > ---> Package vim-enhanced.i386 1:6.3.090-2 set to be updated > ---> Package mtr.i386 2:0.69-6 set to be updated > ---> Package gcc.i386 0:4.0.2-3 set to be updated > ---> Package freetype.i386 0:2.1.10-1 set to be updated > ---> Package eject.i386 0:2.1.2-1 set to be updated > ---> Package ksh.i386 0:20050202-3 set to be updated > ---> Package nss_db.i386 0:2.2-34 set to be updated > ---> Package glibc.i686 0:2.3.90-14 set to be updated > ---> Package pax.i386 0:3.4-1 set to be updated > ---> Package wget.i386 0:1.10.1-7 set to be updated > ---> Package gnupg.i386 0:1.4.2-3 set to be updated > ---> Package perl-XML-NamespaceSupport.noarch 0:1.09-1 set to be updated > ---> Package xorg-x11-font-utils.i386 0:6.8.2-55 set to be updated > ---> Package grep.i386 0:2.5.1-51 set to be updated > ---> Package libxml2-python.i386 0:2.6.22-1 set to be updated > ---> Package cpio.i386 0:2.6-8 set to be updated > ---> Package bash.i386 0:3.0-35 set to be updated > ---> Package libbonoboui.i386 0:2.10.1-1 set to be updated > ---> Package rpm-libs.i386 0:4.4.2-6 set to be updated > ---> Package gamin.i386 0:0.1.6-3 set to be updated > ---> Package krb5-devel.i386 0:1.4.2-4 set to be updated > ---> Package kernel-smp-devel.i686 0:2.6.13-1.1601_FC5 set to be installed > ---> Package rpm-build.i386 0:4.4.2-6 set to be updated > ---> Package vim-common.i386 1:6.3.090-2 set to be updated > ---> Package gnome-terminal.i386 0:2.12.0-1 set to be updated > ---> Package patch.i386 0:2.5.4-29 set to be updated > ---> Package elfutils.i386 0:0.115-1 set to be updated > ---> Package libgnomecups.i386 0:0.2.2-1 set to be updated > ---> Package zlib.i386 0:1.2.3-1 set to be updated > ---> Package gok.i386 0:1.0.5-4 set to be updated > ---> Package neon-devel.i386 0:0.24.7-8 set to be updated > ---> Package pango.i386 0:1.10.1-1 set to be updated > ---> Package selinux-policy-targeted.noarch 0:1.27.1-15 set to be updated > ---> Package libpcap.i386 14:0.9.3-3 set to be updated > ---> Package nss_ldap.i386 0:243-1 set to be updated > ---> Package mkinitrd.i386 0:5.0.4-1 set to be updated > ---> Package pkgconfig.i386 1:0.19-1 set to be updated > ---> Package dbus-devel.i386 0:0.50-1 set to be updated > ---> Package xinitrc.noarch 0:4.0.19-1 set to be updated > ---> Package at.i386 0:3.1.8-79 set to be updated > ---> Package aspell-en.i386 50:6.0-1 set to be updated > ---> Package krbafs.i386 0:1.2.2-9 set to be updated > ---> Package gnome-vfs2.i386 0:2.12.1.1-1 set to be updated > ---> Package ghostscript.i386 0:8.15.1-1 set to be updated > ---> Package system-config-printer-gui.i386 0:0.6.143-1 set to be updated > ---> Package gthumb.i386 0:2.6.8-1 set to be updated > ---> Package dbus-python.i386 0:0.50-1 set to be updated > ---> Package file.i386 0:4.15-4 set to be updated > ---> Package cups-libs.i386 1:1.1.23-22 set to be updated > ---> Package libgnomeprintui22.i386 0:2.12.1-1 set to be updated > ---> Package rmt.i386 0:0.4b40-4 set to be updated > ---> Package pam-devel.i386 0:0.80-9 set to be updated > ---> Package elinks.i386 0:0.10.6-1 set to be updated > ---> Package quota.i386 1:3.12-7 set to be updated > ---> Package strace.i386 0:4.5.13-1 set to be updated > ---> Package sqlite.i386 0:3.2.7-2 set to be updated > ---> Package iproute.i386 0:2.6.14-6 set to be updated > ---> Package python-urlgrabber.noarch 0:2.9.6-4 set to be updated > ---> Package switchdesk.noarch 0:4.0.7-1 set to be updated > ---> Package bzip2-devel.i386 0:1.0.3-1 set to be updated > ---> Package zlib-devel.i386 0:1.2.3-1 set to be updated > ---> Package gstreamer.i386 0:0.8.11-2 set to be updated > ---> Package cyrus-sasl.i386 0:2.1.21-5 set to be updated > ---> Package libgcc.i386 0:4.0.2-3 set to be updated > ---> Package pstack.i386 0:1.2-7 set to be updated > ---> Package gnopernicus.i386 0:0.12.0-1 set to be updated > ---> Package valgrind.i386 1:3.0.1-1 set to be updated > ---> Package sendmail.i386 0:8.13.5-1 set to be updated > ---> Package vixie-cron.i386 4:4.1-36.FC5 set to be updated > ---> Package gnome-pilot.i386 0:2.0.13-7.fc5 set to be updated > ---> Package make.i386 1:3.80-8 set to be updated > ---> Package intltool.i386 0:0.34.1-1 set to be updated > ---> Package libacl-devel.i386 0:2.2.31-1 set to be updated > ---> Package xorg-x11-libs.i386 0:6.8.2-55 set to be updated > ---> Package stunnel.i386 0:4.12-1 set to be updated > ---> Package tzdata.noarch 0:2005m-2 set to be updated > ---> Package libxml2.i386 0:2.6.22-1 set to be updated > ---> Package db4-devel.i386 0:4.3.29-1 set to be updated > ---> Package bzip2-libs.i386 0:1.0.3-1 set to be updated > ---> Package gtk2.i386 0:2.8.6-1 set to be updated > ---> Package gdm.i386 1:2.8.0.4-3 set to be updated > ---> Package alsa-utils.i386 0:1.0.10rc1-1 set to be updated > ---> Package cdrecord.i386 8:2.01.1-10 set to be updated > ---> Package popt.i386 0:1.10.2-6 set to be updated > ---> Package gettext.i386 0:0.14.5-2 set to be updated > ---> Package kernel-smp.i686 0:2.6.13-1.1601_FC5 set to be installed > ---> Package jwhois.i386 0:3.2.3-2 set to be updated > ---> Package gnome-volume-manager.i386 0:1.5.3-1 set to be updated > ---> Package libgnomecanvas.i386 0:2.12.0-1 set to be updated > ---> Package gnome-python2-gtkhtml2.i386 0:2.11.4-9 set to be updated > ---> Package lvm2.i386 0:2.01.14-2 set to be updated > ---> Package initscripts.i386 0:8.17-1 set to be updated > ---> Package ntsysv.i386 0:1.3.20-2 set to be updated > ---> Package isdn4k-utils.i386 0:3.2-32 set to be updated > ---> Package elfutils-libelf.i386 0:0.115-1 set to be updated > ---> Package libgtop2.i386 0:2.12.0-1 set to be updated > ---> Package fontconfig.i386 0:2.3.2-1 set to be updated > ---> Package evolution-data-server.i386 0:1.4.0-2 set to be updated > ---> Package NetworkManager-gnome.i386 0:0.4.1-5.cvs20051010 set to be updated > ---> Package rpm-python.i386 0:4.4.2-6 set to be updated > ---> Package nautilus.i386 0:2.12.1-1 set to be updated > ---> Package less.i386 0:382-8 set to be updated > ---> Package system-config-securitylevel.i386 0:1.6.4-3 set to be updated > ---> Package bind.i386 24:9.3.1-18 set to be updated > ---> Package man.i386 0:1.5p-6 set to be updated > ---> Package glibc-headers.i386 0:2.3.90-14 set to be updated > ---> Package passwd.i386 0:0.71-1 set to be updated > ---> Package desktop-backgrounds-basic.noarch 0:2.0-30 set to be updated > ---> Package ntp.i386 0:4.2.0.a.20050816-2 set to be updated > ---> Package unzip.i386 0:5.51-12 set to be updated > ---> Package hotplug.i386 3:2004_09_23-10 set to be updated > ---> Package desktop-printing.i386 0:0.19-2 set to be updated > ---> Package lftp.i386 0:3.3.0-1 set to be updated > ---> Package pilot-link.i386 1:0.12.0-0.pre4.5 set to be updated > ---> Package system-config-display.noarch 0:1.0.32-1 set to be updated > ---> Package netdump.i386 0:0.7.14-1 set to be updated > ---> Package gnome-vfs2-smb.i386 0:2.12.1.1-1 set to be updated > ---> Package curl-devel.i386 0:7.14.0-1 set to be updated > ---> Package dbus-glib.i386 0:0.50-1 set to be updated > ---> Package pygtk2.i386 0:2.8.0-1 set to be updated > ---> Package openssh-askpass.i386 0:4.2p1-2 set to be updated > ---> Package boost.i386 0:1.33.0-4 set to be updated > ---> Package prelink.i386 0:0.3.6-1 set to be updated > ---> Package gnome-python2-gnomevfs.i386 0:2.11.3-2 set to be updated > ---> Package vnc-server.i386 0:4.1.1-17 set to be updated > ---> Package system-config-users.noarch 0:1.2.41-1 set to be updated > ---> Package filesystem.i386 0:2.3.5-1 set to be updated > ---> Package libgfortran.i386 0:4.0.2-3 set to be updated > ---> Package cyrus-sasl-devel.i386 0:2.1.21-5 set to be updated > ---> Package cracklib-dicts.i386 0:2.8.5-2 set to be updated > ---> Package system-config-services.noarch 0:0.8.26-1 set to be updated > ---> Package m4.i386 0:1.4.3-2 set to be updated > ---> Package tcpdump.i386 14:3.9.3-3 set to be updated > ---> Package policycoreutils.i386 0:1.27.5-3 set to be updated > ---> Package sudo.i386 0:1.6.8p9-5 set to be updated > ---> Package firstboot.noarch 0:1.3.50-1 set to be updated > ---> Package libstdc++.i386 0:4.0.2-3 set to be updated > ---> Package a2ps.i386 0:4.13b-47 set to be updated > ---> Package gstreamer-plugins.i386 0:0.8.11-1 set to be updated > ---> Package nspr.i386 0:4.6-4 set to be updated > ---> Package openssh-askpass-gnome.i386 0:4.2p1-2 set to be updated > ---> Package vino.i386 0:2.12.0-2 set to be updated > ---> Package authconfig.i386 0:5.0.1-1 set to be updated > ---> Package gnome-session.i386 0:2.12.0-1 set to be updated > ---> Package ncurses.i386 0:5.4-19 set to be updated > ---> Package gnome-desktop.i386 0:2.12.1-1 set to be updated > ---> Package usermode-gtk.i386 0:1.81-1 set to be updated > ---> Package libxml2-devel.i386 0:2.6.22-1 set to be updated > ---> Package sqlite-devel.i386 0:3.2.7-2 set to be updated > ---> Package gail.i386 0:1.8.5-1 set to be updated > ---> Package newt.i386 0:0.52.1-0 set to be updated > ---> Package audit.i386 0:1.0.6-1 set to be updated > ---> Package module-init-tools.i386 0:3.2-0.pre7.3 set to be updated > ---> Package pam_passwdqc.i386 0:1.0.2-1 set to be updated > ---> Package iptables.i386 0:1.3.2-1 set to be updated > ---> Package control-center.i386 1:2.12.1-1 set to be updated > ---> Package openssh-clients.i386 0:4.2p1-2 set to be updated > ---> Package gimp-print-utils.i386 0:4.2.7-12 set to be updated > ---> Package net-tools.i386 0:1.60-56 set to be updated > ---> Package rhnlib.noarch 0:1.8-6.p24.11 set to be updated > ---> Package setools.i386 0:2.1.2-3 set to be updated > ---> Package nautilus-cd-burner.i386 0:2.12.1-1 set to be updated > ---> Package gnome-keyring.i386 0:0.4.5-1 set to be updated > ---> Package aspell.i386 12:0.60.3-2 set to be updated > ---> Package cyrus-sasl-plain.i386 0:2.1.21-5 set to be updated > ---> Package dhclient.i386 11:3.0.3-7 set to be updated > ---> Package shared-mime-info.i386 0:0.16-5 set to be updated > ---> Package authconfig-gtk.i386 0:5.0.1-1 set to be updated > ---> Package gnome-netstatus.i386 0:2.12.0-1 set to be updated > ---> Package lockdev.i386 0:1.0.1-9 set to be updated > ---> Package gnome-utils.i386 1:2.12.1-1 set to be updated > ---> Package krb5-auth-dialog.i386 0:0.2-6 set to be updated > ---> Package libattr.i386 0:2.4.23-1 set to be updated > ---> Package lockdev-devel.i386 0:1.0.1-9 set to be updated > ---> Package automake.noarch 0:1.9.6-1 set to be updated > ---> Package libtermcap.i386 0:2.0.8-42 set to be updated > ---> Package pm-utils.i386 0:0.05-1 set to be updated > ---> Package glibc-kernheaders.i386 0:2.4-9.1.95 set to be updated > ---> Package setuptool.i386 0:1.17.3-1 set to be updated > ---> Package libgnomeprint22.i386 0:2.12.1-2 set to be updated > ---> Package ctags.i386 0:5.5.4-4 set to be updated > ---> Package parted.i386 0:1.6.24-1 set to be updated > ---> Package pcre.i386 0:6.3-1 set to be updated > ---> Package rhn-applet.i386 0:2.1.17-4 set to be updated > ---> Package libuser-devel.i386 0:0.54.1-1 set to be updated > ---> Package glib2-devel.i386 0:2.8.3-1 set to be updated > ---> Package ORBit2.i386 0:2.12.4-2 set to be updated > ---> Package file-roller.i386 0:2.12.1-1 set to be updated > ---> Package libsepol.i386 0:1.9.14-1 set to be updated > ---> Package libgnomeui.i386 0:2.12.0-2 set to be updated > ---> Package libraw1394.i386 0:1.2.0-1.fc5 set to be updated > ---> Package desktop-file-utils.i386 0:0.10-3 set to be updated > ---> Package coreutils.i386 0:5.2.1-56 set to be updated > ---> Package openssh-server.i386 0:4.2p1-2 set to be updated > ---> Package bind-libs.i386 24:9.3.1-18 set to be updated > ---> Package slang.i386 0:1.4.9-19 set to be updated > ---> Package usermode.i386 0:1.81-1 set to be updated > ---> Package gnome-python2-bonobo.i386 0:2.11.3-2 set to be updated > ---> Package logrotate.i386 0:3.7.2-5 set to be updated > ---> Package ftp.i386 0:0.17-29 set to be updated > ---> Package gd.i386 0:2.0.33-4 set to be updated > ---> Package hpijs.i386 1:0.9.5-3 set to be updated > ---> Package arts.i386 8:1.4.91-1 set to be updated > ---> Package gnome-system-monitor.i386 0:2.12.1-1 set to be updated > ---> Package numactl.i386 0:0.6.4-1.23 set to be updated > ---> Package ttmkfdir.i386 0:3.0.9-19 set to be updated > ---> Package dbus-x11.i386 0:0.50-1 set to be updated > ---> Package cups.i386 1:1.1.23-22 set to be updated > ---> Package findutils.i386 1:4.2.25-3 set to be updated > ---> Package texinfo.i386 0:4.8-6 set to be updated > ---> Package perl-Compress-Zlib.i386 0:1.37-1.fc5 set to be updated > ---> Package pygtk2-libglade.i386 0:2.8.0-1 set to be updated > ---> Package cvs.i386 0:1.11.19-10 set to be updated > ---> Package rsync.i386 0:2.6.6-2 set to be updated > ---> Package attr.i386 0:2.4.23-1 set to be updated > ---> Package librsvg2.i386 0:2.12.7-1 set to be updated > ---> Package cpp.i386 0:4.0.2-3 set to be updated > ---> Package newt-devel.i386 0:0.52.1-0 set to be updated > ---> Package bind-utils.i386 24:9.3.1-18 set to be updated > ---> Package gnome-keyring-manager.i386 0:2.12.0-1 set to be updated > ---> Package wireless-tools.i386 1:28-0.pre9.5 set to be updated > ---> Package emacs.i386 0:21.4-7 set to be updated > ---> Package alsa-lib.i386 0:1.0.10rc1-2 set to be updated > ---> Package glibc-devel.i386 0:2.3.90-14 set to be updated > ---> Package db4.i386 0:4.3.29-1 set to be updated > ---> Package xscreensaver-base.i386 1:4.22-18 set to be updated > ---> Package fedora-logos.noarch 0:1.1.31-2 set to be updated > ---> Package krb5-workstation.i386 0:1.4.2-4 set to be updated > ---> Package xorg-x11-xfs.i386 0:6.8.2-55 set to be updated > ---> Package gnutls.i386 0:1.2.6-1 set to be updated > ---> Package nfs-utils.i386 0:1.0.7-18.FC5 set to be updated > ---> Package gnome-python2-canvas.i386 0:2.11.3-2 set to be updated > ---> Package boost-devel.i386 0:1.33.0-4 set to be updated > ---> Package procps.i386 0:3.2.5-7 set to be updated > ---> Package setup.noarch 0:2.5.47-1.1 set to be updated > ---> Package libsoup.i386 0:2.2.6.1-1 set to be updated > ---> Package perl-Crypt-SSLeay.i386 0:0.51-8 set to be updated > ---> Package sysklogd.i386 0:1.4.1-33 set to be updated > ---> Package python.i386 0:2.4.1-14 set to be updated > ---> Package vte.i386 0:0.11.15-1.fc5 set to be updated > ---> Package gawk.i386 0:3.1.5-4 set to be updated > ---> Package libselinux-devel.i386 0:1.27.7-1 set to be updated > ---> Package hdparm.i386 0:6.1-1 set to be updated > ---> Package libidn.i386 0:0.5.19-1 set to be updated > ---> Package checkpolicy.i386 0:1.27.7-2 set to be updated > ---> Package gnome-menus.i386 0:2.12.0-1 set to be updated > ---> Package cracklib.i386 0:2.8.5-2 set to be updated > ---> Package system-config-lvm.noarch 0:1.0.7-1.0 set to be updated > ---> Package audit-libs.i386 0:1.0.6-1 set to be updated > ---> Package redhat-artwork.i386 0:0.128-2 set to be updated > ---> Package esound.i386 1:0.2.36-1 set to be updated > ---> Package slang-devel.i386 0:1.4.9-19 set to be updated > ---> Package vsftpd.i386 0:2.0.3-11 set to be updated > ---> Package mutt.i386 5:1.4.2.1-3 set to be updated > ---> Package libwnck.i386 0:2.12.1-1 set to be updated > ---> Package rhpl.i386 0:0.176-1 set to be updated > ---> Package libgnome.i386 0:2.12.0.1-1 set to be updated > ---> Package libacl.i386 0:2.2.31-1 set to be updated > ---> Package libbonobo.i386 0:2.10.1-2 set to be updated > ---> Package pam_ccreds.i386 0:1-7 set to be updated > ---> Package libtiff.i386 0:3.7.4-1 set to be updated > ---> Package traceroute.i386 0:1.4a12-27 set to be updated > ---> Package acl.i386 0:2.2.31-1 set to be updated > ---> Package diffstat.i386 0:1.38-4 set to be updated > ---> Package fedora-release.noarch 0:4-99.rawhide set to be updated > ---> Package doxygen.i386 1:1.4.4-2 set to be updated > ---> Package yelp.i386 0:2.12.1-1 set to be updated > ---> Package hwdata.noarch 0:0.169-1 set to be updated > ---> Package rpm-devel.i386 0:4.4.2-6 set to be updated > --> Running transaction check > --> Processing Dependency: libcairo.so.2 for package: libbonoboui > --> Processing Dependency: libcairo.so.2 for package: vte > --> Processing Dependency: cyrus-sasl-lib = 2.1.21-5 for package: cyrus-sasl-md5 > --> Processing Conflict: initscripts conflicts kernel < 2.6.12 > --> Processing Dependency: libcairo.so.2 for package: gnome-python2-gtkhtml2 > --> Processing Dependency: libsasl2.so.2 for package: cyrus-sasl-devel > --> Processing Dependency: libcairo.so.2 for package: gnome-panel > --> Processing Dependency: rhpxl for package: firstboot > --> Processing Dependency: libcairo.so.2 for package: libglade2 > --> Processing Dependency: cryptsetup-luks >= 1.0.1-2 for package: hal > --> Processing Dependency: libcairo.so.2 for package: gnopernicus > --> Processing Dependency: libsemanage.so.1(LIBSEMANAGE_1.0) for package: policycoreutils > --> Processing Dependency: cyrus-sasl-lib = 2.1.21-5 for package: cyrus-sasl-plain > --> Processing Dependency: libcairo.so.2 for package: gnome-system-monitor > --> Processing Dependency: cyrus-sasl-lib = 2.1.21-5 for package: cyrus-sasl-devel > --> Processing Dependency: libcairo.so.2 for package: xscreensaver-base > --> Processing Dependency: elfutils-libs = 0.115-1 for package: elfutils > --> Processing Dependency: libcairo.so.2 for package: nautilus-cd-burner > --> Processing Dependency: libcairo.so.2 for package: nautilus > --> Processing Dependency: libsasl2.so.2 for package: cyrus-sasl > --> Processing Dependency: libsemanage for package: policycoreutils > --> Processing Dependency: libcairo.so.2 for package: GConf2 > --> Processing Dependency: libcairo.so.2 for package: gnome-python2 > --> Processing Dependency: libcairo.so.2 for package: libwnck > --> Processing Dependency: libcairo.so.2 for package: gnome-utils > --> Processing Dependency: libcairo.so.2 for package: yelp > --> Processing Dependency: libcairo.so.2 for package: gtk2 > --> Processing Dependency: libcairo.so.2 for package: metacity > --> Processing Dependency: libcairo.so.2 for package: desktop-printing > --> Processing Dependency: libmysqlclient.so.14 for package: cyrus-sasl-devel > --> Processing Dependency: elfutils-libelf-devel for package: rpm-devel > --> Processing Dependency: libcairo.so.2 for package: NetworkManager-gnome > --> Processing Dependency: libcairo.so.2 for package: gconf-editor > --> Processing Dependency: libcairo.so.2 for package: vino > --> Processing Dependency: libsemanage.so.1 for package: policycoreutils > --> Processing Dependency: libcairo.so.2 for package: gnome-terminal > --> Processing Dependency: libcairo.so.2 for package: evince > --> Processing Dependency: libcairo.so.2 for package: pango > --> Processing Dependency: libsasl2.so.2 for package: openldap > --> Processing Dependency: libcairo.so.2 for package: gnome-python2-bonobo > --> Processing Dependency: libcairo.so.2 for package: at-spi > --> Processing Dependency: libsasl2.so.2 for package: python-ldap > --> Processing Dependency: libcairo.so.2 for package: gnome-applets > --> Processing Dependency: libcairo.so.2 for package: krb5-auth-dialog > --> Processing Dependency: libcairo.so.2 for package: openssh-askpass-gnome > --> Processing Dependency: libcairo.so.2 for package: libgnomecanvas > --> Processing Dependency: libcairo.so.2 for package: librsvg2 > --> Processing Dependency: cairo >= 0.9.2 for package: pango > --> Processing Dependency: libpq.so.4 for package: cyrus-sasl > --> Processing Dependency: libdw.so.1(ELFUTILS_0.115) for package: elfutils > --> Processing Dependency: libcairo.so.2 for package: gnome-mag > --> Processing Dependency: libdw.so.1 for package: elfutils > --> Processing Dependency: libcairo.so.2 for package: gok > --> Processing Dependency: libcairo.so.2 for package: file-roller > --> Processing Dependency: libcairo.so.2 for package: gtk2-engines > --> Processing Dependency: libcairo.so.2 for package: gnome-keyring-manager > --> Processing Dependency: libcairo.so.2 for package: gstreamer-plugins > --> Processing Dependency: libcairo.so.2 for package: gnome-media > --> Processing Dependency: libcairo.so.2 for package: gedit > --> Processing Dependency: libcairo.so.2 for package: usermode-gtk > --> Processing Dependency: libpq.so.4 for package: cyrus-sasl-devel > --> Processing Dependency: libsasl2.so.2 for package: sendmail > --> Processing Dependency: libcairo.so.2 for package: gdm > --> Processing Dependency: libmysqlclient.so.14 for package: cyrus-sasl > --> Processing Dependency: cyrus-sasl-lib = 2.1.21-5 for package: cyrus-sasl > --> Processing Dependency: libcairo.so.2 for package: pygtk2 > --> Processing Conflict: kudzu conflicts kernel < 2.6.13 > --> Processing Dependency: libcairo.so.2 for package: rhn-applet > --> Processing Dependency: libcairo.so.2 for package: control-center > --> Processing Dependency: dhcdbd for package: NetworkManager > --> Processing Dependency: libcairo.so.2 for package: pygtk2-libglade > --> Processing Dependency: libcairo.so.2 for package: gnome-python2-canvas > --> Processing Dependency: libcairo.so.2 for package: libgnomeprintui22 > --> Processing Dependency: libcairo.so.2 for package: gthumb > --> Processing Dependency: libcairo.so.2 for package: eel2 > --> Processing Dependency: libcairo.so.2 for package: gnome-pilot > --> Processing Dependency: libcairo.so.2 for package: poppler > --> Processing Dependency: libsetrans for package: libselinux > --> Processing Dependency: libcairo.so.2 for package: evolution-data-server > --> Processing Dependency: libcairo.so.2 for package: gail > --> Processing Dependency: libcairo.so.2 for package: gnome-keyring > --> Processing Dependency: libcairo.so.2 for package: gnome-volume-manager > --> Processing Dependency: libcairo.so.2 for package: gnome-netstatus > --> Processing Dependency: libcairo.so.2 for package: gtksourceview > --> Processing Dependency: libcairo.so.2 for package: gnome-desktop > --> Processing Dependency: libcairo.so.2 for package: libgnomeui > --> Processing Dependency: libcairo.so.2 for package: gnome-session > --> Processing Dependency: libsasl2.so.2 for package: mutt > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > ---> Package cryptsetup-luks.i386 0:1.0.1-2 set to be updated > ---> Package mysql.i386 0:4.1.14-1 set to be updated > ---> Package dhcdbd.i386 0:1.9-1 set to be updated > ---> Package postgresql-libs.i386 0:8.0.4-2 set to be updated > ---> Package libsetrans.i386 0:0.1.7-1 set to be updated > ---> Package cyrus-sasl-lib.i386 0:2.1.21-5 set to be updated > ---> Package rhpxl.noarch 0:0.3-1 set to be updated > ---> Package elfutils-libelf-devel.i386 0:0.115-1 set to be updated > ---> Package libsemanage.i386 0:1.3.9-1 set to be updated > ---> Package cairo.i386 0:1.0.2-2 set to be updated > ---> Package elfutils-libs.i386 0:0.115-1 set to be updated > --> Running transaction check > --> Processing Conflict: initscripts conflicts kernel < 2.6.12 > --> Processing Dependency: perl(DBI) for package: mysql > --> Processing Conflict: kudzu conflicts kernel < 2.6.13 > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > ---> Package perl-DBI.i386 0:1.48-4 set to be updated > --> Running transaction check > --> Processing Conflict: initscripts conflicts kernel < 2.6.12 > --> Processing Conflict: kudzu conflicts kernel < 2.6.13 > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > --> Running transaction check > --> Processing Conflict: initscripts conflicts kernel < 2.6.12 > --> Processing Conflict: kudzu conflicts kernel < 2.6.13 > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > --> Running transaction check > Error: Unable to satisfy dependencies > Error: Package initscripts needs kernel < 2.6.12, this is not available. > Error: Package kudzu needs kernel < 2.6.13, this is not available. > > Thanks ... > > -- Patrick Mansfield > From patmans at us.ibm.com Wed Oct 12 21:34:48 2005 From: patmans at us.ibm.com (Patrick Mansfield) Date: Wed, 12 Oct 2005 14:34:48 -0700 Subject: trying to update or install rawhide on x86 system In-Reply-To: <1129149031.7745.2.camel@nighthawk.neonetwork> References: <20051012201235.GA24249@us.ibm.com> <1129149031.7745.2.camel@nighthawk.neonetwork> Message-ID: <20051012213448.GA26805@us.ibm.com> On Wed, Oct 12, 2005 at 04:30:31PM -0400, Sean Plantz wrote: > I had the same issue, and removing the older kernels worked (all pre > 2.6.13 kernels) easiest way to do it is rpm -e kernel-2.6.12* and > append to what versions you still have.. hope that helps. > On Wed, 2005-10-12 at 13:12 -0700, Patrick Mansfield wrote: Yes, thanks, that seems to do it. Though I had some funky write (network write?) hang, and the yum update died in the middle. Looks like rpm/yum database is in a bad state now :-( -- Patrick Mansfield From jamatos at fc.up.pt Wed Oct 12 21:41:13 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 12 Oct 2005 22:41:13 +0100 Subject: Developers Needed!! : Fedora Tracker References: <1129062615.4693.111.camel@satsuki.geekdome.lan> <1129144435.2164.5.camel@localhost> <1129144489.20213.34.camel@cutter> Message-ID: seth vidal wrote: >> >> [0]: http://www.myghty.org/ >> > > or python-kid, which is in extras. So it is python-mighty. :-) > -sv Nice try. ;-) -- Jos? Matos From ang3l0 at katamail.com Wed Oct 12 20:48:55 2005 From: ang3l0 at katamail.com (Angelo) Date: Wed, 12 Oct 2005 22:48:55 +0200 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <20051012185410.GA27139@devserv.devel.redhat.com> References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> Message-ID: <434D76B7.4070101@katamail.com> Alan Cox wrote: >Try netdev at oss.sgi.com. Fedora tracks the base kernel. > i'll try.. i hoped that it could be inserted in the long list of already added patches to the vanilla kernel regards, Angelo From sundaram at redhat.com Wed Oct 12 23:17:45 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 13 Oct 2005 04:47:45 +0530 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434D76B7.4070101@katamail.com> References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> Message-ID: <434D9999.3010700@redhat.com> Angelo wrote: > Alan Cox wrote: > >> Try netdev at oss.sgi.com. Fedora tracks the base kernel. >> > i'll try.. i hoped that it could be inserted in the long list of > already added patches to the vanilla kernel > > regards, > Angelo If you look at the existing patches generally do not add new features but contain bug fixes in order to fix the problem sooner and usually are later merged into the upstream kernel. In general, working with the upstream projects would mean that there is better integration, testing and review within the projects and less deviation and maintenance issues at the distribution level. If the patch list in the kernel is long then we need to work on fixing that rather than use it as a justification to make it even worse. regards Rahul From shiva at sewingwitch.com Wed Oct 12 23:20:22 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 12 Oct 2005 16:20:22 -0700 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434D9999.3010700@redhat.com> References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com> Message-ID: <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> --On Thursday, October 13, 2005 4:47 AM +0530 Rahul Sundaram wrote: > If you look at the existing patches generally do not add new features but > contain bug fixes in order to fix the problem sooner and usually are > later merged into the upstream kernel. Is there some way to tell for each patch where it came from and what it's status is upstream? Like a kernel.org bugzilla entry (or whatever they use). How does the kernel maintainer know when it's time to pull a patch out of the RPM? From davej at redhat.com Wed Oct 12 23:27:35 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 12 Oct 2005 19:27:35 -0400 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com> <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> Message-ID: <20051012232735.GA7772@redhat.com> On Wed, Oct 12, 2005 at 04:20:22PM -0700, Kenneth Porter wrote: > >If you look at the existing patches generally do not add new features but > >contain bug fixes in order to fix the problem sooner and usually are > >later merged into the upstream kernel. > > Is there some way to tell for each patch where it came from and what it's > status is upstream? Like a kernel.org bugzilla entry (or whatever they > use). How does the kernel maintainer know when it's time to pull a patch > out of the RPM? It's usually time to pull it when it no longer applies to the latest upstream :-) The actual patchfiles contain info at the top of the file (or at least a pointer to the bugzilla they're fixing) in most cases, though some of the 'legacy' patches don't have any description yet. Dave From sundaram at redhat.com Wed Oct 12 23:41:03 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 13 Oct 2005 05:11:03 +0530 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <20051012232735.GA7772@redhat.com> References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com> <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> <20051012232735.GA7772@redhat.com> Message-ID: <434D9F0F.40600@redhat.com> Dave Jones wrote: >On Wed, Oct 12, 2005 at 04:20:22PM -0700, Kenneth Porter wrote: > > > >If you look at the existing patches generally do not add new features but > > >contain bug fixes in order to fix the problem sooner and usually are > > >later merged into the upstream kernel. > > > > Is there some way to tell for each patch where it came from and what it's > > status is upstream? Like a kernel.org bugzilla entry (or whatever they > > use). How does the kernel maintainer know when it's time to pull a patch > > out of the RPM? > >It's usually time to pull it when it no longer applies to the latest upstream :-) >The actual patchfiles contain info at the top of the file (or at least a >pointer to the bugzilla they're fixing) in most cases, though some of the >'legacy' patches don't have any description yet. > > Dave > > > It would be useful to add description to those legacy patches too and maintain the current status in a URL and kill the Fedora kernels are heavily patched myth while providing technically capable or merely curious users more information on the patches. regards Rahil From davej at redhat.com Wed Oct 12 23:44:49 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 12 Oct 2005 19:44:49 -0400 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434D9F0F.40600@redhat.com> References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com> <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> <20051012232735.GA7772@redhat.com> <434D9F0F.40600@redhat.com> Message-ID: <20051012234449.GB7772@redhat.com> On Thu, Oct 13, 2005 at 05:11:03AM +0530, Rahul Sundaram wrote: > >The actual patchfiles contain info at the top of the file (or at least a > >pointer to the bugzilla they're fixing) in most cases, though some of the > >'legacy' patches don't have any description yet. > > > It would be useful to add description to those legacy patches too Sure. I'm getting to them one by one, but I've more important things to fix tbh. > and maintain the current status in a URL and kill the Fedora kernels are > heavily patched myth while providing technically capable or merely > curious users more information on the patches. My http://people.redhat.com/davej/kernels/Fedora/*/ pages have a list of patches in each kernel, though they are somewhat out of date now. At some point the patches in CVS will all be documented, and I can run some script nightly that auto-generates those text files. Dave From sundaram at redhat.com Wed Oct 12 23:49:53 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 13 Oct 2005 05:19:53 +0530 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <20051012234449.GB7772@redhat.com> References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com> <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> <20051012232735.GA7772@redhat.com> <434D9F0F.40600@redhat.com> <20051012234449.GB7772@redhat.com> Message-ID: <434DA121.6080401@redhat.com> Dave Jones wrote: >On Thu, Oct 13, 2005 at 05:11:03AM +0530, Rahul Sundaram wrote: > > > >The actual patchfiles contain info at the top of the file (or at least a > > >pointer to the bugzilla they're fixing) in most cases, though some of the > > >'legacy' patches don't have any description yet. > > > > > It would be useful to add description to those legacy patches too > >Sure. I'm getting to them one by one, but I've more important things >to fix tbh. > > > Right. This is just making the information better documented and transparent to end users. Has lower priority to fixing any actual problems obviously. > > and maintain the current status in a URL and kill the Fedora kernels are > > heavily patched myth while providing technically capable or merely > > curious users more information on the patches. > >My http://people.redhat.com/davej/kernels/Fedora/*/ pages have a list >of patches in each kernel, though they are somewhat out of date now. > >At some point the patches in CVS will all be documented, and >I can run some script nightly that auto-generates those text files. > > That would be great. Thanks regards Rahul From dimi at lattica.com Wed Oct 12 23:53:09 2005 From: dimi at lattica.com (Dimi Paun) Date: Wed, 12 Oct 2005 19:53:09 -0400 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels References: <434D34E6.8020105@katamail.com><20051012185410.GA27139@devserv.devel.redhat.com><434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com><69F3758B31FB6A0BF3743ACC@[10.169.6.233]><20051012232735.GA7772@redhat.com> <434D9F0F.40600@redhat.com> <20051012234449.GB7772@redhat.com> Message-ID: <02d401c5cf88$19512f60$b6491b31@td612671> From: "Dave Jones" > My http://people.redhat.com/davej/kernels/Fedora/*/ pages have a list > of patches in each kernel, though they are somewhat out of date now. Looking at: http://people.redhat.com/davej/kernels/Fedora/FC4/kernel-2.6.13-1.1529_FC4.src.rpm-buildlog.txt I see this: + echo 'Patch #1021 (linux-2.6-debug-sleep-in-irq-warning.patch):' + echo 'Patch #1900 (linux-2.6-obsolete-idescsi-warning.patch):' + echo 'Patch #1901 (linux-2.6-obsolete-oss-warning.patch):' + echo 'Patch #801 (linux-2.6-build-userspace-headers-warning.patch):' /usr/include/asm/byteorder.h:6:2: warning: #warning using private kernel header; include instead! /usr/lib/bison.simple:164:5: warning: "YYMAXDEPTH" is not defined Patch #1021 (linux-2.6-debug-sleep-in-irq-warning.patch): Patch #1900 (linux-2.6-obsolete-idescsi-warning.patch): Patch #1901 (linux-2.6-obsolete-oss-warning.patch): Patch #801 (linux-2.6-build-userspace-headers-warning.patch): Does this mean that 2.6.13-1.1529 in FC4 has only 4 patches on top of the upstream kernel? > At some point the patches in CVS will all be documented, and > I can run some script nightly that auto-generates those text files. That would be very cool indeed, I was just trying to convince a friend that FC4 kernels are rather standard. It would have come in handy :) -- Dimi Paun Lattica, Inc. From pbrobinson at gmail.com Wed Oct 12 16:49:11 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 12 Oct 2005 17:49:11 +0100 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434D3D2F.4000507@katamail.com> References: <434D3D2F.4000507@katamail.com> Message-ID: <5256d0b0510120949v2afe4b5cu83a03225997fa545@mail.gmail.com> On 10/12/05, Angelo wrote: > Quoting myself from an year ago: (19 October 2004) > -------------------------------------------------------- > Hi all, > Linux TCP/IP protocol stack is well built but it lacks a bit in > performance. > > To give you an idea, my box has a 10MBit connection to the internet, and > if I try to transfer a file to a little lagged but high bandwidth host > (50ms / 100MBit) this lack of optimization will begin showing. > > Even if my link will permit to transfer from this host at about > 900-1000KB/s I will get only 600-650KB/s. Even using windows tuned to > broadband connection I will get 900KB/s. > > This seems to be related to the tcp window scaling, and even if i try to > tune the kernel related parameters (receive/send buffer) logging the > traffic the tcp window seems to be left too small for this transfers. > > Web100 (www.web100.org) is a project that has solved this issue creating > a patch that will tune every tcp/ip connection to get the best performance. > > I hope this patch will be inserted in the fedora stock kernels. > > Regards, > Angelo > ----------------------------------------------------- > > In a year not a single reply.. i'm still hoping to get this in > > Any idea, comment, reason to disagree, something ? > Well the Fedora Core policy with kernels is that it needs to go upstream to be included in the kernel.. so for something like this you'd be better joining the linux network mailing list and getting some feedback from them and getting it upstreamed via them. Once its hits the main kernel it'll be in Fedora. Pete From tibbs at math.uh.edu Thu Oct 13 00:53:35 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 12 Oct 2005 19:53:35 -0500 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <02d401c5cf88$19512f60$b6491b31@td612671> (Dimi Paun's message of "Wed, 12 Oct 2005 19:53:09 -0400") References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com> <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> <20051012232735.GA7772@redhat.com> <434D9F0F.40600@redhat.com> <20051012234449.GB7772@redhat.com> <02d401c5cf88$19512f60$b6491b31@td612671> Message-ID: >>>>> "DP" == Dimi Paun writes: DP> Does this mean that 2.6.13-1.1529 in FC4 has only 4 patches on top DP> of the upstream kernel? I count 101 applied patches. You can check the current kernel packages out out Fedora CVS and see for yourself: fedora-cvs/kernel/FC-4> grep '^%patch' kernel-2.6.spec |wc -l 101 Current rawhide has only 81. As I understand it, the plan is to tend towards zero but of course that will not be possible in general. - J< From sundaram at redhat.com Thu Oct 13 00:57:53 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 13 Oct 2005 06:27:53 +0530 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com> <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> <20051012232735.GA7772@redhat.com> <434D9F0F.40600@redhat.com> <20051012234449.GB7772@redhat.com> <02d401c5cf88$19512f60$b6491b31@td612671> Message-ID: <434DB111.2010602@redhat.com> Jason L Tibbitts III wrote: >>>>>>"DP" == Dimi Paun writes: >>>>>> >>>>>> > >DP> Does this mean that 2.6.13-1.1529 in FC4 has only 4 patches on top >DP> of the upstream kernel? > >I count 101 applied patches. You can check the current kernel >packages out out Fedora CVS and see for yourself: > >fedora-cvs/kernel/FC-4> grep '^%patch' kernel-2.6.spec |wc -l >101 > Counting the number of occurances of the word is misleading since it appears in the spec comments several times. You need to look into the source rpm or http://cvs.fedora.redhat.com and count the actual number of patches. regards Rahul From bernie at develer.com Thu Oct 13 01:02:48 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 13 Oct 2005 03:02:48 +0200 Subject: Deprecating pam_stack.so In-Reply-To: <1129107955.3158.6.camel@perun.redhat.usu> References: <1128690065.3156.29.camel@perun.redhat.usu> <434C5377.7080501@develer.com> <1129107955.3158.6.camel@perun.redhat.usu> Message-ID: <434DB238.1050002@develer.com> Tomas Mraz wrote: >> - For some reason, pam_ldap interacts strangely with pam_unix. >> Even tough pam_unix comes before it and is "sufficient", >> nobody can login when the network is down or slapd is down. > The pam_ldap module will reject login in the account phase. You can use > pam_localuser (supported by authconfig) to make pam_unix authorization > of local users sufficient. Thank you. I've regenerated my /etc/pam.d/system-auth with system-config-authentication and enabled the localuser module. Login with local user accounts still failed because nss_ldap tries too hard to connect to the LDAP server and incurs in the 60 seconds timeout of /bin/login. I've fixed it by setting these options in my /etc/ldap.conf: # Search timelimit timelimit 3 # Bind timelimit bind_timelimit 2 # Reconnect policy: hard (default) will retry connecting to # the software with exponential backoff, soft will fail # immediately. bind_policy soft I wonder if values like these should become the Fedora defaults? A system that just hangs when you pull the ethernet cable doesn't make a good impression with most users. >> Also, you can login as root with root's password from ldap >> even tough there's a valid root entry in /etc/passwd. > That's expected as both pam_ldap and pam_unix are sufficient entries. > If you want to prevent that you can insert pam_succeed_if Sorry, I don't quite understand how to set it up to reject uid == 0 just for pam_ldap and not for pam_unix. I also don't understand what the "uid < 100" condition inserted by system-config-auth is for. My current config is: auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_krb5afs.so use_first_pass tokens auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 100 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account [default=bad success=ok user_unknown=ignore] pam_krb5afs.so account required pam_permit.so password requisite pam_cracklib.so retry=3 password sufficient pam_unix.so md5 shadow nullok use_authtok password sufficient pam_krb5afs.so use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so session required pam_limits.so session required pam_unix.so session optional pam_krb5afs.so session optional pam_ldap.so The man pam_succeed_if man-page says it can suceed _or_ fail, but it only seems to >> - Many pam.d files still use the absolute path "/lib/security/$ISA/" >> that doesn't seem to be useful anymore and looks weird on >> bi-arch systems such as x86_64. > They will be converted during the change to use include instead of > pam_stack. Nice. system-config-authentication already wiped the paths out when it rewrote system-auth. >> - Something similar of pam_ssh would be much cleaner than the >> current hack of running ssh-agent in GDM's session. gpg-agent >> support would also be welcome. > This is a problem as the passphrases for ssh keys can be different from > the user's system password. So the pam_ssh is definitely not a > replacement for ssh-agent. Yes, we would need half of what pam_ssh does: instead of authenticating the user against his ssh key, it should just load the key iff the passphrase happens to match the account password. Maybe this other project would be more appropriate: http://sourceforge.net/projects/pam-ssh-agent/ PAM module that spawns a ssh-agent and adds identities using the password supplied at login. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Thu Oct 13 01:06:05 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 13 Oct 2005 03:06:05 +0200 Subject: Deprecating pam_stack.so In-Reply-To: <1129108256.3158.10.camel@perun.redhat.usu> References: <1128690065.3156.29.camel@perun.redhat.usu> <434C5377.7080501@develer.com> <1129107955.3158.6.camel@perun.redhat.usu> <1129108256.3158.10.camel@perun.redhat.usu> Message-ID: <434DB2FD.8090400@develer.com> Tomas Mraz wrote: > On Wed, 2005-10-12 at 11:05 +0200, Tomas Mraz wrote: >> On Wed, 2005-10-12 at 02:06 +0200, Bernardo Innocenti wrote: > >>> Also, you can login as root with root's password from ldap >>> even tough there's a valid root entry in /etc/passwd. >> That's expected as both pam_ldap and pam_unix are sufficient entries. >> If you want to prevent that you can insert pam_succeed_if > I've forgot to finish this. You can insert pam_succeed_if in between > pam_unix and pam_ldap. > > auth sufficient pam_unix.so ..... > auth required pam_succeed_if.so uid != 0 quiet > auth sufficient pam_ldap.so ..... > > This way only the local unix password will work for root. Works fine, thanks! (please ignore my previous post asking for clarifications). -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Thu Oct 13 01:13:07 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 13 Oct 2005 03:13:07 +0200 Subject: rawhide report: 20051011 changes In-Reply-To: <200510111115.j9BBFRmr009853@porkchop.devel.redhat.com> References: <200510111115.j9BBFRmr009853@porkchop.devel.redhat.com> Message-ID: <434DB4A3.7030405@develer.com> Build System wrote: > system-config-nfs-1.3.12-1 > -------------------------- > * Tue Oct 11 2005 Nils Philippsen 1.3.12 > - allow user to set networking ports to be used (#151166) > - separate code concerning the NFS server, its settings and NFS exports > - some code cleanup Some files are missing in this package: # system-config-nfs Traceback (most recent call last): File "/usr/share/system-config-nfs/system-config-nfs.py", line 40, in ? import mainWindow File "/usr/share/system-config-nfs/mainWindow.py", line 22, in ? import nfsServer ImportError: No module named nfsServer BTW, is NFSv4 officially supported in Fedora now? With gss-api authentication too? -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From tibbs at math.uh.edu Thu Oct 13 01:15:22 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 12 Oct 2005 20:15:22 -0500 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434DB111.2010602@redhat.com> (Rahul Sundaram's message of "Thu, 13 Oct 2005 06:27:53 +0530") References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com> <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> <20051012232735.GA7772@redhat.com> <434D9F0F.40600@redhat.com> <20051012234449.GB7772@redhat.com> <02d401c5cf88$19512f60$b6491b31@td612671> <434DB111.2010602@redhat.com> Message-ID: >>>>> "RS" == Rahul Sundaram writes: RS> Counting the number of occurances of the word is misleading since RS> it appears in the spec comments several times. I don't believe it can be both in a comment and at the beginning of a line, since the spec file format does not have block comments. I could not find a single match that wasn't the direct application of a patch. If you have evidence to the contrary, I invite you to enlighten me. RS> You need to look into the source rpm or RS> http://cvs.fedora.redhat.com and count the actual number of RS> patches. As I said, I am looking at a current CVS checkout. However, if you just count the patch files, you may be counting some that aren't applied in the current .spec, such as linux-2.6-debug-detect-softlockups.patch, which appears in a current CVS checkout and in the SRPM but is not actually applied by the current spec. Anyway, it's a trivial matter so I apologize for spamming. But I relly did try to engage my brain before posting, and I do have at least a bit of experience doing this. - J< From ang3l0 at katamail.com Wed Oct 12 20:47:39 2005 From: ang3l0 at katamail.com (Angelo) Date: Wed, 12 Oct 2005 22:47:39 +0200 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434D485A.5030202@hhs.nl> References: <434D3D2F.4000507@katamail.com> <434D3E86.3010307@redhat.com> <434D485A.5030202@hhs.nl> Message-ID: <434D766B.5000504@katamail.com> > So, it is merged already, next time check first, complain later. sorry, it was partly merged about 2-3 months ago but i haven't noticed. still is partly merged because i notice an improvement after patching and recompiling the kernel regards, Angelo From shahms at shahms.com Thu Oct 13 01:56:47 2005 From: shahms at shahms.com (Shahms E. King) Date: Wed, 12 Oct 2005 18:56:47 -0700 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com> <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> <20051012232735.GA7772@redhat.com> <434D9F0F.40600@redhat.com> <20051012234449.GB7772@redhat.com> <02d401c5cf88$19512f60$b6491b31@td612671> <434DB111.2010602@redhat.com> Message-ID: <434DBEDF.8020904@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason L Tibbitts III wrote: |>>>>>"RS" == Rahul Sundaram writes: | | | RS> Counting the number of occurances of the word is misleading since | RS> it appears in the spec comments several times. | | I don't believe it can be both in a comment and at the beginning of a | line, since the spec file format does not have block comments. I | could not find a single match that wasn't the direct application of a | patch. If you have evidence to the contrary, I invite you to | enlighten me. It won't count patches that are in comments, but spec files do support various forms of conditional statements. The last time I looked at the kernel spec (which was a while ago, but still FC4) there are a number of patches that are not used at all (inside the equivalent of an "if false" block) and several that are architecture specific, so the count may be off some, but certainly not by much. - --Shahms -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDTb7eRsWY28vsX4ARAidmAKCgYty6HrKwKMb81GKktNNms3QIogCfQ8SE GeF4ovMVpMnWArPpLHePZtw= =Qhkn -----END PGP SIGNATURE----- From davej at redhat.com Thu Oct 13 02:11:54 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 12 Oct 2005 22:11:54 -0400 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <02d401c5cf88$19512f60$b6491b31@td612671> References: <434D9F0F.40600@redhat.com> <20051012234449.GB7772@redhat.com> <02d401c5cf88$19512f60$b6491b31@td612671> Message-ID: <20051013021154.GA3096@redhat.com> On Wed, Oct 12, 2005 at 07:53:09PM -0400, Dimi Paun wrote: > From: "Dave Jones" > > My http://people.redhat.com/davej/kernels/Fedora/*/ pages have a list > > of patches in each kernel, though they are somewhat out of date now. > > Looking at: > > http://people.redhat.com/davej/kernels/Fedora/FC4/kernel-2.6.13-1.1529_FC4.src.rpm-buildlog.txt > > I see this: > + echo 'Patch #1021 (linux-2.6-debug-sleep-in-irq-warning.patch):' > + echo 'Patch #1900 (linux-2.6-obsolete-idescsi-warning.patch):' > + echo 'Patch #1901 (linux-2.6-obsolete-oss-warning.patch):' > + echo 'Patch #801 (linux-2.6-build-userspace-headers-warning.patch):' > /usr/include/asm/byteorder.h:6:2: warning: #warning using private kernel > header; include instead! > /usr/lib/bison.simple:164:5: warning: "YYMAXDEPTH" is not defined > Patch #1021 (linux-2.6-debug-sleep-in-irq-warning.patch): > Patch #1900 (linux-2.6-obsolete-idescsi-warning.patch): > Patch #1901 (linux-2.6-obsolete-oss-warning.patch): > Patch #801 (linux-2.6-build-userspace-headers-warning.patch): > > Does this mean that 2.6.13-1.1529 in FC4 has only 4 patches on top of > the upstream kernel? No, that's a side effect of the output of the build log being fed through sort -u before grepping for warnings. Dave From tibbs at math.uh.edu Thu Oct 13 02:13:53 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 12 Oct 2005 21:13:53 -0500 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <434DBEDF.8020904@shahms.com> (Shahms E. King's message of "Wed, 12 Oct 2005 18:56:47 -0700") References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> <434D76B7.4070101@katamail.com> <434D9999.3010700@redhat.com> <69F3758B31FB6A0BF3743ACC@[10.169.6.233]> <20051012232735.GA7772@redhat.com> <434D9F0F.40600@redhat.com> <20051012234449.GB7772@redhat.com> <02d401c5cf88$19512f60$b6491b31@td612671> <434DB111.2010602@redhat.com> <434DBEDF.8020904@shahms.com> Message-ID: >>>>> "SEK" == Shahms E King writes: SEK> The last time I looked at the kernel spec (which was a while ago, SEK> but still FC4) there are a number of patches that are not used at SEK> all (inside the equivalent of an "if false" block) and several SEK> that are architecture specific, so the count may be off some, but SEK> certainly not by much. In the current development kernel I count seven patches that are conditionally applied, all wrapped in %if %{includexen} ... %endif Those patches are: Patch700: linux-2.6.12-xen.patch Patch701: linux-2.6.12-xen-additional.patch Patch702: linux-2.6.9-xen-compile.patch Patch812: linux-2.6.8-execshield-xen.patch Patch814: linux-2.6.12rc3-xen-vdso-note.patch Patch1051: linux-2.6.8-devmem-xen.patch Patch1061: linux-2.6.10-crash-xen.patch The current specfile is very clean, significantly better than the 2.4 specs. I suggest that folks interested in this discussion take a look at it: http://cvs.fedora.redhat.com/viewcvs/devel/kernel/kernel-2.6.spec - J< From shiva at sewingwitch.com Thu Oct 13 02:40:54 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 12 Oct 2005 19:40:54 -0700 Subject: [RETRY #2] Web100 kernel patch on fedora stock kernels In-Reply-To: <20051012185410.GA27139@devserv.devel.redhat.com> References: <434D34E6.8020105@katamail.com> <20051012185410.GA27139@devserv.devel.redhat.com> Message-ID: <3C07F7AC81DF7DC86A2EB248@[10.169.6.233]> --On Wednesday, October 12, 2005 2:54 PM -0400 Alan Cox wrote: > On Wed, Oct 12, 2005 at 06:08:06PM +0200, Angelo wrote: >> In a year not a single reply.. i'm still hoping to get this in >> Any idea, comment, reason to disagree, something ? > > Try netdev at oss.sgi.com. Fedora tracks the base kernel. A search of their archives for "web100" turned up this plea for a kernel insider to help clean up the patch, back in 2003: That was the highest-scoring match. The rest of the initial ones mention web100 in proposing performance patches. The patch on the Web100 page seems relatively up-to-date but the site itself and the white papers are pretty old (in web time). The Web100 mailing list looks like it's been pretty quiet for a year. Hard to get a read on what's happening with the project, if anything. From nphilipp at redhat.com Thu Oct 13 07:38:12 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 13 Oct 2005 09:38:12 +0200 Subject: rawhide report: 20051011 changes In-Reply-To: <434DB4A3.7030405@develer.com> References: <200510111115.j9BBFRmr009853@porkchop.devel.redhat.com> <434DB4A3.7030405@develer.com> Message-ID: <1129189092.27281.6.camel@wombat.tiptoe.de> On Thu, 2005-10-13 at 03:13 +0200, Bernardo Innocenti wrote: > Build System wrote: > > > system-config-nfs-1.3.12-1 > > -------------------------- > > * Tue Oct 11 2005 Nils Philippsen 1.3.12 > > - allow user to set networking ports to be used (#151166) > > - separate code concerning the NFS server, its settings and NFS exports > > - some code cleanup > > Some files are missing in this package: > > # system-config-nfs > Traceback (most recent call last): > File "/usr/share/system-config-nfs/system-config-nfs.py", line 40, in ? > import mainWindow > File "/usr/share/system-config-nfs/mainWindow.py", line 22, in ? > import nfsServer > ImportError: No module named nfsServer Argh. Adding these files to CVS would help I suppose... > BTW, is NFSv4 officially supported in Fedora now? I think so, yes -- steved (on Cc) can tell us more about this. > With gss-api > authentication too? gss authentication isn't supported in s-c-nfs yet, but I'll be working on it. 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 nphilipp at redhat.com Thu Oct 13 07:38:12 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 13 Oct 2005 09:38:12 +0200 Subject: rawhide report: 20051011 changes In-Reply-To: <434DB4A3.7030405@develer.com> References: <200510111115.j9BBFRmr009853@porkchop.devel.redhat.com> <434DB4A3.7030405@develer.com> Message-ID: <1129189092.27281.6.camel@wombat.tiptoe.de> On Thu, 2005-10-13 at 03:13 +0200, Bernardo Innocenti wrote: > Build System wrote: > > > system-config-nfs-1.3.12-1 > > -------------------------- > > * Tue Oct 11 2005 Nils Philippsen 1.3.12 > > - allow user to set networking ports to be used (#151166) > > - separate code concerning the NFS server, its settings and NFS exports > > - some code cleanup > > Some files are missing in this package: > > # system-config-nfs > Traceback (most recent call last): > File "/usr/share/system-config-nfs/system-config-nfs.py", line 40, in ? > import mainWindow > File "/usr/share/system-config-nfs/mainWindow.py", line 22, in ? > import nfsServer > ImportError: No module named nfsServer Argh. Adding these files to CVS would help I suppose... > BTW, is NFSv4 officially supported in Fedora now? I think so, yes -- steved (on Cc) can tell us more about this. > With gss-api > authentication too? gss authentication isn't supported in s-c-nfs yet, but I'll be working on it. 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 -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From buildsys at redhat.com Thu Oct 13 11:13:25 2005 From: buildsys at redhat.com (Build System) Date: Thu, 13 Oct 2005 07:13:25 -0400 Subject: rawhide report: 20051013 changes Message-ID: <200510131113.j9DBDPek028350@porkchop.devel.redhat.com> New package valgrind-callgrind Call-graph profiler plugin for valgrind Updated Packages: anaconda-10.3.0.31-1 -------------------- * Wed Oct 12 2005 Jeremy Katz - 10.3.0.31-1 - Handle missing metadata (pnasrat) - Give indication of kickstarts scriptlets running (#170017) - Fix a traceback with RAID (#170189) - Fix an FTP install traceback (#170428) - Clean up floppy stuff (clumens) - Clean up some warnings (clumens) - Make IDE device node creation cleaner - Change location of modes data files anthy-7013-1 ------------ * Thu Oct 13 2005 Akira TAGOH - 7013-1 - New upstream snapshot release. - removed the patches: - anthy-add-placename-dict.patch: isn't needed anymore. - anthy_base.t.diff: merged into upstream. - zipcode-20050831.tar.bz2: merged into upstream. cairo-java-1.0.0-10 ------------------- * Wed Oct 12 2005 Igor Foox - 1.0.0-10 - Added dependency on java-1.4.2-gcj-compat for a javadoc generator (bug# 170494). checkpolicy-1.27.8-2 -------------------- * Wed Oct 12 2005 Karsten Hopp 1.27.8-2 - add buildrequirement for libselinux-devel for dispol * Mon Oct 10 2005 Dan Walsh 1.27.8-1 - Latest upgrade from NSA * Updated for changes to libsepol. compat-db-4.2.52-3 ------------------ * Wed Oct 12 2005 Karsten Hopp 4.2.52-3 - add Buildprereq ed (#163025) curl-7.14.1-1 ------------- * Thu Oct 13 2005 Ivana Varekova 7.14.1-1 - update to 7.14.1 ddd-3.3.11-2 ------------ * Wed Oct 12 2005 Than Ngo 3.3.11-2 - install icon in correct place #170512 docbook-dtds-1.0-28 ------------------- * Thu Oct 13 2005 Tim Waugh 1.0-28 - Fixed last fix (bug #159382). dosfstools-2.11-1 ----------------- * Wed Oct 12 2005 Peter Vrabec 2.11-1 - upgrade eclipse-1:3.1.1-1jpp_2fc ------------------------ * Wed Oct 12 2005 Andrew Overholt 3.1.1-1jpp_2fc - Add JavaModelCache overflow patch (e.o#111299). gconf-editor-2.12.0-2 --------------------- * Wed Oct 12 2005 Ray Strode 2.12.0-2 - uninstall schemas when removing rpm gdb-6.3.0.0-1.81 ---------------- * Tue Oct 11 2005 Jeff Johnston 6.3.0.0-1.81 - Bump up release number. * Tue Oct 11 2005 Jeff Johnston 6.3.0.0-1.78 - Support gdb attaching to a stopped process. * Thu Sep 29 2005 Jeff Johnston 6.3.0.0-1.77 - Bump up release number. gnome-themes-2.12.1-2 --------------------- * Wed Oct 12 2005 Matthias Clasen - 2.12.1-2 - Silence %post gnome-utils-1:2.12.1-2 ---------------------- * Wed Oct 12 2005 Matthias Clasen - 1:2.12.1-2 - No need to call update-gtk-immodules in %post, since gucharmap does not include the input method anymore gthumb-2.6.8-2 -------------- * Wed Oct 12 2005 Matthias Clasen - 2.6.8-2 - Use GTK+ stock icons where available hplip-0.9.6-2 ------------- * Wed Oct 12 2005 Tim Waugh 0.9.6-2 - 0.9.6. ipsec-tools-0.6.1-1 ------------------- * Wed Oct 12 2005 Harald Hoyer 0.6.1-1 - version 0.6.1 jonas-0:4.3.3-1jpp_12fc ----------------------- * Tue Oct 11 2005 Gary Benson - 4.3.3-1jpp_12fc - Add java-gcj-compat dependency to examples subpackage. - Fix NullPointerException on jonasAdmin login page. - Reinstate the client jarfile (required for testsuite). kasumi-0.10-1.fc5 ----------------- * Thu Oct 13 2005 Akira TAGOH - 0.10-1 - New upstream release. * Tue Aug 16 2005 Akira TAGOH - 0.9-3 - Rebuild * Tue Aug 09 2005 Akira TAGOH - added dist tag in Release. kdelibs-6:3.4.91-2 ------------------ * Wed Oct 12 2005 Than Ngo 6:3.4.91-2 - add libacl-devel buildrequirement - add openoffice mimelnk files #121769 kdeutils-6:3.4.91-3 ------------------- * Wed Oct 12 2005 Than Ngo 6:3.4.91-3 - remove unneeded libacl-devel buildrequirement libjpeg-6b-36 ------------- * Wed Oct 12 2005 Matthias Clasen - 6b-36 - Don't ship static libraries * Sun Mar 06 2005 Matthias Clasen - 6b-35 - Remove .la files (#145971) libsemanage-1.3.11-1 -------------------- * Wed Oct 12 2005 Dan Walsh 1.3.11-1 - Update from NSA * Fixed semanage_install_active() to use the same logic for selecting a policy version as semanage_expand_sandbox(). Dropped dead code from semanage_install_sandbox(). * Mon Oct 10 2005 Dan Walsh 1.3.10-1 - Update from NSA * Updated for changes to libsepol, and to only use types and interfaces provided by the shared libsepol. libsepol-1.9.14.1-1 ------------------- * Mon Oct 10 2005 Dan Walsh 1.9.14.1-1 - Upgrade to latest from NSA * Fixed use of policydb_from_image/to_image to ensure proper init of policydb. * Isolated policydb internal headers under . These headers should only be used by users of the static libsepol. Created new with new public types and interfaces for shared libsepol. Created new with public types and interfaces moved or wrapped from old module.h, link.h, and expand.h, adjusted for new public types for policydb and policy_file. Added public interfaces to libsepol.map. Some implementation changes visible to users of the static libsepol: 1) policydb_read no longer calls policydb_init. Caller must do so first. 2) policydb_init no longer takes policy_type argument. Caller must set policy_type separately. 3) expand_module automatically enables the global branch. Caller no longer needs to do so. 4) policydb_write uses the policy_type and policyvers from the policydb itself, and sepol_set_policyvers() has been removed. * Fri Oct 07 2005 Dan Walsh 1.9.12-1 - Upgrade to latest from NSA * Merged function renaming and static cleanup from Ivan Gyurdiev. * Thu Oct 06 2005 Dan Walsh 1.9.11-1 - Upgrade to latest from NSA * Merged bug fix for check_assertions handling of no assertions from Joshua Brindle (Tresys). logrotate-3.7.2-6 ----------------- * Wed Oct 12 2005 Peter Vrabec 3.7.2-6 - code clean up (#169885) openssl-0.9.7f-10 ----------------- * Wed Oct 12 2005 Tomas Mraz 0.9.7f-10 - fix CAN-2005-2969 - remove SSL_OP_MSIE_SSLV2_RSA_PADDING which disables the countermeasure against man in the middle attack in SSLv2 (#169863) - use sha1 as default for CA and cert requests - CAN-2005-2946 (#169803) openssl097a-0.9.7a-4 -------------------- * Wed Oct 12 2005 Tomas Mraz 0.9.7a-4 - fix CAN-2005-2969 - remove SSL_OP_MSIE_SSLV2_RSA_PADDING which disables the countermeasure against man in the middle attack in SSLv2 (#169863) - more fixes for constant time/memory access for DSA signature algorithm - updated ICA engine patch policycoreutils-1.27.7-1 ------------------------ * Wed Oct 12 2005 Dan Walsh 1.27.7-1 - Update to match NSA * Updated semodule_link and semodule_expand to use shared libsepol. Fixed audit2why to call policydb_init prior to policydb_read (still uses the static libsepol). * Mon Oct 10 2005 Dan Walsh 1.27.6-1 - Update to match NSA * Updated for changes to libsepol. Changed semodule and semodule_package to use the shared libsepol. Disabled build of semodule_link and semodule_expand for now. Updated audit2why for relocated policydb internal headers, still needs to be converted to a shared lib interface. procinfo-18-18 -------------- * Wed Oct 12 2005 Karel Zak 18-18 - improve procinfo-18-ranges.patch * Wed Oct 12 2005 Karel Zak 18-17 - fix #170424 - procinfo crashing on X86_64 procps-3.2.5-8 -------------- * Wed Oct 12 2005 Karel Zak 3.2.5-8 - fix #170083 - Top showing bad cpu usage numbers redhat-artwork-0.129-1 ---------------------- * Wed Oct 12 2005 Matthias Clasen 0.129-1 - Fix text color in combo boxes. (#167086) rhpxl-0.4-1 ----------- * Wed Oct 12 2005 Chris Lumens 0.4-1 - Correct where we look for data files (#170505). - Translate in rhpxl domain instead of rhpl domain. - Correct __init__ to import everything. shared-mime-info-0.16-6 ----------------------- * Wed Oct 12 2005 Matthias Clasen - 0.16-6 - Add glade to defaults.list system-config-boot-0.2.10-1 --------------------------- * Thu Oct 13 2005 Harald Hoyer - 0.2.10-1 - use firstboot instead of deprecated functions in rhpl tomcat5-0:5.0.30-8jpp_4fc ------------------------- * Wed Oct 12 2005 Gary Benson 0:5.0.30-8jpp_4fc - Reenable build on ppc64 (#166657). valgrind-1:3.0.1-2 ------------------ * Thu Oct 13 2005 Jakub Jelinek 3.0.1-2 - remove Obsoletes for valgrind-callgrind, as it has been ported to valgrind 3.0.x already xterm-205-1 ----------- * Wed Oct 12 2005 Jason Vas Dias 205-1 - Upgrade to upstream version 205 fixes bugs: 124421, 129146, 159562, 161894, 169347 * Sat Sep 24 2005 Mike A. Harris 200-10 - Updated xterm-resources-redhat.patch to add "xterm*ttyModes: erase ^?" resource to fix bug (#155538,160354,163812,162549) From rdieter at math.unl.edu Thu Oct 13 11:58:20 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 13 Oct 2005 06:58:20 -0500 Subject: rawhide report: 20051013 changes In-Reply-To: <200510131113.j9DBDPek028350@porkchop.devel.redhat.com> References: <200510131113.j9DBDPek028350@porkchop.devel.redhat.com> Message-ID: <434E4BDC.6010807@math.unl.edu> Build System wrote: > kdelibs-6:3.4.91-2 > ------------------ > * Wed Oct 12 2005 Than Ngo 6:3.4.91-2 > - add libacl-devel buildrequirement "Just say no to libtool/BR bloat": (-: http://bugzilla.redhat.com/bugzilla/170602 -- Rex From smooge at gmail.com Thu Oct 13 16:49:27 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Thu, 13 Oct 2005 10:49:27 -0600 Subject: Bringing syslog-ng into the fold [FC6 ?] Message-ID: <80d7e4090510130949o8af851ag41721f2cb317b89@mail.gmail.com> One of the things we have to do at our sites is remove the Red Hat/Fedora syslog services and replace them with syslog-ng. The TCP part, the better message congestion issues, and the better ability to group logging together is really needed by larger sites. [We have found that the lossiness of regular syslog can get black marks on reviews.] A long time ago, it was proposed for inclusion around Red Hat Linux 6.0 but was considered too unstable and some other issues. Could it be evaluated again for either for replacing the older syslog system or working the syslog system so that alternatives could cover it with syslog-ng in extras? What issues would need to be done to help this along? Thanks. -- Stephen J Smoogen. CSIRT/Linux System Administrator From sundaram at redhat.com Thu Oct 13 17:05:58 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 13 Oct 2005 22:35:58 +0530 Subject: Bringing syslog-ng into the fold [FC6 ?] In-Reply-To: <80d7e4090510130949o8af851ag41721f2cb317b89@mail.gmail.com> References: <80d7e4090510130949o8af851ag41721f2cb317b89@mail.gmail.com> Message-ID: <434E93F6.9000007@redhat.com> Stephen J. Smoogen wrote: >One of the things we have to do at our sites is remove the Red >Hat/Fedora syslog services and replace them with syslog-ng. The TCP >part, the better message congestion issues, and the better ability to >group logging together is really needed by larger sites. [We have >found that the lossiness of regular syslog can get black marks on >reviews.] A long time ago, it was proposed for inclusion around Red >Hat Linux 6.0 but was considered too unstable and some other issues. > >Could it be evaluated again for either for replacing the older syslog >system or working the syslog system so that alternatives could cover >it with syslog-ng in extras? What issues would need to be done to help >this along? > If this is a straight foward decision, proposing that as a enhancement by filing it against 'distribution' as a component in Fedora bugzilla would be enough. regards Rahul From laroche at redhat.com Thu Oct 13 17:05:25 2005 From: laroche at redhat.com (Florian La Roche) Date: Thu, 13 Oct 2005 19:05:25 +0200 Subject: Bringing syslog-ng into the fold [FC6 ?] In-Reply-To: <80d7e4090510130949o8af851ag41721f2cb317b89@mail.gmail.com> References: <80d7e4090510130949o8af851ag41721f2cb317b89@mail.gmail.com> Message-ID: <20051013170525.GA2718@dudweiler.stuttgart.redhat.com> On Thu, Oct 13, 2005 at 10:49:27AM -0600, Stephen J. Smoogen wrote: > One of the things we have to do at our sites is remove the Red > Hat/Fedora syslog services and replace them with syslog-ng. The TCP > part, the better message congestion issues, and the better ability to > group logging together is really needed by larger sites. [We have > found that the lossiness of regular syslog can get black marks on > reviews.] A long time ago, it was proposed for inclusion around Red > Hat Linux 6.0 but was considered too unstable and some other issues. > > Could it be evaluated again for either for replacing the older syslog > system or working the syslog system so that alternatives could cover > it with syslog-ng in extras? What issues would need to be done to help > this along? Hello Stephen, syslog-ng has shown up in Fedora Extras, so testing out that package does certainly help. Given the long history of the current syslog package, I am not sure if/when a good point for that will come. greetings, Florian La Roche From skvidal at phy.duke.edu Thu Oct 13 17:11:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 13 Oct 2005 13:11:49 -0400 Subject: Bringing syslog-ng into the fold [FC6 ?] In-Reply-To: <20051013170525.GA2718@dudweiler.stuttgart.redhat.com> References: <80d7e4090510130949o8af851ag41721f2cb317b89@mail.gmail.com> <20051013170525.GA2718@dudweiler.stuttgart.redhat.com> Message-ID: <1129223509.26409.22.camel@cutter> On Thu, 2005-10-13 at 19:05 +0200, Florian La Roche wrote: > On Thu, Oct 13, 2005 at 10:49:27AM -0600, Stephen J. Smoogen wrote: > > One of the things we have to do at our sites is remove the Red > > Hat/Fedora syslog services and replace them with syslog-ng. The TCP > > part, the better message congestion issues, and the better ability to > > group logging together is really needed by larger sites. [We have > > found that the lossiness of regular syslog can get black marks on > > reviews.] A long time ago, it was proposed for inclusion around Red > > Hat Linux 6.0 but was considered too unstable and some other issues. > > > > Could it be evaluated again for either for replacing the older syslog > > system or working the syslog system so that alternatives could cover > > it with syslog-ng in extras? What issues would need to be done to help > > this along? > > Hello Stephen, > > syslog-ng has shown up in Fedora Extras, so testing out that package > does certainly help. Given the long history of the current syslog > package, I am not sure if/when a good point for that will come. > I think no time like the present. It's not like we have to maintain syslog compat b/t fc4 and fc5. -sv From smooge at gmail.com Thu Oct 13 17:22:33 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Thu, 13 Oct 2005 11:22:33 -0600 Subject: Bringing syslog-ng into the fold [FC6 ?] In-Reply-To: <20051013170525.GA2718@dudweiler.stuttgart.redhat.com> References: <80d7e4090510130949o8af851ag41721f2cb317b89@mail.gmail.com> <20051013170525.GA2718@dudweiler.stuttgart.redhat.com> Message-ID: <80d7e4090510131022w108e8f00vcdba8b4ca52d6fb1@mail.gmail.com> On 10/13/05, Florian La Roche wrote: > On Thu, Oct 13, 2005 at 10:49:27AM -0600, Stephen J. Smoogen wrote: > > One of the things we have to do at our sites is remove the Red > > Hat/Fedora syslog services and replace them with syslog-ng. The TCP > > part, the better message congestion issues, and the better ability to > > group logging together is really needed by larger sites. [We have > > found that the lossiness of regular syslog can get black marks on > > reviews.] A long time ago, it was proposed for inclusion around Red > > Hat Linux 6.0 but was considered too unstable and some other issues. > > > > Could it be evaluated again for either for replacing the older syslog > > system or working the syslog system so that alternatives could cover > > it with syslog-ng in extras? What issues would need to be done to help > > this along? > > Hello Stephen, > > syslog-ng has shown up in Fedora Extras, so testing out that package > does certainly help. Given the long history of the current syslog > package, I am not sure if/when a good point for that will come. > > greetings, > > Florian La Roche > Cool. I missed that package addition, and will go test it. We have found this really helps our FISMA requirements and may help organizations that need to document for HIPAA etc that they are indeed not losing data. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator From lamont at gurulabs.com Thu Oct 13 17:56:56 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 13 Oct 2005 11:56:56 -0600 Subject: Deprecating pam_stack.so In-Reply-To: <434DB238.1050002@develer.com> References: <1128690065.3156.29.camel@perun.redhat.usu> <1129107955.3158.6.camel@perun.redhat.usu> <434DB238.1050002@develer.com> Message-ID: <200510131157.01361.lamont@gurulabs.com> On Wednesday 12 October 2005 07:02pm, Bernardo Innocenti wrote: > Tomas Mraz wrote: [SNIP] > >> Also, you can login as root with root's password from ldap > >> even tough there's a valid root entry in /etc/passwd. > > > > That's expected as both pam_ldap and pam_unix are sufficient entries. > > If you want to prevent that you can insert pam_succeed_if > > Sorry, I don't quite understand how to set it up to reject uid == 0 > just for pam_ldap and not for pam_unix. The correct solution is simply this: DO NOT add root (uid == 0) authentication credentials in your central authentication stores. If you already have root credentials in there, GET THEM OUT OF THERE. root should only be able to authenticate locally on every single box. The security danger of not following this policy can be quite high. That said, it still might not be a bad idea to implement the extra config line that Tomas Mraz suggested, earlier...as an extra protection measure. The disadvantage of adding it is that you will have to do so on all systems you want to have connected to your central authentication store (LDAP, Kerberos, whatever). Perhaps it should be added to the default PAM configuration for FC5. I would vote for that. > I also don't understand what the "uid < 100" condition inserted > by system-config-auth is for. There are only two kinds of accounts as far as the kernel is concerned; root and everyone else. We humans think of it in terms of three kinds of accounts; "root" (superuser), "system" (not-superuser and no human being associated, typically, 0 < system account uid < 100) and "regular-user" (human being). Typically, one should not be able to login to "system" accounts. Occasionally, it is necessary to run a bunch of shell commands/scripts as a system account (installing some DB engines comes to mind), in which case root can "su - system-account" to do so. SELinux also helps with this "issue". [SNIP] > > This is a problem as the passphrases for ssh keys can be different from > > the user's system password. So the pam_ssh is definitely not a > > replacement for ssh-agent. > > Yes, we would need half of what pam_ssh does: instead of authenticating > the user against his ssh key, it should just load the key iff the > passphrase happens to match the account password. > > Maybe this other project would be more appropriate: > > http://sourceforge.net/projects/pam-ssh-agent/ > > PAM module that spawns a ssh-agent and adds identities using the > password supplied at login. I like this. It would be nice if FC5 would ship pam-ssh-agent. I'll vote for it :). -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tadams-lists at myrealbox.com Thu Oct 13 21:33:58 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Thu, 13 Oct 2005 15:33:58 -0600 Subject: avahi and howl Message-ID: <1129239238.2624.5.camel@aurora.localdomain> I was just reading up on gaim development. They are moving to avahi in place of howl. Debian is already doing or trying to do the same. It seems avahi does have some functionality enhancements over howl and license compability with more code (APSL vs. LGPL). It also supports reflections over lan segments. Is this something that RedHat/Fedora should follow Debian/Gaim on? Sorry if this is purely political. Thank you, Trever Adams From bojan at rexursive.com Fri Oct 14 11:09:00 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 14 Oct 2005 21:09:00 +1000 Subject: glibc/malloc_consolidate() Message-ID: <1129288140.20109.4.camel@coyote.rexursive.com> I have a feeling that recent versions of glibc in Rawhide have a problem related to this function. It seems to be overwriting allocated memory. Has anyone seen anything similar? -- Bojan From alan at redhat.com Thu Oct 13 21:53:47 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 13 Oct 2005 17:53:47 -0400 Subject: avahi and howl In-Reply-To: <1129239238.2624.5.camel@aurora.localdomain> References: <1129239238.2624.5.camel@aurora.localdomain> Message-ID: <20051013215347.GC16732@devserv.devel.redhat.com> On Thu, Oct 13, 2005 at 03:33:58PM -0600, Trever L. Adams wrote: > Is this something that RedHat/Fedora should follow Debian/Gaim on? > Sorry if this is purely political. I'd rather we pushed Gaim into extras. Unfortunately however there seem to be a lack of secure sane im clients From jspaleta at gmail.com Thu Oct 13 23:39:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 13 Oct 2005 19:39:09 -0400 Subject: avahi and howl In-Reply-To: <1129239238.2624.5.camel@aurora.localdomain> References: <1129239238.2624.5.camel@aurora.localdomain> Message-ID: <604aa7910510131639p31bc00ddgdd32583dc1843b12@mail.gmail.com> On 10/13/05, Trever L. Adams wrote: > Is this something that RedHat/Fedora should follow Debian/Gaim on? As soon as programs in Core require it I'm sure that its going to get sucked in to Core. The more important question is... now that gaim is going to use avahi... what else in Fedora Core requires howl..and can those other items be made to use avahi as well? It would be best if howl could be replaced completely in Core with avahi to avoid duplication of functionality with multuple implementations. rawhide>repoquery --whatrequires libhowl.so.0 gnome-games-1:2.12.1-1.i386 in Core gnomemeeting-0:1.2.2-2.i386 in Core gnome-vfs2-0:2.12.1.1-1.i386 in Core obby-0:0.2.0-5.fc5.i386 in Extras -jef From pbrobinson at gmail.com Thu Oct 13 21:59:16 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 13 Oct 2005 22:59:16 +0100 Subject: avahi and howl In-Reply-To: <1129239238.2624.5.camel@aurora.localdomain> References: <1129239238.2624.5.camel@aurora.localdomain> Message-ID: <5256d0b0510131459g4dc535g2c01dd5547ef621@mail.gmail.com> On 10/13/05, Trever L. Adams wrote: > I was just reading up on gaim development. They are moving to avahi in > place of howl. Debian is already doing or trying to do the same. It > seems avahi does have some functionality enhancements over howl and > license compability with more code (APSL vs. LGPL). It also supports > reflections over lan segments. > > Is this something that RedHat/Fedora should follow Debian/Gaim on? Its not just debian/gaim, a lot of projects are adding support for avahi (as well as howl), rhythmnbox and I think gnomemeeting support both, and the license is aimed for better suport. Pete From wrrhdev at riede.org Thu Oct 13 22:33:41 2005 From: wrrhdev at riede.org (Willem Riede) Date: Thu, 13 Oct 2005 22:33:41 +0000 Subject: rawhide report: 20051013 changes In-Reply-To: <200510131113.j9DBDPek028350@porkchop.devel.redhat.com> (from buildsys@redhat.com on Thu Oct 13 07:13:25 2005) References: <200510131113.j9DBDPek028350@porkchop.devel.redhat.com> Message-ID: <1129242821l.32027l.9l@serve.riede.org> On 10/13/2005 07:13:25 AM, Build System wrote: > > anaconda-10.3.0.31-1 > -------------------- > * Wed Oct 12 2005 Jeremy Katz - 10.3.0.31-1 Today (x86_64) I got as far as: Starting graphical installation... Traceback (most recent call last): File "/usr/bin/anaconda", line 1066, in ? from yuminstall import YumBackend File "/usr/lib/anaconda/yuminstall.py", line 27, in ? from yum.errors import RepoError ImportError: No module named errors install exited abnormally .... Anyone else see this? Willem Riede. From buildsys at redhat.com Fri Oct 14 11:20:27 2005 From: buildsys at redhat.com (Build System) Date: Fri, 14 Oct 2005 07:20:27 -0400 Subject: rawhide report: 20051014 changes Message-ID: <200510141120.j9EBKRx1017348@porkchop.devel.redhat.com> Updated Packages: busybox-1:1.01-2 ---------------- * Thu Oct 13 2005 Daniel Walsh - 1.01-2 - Add sepol for linking load_policy cryptsetup-luks-1.0.1-3 ----------------------- device-mapper-1.01.05-2.0 ------------------------- * Thu Oct 13 2005 Florian La Roche - add linking against -lsepol gaim-1:1.5.0-7.fc5 ------------------ * Thu Oct 13 2005 Ray Strode - 1:1.5.0-7.fc5 - use upstream desktop file (except use generic name, because this is our default instant messaging client) gnopernicus-0.12.0-2 -------------------- * Thu Oct 13 2005 Matthias Clasen 0.12.0-2 - Don't require libglade-devel jonas-0:4.3.3-1jpp_13fc ----------------------- * Thu Oct 13 2005 Gary Benson - 4.3.3-1jpp_13fc - Build the testsuite. * Wed Oct 12 2005 Gary Benson - 4.3.3-1jpp_12fc - Add java-gcj-compat dependency to examples subpackage. - Fix NullPointerException on jonasAdmin login page. - Reinstate the client jarfile (required for testsuite). * Wed Sep 21 2005 Gary Benson - 4.3.3-1jpp_11fc - Build with fixed aot-compile-rpm. kernel-2.6.13-1.1603_FC5 ------------------------ * Thu Oct 13 2005 Dave Jones - 2.6.14-rc4-git2 * Wed Oct 12 2005 Dave Jones - 2.6.14-rc4-git1 libselinux-1.27.7-2 ------------------- logwatch-7.0-1 -------------- * Thu Oct 13 2005 Ivana Varekova 7.0-1 - update to 7.0 (new directory structure) - add smartd and zz-disk_space patch netatalk-4:2.0.3-3 ------------------ * Thu Oct 13 2005 Tomas Mraz - use include instead of pam_stack in pam config openssh-4.2p1-3 --------------- * Thu Oct 13 2005 Tomas Mraz 4.2p1-3 - Update selinux patch to use getseuserbyname pam-0.80-10 ----------- * Thu Oct 13 2005 Dan Walsh 0.80-11 - Add getseuserbyname call for SELinux MCS/MLS policy * Tue Oct 04 2005 Tomas Mraz - pam_console manpage fixes (#169373) * Fri Sep 30 2005 Tomas Mraz 0.80-9 - don't include ps and pdf docs (#168823) - new common config file for configuration utilities - remove glib2 dependency (#166979) policycoreutils-1.27.7-2 ------------------------ * Thu Oct 13 2005 Dan Walsh 1.27.7-2 - Fix run_init.pamd and spec file pykickstart-0.3-2 ----------------- * Thu Oct 13 2005 Chris Lumens 0.3-2 - Correct python lib directory on 64-bit archs (#170621). qt-1:3.3.5-5 ------------ * Thu Oct 13 2005 Than Ngo 1:3.3.5-5 - update qt-x11-immodule-unified-qt3.3.5-20051012 - disable some debug messages - apply patch to fix build problem with the new immodule patch * Tue Sep 27 2005 Than Ngo 1:3.3.5-4 - apply patch to fix gcc warnings rhpxl-0.4-2 ----------- * Thu Oct 13 2005 Chris Lumens 0.4-2 - Correct python lib directory on 64-bit archs (#170624). rsh-0.17-30 ----------- * Thu Oct 13 2005 Karel Zak 0.17-30 - replace pam_stack with "include" selinux-policy-strict-1.27.1-17 ------------------------------- * Thu Oct 13 2005 Dan Walsh 1.27.1-17 - Fix protections on seusers - Add disable_postfix_trans boolean * Thu Oct 13 2005 Dan Walsh 1.27.1-16 - Apply Russells fixes selinux-policy-targeted-1.27.1-17 --------------------------------- * Thu Oct 13 2005 Dan Walsh 1.27.1-17 - Fix protections on seusers - Add disable_postfix_trans boolean * Thu Oct 13 2005 Dan Walsh 1.27.1-16 - Apply Russells fixes squid-7:2.5.STABLE11-3 ---------------------- * Thu Oct 13 2005 Tomas Mraz 7:2.5.STABLE11-3 - use include instead of pam_stack in pam config sudo-1.6.8p9-6 -------------- * Thu Oct 13 2005 Tomas Mraz 1.6.8p9-6 - use include instead of pam_stack in pam config system-config-boot-0.2.11-1 --------------------------- * Thu Oct 13 2005 Harald Hoyer - 0.2.11-1 - use new config tool pam configuration file system-config-nfs-1.3.13-1 -------------------------- * Thu Oct 13 2005 Nils Philippsen 1.3.13 - include missing files (spotted by Bernardo Innocenti), remove unneeded test and sample files - don't remove byte-compiled files anymore vixie-cron-4:4.1-38.FC5 ----------------------- * Thu Oct 13 2005 Tomas Mraz - 4.1-38.FC5 - use include instead of pam_stack in pam config * Sat Aug 13 2005 Dan Walsh - 4.1-37.FC5 - Change checkPasswdAccess to selinux_check_passwd_access for new selinux api vlock-1.3-21 ------------ * Thu Oct 13 2005 Karel Zak 1.3-21 - replace pam_stack with "include" xpdf-1:3.01-3 ------------- * Thu Oct 13 2005 Matthias Clasen 3.01-3 - don't use freetype internals xscreensaver-1:4.22-19 ---------------------- * Thu Oct 13 2005 Tomas Mraz 1:4.22-19 - use include instead of pam_stack in pam config From patmans at us.ibm.com Fri Oct 14 17:47:26 2005 From: patmans at us.ibm.com (Patrick Mansfield) Date: Fri, 14 Oct 2005 10:47:26 -0700 Subject: rawhide report: 20051013 changes In-Reply-To: <1129242821l.32027l.9l@serve.riede.org> References: <200510131113.j9DBDPek028350@porkchop.devel.redhat.com> <1129242821l.32027l.9l@serve.riede.org> Message-ID: <20051014174726.GA29883@us.ibm.com> On Thu, Oct 13, 2005 at 10:33:41PM +0000, Willem Riede wrote: > On 10/13/2005 07:13:25 AM, Build System wrote: > > > >anaconda-10.3.0.31-1 > >-------------------- > >* Wed Oct 12 2005 Jeremy Katz - 10.3.0.31-1 > > Today (x86_64) I got as far as: > > Starting graphical installation... > Traceback (most recent call last): > File "/usr/bin/anaconda", line 1066, in ? > from yuminstall import YumBackend > File "/usr/lib/anaconda/yuminstall.py", line 27, in ? > from yum.errors import RepoError > ImportError: No module named errors > install exited abnormally > .... > > Anyone else see this? Willem Riede. Yes, I hit that yesterday. I did a yum update to get to rawhide, but I was trying to work on some anaconda install changes, that is hard to do if I can't install :) I'm new to rawhide i.e. I'm not sure where to report failures. I haven't been able to install rawhide yet (AFAIR 3 different failures on three different days). -- Patrick Mansfield From sundaram at redhat.com Fri Oct 14 17:54:27 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 14 Oct 2005 23:24:27 +0530 Subject: rawhide report: 20051013 changes In-Reply-To: <20051014174726.GA29883@us.ibm.com> References: <200510131113.j9DBDPek028350@porkchop.devel.redhat.com> <1129242821l.32027l.9l@serve.riede.org> <20051014174726.GA29883@us.ibm.com> Message-ID: <434FF0D3.7090403@redhat.com> Hi >I'm new to rawhide i.e. I'm not sure where to report failures. I haven't >been able to install rawhide yet (AFAIR 3 different failures on three >different days). > > You can report them in bugzilla against the appropriate component against Fedora development branch. http://fedoraproject.org/wiki/ReportingBugs. If it required discussions, post to the fedora-test or this list. http://fedoraproject.org/wiki/Communicate regards Rahul From sopwith at redhat.com Fri Oct 14 18:08:55 2005 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 14 Oct 2005 14:08:55 -0400 (EDT) Subject: Bringing syslog-ng into the fold [FC6 ?] In-Reply-To: <80d7e4090510130949o8af851ag41721f2cb317b89@mail.gmail.com> References: <80d7e4090510130949o8af851ag41721f2cb317b89@mail.gmail.com> Message-ID: On Thu, 13 Oct 2005, Stephen J. Smoogen wrote: > One of the things we have to do at our sites is remove the Red > Hat/Fedora syslog services and replace them with syslog-ng. The TCP > part, the better message congestion issues, and the better ability to > group logging together is really needed by larger sites. [We have > found that the lossiness of regular syslog can get black marks on > reviews.] A long time ago, it was proposed for inclusion around Red > Hat Linux 6.0 but was considered too unstable and some other issues. > > Could it be evaluated again for either for replacing the older syslog > system or working the syslog system so that alternatives could cover > it with syslog-ng in extras? What issues would need to be done to help > this along? There are enough syslog replacement wannabees out there that this isn't a slam-dunk decision. Because the client-side interface is built into glibc, so many apps use the syslog interface that just putting syslog-ng into the distro won't accomplish much for admins. (For syslog-ng in particular, I seem to recall when I looked at it that it avoided making radical-but-necessary improvements for the sake of compatibility, which makes it sound a bit like subversion to me.) I think someone needs to evaluate the millions of syslog replacements out there, pick the best one overall, and get the client-side API for that into glibc. Then it'll just be a matter of starting to convert apps from the old API to the new one. Best, -- Elliot From skvidal at phy.duke.edu Fri Oct 14 18:17:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 14 Oct 2005 14:17:06 -0400 Subject: Bringing syslog-ng into the fold [FC6 ?] In-Reply-To: References: <80d7e4090510130949o8af851ag41721f2cb317b89@mail.gmail.com> Message-ID: <1129313826.32350.28.camel@cutter> On Fri, 2005-10-14 at 14:08 -0400, Elliot Lee wrote: > On Thu, 13 Oct 2005, Stephen J. Smoogen wrote: > > > One of the things we have to do at our sites is remove the Red > > Hat/Fedora syslog services and replace them with syslog-ng. The TCP > > part, the better message congestion issues, and the better ability to > > group logging together is really needed by larger sites. [We have > > found that the lossiness of regular syslog can get black marks on > > reviews.] A long time ago, it was proposed for inclusion around Red > > Hat Linux 6.0 but was considered too unstable and some other issues. > > > > Could it be evaluated again for either for replacing the older syslog > > system or working the syslog system so that alternatives could cover > > it with syslog-ng in extras? What issues would need to be done to help > > this along? > > There are enough syslog replacement wannabees out there that this isn't a > slam-dunk decision. Because the client-side interface is built into glibc, > so many apps use the syslog interface that just putting syslog-ng into the > distro won't accomplish much for admins. > > (For syslog-ng in particular, I seem to recall when I looked at it that it > avoided making radical-but-necessary improvements for the sake of > compatibility, which makes it sound a bit like subversion to me.) > > I think someone needs to evaluate the millions of syslog replacements out > there, pick the best one overall, and get the client-side API for that > into glibc. Then it'll just be a matter of starting to convert apps from > the old API to the new one. > okay I'm confused. Why isn't using syslog-ng a slam-dunk. 1. we don't break compatibility for the api - which means not modifying lots of difficult programs 2. it makes it easier for this to trickle into rhel 3. it's a known value in that it's used in large-scale and small-scale operations all over the place. 4. it's an immediate win over syslog in that it is: a. more feature-full b. actually maintained -sv From sopwith at redhat.com Fri Oct 14 18:23:34 2005 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 14 Oct 2005 14:23:34 -0400 (EDT) Subject: Bringing syslog-ng into the fold [FC6 ?] Message-ID: On Fri, 2005-10-14 Seth Vidal wrote: > okay I'm confused. Why isn't using syslog-ng a slam-dunk. > > 1. we don't break compatibility for the api - which means not modifying > lots of difficult programs > 2. it makes it easier for this to trickle into rhel > 3. it's a known value in that it's used in large-scale and small-scale > operations all over the place. > 4. it's an immediate win over syslog in that it is: > a. more feature-full > b. actually maintained Because syslog-ng isn't the Right Solution(tm) for the general problem of event logging. For example, not breaking the API means there is no way to log anything more structured than a text string, which makes analyzing the logged events a lot more difficult. My thinking was that if we're going to switch, let's switch to the Right Solution(tm). Of course, the Right Solution(tm) may not exist or be usable at this point. If syslog-ng is a drop-in replacement for the present syslogd (including configuration files and applications), then you're right and I'm being a stick in the mind. :) However, having to do a migration to syslog-ng that is not pain-free for sysadmins might not make sense if something even better is be out there. Best, -- Elliot From dimi at lattica.com Fri Oct 14 18:55:30 2005 From: dimi at lattica.com (Dimi Paun) Date: Fri, 14 Oct 2005 14:55:30 -0400 Subject: Bringing syslog-ng into the fold [FC6 ?] References: Message-ID: <00d401c5d0f0$d96f0fb0$b6491b31@td612671> From: "Elliot Lee" > Because syslog-ng isn't the Right Solution(tm) for the general problem of > event logging. Also breaking binary compatibility for the sake of the Right Solution (TM) might not be the best strategy in the world. > For example, not breaking the API means there is no way to > log anything more structured than a text string, which makes analyzing the > logged events a lot more difficult. It's not even clear that doing something more structured is such a good idea to begin with. Modern efforts at logging APIs (log4j, Java Logger, etc.) still do text only to this day, and that's fine. This sounds to me as a case where incremental improvement is held back for the sake of the Perfect Solution which, on second thought, is not even clear that is that desirable :) -- Dimi Paun Lattica, Inc. From sundaram at redhat.com Fri Oct 14 19:05:56 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 15 Oct 2005 00:35:56 +0530 Subject: Bringing syslog-ng into the fold [FC6 ?] In-Reply-To: <00d401c5d0f0$d96f0fb0$b6491b31@td612671> References: <00d401c5d0f0$d96f0fb0$b6491b31@td612671> Message-ID: <43500194.5020202@redhat.com> Dimi Paun wrote: >From: "Elliot Lee" > > >>Because syslog-ng isn't the Right Solution(tm) for the general problem of >>event logging. >> >> > >Also breaking binary compatibility for the sake of the Right Solution (TM) >might not be the best strategy in the world. > > > If glibc continues to support but deprecate the older syslog API along with the Right Solution(TM) API then there is no need to break binary compatibility for as long as time period deemed convenient. >This sounds to me as a case where incremental improvement is held >back for the sake of the Perfect Solution which, on second thought, >is not even clear that is that desirable :) > > > Agreed on that though. Taking Elliot's cvs analogy further, subversion might be better than bazaar-ng atleast for now. regards Rahul From dimi at lattica.com Fri Oct 14 19:11:33 2005 From: dimi at lattica.com (Dimi Paun) Date: Fri, 14 Oct 2005 15:11:33 -0400 Subject: Bringing syslog-ng into the fold [FC6 ?] References: <00d401c5d0f0$d96f0fb0$b6491b31@td612671> <43500194.5020202@redhat.com> Message-ID: <00e801c5d0f3$178e9de0$b6491b31@td612671> From: "Rahul Sundaram" > If glibc continues to support but deprecate the older syslog API along > with the Right Solution(TM) API then there is no need to break binary > compatibility for as long as time period deemed convenient. Absolutely. In fact, I can't see why we would ever have to break it. Any replacement of syslog should be at least be as capable as the current one, so the old API should be easily implemented on top of the new one. -- Dimi Paun Lattica, Inc. From sundaram at redhat.com Fri Oct 14 19:20:08 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 15 Oct 2005 00:50:08 +0530 Subject: Bringing syslog-ng into the fold [FC6 ?] In-Reply-To: <00e801c5d0f3$178e9de0$b6491b31@td612671> References: <00d401c5d0f0$d96f0fb0$b6491b31@td612671> <43500194.5020202@redhat.com> <00e801c5d0f3$178e9de0$b6491b31@td612671> Message-ID: <435004E8.3090508@redhat.com> Dimi Paun wrote: >From: "Rahul Sundaram" > > >>If glibc continues to support but deprecate the older syslog API along >>with the Right Solution(TM) API then there is no need to break binary >>compatibility for as long as time period deemed convenient. API to provide functionality improvements >> >> > >Absolutely. In fact, I can't see why we would ever have to break it. >Any replacement of syslog should be at least be as capable as the >current one, so the old API should be easily implemented on top of >the new one. > > > Generally thats the procedure but sometimes the older API might be brain dead and one cannot sanely extend it or build on top of it. So deprecating the older API and creating a new one is an option to retain binary compatibility. Pre GTK 2.6 file dialog API vs the newer one is a example of the latter. regards Rahul From philipp_subx at redfish-solutions.com Fri Oct 14 22:01:55 2005 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 14 Oct 2005 16:01:55 -0600 Subject: Supporting XvMC (and XvMCW) Message-ID: <43502AD3.7060701@redfish-solutions.com> Apologies if this has already been discussed and I missed it... I've only been on the list a couple of months... and a quick search of old messages didn't turn anything up. Could the X driver installation process write out the contents of /etc/X11/XvMCConfig based on the driver module that has been selected for the xorg.conf file? For instance, if you've selected the via drivers (in xorg 6.8.99.900 and later, for instance), then /etc/X11/XvMCConfig should contain: libviaXvMC.so or: libviaXvMCPro.so If you're using the NVidia drivers (from NVidia, and not the GPL "nv" drivers instead) you'd have: libXVMCNVIDIA.so for instance. Other cards might not offer support. I believe the Savage cards do. Does this sound feasible? -Philip From notting at redhat.com Fri Oct 14 23:14:10 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 14 Oct 2005 19:14:10 -0400 Subject: Supporting XvMC (and XvMCW) In-Reply-To: <43502AD3.7060701@redfish-solutions.com> References: <43502AD3.7060701@redfish-solutions.com> Message-ID: <20051014231410.GC12977@devserv.devel.redhat.com> Philip Prindeville (philipp_subx at redfish-solutions.com) said: > Apologies if this has already been discussed and I missed it... I've > only been on the list a couple of months... and a quick search of > old messages didn't turn anything up. > > Could the X driver installation process write out the contents of > /etc/X11/XvMCConfig based on the driver module that has > been selected for the xorg.conf file? > > For instance, if you've selected the via drivers (in xorg 6.8.99.900 > and later, for instance), then /etc/X11/XvMCConfig should contain: > > libviaXvMC.so > > or: > > libviaXvMCPro.so > > If you're using the NVidia drivers (from NVidia, and not the GPL "nv" > drivers instead) you'd have: > > libXVMCNVIDIA.so > > for instance. Other cards might not offer support. I believe the Savage > cards do. > > Does this sound feasible? It sounds like dumb code. The driver already, from what you've posted, knows what the name of the module it uses is. So why on earth does it need a config file? Bill From bernie at develer.com Sat Oct 15 00:05:58 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Sat, 15 Oct 2005 02:05:58 +0200 Subject: Deprecating pam_stack.so In-Reply-To: <200510131157.01361.lamont@gurulabs.com> References: <1128690065.3156.29.camel@perun.redhat.usu> <1129107955.3158.6.camel@perun.redhat.usu> <434DB238.1050002@develer.com> <200510131157.01361.lamont@gurulabs.com> Message-ID: <435047E6.2030407@develer.com> Lamont R. Peterson wrote: > The correct solution is simply this: DO NOT add root (uid == 0) authentication > credentials in your central authentication stores. If you already have root > credentials in there, GET THEM OUT OF THERE. root should only be able to > authenticate locally on every single box. The security danger of not > following this policy can be quite high. I agree, but I think the correct solution is getting the clients not to trust their LDAP server when authenticating uid=0. Just removing root from the directory isn't going to make clients more secure. IP spoofing and other tricks can be used to fake another LDAP server with a root account. Of course you may be using TLS and install SSL certificates on every clients, but I doubt any busy system administrator would go this far to protect *clients* on the LAN. > That said, it still might not be a bad idea to implement the extra config line > that Tomas Mraz suggested, earlier...as an extra protection measure. The > disadvantage of adding it is that you will have to do so on all systems you > want to have connected to your central authentication store (LDAP, Kerberos, > whatever). > > Perhaps it should be added to the default PAM configuration for FC5. I would > vote for that. I'd vote for that too. >> Maybe this other project would be more appropriate: >> >> http://sourceforge.net/projects/pam-ssh-agent/ >> >> PAM module that spawns a ssh-agent and adds identities using the >> password supplied at login. > > I like this. It would be nice if FC5 would ship pam-ssh-agent. I'll vote for > it :). Good. Who should we bug to get it into FC5? :-) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From smooge at gmail.com Sat Oct 15 00:17:41 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 14 Oct 2005 18:17:41 -0600 Subject: Bringing syslog-ng into the fold [FC6 ?] In-Reply-To: <435004E8.3090508@redhat.com> References: <00d401c5d0f0$d96f0fb0$b6491b31@td612671> <43500194.5020202@redhat.com> <00e801c5d0f3$178e9de0$b6491b31@td612671> <435004E8.3090508@redhat.com> Message-ID: <80d7e4090510141717q6db45843qb2d43861d1484ee9@mail.gmail.com> Well to be honest.. I have only used syslog-ng over any of the replacements out there. I found a webpage listing the replacements: http://www.loganalysis.org/sections/syslog/syslog-replacements/ Please correct me if I am wrong, but there are 3 parts to what Sopwith is asking: 1) Better API? [This would seem to require changes in LOTS of applications, glibc, and kernel to deal with this better API.] From my readings in the last month on this.. I dont think any of the syslog authors would say that the current API couldnt use a complete overhaul. 2) Able to replace what is currently there. 3) Able to handle the increased loads that people are wanting... I am guessing that the current tools need a testing to see what would meet those needs. -- Stephen J Smoogen. CSIRT/Linux System Administrator From philipp_subx at redfish-solutions.com Sat Oct 15 00:38:02 2005 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 14 Oct 2005 18:38:02 -0600 Subject: Supporting XvMC (and XvMCW) In-Reply-To: <20051014231410.GC12977@devserv.devel.redhat.com> References: <43502AD3.7060701@redfish-solutions.com> <20051014231410.GC12977@devserv.devel.redhat.com> Message-ID: <43504F6A.2090602@redfish-solutions.com> Bill Nottingham wrote: >Philip Prindeville (philipp_subx at redfish-solutions.com) said: > > >>Apologies if this has already been discussed and I missed it... I've >>only been on the list a couple of months... and a quick search of >>old messages didn't turn anything up. >> >>Could the X driver installation process write out the contents of >>/etc/X11/XvMCConfig based on the driver module that has >>been selected for the xorg.conf file? >> >>For instance, if you've selected the via drivers (in xorg 6.8.99.900 >>and later, for instance), then /etc/X11/XvMCConfig should contain: >> >>libviaXvMC.so >> >>or: >> >>libviaXvMCPro.so >> >>If you're using the NVidia drivers (from NVidia, and not the GPL "nv" >>drivers instead) you'd have: >> >>libXVMCNVIDIA.so >> >>for instance. Other cards might not offer support. I believe the Savage >>cards do. >> >>Does this sound feasible? >> >> > >It sounds like dumb code. The driver already, from what you've posted, >knows what the name of the module it uses is. So why on earth does it >need a config file? > >Bill > > > Because the client isn't statically linked to the library, and needs to discover it dynamically at run-time. A lot of X libraries contain both client-side and server-side functions. -Philip From nmiell at comcast.net Sat Oct 15 02:48:59 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Fri, 14 Oct 2005 19:48:59 -0700 Subject: Supporting XvMC (and XvMCW) In-Reply-To: <43504F6A.2090602@redfish-solutions.com> References: <43502AD3.7060701@redfish-solutions.com> <20051014231410.GC12977@devserv.devel.redhat.com> <43504F6A.2090602@redfish-solutions.com> Message-ID: <1129344539.2777.1.camel@entropy> On Fri, 2005-10-14 at 18:38 -0600, Philip Prindeville wrote: > Bill Nottingham wrote: > > >Philip Prindeville (philipp_subx at redfish-solutions.com) said: > > > > > >>Apologies if this has already been discussed and I missed it... I've > >>only been on the list a couple of months... and a quick search of > >>old messages didn't turn anything up. > >> > >>Could the X driver installation process write out the contents of > >>/etc/X11/XvMCConfig based on the driver module that has > >>been selected for the xorg.conf file? > >> > >>For instance, if you've selected the via drivers (in xorg 6.8.99.900 > >>and later, for instance), then /etc/X11/XvMCConfig should contain: > >> > >>libviaXvMC.so > >> > >>or: > >> > >>libviaXvMCPro.so > >> > >>If you're using the NVidia drivers (from NVidia, and not the GPL "nv" > >>drivers instead) you'd have: > >> > >>libXVMCNVIDIA.so > >> > >>for instance. Other cards might not offer support. I believe the Savage > >>cards do. > >> > >>Does this sound feasible? > > > >It sounds like dumb code. The driver already, from what you've posted, > >knows what the name of the module it uses is. So why on earth does it > >need a config file? > > > Because the client isn't statically linked to the library, and needs to > discover it dynamically at run-time. > > A lot of X libraries contain both client-side and server-side functions. > libGL.so solved the exact same problem without resorting to a config file. Perhaps you should file a bug in Xorg's bugzilla. -- Nicholas Miell From sundaram at redhat.com Sat Oct 15 03:27:37 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 15 Oct 2005 08:57:37 +0530 Subject: avahi and howl In-Reply-To: <20051013215347.GC16732@devserv.devel.redhat.com> References: <1129239238.2624.5.camel@aurora.localdomain> <20051013215347.GC16732@devserv.devel.redhat.com> Message-ID: <43507729.40003@redhat.com> Alan Cox wrote: >On Thu, Oct 13, 2005 at 03:33:58PM -0600, Trever L. Adams wrote: > > >>Is this something that RedHat/Fedora should follow Debian/Gaim on? >>Sorry if this is purely political. >> >> > >I'd rather we pushed Gaim into extras. Unfortunately however there seem >to be a lack of secure sane im clients > > > That would only work if Gaim was the only thing using howl in Fedora Core but there seems be a general trend towards moving away from howl to avahi or providing it as a alternative with a abstraction layer in several upstream projects and while we are talking about gaim, its worth point out that Google has hired the lead Gaim developer to work on Google Talk. Hopefully that has some positive effects on Gaim too. http://www.devxnews.com/article.php/3556506 regards Rahul From tadams-lists at myrealbox.com Sat Oct 15 07:40:06 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Sat, 15 Oct 2005 01:40:06 -0600 Subject: avahi and howl In-Reply-To: <43507729.40003@redhat.com> References: <1129239238.2624.5.camel@aurora.localdomain> <20051013215347.GC16732@devserv.devel.redhat.com> <43507729.40003@redhat.com> Message-ID: <1129362006.2791.1.camel@aurora.localdomain> On Sat, 2005-10-15 at 08:57 +0530, Rahul Sundaram wrote: > That would only work if Gaim was the only thing using howl in Fedora > Core but there seems be a general trend towards moving away from howl to > avahi or providing it as a alternative with a abstraction layer in > several upstream projects and while we are talking about gaim, its worth > point out that Google has hired the lead Gaim developer to work on > Google Talk. Hopefully that has some positive effects on Gaim too. > > http://www.devxnews.com/article.php/3556506 > > regards > Rahul > This is actually what started this thread. The gaim site seems to suggest that voice chat will be added and will work with Google Talk. Rumors at this point, even if they are from the development team (though they seem to make good on most of it). Trever -- "But these [serious NT security flaws] are not inherent flaws in the operating system -- they don't happen by accident. They are the result of deliberate and well-thought-out efforts." -- Mike Nash, Microsoft. The _flaws_ are deliberate? From pbrobinson at gmail.com Sat Oct 15 10:10:26 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 15 Oct 2005 11:10:26 +0100 Subject: avahi and howl In-Reply-To: <604aa7910510131639p31bc00ddgdd32583dc1843b12@mail.gmail.com> References: <1129239238.2624.5.camel@aurora.localdomain> <604aa7910510131639p31bc00ddgdd32583dc1843b12@mail.gmail.com> Message-ID: <5256d0b0510150310j2c612a8cxd0fe6e358fb57839@mail.gmail.com> > The more important question is... now that gaim is going to use > avahi... what else in Fedora Core requires howl..and can those other > items be made to use avahi as well? > It would be best if howl could be replaced completely in Core with > avahi to avoid duplication of functionality with multuple > implementations. > > rawhide>repoquery --whatrequires libhowl.so.0 > gnome-games-1:2.12.1-1.i386 in Core > gnomemeeting-0:1.2.2-2.i386 in Core > gnome-vfs2-0:2.12.1.1-1.i386 in Core > obby-0:0.2.0-5.fc5.i386 in Extras I'm pretty sure gnomemeeting now supports both (well it will in 2.0) and rhythmbox now has a dependancy but supports both too. From pbrobinson at gmail.com Sat Oct 15 10:14:20 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 15 Oct 2005 11:14:20 +0100 Subject: avahi and howl In-Reply-To: <1129362006.2791.1.camel@aurora.localdomain> References: <1129239238.2624.5.camel@aurora.localdomain> <20051013215347.GC16732@devserv.devel.redhat.com> <43507729.40003@redhat.com> <1129362006.2791.1.camel@aurora.localdomain> Message-ID: <5256d0b0510150314xc599444x4c5e416fb9f384d7@mail.gmail.com> > This is actually what started this thread. The gaim site seems to > suggest that voice chat will be added and will work with Google Talk. > > Rumors at this point, even if they are from the development team (though > they seem to make good on most of it). Not really rumours. To quote straight off the front of gaim's website 'On a related note, the gaim-vv project?which aimed to offer a framework for voice and video support in Gaim?is being merged back into Gaim proper for hopeful incorporation into Gaim 2.0.0. This will be used to support Google Talk's voice as well as MSN and Yahoo! webcams' - Check the full news entry out at http://gaim.sf.net Pete From buildsys at redhat.com Sat Oct 15 11:14:06 2005 From: buildsys at redhat.com (Build System) Date: Sat, 15 Oct 2005 07:14:06 -0400 Subject: rawhide report: 20051015 changes Message-ID: <200510151114.j9FBE6iR012641@porkchop.devel.redhat.com> Updated Packages: SysVinit-2.85-41 ---------------- * Fri Oct 14 2005 Dan Walsh - 2.85-41 - replace load_policy with selinux_init_load_policy - add getseuserbyname to sulogin anaconda-10.3.0.32-1 -------------------- * Fri Oct 14 2005 Jeremy Katz - 10.3.0.32-1 - fix typo causing traceback (pnasrat) - Create character device nodes to fix synaptics (clumens) anthy-7015-1 ------------ * Fri Oct 14 2005 Akira TAGOH - 7015-1 - New upstream snapshot release. authconfig-5.0.2-1 ------------------ * Fri Oct 14 2005 Tomas Mraz - 5.0.2-1 - authinfo-tui.py is now symlink - reword the CA certificate message (#154317) - use include instead of pam_stack in pam config - don't break yp.conf with multiple domains (#127306) bison-2.1-1 ----------- * Fri Oct 14 2005 Roland McGrath - 2.1-1 - New upstream version 2.1 - New subpackage bison-runtime for i18n support files used by parsers. checkpolicy-1.27.9-1 -------------------- * Fri Oct 14 2005 Dan Walsh 1.27.9-1 - Latest upgrade from NSA * Merged support for require blocks inside conditionals from Joshua Brindle (Tresys). gdm-1:2.8.0.4-4 --------------- * Thu Oct 13 2005 Dan Walsh 1:2.8.0.4-4 - Change to use getseuserbyname hplip-0.9.6-3 ------------- * Fri Oct 14 2005 Tim Waugh 0.9.6-3 - Don't install desktop file (bug #170762). - Quieten the hpssd daemon at startup (bug #170762). kernel-2.6.13-1.1605_FC5 ------------------------ * Fri Oct 14 2005 Dave Jones - 2.6.14-rc4-git3 libselinux-1.27.9-2 ------------------- * Fri Oct 14 2005 Dan Walsh 1.27.9-2 - Tell init to reexec itself in post script * Fri Oct 07 2005 Dan Walsh 1.27.9-1 - Update to latest from NSA * Changed selinux_mkload_policy to try downgrading the latest policy version available to the kernel-supported version. * Changed selinux_mkload_policy to fall back to the maximum policy version supported by libsepol if the kernel policy version falls outside of the supported range. libsemanage-1.3.14-1 -------------------- * Fri Oct 14 2005 Dan Walsh 1.3.14-1 - Update from NSA * Updated to use get interfaces for hidden sepol_module_package type. * Changed semanage_expand_sandbox and semanage_install_active to generate/install the latest policy version supported by libsepol by default (unless overridden by semanage.conf), since libselinux will now downgrade automatically for load_policy. * Merged new callback-based error reporting system and ongoing database work from Ivan Gyurdiev. libsepol-1.9.17-2 ----------------- * Fri Oct 14 2005 Dan Walsh 1.9.17-2 - Tell init to reexec itself in post script * Mon Oct 10 2005 Dan Walsh 1.9.17-1 - Upgrade to latest from NSA * Hid sepol_module_package type definition, and added get interfaces. * Merged new callback-based error reporting system from Ivan Gyurdiev. * Merged support for require blocks inside conditionals from Joshua Brindle (Tresys). libsetrans-0.1.7-2 ------------------ * Fri Oct 14 2005 Dan Walsh 0.1.7-2 - Change SystemHigh to match the higher level of Categories. mozplugger-1.7.3-1 ------------------ * Fri Oct 14 2005 Florian La Roche - update to 1.7.3 openoffice.org-1:2.0.0-3.1.2 ---------------------------- * Fri Oct 14 2005 Caolan McNamara - 1:2.0.0-3.1 - release candidate 3 - alias en_US thesasurus for other en varients - can crash on empty thesasurus rh#170091#/ooo#55603# - drop thesaruses not in new format policycoreutils-1.27.11-1 ------------------------- * Fri Oct 14 2005 Dan Walsh 1.27.11-1 - Update to match NSA * Updated semodule_expand to use get interfaces for hidden sepol_module_package type. * Merged newrole and run_init pam config patches from Dan Walsh (Red Hat). * Merged fixfiles patch from Dan Walsh (Red Hat). * Updated semodule for removal of semanage_strerror. rsh-0.17-31 ----------- * Thu Oct 13 2005 Karel Zak 0.17-31 - rewrite rexecd PAM_conversation() squid-7:2.5.STABLE11-4 ---------------------- * Fri Oct 14 2005 Martin Stransky 7:2.5.STABLE11-4 - enabled support for large files (#167503) system-config-securitylevel-1.6.5-1 ----------------------------------- * Fri Oct 14 2005 Chris Lumens 1.6.5-1 - Remove the SELinux policy type combo box if there's only one policy installed. - Use a new pam configuration (#170644). - Don't pop up relabel warning during firstboot if the user did something like disabled->enabled->disabled before clicking next (#170549, #170550). texinfo-4.8-7 ------------- * Fri Oct 14 2005 Tim Waugh 4.8-7 - Apply patch to fix CAN-2005-3011 (bug #169585). vixie-cron-4:4.1-39.FC5 ----------------------- * Fri Oct 14 2005 Jason Vas Dias - 4.1-39-FC5 - fix bug 170830: the last PAM change disabled all cron jobs. backing out the new PAM configuration file until I've had a chance to test it with replacement of pam_stack.so. vlock-1.3-22 ------------ * Fri Oct 14 2005 Karel Zak 1.3-22 - fix #170488 - add screen(1) warning - compilation warnings cleanup From shane at geeklords.org Sat Oct 15 18:17:31 2005 From: shane at geeklords.org (Shane Stixrud) Date: Sat, 15 Oct 2005 11:17:31 -0700 (PDT) Subject: sysvinit replacement? Message-ID: Is there any plan to replace sysvinit with a system like SMF (Service Management Framework) in Solaris? Perhaps it is even possible to take SMF as is and integrate it into fedora without building our own or resurrecting DMD (http://directory.fsf.org/GNU/DMD.html) from the grave? Cheers, Shane From loony at loonybin.org Sat Oct 15 18:35:48 2005 From: loony at loonybin.org (Peter Arremann) Date: Sat, 15 Oct 2005 14:35:48 -0400 Subject: sysvinit replacement? In-Reply-To: References: Message-ID: <200510151435.48938.loony@loonybin.org> On Saturday 15 October 2005 14:17, Shane Stixrud wrote: > Is there any plan to replace sysvinit with a system like SMF (Service > Management Framework) in Solaris? Perhaps it is even possible to take SMF > as is and integrate it into fedora without building our own or resurrecting > DMD (http://directory.fsf.org/GNU/DMD.html) from the grave? Why not just create something thats compatible with the Windows registry? ;) We've been using 10 since it was in beta for several reasons and once you've gotten past the "woohoo - new and shiny" phase, SMF is one of the worst changes in Sol10. The biggest issue with SMF is the state database. A single type on a service file can corrupt your state database. So can interrupting a svcs command at the wrong time. If that happens, good luck - you go back to the last saved state and hope things still work. Of course if you installed software since then you end up with a mess and... Then the startup time gains are overrated... Log into your Sol10 box as soon as its possible and run "format" - if your box survives that (some older ones dont) then you'll see your format stall for a long time before you get your output. In the end, if you measure the time from push of the power button (assuming a reasonable diag level) to the time you logged in and got your format output there is barely any difference between Sol9 and Sol10. Same holds true for printing or a JES webserver request. Other problems are that you're trading a well known, well debugged system against something noone knows and that has virtually no tools to troubleshoot at the moment. You also make it much harder for anyone to port software to your Linux flavor. SMF is in my opinion one of the biggest technical mistakes sun has made in the recent history - would be a shame if Fedora followed such a bad example. Peter. From shane at geeklords.org Sat Oct 15 18:49:18 2005 From: shane at geeklords.org (Shane Stixrud) Date: Sat, 15 Oct 2005 11:49:18 -0700 (PDT) Subject: sysvinit replacement? In-Reply-To: <200510151435.48938.loony@loonybin.org> References: <200510151435.48938.loony@loonybin.org> Message-ID: On Sat, 15 Oct 2005, Peter Arremann wrote: > > The biggest issue with SMF is the state database. A single type on a service > file can corrupt your state database. So can interrupting a svcs command at > the wrong time. If that happens, good luck - you go back to the last saved > state and hope things still work. Of course if you installed software since > then you end up with a mess and... Are you saying this is a fundamental problem with a SMF type management framework or just a implementation detail in the current SMF system? > > Then the startup time gains are overrated... Log into your Sol10 box as soon > as its possible and run "format" - if your box survives that (some older ones > dont) then you'll see your format stall for a long time before you get your > output. In the end, if you measure the time from push of the power button > (assuming a reasonable diag level) to the time you logged in and got your > format output there is barely any difference between Sol9 and Sol10. Same > holds true for printing or a JES webserver request. I never found the startup time issue that big of a deal, it is a bigger deal for desktops/hand helds than servers IMO. I am more fond of the service monitoring/event features than I am how quick it is. > > Other problems are that you're trading a well known, well debugged system > against something noone knows and that has virtually no tools to troubleshoot > at the moment. You also make it much harder for anyone to port software to > your Linux flavor. This is true every time major change occurs, it is valid consideration though. Cheers, Shane From loony at loonybin.org Sat Oct 15 19:02:31 2005 From: loony at loonybin.org (Peter Arremann) Date: Sat, 15 Oct 2005 15:02:31 -0400 Subject: sysvinit replacement? In-Reply-To: References: <200510151435.48938.loony@loonybin.org> Message-ID: <200510151502.31731.loony@loonybin.org> On Saturday 15 October 2005 14:49, Shane Stixrud wrote: > Are you saying this is a fundamental problem with a SMF type management > framework or just a implementation detail in the current SMF system? I'm complaining about the current SMF implementation mostly. The porting will always be an issue if you introduce new technology but if the reward is worth it, it makes sense. > I never found the startup time issue that big of a deal, it is a bigger > deal for desktops/hand helds than servers IMO. I am more fond of the > > service monitoring/event features than I am how quick it is. And that only works if your application supports it. And if you take only a small section of the market the way sun is doing it, getting people to port to the new setup is gonna be difficult. > > Other problems are that you're trading a well known, well debugged system > > against something noone knows and that has virtually no tools to > > troubleshoot at the moment. You also make it much harder for anyone to > > port software to your Linux flavor. > > This is true every time major change occurs, it is valid consideration > though. That's why its important that what you're doing is really really worth it (like the SYSV package changes to support zones) and not something half baked like SMF. Peter. From ivazquez at ivazquez.net Sat Oct 15 21:50:27 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 15 Oct 2005 17:50:27 -0400 Subject: sysvinit replacement? In-Reply-To: References: Message-ID: <1129413027.7339.4.camel@ignacio.lan> On Sat, 2005-10-15 at 11:17 -0700, Shane Stixrud wrote: > Is there any plan to replace sysvinit with a system like SMF (Service > Management Framework) in Solaris? Perhaps it is even possible to take SMF > as is and integrate it into fedora without building our own or resurrecting > DMD (http://directory.fsf.org/GNU/DMD.html) from the grave? https://www.redhat.com/archives/fedora-devel-list/2005-June/msg01024.html -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 sundaram at redhat.com Sat Oct 15 22:44:29 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 16 Oct 2005 04:14:29 +0530 Subject: sysvinit replacement? In-Reply-To: References: Message-ID: <4351864D.9030809@redhat.com> Shane Stixrud wrote: > Is there any plan to replace sysvinit with a system like SMF (Service > Management Framework) in Solaris? Perhaps it is even possible to take > SMF as is and integrate it into fedora without building our own or > resurrecting DMD (http://directory.fsf.org/GNU/DMD.html) from the grave? There was a similar discussion before in this list. The consoldiated form is http://fedoraproject.org/wiki/FCNewInit. regards Rahul From seg at haxxed.com Sun Oct 16 07:45:00 2005 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 16 Oct 2005 02:45:00 -0500 Subject: FCNewInit and power management Message-ID: <1129448700.7318.73.camel@localhost.localdomain> I've been tweaking Fedora on laptops for a while now, and there really is a huge need for a clean, sane, flexible userspace power management infrastructure in Linux. Everything is a scattered mess of duplicated effort and functionality. Looking at it all, I've come to the realization that init/initscripts really needs to be handling a lot of it! So I look around and discover its been decided the whole SysvInit/initscripts system needs to be rewritten anyway. Perfect! However looking at the wiki summary, ( http://fedoraproject.org/wiki/FCNewInit ) it doesn't seem as if anyone else has realized the role init should have in power management. Look at apmd's /etc/sysconfig/apm-scripts/apmscript, look at acpid's /etc/acpi/actions/, look at suspend2's hibernate scripts ( http://www.suspend2.net/downloads/ ). Look at how init already (sorta) handles UPS power failures! Is a desktop on a UPS really that much different from a laptop with a battery? These are all extravagant duplications of what run levels should be doing. (Except maybe acpid which seems to do mostly nothing by default...) Run levels are states the system can be in. In addition to the existing "halt" "reboot" "single user" "no network" and "normal" states, there is "on battery" and "suspended" states just begging to be added. (I'm not sure the best way to handle slightly different types of similar states. We could possibly have a "battery low" state and we have "standby" "suspend to ram" and "suspend to disk" to choose from. Do they full run levels of their own? I'm guessing not...) The system I envision goes something like this. apmd and acpid get stripped down so all they do is send events to init. init absorbs similar functionality to acpid, it takes in "events" (over dbus?) from apmd, acpid, UPS daemons, /usr/bin/poweroff, etc and evaluates rules (Run scripts like acpid does?) that decide what states to switch to based on these events. Switching states is then handled much like the existing SysV init always has, or however the future system decides to do so. I'm actually not so sure about where the decision making needs to be, but the main point is the state switching/tracking should all be done by init, because thats what its for. Currently, there's a lot of duplication in the handling of state changes, in apmd, acpid, hibernate, laptop-mode, etc, that really needs to be centralized. Comments? -------------- 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 Sun Oct 16 11:20:42 2005 From: buildsys at redhat.com (Build System) Date: Sun, 16 Oct 2005 07:20:42 -0400 Subject: rawhide report: 20051016 changes Message-ID: <200510161120.j9GBKgb5029575@porkchop.devel.redhat.com> Updated Packages: SysVinit-2.85-42 ---------------- * Fri Oct 14 2005 Dan Walsh - 2.85-42 - Fix patch beecrypt-4.1.2-9 ---------------- * Sat Oct 15 2005 Florian La Roche - Use -with-cplusplus=no. The libs still require libstdc++, so this needs further cleanup. cdparanoia-alpha9.8-26 ---------------------- * Sat Oct 15 2005 Florian La Roche - make sure shared libs are linked against respective other libs checkpolicy-1.27.9-2 -------------------- * Sat Oct 15 2005 Dan Walsh 1.27.9-2 - Rebuild to get latest libsepol cups-1:1.1.23-23 ---------------- * Sat Oct 15 2005 Florian La Roche - link libcupsimage.so against libcups dmraid-1.0.0.rc8-FC4_6 ---------------------- * Sat Oct 15 2005 Florian La Roche - add -lselinux -lsepol for new device-mapper deps doxygen-1:1.4.5-1 ----------------- * Sat Oct 15 2005 Florian La Roche - 1.4.5 esound-1:0.2.36-2 ----------------- * Sat Oct 15 2005 Florian La Roche - link shared libs against all dependent libs gnome-screensaver-0.0.16-1 -------------------------- * Sun Oct 16 2005 Matthias Clasen 0.0.16-1 - Update to 0.0.16 * Fri Oct 14 2005 Matthias Clasen 0.0.15-2 - Don't use pam_stack (#170703) * Thu Oct 06 2005 Matthias Clasen 0.0.15-1 - Update to 0.0.15 howl-0.9.8-4 ------------ * Sun Oct 16 2005 Florian La Roche - link shared lib against -lpthread - exit 0 for postun * Wed Mar 02 2005 Alex Larsson 0.9.8-3 - Rebuild * Mon Dec 20 2004 Daniel Reed 0.9.8-2 - fix pkgconfig include directory kernel-2.6.13-1.1611_FC5 ------------------------ * Sat Oct 15 2005 Dave Jones - 2.6.14-rc4-git4 lftp-3.3.1-1 ------------ * Sat Oct 15 2005 Florian La Roche - 3.3.1 libavc1394-0.4.1-9 ------------------ * Sat Oct 15 2005 Florian La Roche - make sure librom1394 is linked to libraw1394 and also libavc1394 is linked to librom1394 (also bz 156938) libc-client-2002e-11 -------------------- * Sat Oct 15 2005 Florian La Roche - fix to rebuild at least, seems the way to specify the include dir is a bit broken * Wed Mar 02 2005 Joe Orton 2002e-10 - rebuild libcroco-0.6.0-6 ---------------- * Sat Oct 15 2005 Florian La Roche - link shared lib against -lglib-2.0 and -lxml2 libsemanage-1.3.18-1 -------------------- * Sat Oct 15 2005 Dan Walsh 1.3.18-1 - Update from NSA * Merged bugfix patch from Ivan Gyurdiev. * Merged seuser database patch from Ivan Gyurdiev. Merged direct user/port databases to the handle from Ivan Gyurdiev. * Removed obsolete include/semanage/commit_api.h (leftover). Merged seuser record patch from Ivan Gyurdiev. * Merged boolean and interface databases from Ivan Gyurdiev. libsepol-1.9.18-1 ----------------- * Sat Oct 15 2005 Dan Walsh 1.9.18-1 - Upgrade to latest from NSA * Merged conditional expression mapping fix in the module linking code from Joshua Brindle. libsilc-0:0.9.12-12 ------------------- * Sat Oct 15 2005 Florian La Roche - link against dependent libs logrotate-3.7.2-7 ----------------- * Sat Oct 15 2005 Peter Vrabec 3.7.2-7 - fix_free_segfaults (#170904) lvm2-2.01.14-3 -------------- * Sat Oct 15 2005 Florian La Roche - add -lselinux -lsepol to the static linking -ldevice-mapper requires it memtest86+-1.65-2 ----------------- * Sat Oct 15 2005 Florian La Roche - make sure 32bit glibc-devel is installed (#170614) policycoreutils-1.27.12-1 ------------------------- * Sat Oct 15 2005 Dan Walsh 1.27.12-1 - Update to match NSA * Merged non-PAM Makefile support for newrole and run_init from Timothy Wood. sane-backends-1.0.16-2 ---------------------- * Sat Oct 15 2005 Florian La Roche - rebuild slang-1.4.9-20 -------------- * Sun Oct 16 2005 Florian La Roche - add exec perms to shared libs unixODBC-2.2.11-4 ----------------- * Sun Oct 16 2005 Florian La Roche - link against dependent libs - fix some bugs to resolve unknown symbols ;-( utempter-0.5.5-7 ---------------- * Sun Oct 16 2005 Florian La Roche - install shared lib with execute perms wget-1.10.2-1 ------------- * Sat Oct 15 2005 Florian La Roche - 1.10.2 Broken deps for s390x ---------------------------------------------------------- slang - 1.4.9-20.s390 requires ld.so.1(GLIBC_PRIVATE) slang - 1.4.9-20.s390x requires ld64.so.1(GLIBC_PRIVATE)(64bit) Broken deps for ppc64 ---------------------------------------------------------- slang - 1.4.9-20.ppc64 requires ld64.so.1(GLIBC_PRIVATE)(64bit) Broken deps for ppc ---------------------------------------------------------- slang - 1.4.9-20.ppc requires ld.so.1(GLIBC_PRIVATE) Broken deps for ia64 ---------------------------------------------------------- slang - 1.4.9-20.ia64 requires ld-linux-ia64.so.2(GLIBC_PRIVATE)(64bit) Broken deps for s390 ---------------------------------------------------------- slang - 1.4.9-20.s390 requires ld.so.1(GLIBC_PRIVATE) Broken deps for i386 ---------------------------------------------------------- slang - 1.4.9-20.i386 requires ld-linux.so.2(GLIBC_PRIVATE) Broken deps for x86_64 ---------------------------------------------------------- slang - 1.4.9-20.x86_64 requires ld-linux-x86-64.so.2(GLIBC_PRIVATE)(64bit) slang - 1.4.9-20.i386 requires ld-linux.so.2(GLIBC_PRIVATE) From josep.puigdemont at gmail.com Sun Oct 16 12:18:53 2005 From: josep.puigdemont at gmail.com (Josep Puigdemont) Date: Sun, 16 Oct 2005 14:18:53 +0200 Subject: Proposed Development Areas for Fedora Core 5 and Fedora Project Message-ID: <1129465133.7299.101.camel@deimos.baldrick.mine.nu> I'm reading a suggestion in http://fedoraproject.org/wiki/FC5Future for trimming down core: "All stuff for personal install and the support for the six main languages (en,de,fr,es,??) on the first two CDs. Big stuff like openoffice-lang-support for uncommon langages only in extras?" That's a bad joke, right? /Josep (an uncommon language speaker) P.S.: Don't know who wrote that, but neither French nor German are in the top 6 most spoken languages (Chinese, Arabic, Hindi and others go first) From gilboada at netvision.net.il Sun Oct 16 12:26:59 2005 From: gilboada at netvision.net.il (Gilboa Davara) Date: Sun, 16 Oct 2005 14:26:59 +0200 Subject: Proposed Development Areas for Fedora Core 5 and Fedora Project In-Reply-To: <1129465133.7299.101.camel@deimos.baldrick.mine.nu> References: <1129465133.7299.101.camel@deimos.baldrick.mine.nu> Message-ID: <1129465619.32625.2.camel@gilboa-work-dev> I assume that a these "extra" package will also be mastered as a downloadable ISOs , right? Having to download 400MB of he_IL packages on each NFS Fedora installation doesn't bode well for my ISP account... Gilboa On Sun, 2005-10-16 at 14:18 +0200, Josep Puigdemont wrote: > I'm reading a suggestion in > http://fedoraproject.org/wiki/FC5Future > for trimming down core: > > "All stuff for personal install and the support for the six main > languages (en,de,fr,es,??) on the first two CDs. Big stuff like > openoffice-lang-support for uncommon langages only in extras?" > > > That's a bad joke, right? > > > > /Josep (an uncommon language speaker) > > P.S.: Don't know who wrote that, but neither French nor German > are in the top 6 most spoken languages (Chinese, Arabic, Hindi and > others go first) > > From pbrobinson at gmail.com Sun Oct 16 13:39:55 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 16 Oct 2005 14:39:55 +0100 Subject: Proposed Development Areas for Fedora Core 5 and Fedora Project In-Reply-To: <1129465619.32625.2.camel@gilboa-work-dev> References: <1129465133.7299.101.camel@deimos.baldrick.mine.nu> <1129465619.32625.2.camel@gilboa-work-dev> Message-ID: <5256d0b0510160639n68cfce1ame8d67d999c3c5bdf@mail.gmail.com> > I assume that a these "extra" package will also be mastered as a > downloadable ISOs , right? > Having to download 400MB of he_IL packages on each NFS Fedora > installation doesn't bode well for my ISP account... > > > "All stuff for personal install and the support for the six main > > languages (en,de,fr,es,??) on the first two CDs. Big stuff like > > openoffice-lang-support for uncommon langages only in extras?" > > > > That's a bad joke, right? My understanding was that it would be part of the main distro but on another CD image so if you download across the net or as a DVD it would be of no effect but if you only use English or one of around 6 of the best supported languages you'd have to download the separate CD. If you install off the net it would make no difference at all, or if you buy the distro as a CD to save the download if wouldn't matter either. Peter From laroche at redhat.com Sun Oct 16 15:47:59 2005 From: laroche at redhat.com (Florian La Roche) Date: Sun, 16 Oct 2005 17:47:59 +0200 Subject: FC-devel install Message-ID: <20051016154758.GA19149@dudweiler.stuttgart.redhat.com> Current FC-devel tree via kickstart stops at kickstart.py:655 due to missing _(). Maybe the following would fix it: --- kickstart.py +++ kickstart.py @@ -28,6 +28,7 @@ import urlgrabber.grabber as grabber import lvm from pykickstart.parser import * from pykickstart.data import * +from rhpl.translate import _ import logging log = logging.getLogger("anaconda") greetings, Florian La Roche From nicolas.mailhot at laposte.net Sun Oct 16 20:34:44 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 16 Oct 2005 22:34:44 +0200 Subject: Buildsys needs kicking Message-ID: <1129494884.4537.1.camel@rousalka.dyndns.org> [nim at rousalka FC-3]$ plague-client list Traceback (most recent call last): File "/usr/bin/plague-client", line 421, in ? list_jobs(server, sys.argv[2:]) File "/usr/bin/plague-client", line 171, in list_jobs (e, msg, jobs) = server.list_jobs(query_args) File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/lib64/python2.4/xmlrpclib.py", line 1147, in request return self._parse_response(h.getfile(), sock) File "/usr/lib64/python2.4/xmlrpclib.py", line 1286, in _parse_response return u.close() File "/usr/lib64/python2.4/xmlrpclib.py", line 744, in close raise Fault(**self._stack[0]) xmlrpclib.Fault: [nim at rousalka FC-3]$ date dim oct 16 22:34:22 CEST 2005 -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Mon Oct 17 04:37:07 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Oct 2005 00:37:07 -0400 Subject: FCNewInit and power management In-Reply-To: <1129448700.7318.73.camel@localhost.localdomain> References: <1129448700.7318.73.camel@localhost.localdomain> Message-ID: <20051017043707.GA26122@devserv.devel.redhat.com> Callum Lerwick (seg at haxxed.com) said: > Look at apmd's /etc/sysconfig/apm-scripts/apmscript, look at > acpid's /etc/acpi/actions/, look at suspend2's hibernate scripts > ( http://www.suspend2.net/downloads/ ). Why? These are already deprecated in favor of scripts that use HAL. (See gnome-power-manager and pm-utils.) Bill From alexl at redhat.com Mon Oct 17 09:31:16 2005 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 17 Oct 2005 11:31:16 +0200 Subject: avahi and howl In-Reply-To: <604aa7910510131639p31bc00ddgdd32583dc1843b12@mail.gmail.com> References: <1129239238.2624.5.camel@aurora.localdomain> <604aa7910510131639p31bc00ddgdd32583dc1843b12@mail.gmail.com> Message-ID: <1129541477.22755.17.camel@greebo> On Thu, 2005-10-13 at 19:39 -0400, Jeff Spaleta wrote: > On 10/13/05, Trever L. Adams wrote: > > Is this something that RedHat/Fedora should follow Debian/Gaim on? > > As soon as programs in Core require it I'm sure that its going to get > sucked in to Core. > > The more important question is... now that gaim is going to use > avahi... what else in Fedora Core requires howl..and can those other > items be made to use avahi as well? > It would be best if howl could be replaced completely in Core with > avahi to avoid duplication of functionality with multuple > implementations. > > rawhide>repoquery --whatrequires libhowl.so.0 > gnome-games-1:2.12.1-1.i386 in Core > gnomemeeting-0:1.2.2-2.i386 in Core > gnome-vfs2-0:2.12.1.1-1.i386 in Core > obby-0:0.2.0-5.fc5.i386 in Extras I'll try to find some time to port gnome-vfs2. I think it makes sense to switch to Avahi. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a fast talking moralistic hairdresser who hides his scarred face behind a mask. She's a blind African-American wrestler married to the Mob. They fight crime! From pbrobinson at gmail.com Mon Oct 17 10:35:12 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 17 Oct 2005 11:35:12 +0100 Subject: avahi and howl In-Reply-To: <1129541477.22755.17.camel@greebo> References: <1129239238.2624.5.camel@aurora.localdomain> <604aa7910510131639p31bc00ddgdd32583dc1843b12@mail.gmail.com> <1129541477.22755.17.camel@greebo> Message-ID: <5256d0b0510170335m531ed0a0l92d63d66245a8da2@mail.gmail.com> > > On 10/13/05, Trever L. Adams wrote: > > > Is this something that RedHat/Fedora should follow Debian/Gaim on? > > > > As soon as programs in Core require it I'm sure that its going to get > > sucked in to Core. > > > > The more important question is... now that gaim is going to use > > avahi... what else in Fedora Core requires howl..and can those other > > items be made to use avahi as well? > > It would be best if howl could be replaced completely in Core with > > avahi to avoid duplication of functionality with multuple > > implementations. > > > > rawhide>repoquery --whatrequires libhowl.so.0 > > gnome-games-1:2.12.1-1.i386 in Core > > gnomemeeting-0:1.2.2-2.i386 in Core > > gnome-vfs2-0:2.12.1.1-1.i386 in Core > > obby-0:0.2.0-5.fc5.i386 in Extras > > I'll try to find some time to port gnome-vfs2. I think it makes sense to > switch to Avahi. According to this blog entry http://0pointer.de/blog/projects/avahi-compat the avahi guys have created a compatibility layer for howl/bonjour that runs with gnome-vfs2, nautilus etc. so we should be able to replace howl with the soon to be released 0.6 of avahi while everything gets ported to native avahi. Pete From buildsys at redhat.com Mon Oct 17 12:02:15 2005 From: buildsys at redhat.com (Build System) Date: Mon, 17 Oct 2005 08:02:15 -0400 Subject: rawhide report: 20051017 changes Message-ID: <200510171202.j9HC2FLF016463@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.13-1.1615_FC5 ------------------------ * Sun Oct 16 2005 Dave Jones - Enable ACPI EC Burst. - Change printk level of an ACPI message. - Stop IDE claiming legacy ports before libata in combined mode. net-tools-1.60-57 ----------------- * Sat Oct 15 2005 Radek Vokal 1.60-57 - add note to hostname man page about gethostbyname() (#166581) - don't ship any rarp man page (#170537) slang-1.4.9-21 -------------- system-config-soundcard-1.2.12-6 -------------------------------- * Sun Oct 16 2005 Martin Stransky 1.2.12-6 - new pam file (#170648 ??? pam_stack is deprecated) From clumens at redhat.com Mon Oct 17 15:05:07 2005 From: clumens at redhat.com (Chris Lumens) Date: Mon, 17 Oct 2005 11:05:07 -0400 (EDT) Subject: FC-devel install In-Reply-To: <20051016154758.GA19149@dudweiler.stuttgart.redhat.com> References: <20051016154758.GA19149@dudweiler.stuttgart.redhat.com> Message-ID: > --- kickstart.py > +++ kickstart.py > @@ -28,6 +28,7 @@ import urlgrabber.grabber as grabber > import lvm > from pykickstart.parser import * > from pykickstart.data import * > +from rhpl.translate import _ > > import logging > log = logging.getLogger("anaconda") Committed. Thanks. - Chris From smooge at gmail.com Mon Oct 17 17:10:41 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 17 Oct 2005 11:10:41 -0600 Subject: Silly request of the day: Message-ID: <80d7e4090510171010r3e6e64fbr747c790018a4c2e7@mail.gmail.com> With authconfig possibly getting a rewrite.. how about renaming it to system-config-authorization ? -- Stephen J Smoogen. CSIRT/Linux System Administrator From dravet at hotmail.com Mon Oct 17 18:24:13 2005 From: dravet at hotmail.com (Jason Dravet) Date: Mon, 17 Oct 2005 13:24:13 -0500 Subject: only half of screen is visable during boot Message-ID: I opened https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170450 a week and half ago and I have not received any response so I thought I would send an email here. I have been using the rawhide kernel since (2.6.13-1.1600_FC5 and I am running 1615 now. During the boot, only part of the screen is visable. For example the monitor the is the lines and I can only see text in the asterik area. The bottom of the area I can see is only the top half of the line. It is like someone cut off the bottom of my monitor. ----------------------- | **************** | | * * | | * * | | **************** | | | | | | | ----------------------- I have a Number Nine revolution 4 video card and a SGI 1600sw lcd panel. Thanks, Jason From Florin.Malita at Glenayre.com Mon Oct 17 18:29:16 2005 From: Florin.Malita at Glenayre.com (Malita, Florin) Date: Mon, 17 Oct 2005 14:29:16 -0400 Subject: Silly request of the day: Message-ID: <1129573425.11576.33.camel@scox.glenatl.glenayre.com> On Mon, 2005-10-17 at 13:10 -0400, Stephen J. Smoogen wrote: > With authconfig possibly getting a rewrite.. how about renaming it to > system-config-authorization ? You mean system-config-authentication, right? From wtogami at redhat.com Mon Oct 17 18:34:37 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 17 Oct 2005 14:34:37 -0400 Subject: avahi and howl In-Reply-To: <5256d0b0510170335m531ed0a0l92d63d66245a8da2@mail.gmail.com> References: <1129239238.2624.5.camel@aurora.localdomain> <604aa7910510131639p31bc00ddgdd32583dc1843b12@mail.gmail.com> <1129541477.22755.17.camel@greebo> <5256d0b0510170335m531ed0a0l92d63d66245a8da2@mail.gmail.com> Message-ID: <4353EEBD.60601@redhat.com> Peter Robinson wrote: >> >>I'll try to find some time to port gnome-vfs2. I think it makes sense to >>switch to Avahi. > > > According to this blog entry > http://0pointer.de/blog/projects/avahi-compat the avahi guys have > created a compatibility layer for howl/bonjour that runs with > gnome-vfs2, nautilus etc. so we should be able to replace howl with > the soon to be released 0.6 of avahi while everything gets ported to > native avahi. > > Pete > If there is agreement here that we need to add avahi, then the next step is to have a Red Hat engineer become owner. Who? Warren Togami wtogami at redhat.com From ivazquez at ivazquez.net Mon Oct 17 18:46:56 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 17 Oct 2005 14:46:56 -0400 Subject: Silly request of the day: In-Reply-To: <80d7e4090510171010r3e6e64fbr747c790018a4c2e7@mail.gmail.com> References: <80d7e4090510171010r3e6e64fbr747c790018a4c2e7@mail.gmail.com> Message-ID: <1129574816.7339.15.camel@ignacio.lan> On Mon, 2005-10-17 at 11:10 -0600, Stephen J. Smoogen wrote: > With authconfig possibly getting a rewrite.. how about renaming it to > system-config-authorization ? Or perhaps system-config-auth as it deals with both authorization and authentication. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 jfrieben at freesurf.fr Mon Oct 17 18:49:24 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Mon, 17 Oct 2005 20:49:24 +0200 (CEST) Subject: ACPI changes prevent IBM ThinkPad T23 from booting Message-ID: <9252.194.94.224.254.1129574964.squirrel@jose.freesurf.fr> Today's ACPI updates in kernel-2.6.13-1.1615_FC5 make my IBM ThinkPad T23 hang during boot. I have to add "acpi=off" to make the system come up at all. From tadams-lists at myrealbox.com Mon Oct 17 19:29:58 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Mon, 17 Oct 2005 13:29:58 -0600 Subject: avahi and howl In-Reply-To: <4353EEBD.60601@redhat.com> References: <1129239238.2624.5.camel@aurora.localdomain> <604aa7910510131639p31bc00ddgdd32583dc1843b12@mail.gmail.com> <1129541477.22755.17.camel@greebo> <5256d0b0510170335m531ed0a0l92d63d66245a8da2@mail.gmail.com> <4353EEBD.60601@redhat.com> Message-ID: <1129577398.2638.1.camel@aurora.localdomain> On Mon, 2005-10-17 at 14:34 -0400, Warren Togami wrote: > If there is agreement here that we need to add avahi, then the next step > is to have a Red Hat engineer become owner. Who? > > Warren Togami > wtogami at redhat.com > I may be completely wrong, but it seems to me to give it to whoever owns howl. Trever -- "Seize the day, put no trust in the morrow!" -- Quintus Horatius Flaccus (Horace) From bojan at rexursive.com Tue Oct 18 00:54:27 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 18 Oct 2005 10:54:27 +1000 Subject: ACPI changes prevent IBM ThinkPad T23 from booting In-Reply-To: <9252.194.94.224.254.1129574964.squirrel@jose.freesurf.fr> References: <9252.194.94.224.254.1129574964.squirrel@jose.freesurf.fr> Message-ID: <20051018105427.n1usxqrwcgskksc8@imp.rexursive.com> Quoting Joachim Frieben : > Today's ACPI updates in kernel-2.6.13-1.1615_FC5 make my > IBM ThinkPad T23 hang during boot. I have to add "acpi=off" > to make the system come up at all. Ditto HP Pavilion ZE-4201 (i.e. it hangs). Given this notebook doesn't do APM, I didn't even try without ACPI. -- Bojan From ffedora at sympatico.ca Tue Oct 18 03:04:17 2005 From: ffedora at sympatico.ca (Fedora) Date: Mon, 17 Oct 2005 23:04:17 -0400 Subject: SATA DVD support Message-ID: What is the status of SATA DVD support (Plextor PX-716SA) in Fedora 4? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlauterbach at mail.wtamu.edu Tue Oct 18 03:51:28 2005 From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach) Date: Mon, 17 Oct 2005 22:51:28 -0500 Subject: only half of screen is visable during boot In-Reply-To: References: Message-ID: <1129607489.16727.9.camel@amd64.mattlauterbach.com> On Mon, 2005-10-17 at 13:24 -0500, Jason Dravet wrote: > I opened https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170450 a week > and half ago and I have not received any response so I thought I would send > an email here. I have been using the rawhide kernel since > (2.6.13-1.1600_FC5 and I am running 1615 now. During the boot, only part of > the screen is visable. For example the monitor the is the lines and I can > only see text in the asterik area. The bottom of the area I can see is only > the top half of the line. It is like someone cut off the bottom of my > monitor. > ----------------------- > | **************** | > | * * | > | * * | > | **************** | > | | > | | > | | > ----------------------- > > I have a Number Nine revolution 4 video card and a SGI 1600sw lcd panel. Help the kernel guys out with a little more info. Attach the results of lspci to your bugzilla entry. Did it work with stock FC4? Try another monitor to isolate the problem to the card or the monitor. Are the card and the monitor being detected correctly? Get the kernel source and check for recent changes in the kernel module for that video card. Are you running all of rawhide or just the kernel? Does dmesg say anything about it? Matthew E. Lauterbach From d.lesca at solinos.it Tue Oct 18 08:36:01 2005 From: d.lesca at solinos.it (Dario Lesca) Date: Tue, 18 Oct 2005 10:36:01 +0200 Subject: FC4: SCSI tape not detect Message-ID: <1129624561.5046.12.camel@lesca.home.solinos.it> Hi, After kernel update (2.6.13-1.1526_FC4smp) the SCSI tape driver not work, is missing. If I rebuild with a previous kernel (2.6.12-1.1447_FC4smp) the tape work property. The server is a HP Proliant ML 350 with 2 SCSI controller - smartarray controller (with RAID 5) - LSI controller (with TAPE C7438A HP Model) . See the attach, is a previous message with two boot process, post to fedora user list. I must also fill a bug report on bugzilla? Many thanks for your reply and sorry for my bad English -- Dario Lesca -------------- next part -------------- An embedded message was scrubbed... From: Dario Lesca Subject: Re: HP Tape not detect after kernel update Date: Fri, 14 Oct 2005 19:42:54 +0200 Size: 41075 URL: From buildsys at redhat.com Tue Oct 18 11:21:51 2005 From: buildsys at redhat.com (Build System) Date: Tue, 18 Oct 2005 07:21:51 -0400 Subject: rawhide report: 20051018 changes Message-ID: <200510181121.j9IBLptf003231@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.5.0-2 ---------------------- * Mon Oct 17 2005 Christopher Aillon - 0.5.0-2 - NetworkManager 0.5.0 dhcp-11:3.0.3-8 --------------- * Thu Oct 13 2005 Jason Vas Dias - 11:3.0.3-8 - further fix for bug 160655 / ISC bug 15293 - upstream patch: do NOT always strip trailing nulls in the dhcpd server evolution-data-server-1.4.1.1-1 ------------------------------- * Mon Oct 17 2005 David Malcolm - 1.4.1.1-1 - 1.4.1.1 * Mon Oct 17 2005 David Malcolm - 1.4.1-2 - Updated patch 102 (fix-implicit-function-declarations) to include fix for http calendar backend (thanks to Peter Robinson) * Tue Oct 04 2005 David Malcolm - 1.4.1-1 - 1.4.1 file-4.16-1 ----------- * Tue Oct 18 2005 Radek Vokal - 4.16-1 - upgrade to upstream * Mon Oct 03 2005 Radek Vokal - 4.15-4 - file output for Berkeley DB gains Cracklib (#168917) * Mon Sep 19 2005 Radek Vokal - 4.15-3 - small fix in previously added patch, now it works for multiple params firstboot-1.3.51-1 ------------------ * Mon Oct 17 2005 Chris Lumens 1.3.51-1 - Fix whrandom deprecation warnings. - Fix render_to_drawable deprecation warnings. - Change "Next" button on last page to "Finish". fontconfig-2.3.91.cvs20051017-1 ------------------------------- * Fri Oct 14 2005 Matthias Clasen - 2.3.91.cvs20051017-1 - Update to the mmap branch of fontconfig gdm-1:2.8.0.4-6 --------------- * Mon Oct 17 2005 Steve Grubb 1:2.8.0.4-6 - add login audit patch (bug 170569) * Mon Oct 17 2005 Ray Strode 1:2.8.0.4-5 - bump redhat-artwork requirement to get rid of the boot throbber for now, since it seems to have reappeared mysteriously (bug 171025) gjdoc-0.7.6-1 ------------- * Mon Oct 17 2005 Andrew Overholt 0.7.6-1 - 0.7.6. kernel-2.6.13-1.1616_FC5 ------------------------ * Mon Oct 17 2005 Dave Jones - 2.6.14-rc4-git5 libselinux-1.27.10-1 -------------------- * Mon Oct 17 2005 Dan Walsh 1.27.10-1 - lynx-2.8.5-24 ------------- * Mon Oct 17 2005 Tim Waugh 2.8.5-24 - Apply patch to fix CAN-2005-3120 (bug #170253). mc-1:4.6.1a-0.19 ---------------- * Sun Oct 16 2005 Jindrich Novy 4.6.1a-0.19 - update from CVS - convert spec to UTF-8 - sync utf8, promptfix, 64bit patches - drop upstreamed gcc4, ftpcrash, find, symcrash, cstrans, searchfix patches - drop ctrl-t patch - update userhost patch to let the edited/viewed file name be displayed in xterm title mkinitrd-5.0.5-1 ---------------- * Mon Oct 17 2005 Peter Jones - 5.0.5-1 - make PROBE, MODULES, and PREMODS load defaults from a config file - get rid of support for not using a dynamic /dev - add options to force device probes (for when PROBE is "no") - consolidate some duplicate code paths - make nash's otherCommand check PATH first and use what it finds there for any commands it needs to run, unless the command starts with "nash-", in which case the internal version is used unconditionally - remove the symlink hack for setuproot/preswitchroot/switchroot - wrap all the nash commands in mkinitrd with shell functions and use the "nash-" varient. - rework root fs creation so Jeremy can use the otherCommand feature redhat-artwork-0.129-2 ---------------------- * Mon Oct 17 2005 Ray Strode 0.129-2 - remove throbber patch for now scim-anthy-0.7.1-1.fc5 ---------------------- * Mon Oct 17 2005 Akira TAGOH - 0.7.1-1 - New upstream release. - scim-0.7.0-fix_crash_bug.diff: removed. selinux-policy-strict-1.27.1-18 ------------------------------- * Mon Oct 17 2005 Dan Walsh 1.27.1-18 - Cleanup category defs - Add configfs_t - Allow http to run with mod_ftpd - Fix initrc_exec_t scripts to run with the correct securitylevel - Fixes for postfix_local selinux-policy-targeted-1.27.1-18 --------------------------------- * Mon Oct 17 2005 Dan Walsh 1.27.1-18 - Cleanup category defs - Add configfs_t - Allow http to run with mod_ftpd - Fix initrc_exec_t scripts to run with the correct securitylevel - Fixes for postfix_local system-config-printer-0.6.144-1 ------------------------------- * Mon Oct 17 2005 Tim Waugh 0.6.144-1 - 0.6.144: - Use SUDO_USER if set when printing test page (bug #170013). - Avoid pam_stack (bug #170640). util-linux-2.13-0.5.pre4 ------------------------ * Mon Oct 17 2005 Karel Zak 2.13-0.5.pre4 * fix #170564 - add audit message to login vim-1:6.4.000-1 --------------- * Mon Oct 17 2005 Karsten Hopp 6.4.000-1 - vim-6.4 patchlevel 0 wireless-tools-1:28-0.pre10.5 ----------------------------- * Mon Oct 17 2005 Christopher Aillon 28-0pre10 - Update to version 28 pre10 yelp-2.12.1-3 ------------- * Mon Oct 17 2005 Matthias Clasen - 2.12.1-3 - Include the category General|Linux|Distributions|Other on the title page * Mon Oct 17 2005 Matthias Clasen - 2.12.1-2 - Fix a double-free bug Broken deps for i386 ---------------------------------------------------------- gdm - 1:2.8.0.4-6.i386 requires redhat-artwork >= 0:0.129-20 Broken deps for ppc ---------------------------------------------------------- gdm - 1:2.8.0.4-6.ppc requires redhat-artwork >= 0:0.129-20 Broken deps for s390x ---------------------------------------------------------- gdm - 1:2.8.0.4-6.s390x requires redhat-artwork >= 0:0.129-20 Broken deps for ia64 ---------------------------------------------------------- gdm - 1:2.8.0.4-6.ia64 requires redhat-artwork >= 0:0.129-20 Broken deps for x86_64 ---------------------------------------------------------- gdm - 1:2.8.0.4-6.x86_64 requires redhat-artwork >= 0:0.129-20 Broken deps for ppc64 ---------------------------------------------------------- gdm - 1:2.8.0.4-6.ppc64 requires redhat-artwork >= 0:0.129-20 Broken deps for s390 ---------------------------------------------------------- gdm - 1:2.8.0.4-6.s390 requires redhat-artwork >= 0:0.129-20 From pbrobinson at gmail.com Tue Oct 18 12:35:46 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 18 Oct 2005 13:35:46 +0100 Subject: rawhide report: 20051018 changes In-Reply-To: <200510181121.j9IBLptf003231@porkchop.devel.redhat.com> References: <200510181121.j9IBLptf003231@porkchop.devel.redhat.com> Message-ID: <5256d0b0510180535r71c55895t45f858a8509aaebf@mail.gmail.com> > evolution-data-server-1.4.1.1-1 > ------------------------------- > * Mon Oct 17 2005 David Malcolm - 1.4.1.1-1 > - 1.4.1.1 > > * Mon Oct 17 2005 David Malcolm - 1.4.1-2 > - Updated patch 102 (fix-implicit-function-declarations) to include fix for > http calendar backend (thanks to Peter Robinson) I also did a similar patch for evo 2.4.1 but I ran into problems because there was a new function added that wasn't prototyped (I think that's what you call it) in the .h file. So does that mean we get evo 2.4.1 shortly too :-) Pete From ph18 at cornell.edu Tue Oct 18 16:06:35 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Tue, 18 Oct 2005 12:06:35 -0400 Subject: FCNewInit and power management In-Reply-To: <1129448700.7318.73.camel@localhost.localdomain> References: <1129448700.7318.73.camel@localhost.localdomain> Message-ID: <43551D8B.8070908@cornell.edu> Callum Lerwick wrote: >Run levels are states the system can be in. In addition to the existing >"halt" "reboot" "single user" "no network" and "normal" states, there is >"on battery" and "suspended" states just begging to be added. (I'm not >sure the best way to handle slightly different types of similar states. >We could possibly have a "battery low" state and we have "standby" >"suspend to ram" and "suspend to disk" to choose from. Do they full run >levels of their own? I'm guessing not...) > > > One trouble is that the real state of the system is really the direct product of a few different states, unioned with a few states that are 'special' {network, no network} [x] { wallplug power, battery normal, battery low, ... } + {halt, reboot, suspend, single user} so the configuration system ought to reflect this, rather than expanding into tens or hundreds of 'runlevels' as new substates get added. The kind of thinking above would be the beginning of it... You can define the set of states as a union of sets, these sets can be a list of states or be a direct product of a union of sets against another union of sets. >The system I envision goes something like this. apmd and acpid get >stripped down so all they do is send events to init. init absorbs >similar functionality to acpid, it takes in "events" (over dbus?) from >apmd, acpid, UPS daemons, /usr/bin/poweroff, etc and evaluates rules >(Run scripts like acpid does?) that decide what states to switch to >based on these events. Switching states is then handled much like the >existing SysV init always has, or however the future system decides to >do so. > > > This could be nice. >I'm actually not so sure about where the decision making needs to be, >but the main point is the state switching/tracking should all be done by >init, because thats what its for. Currently, there's a lot of >duplication in the handling of state changes, in apmd, acpid, hibernate, >laptop-mode, etc, that really needs to be centralized. > >Comments? > > Some people have thought about applying logic programming ideas to init: http://www-128.ibm.com/developerworks/linux/library/l-boot.html?ca=dgr-lnxw04BootFaster Overall I'm skeptical about power management in laptops, I've yet to own one where the cure is worse than the disease... After NiIMH batteries age for a while, the 'low battery' indication seems to be unreliable: my experience is that it either comes 30 seconds before the system fails or it comes an hour early. With a reliable file system like ext3, I just run it into the ground. Because I do all my work in emacs, I never lose more than a minute of work. From dravet at hotmail.com Tue Oct 18 16:25:55 2005 From: dravet at hotmail.com (Jason Dravet) Date: Tue, 18 Oct 2005 11:25:55 -0500 Subject: bad gdm dependency Message-ID: When updating gdm from todays rawhide I get the following: /etc/selinux/targeted/contexts/files/file_contexts: line 1313 has invalid context system_u:object_r:newrole_exec_t error: Failed dependencies: redhat-artwork >= 0:0.129-20 is needed by gdm-2.8.0.4-6.i386 Just an FYI, Jason From jkeating at j2solutions.net Tue Oct 18 17:27:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 18 Oct 2005 10:27:51 -0700 Subject: SATA DVD support In-Reply-To: <1129604657.3245.10.camel@nebuchadnezzar.l2technologies.net> References: <1129604657.3245.10.camel@nebuchadnezzar.l2technologies.net> Message-ID: <1129656471.19279.35.camel@prometheus.gamehouse.com> On Mon, 2005-10-17 at 23:04 -0400, Fedora wrote: > What is the status of SATA DVD support (Plextor PX-716SA) in Fedora 4? The question would be more for the chipset you're going to plug it into. SATA mostly represents itself as a SCSI device under the 2.6 kernel tree, so since I seem to recall SCSI cdroms working, I can't think of too many reasons why a SATA CDROM device wouldn't. Have you tried this device and ran into problems? Is there something that makes you think it won't work? -- 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 From pjones at redhat.com Tue Oct 18 17:54:00 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 18 Oct 2005 13:54:00 -0400 Subject: SATA DVD support In-Reply-To: <1129656471.19279.35.camel@prometheus.gamehouse.com> References: <1129604657.3245.10.camel@nebuchadnezzar.l2technologies.net> <1129656471.19279.35.camel@prometheus.gamehouse.com> Message-ID: <1129658040.23024.20.camel@localhost.localdomain> On Tue, 2005-10-18 at 10:27 -0700, Jesse Keating wrote: > On Mon, 2005-10-17 at 23:04 -0400, Fedora wrote: > > What is the status of SATA DVD support (Plextor PX-716SA) in Fedora 4? > > The question would be more for the chipset you're going to plug it into. > SATA mostly represents itself as a SCSI device under the 2.6 kernel > tree, so since I seem to recall SCSI cdroms working, I can't think of > too many reasons why a SATA CDROM device wouldn't. Have you tried this > device and ran into problems? Is there something that makes you think > it won't work? It won't work; support for ATAPI devices in libata is not enabled in the Fedora kernels, on the advice of the code's author. Hopefully jgarzik will chime in on this, but I don't think he's on this list, so I've Cc'd him. -- Peter From fedora at leemhuis.info Tue Oct 18 17:55:33 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 18 Oct 2005 19:55:33 +0200 Subject: SATA DVD support In-Reply-To: <1129656471.19279.35.camel@prometheus.gamehouse.com> References: <1129604657.3245.10.camel@nebuchadnezzar.l2technologies.net> <1129656471.19279.35.camel@prometheus.gamehouse.com> Message-ID: <1129658133.3240.17.camel@localhost.localdomain> Am Dienstag, den 18.10.2005, 10:27 -0700 schrieb Jesse Keating: > On Mon, 2005-10-17 at 23:04 -0400, Fedora wrote: > > What is the status of SATA DVD support (Plextor PX-716SA) in Fedora 4? > > The question would be more for the chipset you're going to plug it into. > SATA mostly represents itself as a SCSI device under the 2.6 kernel > tree, so since I seem to recall SCSI cdroms working, I can't think of > too many reasons why a SATA CDROM device wouldn't. Have you tried this > device and ran into problems? Is there something that makes you think > it won't work? ATAPI-SATA is not yet fully supported in the kernel so SATA-CDROMS won't work (maybe they do if you have a BIOS that can emulate it). There are patches around (see http://www.ussg.iu.edu/hypermail/linux/kernel/0508.3/1620.html and read the warning there, too) that add that support but they are not in the FC4 kernel afaics (for good reason as it seems). A up2date version of that patch was merged some time ago into 2.6.14-rc. So the support might show up in FC4 and probably will be in FC5. For details see http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1623c81eece58740279b8de802fa5895221f2044 -- Thorsten Leemhuis From jatsrt at gmail.com Tue Oct 18 19:23:13 2005 From: jatsrt at gmail.com (Jake Thompson) Date: Tue, 18 Oct 2005 15:23:13 -0400 Subject: Stateless Linux Update? Message-ID: <8dd7baa90510181223k6645df0dv4a7a0ee4dbf23fe6@mail.gmail.com> Hi All, I am wondering if there are any developers out there that can sound off on the state of the stateless linux project. It would be a perfect solution for what I am doing, but since it seems dead in the water, I am hesitant to move forward. Thanks, Jake T. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Tue Oct 18 21:27:49 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 18 Oct 2005 15:27:49 -0600 Subject: Stateless Linux Update? In-Reply-To: <8dd7baa90510181223k6645df0dv4a7a0ee4dbf23fe6@mail.gmail.com> References: <8dd7baa90510181223k6645df0dv4a7a0ee4dbf23fe6@mail.gmail.com> Message-ID: <80d7e4090510181427s1a3ae7a2vc5780a9d6a72268d@mail.gmail.com> On 10/18/05, Jake Thompson wrote: > Hi All, > I am wondering if there are any developers out there that can sound off on > the state of the stateless linux project. It would be a perfect solution for > what I am doing, but since it seems dead in the water, I am hesitant to move > forward. > Basically it is dead in the water, because every 2-3 months a couple of people say "It is perfect for what I am doing.. but it seems dead in the water." No one seems to have the time to go into it and yanks its guts out and rewrite. Me included :(. -- Stephen J Smoogen. CSIRT/Linux System Administrator From kyrre at solution-forge.net Tue Oct 18 21:54:09 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 18 Oct 2005 23:54:09 +0200 Subject: Stateless Linux Update? In-Reply-To: <80d7e4090510181427s1a3ae7a2vc5780a9d6a72268d@mail.gmail.com> References: <8dd7baa90510181223k6645df0dv4a7a0ee4dbf23fe6@mail.gmail.com> <80d7e4090510181427s1a3ae7a2vc5780a9d6a72268d@mail.gmail.com> Message-ID: <1129672443.13235.0.camel@localhost.localdomain> tir, 18.10.2005 kl. 23.27 skrev Stephen J. Smoogen: > On 10/18/05, Jake Thompson wrote: > > Hi All, > > I am wondering if there are any developers out there that can sound off on > > the state of the stateless linux project. It would be a perfect solution for > > what I am doing, but since it seems dead in the water, I am hesitant to move > > forward. > > > > Basically it is dead in the water, because every 2-3 months a couple > of people say "It is perfect for what I am doing.. but it seems dead > in the water." No one seems to have the time to go into it and yanks > its guts out and rewrite. Me included :(. Could Fedora Directory server help it, make it easier to admin, etc? Kyrre From rodd at clarkson.id.au Tue Oct 18 23:36:10 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 19 Oct 2005 09:36:10 +1000 Subject: bad gdm dependency In-Reply-To: References: Message-ID: <1129678570.7066.3.camel@localhost.localdomain> On Tue, 2005-10-18 at 11:25 -0500, Jason Dravet wrote: > When updating gdm from todays rawhide I get the following: > > /etc/selinux/targeted/contexts/files/file_contexts: line 1313 has invalid > context system_u:object_r:newrole_exec_t > error: Failed dependencies: > redhat-artwork >= 0:0.129-20 is needed by gdm-2.8.0.4-6.i386 > > Just an FYI, This was made clear in the rawhide report (see all the dependency listings at the bottom of the page. You can --exclude=gdm\* but then gdm is missing a file so it goes to an alternative login screen and this didn't seem to want to work either. So, don't installed redhat-artwork-0.129-2 either. ;-] Rodd -- "It's a fine line between denial and faith. It's much better on my side" From bojan at rexursive.com Wed Oct 19 01:01:57 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 19 Oct 2005 11:01:57 +1000 Subject: ACPI changes prevent IBM ThinkPad T23 from booting In-Reply-To: <20051018105427.n1usxqrwcgskksc8@imp.rexursive.com> References: <9252.194.94.224.254.1129574964.squirrel@jose.freesurf.fr> <20051018105427.n1usxqrwcgskksc8@imp.rexursive.com> Message-ID: <20051019110157.nsbm6xxp2c0c8occ@imp.rexursive.com> Quoting Bojan Smojver : > Ditto HP Pavilion ZE-4201 (i.e. it hangs). Given this notebook doesn't > do APM, I didn't even try without ACPI. The 1616 appears to be much better (read: it actually boots :-). It also works fine when compiled with suspend2, 2.2-rc8. -- Bojan From bojan at rexursive.com Wed Oct 19 01:06:47 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 19 Oct 2005 11:06:47 +1000 Subject: bad gdm dependency In-Reply-To: <1129678570.7066.3.camel@localhost.localdomain> References: <1129678570.7066.3.camel@localhost.localdomain> Message-ID: <20051019110647.mb6vpywc08okg8k0@imp.rexursive.com> Quoting Rodd Clarkson : > You can --exclude=gdm\* but then gdm is missing a file so it goes to an > alternative login screen and this didn't seem to want to work either. > > So, don't installed redhat-artwork-0.129-2 either. ;-] Actually, the little flowery thingy that pops up after the error works if you press OK first. It then enables you to actually enter username and password... -- Bojan From bojan at rexursive.com Wed Oct 19 01:31:14 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 19 Oct 2005 11:31:14 +1000 Subject: glibc/malloc_consolidate() In-Reply-To: <1129288140.20109.4.camel@coyote.rexursive.com> References: <1129288140.20109.4.camel@coyote.rexursive.com> Message-ID: <20051019113114.qxp2tlansw0swkwk@imp.rexursive.com> Quoting Bojan Smojver : > I have a feeling that recent versions of glibc in Rawhide have a problem > related to this function. It seems to be overwriting allocated memory. > Has anyone seen anything similar? Nah, don't worry about this one. Just my own stupidity :-( -- Bojan From bojan at rexursive.com Wed Oct 19 01:37:21 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 19 Oct 2005 11:37:21 +1000 Subject: rawhide report: 20051018 changes In-Reply-To: <5256d0b0510180535r71c55895t45f858a8509aaebf@mail.gmail.com> References: <200510181121.j9IBLptf003231@porkchop.devel.redhat.com> <5256d0b0510180535r71c55895t45f858a8509aaebf@mail.gmail.com> Message-ID: <20051019113721.eeif30oqb7wo40g0@imp.rexursive.com> Quoting Peter Robinson : > So does that mean we get evo 2.4.1 shortly too :-) That would be nice :-) -- Bojan From jatsrt at gmail.com Wed Oct 19 02:35:14 2005 From: jatsrt at gmail.com (Jake Thompson) Date: Tue, 18 Oct 2005 22:35:14 -0400 Subject: Stateless Linux Update? In-Reply-To: <80d7e4090510181427s1a3ae7a2vc5780a9d6a72268d@mail.gmail.com> References: <8dd7baa90510181223k6645df0dv4a7a0ee4dbf23fe6@mail.gmail.com> <80d7e4090510181427s1a3ae7a2vc5780a9d6a72268d@mail.gmail.com> Message-ID: <8dd7baa90510181935i4fbdcc48h20ce65953710b96f@mail.gmail.com> It is a shame that it is dead, perhaps I will run with what is currently there and see what I can come up with. On 10/18/05, Stephen J. Smoogen wrote: > > On 10/18/05, Jake Thompson wrote: > > Hi All, > > I am wondering if there are any developers out there that can sound off > on > > the state of the stateless linux project. It would be a perfect solution > for > > what I am doing, but since it seems dead in the water, I am hesitant to > move > > forward. > > > > Basically it is dead in the water, because every 2-3 months a couple > of people say "It is perfect for what I am doing.. but it seems dead > in the water." No one seems to have the time to go into it and yanks > its guts out and rewrite. Me included :(. > > > > -- > Stephen J Smoogen. > CSIRT/Linux System Administrator > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodd at clarkson.id.au Wed Oct 19 03:17:21 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 19 Oct 2005 13:17:21 +1000 Subject: bad gdm dependency In-Reply-To: <20051019110647.mb6vpywc08okg8k0@imp.rexursive.com> References: <1129678570.7066.3.camel@localhost.localdomain> <20051019110647.mb6vpywc08okg8k0@imp.rexursive.com> Message-ID: <1129691842.7066.6.camel@localhost.localdomain> On Wed, 2005-10-19 at 11:06 +1000, Bojan Smojver wrote: > Quoting Rodd Clarkson : > > > You can --exclude=gdm\* but then gdm is missing a file so it goes to an > > alternative login screen and this didn't seem to want to work either. > > > > So, don't installed redhat-artwork-0.129-2 either. ;-] > > Actually, the little flowery thingy that pops up after the error works > if you press OK first. It then enables you to actually enter username > and password... I couldn't get the flowery thingy to work. Didn't see any OK to push (other than the warning about the missing file), but clicked madly on things for a while just in case something was wonky(er) R -- "It's a fine line between denial and faith. It's much better on my side" From bojan at rexursive.com Wed Oct 19 04:19:41 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 19 Oct 2005 14:19:41 +1000 Subject: bad gdm dependency In-Reply-To: <1129691842.7066.6.camel@localhost.localdomain> References: <1129678570.7066.3.camel@localhost.localdomain> <20051019110647.mb6vpywc08okg8k0@imp.rexursive.com> <1129691842.7066.6.camel@localhost.localdomain> Message-ID: <20051019141941.6dreqyxzk8ss4440@imp.rexursive.com> Quoting Rodd Clarkson : > I couldn't get the flowery thingy to work. Didn't see any OK to push > (other than the warning about the missing file), but clicked madly on > things for a while just in case something was wonky(er) I also upgrade the redhat-artwork RPM (to the new, broken one), so maybe that made some difference... Not sure. -- Bojan From buildsys at redhat.com Wed Oct 19 11:14:10 2005 From: buildsys at redhat.com (Build System) Date: Wed, 19 Oct 2005 07:14:10 -0400 Subject: rawhide report: 20051019 changes Message-ID: <200510191114.j9JBEAGb008458@porkchop.devel.redhat.com> New package libsigc++ The Typesafe Signal Framework for C++. Updated Packages: checkpolicy-1.27.11-1 --------------------- * Tue Oct 18 2005 Dan Walsh 1.27.11-1 - Latest upgrade from NSA * Updated for changes to sepol policydb_index_others interface. * Tue Oct 18 2005 Dan Walsh 1.27.10-1 - Latest upgrade from NSA * Updated for changes to sepol expand_module and link_modules interfaces. curl-7.15.0-1 ------------- * Tue Oct 18 2005 Ivana Varekova 7.15.0-1 - update to 7.15.0 devhelp-0.10-6 -------------- * Tue Oct 18 2005 Christopher Aillon - 0.10-6 - Build on ppc64 dhcp-11:3.0.3-10 ---------------- * Tue Oct 18 2005 Jason Vas Dias - 11:3.0.3-10 - Allow dhclient route metrics to be specified with DHCP options: The dhcp-options(5) man-page states: 'option routers ... Routers should be listed in order of preference' and 'option static-routes ... are listed in descending order of priority' . No preference / priority could be set with previous dhclient-script . Now, dhclient-script provides: Default Gateway (option 'routers') metrics: Instead of allowing only one default gateway, if more than one router is specified in the routers option, routers following the first router will have a 'metric' of their position in the list (1,...N>1). Option static-routes metrics: If a target appears in the list more than once, routes for duplicate targets will have successively greater metrics, starting at 1. * Mon Oct 17 2005 Jason Vas Dias - 11:3.0.3-8 - further fix for bug 160655 / ISC bug 15293 - upstream patch: do NOT always strip trailing nulls in the dhcpd server - handle static-routes option properly in dhclient-script : trailing 0 octets in the 'target' IP specify the class - ie '172.16.0.0 w.x.y.z' specifies '172.16/16 via w.x.y.z'. * Fri Sep 23 2005 Jason Vas Dias - 11:3.0.3-7 - fix bug 169164: separate /var/lib/{dhcpd,dhclient} directories - fix bug 167292: update failover port info in dhcpd.conf.5; give failover ports default values in server/confpars.c epiphany-1.8.2-3 ---------------- * Tue Oct 18 2005 Christopher Aillon - 1.8.2-3 - Build on ppc64 * Tue Oct 18 2005 Christopher Aillon - 1.8.2-2 - Rebuild evolution-2.4.1-4 ----------------- * Tue Oct 18 2005 David Malcolm - 2.4.1-4 - updated patch 804 to declare e_calendar_table_process_completed_tasks * Tue Oct 18 2005 David Malcolm - 2.4.1-3 - added patch (804: evolution-2.4.1-fix-missing-declarations.patch) to fix missing declaration (thanks to Peter Robinson) * Mon Oct 17 2005 David Malcolm - 2.4.1-2 - bump e-d-s requirement to 1.4.1.1 evolution-connector-2.4.1-1 --------------------------- * Tue Oct 18 2005 David Malcolm - 2.4.1-1 - 2.4.1 - bump evolution requirement to 2.4.1 and libsoup requirement to 2.2.6.1 - fix URL to point to 2.4, not 2.3 evolution-webcal-2.4.1-1 ------------------------ * Tue Oct 18 2005 David Malcolm - 2.4.1-1 - 2.4.1 gdm-1:2.8.0.4-7 --------------- * Tue Oct 18 2005 Ray Strode 1:2.8.0.4-7 - zero-initialize message buffer, bug fixed by Josh Parson (jbparsons at usdavis.edu) (bug 160603) - fix typo in redhat-artwork requires line kernel-2.6.13-1.1617_FC5 ------------------------ * Tue Oct 18 2005 Dave Jones - 2.6.14-rc4-git6 lftp-3.3.2-1 ------------ * Tue Oct 18 2005 Jason Vas Dias - 3.3.2-1 - *** PLEASE COULD ANYONE MODIFYING lftp TEST IT BEFORE SUBMITTING! *** (and preferably contact the lftp package maintainer (me) first - thank you!) bug 171096 : 'mget files in lftp causes abort' (core dump actually) resulted from not doing so . See http://lftp.yar.ru : Recent events: 2005-10-17: lftp-3.3.2 released. Fixed a coredump caused by double-free. * Sat Oct 15 2005 Florian La Roche - 3.3.1-1 - 3.3.1 * Wed Aug 24 2005 Jason Vas Dias - 3.3.0-1 - Upgrade to upstream version 3.3.0 libselinux-1.27.12-1 -------------------- * Mon Oct 17 2005 Dan Walsh 1.27.12-1 - Update to latest from NSA * Merged get_default_context_with_rolelevel and man pages from Dan Walsh (Red Hat). * Updated call to sepol_policydb_to_image for sepol changes. * Changed getseuserbyname to ignore empty lines and to handle no matching entry in the same manner as no seusers file. * Fri Oct 14 2005 Dan Walsh 1.27.9-2 - Tell init to reexec itself in post script * Fri Oct 07 2005 Dan Walsh 1.27.9-1 - Update to latest from NSA * Changed selinux_mkload_policy to try downgrading the latest policy version available to the kernel-supported version. * Changed selinux_mkload_policy to fall back to the maximum policy version supported by libsepol if the kernel policy version falls outside of the supported range. libsemanage-1.3.23-1 -------------------- * Mon Oct 17 2005 Dan Walsh 1.3.20-1 - Update from NSA * Changed default args for load_policy to be null, as it no longer takes a pathname argument and we want to preserve booleans. * Merged move local dbase initialization patch from Ivan Gyurdiev. * Merged acquire/release read lock in databases patch from Ivan Gyurdiev. * Merged rename direct -> policydb as appropriate patch from Ivan Gyurdiev. * Added calls to sepol_policy_file_set_handle interface prior to invoking sepol operations on policy files. * Updated call to sepol_policydb_from_image to pass the handle. * Mon Oct 17 2005 Dan Walsh 1.3.20-1 - Update from NSA * Merged user and port APIs - policy database patch from Ivan Gyurdiev. * Converted calls to sepol link_packages and expand_module interfaces from using buffers to using sepol handles for error reporting, and changed direct_connect/disconnect to create/destroy sepol handles. libsepol-1.9.21-1 ----------------- * Tue Oct 18 2005 Dan Walsh 1.9.19-1 - Upgrade to latest from NSA * Changed sepol_module_package_set_file_contexts to copy the file contexts data since it is internally managed. * Added sepol_policy_file_set_handle interface to associate a handle with a policy file. * Added handle argument to policydb_from_image/to_image. * Added sepol_module_package_set_file_contexts interface. * Dropped sepol_module_package_create_file interface. * Reworked policydb_read/write, policydb_from_image/to_image, and sepol_module_package_read/write to use callback-based error reporting system rather than DEBUG. * Tue Oct 18 2005 Dan Walsh 1.9.19-1 - Upgrade to latest from NSA * Reworked link_packages, link_modules, and expand_module to use callback-based error reporting system rather than error buffering. logrotate-3.7.2-8 ----------------- * Tue Oct 18 2005 Peter Vrabec 3.7.2-8 - fix leaks of tabooExts mkinitrd-5.0.6-1 ---------------- * Tue Oct 18 2005 - 5.0.6-1 - make lvm work again mozilla-37:1.7.12-2 ------------------- * Tue Oct 18 2005 Christopher Aillon 37:1.7.12-2 - Update to 1.7.12, containing fixes for: CAN-2005-2701 CAN-2005-2702 CAN-2005-2703 CAN-2005-2704 CAN-2005-2705 CAN-2005-2706 CAN-2005-2707 CAN-2005-2968 pam-0.80-11 ----------- * Fri Oct 14 2005 Dan Walsh 0.80-11 - Eliminate fail over for getseuserbyname call * Thu Oct 13 2005 Dan Walsh 0.80-10 - Add getseuserbyname call for SELinux MCS/MLS policy * Tue Oct 04 2005 Tomas Mraz - pam_console manpage fixes (#169373) policycoreutils-1.27.14-1 ------------------------- * Tue Oct 18 2005 Dan Walsh 1.27.14-1 - Update to match NSA * Updated semodule_package for sepol interface changes. * Tue Oct 18 2005 Dan Walsh 1.27.13-1 - Update to match NSA * Updated semodule_expand/link for sepol interface changes. pup-0.1.1-1 ----------- * Tue Oct 18 2005 Jeremy Katz - 0.1.1-1 - fix silly debugging that was left in scim-tables-0.5.3-7 ------------------- * Tue Oct 18 2005 Jens Petersen - 0.5.3-7 - update to cvs head to fix various table issues with scim-tables-cvs-20051018.patch selinux-policy-strict-1.27.1-20 ------------------------------- * Tue Oct 18 2005 Dan Walsh 1.27.1-20 - Allow dhcpc to run arping * Tue Oct 18 2005 Dan Walsh 1.27.1-19 - Policy cleanups from Thomas Bleher selinux-policy-targeted-1.27.1-20 --------------------------------- * Tue Oct 18 2005 Dan Walsh 1.27.1-20 - Allow dhcpc to run arping * Tue Oct 18 2005 Dan Walsh 1.27.1-19 - Policy cleanups from Thomas Bleher shared-mime-info-0.16.cvs20051018-1 ----------------------------------- * Tue Oct 18 2005 Matthias Clasen - 0.16.cvs20051018-1 - Incorporate upstream changes vixie-cron-4:4.1-40.FC5 ----------------------- * Tue Oct 18 2005 Jason Vas Dias - 4.1-39-FC5 - *** NOTE : please do not modify vixie-cron without contacting *** *** the package maintainer (me at the moment). *** *** Or at least test it first! *** - fix bug 170830: it was not the pam_stack change - the setuid mode of crontab was dropped for some reason. - apply Dan's new getseuserbyname patch - somehow build_env() invocation was dropped - use pam_env settings. yelp-2.12.1-4 ------------- * Tue Oct 18 2005 Christopher Aillon - 2.12.1-4 - Rebuild From vonbrand at inf.utfsm.cl Wed Oct 19 12:19:13 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Wed, 19 Oct 2005 09:19:13 -0300 Subject: bad gdm dependency In-Reply-To: Your message of "Wed, 19 Oct 2005 14:19:41 +1000." <20051019141941.6dreqyxzk8ss4440@imp.rexursive.com> Message-ID: <200510191219.j9JCJDFE018037@laptop11.inf.utfsm.cl> Bojan Smojver wrote: > Quoting Rodd Clarkson : > > I couldn't get the flowery thingy to work. Didn't see any OK to push > > (other than the warning about the missing file), but clicked madly on > > things for a while just in case something was wonky(er) > I also upgrade the redhat-artwork RPM (to the new, broken one), so maybe > that made some difference... Not sure. Here the flowery worked after pressing OK on the login window. In any case, a "solution" was to get a throbber.png (out of Gnome CVS) and drop that in instead of the missing file. Will see what today brings us... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From fedora at wir-sind-cool.org Wed Oct 19 12:41:45 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 19 Oct 2005 14:41:45 +0200 Subject: rawhide report: 20051019 changes In-Reply-To: <200510191114.j9JBEAGb008458@porkchop.devel.redhat.com> References: <200510191114.j9JBEAGb008458@porkchop.devel.redhat.com> Message-ID: <20051019144145.49f91361.fedora@wir-sind-cool.org> On Wed, 19 Oct 2005 07:14:10 -0400, Build System wrote: > New package libsigc++ > The Typesafe Signal Framework for C++. > * Wed Oct 19 2005 Caolan McNamara 2.0.16-1 > - the return of libsigc++ > > * Wed Jan 09 2002 Tim Powers > - automated rebuild Ouch! :( Please note that it has been part of Fedora Extras for a long time. We don't ignore Fedora Extras, do we? From cknowlton at science.edu Wed Oct 19 13:29:35 2005 From: cknowlton at science.edu (Carlos Knowlton) Date: Wed, 19 Oct 2005 08:29:35 -0500 Subject: Stateless Linux Update? In-Reply-To: <1129672443.13235.0.camel@localhost.localdomain> References: <8dd7baa90510181223k6645df0dv4a7a0ee4dbf23fe6@mail.gmail.com> <80d7e4090510181427s1a3ae7a2vc5780a9d6a72268d@mail.gmail.com> <1129672443.13235.0.camel@localhost.localdomain> Message-ID: <43564A3F.8000007@science.edu> Kyrre Ness Sjobak wrote: >tir, 18.10.2005 kl. 23.27 skrev Stephen J. Smoogen: > > >>On 10/18/05, Jake Thompson wrote: >> >> >>>Hi All, >>> I am wondering if there are any developers out there that can sound off on >>>the state of the stateless linux project. It would be a perfect solution for >>>what I am doing, but since it seems dead in the water, I am hesitant to move >>>forward. >>> >>> >>> >>Basically it is dead in the water, because every 2-3 months a couple >>of people say "It is perfect for what I am doing.. but it seems dead >>in the water." No one seems to have the time to go into it and yanks >>its guts out and rewrite. Me included :(. >> >> > >Could Fedora Directory server help it, make it easier to admin, etc? > >Kyrre > > > That may be the piece that Stateless needs. My diskless lab is more-or-less based on a mix of stateless and older remote boot solutions. The main problem I had with Stateless was the steep learning curve of the LDAP user management, and the lack of a good intuitive user interface for it. If Fedora Directory server has the kind of UI simplicity that Active Directory does, it may be the perfect fit for Stateless. While we're talking about reworking Stateless, another feature that would be cool, would be some elegant integration of Unionfs (unionfs.org) either in addition to, or in exchange for the current "Read-only root" system. Knoppix and other LiveCDs are now using this, and it has made them much more usable, since it provides read-write emulation of large portions of the read-only filesystem. Regards, Carlos From denis at poolshark.org Wed Oct 19 17:27:05 2005 From: denis at poolshark.org (Denis Leroy) Date: Wed, 19 Oct 2005 10:27:05 -0700 Subject: rawhide report: 20051019 changes In-Reply-To: <20051019144145.49f91361.fedora@wir-sind-cool.org> References: <200510191114.j9JBEAGb008458@porkchop.devel.redhat.com> <20051019144145.49f91361.fedora@wir-sind-cool.org> Message-ID: <435681E9.6090800@poolshark.org> Michael Schwendt wrote: > On Wed, 19 Oct 2005 07:14:10 -0400, Build System wrote: > > >>New package libsigc++ >> The Typesafe Signal Framework for C++. > > >>* Wed Oct 19 2005 Caolan McNamara 2.0.16-1 >>- the return of libsigc++ >> >>* Wed Jan 09 2002 Tim Powers >>- automated rebuild > > > Ouch! :( > > Please note that it has been part of Fedora Extras for a long time. > We don't ignore Fedora Extras, do we? Yes, this is unfortunate. Also, it would not be a good idea to have libsigc++ in core and gtkmm in extras. I think you really want the same person to be maintaining those, and they need to be upgraded at the same time. Was there a specific reason to add it to core ? -denis, sigC++/gtkmm extras maintainer From dmalcolm at redhat.com Wed Oct 19 17:41:49 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 19 Oct 2005 13:41:49 -0400 Subject: rawhide report: 20051018 changes In-Reply-To: <20051019113721.eeif30oqb7wo40g0@imp.rexursive.com> References: <200510181121.j9IBLptf003231@porkchop.devel.redhat.com> <5256d0b0510180535r71c55895t45f858a8509aaebf@mail.gmail.com> <20051019113721.eeif30oqb7wo40g0@imp.rexursive.com> Message-ID: <1129743709.9817.13.camel@cassandra.boston.redhat.com> On Wed, 2005-10-19 at 11:37 +1000, Bojan Smojver wrote: > Quoting Peter Robinson : > > > So does that mean we get evo 2.4.1 shortly too :-) > > That would be nice :-) > It made it into today's rawhide; sorry about the delay. I'm using it to send this email. Dave From alan at redhat.com Wed Oct 19 17:53:56 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Oct 2005 13:53:56 -0400 Subject: Proposed Development Areas for Fedora Core 5 and Fedora Project In-Reply-To: <1129465133.7299.101.camel@deimos.baldrick.mine.nu> References: <1129465133.7299.101.camel@deimos.baldrick.mine.nu> Message-ID: <20051019175356.GF31966@devserv.devel.redhat.com> On Sun, Oct 16, 2005 at 02:18:53PM +0200, Josep Puigdemont wrote: > languages (en,de,fr,es,??) on the first two CDs. Big stuff like > openoffice-lang-support for uncommon langages only in extras?" > > That's a bad joke, right? I hope so. Not because uncommon languages are any different to other uncommon packages but because many "uncommon language" areas are those where there is a lack of network connectivity and CD is king... There are also political issues to be careful with and legal ones. Any language policy would need to have a clear justification and be transparent to avoid questions of racism in some countries. It would also want to consider legal requirements and the business/political climate. So in the case of Welsh there are good arguments for extras - fairly good connectivity, relatively small language base. On the other hand you need dual language support to get into schools/government/some other bodies as well as to earn happy points with the powers that be. French would be another example where there are definitive sensitivities and even bigger questions that need care. Consider shipping English but not French in Canada, or the size of the boom if someone put French as extras only. Alan From alan at redhat.com Wed Oct 19 17:58:39 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Oct 2005 13:58:39 -0400 Subject: FCNewInit and power management In-Reply-To: <1129448700.7318.73.camel@localhost.localdomain> References: <1129448700.7318.73.camel@localhost.localdomain> Message-ID: <20051019175839.GG31966@devserv.devel.redhat.com> On Sun, Oct 16, 2005 at 02:45:00AM -0500, Callum Lerwick wrote: > Run levels are states the system can be in. In addition to the existing > "halt" "reboot" "single user" "no network" and "normal" states, there is > "on battery" and "suspended" states just begging to be added. (I'm not > sure the best way to handle slightly different types of similar states. > We could possibly have a "battery low" state and we have "standby" > "suspend to ram" and "suspend to disk" to choose from. Do they full run > levels of their own? I'm guessing not...) Agree entirely - and one reason I do so is having done similar things years ago with a notifier setup (not init in this case). I'm dubious it belongs in init but it belongs somewhere./ The core tool that was used was Make originally (make handling the rules and dependancies) make new-ip-address new-ip-address: rebuild-nis restart-sendmail restart-sendmail: service sendmail restart etc Not sure it is the right way to do it (its hard to get it right adding scripts unlike the make model). There are many other system interesting events first login [suspend batch work/adjust xen prio] last user logged out [resume batch work/adjust xen prio] network found network lost laptop docked laptop undocked etc that affect more than just the logged in user From pbrobinson at gmail.com Wed Oct 19 17:51:26 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 19 Oct 2005 18:51:26 +0100 Subject: rawhide report: 20051018 changes In-Reply-To: <1129743709.9817.13.camel@cassandra.boston.redhat.com> References: <200510181121.j9IBLptf003231@porkchop.devel.redhat.com> <5256d0b0510180535r71c55895t45f858a8509aaebf@mail.gmail.com> <20051019113721.eeif30oqb7wo40g0@imp.rexursive.com> <1129743709.9817.13.camel@cassandra.boston.redhat.com> Message-ID: <5256d0b0510191051v23407b8fu1d628355c6406f7b@mail.gmail.com> On 10/19/05, David Malcolm wrote: > On Wed, 2005-10-19 at 11:37 +1000, Bojan Smojver wrote: > > Quoting Peter Robinson : > > > > > So does that mean we get evo 2.4.1 shortly too :-) > > > > That would be nice :-) > > > > It made it into today's rawhide; sorry about the delay. > > I'm using it to send this email. Yes, I saw and have downloaded it and recompiled for FC4. Thanks! pete From ph18 at cornell.edu Wed Oct 19 19:36:11 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Wed, 19 Oct 2005 15:36:11 -0400 Subject: Proposed Development Areas for Fedora Core 5 and Fedora Project In-Reply-To: <20051019175356.GF31966@devserv.devel.redhat.com> References: <1129465133.7299.101.camel@deimos.baldrick.mine.nu> <20051019175356.GF31966@devserv.devel.redhat.com> Message-ID: <4356A02B.5010100@cornell.edu> Alan Cox wrote: >I hope so. Not because uncommon languages are any different to other >uncommon packages but because many "uncommon language" areas are those where >there is a lack of network connectivity and CD is king... > > Yeah, but the size of the CD isn't the only thing. There is stuff that I like that comes in with the "everything install" that doesn't seem to come in with the other configurations, and it's not so clear to me how to select these things individually. Even though "en-us" is the only language I select in the menus about language support, I get a lot of language packs that I'll never care about, input method daemons that waste tens of seconds at boot, etc -- about a gigabyte of stuff that I couldn't care less about. 1 GB on the hard drive may seem like small change in 2005, but I end up installing Linux in small places all the time. An option to not install unwanted language packs could be particularly useful for people in the third world who need one language pack but not a hundred others. From bernie at develer.com Wed Oct 19 23:08:30 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 20 Oct 2005 01:08:30 +0200 Subject: [Fwd: [ANNOUNCE] X11R6.9/X11R7 Release Candidate 1 ready for testing] Message-ID: <4356D1EE.4020706@develer.com> Is anyone packaging RPMs for FC5 already? Is R7.0 planned for FC5 core? -------- Original Message -------- Date: Wed, 19 Oct 2005 14:15:29 -0400 From: Kevin E Martin To: Xorg mailing list Subject: [ANNOUNCE] X11R6.9/X11R7 Release Candidate 1 ready for testing We are pleased to announce the availability of the first full Release Candidate (RC1) for the upcoming X.Org Foundation release of X11R6.9 and X11R7. This release marks the completion of the development cycle for the modular source tree. We have tagged both the monolithic and modular trees and have prepared tarballs for you to test. The X11R6.9-RC1 tarball was created from the traditional monolithic source tree and can be found here: http://xorg.freedesktop.org/releases/X11R6.9-RC1/ X11R7-RC1 is based on the new modularized source tree and as such there are individual tarballs for each module component in the tree. The set of tarballs can be found here: http://xorg.freedesktop.org/releases/X11R7.0-RC1/ Now that RC1 has been completed, we are moving into the testing and bug fixing phase. We ask that you please test _both_ the modular and monolithic trees. If you find any problems, please file bugs in fdo's bugzilla (https://bugs.freedesktop.org/enter_bug.cgi?product=xorg) and mark them as blockers of the release bug (see below) so that they can be tracked. Also, we encourage you to discuss any issues you encounter on this mailing list. For those looking for known issues to work on, please see the list of current blocker bugs on the release bug: https://bugs.freedesktop.org/bugzilla/show_bug.cgi?id=1690 For those looking for some ideas on how to test the release, please see the following message: http://lists.freedesktop.org/archives/xorg/2005-July/008552.html In addition to running the test suite, we also encourage you to test your standard desktop and any applications you use (including OpenGL apps) on various graphics cards and hardware platforms. We would like to hear about both successes and failures. The plan is that by the time we reach RC2, we will have either fixed all of the blocker bugs or determined that they are not fixable during this release cycle. Until we tag RC2, anyone is allowed to check in bug fixes. Once we tag RC2, however, getting patches included will require approval of the release managers, so if you have bug fixes that you would like to see included in the release, please check them in ASAP. Also, note that the tree is closed for new features. If you have any questions about whether a particular patch would be considered a bug fix or a feature, ask one of the release managers to review the patch. Lastly, since the modular development cycle has now been completed, we can return to our original timetable. We have updated the schedule on the release plan page (http://wiki.x.org/wiki/X11R6970ReleasePlan) as shown here: 4 Jul 2005: Feature freeze for the monolithic source tree 1 Aug 2005: RC0 (Release Candidate 0) 18 Oct 2005: RC1 (Full release candidate) 9 Nov 2005: RC2 (Code Freeze) 30 Nov 2005: RCfinal 7 Dec 2005: X11R6.9/X11R7 Release This gives us three full weeks to test this release and fix bugs before RC2, so please test early and often! Thank you for your help with making this a successful release! Alan Coopersmith Adam Jackson Kevin E. Martin _______________________________________________ xorg mailing list xorg at lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From ivazquez at ivazquez.net Thu Oct 20 03:03:58 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 19 Oct 2005 23:03:58 -0400 Subject: [Fwd: [ANNOUNCE] X11R6.9/X11R7 Release Candidate 1 ready for testing] In-Reply-To: <4356D1EE.4020706@develer.com> References: <4356D1EE.4020706@develer.com> Message-ID: <1129777438.26357.1.camel@ignacio.lan> On Thu, 2005-10-20 at 01:08 +0200, Bernardo Innocenti wrote: > Is anyone packaging RPMs for FC5 already? > > Is R7.0 planned for FC5 core? Mike has it under control. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 gangaraju.chowki at host-technology.com Thu Oct 20 10:45:09 2005 From: gangaraju.chowki at host-technology.com (Gangaraju) Date: Thu, 20 Oct 2005 10:45:09 +0000 Subject: Complete graphical boot for Fedora Message-ID: <1129805109.3100.13.camel@localhost.localdomain> HI, AS WE ARE BOOTING THE SYSTEM WITH FEDORA LINUX-2.6.9 AFTER SELECTING AT GRUB MENU ,FIRST THE TEXT MESSAGES LIKE title fedora (2.6.9-fedora) root (hd0,0) kernel /boot/vmlinuz-2.6.9-fedora ro root=LABEL=/1 rhgb quiet initrd /boot/initrd-2.6.9-fedora.img Uncompressing the kernel Nash version-...etc welcome to fedora Starting udev Initialising hardware storage network audio THEN GRAPHICAL BOOT(X SERVER) STARTS , ALL TEXT MESSAGES ARE HIDDEN AND ONLY A IMAGE WITH PROGRESS BAR IS SHOWN. BUT I WANT TO BUILD MY KERNEL AS WHEN SELECTING AT GRUB MENU IT SHOULD NOT SHOW ANY KIND OF TEXT MESSAGES,BUT ONLY GRAPHICAL IMAGE WITH PROGRESS BAR LIKE WINDOWS OS . AND THE SAME IDEA I WANT TO IMPEMENT WHILE SHUTDOWN. I HOPE YOU UNDERSTOOD ME . PLEASE LET ME KNOW. -- Warm Regards, Gangaraju.Chowki Software Engineer, Host Technologies Ltd, Banjara Hills,Road No:12, Hyderabad. From mk at crc.dk Thu Oct 20 06:27:10 2005 From: mk at crc.dk (Mogens Kjaer) Date: Thu, 20 Oct 2005 08:27:10 +0200 Subject: FC4: SCSI tape not detect In-Reply-To: <1129624561.5046.12.camel@lesca.home.solinos.it> References: <1129624561.5046.12.camel@lesca.home.solinos.it> Message-ID: <435738BE.3060900@crc.dk> Dario Lesca wrote: > Hi, After kernel update (2.6.13-1.1526_FC4smp) the SCSI tape driver not > work, is missing. > > If I rebuild with a previous kernel (2.6.12-1.1447_FC4smp) the tape work > property. > > The server is a HP Proliant ML 350 with 2 SCSI controller > - smartarray controller (with RAID 5) > - LSI controller (with TAPE C7438A HP Model) . > > See the attach, is a previous message with two boot process, post to > fedora user list. > > I must also fill a bug report on bugzilla? > > Many thanks for your reply and sorry for my bad English > > > > ------------------------------------------------------------------------ > > Subject: > Re: HP Tape not detect after kernel update > From: > Dario Lesca > Date: > Fri, 14 Oct 2005 19:42:54 +0200 > To: > For users of Fedora Core releases > > To: > For users of Fedora Core releases > > > Il giorno ven, 14/10/2005 alle 14.55 +0200, Mogens Kjaer ha scritto: > >>Dario Lesca wrote: >> >>>Il giorno gio, 13/10/2005 alle 10.20 -0400, James Kosin ha scritto: >>> >>> >>>>-----BEGIN PGP SIGNED MESSAGE----- >>> >>> >>>>(1) Is this an IDE version or SCSI version. >>> >>>SCSI tape >> >>Is it connected to the smartarray controller? > > no, is connected to LSI SCSI controller. > > >>If so, what is logged by the new and the old >>kernel when the cciss driver is loaded? > > See 2 file attach. > ... Diff'ing the two files shows: < Fusion MPT base driver 3.01.20 < Copyright (c) 1999-2004 LSI Logic Corporation < ACPI: PCI Interrupt 0000:02:03.0[A] -> GSI 24 (level, low) -> IRQ 177 < mptbase: Initiating ioc0 bringup < ioc0: 53C1030: Capabilities={Initiator,Target} < ACPI: PCI Interrupt 0000:02:03.1[B] -> GSI 25 (level, low) -> IRQ 185 < mptbase: Initiating ioc1 bringup < input: ImPS/2 Logitech Wheel Mouse on isa0060/serio1 < ioc1: 53C1030: Capabilities={Initiator,Target} < Fusion MPT SCSI Host driver 3.01.20 < scsi0 : ioc0: LSI53C1030, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=177 < scsi1 : ioc1: LSI53C1030, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=185 < Vendor: HP Model: C7438A Rev: V312 < Type: Sequential-Access ANSI SCSI revision: 03 --- > Fusion MPT base driver 3.03.02 > Copyright (c) 1999-2005 LSI Logic Corporation 267c287 < ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 48 (level, low) -> IRQ 193 --- > ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 48 (level, low) -> IRQ 177 278c298 < cfq: depth 4 reached, tagging now on --- > input: ImPS/2 Logitech Wheel Mouse on isa0060/serio1 281,283d300 < st: Version 20050312, fixed bufsize 32768, s/g segs 256 < Attached scsi tape st0 at scsi1, channel 0, id 5, lun 0 < st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 4294967295 I.e. the problem is, that the MPT scsi driver version 3.03.02 doesn't recognize the tape device. You could send an email to the address mentioned in the linux/drivers/message/fusion/mptscsih.c file and ask them if they have a fix. 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 jfrieben at freesurf.fr Thu Oct 20 09:31:41 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Thu, 20 Oct 2005 11:31:41 +0200 (CEST) Subject: [Fwd: [ANNOUNCE] X11R6.9/X11R7 Release Candidate 1 ready for In-Reply-To: <4356D1EE.4020706@develer.com> References: <4356D1EE.4020706@develer.com> Message-ID: <24875.194.94.224.254.1129800701.squirrel@arlette.freesurf.fr> Have a look at ftp://people.redhat.com/mharris/symphony-x/ I rebuilt the binary RPMs on a text-only FC4 system and managed to get a basic X setup work running the "twm" window manager. Still, there are some issues reported by me on this list about 2 weeks ago. Today, the packages are still those of 10/06/05. From briot at adacore.com Thu Oct 20 09:36:21 2005 From: briot at adacore.com (Emmanuel Briot) Date: Thu, 20 Oct 2005 11:36:21 +0200 Subject: Rawhide issue with fontconfig Message-ID: <43576515.8080007@adacore.com> I have recently updated fontconfig (now version 2.3.91.cvs20051017-1). I had a duplicate on my system with fontconfig-2.3.2-1 (not removed when doing the update). I therefore removed the second one, and when running fc-cache, I get the following error: Fontconfig error: "conf.d", line 1: no element found From what I could see, the issue comes from /etc/fonts/fonts.conf, which contains the line: conf.d since conf.d is in fact a subdirectory, this is of course incorrect. Commenting out that line removes the error. I have tried to replace the line with conf.d/40-blacklist-fonts.conf conf.d/50-no-hint-fonts.conf conf.d/autohint.conf no-bitmaps.conf no-sub-pixel.conf sub-pixel.conf unhinted.conf yes-bitmaps.conf but in fact the first one contains unknown tags: Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 7: unknown element "selectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 8: unknown element "rejectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 9: unknown element "rejectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 10: unknown element "rejectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 11: unknown element "rejectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 12: unknown element "rejectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 13: unknown element "rejectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 14: unknown element "rejectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 15: unknown element "rejectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 16: unknown element "rejectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 17: unknown element "rejectfont" Fontconfig warning: "conf.d/40-blacklist-fonts.conf", line 18: unknown element "rejectfont" and no-sub-pixel.conf and sub-pixel.conf seem to conflict with each other, so I am not sure what the real intent is here. I will simply remove the conf.d line since the system seems to work correctly without it From fedora at wir-sind-cool.org Thu Oct 20 10:43:49 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 20 Oct 2005 12:43:49 +0200 Subject: libsigc++ (was: Re: rawhide report: 20051019 changes) In-Reply-To: <435681E9.6090800@poolshark.org> References: <200510191114.j9JBEAGb008458@porkchop.devel.redhat.com> <20051019144145.49f91361.fedora@wir-sind-cool.org> <435681E9.6090800@poolshark.org> Message-ID: <20051020124349.70fe848a.fedora@wir-sind-cool.org> On Wed, 19 Oct 2005 10:27:05 -0700, Denis Leroy wrote: > Michael Schwendt wrote: > > On Wed, 19 Oct 2005 07:14:10 -0400, Build System wrote: > > > > > >>New package libsigc++ > >> The Typesafe Signal Framework for C++. > > > > > >>* Wed Oct 19 2005 Caolan McNamara 2.0.16-1 > >>- the return of libsigc++ > >> > >>* Wed Jan 09 2002 Tim Powers > >>- automated rebuild > > > > > > Ouch! :( > > > > Please note that it has been part of Fedora Extras for a long time. > > We don't ignore Fedora Extras, do we? > > Yes, this is unfortunate. Also, it would not be a good idea to have > libsigc++ in core and gtkmm in extras. I think you really want the same > person to be maintaining those, and they need to be upgraded at the same > time. > > Was there a specific reason to add it to core ? > > -denis, sigC++/gtkmm extras maintainer > Adding to that, the package currently conflicts with libsigc++20 from Extras since it upgrades the older one for the older API, which we've kept as libsigc++. It is based on an old package from Red Hat Linux, which has flaws. It owns /usr/share/doc, contains libsigc-2.0.so in the wrong package, contains duplicates of the %doc files from the main package in the -devel package, should require pkgconfig in the -devel package, and moves the html docs to a different directory. A copy of the GPL ought to be included also in the Extras package, btw. From buildsys at redhat.com Thu Oct 20 11:20:15 2005 From: buildsys at redhat.com (Build System) Date: Thu, 20 Oct 2005 07:20:15 -0400 Subject: rawhide report: 20051020 changes Message-ID: <200510201120.j9KBKF9e022621@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.5.1-2 ---------------------- * Thu Oct 20 2005 Christopher Aillon - 0.5.1-2 - NetworkManager 0.5.1 apr-0.9.7-2 ----------- * Thu Oct 20 2005 Joe Orton 0.9.7-2 - update to 0.9.7 audit-1.0.7-1 ------------- * Wed Oct 19 2005 Steve Grubb 1.0.7-1 - Update reports - Add new message types - Bug fixes bind-24:9.3.1-20 ---------------- * Wed Oct 19 2005 Jason Vas Dias - 24.9.3.1-20 - Allow the -D enable D-BUS option to be used within bind-chroot . - fix bug 171226: supply some documentation for pgsql SDB . ethereal-0.10.13-1 ------------------ * Thu Oct 20 2005 Radek Vokal 0.10.13-1 - upgrade to 0.10.13 - CAN-2005-3241 Multiple ethereal issues fixed (#171063) gdm-1:2.8.0.4-8 --------------- * Thu Oct 20 2005 Ray Strode 1:2.8.0.4-8 - redhat-artwork was busted, require new version gnome-panel-2.12.1-3 -------------------- * Thu Oct 20 2005 Matthias Clasen 2.12.1-3 - Add trash applet to the default setup * Mon Oct 17 2005 Matthias Clasen 2.12.1-2 - Change the "Cancel" button on the "add to" dialog to "Close" gnome-power-manager-0.2.8-1 --------------------------- * Wed Oct 19 2005 Ray Strode 0.2.8-1 - update to 0.2.8 gnome-vfs2-2.12.1.1-2 --------------------- * Wed Oct 19 2005 Matthias Clasen 2.12.1.1-2 - Fix the cache handling in xdgmime gtk2-2.8.6-2 ------------ * Wed Oct 19 2005 Matthias Clasen 2.8.6-2 - Sync to upstream xdgmime less-392-1 ---------- * Wed Oct 19 2005 Jindrich Novy 392-1 - update to less-392 - fixes #122847 and enhances UTF8 support libsemanage-1.3.24-1 -------------------- * Mon Oct 17 2005 Dan Walsh 1.3.24-1 - Update from NSA * Merged default database from Ivan Gyurdiev. * Merged removal of connect requirement in policydb backend from Ivan Gyurdiev. * Merged commit locking fix and lock rename from Joshua Brindle. * Merged transaction rollback in lock patch from Joshua Brindle. * Changed default args for load_policy to be null, as it no longer takes a pathname argument and we want to preserve booleans. * Merged move local dbase initialization patch from Ivan Gyurdiev. * Merged acquire/release read lock in databases patch from Ivan Gyurdiev. * Merged rename direct -> policydb as appropriate patch from Ivan Gyurdiev. * Added calls to sepol_policy_file_set_handle interface prior to invoking sepol operations on policy files. * Updated call to sepol_policydb_from_image to pass the handle. man-pages-ja-20051015-1 ----------------------- * Thu Oct 20 2005 Akira TAGOH - 20051015-1 - updates to 20051015. - man-pages-ja-20050215-shmget.patch: no longer needed. merged into upstream. mod_perl-2.0.1-2 ---------------- * Thu Oct 20 2005 Joe Orton 2.0.1-2 - rebuild mtools-3.9.10-1 --------------- * Wed Oct 19 2005 Tim Waugh 3.9.10-1 - 3.9.10. openssh-4.2p1-4 --------------- * Tue Oct 18 2005 Dan Walsh 4.2p1-4 - Change selinux patch to use get_default_context_with_rolelevel in libselinux. pup-0.1.2-1 ----------- * Wed Oct 19 2005 Jeremy Katz - 0.1.2-1 - fix using file:/// paths for repos - error correctly when there's an unresolvable dependency pykickstart-0.4-1 ----------------- * Wed Oct 19 2005 Chris Lumens 0.4-1 - Correct deprecated attribute on options. - Added programming documentation. redhat-artwork-0.129-3 ---------------------- * Thu Oct 20 2005 Ray Strode 0.129-3 - some of the throbber patch got upstreamed apparently, patch it out selinux-policy-strict-1.27.1-21 ------------------------------- * Wed Oct 19 2005 Dan Walsh 1.27.1-21 - Fixes for MLS - Allow dhcp to write /etc/localtime selinux-policy-targeted-1.27.1-21 --------------------------------- * Wed Oct 19 2005 Dan Walsh 1.27.1-21 - Fixes for MLS - Allow dhcp to write /etc/localtime squid-7:2.5.STABLE11-5 ---------------------- * Thu Oct 20 2005 Martin Stransky 7:2.5.STABLE11-5 - fix for #171213 - CVE-2005-3258 Squid crash due to malformed FTP response - more fixes from upstream system-config-network-1.3.28-1 ------------------------------ * Mon Oct 10 2005 Harald Hoyer - 1.3.28 - fixed picture paths in glade files - fixed cancel case of passphrase dialog * Mon Oct 10 2005 Harald Hoyer - 1.3.27 - use new pam stack replacement - added OnParent for Alias Devices - added SPI and better key generation for ipsec - corrected column handling in main window - GUI liftup - added AVM Fritz!PCI v2.0 ISDN card to ISDN Hardwarelist (bug 134605) - remove /etc/sysconfig/isdncard, if no ISDN is configured yelp-2.12.1-5 ------------- * Wed Oct 19 2005 Jeremy Katz - 2.12.1-5 - build on ppc64 now that we have mozilla there again From rdieter at math.unl.edu Thu Oct 20 12:08:25 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 20 Oct 2005 07:08:25 -0500 Subject: Rawhide issue with fontconfig In-Reply-To: <43576515.8080007@adacore.com> References: <43576515.8080007@adacore.com> Message-ID: Emmanuel Briot wrote: > > > I have recently updated fontconfig (now version 2.3.91.cvs20051017-1). I > had a duplicate on my system with fontconfig-2.3.2-1 (not removed when > doing the update). Shouldn't these problems be reported to http://bugzilla.redhat.com/ ? -- Rex From wtogami at redhat.com Thu Oct 20 12:51:35 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 20 Oct 2005 08:51:35 -0400 Subject: Rawhide issue with fontconfig In-Reply-To: References: <43576515.8080007@adacore.com> Message-ID: <435792D7.8080505@redhat.com> Rex Dieter wrote: > Emmanuel Briot wrote: > >> >> >> I have recently updated fontconfig (now version 2.3.91.cvs20051017-1). I >> had a duplicate on my system with fontconfig-2.3.2-1 (not removed when >> doing the update). > > > Shouldn't these problems be reported to http://bugzilla.redhat.com/ ? > > -- Rex > I ran into a similar issue while doing yum update on my rawhide x86_64 system. I had to install both archs of fontconfig manually, then yum was able to proceed. I'll see if I can reproduce this later today... Warren Togami wtogami at redhat.com From mike at plan99.net Thu Oct 20 15:32:39 2005 From: mike at plan99.net (Mike Hearn) Date: Thu, 20 Oct 2005 16:32:39 +0100 Subject: Supporting third party software in /usr/local Message-ID: Hi, Every so often people pop up and give us (the autopackage team) flak for using a default install path of /usr instead of /usr/local. The reasoning is that as RPM and friends don't check to see if the software they're installing already exists on the filesystem, it's possible for a user to install some program (say Inkscape, or AbiWord) from the upstream autopackage and then install an RPM over the top by accident, for instance by doing a group install, or if the application is resolved as part of some other dependency (deps on applications are bizarre in my mind, but they do happen ...) This set of problems could be traded for an entirely different set (on Fedora at least) if /usr/local was fully supported. Currently there are lots of ways in which software installed here is a second class citizen. These problems affect source code installs too as most configure scripts default to /usr/local. Here are a few I noticed a while back - apologies if these have changed in rawhide or if I am misremembering: * /etc/ld.so.conf doesn't include /usr/local/lib * /etc/xdg/menus/applications.menu doesn't merge /usr/local/share/applications [bug #117671] * $XDG_DATA_DIRS doesn't include /usr/local/share * $BONOBO_ACTIVATION_PATH doesn't include /usr/local/lib/bonobo/servers * $KDEDIRS doesn't include /usr/local * $PKG_CONFIG_PATH doesn't include /usr/lib/pkgconfig * DBUS configuration file does not /usr/local/etc/dbus-1/system.d * fontconfig doesn't have a element for /usr/local/share/fonts * Actually I'm not even sure regular $PATH includes /usr/local/bin, but maybe that was some other distro ... And at least one weird oddity: * Info looks in /usr/share/info and /usr/local/info. Is it top level or not? I think there are some more I missed. I filed a bug for the menu entries long ago as this is the most visible thing that breaks when we install out of /usr but I guess for obvious reasons I didn't bother filing bugs for all of them. There are just too many and there's bound to be some I forget or miss out. As this is a policy issue that touches many packages, I think maybe a better solution would be for the owner of each package to take a 2-minute break and think "Does my package have a $FOO_DIR or foo type configuration option? If so, should it include /usr/local?" and then just go in and fix it. The issues are normally with config files, startup scripts and so on anyway. I know I shouldn't really make requests without patches, but in most cases it'd be faster for the relevant maintainer to just add the line themselves than read a patch then apply it. Does anybody have any objections to doing this? If not, what is the best thing for me to do - file a single bug and just CC the maintainers of any affected packages I can think of? thanks -mike From darko.ilic at gmail.com Thu Oct 20 18:08:53 2005 From: darko.ilic at gmail.com (Darko Ilic) Date: Thu, 20 Oct 2005 20:08:53 +0200 Subject: SquashFS? Message-ID: <200510202008.53326.darko.ilic@gmail.com> Hello, My name is Darko Ilic, I`m working on Fedora live CD generator named Kadischi (http://fedoraproject.org/wiki/Kadischi). Live CDs that Kadischi generates currently use zisofs, but IMHO it would be much better to make them with SquashFS. According to the benchmark results found at http://kerneltrap.org/files/PERFORMANCE.README.txt SquashFS is far superior. It is faster and has higher compression ratio, and both of the mentioned problems are present on live CDs Kadischi generates. I wanted to ask what are the opinions on the subject, and is there any chance for SquashFS to make it's way into Fedora kernel by FC5? I`ve heard it was submitted to LKML recently and there was some discussions surrounding that and that it is a likely candidate for the upstream kernel. Since we`re trying to make the first Fedora live CDs for FC5, it would be really nice to have SquashFS, because it would improve the quality of the live CDs dramatically. -- Darko From rdieter at math.unl.edu Thu Oct 20 18:20:56 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 20 Oct 2005 13:20:56 -0500 Subject: SquashFS? In-Reply-To: <200510202008.53326.darko.ilic@gmail.com> References: <200510202008.53326.darko.ilic@gmail.com> Message-ID: <4357E008.6040403@math.unl.edu> Darko Ilic wrote: > I wanted to ask what are the opinions on the subject, and is there any chance > for SquashFS to make it's way into Fedora kernel by FC5? I`ve heard it was > submitted to LKML recently and there was some discussions surrounding that > and that it is a likely candidate for the upstream kernel. If it makes it upstream, then most likely, yes. -- Rex From sopwith at redhat.com Thu Oct 20 18:56:55 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 20 Oct 2005 14:56:55 -0400 (EDT) Subject: Fedora web team In-Reply-To: <1126361756.3139.22.camel@localhost.localdomain> References: <1123782360.8431.15.camel@cutter> <42FC0385.2080807@gmail.com> <1123810968.12234.2.camel@cutter> <1124967312.2558.7.camel@localhost.localdomain> <1125281847.4613.3.camel@localhost.localdomain> <1125367535.3327.33.camel@localhost.localdomain> <1126361756.3139.22.camel@localhost.localdomain> Message-ID: Hey all, It seems like there are at least a few people who are interested in reworking the Fedora web site. I think it would be good to have more coordination on our efforts. So, please visit: http://fedoraproject.org/wiki/Fedora/Web and let's all get together and figure things out. This may just be my way of catching up with everyone else who is already working nicely together - please bring me up to speed. :) Best, -- Elliot From kwade at redhat.com Thu Oct 20 23:07:16 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 20 Oct 2005 16:07:16 -0700 Subject: no central call for FC release notes, see your beat writer Message-ID: <1129849636.18168.562.camel@erato.phig.org> There is no central call for release notes, no central draw. This is the last single-source nagmail about release notes for Fedora. You and your beat writer ... http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats#assignments ... can work out arrangements as you see fit. Submissions can come into: * Wiki ( http://fedoraproject.org/wiki/Docs/Beats ) * Bugzilla against Fedora Documentation > Release Notes * CVS commit keyword *docs* * Email to beat writer * Email to relnotes at fedoraproject.org * Whatever else you dream of cheers, Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- 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 mpeters at mac.com Thu Oct 20 23:26:59 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 20 Oct 2005 16:26:59 -0700 Subject: Supporting third party software in /usr/local In-Reply-To: References: Message-ID: <1129850819.2040.15.camel@locolhost.localdomain> On Thu, 2005-10-20 at 16:32 +0100, Mike Hearn wrote: > > Here are a few I noticed a while back - apologies if these have changed in > rawhide or if I am misremembering: > > * /etc/ld.so.conf doesn't include /usr/local/lib IMHO that is a bug and should be fixed. However - you can add a directory via placing a file in /etc/ld.so.conf.d/ > * /etc/xdg/menus/applications.menu doesn't merge > /usr/local/share/applications [bug #117671] I believe the standard is that they go into /usr/share/applications. To avoid conflict - desktop-file-install should be used specifying the vendor. For example - in Fedora Extras we use --vendor=fedora which results in the desktop files having a prefix of fedora- If desktop files conflict between two vendors, it is imho a packaging bug by one (or both) vendors. Using desktop-file-install also ensures that desktop file isn't completely broken. > * $XDG_DATA_DIRS doesn't include /usr/local/share That imho is a bug > * $BONOBO_ACTIVATION_PATH doesn't include /usr/local/lib/bonobo/servers I can't speak to that. > * $KDEDIRS doesn't include /usr/local I can't speak to that. > * $PKG_CONFIG_PATH doesn't include /usr/lib/pkgconfig I assume you mean /usr/local/lib/pkgconfig It probably should be up to the script of a devel package to add that if it needs that but it isn't set already. You could install a script in /etc/profile.d/ if the PKG_CONFIG path doesn't include the path to your pkgconfig files. > * DBUS configuration file does not /usr/local/etc/dbus-1/system.d I can't speak to that. > * fontconfig doesn't have a element for /usr/local/share/fonts That I consider to be a bug, since the file where it is set has a big warning about not editing it. But perhaps there is a way to add to the searched patch via /etc/fonts/local.conf or in new fontconfig, /etc/fonts/conf.d ? Speaking of not editing that file, it also includes the fake italic and fake bold instructions, which I think in the fontconfig 2.4 branch should be files in /etc/fonts/conf.d/ so they can be disabled w/o editing the "do not edit" config file > * Actually I'm not even sure regular $PATH includes /usr/local/bin, but > maybe that was some other distro ... /usr/local/bin is in my path - if a distro does not include it, it is imho a bug. From tjarls at iee.lu Thu Oct 20 23:52:02 2005 From: tjarls at iee.lu (Charles Lopes) Date: Fri, 21 Oct 2005 01:52:02 +0200 Subject: FC4: SCSI tape not detect In-Reply-To: <1129624561.5046.12.camel@lesca.home.solinos.it> References: <1129624561.5046.12.camel@lesca.home.solinos.it> Message-ID: <43582DA2.6000805@iee.lu> Dario Lesca wrote: > Hi, After kernel update (2.6.13-1.1526_FC4smp) the SCSI tape driver not > work, is missing. > > If I rebuild with a previous kernel (2.6.12-1.1447_FC4smp) the tape work > property. > > The server is a HP Proliant ML 350 with 2 SCSI controller > - smartarray controller (with RAID 5) > - LSI controller (with TAPE C7438A HP Model) . > > See the attach, is a previous message with two boot process, post to > fedora user list. > > I must also fill a bug report on bugzilla? > > Many thanks for your reply and sorry for my bad English > > Starting with 2.6.13, the low level access for the fusion driver has been splitted out into mptfc.ko (fiber channel) and mptspi.ko (SCSI parallel interface). Try loading one of these (probably mptspi). From mihamina.rakotomandimby at etu.univ-orleans.fr Fri Oct 21 00:50:33 2005 From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina) Date: Fri, 21 Oct 2005 02:50:33 +0200 Subject: problem installing BIND Message-ID: <1129855833.2279.471.camel@localhost.localdomain> Hi, I'm running Fedora core 4 (testing repos enabled): # yum install bind: [...] Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for bind to pack into transaction set. bind-9.3.1-12_FC4.i386.rp 100% |=========================| 39 kB ---> Package bind.i386 24:9.3.1-12_FC4 set to be updated --> Running transaction check --> Processing Dependency: bind-utils = 24:9.3.1-12_FC4 for package:bind --> Processing Dependency: bind-libs = 24:9.3.1-12_FC4 for package: bind --> Finished Dependency Resolution Error: Missing Dependency: bind-utils = 24:9.3.1-12_FC4 is needed by package bind Error: Missing Dependency: bind-libs = 24:9.3.1-12_FC4 is needed by package bind PS: Crossposted message, feel free to follow up where you want. -- Administration & Formation ? l'administration de serveurs d?di?s: http://www.google.fr/search?q=aspo+infogerance+serveur From mikep at mi-consultants.com Fri Oct 21 01:02:03 2005 From: mikep at mi-consultants.com (Michael J. Pawlowsky) Date: Thu, 20 Oct 2005 21:02:03 -0400 Subject: NVIDIA Raid Drivers for Fedora Core 4 Message-ID: <43583E0B.7010808@mi-consultants.com> I have a ASUS K8N-DL Motherboard with a NVIDIA RAID controller on it. Although I can create the Raids using the tool at bootup (After the bios loads), Fedora Core 4 Installation sees the drives as 4 seperate drives and not 2 RAID drives. Has anyone been able to get the NVIDIA Raid Controllers to work in Core 4? Thanks, Mike From perbj at stanford.edu Fri Oct 21 01:28:10 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 20 Oct 2005 18:28:10 -0700 Subject: Supporting third party software in /usr/local In-Reply-To: References: Message-ID: <1129858090.3263.32.camel@localhost.localdomain> On Thu, 2005-10-20 at 16:32 +0100, Mike Hearn wrote: > * /etc/xdg/menus/applications.menu doesn't merge > /usr/local/share/applications [bug #117671] Have you checked that this one doesn't work on something recent? I have dumped .desktop files in /usr/share/applications on several FC4 installations and they got picked up and added to the (Gnome) menu (haven't checked KDE though). Looking at /etc/xdg/menus/aplications I'd assume that it's the line that does it (note that there is actually no entry for /usr/share/applications either!) I can't find where the defaults come from at the moment, perhaps they're hardcoded in the panel? /Per From toshio at tiki-lounge.com Fri Oct 21 01:35:59 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 20 Oct 2005 18:35:59 -0700 Subject: SquashFS? In-Reply-To: <4357E008.6040403@math.unl.edu> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> Message-ID: <1129858560.3260.32.camel@localhost> On Thu, 2005-10-20 at 13:20 -0500, Rex Dieter wrote: > Darko Ilic wrote: > > > I wanted to ask what are the opinions on the subject, and is there any chance > > for SquashFS to make it's way into Fedora kernel by FC5? I`ve heard it was > > submitted to LKML recently and there was some discussions surrounding that > > and that it is a likely candidate for the upstream kernel. > > If it makes it upstream, then most likely, yes. I'd like to see a quality Fedora LiveCD. At my day job we're evaluating livecds for kiosks, recovery, and lab installs. What has struck me in recent days is that they're _all_ Debian based. If we want this to change, we need to create liveCDs that squashfs and unionfs are both kernel modules that are pretty standard fare in the liveCD world but are not part of the mainline kernel. We need to include them in Fedora in order to advance our reputation in the liveCD arena. There are three alternatives here. 1) We don't care about LiveCDs. If you want to make a serious LiveCD based on Fedora, you have to fork and maintain some packages outside of the Fedora arena. 2) We get these integrated into Core despite the fact that they aren't upstream [Example: GFS] 3) We integrate these modules in Extras. Is this important enough to Red Hat that Core manpower can be expended to make this happen? Or can we finally muster the will to package kernel modules for Extras _knowing_ that the policies and proceedures we set out in the first cut will need to be revised, possibly with a great deal of pain? Sorry for the emotion but kernel modules are currently stuck in a very undesirable limbo that's not doing Fedora as a whole any good. -Toshio PS - I discovered that work has one old Puppy Linux disk so that's one non-Debian distro... It's not Fedora-based, 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 bernie at develer.com Fri Oct 21 01:36:22 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 21 Oct 2005 03:36:22 +0200 Subject: Supporting third party software in /usr/local In-Reply-To: <1129850819.2040.15.camel@locolhost.localdomain> References: <1129850819.2040.15.camel@locolhost.localdomain> Message-ID: <43584616.3010608@develer.com> Michael A. Peters wrote: >> * Actually I'm not even sure regular $PATH includes /usr/local/bin, but >> maybe that was some other distro ... > > /usr/local/bin is in my path - if a distro does not include it, it is > imho a bug. It's there, but it comes after /bin and /usr/bin, making it useless for people who install replacement versions of vendor packages. I use this workaround in my /etc/profile.d/zzz_profile.sh: # reorder local PATH=/usr/local/bin:`echo $PATH | sed -e 's,:*/usr/local/bin,,g' -e 's,:*/usr/local/sbin,,g'` test "$UID" = 0 && PATH=/usr/local/sbin:$PATH -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From jkeating at j2solutions.net Fri Oct 21 01:53:23 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 Oct 2005 18:53:23 -0700 Subject: NVIDIA Raid Drivers for Fedora Core 4 In-Reply-To: <43583E0B.7010808@mi-consultants.com> References: <43583E0B.7010808@mi-consultants.com> Message-ID: <1129859603.28454.53.camel@yoda.loki.me> On Thu, 2005-10-20 at 21:02 -0400, Michael J. Pawlowsky wrote: > Has anyone been able to get the NVIDIA Raid Controllers to work in > Core 4? Wrong email list. But those are not likely to work in FC4. FC5 is supposed to include the dmraid module set which I do believe would allow for this raid array to be accessed as such. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From mpeters at mac.com Fri Oct 21 02:02:14 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 20 Oct 2005 19:02:14 -0700 Subject: Supporting third party software in /usr/local In-Reply-To: <43584616.3010608@develer.com> References: <1129850819.2040.15.camel@locolhost.localdomain> <43584616.3010608@develer.com> Message-ID: <1129860134.2040.19.camel@locolhost.localdomain> On Fri, 2005-10-21 at 03:36 +0200, Bernardo Innocenti wrote: > Michael A. Peters wrote: > > >> * Actually I'm not even sure regular $PATH includes /usr/local/bin, but > >> maybe that was some other distro ... > > > > /usr/local/bin is in my path - if a distro does not include it, it is > > imho a bug. > > It's there, but it comes after /bin and /usr/bin, making it > useless for people who install replacement versions of vendor > packages. It should come after /bin and /usr/bin - system installed administration scripts may expect behavior specific to the version installed with the system. A user can re-arrange the path if they need to - or create an alias if they need to (probably better). From lists at ralii.com Fri Oct 21 02:59:19 2005 From: lists at ralii.com (Robert Locke) Date: Thu, 20 Oct 2005 22:59:19 -0400 Subject: Supporting third party software in /usr/local In-Reply-To: <1129860134.2040.19.camel@locolhost.localdomain> References: <1129850819.2040.15.camel@locolhost.localdomain> <43584616.3010608@develer.com> <1129860134.2040.19.camel@locolhost.localdomain> Message-ID: <1129863559.5525.4.camel@rltp40f4.ralii.com> On Thu, 2005-10-20 at 19:02 -0700, Michael A. Peters wrote: > On Fri, 2005-10-21 at 03:36 +0200, Bernardo Innocenti wrote: > > Michael A. Peters wrote: > > > > >> * Actually I'm not even sure regular $PATH includes /usr/local/bin, but > > >> maybe that was some other distro ... > > > > > > /usr/local/bin is in my path - if a distro does not include it, it is > > > imho a bug. > > > > It's there, but it comes after /bin and /usr/bin, making it > > useless for people who install replacement versions of vendor > > packages. > > It should come after /bin and /usr/bin - system installed administration > scripts may expect behavior specific to the version installed with the > system. > > A user can re-arrange the path if they need to - or create an alias if > they need to (probably better). > Actually, isn't the default regular user PATH variable hard coded in to /bin/bash? And, I believe it is set to "/usr/local/bin:/bin:/usr/bin", at least on FC4, it is. Then the scripts modify/replace that..... --Rob From mpeters at mac.com Fri Oct 21 05:06:12 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 20 Oct 2005 22:06:12 -0700 Subject: Supporting third party software in /usr/local In-Reply-To: <1129863559.5525.4.camel@rltp40f4.ralii.com> References: <1129850819.2040.15.camel@locolhost.localdomain> <43584616.3010608@develer.com> <1129860134.2040.19.camel@locolhost.localdomain> <1129863559.5525.4.camel@rltp40f4.ralii.com> Message-ID: <1129871173.2040.37.camel@locolhost.localdomain> On Thu, 2005-10-20 at 22:59 -0400, Robert Locke wrote: > > Actually, isn't the default regular user PATH variable hard coded in > to /bin/bash? And, I believe it is set to > "/usr/local/bin:/bin:/usr/bin", at least on FC4, it is. Heh yeah - you're right. From fedora at leemhuis.info Fri Oct 21 05:10:23 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 21 Oct 2005 07:10:23 +0200 Subject: kernel-modules in extras (Was: Re: SquashFS?) In-Reply-To: <1129858560.3260.32.camel@localhost> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> Message-ID: <1129871423.13028.10.camel@thl.ct.heise.de> Am Donnerstag, den 20.10.2005, 18:35 -0700 schrieb Toshio Kuratomi: >[...] >3) We integrate these modules in Extras. Just out of curiosity: Can squashfs or unionfs build as a module without patching the core kernel? > Or can we finally muster the will to package > kernel modules for Extras _knowing_ that the policies and proceedures we > set out in the first cut will need to be revised, possibly with a great > deal of pain? > > Sorry for the emotion but kernel modules are currently stuck in a very > undesirable limbo that's not doing Fedora as a whole any good. http://www.fedoraproject.org/wiki/FedoraExtrasSchedule Task Name, Owner, Priority, Target Date, Notes Kernel module standardization, ThorstenLeemhuis, 1, soon, Good discussion underway, will continue to drive forward [...] Might take some more weeks but we're getting somewhere. Stay tuned on the usual mailing list, but give us some days to sort everything out. CU thl From toshio at tiki-lounge.com Fri Oct 21 05:51:43 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 20 Oct 2005 22:51:43 -0700 Subject: kernel-modules in extras (Was: Re: SquashFS?) In-Reply-To: <1129871423.13028.10.camel@thl.ct.heise.de> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> <1129871423.13028.10.camel@thl.ct.heise.de> Message-ID: <1129873903.3260.56.camel@localhost> On Fri, 2005-10-21 at 07:10 +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 20.10.2005, 18:35 -0700 schrieb Toshio Kuratomi: > >[...] > >3) We integrate these modules in Extras. > > Just out of curiosity: Can squashfs or unionfs build as a module > without patching the core kernel? > Damn, good catch. unionfs requires no patching but squashfs is a little entangled and requires patching the kernel in order to build. So unionfs is a good candidate for Extras but squashfs needs Core support. > http://www.fedoraproject.org/wiki/FedoraExtrasSchedule > > Task Name, Owner, Priority, Target Date, Notes > Kernel module standardization, ThorstenLeemhuis, 1, soon, Good discussion underway, will continue to drive forward > [...] > > Might take some more weeks but we're getting somewhere. Stay tuned on > the usual mailing list, but give us some days to sort everything out. Ah great! I'll watch for further postings from you, then :-) -Toshio -------------- 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 mpeters at mac.com Fri Oct 21 06:40:29 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 20 Oct 2005 23:40:29 -0700 Subject: bad gdm dependency In-Reply-To: <20051019110647.mb6vpywc08okg8k0@imp.rexursive.com> References: <1129678570.7066.3.camel@localhost.localdomain> <20051019110647.mb6vpywc08okg8k0@imp.rexursive.com> Message-ID: <1129876829.2040.40.camel@locolhost.localdomain> On Wed, 2005-10-19 at 11:06 +1000, Bojan Smojver wrote: > > Actually, the little flowery thingy that pops up after the error works > if you press OK first. btw - that "flowery thingy" is my normal gdm login screen (by choice) - it's a nice design. But yes - I noticed the same thing - have to click on "OK" first, and then you can enter a username. From mikem at cyber.com.au Fri Oct 21 06:59:38 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Fri, 21 Oct 2005 16:59:38 +1000 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: References: Message-ID: <1129877978.3410.49.camel@localhost.localdomain> On Thu, 2005-10-20 at 16:32 +0100, Mike Hearn wrote: > Hi, > > Every so often people pop up and give us (the autopackage team) flak for > using a default install path of /usr instead of /usr/local. > > The reasoning is that as RPM and friends don't check to see if the > software they're installing already exists on the filesystem, Yes. That's correct. The only software that in considered to be installed is that which is properly installed, using the same method as every other app. > This set of problems could be traded for an entirely different set (on > Fedora at least) if /usr/local was fully supported. Why should Fedora and Red Hat encourage installing software in a non-standard method? How is it easier to have an application that installs in a totally different method from every other app on my system? This isn't a defence of RPM. It's a defence of good systems management. One way to install software is better than two. How do I find out a list of my most recent apps, if half of them are installed one way and half another? How do I find out a list of the largest installed apps, if half of them are installed one way and half another? How do I simply find out what's even installed, if half of them are installed one way and half another? > Currently there are > lots of ways in which software installed here is a second class citizen. Yes! Because important software shouldn't be installed there. Sweet isn't it? > These problems affect source code installs too as most configure scripts > default to /usr/local. Yes, but most applications are installed using %configure, which makes configure install to /usr. People who run 'configure, make, make install' can easily make an RPM of most applications in under 5 minutes. I'd take about three myself. > Here are a few I noticed a while back - apologies if these have changed in > rawhide or if I am misremembering: (List of good things follows) > Does anybody have any objections to doing this? If not, what is the best > thing for me to do - file a single bug and just CC the maintainers of any > affected packages I can think of? Yes. Anything that encourages people not to install software properly is bad. If you want to improve the packaging system, improve it. Or write your own and make a distro that uses it exclusively. Don't try and encourage people to use two different packaging systems simultaneously. Mike From mikem at cyber.com.au Fri Oct 21 07:01:48 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Fri, 21 Oct 2005 17:01:48 +1000 Subject: Supporting third party software in /usr/local In-Reply-To: <43584616.3010608@develer.com> References: <1129850819.2040.15.camel@locolhost.localdomain> <43584616.3010608@develer.com> Message-ID: <1129878108.3410.52.camel@localhost.localdomain> On Fri, 2005-10-21 at 03:36 +0200, Bernardo Innocenti wrote: > Michael A. Peters wrote: > > >> * Actually I'm not even sure regular $PATH includes /usr/local/bin, but > >> maybe that was some other distro ... > > > > /usr/local/bin is in my path - if a distro does not include it, it is > > imho a bug. > > It's there, but it comes after /bin and /usr/bin, making it > useless for people who install replacement versions of vendor > packages. Its quite useful for people who install replacements to vendors packages. They just have to do it properly. Using the same packaging system as everyone else. It makes it inconvenient for people who try and install multiple copies of the same software to different directories using different packaging systems. These people are likely inconveniencing themselves in many other ways. Mike From tnmurphy at gmail.com Fri Oct 21 09:01:12 2005 From: tnmurphy at gmail.com (Tim Murphy) Date: Fri, 21 Oct 2005 10:01:12 +0100 Subject: Crash with fontconfig-2.3.91.cvs20051017-1 Message-ID: Hi, After installing fontconfig-2.3.91.cvs20051017-1.i386, gdm would start but then crash before displaying anything. Eventually I managed to get X to startup with xinit and tried to run metacity. Metacity crashed and I then tried it under valgrind. I have appended the output but basically there seemed to be a problem in fontconfig relating to permissions to some mmapp'd memory area. I downgraded to fontconfig-2.3.2-1 and the problem "went away." I can't be sure if this is a fontconfig problem or some setup problem - has anyone else experienced it? Regards, Tim ==23609== Invalid read of size 4 ==23609== at 0x1BCEC823: FcStrListCreate (in /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE3661: FcLangSetHasLang (in /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE56FB: (within /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE5B3F: (within /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE5F7F: (within /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE686C: FcFontSetSort (in /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE6D72: FcFontSort (in /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x4C91688D: (within /usr/lib/libpangoft2-1.0.so.0.1001.0) ==23609== by 0x4C94C0AE: pango_font_map_load_fontset (in /usr/lib/libpango- 1.0.so.0.1001.0) ==23609== by 0x4C94ACBA: pango_context_get_metrics (in /usr/lib/libpango- 1.0.so.0.1001.0) ==23609== by 0x807D261: ??? (theme.c:5180) ==23609== by 0x805F196: ??? (frames.c:503) ==23609== Address 0x6D616E20 is not stack'd, malloc'd or (recently) free'd ==23609== ==23609== Process terminating with default action of signal 11 (SIGSEGV) ==23609== Bad permissions for mapped region at address 0x6D616E20 ==23609== at 0x1BCEC823: FcStrListCreate (in /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE3661: FcLangSetHasLang (in /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE56FB: (within /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE5B3F: (within /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE5F7F: (within /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE686C: FcFontSetSort (in /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x1BCE6D72: FcFontSort (in /usr/lib/libfontconfig.so.1.0.4) ==23609== by 0x4C91688D: (within /usr/lib/libpangoft2-1.0.so.0.1001.0) ==23609== by 0x4C94C0AE: pango_font_map_load_fontset (in /usr/lib/libpango- 1.0.so.0.1001.0) ==23609== by 0x4C94ACBA: pango_context_get_metrics (in /usr/lib/libpango- 1.0.so.0.1001.0) ==23609== by 0x807D261: ??? (theme.c:5180) ==23609== by 0x805F196: ??? (frames.c:503) ==23609== ==23609== ERROR SUMMARY: 94 errors from 3 contexts (suppressed: 64 from 3) ==23609== malloc/free: in use at exit: 337686 bytes in 6999 blocks. ==23609== malloc/free: 28615 allocs, 21616 frees, 2031211 bytes allocated. ==23609== For counts of detected errors, rerun with: -v ==23609== searching for pointers to 6999 not-freed blocks. ==23609== checked 792564 bytes. ==23609== ==23609== LEAK SUMMARY: ==23609== definitely lost: 56 bytes in 2 blocks. ==23609== possibly lost: 1084 bytes in 29 blocks. ==23609== still reachable: 336546 bytes in 6968 blocks. ==23609== suppressed: 0 bytes in 0 blocks. ==23609== Use --leak-check=full to see details of leaked memory. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellson at research.att.com Fri Oct 21 10:02:59 2005 From: ellson at research.att.com (John Ellson) Date: Fri, 21 Oct 2005 06:02:59 -0400 Subject: Crash with fontconfig-2.3.91.cvs20051017-1 In-Reply-To: References: Message-ID: <4358BCD3.3040900@research.att.com> Tim Murphy wrote: > Hi, > > After installing fontconfig-2.3.91.cvs20051017-1.i386, gdm would start but > then crash before displaying anything. Eventually I managed to get X to > startup with xinit and tried to run metacity. Metacity crashed and I then > tried it under valgrind. I have appended the output but basically there > seemed to be a problem in fontconfig relating to permissions to some mmapp'd > memory area. > > I downgraded to fontconfig-2.3.2-1 and the problem "went away." > > I can't be sure if this is a fontconfig problem or some setup problem - has > anyone else experienced it? > > > Regards, > > Tim > > ==23609== Invalid read of size 4 > ==23609== at 0x1BCEC823: FcStrListCreate (in > /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE3661: FcLangSetHasLang (in > /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE56FB: (within /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE5B3F: (within /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE5F7F: (within /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE686C: FcFontSetSort (in /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE6D72: FcFontSort (in /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x4C91688D: (within /usr/lib/libpangoft2-1.0.so.0.1001.0) > ==23609== by 0x4C94C0AE: pango_font_map_load_fontset (in /usr/lib/libpango- > 1.0.so.0.1001.0) > ==23609== by 0x4C94ACBA: pango_context_get_metrics (in /usr/lib/libpango- > 1.0.so.0.1001.0) > ==23609== by 0x807D261: ??? (theme.c:5180) > ==23609== by 0x805F196: ??? (frames.c:503) > ==23609== Address 0x6D616E20 is not stack'd, malloc'd or (recently) free'd > ==23609== > ==23609== Process terminating with default action of signal 11 (SIGSEGV) > ==23609== Bad permissions for mapped region at address 0x6D616E20 > ==23609== at 0x1BCEC823: FcStrListCreate (in > /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE3661: FcLangSetHasLang (in > /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE56FB: (within /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE5B3F: (within /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE5F7F: (within /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE686C: FcFontSetSort (in /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x1BCE6D72: FcFontSort (in /usr/lib/libfontconfig.so.1.0.4) > ==23609== by 0x4C91688D: (within /usr/lib/libpangoft2-1.0.so.0.1001.0) > ==23609== by 0x4C94C0AE: pango_font_map_load_fontset (in /usr/lib/libpango- > 1.0.so.0.1001.0) > ==23609== by 0x4C94ACBA: pango_context_get_metrics (in /usr/lib/libpango- > 1.0.so.0.1001.0) > ==23609== by 0x807D261: ??? (theme.c:5180) > ==23609== by 0x805F196: ??? (frames.c:503) > ==23609== > ==23609== ERROR SUMMARY: 94 errors from 3 contexts (suppressed: 64 from 3) > ==23609== malloc/free: in use at exit: 337686 bytes in 6999 blocks. > ==23609== malloc/free: 28615 allocs, 21616 frees, 2031211 bytes allocated. > ==23609== For counts of detected errors, rerun with: -v > ==23609== searching for pointers to 6999 not-freed blocks. > ==23609== checked 792564 bytes. > ==23609== > ==23609== LEAK SUMMARY: > ==23609== definitely lost: 56 bytes in 2 blocks. > ==23609== possibly lost: 1084 bytes in 29 blocks. > ==23609== still reachable: 336546 bytes in 6968 blocks. > ==23609== suppressed: 0 bytes in 0 blocks. > ==23609== Use --leak-check=full to see details of leaked memory. > > I was having a problem with firefox crashes that were also "fixed" by downgrading to fontconfig-2.3.2-1, but then the next day after logging out and back in (and possibly also rebooting) I re-upgraded to fontconfig-2.3.91.cvs20051017-1 and the problem had gone away. I suspect some kind of font cache issue during upgrades. I reported the problem in bug#171224, but later closed it again as I can no longer recreate it. John From buildsys at redhat.com Fri Oct 21 11:16:41 2005 From: buildsys at redhat.com (Build System) Date: Fri, 21 Oct 2005 07:16:41 -0400 Subject: rawhide report: 20051021 changes Message-ID: <200510211116.j9LBGfke002515@porkchop.devel.redhat.com> Updated Packages: am-utils-5:6.1.3-1 ------------------ * Thu Oct 20 2005 Peter Vrabec 6.1.3-1 - upgrade anaconda-10.89.2-1 ------------------ * Thu Oct 20 2005 Jeremy Katz - 10.89.2-1 - fix references to second stage module stuff that caused breakage * Thu Oct 20 2005 Jeremy Katz - 10.89.1-1 - fix for mkcramfs -> mkfs.cramfs - Use minstg2.img instead of netstg2.img/hdstg2.img in the loader * Thu Oct 20 2005 Jeremy Katz - 10.89.0-1 - Fix SELinux policy loading (clumens) - Fix translation import for kickstart (laroche) - Add yumcache (pnasrat) - Upgrade blacklisting (pnasrat) - Clean up exception copying (clumens) - Improve text mode exception dialog too (clumens) - Don't allow bootable partitions on XFS - Some speed improvements, progress bars, etc for package stuff (pnasrat) - Clean up image creation, move all modules to initrd.img. apr-util-0.9.7-3 ---------------- * Thu Oct 20 2005 Joe Orton 0.9.7-3 - fix epoch again * Thu Oct 20 2005 Joe Orton 0.9.7-2 - update to 0.9.7 - drop static libs (#170051) * Tue Jul 26 2005 Joe Orton 0.9.6-3 - add FILE bucket fix for truncated files (#159191) - add epoch to dependencies cups-1:1.1.23-24 ---------------- * Thu Oct 20 2005 Tim Waugh 1:1.1.23-24 - Build with -fstack-protector-all. * Sat Oct 15 2005 Florian La Roche 1:1.1.23-23 - link libcupsimage.so against libcups * Tue Oct 11 2005 Tim Waugh 1:1.1.23-22 - Apply patch to fix STR #1301 (bug #169979). gaim-1:1.5.0-8.fc5 ------------------ glibc-2.3.90-15 --------------- * Thu Oct 20 2005 Jakub Jelinek 2.3.90-15 - update from CVS - be permissive in %n check because of kernel bug #165351 (#171240) - don't misalign stack in pthread_once on x86_64 (#170786, IT#81521) - many locale fixes gnome-applets-1:2.12.1-2 ------------------------ * Thu Oct 20 2005 Ray Strode - 1:2.12.1-2 - require libgtop2 >= 2.12.0, bug 171285 httpd-2.0.54-14 --------------- * Thu Oct 20 2005 Joe Orton 2.0.54-14 - mod_ssl: add security fix for SSLVerifyClient (CVE-2005-2700) - add security fix for byterange filter DoS (CVE-2005-2728) - add security fix for C-L vs T-E handling (CVE-2005-2088) - mod_ssl: add security fix for CRL overflow (CVE-2005-1268) - mod_ldap/mod_auth_ldap: add fixes from 2.0.x branch (upstream #34209 etc) - add fix for dummy connection handling (#167425) - mod_auth_digest: fix hostinfo comparison in CONNECT requests - mod_include: fix variable corruption in nested includes (upstream #12655) - mod_ssl: add fix for handling non-blocking reads - mod_ssl: fix to enable output buffering (upstream #35279) - mod_ssl: buffer request bodies for per-location renegotiation (upstream #12355) * Sat Aug 13 2005 Joe Orton 2.0.54-13 - don't load by default: mod_cern_meta, mod_asis - do load by default: mod_ext_filter (#165893) kernel-2.6.13-1.1621_FC5 ------------------------ * Thu Oct 20 2005 Dave Jones - 2.6.14-rc5 - Aparently the ipw2200 drivers need 2.2 of the firmware right now. - Fix autofs4 looking up wrong path element when ghosting is enabled. * Thu Oct 20 2005 David Woodhouse - Bring forward 8250 OpenFirmware probe patch from FC4. libsepol-1.9.23-1 ----------------- * Tue Oct 18 2005 Dan Walsh 1.9.23-1 * Added check flag to expand_module() to control assertion and hierarchy checking on expansion. * Reworked check_assertions() and hierarchy_check_constraints() to take handles and use callback-based error reporting. * Changed expand_module() to call check_assertions() and hierarchy_check_constraints() prior to returning the expanded policy. * Tue Oct 18 2005 Dan Walsh 1.9.21-1 - Upgrade to latest from NSA * Changed sepol_module_package_set_file_contexts to copy the file contexts data since it is internally managed. * Added sepol_policy_file_set_handle interface to associate a handle with a policy file. * Added handle argument to policydb_from_image/to_image. * Added sepol_module_package_set_file_contexts interface. * Dropped sepol_module_package_create_file interface. * Reworked policydb_read/write, policydb_from_image/to_image, and sepol_module_package_read/write to use callback-based error reporting system rather than DEBUG. logrotate-3.7.2-9 ----------------- * Thu Oct 20 2005 Peter Vrabec 3.7.2-9 - fix_free_segfaults (#171093) pup-0.1.3-1 ----------- * Thu Oct 20 2005 Jeremy Katz - 0.1.3-1 - Don't let people use the main window when a progress bar is up (#171231) - Give details of download and dependency errors. quagga-0:0.98.5-3 ----------------- * Wed Oct 19 2005 Jay Fenlason 0.98.5-3 - add the -pie patch, to make -fPIE compiling actually work on all platforms. - Include -pam patch to close bz#170256 ? pam_stack is deprecated - Change ucd-snmp to net-snmp to close bz#164333 ? quagga 0.98.4-2 requires now obsolete package ucd-snmp-devel - also fix duplicate line mentioned in bz#164333 selinux-policy-strict-1.27.1-22 ------------------------------- * Thu Oct 20 2005 Dan Walsh 1.27.1-22 - Fix to make postfix read spamassasin files selinux-policy-targeted-1.27.1-22 --------------------------------- * Thu Oct 20 2005 Dan Walsh 1.27.1-22 - Fix to make postfix read spamassasin files From alan at redhat.com Fri Oct 21 11:37:39 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 21 Oct 2005 07:37:39 -0400 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <1129877978.3410.49.camel@localhost.localdomain> References: <1129877978.3410.49.camel@localhost.localdomain> Message-ID: <20051021113739.GB28870@devserv.devel.redhat.com> On Fri, Oct 21, 2005 at 04:59:38PM +1000, Mike MacCana wrote: > > This set of problems could be traded for an entirely different set (on > > Fedora at least) if /usr/local was fully supported. > > Why should Fedora and Red Hat encourage installing software in a > non-standard method? The FHS says that locally built and installed software goes in /usr/local/ so even if you believe RPM is the "one true way" (which I don't for local builds quite honestly) then the bug is relevant From mike at plan99.net Fri Oct 21 13:03:11 2005 From: mike at plan99.net (Mike Hearn) Date: Fri, 21 Oct 2005 14:03:11 +0100 Subject: Supporting third party software in /usr/local References: <1129858090.3263.32.camel@localhost.localdomain> Message-ID: On Thu, 20 Oct 2005 18:28:10 -0700, Per Bjornsson wrote: > Have you checked that this one doesn't work on something recent? I have > dumped .desktop files in /usr/share/applications on several FC4 > installations and they got picked up and added to the (Gnome) menu > (haven't checked KDE though). Yes of course /usr/share/applications works, the problem is that /usr/local/share/applications does not work, because the menu definitions don't list this as an . So it means any software installed to /usr/local such as things compiled from source don't get menu entries. thanks -mike From mike at plan99.net Fri Oct 21 13:55:12 2005 From: mike at plan99.net (Mike Hearn) Date: Fri, 21 Oct 2005 14:55:12 +0100 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) References: <1129877978.3410.49.camel@localhost.localdomain> Message-ID: On Fri, 21 Oct 2005 16:59:38 +1000, Mike MacCana wrote: > Why should Fedora and Red Hat encourage installing software in a > non-standard method? Because: a) Fedora RPMs are not a standard method. They're proprietary to Fedora and a particular Fedora release at that b) Non-technical end users like this particular non-standard method c) It's more secure to use RPM for operating system level code and something else for 3rd party application code. I'll talk about the last one more in a moment, as I suspect you don't care much for inter-distro compatibility or what non-technical end users want. > How is it easier to have an application that installs in a totally > different method from every other app on my system? Have you ever tried it? I don't think ease of use is a real problem with autopackage. Anyway, this set of /usr/local bugs affects installing software from source too, which is still VERY common amongst end users, mostly because software people want is often not available in any repositories. > This isn't a defence of RPM. It's a defence of good systems management. > One way to install software is better than two. You say this as if it's obvious. But to me it is not. Let's talk about security. Hopefully it hasn't passed you by that despite being basically miniature computers mobile phones have remained basically impervious to viruses and spyware. Yeah yeah, I'm sure somebody can pull up a scare story about a "virus" that requires you to manually confirm reception and installation of the software, and which can then be trivially deleted. But we've seen nothing like what we've seen in the Windows world, where software gets in undetected and then makes itself nearly impossible to remove. One reason is that there is strict separation between 3rd party application code and native OS code. Java MIDlets are an extreme example of that, which can't access or control each other and run in an interpreted sandbox. They also can't access operating system files (although phones do have operating systems and they do store their code and data in regular files). By keeping application/game software totally sandboxed, the platform has been (so far) kept secure. To upgrade the OS you need to reflash the firmware, it's not like installing a regular application at all. Right now we simply *cannot* do that on Linux because there is no distinction between a kernel or libc upgrade and installing a new chat client. When RPM is used for both, how can you possibly sandbox the installation of this software? How can you say, well, THIS rpm can modify the grub configuration but THIS rpm cannot? You could try playing games with digital signatures - RPMs signed by this authority can do anything, and RPMs that aren't signed cannot - but then you did exactly what we did with autopackage and produce a new format. They might have the same file extension but they actually aren't the same type of file at all. They have different capabilities and work in different ways. Anyway. One of the things we've been looking at lately is using the binary policy modules in Fedora Core 5 to sandbox autopackages down so they can't interfere with system configuration in unacceptable ways. We can do that because we control the API and because the format was advertised since day one as a way for developers to distribute their application-level software to end users and not as a distro building tool. You'll never find a kernel autopackage, so the format itself acts as the dividing line. Through this technique and others (like whitelisting) we hope to improve security far beyond what a "one size fits all" tool can offer. > Don't try and encourage people to use two different packaging systems simultaneously. Too late. The cat is already out of the bag, 250+ people install their first autopackage every day and it's growing all the time. Why don't you work with what end users want instead of what you believe to be theoretically pure? thanks -mike From kevin.wright at simtrol.com Fri Oct 21 14:22:42 2005 From: kevin.wright at simtrol.com (Kevin A. Wright) Date: Fri, 21 Oct 2005 10:22:42 -0400 Subject: Complete graphical boot for Fedora In-Reply-To: <1129805109.3100.13.camel@localhost.localdomain> Message-ID: <001701c5d64a$e6585600$ed01a8c0@atl.simtrol.net> In all seriousness, what obstacles are there to the implementation of this? Perhaps I understand why the initial stuff like uncompressing the kernel, starting udev, etc is in text, but what trouble would it be to extend the graphical boot to a graphical shutdown? I'd like to help in any way I can. Kevin -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of Gangaraju Sent: Thursday, October 20, 2005 6:45 AM To: fedora-devel-list at redhat.com Subject: Complete graphical boot for Fedora HI, AS WE ARE BOOTING THE SYSTEM WITH FEDORA LINUX-2.6.9 AFTER SELECTING AT GRUB MENU ,FIRST THE TEXT MESSAGES LIKE title fedora (2.6.9-fedora) root (hd0,0) kernel /boot/vmlinuz-2.6.9-fedora ro root=LABEL=/1 rhgb quiet initrd /boot/initrd-2.6.9-fedora.img Uncompressing the kernel Nash version-...etc welcome to fedora Starting udev Initialising hardware storage network audio THEN GRAPHICAL BOOT(X SERVER) STARTS , ALL TEXT MESSAGES ARE HIDDEN AND ONLY A IMAGE WITH PROGRESS BAR IS SHOWN. BUT I WANT TO BUILD MY KERNEL AS WHEN SELECTING AT GRUB MENU IT SHOULD NOT SHOW ANY KIND OF TEXT MESSAGES,BUT ONLY GRAPHICAL IMAGE WITH PROGRESS BAR LIKE WINDOWS OS . AND THE SAME IDEA I WANT TO IMPEMENT WHILE SHUTDOWN. I HOPE YOU UNDERSTOOD ME . PLEASE LET ME KNOW. -- Warm Regards, Gangaraju.Chowki Software Engineer, Host Technologies Ltd, Banjara Hills,Road No:12, Hyderabad. -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From nicolas.mailhot at laposte.net Fri Oct 21 14:22:45 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Oct 2005 16:22:45 +0200 (CEST) Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: References: <1129877978.3410.49.camel@localhost.localdomain> Message-ID: <57157.192.54.193.35.1129904565.squirrel@rousalka.dyndns.org> Mike, You've complained again and again that Fedora's design goals are not aligned with your own design goals. Fedora does not owe you anything. It won't change its core principles to accomodate you. If you're right and the Fedora people are wrong Fedora will fail but that's the Fedora people problem. It's THEIR project and they can choose to (mis)manage it any way they want. So accept it and move on. If YOU want autopackage to succeed on Fedora it's YOUR problem ie YOU have to make your packages appear like rpms to the system and register in the rpm database. Fedora is designed as an rpm-only distribution (and that won't change because of you). If you don't want to make this effort, that's too bad, but you're the one who wanted autopackages on Fedora in the first place. -- Nicolas Mailhot From hughsient at gmail.com Fri Oct 21 14:41:07 2005 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 21 Oct 2005 15:41:07 +0100 Subject: Complete graphical boot for Fedora In-Reply-To: <001701c5d64a$e6585600$ed01a8c0@atl.simtrol.net> References: <001701c5d64a$e6585600$ed01a8c0@atl.simtrol.net> Message-ID: <1129905667.8121.6.camel@localhost.localdomain> On Fri, 2005-10-21 at 10:22 -0400, Kevin A. Wright wrote: > In all seriousness, what obstacles are there to the implementation of this? > Perhaps I understand why the initial stuff like uncompressing the kernel, > starting udev, etc is in text, but what trouble would it be to extend the > graphical boot to a graphical shutdown? I'd like to help in any way I can. Shouldn't shutdown just take a few seconds at most? I know Fedora sometimes takes ages with the /sbin/service stop routine, but I'm sure some daemons don't *require* this. Is there any way we can quicken this up by not calling the stop script? Richard. From strange at nsk.no-ip.org Fri Oct 21 14:08:27 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 21 Oct 2005 15:08:27 +0100 Subject: kernel-modules in extras (Was: Re: SquashFS?) In-Reply-To: <1129871423.13028.10.camel@thl.ct.heise.de> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> <1129871423.13028.10.camel@thl.ct.heise.de> Message-ID: <20051021140827.GB28122@nsk.no-ip.org> On Fri, Oct 21, 2005 at 07:10:23AM +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 20.10.2005, 18:35 -0700 schrieb Toshio Kuratomi: > >[...] > >3) We integrate these modules in Extras. > > Just out of curiosity: Can squashfs or unionfs build as a module > without patching the core kernel? UnionFS can. The rpm package in http://gsd.di.uminho.pt/old/luciano/unionfs.src.rpm includes a rc.d script for mounting and mounting unionfs defined in /etc/unionfstab on startup. SquashFS can also. The package in http://gsd.di.uminho.pt/old/luciano/squashfs2.2r2-mod.tar.gz includes only the driver sources, slightly changed for compilation as a module: * #include -> #include "squash..." * #define CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE 3 (the default) * no patching of do_mounts, so no initrd support Compilation: make -C /lib/modules/`uname -r`/build M=$PWD modules -- lfr 0/0 From strange at nsk.no-ip.org Fri Oct 21 14:08:27 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 21 Oct 2005 15:08:27 +0100 Subject: kernel-modules in extras (Was: Re: SquashFS?) In-Reply-To: <1129871423.13028.10.camel@thl.ct.heise.de> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> <1129871423.13028.10.camel@thl.ct.heise.de> Message-ID: <20051021140827.GB28122@nsk.no-ip.org> On Fri, Oct 21, 2005 at 07:10:23AM +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 20.10.2005, 18:35 -0700 schrieb Toshio Kuratomi: > >[...] > >3) We integrate these modules in Extras. > > Just out of curiosity: Can squashfs or unionfs build as a module > without patching the core kernel? UnionFS can. The rpm package in http://gsd.di.uminho.pt/old/luciano/unionfs.src.rpm includes a rc.d script for mounting and mounting unionfs defined in /etc/unionfstab on startup. SquashFS can also. The package in http://gsd.di.uminho.pt/old/luciano/squashfs2.2r2-mod.tar.gz includes only the driver sources, slightly changed for compilation as a module: * #include -> #include "squash..." * #define CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE 3 (the default) * no patching of do_mounts, so no initrd support Compilation: make -C /lib/modules/`uname -r`/build M=$PWD modules -- lfr 0/0 From mike at plan99.net Fri Oct 21 15:02:21 2005 From: mike at plan99.net (Mike Hearn) Date: Fri, 21 Oct 2005 16:02:21 +0100 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) References: <1129877978.3410.49.camel@localhost.localdomain> <57157.192.54.193.35.1129904565.squirrel@rousalka.dyndns.org> Message-ID: On Fri, 21 Oct 2005 16:22:45 +0200, Nicolas Mailhot wrote: > You've complained again and again that Fedora's design goals are not > aligned with your own design goals. Fedora does not owe you anything. It > won't change its core principles to accomodate you. Nicolas, whenever I post bug reports or questions here and refer to my project, you bash it. Please, stop. It brings nothing to the table. Now, if you have something to say on the matter of /usr/local support, desktop security or even mobile phones please say it! Otherwise, don't. And for what it's worth, I doubt that not supporting /usr/local is really a "principle". It's probably just been overlooked. thanks -mike From jspaleta at gmail.com Fri Oct 21 15:25:39 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Oct 2005 11:25:39 -0400 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: References: <1129877978.3410.49.camel@localhost.localdomain> Message-ID: <604aa7910510210825sb22c1a0gc88cdbbc09a2a0af@mail.gmail.com> On 10/21/05, Mike Hearn wrote: > a) Fedora RPMs are not a standard method. They're proprietary to Fedora > and a particular Fedora release at that Can you point out to me a specific written packaging standard..for linux...that has some measure of wide concensous support? I found this: http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/swinstall.html If we can't hold up the LSB, which prefers rpms, then exactly what standard are you trying to apply? Now, whether or not you believe the LSB currently enjoys or should enjoy wide adoption is an open question, outside the scope of this thread. My point is, the LSB stuff is a high profile "standards" attempt in this community and even it prefers rpms to a degree, so I'm not sure how you can claim Fedora is doing something non-standard in the scope of the larger community. Please... lets avoid over the top generalistic language. I'm trying to give your concerns the benefit of the doubt but when you make this sort of statement the strongest argument in your arsenal it becomes difficult to continue to be open to what you are saying with regard to how to appropriately support alternative installation mechanisms. -jef"do your own thing is the de-facto standard"spaleta From mike at plan99.net Fri Oct 21 15:52:08 2005 From: mike at plan99.net (Mike Hearn) Date: Fri, 21 Oct 2005 16:52:08 +0100 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) References: <1129877978.3410.49.camel@localhost.localdomain> <604aa7910510210825sb22c1a0gc88cdbbc09a2a0af@mail.gmail.com> Message-ID: On Fri, 21 Oct 2005 11:25:39 -0400, Jeff Spaleta wrote: > If we can't hold up the LSB, which prefers rpms, then exactly what > standard are you trying to apply? Well, LSB RPMs don't bear much resemblance to Fedora RPMs. They aren't allowed any dependencies, for one. For another, Fedora RPMs can't be installed (reliably) on non-Fedora systems, or on versions of Fedora other than the one they were built for. So sure, you could say "RPM is the standard, the LSB says so", but that doesn't make the Fedora-custom flavours of it standard. It makes the LSB flavour standard. And for what it's worth, last time I asked the LSB guys how many LSB RPMs were "in the wild", the answer was perhaps two or three. So it's more a de-jure standard than a de-facto standard. thanks -mike From jspaleta at gmail.com Fri Oct 21 16:09:06 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Oct 2005 12:09:06 -0400 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: References: <1129877978.3410.49.camel@localhost.localdomain> <604aa7910510210825sb22c1a0gc88cdbbc09a2a0af@mail.gmail.com> Message-ID: <604aa7910510210909t5d2d599fgf2ce4a95434bd031@mail.gmail.com> On 10/21/05, Mike Hearn wrote: > And for what it's worth, last time I asked the LSB guys how many LSB RPMs > were "in the wild", the answer was perhaps two or three. So it's more a > de-jure standard than a de-facto standard. Please point to a standard de-factor or otherwise with wide acceptance.... in the linux space at large....that you are using to measure fedora's packages against. Different groups have has their own ideas in this space...i'd even call it a vibrant space full of competing ideas. Please refrain from making it sound like Fedora is well off the map compared to other distributors. -jef"catch more flies with honey"spaleta From db-fedora at 3di.it Fri Oct 21 16:34:35 2005 From: db-fedora at 3di.it (Davide Bolcioni) Date: Fri, 21 Oct 2005 18:34:35 +0200 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems In-Reply-To: <1129877978.3410.49.camel@localhost.localdomain> References: <1129877978.3410.49.camel@localhost.localdomain> Message-ID: <4359189B.3080506@3di.it> Mike MacCana wrote: > Why should Fedora and Red Hat encourage installing software in a > non-standard method? Forgetting about autopackage for a moment, /usr/local *is* a traditional place for administrator-installed software. It does not sound inappropriate to take it into account in the overall system setup; even if the typical system administrator might be well able to do that by himself, he's likely to appreciate the effort nonetheless. In my opinion, the problem of third-party (meaning not provided by the distribution) applications is supposed to be solved by /opt, but the suppport for /opt across distributions is arguably even less developed than for /usr/local. So maybe the real answer is "provide support for /usr/local and /opt integration". Just my $0.02 Davide Bolcioni -- Paranoia is a survival asset. From rc040203 at freenet.de Fri Oct 21 16:37:22 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Oct 2005 18:37:22 +0200 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <604aa7910510210909t5d2d599fgf2ce4a95434bd031@mail.gmail.com> References: <1129877978.3410.49.camel@localhost.localdomain> <604aa7910510210825sb22c1a0gc88cdbbc09a2a0af@mail.gmail.com> <604aa7910510210909t5d2d599fgf2ce4a95434bd031@mail.gmail.com> Message-ID: <1129912642.28858.153.camel@mccallum.corsepiu.local> On Fri, 2005-10-21 at 12:09 -0400, Jeff Spaleta wrote: > On 10/21/05, Mike Hearn wrote: > > And for what it's worth, last time I asked the LSB guys how many LSB RPMs > > were "in the wild", the answer was perhaps two or three. So it's more a > > de-jure standard than a de-facto standard. > > Please point to a standard de-factor or otherwise with wide > acceptance.... The FHS and the GNU-standards are fairly widely accepted standards in the OSS, Linux and GNU world. As others already mentioned, the LSB's importance is arguable/questionable - Fact is, its importance so far has been almost negligible. Ralf From mhw at wittsend.com Fri Oct 21 14:18:11 2005 From: mhw at wittsend.com (Michael H. Warfield) Date: Fri, 21 Oct 2005 10:18:11 -0400 Subject: SquashFS? In-Reply-To: <1129858560.3260.32.camel@localhost> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> Message-ID: <1129904291.4377.58.camel@canyon.wittsend.com> On Thu, 2005-10-20 at 18:35 -0700, Toshio Kuratomi wrote: > On Thu, 2005-10-20 at 13:20 -0500, Rex Dieter wrote: > > Darko Ilic wrote: > > > > > I wanted to ask what are the opinions on the subject, and is there any chance > > > for SquashFS to make it's way into Fedora kernel by FC5? I`ve heard it was > > > submitted to LKML recently and there was some discussions surrounding that > > > and that it is a likely candidate for the upstream kernel. > > > > If it makes it upstream, then most likely, yes. > I'd like to see a quality Fedora LiveCD. At my day job we're evaluating > livecds for kiosks, recovery, and lab installs. What has struck me in > recent days is that they're _all_ Debian based. If we want this to > change, we need to create liveCDs that > squashfs and unionfs are both kernel modules that are pretty standard > fare in the liveCD world but are not part of the mainline kernel. We > need to include them in Fedora in order to advance our reputation in the > liveCD arena. I spoke with Andrew Morton about unionfs when we were both at Linux Lunacy V. He stated that nobody had approached him or Linus about unionfs and they had not heard a peep about it. But, if someone wants to submit patches and follow up on it, they are more than willing to look it over and consider it. So, as far as unionfs goes, it's up to the developers to approach the kernel people about inclusion in the upstream sources. So someone needs to push the unionfs developers. > There are three alternatives here. 1) We don't care about LiveCDs. If > you want to make a serious LiveCD based on Fedora, you have to fork and > maintain some packages outside of the Fedora arena. 2) We get these > integrated into Core despite the fact that they aren't upstream > [Example: GFS] 3) We integrate these modules in Extras. > > Is this important enough to Red Hat that Core manpower can be expended > to make this happen? Or can we finally muster the will to package > kernel modules for Extras _knowing_ that the policies and proceedures we > set out in the first cut will need to be revised, possibly with a great > deal of pain? > > Sorry for the emotion but kernel modules are currently stuck in a very > undesirable limbo that's not doing Fedora as a whole any good. > > -Toshio > > PS - I discovered that work has one old Puppy Linux disk so that's one > non-Debian distro... It's not Fedora-based, though. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- 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 jspaleta at gmail.com Fri Oct 21 17:03:03 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Oct 2005 13:03:03 -0400 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <1129912642.28858.153.camel@mccallum.corsepiu.local> References: <1129877978.3410.49.camel@localhost.localdomain> <604aa7910510210825sb22c1a0gc88cdbbc09a2a0af@mail.gmail.com> <604aa7910510210909t5d2d599fgf2ce4a95434bd031@mail.gmail.com> <1129912642.28858.153.camel@mccallum.corsepiu.local> Message-ID: <604aa7910510211003h4319cfd6r3d8ae57bb825f9@mail.gmail.com> On 10/21/05, Ralf Corsepius wrote: > The FHS and the GNU-standards are fairly widely accepted standards in > the OSS, Linux and GNU world. The context was... packaging standards.... which i'm pretty sure isn't covered in the venerable standards you mention. >As others already mentioned, the LSB's > importance is arguable/questionable - Fact is, its importance so far has > been almost negligible. I'm not going to argue its worth, but it is the only attempt at a standard that I am aware of that actually covers packaging.. across distributions... in a way that is relevant to Hearn's comments about Fedora packaging. The fact that the only standards specification that I can find..easily...has questionable worth..only further supports my point that there isn't a workable standard in the package space with wide acceptance, so it's pointless and most likely counter-productive for Hearn to imply that there is such a standard out there to measure Fedora packaging against when trying to compel discussion about changing aspects of Fedora to make cross-distribution packaging easier to do. -jef"more importantly it looks like hot liquid lithium limited Ohmicly heated low aspect ratio tokamak plasma discharges reach an energy confinement time nearly 3 times larger than previous emperical scaling laws would predict... its miller time"spaleta From rc040203 at freenet.de Fri Oct 21 17:15:21 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Oct 2005 19:15:21 +0200 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <604aa7910510211003h4319cfd6r3d8ae57bb825f9@mail.gmail.com> References: <1129877978.3410.49.camel@localhost.localdomain> <604aa7910510210825sb22c1a0gc88cdbbc09a2a0af@mail.gmail.com> <604aa7910510210909t5d2d599fgf2ce4a95434bd031@mail.gmail.com> <1129912642.28858.153.camel@mccallum.corsepiu.local> <604aa7910510211003h4319cfd6r3d8ae57bb825f9@mail.gmail.com> Message-ID: <1129914921.28858.169.camel@mccallum.corsepiu.local> On Fri, 2005-10-21 at 13:03 -0400, Jeff Spaleta wrote: > On 10/21/05, Ralf Corsepius wrote: > > The FHS and the GNU-standards are fairly widely accepted standards in > > the OSS, Linux and GNU world. > The context was... packaging standards.... which i'm pretty sure isn't > covered in the venerable standards you mention. Both the FHS and GNU-standards give recipes from "choosing installation directories" and what to install where. To me, this makes at least 3/4's of packaging. I guess you want to re-read the FHS http://www.pathname.com/fhs/pub/fhs-2.3.html and the GNU-standards http://www.gnu.org/prep/standards/standards.html > >As others already mentioned, the LSB's > > importance is arguable/questionable - Fact is, its importance so far has > > been almost negligible. > > I'm not going to argue its worth, but it is the only attempt at a > standard that I am aware of that actually covers packaging.. Then we probably have a different notion on packaging. :) Ralf From alan at redhat.com Fri Oct 21 17:26:32 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 21 Oct 2005 13:26:32 -0400 Subject: Complete graphical boot for Fedora In-Reply-To: <001701c5d64a$e6585600$ed01a8c0@atl.simtrol.net> References: <1129805109.3100.13.camel@localhost.localdomain> <001701c5d64a$e6585600$ed01a8c0@atl.simtrol.net> Message-ID: <20051021172632.GA5474@devserv.devel.redhat.com> On Fri, Oct 21, 2005 at 10:22:42AM -0400, Kevin A. Wright wrote: > In all seriousness, what obstacles are there to the implementation of this? You need to write code that works on every video card. There are a couple of ways to tackle that. One would be to fallback for non-VGA cards and use strictly VGA 640x480x16 modes without timing jiggery-pokery. Another would be to put up a logo/info area on screen by flipping to 512 character text mode and using a mini font that makes up the logo From jspaleta at gmail.com Fri Oct 21 17:29:05 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Oct 2005 13:29:05 -0400 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <1129914921.28858.169.camel@mccallum.corsepiu.local> References: <1129877978.3410.49.camel@localhost.localdomain> <604aa7910510210825sb22c1a0gc88cdbbc09a2a0af@mail.gmail.com> <604aa7910510210909t5d2d599fgf2ce4a95434bd031@mail.gmail.com> <1129912642.28858.153.camel@mccallum.corsepiu.local> <604aa7910510211003h4319cfd6r3d8ae57bb825f9@mail.gmail.com> <1129914921.28858.169.camel@mccallum.corsepiu.local> Message-ID: <604aa7910510211029i6791dcd4v19b8cfd0d90da94e@mail.gmail.com> On 10/21/05, Ralf Corsepius wrote: > To me, this makes at least 3/4's of packaging. > I guess you want to re-read the FHS > http://www.pathname.com/fhs/pub/fhs-2.3.html > > and the GNU-standards > http://www.gnu.org/prep/standards/standards.html I interpreted Hearn's claim to be that rpm packages as implemented by Fedora as a way to distribute and install software are inherently "non-standard" and I'm looking for anything that would support such a claim. yes... where crap goes on the system is covered by the FHS... but i dont see how rpms as a package blob are in conflict with that inherently. yes... the GNU-standards cover a wide range of how applications should actually be written..but i don't see how rpms as a package blob are in conflict with that inherently. Is there a conflict with how rpms operate with either of these standards, that would support the claim that Fedora packages are "non-standard method" ? Again... the context is this particular quote: On 10/21/05, Mike Hearn wrote: > On Fri, 21 Oct 2005 16:59:38 +1000, Mike MacCana wrote >> Why should Fedora and Red Hat encourage installing software in a >> non-standard method? > >Because: > >a) Fedora RPMs are not a standard method. They're proprietary to Fedora > and a particular Fedora release at that -jef From nicolas.mailhot at laposte.net Fri Oct 21 17:47:50 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Oct 2005 19:47:50 +0200 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems In-Reply-To: <4359189B.3080506@3di.it> References: <1129877978.3410.49.camel@localhost.localdomain> <4359189B.3080506@3di.it> Message-ID: <1129916870.10973.18.camel@rousalka.dyndns.org> Le vendredi 21 octobre 2005 ? 18:34 +0200, Davide Bolcioni a ?crit : > In my opinion, the problem of third-party (meaning not provided by > the distribution) applications is supposed to be solved by /opt, but > the suppport for /opt across distributions is arguably even less > developed than for /usr/local. So maybe the real answer is "provide > support for /usr/local and /opt integration". No one disagrees on this. What people disagree on are bits like "Encouraging the use of multiple packaging systems" and all the marketing handwaving that's been advanced to justify it. /usr/local and /opt will be supported to provide a dumping ground for the quick hacks people need to do now and then. Not because generalising these hacks is a good idea, and certainly not because it will make them "first class citizens". If the requirement to use a single packaging system was obvious fluff as we're asked to believe you'd have several major distributions using multiple packaging systems on the market today. Certainly the Linux market is "fragmented" enough for people to prove the ideas they believe in. And now I'll shut up. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From darko.ilic at gmail.com Fri Oct 21 18:03:16 2005 From: darko.ilic at gmail.com (Darko Ilic) Date: Fri, 21 Oct 2005 20:03:16 +0200 Subject: SquashFS? In-Reply-To: <1129904291.4377.58.camel@canyon.wittsend.com> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> Message-ID: <200510212003.16647.darko.ilic@gmail.com> On Friday 21 October 2005 16:18, Michael H. Warfield wrote: > So, as far as unionfs goes, it's up to the developers to approach the > kernel people about inclusion in the upstream sources. So someone needs > to push the unionfs developers. Well, having unionfs included in the kernel would be *great* for live CDs. If we could push both unionfs and SquashFS to go upstream, that would improve the quality of live CDs dramatically. SquashFS would improve performance because it's much faster than currently used zisofs, and would allow more packages to be included in the distro since it's compression ratio is higher. Higher compression ratio would also result in greater performance because smaller files need less time to be transfered from the CD to the memory. Unionfs would improve the quality of the live CD distributions because it won't be necessary to move files that are supposed to be writable to the ramfs drive, so all the files would stay in their "original" locations. Another thing is that all parts of the file system would be writable which is awesome (editing every single file, installing small pieces of software, moving files...). It is also important that RAM consumption would be much lower since there is no need to transfer all writable files to the RAM, just diffs to the changed files. The main question for me is how to accomplish this. I'm quite new to the whole thing, and maybe I wouldn't choose the right approach to the kernel people... Is there anybody that is willing to help me with this? An advice would be just fine. Thanks -- Darko p.s. I forgot to mention that there is a couple of live CD distributions that already use these two modules, and work very well. From ndbecker2 at gmail.com Fri Oct 21 17:58:23 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 21 Oct 2005 13:58:23 -0400 Subject: SquashFS? References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> Message-ID: If we're talking about livecd FS components, I think we should also consider shadowfs, or something similar. This looks _really_ interesting. From fedora at leemhuis.info Fri Oct 21 18:20:00 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 21 Oct 2005 20:20:00 +0200 Subject: SquashFS? In-Reply-To: <200510212003.16647.darko.ilic@gmail.com> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> <200510212003.16647.darko.ilic@gmail.com> Message-ID: <1129918800.9548.13.camel@localhost.localdomain> Am Freitag, den 21.10.2005, 20:03 +0200 schrieb Darko Ilic: > On Friday 21 October 2005 16:18, Michael H. Warfield wrote: > > So, as far as unionfs goes, it's up to the developers to approach the > > kernel people about inclusion in the upstream sources. So someone needs > > to push the unionfs developers. > > Well, having unionfs included in the kernel would be *great* for live CDs. > > If we could push both unionfs and SquashFS to go upstream, that would > improve the quality of live CDs dramatically. > >[...] > The main question for me is how to accomplish this. I'm quite new to the whole > thing, and maybe I wouldn't choose the right approach to the kernel people... > Is there anybody that is willing to help me with this? An advice would be > just fine. We're working on a kernel-module-standard for fedora-extras. I can package unionfs and SqashFS then if that would be enough for the LiveCD. But there might be a small problem with SqashFS and the initrd: -------- Weitergeleitete Nachricht -------- > Von: Luciano Miguel Ferreira Rocha > Antwort an: Development discussions related to Fedora Core > > An: Development discussions related to Fedora Core > > Betreff: Re: kernel-modules in extras (Was: Re: SquashFS?) > Datum: Fri, 21 Oct 2005 15:08:27 +0100 > > On Fri, Oct 21, 2005 at 07:10:23AM +0200, Thorsten Leemhuis wrote: > > Am Donnerstag, den 20.10.2005, 18:35 -0700 schrieb Toshio Kuratomi: > > >[...] > > >3) We integrate these modules in Extras. > > Just out of curiosity: Can squashfs or unionfs build as a module > > without patching the core kernel? > > UnionFS can. > The rpm package in http://gsd.di.uminho.pt/old/luciano/unionfs.src.rpm > includes a rc.d script for mounting and mounting unionfs defined in > /etc/unionfstab on startup. > > > SquashFS can also. > > The package in http://gsd.di.uminho.pt/old/luciano/squashfs2.2r2-mod.tar.gz > includes only the driver sources, slightly changed for compilation as a > module: > * #include -> #include "squash..." > * #define CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE 3 (the default) > * no patching of do_mounts, so no initrd support > > Compilation: > make -C /lib/modules/`uname -r`/build M=$PWD modules -- Thorsten Leemhuis From strange at nsk.no-ip.org Fri Oct 21 18:23:46 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 21 Oct 2005 19:23:46 +0100 Subject: SquashFS? In-Reply-To: <200510212003.16647.darko.ilic@gmail.com> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> <200510212003.16647.darko.ilic@gmail.com> Message-ID: <20051021182346.GA4660@nsk.no-ip.org> On Fri, Oct 21, 2005 at 08:03:16PM +0200, Darko Ilic wrote: > > Well, having unionfs included in the kernel would be *great* for live CDs. > > If we could push both unionfs and SquashFS to go upstream, that would improve > the quality of live CDs dramatically. To have unionfs and squashfs upstream would be nice, yes. But they can be used regardless of being upstream or not. -- lfr 0/0 From strange at nsk.no-ip.org Fri Oct 21 18:33:00 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 21 Oct 2005 19:33:00 +0100 Subject: SquashFS? In-Reply-To: <1129918800.9548.13.camel@localhost.localdomain> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> <200510212003.16647.darko.ilic@gmail.com> <1129918800.9548.13.camel@localhost.localdomain> Message-ID: <20051021183300.GB4660@nsk.no-ip.org> On Fri, Oct 21, 2005 at 08:20:00PM +0200, Thorsten Leemhuis wrote: > We're working on a kernel-module-standard for fedora-extras. I can > package unionfs and SqashFS then if that would be enough for the LiveCD. > But there might be a small problem with SqashFS and the initrd: A kernel-module-standard is a necessity for fedora-extras but not for unionfs/squashfs, IMO. They're small, and can be compiled on-the-fly, when creating the live cd iso. And I don't think the lack of support for a "squashed" initrd is a problem. I believe initramfs works much better for livecds, anyway. :) BTW, I'll gladly help if there's anything I can do. -- lfr 0/0 From perbj at stanford.edu Fri Oct 21 18:41:01 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Fri, 21 Oct 2005 11:41:01 -0700 Subject: Supporting third party software in /usr/local In-Reply-To: References: <1129858090.3263.32.camel@localhost.localdomain> Message-ID: <1129920062.3075.3.camel@localhost.localdomain> On Fri, 2005-10-21 at 14:03 +0100, Mike Hearn wrote: > On Thu, 20 Oct 2005 18:28:10 -0700, Per Bjornsson wrote: > > Have you checked that this one doesn't work on something recent? I have > > dumped .desktop files in /usr/share/applications on several FC4 > > installations and they got picked up and added to the (Gnome) menu > > (haven't checked KDE though). > > Yes of course /usr/share/applications works, the problem is that > /usr/local/share/applications does not work, because the menu definitions > don't list this as an . So it means any software installed to > /usr/local such as things compiled from source don't get menu entries. Boy, I should really learn to proofread better! I meant to say that I had put desktop files in /usr/local/share/applications and it _does_ work on my systems, and I have not changed anything in the menu definition files. (Only tested on FC4 though, I don't have anything older around right now.) My apologies for the confusion! Per From lmacken at redhat.com Fri Oct 21 19:50:59 2005 From: lmacken at redhat.com (Luke Macken) Date: Fri, 21 Oct 2005 15:50:59 -0400 Subject: Complete graphical boot for Fedora In-Reply-To: <1129905667.8121.6.camel@localhost.localdomain> References: <001701c5d64a$e6585600$ed01a8c0@atl.simtrol.net> <1129905667.8121.6.camel@localhost.localdomain> Message-ID: <1129924259.2312.4.camel@localhost> On Fri, 2005-10-21 at 15:41 +0100, Richard Hughes wrote: > Shouldn't shutdown just take a few seconds at most? > > I know Fedora sometimes takes ages with the /sbin/service stop > routine, but I'm sure some daemons don't *require* this. > > Is there any way we can quicken this up by not calling the stop script? We are currently looking into alternatives to SysVinit. Once we get rid of that monstrosity, the startup/shutdown process will most likely be significantly faster. luke From katzj at redhat.com Fri Oct 21 20:13:17 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Oct 2005 16:13:17 -0400 Subject: SquashFS? In-Reply-To: <1129858560.3260.32.camel@localhost> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> Message-ID: <1129925598.2050.186.camel@bree.local.net> On Thu, 2005-10-20 at 18:35 -0700, Toshio Kuratomi wrote: > On Thu, 2005-10-20 at 13:20 -0500, Rex Dieter wrote: > > Darko Ilic wrote: > > > I wanted to ask what are the opinions on the subject, and is there any chance > > > for SquashFS to make it's way into Fedora kernel by FC5? I`ve heard it was > > > submitted to LKML recently and there was some discussions surrounding that > > > and that it is a likely candidate for the upstream kernel. > > > > If it makes it upstream, then most likely, yes. > > I'd like to see a quality Fedora LiveCD. At my day job we're evaluating > livecds for kiosks, recovery, and lab installs. What has struck me in > recent days is that they're _all_ Debian based. If we want this to > change, we need to create liveCDs that I think a lot of people want to see a live CD and there's something of a push to get all of the pieces in place for in the FC5 timeframe. > squashfs and unionfs are both kernel modules that are pretty standard > fare in the liveCD world but are not part of the mainline kernel. We > need to include them in Fedora in order to advance our reputation in the > liveCD arena. And the answer to this, at least traditionally, is that the answer is to get the modules integrated upstream. Personally, I don't even think this is the biggest area that needs work for a real, compelling live CD. Rather, various pieces of the stateless infrastructure need to be finished and integrated into the core. > There are three alternatives here. 1) We don't care about LiveCDs. If > you want to make a serious LiveCD based on Fedora, you have to fork and > maintain some packages outside of the Fedora arena. Come on, it's not that you _can't_ do a live cd without them. > 2) We get these > integrated into Core despite the fact that they aren't upstream > [Example: GFS] And you'll note that GFS is gone again in the development due to the problems that were had... > 3) We integrate these modules in Extras. We're working on module packaging for Extras. This could potentially be a way to get people who really want squashfs and unionfs but aren't willing to try to push upstream... Jeremy From katzj at redhat.com Fri Oct 21 20:21:39 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Oct 2005 16:21:39 -0400 Subject: SquashFS? In-Reply-To: <20051021182346.GA4660@nsk.no-ip.org> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> <200510212003.16647.darko.ilic@gmail.com> <20051021182346.GA4660@nsk.no-ip.org> Message-ID: <1129926099.2050.191.camel@bree.local.net> On Fri, 2005-10-21 at 19:23 +0100, Luciano Miguel Ferreira Rocha wrote: > On Fri, Oct 21, 2005 at 08:03:16PM +0200, Darko Ilic wrote: > > Well, having unionfs included in the kernel would be *great* for live CDs. > > > > If we could push both unionfs and SquashFS to go upstream, that would improve > > the quality of live CDs dramatically. > > To have unionfs and squashfs upstream would be nice, yes. But they can > be used regardless of being upstream or not. Not for an official Fedora Live CD. One aspect is that it *must* be built using components distributed as part of Fedora and we're (generally speaking) against patches which aren't upstream because they significantly raise the maintenance burden and then also get people complaining because the kernel isn't "stock" Jeremy From katzj at redhat.com Fri Oct 21 20:24:13 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Oct 2005 16:24:13 -0400 Subject: SquashFS? In-Reply-To: <20051021183300.GB4660@nsk.no-ip.org> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> <200510212003.16647.darko.ilic@gmail.com> <1129918800.9548.13.camel@localhost.localdomain> <20051021183300.GB4660@nsk.no-ip.org> Message-ID: <1129926254.2050.194.camel@bree.local.net> On Fri, 2005-10-21 at 19:33 +0100, Luciano Miguel Ferreira Rocha wrote: > On Fri, Oct 21, 2005 at 08:20:00PM +0200, Thorsten Leemhuis wrote: > > We're working on a kernel-module-standard for fedora-extras. I can > > package unionfs and SqashFS then if that would be enough for the LiveCD. > > But there might be a small problem with SqashFS and the initrd: > > A kernel-module-standard is a necessity for fedora-extras but not for > unionfs/squashfs, IMO. They're small, and can be compiled on-the-fly, > when creating the live cd iso. This is a non-starter. Allowing compilation of stuff adds far too much of a "random" element with regards to what's on the system. > And I don't think the lack of support for a "squashed" initrd is a > problem. I believe initramfs works much better for livecds, anyway. :) But you need to get the squashfs module into the initrd[1]. Jeremy [1] Using initrd as a generic term for either initrd or initramfs. Note that Core has been using initramfs by default since FC3... this is one of the reasons why I say that the changes for live CD at an infrastructure level need to be better integrated. Peter has made some changes in mkinitrd which will help make this easier and I have the start of the changes for kadischi, but I probably won't get back to finishing them up until after test1 From dmack at leviatron.com Fri Oct 21 20:28:31 2005 From: dmack at leviatron.com (Dave Mack) Date: Fri, 21 Oct 2005 13:28:31 -0700 Subject: SquashFS? References: <200510202008.53326.darko.ilic@gmail.com><1129858560.3260.32.camel@localhost><1129904291.4377.58.camel@canyon.wittsend.com><200510212003.16647.darko.ilic@gmail.com><20051021182346.GA4660@nsk.no-ip.org> <1129926099.2050.191.camel@bree.local.net> Message-ID: <015601c5d67e$00dcf070$0b00a8c0@leviatron.com> Take a look at YETAA (YET Another Adios). Provides about 2.2 GB of Fedora 4 on a CD using squashfs and unionfs. Very cool. The yetaa-0.20 ISO on their site has booted in everything I've tried so far, including my ThinkPad. The 0.30 release has a few bugs in the Makefile, but once you've corrected those it allows you to build your own FC4 live CD quite easily. http://dc.qut.edu.au/yetaa/ dmack ----- Original Message ----- From: "Jeremy Katz" To: "Development discussions related to Fedora Core" Sent: Friday, October 21, 2005 1:21 PM Subject: Re: SquashFS? > On Fri, 2005-10-21 at 19:23 +0100, Luciano Miguel Ferreira Rocha wrote: >> On Fri, Oct 21, 2005 at 08:03:16PM +0200, Darko Ilic wrote: >> > Well, having unionfs included in the kernel would be *great* for live >> > CDs. >> > >> > If we could push both unionfs and SquashFS to go upstream, that would >> > improve >> > the quality of live CDs dramatically. >> >> To have unionfs and squashfs upstream would be nice, yes. But they can >> be used regardless of being upstream or not. > > Not for an official Fedora Live CD. One aspect is that it *must* be > built using components distributed as part of Fedora and we're > (generally speaking) against patches which aren't upstream because they > significantly raise the maintenance burden and then also get people > complaining because the kernel isn't "stock" > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From strange at nsk.no-ip.org Fri Oct 21 20:42:18 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 21 Oct 2005 21:42:18 +0100 Subject: SquashFS? In-Reply-To: <1129926254.2050.194.camel@bree.local.net> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> <200510212003.16647.darko.ilic@gmail.com> <1129918800.9548.13.camel@localhost.localdomain> <20051021183300.GB4660@nsk.no-ip.org> <1129926254.2050.194.camel@bree.local.net> Message-ID: <20051021204218.GA8935@nsk.no-ip.org> On Fri, Oct 21, 2005 at 04:24:13PM -0400, Jeremy Katz wrote: > On Fri, 2005-10-21 at 19:33 +0100, Luciano Miguel Ferreira Rocha wrote: > > On Fri, Oct 21, 2005 at 08:20:00PM +0200, Thorsten Leemhuis wrote: > > > We're working on a kernel-module-standard for fedora-extras. I can > > > package unionfs and SqashFS then if that would be enough for the LiveCD. > > > But there might be a small problem with SqashFS and the initrd: > > > > A kernel-module-standard is a necessity for fedora-extras but not for > > unionfs/squashfs, IMO. They're small, and can be compiled on-the-fly, > > when creating the live cd iso. > > This is a non-starter. Allowing compilation of stuff adds far too much > of a "random" element with regards to what's on the system. I don't understand that sentence. A "mklivecd" program already has to: 1. create initial root 2. install packages 3. configure livecd system 4. create livecd initrd What's the damage of adding: 3b. make unionfs squashfs? > > > And I don't think the lack of support for a "squashed" initrd is a > > problem. I believe initramfs works much better for livecds, anyway. :) > > But you need to get the squashfs module into the initrd[1]. > > Jeremy > > [1] Using initrd as a generic term for either initrd or initramfs. Note > that Core has been using initramfs by default since FC3... this is one > of the reasons why I say that the changes for live CD at an > infrastructure level need to be better integrated. Peter has made some > changes in mkinitrd which will help make this easier and I have the > start of the changes for kadischi, but I probably won't get back to > finishing them up until after test1 Well, I'd expected the initrd/initramfs to be cunstom built, anyway. Specially for the part of searching for the livecd image (in a cdrom, nfs, hdd, whatever). And about current mkinitrd, isn't --preload=mod.ko sufficient? -- lfr 0/0 From mike at plan99.net Fri Oct 21 20:46:55 2005 From: mike at plan99.net (Mike Hearn) Date: Fri, 21 Oct 2005 21:46:55 +0100 Subject: Supporting third party software in /usr/local References: <1129858090.3263.32.camel@localhost.localdomain> <1129920062.3075.3.camel@localhost.localdomain> Message-ID: On Fri, 21 Oct 2005 11:41:01 -0700, Per Bjornsson wrote: > Boy, I should really learn to proofread better! I meant to say that I had > put desktop files in /usr/local/share/applications and it _does_ work on > my systems, and I have not changed anything in the menu definition files. > (Only tested on FC4 though, I don't have anything older around right now.) Hmm, that's odd, doesn't work here. Maybe XDG_DATA_DIRS includes it on your system and so it doesn't need to be merged into the menu file explicitly? From strange at nsk.no-ip.org Fri Oct 21 20:49:20 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 21 Oct 2005 21:49:20 +0100 Subject: SquashFS? In-Reply-To: <1129926099.2050.191.camel@bree.local.net> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> <200510212003.16647.darko.ilic@gmail.com> <20051021182346.GA4660@nsk.no-ip.org> <1129926099.2050.191.camel@bree.local.net> Message-ID: <20051021204920.GB8935@nsk.no-ip.org> On Fri, Oct 21, 2005 at 04:21:39PM -0400, Jeremy Katz wrote: > On Fri, 2005-10-21 at 19:23 +0100, Luciano Miguel Ferreira Rocha wrote: > > On Fri, Oct 21, 2005 at 08:03:16PM +0200, Darko Ilic wrote: > > > Well, having unionfs included in the kernel would be *great* for live CDs. > > > > > > If we could push both unionfs and SquashFS to go upstream, that would improve > > > the quality of live CDs dramatically. > > > > To have unionfs and squashfs upstream would be nice, yes. But they can > > be used regardless of being upstream or not. > > Not for an official Fedora Live CD. One aspect is that it *must* be > built using components distributed as part of Fedora and we're > (generally speaking) against patches which aren't upstream because they > significantly raise the maintenance burden and then also get people > complaining because the kernel isn't "stock" I was thinking of adding the source of the modules to the "official fedora livecd maker". The _binary_ rpm would have the sources. Thus, no need for kernel patches or any unionfs/squashfs package at all. The fedora livecd build process will compile the modules on livecd creation, using the kernel-dev package for the kernel to be used by the livecd. As the livecd system won't be updated anyway, there isn't even a need of keeping any unionfs/squashfs package at the same level of the kernel package. I'd be rather happy to see unionfs and squashfs packages in extras, and I even volunteer myself to maintain them. But I still see no need to have them as packages before they can be used, officially, as part of a livecd system. Regards, Luciano Rocha -- lfr 0/0 From toshio at tiki-lounge.com Fri Oct 21 21:00:28 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 21 Oct 2005 14:00:28 -0700 Subject: SquashFS? In-Reply-To: <1129925598.2050.186.camel@bree.local.net> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> <1129925598.2050.186.camel@bree.local.net> Message-ID: <1129928428.3199.20.camel@localhost> On Fri, 2005-10-21 at 16:13 -0400, Jeremy Katz wrote: > On Thu, 2005-10-20 at 18:35 -0700, Toshio Kuratomi wrote: > > On Thu, 2005-10-20 at 13:20 -0500, Rex Dieter wrote: > > > Darko Ilic wrote: > > > > I wanted to ask what are the opinions on the subject, and is there any chance > > > > for SquashFS to make it's way into Fedora kernel by FC5? I`ve heard it was > > > > submitted to LKML recently and there was some discussions surrounding that > > > > and that it is a likely candidate for the upstream kernel. > > > > > > If it makes it upstream, then most likely, yes. > > > > I'd like to see a quality Fedora LiveCD. At my day job we're evaluating > > livecds for kiosks, recovery, and lab installs. What has struck me in > > recent days is that they're _all_ Debian based. If we want this to > > change, we need to create liveCDs that > > I think a lot of people want to see a live CD and there's something of a > push to get all of the pieces in place for in the FC5 timeframe. > > > squashfs and unionfs are both kernel modules that are pretty standard > > fare in the liveCD world but are not part of the mainline kernel. We > > need to include them in Fedora in order to advance our reputation in the > > liveCD arena. > > And the answer to this, at least traditionally, is that the answer is to > get the modules integrated upstream. > > Personally, I don't even think this is the biggest area that needs work > for a real, compelling live CD. Rather, various pieces of the stateless > infrastructure need to be finished and integrated into the core. I won't dispute that stateless will definitely add value. But stateless is, as you point out, a big area of work. These filesystems which are already being integrated into other livecds are a low hanging fruit in comparison. > > There are three alternatives here. 1) We don't care about LiveCDs. If > > you want to make a serious LiveCD based on Fedora, you have to fork and > > maintain some packages outside of the Fedora arena. > > Come on, it's not that you _can't_ do a live cd without them. > True :-) But I'm talking about gaining live-cd market share. A LiveCD without squashfs and unionfs and other goodies might help to encourage Fedora installs, but to help make the Fedora LiveCD the liveCD of choice means we need technologies that are relevant to that area. > > 2) We get these > > integrated into Core despite the fact that they aren't upstream > > [Example: GFS] > > And you'll note that GFS is gone again in the development due to the > problems that were had... > Woo hoo! Err... I mean, all the better to encourage thinking on the out of mainline but we need to include it issues :-) > > 3) We integrate these modules in Extras. > > We're working on module packaging for Extras. This could potentially be > a way to get people who really want squashfs and unionfs but aren't > willing to try to push upstream... It seems to me that pushing upstream has to be spearheaded by the kernel module developers, not the people who want to use the modules. Most of the time packagers are technically-competent consumers -- I want to use this functionality and I can do so in such a way that others can have an easier time using it as well. This means that we can try prodding upstream into doing our bidding but the means of effecting change are out of our hands. My major point is that a LiveCD has needs that Fedora Core does not. Because of the route we're travelling with Kadischi we have to think of some way to satisfy those needs that fits comfortably with the rest of the Fedora development philosophy and infrastructure. -Toshio -------------- 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 mhw at wittsend.com Fri Oct 21 19:11:54 2005 From: mhw at wittsend.com (Michael H. Warfield) Date: Fri, 21 Oct 2005 15:11:54 -0400 Subject: SquashFS? In-Reply-To: References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> Message-ID: <1129921914.4620.11.camel@canyon.wittsend.com> On Fri, 2005-10-21 at 13:58 -0400, Neal Becker wrote: > If we're talking about livecd FS components, I think we should also consider > shadowfs, or something similar. This looks _really_ interesting. That's basically what unionfs is. In fact, the shadowfs project in gnu hurd has been replaced by their unionfs project. Translucent fs and ifs [inheritance fs?] are other names for the same concept and were similar projects with similar goals. Some (ifs) have been abandoned while unionfs seems very active in development. There are several live cds (Knoppix and several varients) which use unionfs already for mapping a read/write ram storage and persistent storage over top of read-only file systems. Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- 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 strange at nsk.no-ip.org Fri Oct 21 21:04:37 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 21 Oct 2005 22:04:37 +0100 Subject: SquashFS? In-Reply-To: <1129926099.2050.191.camel@bree.local.net> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> <200510212003.16647.darko.ilic@gmail.com> <20051021182346.GA4660@nsk.no-ip.org> <1129926099.2050.191.camel@bree.local.net> Message-ID: <20051021210437.GC8935@nsk.no-ip.org> On Fri, Oct 21, 2005 at 04:21:39PM -0400, Jeremy Katz wrote: > On Fri, 2005-10-21 at 19:23 +0100, Luciano Miguel Ferreira Rocha wrote: > > On Fri, Oct 21, 2005 at 08:03:16PM +0200, Darko Ilic wrote: > > > Well, having unionfs included in the kernel would be *great* for live CDs. > > > > > > If we could push both unionfs and SquashFS to go upstream, that would improve > > > the quality of live CDs dramatically. > > > > To have unionfs and squashfs upstream would be nice, yes. But they can > > be used regardless of being upstream or not. > > Not for an official Fedora Live CD. One aspect is that it *must* be > built using components distributed as part of Fedora and we're > (generally speaking) against patches which aren't upstream because they > significantly raise the maintenance burden and then also get people > complaining because the kernel isn't "stock" > > Jeremy I now realize you're speaking about a live cd created by the fedora project, not about a package for creation of livecds. Sorry for the noise, my bad. Regards, Luciano Rocha -- lfr 0/0 From katzj at redhat.com Fri Oct 21 21:07:55 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Oct 2005 17:07:55 -0400 Subject: SquashFS? In-Reply-To: <20051021204218.GA8935@nsk.no-ip.org> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> <200510212003.16647.darko.ilic@gmail.com> <1129918800.9548.13.camel@localhost.localdomain> <20051021183300.GB4660@nsk.no-ip.org> <1129926254.2050.194.camel@bree.local.net> <20051021204218.GA8935@nsk.no-ip.org> Message-ID: <1129928875.2050.198.camel@bree.local.net> On Fri, 2005-10-21 at 21:42 +0100, Luciano Miguel Ferreira Rocha wrote: > On Fri, Oct 21, 2005 at 04:24:13PM -0400, Jeremy Katz wrote: > > On Fri, 2005-10-21 at 19:33 +0100, Luciano Miguel Ferreira Rocha wrote: > > > On Fri, Oct 21, 2005 at 08:20:00PM +0200, Thorsten Leemhuis wrote: > > > > We're working on a kernel-module-standard for fedora-extras. I can > > > > package unionfs and SqashFS then if that would be enough for the LiveCD. > > > > But there might be a small problem with SqashFS and the initrd: > > > > > > A kernel-module-standard is a necessity for fedora-extras but not for > > > unionfs/squashfs, IMO. They're small, and can be compiled on-the-fly, > > > when creating the live cd iso. > > > > This is a non-starter. Allowing compilation of stuff adds far too much > > of a "random" element with regards to what's on the system. > > I don't understand that sentence. A "mklivecd" program already has to: > > 1. create initial root > 2. install packages > 3. configure livecd system > 4. create livecd initrd Creating the live cd initrd should just happen with the standard tools. Which means mkinitrd doing it when the kernel package is installed. > What's the damage of adding: > 3b. make unionfs squashfs? See above. > > > And I don't think the lack of support for a "squashed" initrd is a > > > problem. I believe initramfs works much better for livecds, anyway. :) > > > > But you need to get the squashfs module into the initrd[1]. > > > > Jeremy > > > > [1] Using initrd as a generic term for either initrd or initramfs. Note > > that Core has been using initramfs by default since FC3... this is one > > of the reasons why I say that the changes for live CD at an > > infrastructure level need to be better integrated. Peter has made some > > changes in mkinitrd which will help make this easier and I have the > > start of the changes for kadischi, but I probably won't get back to > > finishing them up until after test1 > > Well, I'd expected the initrd/initramfs to be cunstom built, anyway. > Specially for the part of searching for the livecd image (in a cdrom, > nfs, hdd, whatever). We're making changes to the mkinitrd infrastructure to allow plugging things like this in. This will allow for greater consistency between various methods of system initrds and avoid having to replicate everything in fifteen different places. > And about current mkinitrd, isn't --preload=mod.ko sufficient? mkinitrd gets run by new-kernel-pkg, so there's not really a chance to add random arguments Jeremy From katzj at redhat.com Fri Oct 21 21:09:38 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Oct 2005 17:09:38 -0400 Subject: SquashFS? In-Reply-To: <20051021204920.GB8935@nsk.no-ip.org> References: <200510202008.53326.darko.ilic@gmail.com> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> <200510212003.16647.darko.ilic@gmail.com> <20051021182346.GA4660@nsk.no-ip.org> <1129926099.2050.191.camel@bree.local.net> <20051021204920.GB8935@nsk.no-ip.org> Message-ID: <1129928978.2050.201.camel@bree.local.net> On Fri, 2005-10-21 at 21:49 +0100, Luciano Miguel Ferreira Rocha wrote: > On Fri, Oct 21, 2005 at 04:21:39PM -0400, Jeremy Katz wrote: > > On Fri, 2005-10-21 at 19:23 +0100, Luciano Miguel Ferreira Rocha wrote: > > > On Fri, Oct 21, 2005 at 08:03:16PM +0200, Darko Ilic wrote: > > > > Well, having unionfs included in the kernel would be *great* for live CDs. > > > > > > > > If we could push both unionfs and SquashFS to go upstream, that would improve > > > > the quality of live CDs dramatically. > > > > > > To have unionfs and squashfs upstream would be nice, yes. But they can > > > be used regardless of being upstream or not. > > > > Not for an official Fedora Live CD. One aspect is that it *must* be > > built using components distributed as part of Fedora and we're > > (generally speaking) against patches which aren't upstream because they > > significantly raise the maintenance burden and then also get people > > complaining because the kernel isn't "stock" > > I was thinking of adding the source of the modules to the "official > fedora livecd maker". The _binary_ rpm would have the sources. > > Thus, no need for kernel patches or any unionfs/squashfs package at all. > > The fedora livecd build process will compile the modules on livecd > creation, using the kernel-dev package for the kernel to be used by the > livecd. As the livecd system won't be updated anyway, there isn't even a > need of keeping any unionfs/squashfs package at the same level of the > kernel package. And if the compiler on the system is different? This is a really dangerous path to go down. Also, unionfs and squashfs have to be at the same level as the kernel package because that's where the kernel for the live cd comes from. Jeremy From katzj at redhat.com Fri Oct 21 21:18:38 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Oct 2005 17:18:38 -0400 Subject: SquashFS? In-Reply-To: <1129928428.3199.20.camel@localhost> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> <1129925598.2050.186.camel@bree.local.net> <1129928428.3199.20.camel@localhost> Message-ID: <1129929519.2050.210.camel@bree.local.net> On Fri, 2005-10-21 at 14:00 -0700, Toshio Kuratomi wrote: > On Fri, 2005-10-21 at 16:13 -0400, Jeremy Katz wrote: > > On Thu, 2005-10-20 at 18:35 -0700, Toshio Kuratomi wrote: > > > On Thu, 2005-10-20 at 13:20 -0500, Rex Dieter wrote: > > > > Darko Ilic wrote: > > > > > I wanted to ask what are the opinions on the subject, and is there any chance > > > > > for SquashFS to make it's way into Fedora kernel by FC5? I`ve heard it was > > > > > submitted to LKML recently and there was some discussions surrounding that > > > > > and that it is a likely candidate for the upstream kernel. > > > > > > > > If it makes it upstream, then most likely, yes. > > > > > > I'd like to see a quality Fedora LiveCD. At my day job we're evaluating > > > livecds for kiosks, recovery, and lab installs. What has struck me in > > > recent days is that they're _all_ Debian based. If we want this to > > > change, we need to create liveCDs that > > > > I think a lot of people want to see a live CD and there's something of a > > push to get all of the pieces in place for in the FC5 timeframe. > > > > > squashfs and unionfs are both kernel modules that are pretty standard > > > fare in the liveCD world but are not part of the mainline kernel. We > > > need to include them in Fedora in order to advance our reputation in the > > > liveCD arena. > > > > And the answer to this, at least traditionally, is that the answer is to > > get the modules integrated upstream. > > > > Personally, I don't even think this is the biggest area that needs work > > for a real, compelling live CD. Rather, various pieces of the stateless > > infrastructure need to be finished and integrated into the core. > > I won't dispute that stateless will definitely add value. But stateless > is, as you point out, a big area of work. These filesystems which are > already being integrated into other livecds are a low hanging fruit in > comparison. Without the work occurring, a live CD is _always_ going to be playing catch-up with the rest of the system. And there are a lot of things which end up having to be hacked around or duplicated, cf the mklivecd_initrd stuff. > > > There are three alternatives here. 1) We don't care about LiveCDs. If > > > you want to make a serious LiveCD based on Fedora, you have to fork and > > > maintain some packages outside of the Fedora arena. > > > > Come on, it's not that you _can't_ do a live cd without them. > > > True :-) But I'm talking about gaining live-cd market share. > A LiveCD without squashfs and unionfs and other goodies might help to > encourage Fedora installs, but to help make the Fedora LiveCD the liveCD > of choice means we need technologies that are relevant to that area. There are always going to be multiple live cds, just like there are multiple distributions. And I think we get much bigger wins from having the technology done properly than with filesystems... at the end of the day, the filesystem used is not what you decide on a technology on[1] > > > 3) We integrate these modules in Extras. > > > > We're working on module packaging for Extras. This could potentially be > > a way to get people who really want squashfs and unionfs but aren't > > willing to try to push upstream... > > It seems to me that pushing upstream has to be spearheaded by the kernel > module developers, not the people who want to use the modules. Most of > the time packagers are technically-competent consumers -- I want to use > this functionality and I can do so in such a way that others can have an > easier time using it as well. This means that we can try prodding > upstream into doing our bidding but the means of effecting change are > out of our hands. Education can go a long way... also, letting an upstream know "we'd really like to use this, but we can really only depend on things in the upstream kernel" has positive effects a lot of the time. Has anyone even talked with the upstream developers of unionfs and squashfs about moving to the upstream kernel? They could even have a good reason :) > My major point is that a LiveCD has needs that Fedora Core does not. > Because of the route we're travelling with Kadischi we have to think of > some way to satisfy those needs that fits comfortably with the rest of > the Fedora development philosophy and infrastructure. After some investigation, I really don't feel the needs are that different. Jeremy From perbj at stanford.edu Fri Oct 21 21:46:29 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Fri, 21 Oct 2005 14:46:29 -0700 Subject: Supporting third party software in /usr/local In-Reply-To: References: <1129858090.3263.32.camel@localhost.localdomain> <1129920062.3075.3.camel@localhost.localdomain> Message-ID: <1129931190.3075.26.camel@localhost.localdomain> On Fri, 2005-10-21 at 21:46 +0100, Mike Hearn wrote: > On Fri, 21 Oct 2005 11:41:01 -0700, Per Bjornsson wrote: > > Boy, I should really learn to proofread better! I meant to say that I had > > put desktop files in /usr/local/share/applications and it _does_ work on > > my systems, and I have not changed anything in the menu definition files. > > (Only tested on FC4 though, I don't have anything older around right now.) > > Hmm, that's odd, doesn't work here. Maybe XDG_DATA_DIRS includes it on > your system and so it doesn't need to be merged into the menu file > explicitly? Actually, as far as I can tell XDG_DATA_DIRS is just not set at all in my environment. (Just checking in a shell, but I suppose the panel should have the same environment.) In this case, the Freedesktop basedir spec says that the value /usr/local/share/:/usr/share/ should be used. ( http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html if anyone is interested in looking at this.) As far as I can see, if the variable is simply not set at all, everything should just work, so just not having the variable set seems like a good default to me. Is this environment variable getting set on a fresh FC4 installation somewhere? (If this was the case, wouldn't it be getting set in /etc/profile or somewhere in /etc/profile.d? I can't find anything about setting that environment variable there.) Mike, could you check if it is actually set on your computer (and in that case where it's getting set)? /Per From mpeters at mac.com Fri Oct 21 22:31:17 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 21 Oct 2005 15:31:17 -0700 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <1129877978.3410.49.camel@localhost.localdomain> References: <1129877978.3410.49.camel@localhost.localdomain> Message-ID: <1129933878.19288.3.camel@locolhost.localdomain> On Fri, 2005-10-21 at 16:59 +1000, Mike MacCana wrote: > > Why should Fedora and Red Hat encourage installing software in a > non-standard method? I agree with you that rpm is the proper way to install software on an rpm based system. However, some software is not available as rpm - and I don't believe that the end user should be responsible for creating an rpm themselves. There should at least be basic support (IE ldconfig knowing about stuff in /usr/local/lib) for installing software from source, which would also allow tools like autopackage to install there and not conflict with the rpm system. From mpeters at mac.com Fri Oct 21 22:35:43 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 21 Oct 2005 15:35:43 -0700 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: References: <1129877978.3410.49.camel@localhost.localdomain> Message-ID: <1129934144.19288.8.camel@locolhost.localdomain> On Fri, 2005-10-21 at 14:55 +0100, Mike Hearn wrote: > > b) Non-technical end users like this particular non-standard method Yeah - but that's actually scary. Non technical users aren't going to be watching security lists etc. to know its time to update, rpm is just part of packaging with Fedora - rpm packages can be served from a repository that updates the packages when needed so that the non-technical end user just has to hit a button and have their software updated. Take the recent rtf patch to AbiWord - people using Fedora with the repositories got updates that fixed the issue because the updates were pushed through yum. People using the autopackage - they must find out by some other means that an update is available to fix a problem they may not know exists. From mike at plan99.net Sat Oct 22 00:47:58 2005 From: mike at plan99.net (Mike Hearn) Date: Sat, 22 Oct 2005 01:47:58 +0100 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) References: <1129877978.3410.49.camel@localhost.localdomain> <1129934144.19288.8.camel@locolhost.localdomain> Message-ID: On Fri, 21 Oct 2005 15:35:43 -0700, Michael A. Peters wrote: > People using the autopackage - they must find out by some other means that > an update is available to fix a problem they may not know exists. Don't panic, it's just a bug. We have quite detailed blueprints for an automatic online update service, it just hasn't been implemented yet. From mricon at gmail.com Sat Oct 22 02:16:19 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Fri, 21 Oct 2005 22:16:19 -0400 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: References: <1129877978.3410.49.camel@localhost.localdomain> <1129934144.19288.8.camel@locolhost.localdomain> Message-ID: On 21/10/05, Mike Hearn wrote: > > People using the autopackage - they must find out by some other means that > > an update is available to fix a problem they may not know exists. > > Don't panic, it's just a bug. We have quite detailed blueprints for > an automatic online update service, it just hasn't been implemented yet. Autopackage has been "solving the world hunger" for the past few years. It has failed so far (I've seen a bonafide .package file offered to me ONCE in my entire life), and there are no indications that the "tides" will turn. Nobody is interested in a Packaging and Updating System to Obsolete All Packaging and Updating Systems, since every major distribution has already moved on past this problem: * With Debian/Ubuntu you can already install almost any bit of software ever written * Fedora Extras is getting us there * Gentoo et al are also not interested * Linspire has their own system * Proprietary vendors just release statically compiled tarballs, or generally lack clue (usually both) Why are you so set on making it more difficult to support the systems? In our previous conversation on the Ubuntu list, I've already shown you how Autopackage will lead to problems, since its dependency tracking only checks for things that are required by the package currently installed: * foo requires libbaz-1.0, which autopackage fetches and installs * bar requires libbaz-2.0, which autopackage fetches and installs * foo stops working, since its dependency is no longer there If your answer starts with "b" and ends with "undle", then how is this different from LSB RPMs and the aforementioned statically-happy vendors? Can you state clearly the problem that autopackage is trying to solve? As a bonus, can you state clearly how autopackage won't ultimately do more harm by potentially breaking systems or leaving them vulnerable, since it won't do updates? And when it does become smart enough to do updates, can you tell us how your claim that "repositories are not sustainable" will still hold true? It seems to me that you're repeatedly trying to enter a door that's no longer there. -- Konstantin Ryabitsev http://www.mricon.com/ From mpeters at mac.com Sat Oct 22 03:08:28 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 21 Oct 2005 20:08:28 -0700 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: References: <1129877978.3410.49.camel@localhost.localdomain> <1129934144.19288.8.camel@locolhost.localdomain> Message-ID: <1129950508.19288.12.camel@locolhost.localdomain> On Fri, 2005-10-21 at 22:16 -0400, Konstantin Ryabitsev wrote: > * Proprietary vendors just release statically compiled tarballs, or > generally lack clue (usually both) I use to use RealBasic in OS X I decided to try the RealBasic for Linux. Downloaded the rpm and looked at it with rpm -qlp. they have a directory in /usr/bin - and lots of stuff with spaces in the path. I never installed it. Clearly their packager doesn't have a clue. From shiva at sewingwitch.com Sat Oct 22 04:26:41 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 21 Oct 2005 21:26:41 -0700 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <1129933878.19288.3.camel@locolhost.localdomain> References: <1129877978.3410.49.camel@localhost.localdomain> <1129933878.19288.3.camel@locolhost.localdomain> Message-ID: <8A99757938709E19EFFE0D6C@[10.0.0.14]> --On Friday, October 21, 2005 3:31 PM -0700 "Michael A. Peters" wrote: > However, some software is not available as rpm - and I don't believe > that the end user should be responsible for creating an rpm themselves. It's relatively straightforward to create a spec file for simple applications that packages a source tarball. A simple spec file is little more than a meta-script that does the configure/make/makeinstall, and has some header info for the RPM DB that any app should have anyway (like name, summary, description, URL). Look at how easy it is to make an RPM from the SpamAssassin tarball. (Instructions are on the SA download page. It's a one-liner.) From mpeters at mac.com Sat Oct 22 05:28:49 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 21 Oct 2005 22:28:49 -0700 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <8A99757938709E19EFFE0D6C@[10.0.0.14]> References: <1129877978.3410.49.camel@localhost.localdomain> <1129933878.19288.3.camel@locolhost.localdomain> <8A99757938709E19EFFE0D6C@[10.0.0.14]> Message-ID: <1129958930.19288.22.camel@locolhost.localdomain> On Fri, 2005-10-21 at 21:26 -0700, Kenneth Porter wrote: > --On Friday, October 21, 2005 3:31 PM -0700 "Michael A. Peters" > wrote: > > > However, some software is not available as rpm - and I don't believe > > that the end user should be responsible for creating an rpm themselves. > > It's relatively straightforward to create a spec file for simple > applications that packages a source tarball. Yes it is. If you know how to do it. I only install software on my system through rpm. But being relatively simple for someone like me does not mean it is relatively simple for other people, and it does require a learning process. Some upstream tarballs contain a generic spec file that works on most systems - then you can just do rpmbuild -ta foo.tar.gz but I've actually found quite a few that have packaging errors themselves. Then there's issue where DESTDIR support is not always proper and some patches to the Makefile need to be added, gnome applications will require you to disable gconf updating during the install and do it in the post script, etc. Users should not be expected to learn how to package rpm's unless they need to learn it for another reason. I do think that developers should learn rpm so they can provide a *quality* generic spec file, some spec files I've seen are just scary (and often not generated by autoconf so the version ends up being wrong if they don't remember to manually update it for a new release) From shiva at sewingwitch.com Sat Oct 22 08:11:21 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 22 Oct 2005 01:11:21 -0700 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <1129958930.19288.22.camel@locolhost.localdomain> References: <1129877978.3410.49.camel@localhost.localdomain> <1129933878.19288.3.camel@locolhost.localdomain> <8A99757938709E19EFFE0D6C@[10.0.0.14]> <1129958930.19288.22.camel@locolhost.localdomain> Message-ID: <0E7777A9791E1F3AC15102C5@[10.169.6.233]> --On Friday, October 21, 2005 10:28 PM -0700 "Michael A. Peters" wrote: > Users should not be expected to learn how to package rpm's unless they > need to learn it for another reason. I do think that developers should > learn rpm so they can provide a *quality* generic spec file, some spec > files I've seen are just scary (and often not generated by autoconf so > the version ends up being wrong if they don't remember to manually > update it for a new release) Right. Anyone who can learn how to use autoconf or Make should be able to write a simple spec file. Then the end user can issue "rpmbuild -ta xxx.tar.gz" instead of "configure/make/make install". Does autoconf now have the ability to write spec files? If so, that could simplify this issue for a lot of developers. From nicolas.mailhot at laposte.net Sat Oct 22 09:44:16 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 22 Oct 2005 11:44:16 +0200 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: References: <1129877978.3410.49.camel@localhost.localdomain> <1129934144.19288.8.camel@locolhost.localdomain> Message-ID: <1129974257.10973.48.camel@rousalka.dyndns.org> Le vendredi 21 octobre 2005 ? 22:16 -0400, Konstantin Ryabitsev a ?crit : > Can you state clearly the problem that autopackage is trying to solve? > As a bonus, can you state clearly how autopackage won't ultimately do > more harm by potentially breaking systems or leaving them vulnerable, And now they're experimenting elaborate methods of protecting the system from autopackages. Somehow I'm not surprised. (Not that this kind of sandboxing couldn't be done on top of rpm as the buildsys shows. But somehow we're not feeling strongly this sandboxing need today in the rpm world) Ultimately, when you remove the requirement of the packager to know the system it will deploy on (clueless packagers), and target normal people (clueless admins), you have to find something else to take care of system sanity. I'm less than convinced it can be done automagicaly without reducing the functionality of the system to that of a mobile phone/game console. A computer processes lots of user data, how are you going to decide which data is safe to access from untrusted apps and which isn't ? Of course you can reduce the scope to apps that only access private data, but there's not a lot of them out there. And you only need to care about user data. If reinstalling a clean system was not fast nowadays, FC couldn't have had a short release cycle. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From wrrhdev at riede.org Sat Oct 22 15:54:55 2005 From: wrrhdev at riede.org (Willem Riede) Date: Sat, 22 Oct 2005 15:54:55 +0000 Subject: yum multi-lib dependency processing Message-ID: <1129996495l.3354l.1l@serve.riede.org> It is my observation (fc5-devel), that when yum decides a package (B) that is installed in both i386 and x86_64 versions needs upgrading because of a dependancy on a newer version of package (B) by package (A) I'm telling yum to install, it will add only one (B.x86_64) to the update set, and then will complain about conflicting files when I tell it to go ahead. On the other hand, if I tell yum explicitely to upgrate that multi-lib package (B), it correctly figures out that both need updating, and there are no conflicts. So my question is, can we teach yum to upgrade both architectures when an upgrade of one is indicated as a side effect of the current transaction? Thanks, Willem Riede. From mike at plan99.net Sat Oct 22 18:31:41 2005 From: mike at plan99.net (Mike Hearn) Date: Sat, 22 Oct 2005 19:31:41 +0100 Subject: Supporting third party software in /usr/local References: <1129858090.3263.32.camel@localhost.localdomain> <1129920062.3075.3.camel@localhost.localdomain> <1129931190.3075.26.camel@localhost.localdomain> Message-ID: On Fri, 21 Oct 2005 14:46:29 -0700, Per Bjornsson wrote: > Mike, could you check if it is actually set > on your computer (and in that case where it's getting set)? Ah, it was being set in a startup script. I'm not sure how or why - presumably I added it there at some point. This box has been through a few upgrades. If I unset it, menu items work there too. Icons in /usr/local/share/pixmaps seem not to work though. Marlin at least relies on this... thanks -mike From mike at plan99.net Sat Oct 22 18:35:53 2005 From: mike at plan99.net (Mike Hearn) Date: Sat, 22 Oct 2005 19:35:53 +0100 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) References: <1129877978.3410.49.camel@localhost.localdomain> <1129934144.19288.8.camel@locolhost.localdomain> Message-ID: On Fri, 21 Oct 2005 22:16:19 -0400, Konstantin Ryabitsev wrote: > Can you state clearly the problem that autopackage is trying to solve? This has got nothing to do with the original question. PLEASE try and keep this thread on topic! Anyway, I don't care to answer this question again. I'll let Linux end-users answer it instead. http://www.abisource.com/mailinglists/abiword-dev/2005/Oct/0024.html http://ubuntuforums.org/showthread.php?t=23008&highlight=autopackage http://autopackage.org/forums/viewtopic.php?t=144 http://yergler.net/blog/archives/2005/08/17/packaging-applications-for-linux-with-autopackage http://article.gmane.org/gmane.comp.autopackage.devel/3439 http://autopackage.org/forums/viewtopic.php?t=115 http://www.linuxformat.co.uk/index.php?name=PNphpBB2&file=viewtopic&t=926 (*) http://article.gmane.org/gmane.comp.autopackage.devel/2850 (**) (*) LXF is a well known UK magazine which reviewed the software and gave it "hot pick" status, unfortunately, no archives of that issue are available, not even to me! (**) TUX Magazine comes as a subscription PDF so I can't link to it directly. More letters were sent in the following months. From buildsys at redhat.com Sat Oct 22 21:46:26 2005 From: buildsys at redhat.com (Build System) Date: Sat, 22 Oct 2005 17:46:26 -0400 Subject: rawhide report: 20051022 changes Message-ID: <200510222146.j9MLkQ9d022390@porkchop.devel.redhat.com> New package kernel-xen Older kernel (temporary) to enable xen packages for rawhide Updated Packages: checkpolicy-1.27.16-1 --------------------- * Thu Oct 20 2005 Dan Walsh 1.27.16-1 - Latest upgrade from NSA * Removed obsolete cond_check_type_rules() function and call and cond_optimize_lists() call from checkpolicy.c; these are handled during parsing and expansion now. * Updated calls to expand_module for interface change. * Changed checkmodule to verify that expand_module succeeds when building base modules. * Merged module compiler fixes from Joshua Brindle. * Removed direct calls to hierarchy_check_constraints() and check_assertions() from checkpolicy since they are now called internally by expand_module(). docbook-dtds-1.0-29 ------------------- * Fri Oct 21 2005 Tim Waugh 1.0-29 - Scriptlet fix (bug #171229). eclipse-cdt-1:3.0.0_fc-2 ------------------------ * Fri Oct 21 2005 Andrew Overholt 3.0.0_fc-2 - Rebuild against gcc 4.0.2 gimp-help-2-0.1.0.9.1 --------------------- * Fri Oct 21 2005 Nils Philippsen - version 2-0.9 gnuplot-4.0.0-9 --------------- * Fri Oct 21 2005 Phil Knirsch 4.0.0-9 - Fixed 64bit problem with x11 display (#167508) - Added missing file ownage of /usr/share/gnuplot (#169333) kernel-2.6.13-1.1622_FC5 ------------------------ * Sat Oct 22 2005 Dave Jones - 2.6.14-rc5-git1 less-392-2 ---------- * Fri Oct 21 2005 Jindrich Novy 392-2 - fix the -F option (#79650), thanks to Petr Raszyk libselinux-1.27.13-2 -------------------- * Fri Oct 21 2005 Dan Walsh 1.9.23-2 - Need to check for /sbin/telinit * Thu Oct 20 2005 Dan Walsh 1.27.13-1 - Update to latest from NSA * Merged fixes for make DESTDIR= builds from Joshua Brindle. libsemanage-1.3.31-1 -------------------- * Fri Oct 21 2005 Dan Walsh 1.3.30-1 - Update from NSA * Fixed policy file leaks in semanage_load_module and semanage_write_module. * Merged further database work from Ivan Gyurdiev. * Fixed bug in semanage_direct_disconnect. * Thu Oct 20 2005 Dan Walsh 1.3.28-1 - Update from NSA * Merged interface renaming patch from Ivan Gyurdiev. * Merged policy component patch from Ivan Gyurdiev. * Renamed 'check=' configuration value to 'expand-check=' for clarity. * Changed semanage_commit_sandbox to check for and report errors on rename(2) calls performed during rollback. * Added optional check= configuration value to semanage.conf and updated call to sepol_expand_module to pass its value to control assertion and hierarchy checking on module expansion. * Merged fixes for make DESTDIR= builds from Joshua Brindle. * Tue Oct 18 2005 Dan Walsh 1.3.24-1 - Update from NSA * Merged default database from Ivan Gyurdiev. * Merged removal of connect requirement in policydb backend from Ivan Gyurdiev. * Merged commit locking fix and lock rename from Joshua Brindle. * Merged transaction rollback in lock patch from Joshua Brindle. * Changed default args for load_policy to be null, as it no longer takes a pathname argument and we want to preserve booleans. * Merged move local dbase initialization patch from Ivan Gyurdiev. * Merged acquire/release read lock in databases patch from Ivan Gyurdiev. * Merged rename direct -> policydb as appropriate patch from Ivan Gyurdiev. * Added calls to sepol_policy_file_set_handle interface prior to invoking sepol operations on policy files. * Updated call to sepol_policydb_from_image to pass the handle. libsepol-1.9.25-1 ----------------- * Fri Oct 21 2005 Dan Walsh 1.9.25-1 - Upgrade to latest from NSA * Merged users cleanup patch from Ivan Gyurdiev. * Merged user record memory leak fix from Ivan Gyurdiev. * Merged reorganize users patch from Ivan Gyurdiev. - Need to check for /sbin/telinit mkinitrd-5.0.8-1 ---------------- * Fri Oct 21 2005 Peter Jones - 5.0.8-1 - don't clobber cmdline in mkrootdev (fixes runlevel selection) * Fri Oct 21 2005 Jeremy Katz - 5.0.7-1 - fix new-kernel-pkg --multiboot= mtr-2:0.69-7 ------------ * Fri Oct 21 2005 Phil Knirsch 2:0.69-7 - Fixed xmtr to be installed in /usr/bin instead of /usr/X11R6/bin (#170945) nautilus-2.12.1-3 ----------------- * Fri Oct 21 2005 Matthias Clasen 2.12.1-3 - Only show the "Format menu item if gfloppy is present * Fri Oct 21 2005 Matthias Clasen 2.12.1-2 - Add a "Format" context menu item to the floppy in "Computer" * Thu Oct 06 2005 Matthias Clasen 2.12.1-1 - Update to 2.12.1 nc-1.82-2 --------- * Fri Oct 21 2005 Radek Vokal 1.82-2 - use SO_REUSEADDR (#171315) * Tue Sep 27 2005 Tomas Mraz 1.82-1 - update from OpenBSD upstream CVS - fix pollhup patch so it reads everything before shutdown * Wed May 11 2005 David Woodhouse 1.78-2 - Don't ignore POLLHUP and go into an endless loop (#156835) netpbm-10.30-1 -------------- * Fri Oct 21 2005 Jindrich Novy 10.30-1 - update to 10.30 - update manpath, gcc4 patches - update security patch - fixed length problem in rle_addhist - update partly upstreamed bmptopnm, pnmtopng patches - drop manpath patch - regenerate man pages openCryptoki-2.1.6-1 -------------------- * Fri Oct 21 2005 Phil Knirsch 2.1.6-rc2.1 - Update to openCryptoki-2.1.6-rc2 * Tue Sep 06 2005 Phil Knirsch 2.1.5-6.10 - Fixed quite a few warnings and actual errors (#143768) - Fixed the initscript for failed startups (#154495) * Wed Mar 02 2005 Phil Knirsch 2.1.5-6.9 - bump release and rebuild with gcc 4 openssl-0.9.7f-11 ----------------- * Fri Oct 21 2005 Tomas Mraz 0.9.7f-11 - updated IBM ICA engine library and patch to latest upstream version * Wed Oct 12 2005 Tomas Mraz 0.9.7f-10 - fix CAN-2005-2969 - remove SSL_OP_MSIE_SSLV2_RSA_PADDING which disables the countermeasure against man in the middle attack in SSLv2 (#169863) - use sha1 as default for CA and cert requests - CAN-2005-2946 (#169803) * Tue Aug 23 2005 Tomas Mraz 0.9.7f-9 - add *.so.soversion as symlinks in /lib (#165264) - remove unpackaged symlinks (#159595) - fixes from upstream (constant time fixes for DSA, bn assembler div on ppc arch, initialize memory on realloc) redhat-menus-5.0.2-1 -------------------- * Fri Oct 21 2005 Matthias Clasen 5.0.2-1 - Hide gfloppy by default selinux-policy-strict-1.27.2-1 ------------------------------ * Fri Oct 21 2005 Dan Walsh 1.27.2-1 - Update to latest from NSA * Merged patch from Chad Hanson. Modified MLS constraints. Provided comments for the MLS attributes. * Merged two patches from Thomas Bleher which made some minor fixes and cleanups. * Merged patches from Russell Coker. Added comments to some of the MLS attributes. Added the secure_mode_insmod boolean to determine whether the system permits loading policy, setting enforcing mode, and changing boolean values. Made minor fixes for the cdrecord_domain macro, application_domain, newrole_domain, and daemon_base_domain macros. Added rules to allow the mail server to access the user home directories in the targeted policy and allows the postfix showq program to do DNS lookups. Minor fixes for the MCS policy. Made other minor fixes and cleanups. * Merged patch from Dan Walsh. Added opencd, pegasus, readahead, and roundup policies. Created can_access_pty macro to handle pty output. Created nsswithch_domain macro for domains using nsswitch. Added mcs transition rules. Removed mqueue and added capifs genfscon entries. Added dhcpd and pegasus ports. Added domain transitions from login domains to pam_console and alsa domains. Added rules to allow the httpd and squid domains to relay more protocols. For the targeted policy, removed sysadm_r role from unconfined_t. Made other fixes and cleanups. selinux-policy-targeted-1.27.2-1 -------------------------------- * Fri Oct 21 2005 Dan Walsh 1.27.2-1 - Update to latest from NSA * Merged patch from Chad Hanson. Modified MLS constraints. Provided comments for the MLS attributes. * Merged two patches from Thomas Bleher which made some minor fixes and cleanups. * Merged patches from Russell Coker. Added comments to some of the MLS attributes. Added the secure_mode_insmod boolean to determine whether the system permits loading policy, setting enforcing mode, and changing boolean values. Made minor fixes for the cdrecord_domain macro, application_domain, newrole_domain, and daemon_base_domain macros. Added rules to allow the mail server to access the user home directories in the targeted policy and allows the postfix showq program to do DNS lookups. Minor fixes for the MCS policy. Made other minor fixes and cleanups. * Merged patch from Dan Walsh. Added opencd, pegasus, readahead, and roundup policies. Created can_access_pty macro to handle pty output. Created nsswithch_domain macro for domains using nsswitch. Added mcs transition rules. Removed mqueue and added capifs genfscon entries. Added dhcpd and pegasus ports. Added domain transitions from login domains to pam_console and alsa domains. Added rules to allow the httpd and squid domains to relay more protocols. For the targeted policy, removed sysadm_r role from unconfined_t. Made other fixes and cleanups. system-config-date-1.7.99.3-1 ----------------------------- * Fri Oct 21 2005 Nils Philippsen 1.7.99.3 - revamp pot file generation (#171330) * Fri Oct 14 2005 Nils Philippsen - don't use pam_stack (#170623) system-config-keyboard-1.2.7-1 ------------------------------ * Thu Oct 20 2005 Paul Nasrat - 1.2.7-1 - Update pam file (#170630) - New firstboot module - Compiled python xen-3.0-0.20051021.fc5 ---------------------- * Fri Oct 21 2005 Jeremy Katz - 3.0-0.20051021.fc5 - update to current -unstable From mpeters at mac.com Sun Oct 23 04:24:16 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 22 Oct 2005 21:24:16 -0700 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <0E7777A9791E1F3AC15102C5@[10.169.6.233]> References: <1129877978.3410.49.camel@localhost.localdomain> <1129933878.19288.3.camel@locolhost.localdomain> <8A99757938709E19EFFE0D6C@[10.0.0.14]> <1129958930.19288.22.camel@locolhost.localdomain> <0E7777A9791E1F3AC15102C5@[10.169.6.233]> Message-ID: <1130041456.5530.2.camel@locolhost.localdomain> On Sat, 2005-10-22 at 01:11 -0700, Kenneth Porter wrote: > > Does autoconf now have the ability to write spec files? If so, that could > simplify this issue for a lot of developers. > Yes - many projects have foo.spec.in When autoconf is run to generate the configure file, foo.spec is generated - thus you can have version information etc. inside the spec file that does not need to be maintained by the developer (ie use @VERSION@ for the Version header info) From rc040203 at freenet.de Sun Oct 23 04:33:33 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Oct 2005 06:33:33 +0200 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <1130041456.5530.2.camel@locolhost.localdomain> References: <1129877978.3410.49.camel@localhost.localdomain> <1129933878.19288.3.camel@locolhost.localdomain> <8A99757938709E19EFFE0D6C@[10.0.0.14]> <1129958930.19288.22.camel@locolhost.localdomain> <0E7777A9791E1F3AC15102C5@[10.169.6.233]> <1130041456.5530.2.camel@locolhost.localdomain> Message-ID: <1130042013.28858.201.camel@mccallum.corsepiu.local> On Sat, 2005-10-22 at 21:24 -0700, Michael A. Peters wrote: > On Sat, 2005-10-22 at 01:11 -0700, Kenneth Porter wrote: > > > > > Does autoconf now have the ability to write spec files? No. Autoconf doesn't have the ability to write spec files. > If so, that could > > simplify this issue for a lot of developers. > > > > Yes - many projects have foo.spec.in True, but it's not autoconf which generates them, nor does autoconf have any knowledge on rpm nor any other packaging tool. It's the developers having added support for rpm-specs as convenience for those who have use for it. Ralf From mpeters at mac.com Sun Oct 23 06:06:20 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 22 Oct 2005 23:06:20 -0700 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems (was: re: /usr/local) In-Reply-To: <1130042013.28858.201.camel@mccallum.corsepiu.local> References: <1129877978.3410.49.camel@localhost.localdomain> <1129933878.19288.3.camel@locolhost.localdomain> <8A99757938709E19EFFE0D6C@[10.0.0.14]> <1129958930.19288.22.camel@locolhost.localdomain> <0E7777A9791E1F3AC15102C5@[10.169.6.233]> <1130041456.5530.2.camel@locolhost.localdomain> <1130042013.28858.201.camel@mccallum.corsepiu.local> Message-ID: <1130047580.6760.1.camel@locolhost.localdomain> On Sun, 2005-10-23 at 06:33 +0200, Ralf Corsepius wrote: > True, but it's not autoconf which generates them, nor does autoconf have > any knowledge on rpm nor any other packaging tool. Correct - foo.spec.in has to be added by the developer, and maintained by the developer. From toshio at tiki-lounge.com Sun Oct 23 07:08:40 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sun, 23 Oct 2005 00:08:40 -0700 Subject: SquashFS? In-Reply-To: <1129929519.2050.210.camel@bree.local.net> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> <1129925598.2050.186.camel@bree.local.net> <1129928428.3199.20.camel@localhost> <1129929519.2050.210.camel@bree.local.net> Message-ID: <1130051320.3782.10.camel@localhost> On Fri, 2005-10-21 at 17:18 -0400, Jeremy Katz wrote: > On Fri, 2005-10-21 at 14:00 -0700, Toshio Kuratomi wrote: > > My major point is that a LiveCD has needs that Fedora Core does not. > > Because of the route we're travelling with Kadischi we have to think of > > some way to satisfy those needs that fits comfortably with the rest of > > the Fedora development philosophy and infrastructure. > > After some investigation, I really don't feel the needs are that > different. Perhaps "needs" is the wrong word then. How about a LiveCD needs different technologies to achieve its ends than a hard drive install. In our two instances: squashfs addresses two needs of a LiveCD: 1) Ability to add more information to a limited space. This has not seemed to be a goal for Core. We talk about limiting the size of the necessary install in terms of dropping packages from the necessary set, not how to make more applications available in less space. 2) Faster access to programs on disk. Fedora has worked to increase startup speed via bootchart profiling, readahead, early login in gdm, and prelink. All of these benefit LiveCDs as well. Core has not decided to make a read-only, compressed image of all the programs and files on the system so they load from disk faster. Possibly because you'd have to remaster the image that we boot from. It's a pretty poor tradeoff for Core. But for a LiveCD that is already read-only and already remastered anytime there's a change, and where transferring from disk is tremendously slower, it's a natural fit. unionfs overcomes a LiveCD's inability to write to its filesystem. The goal is to provide the ability to modify configuration, provide a place to store user data and system customization, and make less work when adapting a standard linux distro to a CD environment. stateless addresses the last of the issues directly by adapting the standard distro to not write to the root filesystem. The other two are provided via a preconfigured network server. A LiveCd which includes "try-before-you-buy" and rescue capabilities as goals cannot depend on having a preconfigured server on the network (or even the nhtwork) in order to operate. Additionally, unionfs adds the capability to appear to write to a liveCD's filesystem and therefore adds to the potential uses for the liveCD. stateless attempts to subtract the need to write to the filesystem and therefore make Fedora more suited to be remotely managed. The liveCDs and stateless have different goals which have overlapping areas of interest but don't always coincide. -Toshio -------------- 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 bbbush.yuan at gmail.com Sun Oct 23 08:16:23 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sun, 23 Oct 2005 16:16:23 +0800 Subject: Crash with fontconfig-2.3.91.cvs20051017-1 In-Reply-To: <4358BCD3.3040900@research.att.com> References: <4358BCD3.3040900@research.att.com> Message-ID: <76e72f800510230116m75cd64faw@mail.gmail.com> Hi, same problem here, firefox keeps crashing. There is an extra blank line before all the fonts in gnome-font-properties, and fc-list shows a font without name, while some other fonts are missing. Re-run fc-cache -fv solved this, and cannot re-produce. -- bbbush ^_^ From kevinverma at gmail.com Sun Oct 23 09:17:11 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Sun, 23 Oct 2005 14:47:11 +0530 Subject: Complete graphical boot for Fedora In-Reply-To: <1129805109.3100.13.camel@localhost.localdomain> References: <1129805109.3100.13.camel@localhost.localdomain> Message-ID: Gangaraju, Fedora Core uses, Red Hat Graphical Boot (RHGB) for the startup and shutdown eye candy, however there are couple of alternatives as of today: e.g. Boot Splash http://bootsplash.org , functionality similar to bootsplash is also built into software suspend 2 for linux. I really think Fedora must provide choice. By the way Gangaraju, Fedora can benefit lot from your software engineering contributions, I hope you will come up with a better solution. Cheers, On 10/20/05, Gangaraju wrote: > HI, > > AS WE ARE BOOTING THE SYSTEM WITH FEDORA LINUX-2.6.9 > AFTER SELECTING AT GRUB MENU ,FIRST THE TEXT MESSAGES LIKE > title fedora (2.6.9-fedora) > root (hd0,0) > kernel /boot/vmlinuz-2.6.9-fedora ro root=LABEL=/1 rhgb quiet > initrd /boot/initrd-2.6.9-fedora.img > Uncompressing the kernel > Nash version-...etc > welcome to fedora > Starting udev > Initialising hardware storage network audio > > THEN GRAPHICAL BOOT(X SERVER) STARTS , ALL TEXT MESSAGES ARE HIDDEN > AND ONLY A IMAGE WITH PROGRESS BAR IS SHOWN. > > BUT I WANT TO BUILD MY KERNEL AS WHEN SELECTING AT GRUB MENU IT SHOULD > NOT SHOW ANY KIND OF TEXT MESSAGES,BUT ONLY GRAPHICAL IMAGE WITH > PROGRESS BAR > LIKE WINDOWS OS . > AND THE SAME IDEA I WANT TO IMPEMENT WHILE SHUTDOWN. > I HOPE YOU UNDERSTOOD ME . > PLEASE LET ME KNOW. > -- > Warm Regards, > > Gangaraju.Chowki > Software Engineer, > Host Technologies Ltd, > Banjara Hills,Road No:12, > Hyderabad. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From buildsys at redhat.com Sun Oct 23 11:25:30 2005 From: buildsys at redhat.com (Build System) Date: Sun, 23 Oct 2005 07:25:30 -0400 Subject: rawhide report: 20051023 changes Message-ID: <200510231125.j9NBPUWI023792@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.13-1.1623_FC5 ------------------------ kernel-xen-2.6.12-1.4_FC5 ------------------------- m4-1.4.4-1 ---------- * Sat Oct 22 2005 Miloslav Trmac - 1.4.4-1 - Update to m4-1.4.4 shadow-utils-2:4.0.13-1 ----------------------- * Fri Oct 21 2005 Peter Vrabec 2:4.0.13-1 - upgrade stunnel-4.13-1 -------------- * Sat Oct 22 2005 Miloslav Trmac - 4.13-1 - Update to stunnel-4.13 From jfrieben at freesurf.fr Sun Oct 23 12:30:54 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sun, 23 Oct 2005 14:30:54 +0200 (CEST) Subject: No U-SCSI for AIC7880 and 2.6.13 kernel Message-ID: <8902.194.94.224.254.1130070654.squirrel@arlette.freesurf.fr> After upgrading the SMP kernel on my PR440FX box, the SCSI subsystem switched from U-SCSI to FAST-SCSI mode. There are three devices connected to the on-board AHA-2940UW device. This change happens when booting a 2.6.13 kernel. As soon as I return to a 2.6.12 based kernel, everything works right. The attached hard disk is a QUANTUM Atlas 10k III drive. Now, the transfer rate ia a mere 18 MB/s compared to 28 MB/s which was acceptable for the AIC7880 based UW-interface. From arjanv at redhat.com Sun Oct 23 12:53:20 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 23 Oct 2005 14:53:20 +0200 Subject: No U-SCSI for AIC7880 and 2.6.13 kernel In-Reply-To: <8902.194.94.224.254.1130070654.squirrel@arlette.freesurf.fr> References: <8902.194.94.224.254.1130070654.squirrel@arlette.freesurf.fr> Message-ID: <1130072001.2775.8.camel@laptopd505.fenrus.org> On Sun, 2005-10-23 at 14:30 +0200, Joachim Frieben wrote: > After upgrading the SMP kernel on my PR440FX box, the SCSI > subsystem switched from U-SCSI to FAST-SCSI mode. There are > three devices connected to the on-board AHA-2940UW device. > This change happens when booting a 2.6.13 kernel. As soon as > I return to a 2.6.12 based kernel, everything works right. > The attached hard disk is a QUANTUM Atlas 10k III drive. > Now, the transfer rate ia a mere 18 MB/s compared to 28 MB/s > which was acceptable for the AIC7880 based UW-interface. to diagnose this it's probably easiest to capture the dmesg of both kernels, diff those, and then send that diff to the linux-scsi at vger.kernel.org mailinglist (together with the explenation you already gave in this email) From rahulsundaram at gmail.com Sun Oct 23 13:23:04 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sun, 23 Oct 2005 18:53:04 +0530 Subject: Supporting third party software in /usr/local In-Reply-To: References: Message-ID: Hi > > > Does anybody have any objections to doing this? If not, what is the best > thing for me to do - file a single bug and just CC the maintainers of any > affected packages I can think of? > > thanks -mike > The best way to tackle this is to file independant bug report for each of these bugs against the appropriate component in http://bugzilla.redhat.com. It would probably be useful to post a list of the bugzilla numbers for future reference. regards Rahul -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrieben at freesurf.fr Sun Oct 23 14:24:35 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sun, 23 Oct 2005 16:24:35 +0200 (CEST) Subject: No U-SCSI for AIC7880 and 2.6.13 kernel In-Reply-To: <1130072001.2775.8.camel@laptopd505.fenrus.org> References: <1130072001.2775.8.camel@laptopd505.fenrus.org> Message-ID: <17370.194.94.224.254.1130077475.squirrel@arlette.freesurf.fr> Oops, I forgot to mention that the log message clearly indicates that the transfer mode is -asynchronous- whereas it used to be synchronous for 2.6.x kernels (x < 13) thus cutting down the transfer speed by a factor of 2. It seems to have to do with an alleged "Domain Validation Failure". I would be surprised if I were the only Fedora user experiencing this problem. > > to diagnose this it's probably easiest to capture the dmesg of both > kernels, diff those, and then send that diff to the > linux-scsi at vger.kernel.org mailinglist (together with the explenation > you already gave in this email) > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From db-fedora at 3di.it Mon Oct 24 07:53:22 2005 From: db-fedora at 3di.it (Davide Bolcioni) Date: Mon, 24 Oct 2005 09:53:22 +0200 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems In-Reply-To: <1129958930.19288.22.camel@locolhost.localdomain> References: <1129877978.3410.49.camel@localhost.localdomain> <1129933878.19288.3.camel@locolhost.localdomain> <8A99757938709E19EFFE0D6C@[10.0.0.14]> <1129958930.19288.22.camel@locolhost.localdomain> Message-ID: <435C92F2.1040905@3di.it> Michael A. Peters wrote: > Some upstream tarballs contain a generic spec file that works on most > systems - then you can just do > > rpmbuild -ta foo.tar.gz > > but I've actually found quite a few that have packaging errors > themselves. Then there's issue where DESTDIR support is not always > proper and some patches to the Makefile need to be added, gnome > applications will require you to disable gconf updating during the > install and do it in the post script, etc. Is there some place where such common errors are exposed ? It would help newcomers like myself a lot. > Users should not be expected to learn how to package rpm's unless they > need to learn it for another reason. I do think that developers should > learn rpm so they can provide a *quality* generic spec file, some spec > files I've seen are just scary (and often not generated by autoconf so > the version ends up being wrong if they don't remember to manually > update it for a new release) Another interesting point ... how do you generate a .spec through autoconf ? Any examples or tutorials ? Thank you for your consideration, Davide Bolcioni -- There is no place like /home. From buildsys at redhat.com Mon Oct 24 11:18:50 2005 From: buildsys at redhat.com (Build System) Date: Mon, 24 Oct 2005 07:18:50 -0400 Subject: rawhide report: 20051024 changes Message-ID: <200510241118.j9OBIoAW012743@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.13-1.1624_FC5 ------------------------ * Mon Oct 24 2005 Dave Jones - 2.6.14-rc5-git3 libidn-0.5.20-1 --------------- * Mon Oct 24 2005 Joe Orton 0.5.20-1 - update to 0.5.20 yum-2.4.0-7 ----------- * Sun Oct 23 2005 Paul Nasrat - 2.4.0-7 - Drop anaconda flag patch - Fix ppc64pseries/iseries basearch substitution From avijit at cs.ucsb.edu Mon Oct 24 16:12:59 2005 From: avijit at cs.ucsb.edu (Avijit SenMazumder) Date: Mon, 24 Oct 2005 09:12:59 -0700 (PDT) Subject: IGMP packets at user space Message-ID: I am developing an application for multicast detection on Fedora core. As part of it I have to inspect IGMP packets arriving from routers (e.g. Membership Query). I am using raw socket with IPPROTO_IGMP to send and receive IGMP packets. Using ethereal I can see the IGMP packets going out and coming in to the host. However, incoming IGMP packets never arrive to my user level process - socket 'receivefrom' simply does not get them. I am not sure whether I have to set any socket option or ioctl to receive IGMP packets at user process level. I will appreciate any help. I can post my code if required. Also please let me know if I should post it to some other mailing list. Thanks. Avijit osrkn From mclasen at redhat.com Mon Oct 24 20:48:45 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 24 Oct 2005 16:48:45 -0400 Subject: Crash with fontconfig-2.3.91.cvs20051017-1 In-Reply-To: <76e72f800510230116m75cd64faw@mail.gmail.com> References: <4358BCD3.3040900@research.att.com> <76e72f800510230116m75cd64faw@mail.gmail.com> Message-ID: <1130186925.24782.1.camel@golem.boston.redhat.com> On Sun, 2005-10-23 at 16:16 +0800, Yuan Yijun wrote: > Hi, > > same problem here, firefox keeps crashing. There is an extra blank > line before all the fonts in gnome-font-properties, and fc-list shows > a font without name, while some other fonts are missing. Re-run > fc-cache -fv solved this, and cannot re-produce. > > -- > bbbush ^_^ > In case this occurs again, it would be most helpful to get the offending fonts.cache-2 file for closer analysis of what went wrong. Matthias From hughsient at gmail.com Tue Oct 25 11:08:16 2005 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 25 Oct 2005 12:08:16 +0100 Subject: Loading custom DSDT Message-ID: <1130238496.14696.11.camel@localhost.localdomain> What is the fedora "recommended" way of installing a new ACPI DSDT? Can we make the process of loading a new asl file easier for users in FC5? There are lots of broken BIOS's out there that require custom dsdt's, as I've found when debugging power management stuff. Thanks for any help, as I'm not sure what to advise people running Fedora. Richard. From arjanv at redhat.com Tue Oct 25 11:17:19 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 25 Oct 2005 13:17:19 +0200 Subject: Loading custom DSDT In-Reply-To: <1130238496.14696.11.camel@localhost.localdomain> References: <1130238496.14696.11.camel@localhost.localdomain> Message-ID: <1130239039.3125.7.camel@laptopd505.fenrus.org> On Tue, 2005-10-25 at 12:08 +0100, Richard Hughes wrote: > What is the fedora "recommended" way of installing a new ACPI DSDT? Can > we make the process of loading a new asl file easier for users in FC5? > > There are lots of broken BIOS's out there that require custom dsdt's, as > I've found when debugging power management stuff. technically that's a flaw in the linux acpi code; if it doesn't accept acpi tables that windows accept then that's a bug. From alan at redhat.com Tue Oct 25 11:27:19 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 25 Oct 2005 07:27:19 -0400 Subject: Loading custom DSDT In-Reply-To: <1130239039.3125.7.camel@laptopd505.fenrus.org> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> Message-ID: <20051025112719.GA8551@devserv.devel.redhat.com> On Tue, Oct 25, 2005 at 01:17:19PM +0200, Arjan van de Ven wrote: > technically that's a flaw in the linux acpi code; if it doesn't accept > acpi tables that windows accept then that's a bug. Not true at all. ACPI tables are written to a standard. In addition they contain OS specific conditional code which means what occurs depends on the system. We fake being one kind of windows to deal with some bugs but many platforms don't work with all forms of windows so its pot luck if you got the right one and some vendors ship dsdt updates with their installs for windows. From hughsient at gmail.com Tue Oct 25 11:32:13 2005 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 25 Oct 2005 12:32:13 +0100 Subject: Loading custom DSDT In-Reply-To: <1130239039.3125.7.camel@laptopd505.fenrus.org> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> Message-ID: <1130239933.14696.22.camel@localhost.localdomain> On Tue, 2005-10-25 at 13:17 +0200, Arjan van de Ven wrote: > On Tue, 2005-10-25 at 12:08 +0100, Richard Hughes wrote: > > What is the fedora "recommended" way of installing a new ACPI DSDT? Can > > we make the process of loading a new asl file easier for users in FC5? > > > > There are lots of broken BIOS's out there that require custom dsdt's, as > > I've found when debugging power management stuff. > > technically that's a flaw in the linux acpi code; if it doesn't accept > acpi tables that windows accept then that's a bug. But some of the ACPI tables out there are *so* broken... The best way to do this surely is to grab the fixed dsdt from http://acpi.sourceforge.net/ dump that in /boot, and reboot (I think this is the way Ubuntu deals with dsdt updates, i.e. build it into the initrd automatically) and not have to worry about rebuilding a custom kernel. I think it's impossible to cope with every broken dsdt table in the kernel acpi code (looking at some, it's a wonder windows works...) -- but I'm no acpi kernel hacker. So what do I tell my helpless user? 1. Start hacking kernel acpi internals, sending patches to lkml that have kludges for specific laptop models. 2. Rebuild their kernel with the updated dsdt. 3. Email your laptop vendor to release a new bios for a 5 year old laptop. I'm pretty certain this will be ignored as it "works in windows". 1,2, and 3 are pretty daunting for a new user. There *must* be a better way. Richard. From buildsys at redhat.com Tue Oct 25 11:36:19 2005 From: buildsys at redhat.com (Build System) Date: Tue, 25 Oct 2005 07:36:19 -0400 Subject: rawhide report: 20051025 changes Message-ID: <200510251136.j9PBaJAO001084@porkchop.devel.redhat.com> Updated Packages: (none) Broken deps for s390 ---------------------------------------------------------- kdesdk - 3.4.91-1.s390 requires libkunittest.so.0 Broken deps for i386 ---------------------------------------------------------- kdesdk - 3.4.91-1.i386 requires libkunittest.so.0 Broken deps for ia64 ---------------------------------------------------------- kdesdk - 3.4.91-1.ia64 requires libkunittest.so.0()(64bit) Broken deps for ppc64 ---------------------------------------------------------- kdesdk - 3.4.91-1.ppc64 requires libkunittest.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- kdesdk - 3.4.91-1.x86_64 requires libkunittest.so.0()(64bit) Broken deps for ppc ---------------------------------------------------------- kdesdk - 3.4.91-1.ppc requires libkunittest.so.0 Broken deps for s390x ---------------------------------------------------------- kdesdk - 3.4.91-1.s390x requires libkunittest.so.0()(64bit) From fedora at leemhuis.info Tue Oct 25 12:07:53 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 25 Oct 2005 14:07:53 +0200 Subject: Loading custom DSDT In-Reply-To: <1130238496.14696.11.camel@localhost.localdomain> References: <1130238496.14696.11.camel@localhost.localdomain> Message-ID: <1130242073.5709.47.camel@thl.ct.heise.de> Am Dienstag, den 25.10.2005, 12:08 +0100 schrieb Richard Hughes: > What is the fedora "recommended" way of installing a new ACPI DSDT? Can > we make the process of loading a new asl file easier for users in FC5? See this thread for some more information: https://www.redhat.com/archives/fedora-test-list/2005-September/msg00287.html And especially: https://www.redhat.com/archives/fedora-test-list/2005-September/msg00292.html https://www.redhat.com/archives/fedora-test-list/2005-September/msg00291.html https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169014 CU thl From hughsient at gmail.com Tue Oct 25 13:20:59 2005 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 25 Oct 2005 14:20:59 +0100 Subject: Loading custom DSDT In-Reply-To: <1130242073.5709.47.camel@thl.ct.heise.de> References: <1130238496.14696.11.camel@localhost.localdomain> <1130242073.5709.47.camel@thl.ct.heise.de> Message-ID: <1130246459.15304.22.camel@localhost.localdomain> On Tue, 2005-10-25 at 14:07 +0200, Thorsten Leemhuis wrote: > Am Dienstag, den 25.10.2005, 12:08 +0100 schrieb Richard Hughes: > > What is the fedora "recommended" way of installing a new ACPI DSDT? Can > > we make the process of loading a new asl file easier for users in FC5? > > See this thread for some more information: > > https://www.redhat.com/archives/fedora-test-list/2005-September/msg00287.html > > And especially: > https://www.redhat.com/archives/fedora-test-list/2005-September/msg00292.html > https://www.redhat.com/archives/fedora-test-list/2005-September/msg00291.html > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169014 Thanks for the links. If Mandriva, SuSE and Ubuntu use this patch by default, then Fedora is the only other big current distro (that I would consider enterprise ready) to *not* support loading a custom dsdt. To quote from Len Brown: > That said, it is useful for developers to be able to override the DSDT. > There are two methods -- re-build kernel or re-build kernel and also > modify the initrd. > > Kernel re-build is (I think) simple enought. I think the patch at hand > takes it from simple to trivial. You try telling a new user to recompile their kernel, from a src.rpm, with an extra patch, into a new rpm, which they then have to install, and you'll understand why I'm worried... Everytime a new kernel update comes along, we have to go kernel-a-building yet again. Which is fine if you are a kernel hacker, or an ACPI maintainer, but for joe average, who just wants this "linux thing" to "just work" -- it's not good enough. And to quote Dave Jones: >If users start manipulating their DSDTs, and getting panics etc, they file bugs >here, and would 'neglect' to say how they hacked their dsdt's >It's a support nightmare waiting to happen. If a user has to install a dsdt, it's to get ACPI working closer to the ACPI standard. The kernel should work properly with a standard dsdt layout, as opposed to a non-standard (and broken) dstd layout. Has a user ever filed a bug with component kernel that failed to mention he/she was using a custom, and broken dstd? No-one's asking for vendor support for automatic override of a dsdt in the initrd -- the user has to manually download the asl file and install it even in Ubuntu. Adding the patch to the fedora system allows the user to choose, as at the moment, they have no choice. We could add a BIG FAT WARNING on boot if we are using a custom dsdt, and hence make the override very obvious. At the moment, should I tell my new-user to either switch to ubuntu, suse or mandriva to use the corrected dsdt? Don't get me wrong, I love Fedora, but I think sometimes we forget that users != developers. Richard. From linville at redhat.com Tue Oct 25 14:43:10 2005 From: linville at redhat.com (John W. Linville) Date: Tue, 25 Oct 2005 10:43:10 -0400 Subject: Loading custom DSDT In-Reply-To: <1130239933.14696.22.camel@localhost.localdomain> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> <1130239933.14696.22.camel@localhost.localdomain> Message-ID: <20051025144310.GA30015@redhat.com> On Tue, Oct 25, 2005 at 12:32:13PM +0100, Richard Hughes wrote: > So what do I tell my helpless user? > > 1. Start hacking kernel acpi internals, sending patches to lkml that > have kludges for specific laptop models. > 2. Rebuild their kernel with the updated dsdt. > 3. Email your laptop vendor to release a new bios for a 5 year old > laptop. I'm pretty certain this will be ignored as it "works in > windows". > > 1,2, and 3 are pretty daunting for a new user. I've been carrying a "DSDT in initrd" patch in my FC4 test kernels for a while now. I've had many reports of people using it successfully. I put-up a little page for it here: http://people.redhat.com/linville/kernels/dsdt/ I would like to see a patch like this upstream. I'm not sure how to convince Len Brown to let it in. I don't think putting it in Fedora is necessarily a bad idea, but it is not a slam dunk either (based on support concerns as pointed-out elsewhere). I'll continue to carry it in my test kernels if people are interested. I don't currently have it in my FC5 kernels, but I can put it there as well. John -- John W. Linville linville at redhat.com From alan at redhat.com Tue Oct 25 14:51:19 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 25 Oct 2005 10:51:19 -0400 Subject: Loading custom DSDT In-Reply-To: <1130239933.14696.22.camel@localhost.localdomain> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> <1130239933.14696.22.camel@localhost.localdomain> Message-ID: <20051025145119.GA8848@devserv.devel.redhat.com> On Tue, Oct 25, 2005 at 12:32:13PM +0100, Richard Hughes wrote: > But some of the ACPI tables out there are *so* broken... The best way to > do this surely is to grab the fixed dsdt from > http://acpi.sourceforge.net/ dump that in /boot, and reboot (I think > this is the way Ubuntu deals with dsdt updates, i.e. build it into the > initrd automatically) and not have to worry about rebuilding a custom > kernel. There are several problems with that 1. ACPI tables are software and provided by the vendor with licenses that forbid modification, redistribution etc. 2. For that matter if you live in the USSA then they probably disallow disassembly 3. Its not something the average user can do > So what do I tell my helpless user? > 1. Start hacking kernel acpi internals, sending patches to lkml that > have kludges for specific laptop models. > 2. Rebuild their kernel with the updated dsdt. > 3. Email your laptop vendor to release a new bios for a 5 year old > laptop. I'm pretty certain this will be ignored as it "works in > windows". If the DSDT bug is known then it becomes practical to look at the problem and make the Linux code bug compatible with Windows - and a fair bit of that has occurred, or to blacklist the ACPI support using the dmi table. That much becomes workable for users because it then just works out of the box. The other approach in the US is probably the "you said it supports ACPI but it's invalid class action lawsuit" approach. But I doubt that really fixes anything but the lawyers swimming pool. Alan From davej at redhat.com Tue Oct 25 18:30:13 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 25 Oct 2005 14:30:13 -0400 Subject: Loading custom DSDT In-Reply-To: <20051025144310.GA30015@redhat.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> <1130239933.14696.22.camel@localhost.localdomain> <20051025144310.GA30015@redhat.com> Message-ID: <20051025183013.GD18996@redhat.com> On Tue, Oct 25, 2005 at 10:43:10AM -0400, John W. Linville wrote: > I would like to see a patch like this upstream. I'm not sure how to > convince Len Brown to let it in. > > I don't think putting it in Fedora is necessarily a bad idea, but it > is not a slam dunk either (based on support concerns as pointed-out > elsewhere). The Intel folks have refused to merge it upstream as they'd rather fix the interpretor to work around broken tables. Some other vendors are also very helpful in the "Whack BIOS vendor on the head" dept when bad tables get reported to them. If Fedora carried such a patch, we could forget all about ever looking at fixing ACPI bugs that get reported, as I can guarantee we'd get reports that conveniently 'forgot' to mention they've hacked their DSDT in wierd and wonderful ways. The ability to screw up AML is hurrendously easy, and the number of wannabe AML hackers frankly, scares me witless. A lot of folk seem to think that things are as simple as .. - disassemble DSDT - fix up warnings from AML compiler - put DSDT into initrd. This is *wrong* on so many levels. For one, even if it does fix the problems the user was seeing, how does it help the next user that hits the problem on the same hardware ? We can't expect every user to have to patch their DSDT. The correct answer is "Fix the BIOS", or where that isn't feasible "Work around it in the interpretor" (Especially if its a widespread problem). Dave From davej at redhat.com Tue Oct 25 18:39:53 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 25 Oct 2005 14:39:53 -0400 Subject: Loading custom DSDT In-Reply-To: <1130246459.15304.22.camel@localhost.localdomain> References: <1130238496.14696.11.camel@localhost.localdomain> <1130242073.5709.47.camel@thl.ct.heise.de> <1130246459.15304.22.camel@localhost.localdomain> Message-ID: <20051025183953.GE18996@redhat.com> On Tue, Oct 25, 2005 at 02:20:59PM +0100, Richard Hughes wrote: > On Tue, 2005-10-25 at 14:07 +0200, Thorsten Leemhuis wrote: > > Am Dienstag, den 25.10.2005, 12:08 +0100 schrieb Richard Hughes: > > > What is the fedora "recommended" way of installing a new ACPI DSDT? Can > > > we make the process of loading a new asl file easier for users in FC5? > > > > See this thread for some more information: > > > > https://www.redhat.com/archives/fedora-test-list/2005-September/msg00287.html > > > > And especially: > > https://www.redhat.com/archives/fedora-test-list/2005-September/msg00292.html > > https://www.redhat.com/archives/fedora-test-list/2005-September/msg00291.html > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169014 > > Thanks for the links. > > If Mandriva, SuSE and Ubuntu use this patch by default, then Fedora is > the only other big current distro (that I would consider enterprise > ready) to *not* support loading a custom dsdt. Mandriva, SuSE and Ubuntu also carry lots of other patches we don't have in Fedora, so the analogy is pointless. One of the goals of Fedora is to stay as close as possible to upstream. The number of "Feature" patches in the current kernels are very low compared to the number of patches fixing problems. Adding this buys *nothing* to most end-users, but empowers a select few to fiddle with their DSDTs. Frankly, if you know what you're doing enough to rewrite a DSDT, you should know how to build a kernel. End-users shouldn't need to know what a DSDT, or an initrd is. I don't want to see a single bug report in the Fedora bugzilla with the words "I recompiled my DSDT because..". If I do, it'll instantly get closed CANTFIX, as it's completely unsupportable. We're already severely outnumbered by the number of bugs coming in for ACPI, and adding this just adds yet another possibility for disaster. > You try telling a new user to recompile their kernel, from a src.rpm, with an > extra patch, into a new rpm, which they then have to install, and you'll > understand why I'm worried... Everytime a new kernel update comes along, > we have to go kernel-a-building yet again. And telling a new user to recompile their DSDT is ok ? Please. (and the idea that people can download random DSDTs from websites just fills me with joy -- people _will_ 'try' ones that aren't for their machine "because the model numbers were similar") > Which is fine if you are a kernel hacker, or an ACPI maintainer, but for > joe average, who just wants this "linux thing" to "just work" -- it's not > good enough. End-users shouldn't need to know what a DSDT, or an initrd is. > At the moment, should I tell my new-user to either switch to ubuntu, > suse or mandriva to use the corrected dsdt? Don't get me wrong, I love > Fedora, but I think sometimes we forget that users != developers. End-users shouldn't need to know what a DSDT, or an initrd is. Dave From manolo at miconexion.com Tue Oct 25 18:54:29 2005 From: manolo at miconexion.com (Manuel Moreno) Date: Tue, 25 Oct 2005 19:54:29 +0100 Subject: Loading custom DSDT In-Reply-To: <20051025183013.GD18996@redhat.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> <1130239933.14696.22.camel@localhost.localdomain> <20051025144310.GA30015@redhat.com> <20051025183013.GD18996@redhat.com> Message-ID: <435E7F65.8070907@miconexion.com> Dave Jones wrote: > On Tue, Oct 25, 2005 at 10:43:10AM -0400, John W. Linville wrote: > > > I would like to see a patch like this upstream. I'm not sure how to > > convince Len Brown to let it in. > > > > I don't think putting it in Fedora is necessarily a bad idea, but it > > is not a slam dunk either (based on support concerns as pointed-out > > elsewhere). > > The Intel folks have refused to merge it upstream as they'd rather > fix the interpretor to work around broken tables. Some other vendors > are also very helpful in the "Whack BIOS vendor on the head" dept > when bad tables get reported to them. > > If Fedora carried such a patch, we could forget all about ever > looking at fixing ACPI bugs that get reported, as I can guarantee > we'd get reports that conveniently 'forgot' to mention they've hacked > their DSDT in wierd and wonderful ways. > > The ability to screw up AML is hurrendously easy, and the number of > wannabe AML hackers frankly, scares me witless. A lot of folk seem > to think that things are as simple as .. > > - disassemble DSDT > - fix up warnings from AML compiler > - put DSDT into initrd. > > This is *wrong* on so many levels. For one, even if it does fix > the problems the user was seeing, how does it help the next user > that hits the problem on the same hardware ? We can't expect > every user to have to patch their DSDT. The correct answer > is "Fix the BIOS", or where that isn't feasible "Work around > it in the interpretor" (Especially if its a widespread problem). > > Dave > I _strongly_ disagree with that and so seems to be the opinion of Ubuntu, Mandriva and Novel/SuSe developpers/users and I'm pretty sure that they have fair good thinking heads too. Are we facing perhaps the NIH RedHat syndrome or is it a desperate and stubborn USA-centric point of view from RH far too afraid from USA barrister greed. -- Manuel Moreno manolo at miconexion.com From skvidal at phy.duke.edu Tue Oct 25 19:03:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Oct 2005 15:03:19 -0400 Subject: Loading custom DSDT In-Reply-To: <435E7F65.8070907@miconexion.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> <1130239933.14696.22.camel@localhost.localdomain> <20051025144310.GA30015@redhat.com> <20051025183013.GD18996@redhat.com> <435E7F65.8070907@miconexion.com> Message-ID: <1130267000.18955.127.camel@cutter> On Tue, 2005-10-25 at 19:54 +0100, Manuel Moreno wrote: > Dave Jones wrote: > > On Tue, Oct 25, 2005 at 10:43:10AM -0400, John W. Linville wrote: > > > > > I would like to see a patch like this upstream. I'm not sure how to > > > convince Len Brown to let it in. > > > > > > I don't think putting it in Fedora is necessarily a bad idea, but it > > > is not a slam dunk either (based on support concerns as pointed-out > > > elsewhere). > > > > The Intel folks have refused to merge it upstream as they'd rather > > fix the interpretor to work around broken tables. Some other vendors > > are also very helpful in the "Whack BIOS vendor on the head" dept > > when bad tables get reported to them. > > > > If Fedora carried such a patch, we could forget all about ever > > looking at fixing ACPI bugs that get reported, as I can guarantee > > we'd get reports that conveniently 'forgot' to mention they've hacked > > their DSDT in wierd and wonderful ways. > > > > The ability to screw up AML is hurrendously easy, and the number of > > wannabe AML hackers frankly, scares me witless. A lot of folk seem > > to think that things are as simple as .. > > > > - disassemble DSDT > > - fix up warnings from AML compiler > > - put DSDT into initrd. > > > > This is *wrong* on so many levels. For one, even if it does fix > > the problems the user was seeing, how does it help the next user > > that hits the problem on the same hardware ? We can't expect > > every user to have to patch their DSDT. The correct answer > > is "Fix the BIOS", or where that isn't feasible "Work around > > it in the interpretor" (Especially if its a widespread problem). > > > > Dave > > > > I _strongly_ disagree with that and so seems to be the opinion of > Ubuntu, Mandriva and Novel/SuSe developpers/users and I'm pretty sure > that they have fair good thinking heads too. Are we facing perhaps the > NIH RedHat syndrome or is it a desperate and stubborn USA-centric point > of view from RH far too afraid from USA barrister greed. Well, Dave used to work at suse, iirc, and he's from the UK, not the US, so, I'm betting not. As has been, repeatedly, the case, fedora kernels try to stay as close to kernel.org kernels as is possible/reasonable. -sv From pbrobinson at gmail.com Tue Oct 25 19:09:55 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 25 Oct 2005 20:09:55 +0100 Subject: Loading custom DSDT In-Reply-To: <435E7F65.8070907@miconexion.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> <1130239933.14696.22.camel@localhost.localdomain> <20051025144310.GA30015@redhat.com> <20051025183013.GD18996@redhat.com> <435E7F65.8070907@miconexion.com> Message-ID: <5256d0b0510251209w7b5ce9b9pd2d7d20db72f7007@mail.gmail.com> > I _strongly_ disagree with that and so seems to be the opinion of > Ubuntu, Mandriva and Novel/SuSe developpers/users and I'm pretty sure > that they have fair good thinking heads too. Are we facing perhaps the > NIH RedHat syndrome or is it a desperate and stubborn USA-centric point > of view from RH far too afraid from USA barrister greed. I agree with Dave and Alan. I don't think this will change in Fedora, RH views or otherwise, but then its free software so there's nothing to stop you from running one of the distros that have the same opinion as yours. That's the great joy of open source! Pete From linville at redhat.com Tue Oct 25 19:11:48 2005 From: linville at redhat.com (John W. Linville) Date: Tue, 25 Oct 2005 15:11:48 -0400 Subject: Loading custom DSDT In-Reply-To: <435E7F65.8070907@miconexion.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> <1130239933.14696.22.camel@localhost.localdomain> <20051025144310.GA30015@redhat.com> <20051025183013.GD18996@redhat.com> <435E7F65.8070907@miconexion.com> Message-ID: <20051025191148.GJ30015@redhat.com> On Tue, Oct 25, 2005 at 07:54:29PM +0100, Manuel Moreno wrote: > NIH RedHat syndrome or is it a desperate and stubborn USA-centric point > of view from RH far too afraid from USA barrister greed. /me chuckles at the thought of Dave J. dressed as Uncle Sam... :-) -- John W. Linville linville at redhat.com From manolo at miconexion.com Tue Oct 25 19:09:53 2005 From: manolo at miconexion.com (Manuel Moreno) Date: Tue, 25 Oct 2005 20:09:53 +0100 Subject: Loading custom DSDT In-Reply-To: <20051025183953.GE18996@redhat.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130242073.5709.47.camel@thl.ct.heise.de> <1130246459.15304.22.camel@localhost.localdomain> <20051025183953.GE18996@redhat.com> Message-ID: <435E8301.2090408@miconexion.com> Dave Jones wrote: > Mandriva, SuSE and Ubuntu also carry lots of other patches we don't I do not know right now about Mandriva and SuSe but I'm well sure that Ubuntu kernel carry far less patches than RH. > have in Fedora, so the analogy is pointless. So your comparison is unsound, untrue and misleading. :-) > > End-users shouldn't need to know what a DSDT, or an initrd is. Why? > > End-users shouldn't need to know what a DSDT, or an initrd is. Because you say so? > > End-users shouldn't need to know what a DSDT, or an initrd is. > Because it is Thy First Commandment? :-) > Dave > Considering the increasing number of laptops/notebooks out there your stand is unsustainable and looks like technofundamentalism. Do you really want Fedora to wane into the shadows of marginal/niche distributions... :-) -- Manuel Moreno manolo at miconexion.com From nicolas.mailhot at laposte.net Tue Oct 25 19:15:11 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 25 Oct 2005 21:15:11 +0200 Subject: Loading custom DSDT In-Reply-To: <435E7F65.8070907@miconexion.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> <1130239933.14696.22.camel@localhost.localdomain> <20051025144310.GA30015@redhat.com> <20051025183013.GD18996@redhat.com> <435E7F65.8070907@miconexion.com> Message-ID: <1130267712.8253.9.camel@rousalka.dyndns.org> Le mardi 25 octobre 2005 ? 19:54 +0100, Manuel Moreno a ?crit : > I _strongly_ disagree with that and so seems to be the opinion of > Ubuntu, Mandriva and Novel/SuSe developpers/users and I'm pretty sure > that they have fair good thinking heads too. Are we facing perhaps the > NIH RedHat syndrome or is it a desperate and stubborn USA-centric point > of view from RH far too afraid from USA barrister greed. This is not Red Hat decision, this is *Intel's* decision (the team that maintains ACPI code for *ALL* linux distributions) Ubuntu, Mandriva and Novel/SuSe are playing a very dangerous game. If enough distributions follow suit Intel may just decide to let the Linux community maintain its own ACPI subsystem and I somehow doubt anyone actually wants to do that. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From david at lovesunix.net Tue Oct 25 19:34:43 2005 From: david at lovesunix.net (David Nielsen) Date: Tue, 25 Oct 2005 21:34:43 +0200 Subject: Loading custom DSDT In-Reply-To: <20051025191148.GJ30015@redhat.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> <1130239933.14696.22.camel@localhost.localdomain> <20051025144310.GA30015@redhat.com> <20051025183013.GD18996@redhat.com> <435E7F65.8070907@miconexion.com> <20051025191148.GJ30015@redhat.com> Message-ID: <1130268883.7929.6.camel@localhost.localdomain> tir, 25 10 2005 kl. 15:11 -0400, skrev John W. Linville: > On Tue, Oct 25, 2005 at 07:54:29PM +0100, Manuel Moreno wrote: > > > NIH RedHat syndrome or is it a desperate and stubborn USA-centric point > > of view from RH far too afraid from USA barrister greed. > > /me chuckles at the thought of Dave J. dressed as Uncle Sam... :-) Personally I have more fun imagining the "Uncle Alan wants you!" poster. Maybe it's true that kernel hackers get the babes (and the minions). I'm with Alan and Dave btw. I personally as a user don't even know what a DSDT table is intended to do for me aside just work out of the box. Which can hardly be said if I have to recompile and hunt down a custom DSDT table from a some obscure website - why would I want to insert something not signed off by Fedora in my kernel again, regardless of how harmless it might sound. I trust Dave more than random bloke/random vendor on the big scary Internet. - David Nielsen From hughsient at gmail.com Tue Oct 25 19:41:55 2005 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 25 Oct 2005 20:41:55 +0100 Subject: Loading custom DSDT In-Reply-To: <20051025183953.GE18996@redhat.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130242073.5709.47.camel@thl.ct.heise.de> <1130246459.15304.22.camel@localhost.localdomain> <20051025183953.GE18996@redhat.com> Message-ID: <1130269315.16802.8.camel@localhost.localdomain> On Tue, 2005-10-25 at 14:39 -0400, Dave Jones wrote: > End-users shouldn't need to know what a DSDT, or an initrd is. In an ideal world, where ACPI support is flawlessly added to all new notebooks, and tested, I would agree. ACPI in real life, however, is less perfect. I'm sure you could use the same argument for the root terminal; the average user shouldn't have to open up a terminal and su to root to do any system configuration action. I do not know *one* Linux user who has not used a root command shell to do admin tasks. Maybe a bad example, but you get my idea. Richard. p.s. This wasn't intended to get into a long thread about fedora kernel development, Dave Jones, Arjan and Alan Cox do a fantastic job in, my opinion, the hardest area of development. Back to my original question: Is there a simple way to recompile the src kernel with the updated dsdt applied? From davej at redhat.com Tue Oct 25 19:48:26 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 25 Oct 2005 15:48:26 -0400 Subject: Loading custom DSDT In-Reply-To: <435E8301.2090408@miconexion.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130242073.5709.47.camel@thl.ct.heise.de> <1130246459.15304.22.camel@localhost.localdomain> <20051025183953.GE18996@redhat.com> <435E8301.2090408@miconexion.com> Message-ID: <20051025194826.GF18996@redhat.com> On Tue, Oct 25, 2005 at 08:09:53PM +0100, Manuel Moreno wrote: > Dave Jones wrote: > >Mandriva, SuSE and Ubuntu also carry lots of other patches we don't > > I do not know right now about Mandriva and SuSe but I'm well sure that > Ubuntu kernel carry far less patches than RH. > > >have in Fedora, so the analogy is pointless. > So your comparison is unsound, untrue and misleading. :-) What comparison ? > >End-users shouldn't need to know what a DSDT, or an initrd is. > Why? Why should they ? A user just wants their computer to work, they don't necessarily care what an "acpi" or a "dsdt" is. > >End-users shouldn't need to know what a DSDT, or an initrd is. > Because you say so? speaking as one of the people that have to make sense of bug reports coming in, yes. Part of my job is to make decisions based upon on how supportable something is. It's exactly the same process that kept inotify from being merged until it got upstream. It's the same reason we don't have reiser4. It's the same reason we don't have countless other things people ask for, that no doubt, *someone* would really like to see in the Fedora kernel. But until these things get upstream, my job is to say no, or go insane trying to deal with the resulting fallout. > Considering the increasing number of laptops/notebooks out there your > stand is unsustainable and looks like technofundamentalism. Do you > really want Fedora to wane into the shadows of marginal/niche > distributions... :-) This stuff should "just work". I agree users shouldn't have to build their own kernels. But that also includes "users shouldn't have to mess around with the initrd". Take a look through bugzilla if you want to see the million ways users *have already* screwed up their initrd's because they thought they knew what they were doing. By saying "you *have* to do this to make it work", we're taking a giant step backwards. Dave From hughsient at gmail.com Tue Oct 25 19:58:04 2005 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 25 Oct 2005 20:58:04 +0100 Subject: Loading custom DSDT In-Reply-To: <20051025194826.GF18996@redhat.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130242073.5709.47.camel@thl.ct.heise.de> <1130246459.15304.22.camel@localhost.localdomain> <20051025183953.GE18996@redhat.com> <435E8301.2090408@miconexion.com> <20051025194826.GF18996@redhat.com> Message-ID: <1130270285.16802.13.camel@localhost.localdomain> On Tue, 2005-10-25 at 15:48 -0400, Dave Jones wrote: > Why should they ? A user just wants their computer to work, they > don't necessarily care what an "acpi" or a "dsdt" is. Yes, but their systems admin (who does know what he is doing) needs a way to "fix" the problem, which in Fedora, he can't do. [1] Richard. [1] Short of compiling a custom kernel everytime a new errata is released, and making sure the right kernel goes onto the right machine... From manolo at miconexion.com Tue Oct 25 20:33:20 2005 From: manolo at miconexion.com (Manuel Moreno) Date: Tue, 25 Oct 2005 21:33:20 +0100 Subject: Loading custom DSDT In-Reply-To: <20051025194826.GF18996@redhat.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130242073.5709.47.camel@thl.ct.heise.de> <1130246459.15304.22.camel@localhost.localdomain> <20051025183953.GE18996@redhat.com> <435E8301.2090408@miconexion.com> <20051025194826.GF18996@redhat.com> Message-ID: <435E9690.6050702@miconexion.com> Dave Jones wrote: > On Tue, Oct 25, 2005 at 08:09:53PM +0100, Manuel Moreno wrote: > > Dave Jones wrote: > > >Mandriva, SuSE and Ubuntu also carry lots of other patches we don't > > > > I do not know right now about Mandriva and SuSe but I'm well sure that > > Ubuntu kernel carry far less patches than RH. > > > > >have in Fedora, so the analogy is pointless. > > So your comparison is unsound, untrue and misleading. :-) > > What comparison ? The one of you saying that ubuntu kernel has more patches than fedora's Fedora ----------- $ cd /usr/src/redhat/SOURCES/ $ rpm -Uvh ../SRPMS/kernel-2.6.13-1.1529_FC4.src.rpm $ ls -l *.patch | wc -l $ 101 Ubuntu ------- linux-patch-debian-2.6.8.1_2.6.8.1-16_all.deb 16 patches linux-patch-debian-2.6.8.1_2.6.8.1-16.24_all.deb 24 patches 16 + 24 = 40 patches (BTW, I know that this measure is _NOT_ accurate!) ... I can say that almost all Sonoma (Alviso) based notebook/laptops out there have broken ACPI tables. The brokenness range from not detecting batteries, not seeing interrupt lines (nonworking sound/wireless/etc. devices) to even not activating fan or other cooling devices efectively "frying" the shiny brand new laptop we got for our last bithday! Are we really going to tell all those users that they can not run Fedora on their laptops? http://acpi.sourceforge.net is not an obscure crackish web site and the dsdt disassembled code to fix is "_source code_" so I am not putting some "unknown" binary into my kernel. IASL compiler/decompiler is officially maintained/blessed by Intel. Anyway IMHO is by far more simple for the average user to fix a few lines of code in an ACPI dsdt disassembled code once and for ever than to take the burden of recompiling from a modified src.rpm everytime a new kernel shows up its ugly nose; and by far quicker than waiting for a corrected firmware from the manufacturer. We (in EU) are entitled to reverse engineering software associated with hardware devices to fix or correct malfunctions and that is what the DSDT replacements go for. The alternative is to make users to flee away from linux as the cat from cold water :-) -- Manuel Moreno manolo at miconexion.com From rodd at clarkson.id.au Tue Oct 25 20:47:01 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 26 Oct 2005 06:47:01 +1000 Subject: rawhide report: 20051025 changes In-Reply-To: <200510251136.j9PBaJAO001084@porkchop.devel.redhat.com> References: <200510251136.j9PBaJAO001084@porkchop.devel.redhat.com> Message-ID: <1130273221.2799.2.camel@localhost.localdomain> On Tue, 2005-10-25 at 07:36 -0400, Build System wrote: > > > Updated Packages: > > (none) Hmmm, Build System is being a little 'mum' on the updates. Especially since the following packages were offered up for update using yum today: Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: kernel i686 2.6.13-1.1626_FC5 development 15 M kernel-devel i686 2.6.13-1.1626_FC5 development 4.1 M Updating: arts i386 8:1.4.92-1 development 1.1 M audit i386 1.0.8-1 development 166 k audit-libs i386 1.0.8-1 development 34 k audit-libs-devel i386 1.0.8-1 development 51 k control-center i386 1:2.12.1-3 development 2.3 M evolution i386 2.4.1-5 development 11 M glibc-kernheaders i386 3.0-2 development 707 k gnome-doc-utils noarch 0.4.3-1 development 139 k gnome-netstatus i386 2.12.0-2 development 255 k gnome-screensaver i386 0.0.17-1 development 1.4 M gnome-themes noarch 2.12.1-4 development 2.5 M gtk2 i386 2.8.6-3 development 5.1 M gtk2-devel i386 2.8.6-3 development 2.6 M hsqldb i386 1.80.1-1jpp_3fc development 1.5 M htmlview noarch 3.0.0-12 development 7.4 k libgnome i386 2.12.0.1-2 development 749 k libgnome-devel i386 2.12.0.1-2 development 104 k libsemanage i386 1.3.32-1 development 45 k libsepol i386 1.9.26-1 development 118 k mutt i386 5:1.4.2.1-4 development 1.1 M nfs-utils i386 1.0.7-19.FC5 development 326 k pkgconfig i386 1:0.20-1 development 56 k policycoreutils i386 1.27.18-1 development 143 k pygtk2 i386 2.8.2-1 development 964 k pygtk2-devel i386 2.8.2-1 development 236 k pygtk2-libglade i386 2.8.2-1 development 15 k qt i386 1:3.3.5-6 development 3.4 M qt-devel i386 1:3.3.5-6 development 14 M rhythmbox i386 0.9.1-1 development 2.0 M selinux-policy-targeted noarch 1.27.2-2 development 172 k slang i386 1.4.9-23 development 191 k slang-devel i386 1.4.9-23 development 549 k system-config-language noarch 1.1.10-1 development 63 k system-config-rootpassword noarch 1.1.8-1 development 51 k totem i386 1.1.5-1 development 1.2 M yum noarch 2.4.0-8 development 450 k Transaction Summary ============================================================================= Install 2 Package(s) Update 36 Package(s) Remove 0 Package(s) Total download size: 73 M And this doesn't even include the mysterious KDE dep below. Rodd > Broken deps for s390 > ---------------------------------------------------------- > kdesdk - 3.4.91-1.s390 requires libkunittest.so.0 > > > > Broken deps for i386 > ---------------------------------------------------------- > kdesdk - 3.4.91-1.i386 requires libkunittest.so.0 > > > > Broken deps for ia64 > ---------------------------------------------------------- > kdesdk - 3.4.91-1.ia64 requires libkunittest.so.0()(64bit) > > > > Broken deps for ppc64 > ---------------------------------------------------------- > kdesdk - 3.4.91-1.ppc64 requires libkunittest.so.0()(64bit) > > > > Broken deps for x86_64 > ---------------------------------------------------------- > kdesdk - 3.4.91-1.x86_64 requires libkunittest.so.0()(64bit) > > > > Broken deps for ppc > ---------------------------------------------------------- > kdesdk - 3.4.91-1.ppc requires libkunittest.so.0 > > > > Broken deps for s390x > ---------------------------------------------------------- > kdesdk - 3.4.91-1.s390x requires libkunittest.so.0()(64bit) > > > -- "It's a fine line between denial and faith. It's much better on my side" From cra at WPI.EDU Tue Oct 25 21:03:04 2005 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 25 Oct 2005 17:03:04 -0400 Subject: Loading custom DSDT In-Reply-To: <435E9690.6050702@miconexion.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130242073.5709.47.camel@thl.ct.heise.de> <1130246459.15304.22.camel@localhost.localdomain> <20051025183953.GE18996@redhat.com> <435E8301.2090408@miconexion.com> <20051025194826.GF18996@redhat.com> <435E9690.6050702@miconexion.com> Message-ID: <20051025210304.GO8436@angus.ind.WPI.EDU> On Tue, Oct 25, 2005 at 09:33:20PM +0100, Manuel Moreno wrote: > The one of you saying that ubuntu kernel has more patches than fedora's > > Fedora > ----------- > $ cd /usr/src/redhat/SOURCES/ > $ rpm -Uvh ../SRPMS/kernel-2.6.13-1.1529_FC4.src.rpm I assume you mean kernel-2.6.13-1.1529_FC5.src.rpm. > $ ls -l *.patch | wc -l > $ 101 Not all patches in the src.rpm are applied. > Ubuntu > ------- > 16 + 24 = 40 patches Number of patch files is irrelevent. How many actual changes are in those patches? Fedora applied patches: applied=`grep -i ^%patch kernel-2.6.spec \ | awk '{print $1}' \ | sed -e's/^%patch/^Patch/' \ | grep -i -f - kernel-2.6.spec \ | awk '{print $2}'` ls `echo $applied` | wc -l 88 diffstat $applied [...] 817 files changed, 143397 insertions(+), 4911 deletions(-) How many of those changes are bugfixes with a low risk vs. new features? From rodd at clarkson.id.au Tue Oct 25 21:57:57 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 26 Oct 2005 07:57:57 +1000 Subject: Loading custom DSDT In-Reply-To: <435E7F65.8070907@miconexion.com> References: <1130238496.14696.11.camel@localhost.localdomain> <1130239039.3125.7.camel@laptopd505.fenrus.org> <1130239933.14696.22.camel@localhost.localdomain> <20051025144310.GA30015@redhat.com> <20051025183013.GD18996@redhat.com> <435E7F65.8070907@miconexion.com> Message-ID: <1130277477.2776.7.camel@localhost.localdomain> On Tue, 2005-10-25 at 19:54 +0100, Manuel Moreno wrote: > Dave Jones wrote: > > On Tue, Oct 25, 2005 at 10:43:10AM -0400, John W. Linville wrote: > > > > > I would like to see a patch like this upstream. I'm not sure how to > > > convince Len Brown to let it in. > > > > > > I don't think putting it in Fedora is necessarily a bad idea, but it > > > is not a slam dunk either (based on support concerns as pointed-out > > > elsewhere). > > > > The Intel folks have refused to merge it upstream as they'd rather > > fix the interpretor to work around broken tables. Some other vendors > > are also very helpful in the "Whack BIOS vendor on the head" dept > > when bad tables get reported to them. > > > > If Fedora carried such a patch, we could forget all about ever > > looking at fixing ACPI bugs that get reported, as I can guarantee > > we'd get reports that conveniently 'forgot' to mention they've hacked > > their DSDT in wierd and wonderful ways. > > > > The ability to screw up AML is hurrendously easy, and the number of > > wannabe AML hackers frankly, scares me witless. A lot of folk seem > > to think that things are as simple as .. > > > > - disassemble DSDT > > - fix up warnings from AML compiler > > - put DSDT into initrd. > > > > This is *wrong* on so many levels. For one, even if it does fix > > the problems the user was seeing, how does it help the next user > > that hits the problem on the same hardware ? We can't expect > > every user to have to patch their DSDT. The correct answer > > is "Fix the BIOS", or where that isn't feasible "Work around > > it in the interpretor" (Especially if its a widespread problem). > > > > Dave > > > > I _strongly_ disagree with that and so seems to be the opinion of > Ubuntu, Mandriva and Novel/SuSe developpers/users and I'm pretty sure > that they have fair good thinking heads too. Are we facing perhaps the > NIH RedHat syndrome or is it a desperate and stubborn USA-centric point > of view from RH far too afraid from USA barrister greed. As a user I don't know what a DSDT table is and I don't care. As a user (and someone who moved from Windows over 8 years ago) I do worry that Linux might start taking the same "don't fix what's busted - work around it" thinking that has made Windows (along with other things) so brain dead. If something is busted, then fix what's busted. Don't make something else work with the bustedness. That just means we've got two busted things to fix (and that we're going backward). I admire the decision (which Dave supports) not to move too far from the mainstream kernel. The list of things that might have been added just because someone thought they were a "Good Idea(TM)" are long and often pointless. As far as I'm aware, we've only just got to a point were we've removed most of the 'busted' add-ins in the kernel from Redhat's earlier days. Let's not go back in that direction. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From wrrhdev at riede.org Tue Oct 25 23:10:47 2005 From: wrrhdev at riede.org (Willem Riede) Date: Tue, 25 Oct 2005 23:10:47 +0000 Subject: Some i386 devel packages installed on x86_64 by mistake Message-ID: <1130281847l.3354l.11l@serve.riede.org> I found out the hard way (rpms not building correctly) that when I installed fc5-devel on my x86_64 system the following three packages were installed only in i386 architecture though x86_64 versions exist: ncurses-devel-5.4-19 pam-devel-0.80-10 zlib-devel-1.2.3-1 After installing their x86_64 counterpart and removing the i386 version all is well (on that front at least). Do I need to bugzilla this and if so, against which component? Regards, Willem Riede. From wrrhdev at riede.org Tue Oct 25 23:20:05 2005 From: wrrhdev at riede.org (Willem Riede) Date: Tue, 25 Oct 2005 23:20:05 +0000 Subject: rawhide report: 20051025 changes In-Reply-To: <1130273221.2799.2.camel@localhost.localdomain> (from rodd@clarkson.id.au on Tue Oct 25 16:47:01 2005) References: <200510251136.j9PBaJAO001084@porkchop.devel.redhat.com> <1130273221.2799.2.camel@localhost.localdomain> Message-ID: <1130282405l.3354l.12l@serve.riede.org> On 10/25/2005 04:47:01 PM, Rodd Clarkson wrote: > On Tue, 2005-10-25 at 07:36 -0400, Build System wrote: > > > > > > Updated Packages: > > > > (none) > > Hmmm, Build System is being a little 'mum' on the updates. > > > Especially since the following packages were offered up for update using > yum today: > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > kernel i686 2.6.13-1.1626_FC5 development 15M Kernel 1626 and 1624 before it don't complete booting on my Opteron x86_64 system. Kernel 1605 on the other hand (still) works just fine. With the later kernels the booting process hangs somewhere during rhgb. It doesn't look like the exact point is reproducable :-( Nothing out of the ordinary is logged in /var/log/messages. Does anyone else experience this? Thanks, Willem Riede. From wrrhdev at riede.org Wed Oct 26 00:04:57 2005 From: wrrhdev at riede.org (Willem Riede) Date: Wed, 26 Oct 2005 00:04:57 +0000 Subject: hsqldb ate uid 500 Message-ID: <1130285097l.3354l.13l@serve.riede.org> When I installed fc5-devel on my x86_64, hsqldb %post created an ordinary user - as opposed to a system one with uid below 500 - which screwed up my NFS mounts as "wriede" is 500 on all my other systems. install.log:Installing hsqldb-1.80.1-1jpp_1fc.x86_64. install.log.syslog:<86>Oct 15 17:18:19 groupadd[4985]: new group: name=hsqldb, GID=500 install.log.syslog:<86>Oct 15 17:18:19 useradd[4986]: new user: name=hsqldb, UID=500, GID=500, home=/var/lib/hsqldb, shell=/bin/sh I also noted that a skeleton was created in /var/lib/hsqldb: total 100 drwxr-xr-x 4 hsqldb hsqldb 4096 Oct 15 17:18 . drwxr-xr-x 19 root root 4096 Oct 22 11:16 .. -rw-r--r-- 1 hsqldb hsqldb 24 Oct 15 17:18 .bash_logout -rw-r--r-- 1 hsqldb hsqldb 191 Oct 15 17:18 .bash_profile -rw-r--r-- 1 hsqldb hsqldb 124 Oct 15 17:18 .bashrc drwxr-xr-x 2 hsqldb hsqldb 4096 Aug 4 06:45 data -rw-r--r-- 1 hsqldb hsqldb 120 Oct 15 17:18 .gtkrc drwxr-xr-x 2 root root 4096 Oct 15 17:18 lib -rw-r--r-- 1 root root 289 Aug 4 06:45 server.properties -rw------- 1 hsqldb hsqldb 4301 Aug 4 06:45 sqltool.rc -rw-r--r-- 1 root root 315 Aug 4 06:45 webserver.properties -rw-r--r-- 1 hsqldb hsqldb 658 Oct 15 17:18 .zshrc I don't think all that's appropriate. Comments? Thanks, Willem Riede. From mhw at wittsend.com Wed Oct 26 03:35:57 2005 From: mhw at wittsend.com (Michael H. Warfield) Date: Tue, 25 Oct 2005 23:35:57 -0400 Subject: SquashFS? In-Reply-To: <1129904291.4377.58.camel@canyon.wittsend.com> References: <200510202008.53326.darko.ilic@gmail.com> <4357E008.6040403@math.unl.edu> <1129858560.3260.32.camel@localhost> <1129904291.4377.58.camel@canyon.wittsend.com> Message-ID: <1130297758.15427.101.camel@canyon.wittsend.com> On Fri, 2005-10-21 at 10:18 -0400, Michael H. Warfield wrote: > On Thu, 2005-10-20 at 18:35 -0700, Toshio Kuratomi wrote: > > On Thu, 2005-10-20 at 13:20 -0500, Rex Dieter wrote: > > > Darko Ilic wrote: > > > > > > > I wanted to ask what are the opinions on the subject, and is there any chance > > > > for SquashFS to make it's way into Fedora kernel by FC5? I`ve heard it was > > > > submitted to LKML recently and there was some discussions surrounding that > > > > and that it is a likely candidate for the upstream kernel. > > > > > > If it makes it upstream, then most likely, yes. > > > I'd like to see a quality Fedora LiveCD. At my day job we're evaluating > > livecds for kiosks, recovery, and lab installs. What has struck me in > > recent days is that they're _all_ Debian based. If we want this to > > change, we need to create liveCDs that > > > squashfs and unionfs are both kernel modules that are pretty standard > > fare in the liveCD world but are not part of the mainline kernel. We > > need to include them in Fedora in order to advance our reputation in the > > liveCD arena. > > I spoke with Andrew Morton about unionfs when we were both at Linux > Lunacy V. He stated that nobody had approached him or Linus about > unionfs and they had not heard a peep about it. But, if someone wants > to submit patches and follow up on it, they are more than willing to > look it over and consider it. > > So, as far as unionfs goes, it's up to the developers to approach the > kernel people about inclusion in the upstream sources. So someone needs > to push the unionfs developers. The issue has now been broached with the developers on the unionfs mailing lists in the context of a major bug fix (hint - upgrade to 1.1.11 if you have large file systems!). I intend on pursuing this further... More to come, I assure you... Regards, Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- 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 nicolas.mailhot at laposte.net Wed Oct 26 06:11:30 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 26 Oct 2005 08:11:30 +0200 Subject: rawhide report: 20051025 changes In-Reply-To: <1130282405l.3354l.12l@serve.riede.org> References: <200510251136.j9PBaJAO001084@porkchop.devel.redhat.com> <1130273221.2799.2.camel@localhost.localdomain> <1130282405l.3354l.12l@serve.riede.org> Message-ID: <1130307090.10185.9.camel@rousalka.dyndns.org> Le mardi 25 octobre 2005 ? 23:20 +0000, Willem Riede a ?crit : > Kernel 1626 and 1624 before it don't complete booting on my Opteron x86_64 > system. Kernel 1605 on the other hand (still) works just fine. > > With the later kernels the booting process hangs somewhere during rhgb. > It doesn't look like the exact point is reproducable :-( > Nothing out of the ordinary is logged in /var/log/messages. > > Does anyone else experience this? Didn't try 1626, so far the newest working kernel is 1622 there (1623 & 1624 fail) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mikem at cyber.com.au Tue Oct 25 04:30:48 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Tue, 25 Oct 2005 14:30:48 +1000 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems In-Reply-To: <4359189B.3080506@3di.it> References: <1129877978.3410.49.camel@localhost.localdomain> <4359189B.3080506@3di.it> Message-ID: <1130214648.2882.13.camel@localhost.localdomain> On Fri, 2005-10-21 at 18:34 +0200, Davide Bolcioni wrote: > Mike MacCana wrote: > > > Why should Fedora and Red Hat encourage installing software in a > > non-standard method? > > Forgetting about autopackage for a moment, /usr/local *is* a > traditional place for administrator-installed software. On Linux, most administrators install software by RPM, and no distinction is made between 'third party' or distro provided except the Packager field. Mike From dax at gurulabs.com Wed Oct 26 07:24:03 2005 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 26 Oct 2005 01:24:03 -0600 Subject: Problems installing rawhide and reporting thereof Message-ID: <1130311443.3223.7.camel@mentorng.gurulabs.com> I understand the guts of Anaconda are changing to use yum and that it is being actively worked on. Given that, are bug reports useful/wanted? I tried installing Oct 25th rawhide on my Thinkpad T42p using the images/boot.iso and a NFS shared rawhide tree. I noticed two problems: 1. X failed to start (all three attempts) with the following error in the various X.log files: [snip] Synaptics no synaptics event device found (checked 10 nodes) Synaptics The /dev/input/event* device nodes seem to be missing Query no Synaptics: 6003C8 (EE) Synaptics no synaptics touchpad detected and no repeater device (EE) Synaptics Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device "Synaptics" No core pointer Fatal server error: failed to initialize core devices [snip] I tried plugging in a usb mouse, but the same error still happened. 2. Skipping X and trying either a VNC or text mode install quickly resulted in failure with a python traceback in yum code, I think it was the "MDrepo" class or something close to that. ------- Dax Kelson Guru Labs From d.lesca at solinos.it Wed Oct 26 08:36:47 2005 From: d.lesca at solinos.it (Dario Lesca) Date: Wed, 26 Oct 2005 10:36:47 +0200 Subject: FC4: SCSI tape not detect [resolved] In-Reply-To: <43582DA2.6000805@iee.lu> References: <1129624561.5046.12.camel@lesca.home.solinos.it> <43582DA2.6000805@iee.lu> Message-ID: <1130315807.3405.53.camel@lesca.home.solinos.it> Il giorno ven, 21/10/2005 alle 01.52 +0200, Charles Lopes ha scritto: > Dario Lesca wrote: > > Hi, After kernel update (2.6.13-1.1526_FC4smp) the SCSI tape driver not > > work, is missing. > Starting with 2.6.13, the low level access for the fusion driver has > been splitted out into mptfc.ko (fiber channel) and mptspi.ko (SCSI > parallel interface). Try loading one of these (probably mptspi). > I have add this line into /etc/modprobe.conf: alias scsi_hostadapter3 mptspi then reboot. Now the tape work great!. Many thanks to all. -- Dario Lesca From db-fedora at 3di.it Wed Oct 26 09:07:49 2005 From: db-fedora at 3di.it (Davide Bolcioni) Date: Wed, 26 Oct 2005 11:07:49 +0200 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems In-Reply-To: <1130214648.2882.13.camel@localhost.localdomain> References: <1129877978.3410.49.camel@localhost.localdomain> <4359189B.3080506@3di.it> <1130214648.2882.13.camel@localhost.localdomain> Message-ID: <435F4765.3020201@3di.it> Mike MacCana wrote: > On Linux, most administrators install software by RPM, and no > distinction is made between 'third party' or distro provided except the > Packager field. Agreed, but RPM-installed software does not usually end up in /usr/local. If I remember the FHS correctly, it is not supposed to end up there, as /usr/local is reserved to locally installed software and must be left untouched by a system upgrade. The typical Linux distro muddles the concept of what is a "system upgrade", e.g. is OpenOffice part of the system upgrade, but I had always regarded the wording in the FHS as a guarantee that "there should not be surprises in /usr/local". Am I wrong ? Thank you for your consideration, Davide Bolcioni From rc040203 at freenet.de Wed Oct 26 09:31:59 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 26 Oct 2005 11:31:59 +0200 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems In-Reply-To: <435F4765.3020201@3di.it> References: <1129877978.3410.49.camel@localhost.localdomain> <4359189B.3080506@3di.it> <1130214648.2882.13.camel@localhost.localdomain> <435F4765.3020201@3di.it> Message-ID: <1130319120.28858.467.camel@mccallum.corsepiu.local> On Wed, 2005-10-26 at 11:07 +0200, Davide Bolcioni wrote: > Mike MacCana wrote: > > > On Linux, most administrators install software by RPM, and no > > distinction is made between 'third party' or distro provided except the > > Packager field. > > Agreed, but RPM-installed software does not usually end up in > /usr/local. True, but this only is a side-effect ... > If I remember the FHS correctly, it is not supposed to end > up there, as /usr/local is reserved to locally installed software and > must be left untouched by a system upgrade. ... of this, because _vendors_ are supposed to install to /usr. => vendor supplied rpms normally do not end up below /usr/local. Also, in a strictly FHS-compliant world, you would install all non-vendor supplied packages to /usr/local and would not replace any vendor supplied package nor file. I.e. to install rpm packages to /usr/local you would have to build them with a different package name and different %_prefix, %_bindir etc., than a vendor would do. As this is beyond most people's capabilities (and because most vendor supplied rpm specs are not prepared for this), most people often simply replace the vendor supplied packages below /usr, instead. Strictly speaking, they violate the FHS, when doing so. Ralf From buildsys at redhat.com Wed Oct 26 11:48:24 2005 From: buildsys at redhat.com (Build System) Date: Wed, 26 Oct 2005 07:48:24 -0400 Subject: rawhide report: 20051026 changes Message-ID: <200510261148.j9QBmOQM014654@porkchop.devel.redhat.com> Removed package libsigc++ Updated Packages: ORBit2-2.12.4-3 --------------- * Tue Oct 25 2005 Alexander Larsson 2.12.4-3 - Build with --enable-purify to avoid valgrind warnings checkpolicy-1.27.17-1 --------------------- * Tue Oct 25 2005 Dan Walsh 1.27.17-1 - Latest upgrade from NSA * Merged dismod fix from Joshua Brindle. gnome-vfs2-2.12.1.1-3 --------------------- * Tue Oct 25 2005 Alexander Larsson - 2.12.1.1-3 - Use avahi instead of howl hdparm-6.3-1 ------------ * Tue Oct 25 2005 Karsten Hopp 6.3-1 - update to hdparm-6.3 hexedit-1.2.12-2 ---------------- * Tue Oct 25 2005 Jindrich Novy 1.2.12-2 - rewrite %description - the original one was a nonsense (#171685) kdeaccessibility-1:3.4.92-1 --------------------------- * Tue Oct 25 2005 Than Ngo 1:3.4.92-1 - update to 3.5 beta2 kdeaddons-3.4.92-1 ------------------ * Tue Oct 25 2005 Than Ngo 3.4.92-1 - update to KDE 3.5 beta 2 kdeartwork-3.4.92-1 ------------------- * Tue Oct 25 2005 Than Ngo 3.4.92-1 - update to 3.5 Beta 2 kdebindings-3.4.92-1 -------------------- * Tue Oct 25 2005 Than Ngo 3.4.92-1 - update to 3.5 beta2 kdeedu-3.4.92-1 --------------- * Tue Oct 25 2005 Than Ngo 3.4.92-1 - update to 3.5 beta2 kdegames-6:3.4.92-1 ------------------- * Tue Oct 25 2005 Than Ngo 6:3.4.92-1 - update to 3.5 Beta2 kdegraphics-7:3.4.92-1 ---------------------- * Tue Oct 25 2005 Than Ngo 7:3.4.92-1 - update to 3.5 Beta 2 * Thu Oct 13 2005 Matthias Clasen 7:3.4.91-2 - don't use freetype internals kdenetwork-7:3.4.92-1 --------------------- * Tue Oct 25 2005 Than Ngo 7:3.4.92-1 - update to 3.5 Beta 2 kdesdk-3.4.92-1 --------------- * Tue Oct 25 2005 Than Ngo 2:3.4.92-1 - update to 3.5 Beta2 kdeutils-6:3.4.92-1 ------------------- * Tue Oct 25 2005 Than Ngo 6:3.4.92-1 - update to 3.5 beta2 kdevelop-9:3.2.92-1 ------------------- * Tue Oct 25 2005 Than Ngo 9:3.2.92-1 - update to KDE 3.5 beta2 kdewebdev-6:3.4.92-1 -------------------- * Tue Oct 25 2005 Than Ngo 6:3.4.92-1 - update to 3.5 beta2 kernel-2.6.13-1.1627_FC5 ------------------------ * Tue Oct 25 2005 Dave Jones - 2.6.14-rc5-git5 libselinux-1.27.14-1 -------------------- * Tue Oct 25 2005 Dan Walsh 1.9.24-1 - Update to latest from NSA * Merged selinux_path() and selinux_homedir_context_path() functions from Joshua Brindle. libsemanage-1.3.34-1 -------------------- * Tue Oct 25 2005 Dan Walsh 1.3.34-1 - Update from NSA * Merged resync to sepol changes and booleans fixes/improvements patches from Ivan Gyurdiev. * Merged support for genhomedircon/homedir template, store selection, explicit policy reload, and semanage.conf relocation from Joshua Brindle. libsepol-1.9.30-1 ----------------- * Tue Oct 25 2005 Dan Walsh 1.9.30-1 - Upgrade to latest from NSA * Removed processing of system.users from sepol_genusers and dropped delusers logic. * Removed policydb_destroy from error path of policydb_read, since create/init/destroy/free of policydb is handled by the caller now. * Fixed sepol_module_package_read to handle a failed policydb_read properly. * Merged query/exists and count patches from Ivan Gyurdiev. * Merged fix for pruned types in expand code from Joshua Brindle. * Merged new module package format code from Joshua Brindle. logrotate-3.7.2-10 ------------------ * Tue Oct 25 2005 Peter Vrabec 3.7.2-10 - some more clean up (#171587) mt-st-0.9b-2 ------------ * Tue Oct 25 2005 Jindrich Novy 0.9b-2 - fix misleading description of "fsfm" and "bsfm" commands (#171340) openoffice.org-1:2.0.0-3.6.2 ---------------------------- * Fri Oct 14 2005 Caolan McNamara - 1:2.0.0-3.6 - rh#171425#/ooo#56536# weird SwTxtNode is not a SwTxtNode problem * Fri Oct 14 2005 Caolan McNamara - 1:2.0.0-3.5 - get RPM_OPT_FLAGS in operation minus -fasynchronous-unwind-tables openswan-2.4.2-0.dr1.1 ---------------------- * Tue Oct 25 2005 Harald Hoyer - 2.4.2-0.dr1.1 - version 2.4.2dr1 ppc64-utils-0.9-11 ------------------ * Tue Oct 25 2005 Paul Nasrat - 0.9-1 - Bump internal version above rhel4 ver - Pull in later ppc64-utils (#169035) * Tue Oct 25 2005 Paul Nasrat - 0.7-13 - Stop scanning nvram on broken content (#170418) pup-0.1.4-1 ----------- * Tue Oct 25 2005 Paul Nasrat - 0.1.4-1 - pam file update (#170738) redhat-menus-5.0.4-1 -------------------- * Tue Oct 25 2005 David Malcolm - 5.0.4-1 - Split the evolution desktop file into four separate ones: one per component. Force people to update evolution, to avoid it using a stale symlink. (#170799). system-config-network-1.3.29-1 ------------------------------ * Tue Oct 25 2005 Harald Hoyer - 1.3.29 - fixed profileFrame labeling udev-071-1 ---------- * Tue Oct 25 2005 Harald Hoyer - 071-1 - version 071 vim-1:6.4.000-2 --------------- * Tue Oct 25 2005 Karsten Hopp 6.4.000-2 - use %{_sysconfdir} (#171556) - add syntax highlighting rule for %check (Ralf Ertzinger, #165277) wget-1.10.2-2 ------------- * Tue Oct 25 2005 Karsten Hopp 1.10.2-2 - use %{_sysconfdir} (#171555) xorg-x11-6.8.2-56 ----------------- * Tue Oct 25 2005 Mike A. Harris 6.8.2-56 - Added "Provides: lib*-devel" virtual provides to 'devel' subpackage, so that packages updated tp build in the modular tree will still build in the monolithic tree as well. From vonbrand at inf.utfsm.cl Wed Oct 26 03:06:49 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Wed, 26 Oct 2005 00:06:49 -0300 Subject: rawhide report: 20051025 changes In-Reply-To: Message from Willem Riede of "Tue, 25 Oct 2005 23:20:05 -0000." <1130282405l.3354l.12l@serve.riede.org> Message-ID: <200510260306.j9Q36n1o009338@laptop11.inf.utfsm.cl> Willem Riede wrote: [...] > Kernel 1626 and 1624 before it don't complete booting on my Opteron x86_64 > system. Kernel 1605 on the other hand (still) works just fine. > > With the later kernels the booting process hangs somewhere during rhgb. > It doesn't look like the exact point is reproducable :-( > Nothing out of the ordinary is logged in /var/log/messages. Here it hangs in "Enabling swap" (get rid of the rhgb argument to see what goes on). Has done so for anything after 1621 here. I filed it to bugzilla, but it is gone now? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From clumens at redhat.com Wed Oct 26 13:53:20 2005 From: clumens at redhat.com (Chris Lumens) Date: Wed, 26 Oct 2005 09:53:20 -0400 (EDT) Subject: Problems installing rawhide and reporting thereof In-Reply-To: <1130311443.3223.7.camel@mentorng.gurulabs.com> References: <1130311443.3223.7.camel@mentorng.gurulabs.com> Message-ID: > I understand the guts of Anaconda are changing to use yum and that it is > being actively worked on. Given that, are bug reports useful/wanted? Yes, bug reports are still useful as long as they're not about how group selection is busted. That's what is seeing the active work right now. > 1. X failed to start (all three attempts) with the following error in > the various X.log files: > > [snip] > Synaptics no synaptics event device found (checked 10 nodes) > Synaptics The /dev/input/event* device nodes seem to be missing > Query no Synaptics: 6003C8 > (EE) Synaptics no synaptics touchpad detected and no repeater device > (EE) Synaptics Unable to query/initialize Synaptics hardware. > (EE) PreInit failed for input device "Synaptics" > No core pointer > > Fatal server error: > failed to initialize core devices > [snip] > > I tried plugging in a usb mouse, but the same error still happened. I fixed this on 10/14 and we did a build later that day, so it should be fine. On a test machine here, I see /dev/input/event{0-3} being created. After X fails, can you switch over to tty2 and check that those exist? > 2. Skipping X and trying either a VNC or text mode install quickly > resulted in failure with a python traceback in yum code, I think it was > the "MDrepo" class or something close to that. This should have been fixed within the past couple days, too. Are you sure you are using a 10/25 tree? - Chris From shiva at sewingwitch.com Wed Oct 26 13:56:29 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 26 Oct 2005 06:56:29 -0700 Subject: Loading custom DSDT In-Reply-To: <1130270285.16802.13.camel@localhost.localdomain> References: <1130238496.14696.11.camel@localhost.localdomain> <1130242073.5709.47.camel@thl.ct.heise.de> <1130246459.15304.22.camel@localhost.localdomain> <20051025183953.GE18996@redhat.com> <435E8301.2090408@miconexion.com> <20051025194826.GF18996@redhat.com> <1130270285.16802.13.camel@localhost.localdomain> Message-ID: <0AC12035D723DD37EDC98361@[10.169.6.233]> --On Tuesday, October 25, 2005 8:58 PM +0100 Richard Hughes wrote: > Yes, but their systems admin (who does know what he is doing) needs a > way to "fix" the problem, which in Fedora, he can't do. Have you approached any of the RH-derived distros to do this? It sounds like you're asking RH to provide free fixes for broken hardware, in some cases obsolete and not supported by the original vendor. I don't see that flying. Instead, consider hiring someone to prepare a derived distro with the fixes you want. For the benefit of lurkers who, like me, don't know what DSDT stands for, here's an excerpt from the Linux ACPI site: > DSDT is an acronym for Differentiated System Description Table. This > table contains the Differentiated Definition Block, which supplies the > information and configuration information about the base system. It is > always inserted into the ACPI Namespace by the OS at boot time. > Unfortunately, many hardware vendors and OEMs are not capable of > supplying fully functional tables (not even the members of the ACPI SIG), > see also the blacklist. This is from . From katzj at redhat.com Wed Oct 26 15:21:19 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 26 Oct 2005 11:21:19 -0400 Subject: Some i386 devel packages installed on x86_64 by mistake In-Reply-To: <1130281847l.3354l.11l@serve.riede.org> References: <1130281847l.3354l.11l@serve.riede.org> Message-ID: <1130340079.2973.23.camel@bree.local.net> On Tue, 2005-10-25 at 23:10 +0000, Willem Riede wrote: > I found out the hard way (rpms not building correctly) that when I installed > fc5-devel on my x86_64 system the following three packages were installed only > in i386 architecture though x86_64 versions exist: [snip] > After installing their x86_64 counterpart and removing the i386 version all is > well (on that front at least). > > Do I need to bugzilla this and if so, against which component? There's an anaconda bug where i386 packages were getting preferred over x86_64 in some cases... I think I fixed it on Monday, but wasn't in the office yesterday so haven't had a chance to double check yet Jeremy From katzj at redhat.com Wed Oct 26 15:27:45 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 26 Oct 2005 11:27:45 -0400 Subject: hsqldb ate uid 500 In-Reply-To: <1130285097l.3354l.13l@serve.riede.org> References: <1130285097l.3354l.13l@serve.riede.org> Message-ID: <1130340466.2973.26.camel@bree.local.net> On Wed, 2005-10-26 at 00:04 +0000, Willem Riede wrote: > When I installed fc5-devel on my x86_64, hsqldb %post created an > ordinary user - as opposed to a system one with uid below 500 - > which screwed up my NFS mounts as "wriede" is 500 on all my other > systems. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165670 Jeremy From dax at gurulabs.com Wed Oct 26 18:14:27 2005 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 26 Oct 2005 12:14:27 -0600 Subject: Problems installing rawhide and reporting thereof In-Reply-To: References: <1130311443.3223.7.camel@mentorng.gurulabs.com> Message-ID: <1130350467.3864.2.camel@mentorng.gurulabs.com> On Wed, 2005-10-26 at 09:53 -0400, Chris Lumens wrote: > > 1. X failed to start (all three attempts) with the following error in > > the various X.log files: > > > > [snip] > > Synaptics no synaptics event device found (checked 10 nodes) > > Synaptics The /dev/input/event* device nodes seem to be missing > I fixed this on 10/14 and we did a build later that day, so it should be > fine. On a test machine here, I see /dev/input/event{0-3} being > created. After X fails, can you switch over to tty2 and check that > those exist? > > > 2. Skipping X and trying either a VNC or text mode install quickly > > resulted in failure with a python traceback in yum code, I think it was > > the "MDrepo" class or something close to that. > > This should have been fixed within the past couple days, too. Are you > sure you are using a 10/25 tree? The tree I was using was 10/24. I'm rsyncing my tree right now and try again today. Dax Kelson Guru Labs From dakingun at gmail.com Wed Oct 26 18:37:13 2005 From: dakingun at gmail.com (Deji Akingunola) Date: Wed, 26 Oct 2005 14:37:13 -0400 Subject: Problems installing rawhide and reporting thereof In-Reply-To: References: <1130311443.3223.7.camel@mentorng.gurulabs.com> Message-ID: On 10/26/05, Chris Lumens wrote: > > 1. X failed to start (all three attempts) with the following error in > > the various X.log files: > > > > [snip] > > Synaptics no synaptics event device found (checked 10 nodes) > > Synaptics The /dev/input/event* device nodes seem to be missing > > Query no Synaptics: 6003C8 > > (EE) Synaptics no synaptics touchpad detected and no repeater device > > (EE) Synaptics Unable to query/initialize Synaptics hardware. > > (EE) PreInit failed for input device "Synaptics" > > No core pointer > > > > Fatal server error: > > failed to initialize core devices > > [snip] > > > > I tried plugging in a usb mouse, but the same error still happened. > > I fixed this on 10/14 and we did a build later that day, so it should be > fine. On a test machine here, I see /dev/input/event{0-3} being > created. After X fails, can you switch over to tty2 and check that > those exist? > I still experienced the same error using a 10/25 tree. Deji From katzj at redhat.com Wed Oct 26 18:48:25 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 26 Oct 2005 14:48:25 -0400 Subject: Problems installing rawhide and reporting thereof In-Reply-To: References: <1130311443.3223.7.camel@mentorng.gurulabs.com> Message-ID: <1130352505.2973.89.camel@bree.local.net> On Wed, 2005-10-26 at 14:37 -0400, Deji Akingunola wrote: > On 10/26/05, Chris Lumens wrote: > > > 1. X failed to start (all three attempts) with the following error in > > > the various X.log files: > > > > > > [snip] > > > Synaptics no synaptics event device found (checked 10 nodes) > > > Synaptics The /dev/input/event* device nodes seem to be missing > > > Query no Synaptics: 6003C8 > > > (EE) Synaptics no synaptics touchpad detected and no repeater device > > > (EE) Synaptics Unable to query/initialize Synaptics hardware. > > > (EE) PreInit failed for input device "Synaptics" > > > No core pointer > > > > > > Fatal server error: > > > failed to initialize core devices > > > [snip] > > > > > > I tried plugging in a usb mouse, but the same error still happened. > > > > I fixed this on 10/14 and we did a build later that day, so it should be > > fine. On a test machine here, I see /dev/input/event{0-3} being > > created. After X fails, can you switch over to tty2 and check that > > those exist? > > > I still experienced the same error using a 10/25 tree. This is because Chris changed it so we make the device nodes after starting X. Less useful. The beating will commence shortly ;-) Jeremy From clumens at redhat.com Wed Oct 26 18:57:18 2005 From: clumens at redhat.com (Chris Lumens) Date: Wed, 26 Oct 2005 14:57:18 -0400 (EDT) Subject: Problems installing rawhide and reporting thereof In-Reply-To: <1130352505.2973.89.camel@bree.local.net> References: <1130311443.3223.7.camel@mentorng.gurulabs.com> <1130352505.2973.89.camel@bree.local.net> Message-ID: > This is because Chris changed it so we make the device nodes after > starting X. Less useful. The beating will commence shortly ;-) Yeah, that's not the smartest thing I've done. I'm sure there will be more of those moments in the future. Fixed. - Chris From jkeating at j2solutions.net Wed Oct 26 19:02:42 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 26 Oct 2005 12:02:42 -0700 Subject: Encouraging the use of multiple packaging systems on one systems, and the resulting problems In-Reply-To: <1130214648.2882.13.camel@localhost.localdomain> References: <1129877978.3410.49.camel@localhost.localdomain> <4359189B.3080506@3di.it> <1130214648.2882.13.camel@localhost.localdomain> Message-ID: <1130353362.28809.80.camel@prometheus.gamehouse.com> On Tue, 2005-10-25 at 14:30 +1000, Mike MacCana wrote: > > On Linux, most administrators install software by RPM, and no > distinction is made between 'third party' or distro provided except the > Packager field. Actually it makes a huge difference. Where are updates going to come from? What other deps will I have to install to get this rpm in? What core software might be replaced by these deps that I have to watch out for? What is the likelihood that this software will be maintained in the future when security or bug reports are made? What happens when we upgrade OS releases, etc. etc.. Admins care greatly where their software comes from. -- 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 From vikasx.aggarwal at intel.com Wed Oct 26 18:48:31 2005 From: vikasx.aggarwal at intel.com (Aggarwal, VikasX) Date: Wed, 26 Oct 2005 11:48:31 -0700 Subject: initrd stage: CAP_SYS_RAWIO on /dev/iscsictl fails . help Message-ID: <69F69FD5FD4A9843ACBF7CE9B7830B4A06289180@orsmsx408> Subject : Is CAP_SYS_RAWIO not permitted during the initrd stage in kernel 2.6.9-22 ? It was permitted in 2.4.20 kernel. Installing and booting from iSCSI disk (worked in 2.4.20 , fails in 2.6.9-22 kernel). Hi, I am in the initrd stage of boot . Kernel 2.6.9-22 , Red Hat enterprise linux. During post-install stage and before the first boot , I modified the initrd to have my iscsi driver and related daemon in initrd. The installation was made successfully to an iSCSI disk. Now need to boot through it. During the initrd stage in first-time-boot , my daemon gets the iSCSI device name from the remote storage server. " now it wants to pass that information to iscsi-sfnet.ko via IOCTL" , the ioctl call returns error (-1) which is EPERM, the perror says-Inappropriate IOCTL". Why that error return from sys_ioctl ? Is CAP_SYS_RAWIO or some other capability not permitted during the initrd stage in kernel 2.6.9-22? I have used the same thing in 2.4.20 kernel . works great. I can install and also boot from the remote iSCSI disk with my modified initrd in 2.4.20 kernels. Are the new security features of 2.6 kernel ( security/seclvl.c) hindering this IOCTL operation during initrd stage? What is the solution to my problem. Is there a boot-time parameter ? Please advice . thanks -Vikas -------------- next part -------------- An HTML attachment was scrubbed... URL: From wrrhdev at riede.org Wed Oct 26 22:33:24 2005 From: wrrhdev at riede.org (Willem Riede) Date: Wed, 26 Oct 2005 22:33:24 +0000 Subject: rawhide report: 20051025 changes In-Reply-To: <200510260306.j9Q36n1o009338@laptop11.inf.utfsm.cl> (from vonbrand@inf.utfsm.cl on Tue Oct 25 23:06:49 2005) References: <200510260306.j9Q36n1o009338@laptop11.inf.utfsm.cl> Message-ID: <1130366004l.3354l.15l@serve.riede.org> On 10/25/2005 11:06:49 PM, Horst von Brand wrote: > Willem Riede wrote: > > [...] > > > Kernel 1626 and 1624 before it don't complete booting on my Opteron x86_64 > > > system. Kernel 1605 on the other hand (still) works just fine. > > > > With the later kernels the booting process hangs somewhere during rhgb. > > It doesn't look like the exact point is reproducable :-( > > Nothing out of the ordinary is logged in /var/log/messages. > > Here it hangs in "Enabling swap" (get rid of the rhgb argument to see what > goes on). Has done so for anything after 1621 here. > > I filed it to bugzilla, but it is gone now? Don't think so -- today's 1627 hangs there for me. Regards, Willem Riede. From arjanv at redhat.com Thu Oct 27 10:13:40 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 27 Oct 2005 12:13:40 +0200 Subject: initrd stage: CAP_SYS_RAWIO on /dev/iscsictl fails . help In-Reply-To: <69F69FD5FD4A9843ACBF7CE9B7830B4A06289180@orsmsx408> References: <69F69FD5FD4A9843ACBF7CE9B7830B4A06289180@orsmsx408> Message-ID: <1130408020.3027.7.camel@laptopd505.fenrus.org> On Wed, 2005-10-26 at 11:48 -0700, Aggarwal, VikasX wrote: > Subject : Is CAP_SYS_RAWIO not permitted during the initrd stage > in kernel 2.6.9-22 ? It was permitted in 2.4.20 kernel. > > Installing and booting from iSCSI disk (worked in > 2.4.20 , fails in 2.6.9-22 kernel). > This is a Red Hat Enterprise Linux question and thus off-topic for this list. Red Hat and your employer have a rather tight engineering relationship, it's probably best if you try to ask your question via that channel so that it gets the attention it deserves. Greetings, Arjan van de Ven From buildsys at redhat.com Thu Oct 27 11:44:17 2005 From: buildsys at redhat.com (Build System) Date: Thu, 27 Oct 2005 07:44:17 -0400 Subject: rawhide report: 20051027 changes Message-ID: <200510271144.j9RBiHtK022297@porkchop.devel.redhat.com> New package pycairo Python bindings for the cairo library New package selinux-policy-mls SELinux mls policy configuration Updated Packages: Pyrex-0:0.9.3.1-2 ----------------- * Wed Oct 26 2005 John (J5) Palmieri - 0.9.3.1-2 - Remove lib64 hack since this is a noarch package - use python_sitelib script for determining where to install to autofs-1:4.1.4-11 ----------------- * Wed Oct 26 2005 - 1:4.1.4-11 - Check the return code of is_local_addr in get_best_mount. (bz #169523) * Wed Oct 26 2005 - 1:4.1.4-10 - Fix some bugs in the parser - allow -net instead of /etc/auto.net - Fix a buffer overflow with large key lengths - Don't allow autofs to unlink files, only to remove directories - change to the upstream reentrant syslog patch from the band-aid deferred syslog patch. - Get rid of the init script patch that hard-coded the release to redhat. This should be handled properly by all red hat distros. avahi-0.5.2-2 ------------- cairo-java-1.0.1-2 ------------------ * Wed Oct 12 2005 Igor Foox - 1.0.0-2 - Excluded s390x. * Wed Oct 12 2005 Igor Foox - 1.0.0-1 - Updated to released 1.0.1 sources from upstream. evolution-2.4.1-7 ----------------- * Wed Oct 26 2005 David Malcolm - 2.4.1-7 - Added a patch (110) to hide the component switcher buttons by default on new windows (#170799) by patching the GConf schema. - Made list of installed schemas explicit. - Own the plugins subdirectory * Tue Oct 25 2005 David Malcolm - 2.4.1-6 - use 4 separate .desktop files from the redhat-menus package, rather than the current single one; bump the redhat-menus requirement accordingly (from 1.13 to 5.0.4); introduce a macro for this requirement. glib-java-0.2.1-2 ----------------- * Wed Oct 26 2005 Igor Foox - 0.2.1-2 - Excluded s390x, since it fails for random reasons. gnome-netstatus-2.12.0-3 ------------------------ * Wed Oct 26 2005 Matthias Clasen - 2.12.0-3 - system-control-network works again hplip-0.9.6-4 ------------- * Wed Oct 26 2005 Tim Waugh 0.9.6-4 - Ship initscript in %{_sysconfdir}/rc.d/init.d. * Fri Oct 14 2005 Tim Waugh - Install the desktop file with Hidden=True (bug #170762). kde-i18n-1:3.4.92-1 ------------------- * Tue Oct 25 2005 Than Ngo 1:3.4.92-1 - update to 3.5 beta2 kernel-2.6.13-1.1629_FC5 ------------------------ * Wed Oct 26 2005 Dave Jones - 2.6.14-rc5-git6 - Disable CONFIG_OPTIMIZE_FOR_SIZE again It seems to break booting randomly on x86-64 among other things. kernel-xen-2.6.12-1.7_FC5 ------------------------- * Wed Oct 26 2005 Arjan van de Ven - resync with mercurial xen in the hope to fix some remaining instabilities libgconf-java-2.12.1-1 ---------------------- * Wed Oct 26 2005 Igor Foox - 2.12.1-1 - Updated to released 2.12.1 sources from upstream. - Excluded s390x. libglade-java-2.12.1-2 ---------------------- * Wed Oct 26 2005 Igor Foox - 2.12.1-1 - Updated to released 2.12.1 sources from upstream. - Excluded s390x. libgnome-java-2.12.1-2 ---------------------- * Wed Oct 26 2005 Igor Foox - 2.12.1-1 - Updated to released 2.12.1 sources from upstream. - Excluded s390x. libgtk-java-2.8.1-1 ------------------- * Wed Oct 12 2005 Igor Foox - 2.8.1-1 - Updated to released 2.8.1 sources from upstream. - Excluded s390x. libselinux-1.27.14-3 -------------------- * Wed Oct 26 2005 Dan Walsh 1.9.24-3 - Change default to __default__ * Tue Oct 25 2005 Dan Walsh 1.9.24-2 - Add selinux_translations_path libsepol-1.9.32-1 ----------------- * Wed Oct 26 2005 Dan Walsh 1.9.32-1 - Upgrade to latest from NSA * Added further checking and error reporting to sepol_module_package_read and _info. * Merged sepol handle passing, DEBUG conversion, and memory leak fix patches from Ivan Gyurdiev. libsetrans-0.1.8-1 ------------------ * Tue Oct 25 2005 Dan Walsh 0.1.8-1 - Add MLS Policy handling pam-0.80-13 ----------- * Wed Oct 26 2005 Tomas Mraz 0.80-13 - fixed CAN-2005-2977 unix_chkpwd should skip user verification only if run as root (#168181) - link pam_loginuid to libaudit - support no tty in pam_access (#170467) - updated audit patch (by Steve Grubb) - the previous pam_selinux change was not applied properly - pam_xauth: look for the xauth binary in multiple directories (#171164) * Wed Oct 26 2005 Dan Walsh 0.80-12 - Eliminate multiple in pam_selinux passwd-0.71-2 ------------- * Tue Oct 25 2005 Steve Grubb 0.71-2 - adjust audit communication to use common logging functions policycoreutils-1.27.19-1 ------------------------- * Tue Oct 25 2005 Dan Walsh 1.27.19-1 - Update to match NSA * Merged semodule support for reload, noreload, and store options from Joshua Brindle. * Merged semodule_package rewrite from Joshua Brindle. pygtk2-2.8.2-2 -------------- * Wed Oct 26 2005 John (J5) Palmieri - 2.8.2-2 - Add the pycairo dependency since pycairo is now built in rawhide rhgb-0.16.2-7 ------------- * Wed Oct 26 2005 Ray Strode 0.16.2-7 - initialize utf-8 mode on console * Wed Oct 26 2005 Ray Strode 0.16.2-6 - Don't make setxkbmap hungry for brains (reported by Chris Lumens). selinux-policy-strict-1.27.2-5 ------------------------------ * Wed Oct 26 2005 Dan Walsh 1.27.2-5 - Fix reload policy in sources - Fix postfix_disable_trans * Wed Oct 26 2005 Dan Walsh 1.27.2-4 - Fix reload policy in sources * Tue Oct 25 2005 Dan Walsh 1.27.2-3 - Add setrans.conf selinux-policy-targeted-1.27.2-5 -------------------------------- * Wed Oct 26 2005 Dan Walsh 1.27.2-5 - Fix reload policy in sources - Fix postfix_disable_trans * Wed Oct 26 2005 Dan Walsh 1.27.2-4 - Fix reload policy in sources * Tue Oct 25 2005 Dan Walsh 1.27.2-3 - Add setrans.conf setools-2.1.3-1 --------------- * Thu Oct 13 2005 Dan Walsh 2.1.3-1 - Upgrade to upstream version sharutils-4.6-1 --------------- * Wed Oct 26 2005 Than Ngo 4.6-1 - update to 4.6 system-config-soundcard-1.2.14-1 -------------------------------- * Wed Oct 26 2005 Martin Stransky 1.2.14 - fix for #170073 - Cannot configure snd-dummy - fix for #171545 - Please do not hard code file name into - fix for #156802 - Menu entry not localized system-switch-mail-0.5.25-5 --------------------------- * Wed Oct 26 2005 Than Ngo 0.5.25-5 - add new common pam configuration file #170650 - update po files totem-1.2.0-1 ------------- * Wed Oct 26 2005 John (J5) Palmieri - 1.2.0-1 - Update to 1.2.0 usermode-1.82-1 --------------- * Wed Oct 26 2005 Jindrich Novy 1.82-1 - don't use pam_stack.so - introduce userformat to better handle device formatting and removing usermount from menus (#132559) wordtrans-1.1pre13-12 --------------------- * Tue Oct 25 2005 Than Ngo 1.1pre13-12 - rebuilt From nicolas.mailhot at laposte.net Thu Oct 27 12:38:01 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 27 Oct 2005 14:38:01 +0200 Subject: UTF-8 & imap folder name handling Message-ID: <1130416681.32348.34.camel@rousalka.dyndns.org> Hi, The Fedora Linux project and Red Hat are pushing very hard for good internationalisation support. That means UTF-8 support in every single app they ship even if it may cause interoperability problems with old applications (the common feeling is if we wait for everyone to jump on the unicode boat before using unicode, we'll still be waiting in ten years). Squirrelmail by default does not use UTF-8 for many of its locales, causing character losses when you reply to a message that contains characters not available in the encoding declared for your locale. To workaround this all the locales in the fedora squirrelmail version are converted to UTF-8 at build time (cf attached build script). This fixes interoperability between locales, since all characters in a received message now fit inside the locale encoding, so quoting people when replying to them now work. Unfortunately this fix has unearthed a problem with squirrelmail handling of imap folders. squirrelmail seems to assume 7bit imap folder names, as soon as you try do display a folder name that use >7bit characters in an UTF-8 locale things break (it doesn't with 8bit iso locales, probably because so many bits assume iso-8859-1 transcoding problems cancel one another). With an UTF-8 locale SM won't display properly non-ascii folder names when those have been created by another mail client, if you recreate/rename the folders in squirrelmail display is now fine inside SM but broken for everyone else. Many common default folders use >7bit encodings in many locales (Sent -> "?l?ments envoy?s" in French) so you're almost certain to hit this bug as soon as you use an UTF-8 locale that actually needs >7bit for naming folders. It's not a problem that can be ignored if one wants to ship and i18n SM. Can someone familiar with squirrelmail fix the imap folder encoding code when local is UTF-8-enabled ? This is a bit too much to do at the Fedora level (especially since Fedora tries to stay close to upstream). If not Fedora will have to accept SM won't do UTF-8 sanely any time soon, which will mean SM removal according to Fedora internal rules. Various bug reports related to the problem : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162852 https://sourceforge.net/tracker/?func=detail&aid=1339393&group_id=311&atid=100311 https://sourceforge.net/tracker/?func=detail&atid=423691&aid=1235345&group_id=311 Regards, -- Nicolas Mailhot -------------- next part -------------- # OPTION: Fedora (1) or RHEL (0) Splash %define fedora_splash 1 %define contentdir /var/www Summary: SquirrelMail webmail client Name: squirrelmail Version: 1.4.6 Release: 0.cvs20050812.2.fc5.1.nim License: GPL URL: http://www.squirrelmail.org/ Group: Applications/Internet #Source: %{name}-%{version}.tar.bz2 Source0: %{name}-1.4.5.tar.bz2 Source1: squirrelmail.conf Source2: squirrelmail-splash-fedora.png Source3: squirrelmail-splash-rhel.png Source4: squirrelmail-20050812_1242-CVS.locales.tar.bz2 Patch2: squirrelmail-1.4.3-config.patch Patch3: squirrelmail-1.4.6-cvs20050812.patch Patch4: squirrelmail-1.4.5-charset.patch BuildRoot: %{_tmppath}/%{name}-%{version}-root BuildArch: noarch Requires: httpd, php >= 4.0.4, perl, tmpwatch >= 2.8, aspell Requires: /usr/sbin/sendmail Prereq: httpd, perl Provides: squirrelmail-i18n %description SquirrelMail is a standards-based webmail package written in PHP4. It includes built-in pure PHP support for the IMAP and SMTP protocols, and all pages render in pure HTML 4.0 (with no Javascript) for maximum compatibility across browsers. It has very few requirements and is very easy to configure and install. SquirrelMail has all the functionality you would want from an email client, including strong MIME support, address books, and folder manipulation. %prep #%setup -q %setup -q -n squirrelmail-1.4.5 %patch2 -p0 %patch3 -p1 %patch4 -p1 rm -f plugins/make_archive.pl # Rearrange the documentation mv AUTHORS ChangeLog COPYING INSTALL README UPGRADE doc/ mv ReleaseNotes doc/ReleaseNotes.txt mv themes/README.themes doc/ for f in `find plugins -name "README*" -or -name INSTALL \ -or -name CHANGES -or -name HISTORY`; do mkdir -p doc/`dirname $f` mv $f $_ done mv doc/plugins/squirrelspell/doc/README doc/plugins/squirrelspell rmdir doc/plugins/squirrelspell/doc mv plugins/squirrelspell/doc/* doc/plugins/squirrelspell rm -f doc/plugins/squirrelspell/index.php rmdir plugins/squirrelspell/doc perl -pi -e "s/\.\.//g" doc/index.html # Fixup various files echo "left_refresh=300" >> data/default_pref for f in contrib/RPM/squirrelmail.cron contrib/RPM/config.php.redhat; do perl -pi -e "s|__ATTDIR__|%{_localstatedir}/spool/squirrelmail/attach/|g;"\ -e "s|__PREFSDIR__|%{_localstatedir}/lib/squirrelmail/prefs/|g;" $f done # Fix the version %{__perl} -pi -e "s|^(\s*\\\$version\s*=\s*'[^']+)'|\1-%{release}'|g"\ functions/strings.php # replace splash screen %if %{fedora_splash} cp %{SOURCE2} images/sm_logo.png %else cp %{SOURCE3} images/sm_logo.png %endif %install rm -rf $RPM_BUILD_ROOT mkdir -p -m0755 $RPM_BUILD_ROOT%{_sysconfdir}/squirrelmail mkdir -p -m0755 $RPM_BUILD_ROOT%{_localstatedir}/lib/squirrelmail/prefs mkdir -p -m0755 $RPM_BUILD_ROOT%{_localstatedir}/spool/squirrelmail/attach mkdir -p -m0755 $RPM_BUILD_ROOT%{_datadir}/squirrelmail mkdir -p -m0755 $RPM_BUILD_ROOT%{contentdir}/html mkdir -p -m0755 $RPM_BUILD_ROOT%{_sysconfdir}/cron.daily # install default_pref install -m 0644 data/default_pref \ $RPM_BUILD_ROOT%{_sysconfdir}/squirrelmail/ ln -s ../../../..%{_sysconfdir}/squirrelmail/default_pref \ $RPM_BUILD_ROOT%{_localstatedir}/lib/squirrelmail/prefs/default_pref # install the config files mkdir -p -m0755 $RPM_BUILD_ROOT%{_datadir}/squirrelmail/config install -m 0644 config/*.php $RPM_BUILD_ROOT%{_datadir}/squirrelmail/config/ rm -f $RPM_BUILD_ROOT%{_datadir}/squirrelmail/config/config_local.php install -m 0644 config/config_local.php \ $RPM_BUILD_ROOT%{_sysconfdir}/squirrelmail/config_local.php ln -s ../../../..%{_sysconfdir}/squirrelmail/config_local.php \ $RPM_BUILD_ROOT%{_datadir}/squirrelmail/config/config_local.php install -m 0644 contrib/RPM/config.php.redhat \ $RPM_BUILD_ROOT%{_sysconfdir}/squirrelmail/config.php ln -s ../../../..%{_sysconfdir}/squirrelmail/config.php \ $RPM_BUILD_ROOT%{_datadir}/squirrelmail/config/config.php install -m 0755 config/*.pl $RPM_BUILD_ROOT%{_datadir}/squirrelmail/config/ # set default_folder_prefix to be dovecot compatible echo -e "\n\$default_folder_prefix = '';" >> $RPM_BUILD_ROOT%{_sysconfdir}/squirrelmail/config_local.php # install index.php install -m 0644 index.php $RPM_BUILD_ROOT%{_datadir}/squirrelmail/ # copy over the rest for d in class functions help images include locale plugins src themes; do cp -rp $d $RPM_BUILD_ROOT%{_datadir}/squirrelmail/ done # install the cron script install -m 0755 contrib/RPM/squirrelmail.cron \ $RPM_BUILD_ROOT/%{_sysconfdir}/cron.daily/ # install the config file mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/httpd/conf.d install -m 644 $RPM_SOURCE_DIR/squirrelmail.conf \ $RPM_BUILD_ROOT%{_sysconfdir}/httpd/conf.d/ # install locales mkdir locale_tempdir cd locale_tempdir tar xfj %SOURCE4 cd squirrelmail.locales # Convert all locales to utf-8. Not only is this probably the right thing # to do anyway, but SquirrelMail will corrupt charsets unless the charset # of the user's locale is a superset of the charset of any mail they reply to # https://sf.net/tracker/?func=detail&atid=423691&aid=1235345&group_id=311 for LOCALE in `ls locale/` ; do case $LOCALE in ja_JP) # ja_JP uses iso2022-jp for email but euc-jp in its interface. CHARSET=euc-jp ;; ko_KR) # Not really, but I can't work out what charset the ko_KR help # files are in, so we'll just leave it alone for now. CHARSET=utf-8 ;; *) CHARSET=`grep CHARSET locale/$LOCALE/setup.php | cut -f6 -d\'` ;; esac # Check for locales where CHARSET isn't in LOCALE. grep LOCALE locale/$LOCALE/setup.php | grep -vi $CHARSET || : if [ "$CHARSET" != "utf-8" -a "$CHARSET" != "UTF-8" ]; then for a in `ls help/$LOCALE/ 2>/dev/null` ; do iconv -f $CHARSET -t utf-8 help/$LOCALE/$a > $a.new && mv $a.new help/$LOCALE/$a done sed -e "s/CHARSET..[ ]*= [^;]*;/CHARSET'] = 'utf-8';/" \ -e "s/LOCALE..[ ]*= [^;]*;/LOCALE'] = '$LOCALE.UTF-8';/" \ locale/$LOCALE/setup.php > setup.php.new ; mv setup.php.new locale/$LOCALE/setup.php fi done # do the pofiles separately since they each specify their own charset for POFILE in `find locale -name \*.po` ; do CHARSET=`grep charset= $POFILE | cut -f2 -d= | cut -f1 -d\\\\` if [ "$CHARSET" != "utf-8" -a "$CHARSET" != "UTF-8" ]; then sed s/charset=$CHARSET/charset=utf-8/ $POFILE | iconv -f $CHARSET -t utf-8 > $POFILE.new && mv $POFILE.new $POFILE fi done ./compilelocales #find -name '*.mo' |xargs rm cp -r locale/* $RPM_BUILD_ROOT%{_datadir}/squirrelmail/locale/ cp -r images/* $RPM_BUILD_ROOT%{_datadir}/squirrelmail/images/ cp -r help/* $RPM_BUILD_ROOT%{_datadir}/squirrelmail/help/ cd ../.. rm $RPM_BUILD_ROOT%{_datadir}/squirrelmail/locale/README.locales %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root) %config %dir %{_sysconfdir}/squirrelmail %attr(640,root,apache) %config(noreplace) %{_sysconfdir}/squirrelmail/*.php %attr(640,root,apache) %config(noreplace) %{_sysconfdir}/squirrelmail/default_pref %config(noreplace) %{_sysconfdir}/httpd/conf.d/*.conf %doc doc/* %dir %{_datadir}/squirrelmail %dir %{_localstatedir}/lib/squirrelmail %dir %{_localstatedir}/spool/squirrelmail %{_datadir}/squirrelmail/class %{_datadir}/squirrelmail/config %{_datadir}/squirrelmail/functions %{_datadir}/squirrelmail/help %{_datadir}/squirrelmail/images %{_datadir}/squirrelmail/include %{_datadir}/squirrelmail/locale %{_datadir}/squirrelmail/plugins %{_datadir}/squirrelmail/src %{_datadir}/squirrelmail/themes %{_datadir}/squirrelmail/index.php %attr(0700, apache, apache) %dir %{_localstatedir}/lib/squirrelmail/prefs %attr(0700, apache, apache) %dir %{_localstatedir}/spool/squirrelmail/attach %{_localstatedir}/lib/squirrelmail/prefs/default_pref %{_sysconfdir}/cron.daily/squirrelmail.cron %changelog * Mon Sep 12 2005 David Woodhouse 1.4.6-0.cvs20050812.2 - Convert all locales to UTF-8 instead of legacy character sets to work around bug #162852. Except for ko_KR, because iconv doesn't believe its help files are actually in EUC-KR as claimed. * Sun Aug 14 2005 Warren Togami 1.4.6-0.cvs20050812.1 - snapshot of 1.4.6 because 1.4.5 upstream was a bad release this hopefully will also work on PHP5 too... * Mon Jun 20 2005 Warren Togami 1.4.5-0.rc1 - 1.4.5-0.rc1 * Thu Jan 27 2005 Warren Togami 1.4.4-2 - 1.4.4 - re-include translations and Provide squirrelmail-i18n better compatible with upstream, but we cannot split sub-package due to support of existing distributions - remove unnecessary .po files * Fri Nov 19 2004 Warren Togami 1.4.3a-7 - CAN-2004-1036 Cross Site Scripting in encoded text - #112769 updated splash screens * Thu Oct 14 2004 Warren Togami 1.4.3a-5 - default_folder_prefix dovecot compatible by default /etc/squirrelmail/config_local.php if you must change it * Wed Oct 13 2004 Warren Togami 1.4.3a-4 - HIGASHIYAMA Masato's patch to improve Japanese support (coordinated by Scott A. Hughes). - real 1.4.3a tarball * Tue Sep 21 2004 Gary Benson 1.4.3-3 - rebuilt. * 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. * Mon Jun 7 2004 Gary Benson 1.4.3-1 - upgrade to 1.4.3a. - retain stuff after version when adding release to it. * Wed Jun 2 2004 Gary Benson - upgrade to 1.4.3. * Fri Feb 13 2004 Elliot Lee - rebuilt. * Wed Jan 21 2004 Gary Benson 1.4.2-2 - fix calendar plugin breakage (#113902). * Thu Jan 8 2004 Gary Benson 1.4.2-1 - upgrade to 1.4.2. - tighten up permissions on /etc/squirrelmail/config.php (#112774). * Mon May 12 2003 Gary Benson 1.4.0-1 - upgrade to 1.4.0. - fix links in /usr/share/doc/squirrelmail-X.Y.Z/index.html (#90269). * Mon Mar 24 2003 Gary Benson 1.2.11-1 - upgrade to 1.2.11 to fix CAN-2003-0160. * Mon Feb 10 2003 Gary Benson 1.2.10-4 - fix syntax error in download.php (#82600). - resized splash screen to be the same size as the one it replaces (#82790) - remove piece of squirrelmail-1.2.10-xss.patch that changed the version from '1.2.10' to '1.2.11 [cvs]' * Wed Jan 22 2003 Tim Powers 1.2.10-3 - rebuilt * Wed Jan 15 2003 Tim Powers 1.2.10-2 - bump and rebuild * Mon Dec 9 2002 Gary Benson 1.2.10-1 - patch to fix CAN-2002-1341 (#78982) and CAN-2002-1276 (#79147). * Tue Dec 03 2002 Elliot Lee 1.2.8-2 - fix prep macro in changelog * Fri Sep 20 2002 Gary Benson 1.2.8-1 - upgrade to 1.2.8 to fix CAN-2002-1131 and CAN-2002-1132 (#74313) * Tue Aug 6 2002 Preston Brown 1.2.7-4 - replacement splash screen. * Mon Jul 22 2002 Gary Benson 1.2.7-3 - get rid of long lines in the specfile. - remove symlink in docroot and use an alias in conf.d instead. - work with register_globals off (#68669) * Tue Jul 09 2002 Gary Benson 1.2.7-2 - hardwire the hostname (well, localhost) into the config file (#67635) * Mon Jun 24 2002 Gary Benson 1.2.7-1 - hardwire the locations into the config file and cron file. - install squirrelmail-cleanup.cron as squirrelmail.cron. - make symlinks relative. - upgrade to 1.2.7. - more dependency fixes. * Fri Jun 21 2002 Gary Benson - summarize the summary, fix deps, and remove some redundant stuff. - tidy up the prep section. - replace directory definitions with standard RHL ones. * Fri Jun 21 2002 Tim Powers 1.2.6-3 - automated rebuild * Wed Jun 19 2002 Preston Brown 1.2.6-2 - adopted Konstantin Riabitsev 's package for Red Hat Linux. Nice job Konstantin! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Thu Oct 27 13:19:49 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 27 Oct 2005 15:19:49 +0200 Subject: [SM-I18N] UTF-8 & imap folder name handling In-Reply-To: <34845.217.77.18.193.1130417709.squirrel@internet.eik.lt> References: <1130416681.32348.34.camel@rousalka.dyndns.org> <34845.217.77.18.193.1130417709.squirrel@internet.eik.lt> Message-ID: <1130419190.7578.1.camel@rousalka.dyndns.org> Le jeudi 27 octobre 2005 ? 15:55 +0300, Tomas Kuliavas a ?crit : > > Unfortunately this fix has unearthed a problem with squirrelmail > > handling of imap folders. squirrelmail seems to assume 7bit imap folder > > names, as soon as you try do display a folder name that use >7bit > > characters in an UTF-8 locale things break (it doesn't with 8bit iso > > locales, probably because so many bits assume iso-8859-1 transcoding > > problems cancel one another). > 1. Enable mbstring support in Fedora PHP package. > > SquirrelMail utf7 imap functions use php mbstring extension to convert > from iso-8859-x and utf8 to utf7-imap. If mbstring extension is not > present, interface reverts to simple iso-8859-1 conversion. Thanks for the info. With mbstring installed everything seems to work now. Perhaps a warning in configtest if mbstring is not present would be a good idea ? Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From benjamin at pythagoras.no-ip.org Thu Oct 27 21:52:07 2005 From: benjamin at pythagoras.no-ip.org (Benjamin Donnachie) Date: Thu, 27 Oct 2005 22:52:07 +0100 Subject: Pam changes. Message-ID: <43614C07.8010405@pythagoras.no-ip.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd be grateful if someone could please advise me what's changed in PAM - - yum automatically updated it this morning and in the process broke mod_pam_auth and php_auth: Oct 27 05:52:37 Updated: pam.i386 0.77-66.2.13 Oct 27 05:52:37 Updated: pam-devel.i386 0.77-66.2.13 Previously both mod_pam_auth and php_auth worked fine with /etc/shadow set to read by root only. In order to get them working again I've had to change the shadow file's group to apache and give it read access. Naturally, I don't feel very comfortable with this and am considering changing back to the previous version of PAM. Many thanks, Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ2FMBegNmph0Y1E2AQIm7g//ZONzC6sVykWGe0o6mg8XCmxbje2Mc28G bNnwDpd1PLxU7bl7oGx6U7Cy7tGQaxb60E7tgzNN3VDaVIs5tlVlmc1CumrlGIyR eWSOxl8HpnANQecjkdQs0jG0FfmI9hU5Pyrq73nlAYuw+OD3sPptwpF0xEJVrO6z yOLl87QgDPAffaCoDvxV+xu4rqaj7Q5A9EccGXkcTEGG/OoJaCAcTgXp3gpyjyq5 Jy8CtpMWq3GFh5we2mszOu06lTh1I141/sLL0FkVcB3jpzs7kkleN3N8ODKguw8R FzMxB1jTb+681ML+OMIDHmpRvto5ecZFYzsKi3WG6gw3mkIFpZsKxuBrcMV9YeJc FH1U2yfganTM2p1uHDoy/rsGOGjAasnVzInjJxN91viPB4hY47LyULB2arvJalAP 4NOHK2IlA29Uw0eEbPa9su979+Ipy4ZrupkhfKyb8ZEPe3HNAQeAYHaeEKWr8hpn 79ZcaG3/xLZxGNULNh8Ru0pqK3QnKZ2x3VgBQT+AXEfEb0HX3d/fKhWlwDuCXJgZ WuJIEXMWDUE0r1E6JRHyqQcODJtMW2EZlzGeaMtcxVZUUPoOX5bQYZgsdYmcX4Uz molVtBMEC2wKDZhYbLKtYMVSZhVqLes7o45ucITBw3NMffwj8JO7slevh5VM9ti/ HjLZpNQ04tY= =Hzvp -----END PGP SIGNATURE----- From benjamin at pythagoras.no-ip.org Thu Oct 27 21:53:28 2005 From: benjamin at pythagoras.no-ip.org (Benjamin Donnachie) Date: Thu, 27 Oct 2005 22:53:28 +0100 Subject: Pam changes. In-Reply-To: <43614C07.8010405@pythagoras.no-ip.org> References: <43614C07.8010405@pythagoras.no-ip.org> Message-ID: <43614C58.6060906@pythagoras.no-ip.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benjamin Donnachie wrote: > I'd be grateful if someone could please advise me what's changed in PAM > - yum automatically updated it this morning and in the process broke > mod_pam_auth and php_auth: > > Oct 27 05:52:37 Updated: pam.i386 0.77-66.2.13 > Oct 27 05:52:37 Updated: pam-devel.i386 0.77-66.2.13 D'oh! I forget to mention that I'm using FC3. Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ2FMVugNmph0Y1E2AQIqpg//U+95C64pUn0zu/xfiNV/hRmBXXDRGtOP wHn8HbnznB0FQAwtMdXADnlp/1/c1aO0KjUKRs9ZaPBLag51qNYZ+2kl/UpN9Bin bUhMFsRtBp3HOkA9G46ieyNr9Sp9atW45yd0zIKBb0hD6wPAAg+W2VnC9xGLoshp yeQx3GxJnWLSH4WO+GetysOzktMsWazV7DBojxe5qplO9j9dKu2FLIY4GpPXVpHw hcTmuvBSZ5CBmoB1xyeYG4Vyg8H2AFaWpyqoL25wZ9EGKb0ElQZBpkSu9VHkEEmI HncULkVA3qLCT3mJ1TSRgy7sgcp9vOd329seJ5sggPwI73TdEt1l+dtY4ZrcR4ct nEXtm3QCOXNjMjppFd5HSetjFVQvAB4pXd7YK25ZgPD1SbbRpXKD1n6o/N30Apqf HLgM0o6Ic1dkT0n02Of2rZcTek6HYXUZGDPYn5gAyNmuSXJEUYvkbIwFIZgw6xXM M01xQBgP1hGvKYwg3aLLKJSEkAAGLzi/Eqb+Lua4sQ+sRLnEFhiNWwj60FZtG+Az rgCAl5FBoNjz14hUO3DOBX7y+/Zx4CwML40maVKQJOSp8nmqDrwczwMV1d3mcQM4 6ICXKJF7fPfQYZjPkw0c/l7EgRK1YlZGBYx+4Fl/MlZu+i2JODcK7wTiTajqRv/6 2xxQhXgGIOg= =P1kK -----END PGP SIGNATURE----- From benjamin at pythagoras.no-ip.org Thu Oct 27 22:04:07 2005 From: benjamin at pythagoras.no-ip.org (Benjamin Donnachie) Date: Thu, 27 Oct 2005 23:04:07 +0100 Subject: Pam changes. In-Reply-To: <43614C58.6060906@pythagoras.no-ip.org> References: <43614C07.8010405@pythagoras.no-ip.org> <43614C58.6060906@pythagoras.no-ip.org> Message-ID: <43614ED7.9040104@pythagoras.no-ip.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benjamin Donnachie wrote: >>>I'd be grateful if someone could please advise me what's changed in PAM >>>- yum automatically updated it this morning and in the process broke >>>mod_pam_auth and php_auth: Not to worry - I finally found this... http://fedoranews.org/blog/?p=937 Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ2FO1ugNmph0Y1E2AQIAcw/+IzJHKzNt2ICs5eoUz66sPXjOws9E29nH HI/pgO5P6JJcAaCsiXCq+ItAsrE2CAgaLNchIUNOSpXi/ISJGSvJOU3n14aN55b/ eAV4lv3NVQ+h/KdZuqRqH4bfbBvpNbKJm7oy//cCVJHwQIRN30Re3t1YHHabB+nb gZr/d0+wt3vwVWMvxEfUI7O4hJGUN7lf4Wc/R+5V0dEi9v3PyMX99ck7mnXyfQAc ShEh9vOZdRSfubPAo5lMrYn4P4C+GExuum5ZZL5OQKiG77OPzlwluUjiKqBf3Hrt BO4b/KChZe+cEa46fOTgEqCO5VO1z6Lb6psDN2OlP5zQEUXyROr/An9l9GHAQtob 5NkFT+XovHHXUanbXaSBNR7sfPXCTAKfz7SVDI5WKdg0vSZPA7yNm8sJtpLs81ii 6GeGaNh8lmErQx5TKjHcHlHyi267k52bZaVJSBwI8JFcv07GaDaVN8Ned0eMiROA P/Y4QMqbmrO8fAodHTbwWvCNfmjnrbppHaCbAIcrh+jCFLIx4BsygYe1o+f4G3W1 EiLO9BUjlgkmo1N2ebySyIn6GBadmQ3EYNltovGOYw/TNQvYvWwRl3yRwzdQ9LBH hsHCOBr0MFa1Ft73Q1IY7mg+dH08vxcMhg29SMVILjdyUnV+R5F9fdjuGGAcOenA oHiVhp3HhlA= =wcZm -----END PGP SIGNATURE----- From rodd at clarkson.id.au Fri Oct 28 04:28:58 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 28 Oct 2005 14:28:58 +1000 Subject: rawhide report: 20051025 changes In-Reply-To: <1130273221.2799.2.camel@localhost.localdomain> References: <200510251136.j9PBaJAO001084@porkchop.devel.redhat.com> <1130273221.2799.2.camel@localhost.localdomain> Message-ID: <1130473738.3020.24.camel@localhost.localdomain> On Wed, 2005-10-26 at 06:47 +1000, Rodd Clarkson wrote: > Installing: > kernel i686 2.6.13-1.1626_FC5 development 15 M > kernel-devel i686 2.6.13-1.1626_FC5 development 4.1 M Something in this kernel (and ongoing) is seeing Network Manager loosing the connection (after a period of not using my system) and not able to get the connection back again by just picking the wireless node. If I restart NetworkManager then it works again until for a while. Here's a list of the offending kernels. kernel-2.6.13-1.1626_FC5 kernel-2.6.13-1.1627_FC5 kernel-2.6.13-1.1629_FC5 Going back to using kernel-2.6.13-1.1624_FC5 see's NetworkManager maintaining the connection. Anyone else noticed this? What other information do I need to provide? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From arjanv at redhat.com Fri Oct 28 07:08:52 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 28 Oct 2005 09:08:52 +0200 Subject: rawhide report: 20051027 changes In-Reply-To: References: <200510271144.j9RBiHtK022297@porkchop.devel.redhat.com> Message-ID: <1130483333.2800.8.camel@laptopd505.fenrus.org> > > kernel-xen-2.6.12-1.7_FC5 > ------------------------- > * Wed Oct 26 2005 Arjan van de Ven < arjanv at redhat.com> > - resync with mercurial xen in the hope to fix some remaining > instabilities > > Any x86_64 xen kernels down the road? that's not in the plans currently. This kernel is just there as a minimal effort so that the installer folks can work on their part of xen work. They are by no means intended for other things, and might not be usable either.... From arjanv at redhat.com Fri Oct 28 07:08:52 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 28 Oct 2005 09:08:52 +0200 Subject: rawhide report: 20051027 changes In-Reply-To: References: <200510271144.j9RBiHtK022297@porkchop.devel.redhat.com> Message-ID: <1130483333.2800.8.camel@laptopd505.fenrus.org> > > kernel-xen-2.6.12-1.7_FC5 > ------------------------- > * Wed Oct 26 2005 Arjan van de Ven < arjanv at redhat.com> > - resync with mercurial xen in the hope to fix some remaining > instabilities > > Any x86_64 xen kernels down the road? that's not in the plans currently. This kernel is just there as a minimal effort so that the installer folks can work on their part of xen work. They are by no means intended for other things, and might not be usable either.... -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From buildsys at redhat.com Fri Oct 28 11:45:11 2005 From: buildsys at redhat.com (Build System) Date: Fri, 28 Oct 2005 07:45:11 -0400 Subject: rawhide report: 20051028 changes Message-ID: <200510281145.j9SBjBMa021065@porkchop.devel.redhat.com> Updated Packages: anaconda-10.89.5-1 ------------------ * Thu Oct 27 2005 Jeremy Katz - 10.89.5-1 - Another fix for kickstart + help hiding - Fix finding of kernel type - Make synaptics device nodes before X starts (clumens) - Use nofb by default - Add pycairo stuff (clumens) - Set minimum displayed log level to WARNING, everything is still in the logfiles (clumens) - Try to clean up syslog (clumens) - Allow installation of hypervisor + xen host kernel by booing with 'xen0' on the installer command line - Fix x86_64 traceback booty-0.58-1 ------------ * Thu Oct 27 2005 Jeremy Katz - 0.58-1 - quick version of getting xen dom0 kernel setup properly in grub.conf eclipse-pydev-1:0.9.3_fc-12 --------------------------- * Thu Oct 27 2005 Andrew Overholt 0.9.3_fc-12 - Re-build. gamin-0.1.7-1 ------------- * Thu Oct 27 2005 Daniel Veillard 0.1.7-1 - hopefully fixes gam_server crashes - some portability fixes - removed a minor leak * Thu Sep 08 2005 Daniel Veillard 0.1.6-1 - revamp of the inotify back-end - memory leak fix - various fixes and cleanups * Tue Aug 09 2005 Daniel Veillard 0.1.5-1 - Improvement of configuration, system wide configuration files and per filesystem type default - Rewrite of the inotify back-end, reduce resources usage, tuning in case of busy resources - Documentation updates - Changes to compile inotify back-end on various architectures - Debugging output improvements grub-0.95-16 ------------ * Mon Aug 01 2005 Peter Jones - 0.95-16 - minor fix to the --recheck fix. joram-0:4.1.5-1jpp_6fc ---------------------- * Thu Oct 27 2005 Gary Benson 0:4.1.5-1jpp_6fc - Reinstate a deleted class to fix JOnAS tests. kernel-2.6.14-1.1632_FC5 ------------------------ * Thu Oct 27 2005 Dave Jones - 2.6.14 * Thu Oct 27 2005 Dave Jones - 2.6.14-rc5-git7 kernel-xen-2.6.12-1.8_FC5 ------------------------- libselinux-1.27.17-1 -------------------- * Wed Oct 26 2005 Dan Walsh 1.27.17-1 - Change default to __default__ * Wed Oct 26 2005 Dan Walsh 1.27.14-3 - Change default to __default__ * Tue Oct 25 2005 Dan Walsh 1.27.14-2 - Add selinux_translations_path mod_perl-2.0.2-2 ---------------- * Wed Oct 26 2005 Joe Orton 2.0.2-2 - update to 2.0.2 mutt-5:1.4.2.1-5 ---------------- * Thu Oct 27 2005 Bill Nottingham 5:1.4.2.1-5 - add patch from 1.5 branch to fix SASL logging (#157251, #171528) * Fri Aug 26 2005 Bill Nottingham 5:1.4.2.1-3 - add patch from 1.5 branch to fix base64 decoding (#166718) * Mon Mar 07 2005 Bill Nottingham 5:1.4.2.1-2 - rebuild against new openssl - fix build with gcc4 nss_ldap-244-1 -------------- * Thu Oct 27 2005 Nalin Dahyabhai 244-1 - update to nss_ldap 244 qt-1:3.3.5-7 ------------ * Tue Oct 25 2005 Than Ngo 1:3.3.5-7 - update qt-x11-immodule-unified-qt3.3.5-20051012-quiet.patch * Mon Oct 24 2005 Than Ngo 1:3.3.5-6 - update qt-x11-immodule-unified-qt3.3.5-20051018.diff - remove unneeded qt-x11-immodule-unified-qt3.3.5-20051012-build.patch * Thu Oct 13 2005 Than Ngo 1:3.3.5-5 - update qt-x11-immodule-unified-qt3.3.5-20051012 - disable some debug messages - apply patch to fix build problem with the new immodule patch selinux-policy-mls-1.27.2-7 --------------------------- * Wed Oct 26 2005 Dan Walsh 1.27.2-7 - Allow spamd to resolve * Wed Oct 26 2005 Dan Walsh 1.27.2-6 - Allow restorecon access to devpts on targetd machines - Fix setrans.conf on strict policy selinux-policy-strict-1.27.2-7 ------------------------------ * Wed Oct 26 2005 Dan Walsh 1.27.2-7 - Allow spamd to resolve * Wed Oct 26 2005 Dan Walsh 1.27.2-6 - Allow restorecon access to devpts on targetd machines - Fix setrans.conf on strict policy selinux-policy-targeted-1.27.2-7 -------------------------------- * Wed Oct 26 2005 Dan Walsh 1.27.2-7 - Allow spamd to resolve * Wed Oct 26 2005 Dan Walsh 1.27.2-6 - Allow restorecon access to devpts on targetd machines - Fix setrans.conf on strict policy system-config-securitylevel-1.6.6-1 ----------------------------------- * Thu Oct 27 2005 Chris Lumens 1.6.6-1 - Add explanatory text to firewall and SELinux firstboot modules (#171022). - Fix a grammar error in lokkit help text (#152273). - Mark name in .desktop file for translation (#171819). - Remove support for modifying tunables since policy source will be disappearing in the future (#160896). From gilboada at netvision.net.il Fri Oct 28 14:33:12 2005 From: gilboada at netvision.net.il (Gilboa Davara) Date: Fri, 28 Oct 2005 16:33:12 +0200 Subject: rawhide report: 20051027 changes In-Reply-To: <1130483333.2800.8.camel@laptopd505.fenrus.org> References: <200510271144.j9RBiHtK022297@porkchop.devel.redhat.com> <1130483333.2800.8.camel@laptopd505.fenrus.org> Message-ID: <1130509992.4345.2.camel@gilboa-home-dev.localhost> Is x86-64 support (which, AFAIK, is a part of Xen 3.0) is planned for FC5 release? Gilboa On Fri, 2005-10-28 at 09:08 +0200, Arjan van de Ven wrote: > > > > kernel-xen-2.6.12-1.7_FC5 > > ------------------------- > > * Wed Oct 26 2005 Arjan van de Ven < arjanv at redhat.com> > > - resync with mercurial xen in the hope to fix some remaining > > instabilities > > > > Any x86_64 xen kernels down the road? > > that's not in the plans currently. > This kernel is just there as a minimal effort so that the installer > folks can work on their part of xen work. They are by no means intended > for other things, and might not be usable either.... > > > -- > fedora-test-list mailing list > fedora-test-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-test-list > From buildsys at redhat.com Sat Oct 29 11:25:21 2005 From: buildsys at redhat.com (Build System) Date: Sat, 29 Oct 2005 07:25:21 -0400 Subject: rawhide report: 20051029 changes Message-ID: <200510291125.j9TBPLM3003235@porkchop.devel.redhat.com> Updated Packages: anaconda-10.89.6-1 ------------------ * Fri Oct 28 2005 Jeremy Katz - 10.89.6-1 - Make char devices slightly later to avoid tracebacks during tree compose - Extract kernel-xen-guest for vmlinuz and initrd in images/xen - Kickstart fix (clumens) - Add some support for xen xvd blockdevs - Select kernel-xen-guest as appropriate - Ensure proper arch of glibc is selected (#171997) - Select all proper multilib parts of a package (#171026) avahi-0.5.2-3 ------------- booty-0.59-1 ------------ * Fri Oct 28 2005 Jeremy Katz - 0.59-1 - support serial console for xen cdrtools-8:2.01.1-11 -------------------- * Wed Sep 28 2005 Harald Hoyer 8:2.01.1-11 - fixed isoinfo #167437 - fixed rscsi debug #152462 checkpolicy-1.27.17-2 --------------------- * Tue Oct 25 2005 Dan Walsh 1.27.17-2 - Rebuild to get latest libsepol coreutils-5.92-1 ---------------- * Fri Oct 28 2005 Tim Waugh 5.92-1 - Finished porting i18n patch to sort.c. - Fixed for sort-mb-tests (avoid +n syntax). * Fri Oct 28 2005 Tim Waugh 5.92-0.2 - Fix chgrp basic test. - Include md5sum patch from ALT. * Mon Oct 24 2005 Tim Waugh 5.92-0.1 - 5.92. - No longer need afs, dircolors, utmp, gcc4, brokentest, dateseconds, chown, rmaccess, copy, stale-utmp, no-sign-extend, fchown patches. - Updated acl, dateman, pam, langinfo, i18n, getgrouplist, selinux patches. - Dropped printf-ll, allow_old_options, jday, zh_CN patches. - NOTE: i18n patch not ported for sort(1) yet. firstboot-1.3.52-1 ------------------ * Fri Oct 28 2005 Chris Lumens 1.3.52-1 - Set a timeout on waiting for the window manager to start. - Correct ps output. - Move keyboard initialization to after the modules have been loaded (#133074, #157870). fonts-ISO8859-2-1.0-15 ---------------------- * Fri Oct 28 2005 Caolan McNamara - 1.0-15 - package description mentions old package name fonts-arabic-1.5-4 ------------------ * Fri Oct 28 2005 Caolan McNamara - 1.5-4 - check for existance of fc-cache kudzu-1.2.10-1 -------------- * Fri Oct 28 2005 Jeremy Katz - 1.2.10-1 - add some basic xen device probing libsemanage-1.3.38-1 -------------------- * Fri Oct 28 2005 Dan Walsh 1.3.38-1 - Upgrade to latest from NSA * Merged dbase policydb list and count change from Ivan Gyurdiev. * Merged enable dbase and set relay patches from Ivan Gyurdiev. * Thu Oct 27 2005 Dan Walsh 1.3.36-1 - Update from NSA * Merged query APIs and dbase_file_set patches from Ivan Gyurdiev. * Wed Oct 26 2005 Dan Walsh 1.3.35-1 - Update from NSA * Merged sepol handle passing, seusers support, and policydb cache patches from Ivan Gyurdiev. libsepol-1.9.33-1 ----------------- * Fri Oct 28 2005 Dan Walsh 1.9.33-1 - Upgrade to latest from NSA * Merged count specification change from Ivan Gyurdiev. nautilus-2.12.1-5 ----------------- * Fri Oct 28 2005 Matthias Clasen 2.12.1-5 - Implement icon stretching keynav - Support formatting non-floppy devices * Sat Oct 22 2005 Matthias Clasen 2.12.1-4 - Improve icon stretching ui openssh-4.2p1-5 --------------- * Fri Oct 28 2005 Tomas Mraz 4.2p1-5 - put back the possibility to skip SELinux patch - add patch for user login auditing by Steve Grubb policycoreutils-1.27.19-2 ------------------------- * Tue Oct 25 2005 Dan Walsh 1.27.19-2 - Rebuild to use latest libselinux, libsemanage, and libsepol pykickstart-0.6-1 ----------------- * Fri Oct 28 2005 Chris Lumens 0.6-1 - Add --resolvedeps and --ignoredeps as deprecated options. - Pass line number to header functions. selinux-policy-mls-1.27.2-9 --------------------------- * Fri Oct 28 2005 Dan Walsh 1.27.2-9 - Add avahi policy * Fri Oct 28 2005 Dan Walsh 1.27.2-8 - Allow spamd to rewrite ~/.spamassin file selinux-policy-strict-1.27.2-10 ------------------------------- * Fri Oct 28 2005 Dan Walsh 1.27.2-10 - Fix file_context * Fri Oct 28 2005 Dan Walsh 1.27.2-9 - Add avahi policy * Fri Oct 28 2005 Dan Walsh 1.27.2-8 - Allow spamd to rewrite ~/.spamassin file selinux-policy-targeted-1.27.2-10 --------------------------------- * Fri Oct 28 2005 Dan Walsh 1.27.2-10 - Fix file_context * Fri Oct 28 2005 Dan Walsh 1.27.2-9 - Add avahi policy * Fri Oct 28 2005 Dan Walsh 1.27.2-8 - Allow spamd to rewrite ~/.spamassin file totem-1.2.0-2 ------------- From nicolas.mailhot at laposte.net Sat Oct 29 12:23:54 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 29 Oct 2005 14:23:54 +0200 Subject: Installing RealPlayer on FC+FE devel x86_64 Message-ID: <1130588634.2796.95.camel@rousalka.dyndns.org> Hi, I've just spent some hours in deep hell trying to install RealPlayer on a Fedora Devel x86_64 box. It was a long time I haven't been in such trouble and I must say I do very well without it. So I thought it would be interesting to share what I found there : - the rpm on https://player.helixcommunity.org/ is deeply f*-up as usual, thanksfuly Rex Dieter provides a semi-sane nosrc.rpm on KDE-Redhat. You just need to adapt it a "little" to the latest Helix binary dump (see later) - usual version changes - make %setup create the root build dir - patch the realplay script so it actually sets HELIX_LIBS - remove some stuff installed but not packaged - rpm didn't want to build an i586 rpm on x86_64 -> make the build arch noarch, redefine _libdir and _lib to something sane (not lib64). This is FUGLY but I didn't find any other way to coax rpm into building. - now you've build a package that can be installed. It "just" needs a bunch of *i386* packages in FE and livna. (one step the Helix package "forgets" as it's not checking dependencies) - This is where I spent most of the time, trying to figure out why yum didn't want to pull them. Why but WHY don't livna and FE provide arch-specific mirrorlists. And WHY can't yum look up in x86_64 AND i386 when presented a generic mirrorlist. (deep anguish, wanted to murder someone when I realised that's why everything was failing). Yum ONLY searches in x86_64 when you use the default mirrorlists, you have to create separate livna and FE entries without any mirrorlist and only the i386 baseurl to make it work. This of course sucks for the root server, but at this point I was past caring about being nice. Anyway, now everything works there, I'll be stressing a bit FE & Livna i386 root servers from now on, but that's real life for you. Hope this message helps others. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Sat Oct 29 13:55:04 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 29 Oct 2005 09:55:04 -0400 Subject: Installing RealPlayer on FC+FE devel x86_64 In-Reply-To: <1130588634.2796.95.camel@rousalka.dyndns.org> References: <1130588634.2796.95.camel@rousalka.dyndns.org> Message-ID: <1130594104.7247.2.camel@cutter> > - This is where I spent most of the time, trying to figure out why yum > didn't want to pull them. Why but WHY don't livna and FE provide > arch-specific mirrorlists. And WHY can't yum look up in x86_64 AND i386 > when presented a generic mirrorlist. (deep anguish, wanted to murder > someone when I realised that's why everything was failing). Yum ONLY > searches in x86_64 when you use the default mirrorlists, you have to > create separate livna and FE entries without any mirrorlist and only the > i386 baseurl to make it work. This of course sucks for the root server, > but at this point I was past caring about being nice. > So you really think it's a good idea for yum to automatically add repositories for i386 if you're on an x86_64? People complain about their being too many i386 binaries in the x86_64 tree as is - and you think having yum default to adding more is going to be helpful? and the reason why using the mirrorlists fail is b/c the mirrorlists use the $ARCH variable which expands out to whatever your arch is on the local system. -sv From nicolas.mailhot at laposte.net Sat Oct 29 14:34:17 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 29 Oct 2005 16:34:17 +0200 Subject: Installing RealPlayer on FC+FE devel x86_64 In-Reply-To: <1130594104.7247.2.camel@cutter> References: <1130588634.2796.95.camel@rousalka.dyndns.org> <1130594104.7247.2.camel@cutter> Message-ID: <1130596458.18991.6.camel@rousalka.dyndns.org> Le samedi 29 octobre 2005 ? 09:55 -0400, seth vidal a ?crit : > > - This is where I spent most of the time, trying to figure out why yum > > didn't want to pull them. Why but WHY don't livna and FE provide > > arch-specific mirrorlists. And WHY can't yum look up in x86_64 AND i386 > > when presented a generic mirrorlist. (deep anguish, wanted to murder > > someone when I realised that's why everything was failing). Yum ONLY > > searches in x86_64 when you use the default mirrorlists, you have to > > create separate livna and FE entries without any mirrorlist and only the > > i386 baseurl to make it work. This of course sucks for the root server, > > but at this point I was past caring about being nice. > > > > So you really think it's a good idea for yum to automatically add > repositories for i386 if you're on an x86_64? People complain about > their being too many i386 binaries in the x86_64 tree as is - and you > think having yum default to adding more is going to be helpful? Much as I'd love to have a pure 64bit system today it's not possible now (which BTW is the whole point of multilib). Now if i386 is considered harmful could we at least have arch-specific mirrorlists ? Or a yum switch to activate them ? Even i386 firefox deps are not fully provided by x86_64 rawhide. > and the reason why using the mirrorlists fail is b/c the mirrorlists use > the $ARCH variable which expands out to whatever your arch is on the > local system. This is what I realised (after much pain). I doubt I'm the only one in trouble. Just the first to report it. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From zaitcev at redhat.com Sun Oct 30 02:35:44 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 29 Oct 2005 19:35:44 -0700 Subject: libusual and ub Message-ID: <20051029193544.096d400e.zaitcev@redhat.com> Hi, Dave, Jeremy, and others: I think now may be the time to enable ub in Rawhide and see if it sticks. The problem it is trying to address is to have fewer oopses and/or lockups related to the usb-storage. I have to say, I do not see all that many these days, but when they do happen, it always happens as if on purpose to break our schedule. Since ub does not support all storage devices, and never will, I developed a way for it to coexist with usb-storage. A patch called "libusual" provides the necessary routing. It is attached at the bottom of this message, and I think is necessary if we are to have ub at all. In order to reap the benefit of ub, I consider it desirable to make it default in libusual. This is, of course, risky. But if we do not do it, Anaconda will be the only user, and it's a hell to debug anything in the installation environment. I would rather have users to poke at ub without installations first, by pulling kernels with yum. To that end, the patch below defaults to ub. This is NOT how it is done upstream. Speaking of upstream, libusual is in Greg Kroah's tree, on its way to AKPM, and is pretty far from Linus tree. Fedora is to test it ahead of time, in my plan. I would like to ask if you guys are good with it. We are in Rawhide, and just coming up to Test 1, after all. I reckoned it appropriate to give a kind of technology preview. -- Pete diff -urpN -X dontdiff linux-2.6.14/drivers/block/Kconfig linux-2.6.14-lem/drivers/block/Kconfig --- linux-2.6.14/drivers/block/Kconfig 2005-10-28 19:11:37.000000000 -0700 +++ linux-2.6.14-lem/drivers/block/Kconfig 2005-10-28 23:10:23.000000000 -0700 @@ -358,7 +358,8 @@ config BLK_DEV_UB This driver supports certain USB attached storage devices such as flash keys. - Warning: Enabling this cripples the usb-storage driver. + If you enable this driver, it is recommended to avoid conflicts + with usb-storage by enabling USB_LIBUSUAL. If unsure, say N. diff -urpN -X dontdiff linux-2.6.14/drivers/block/ub.c linux-2.6.14-lem/drivers/block/ub.c --- linux-2.6.14/drivers/block/ub.c 2005-10-28 19:11:38.000000000 -0700 +++ linux-2.6.14-lem/drivers/block/ub.c 2005-10-28 23:10:23.000000000 -0700 @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include @@ -107,16 +108,6 @@ */ /* - * Definitions which have to be scattered once we understand the layout better. - */ - -/* Transport (despite PR in the name) */ -#define US_PR_BULK 0x50 /* bulk only */ - -/* Protocol */ -#define US_SC_SCSI 0x06 /* Transparent */ - -/* * This many LUNs per USB device. * Every one of them takes a host, see UB_MAX_HOSTS. */ @@ -422,13 +413,18 @@ static int ub_probe_lun(struct ub_dev *s /* */ +#ifdef CONFIG_USB_LIBUSUAL + +#define ub_usb_ids storage_usb_ids +#else + static struct usb_device_id ub_usb_ids[] = { - // { USB_DEVICE_VER(0x0781, 0x0002, 0x0009, 0x0009) }, /* SDDR-31 */ { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_SCSI, US_PR_BULK) }, { } }; MODULE_DEVICE_TABLE(usb, ub_usb_ids); +#endif /* CONFIG_USB_LIBUSUAL */ /* * Find me a way to identify "next free minor" for add_disk(), @@ -2172,6 +2168,9 @@ static int ub_probe(struct usb_interface int rc; int i; + if (usb_usual_check_type(dev_id, USB_US_TYPE_UB)) + return -ENXIO; + rc = -ENOMEM; if ((sc = kmalloc(sizeof(struct ub_dev), GFP_KERNEL)) == NULL) goto err_core; @@ -2479,6 +2478,7 @@ static int __init ub_init(void) if ((rc = usb_register(&ub_driver)) != 0) goto err_register; + usb_usual_set_present(USB_US_TYPE_UB); return 0; err_register: @@ -2494,6 +2494,7 @@ static void __exit ub_exit(void) devfs_remove(DEVFS_NAME); unregister_blkdev(UB_MAJOR, DRV_NAME); + usb_usual_clear_present(USB_US_TYPE_UB); } module_init(ub_init); diff -urpN -X dontdiff linux-2.6.14/drivers/usb/storage/Kconfig linux-2.6.14-lem/drivers/usb/storage/Kconfig --- linux-2.6.14/drivers/usb/storage/Kconfig 2005-10-28 19:12:03.000000000 -0700 +++ linux-2.6.14-lem/drivers/usb/storage/Kconfig 2005-10-28 23:10:23.000000000 -0700 @@ -123,3 +123,17 @@ config USB_STORAGE_ONETOUCH hard drive's as an input device. An action can be associated with this input in any keybinding software. (e.g. gnome's keyboard short- cuts) + +config USB_LIBUSUAL + bool "The shared table of common (or usual) storage devices" + depends on USB + help + This module contains a table of common (or usual) devices + for usb-storage and ub drivers, and allows to switch binding + of these devices without rebuilding modules. + + Typical syntax of /etc/modprobe.conf is: + + options libusual bias="ub" + + If unsure, say N. diff -urpN -X dontdiff linux-2.6.14/drivers/usb/storage/libusual.c linux-2.6.14-lem/drivers/usb/storage/libusual.c --- linux-2.6.14/drivers/usb/storage/libusual.c 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.14-lem/drivers/usb/storage/libusual.c 2005-10-28 23:10:23.000000000 -0700 @@ -0,0 +1,266 @@ +/* + * libusual + * + * The libusual contains the table of devices common for ub and usb-storage. + */ +#include +#include +#include +#include +#include + +/* + */ +#define USU_MOD_FL_THREAD 1 /* Thread is running */ +#define USU_MOD_FL_PRESENT 2 /* The module is loaded */ + +struct mod_status { + unsigned long fls; +}; + +static struct mod_status stat[3]; +static DEFINE_SPINLOCK(usu_lock); + +/* + */ +#define USB_US_DEFAULT_BIAS USB_US_TYPE_UB + +#define BIAS_NAME_SIZE (sizeof("usb-storage")) +static char bias[BIAS_NAME_SIZE]; +static int usb_usual_bias; +static const char *bias_names[3] = { "none", "usb-storage", "ub" }; + +static DECLARE_MUTEX_LOCKED(usu_init_notify); +static DECLARE_COMPLETION(usu_end_notify); +static atomic_t total_threads = ATOMIC_INIT(0); + +static int usu_probe_thread(void *arg); +static int parse_bias(const char *bias_s); + +/* + * The table. + */ +#define UNUSUAL_DEV(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, \ + vendorName, productName,useProtocol, useTransport, \ + initFunction, flags) \ +{ USB_DEVICE_VER(id_vendor, id_product, bcdDeviceMin,bcdDeviceMax), \ + .driver_info = (flags)|(USB_US_TYPE_STOR<<24) } + +#define USUAL_DEV(useProto, useTrans, useType) \ +{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, useProto, useTrans), \ + .driver_info = ((useType)<<24) } + +struct usb_device_id storage_usb_ids [] = { +# include "unusual_devs.h" + { } /* Terminating entry */ +}; + +#undef USUAL_DEV +#undef UNUSUAL_DEV + +MODULE_DEVICE_TABLE(usb, storage_usb_ids); +EXPORT_SYMBOL(storage_usb_ids); + +/* + * @type: the module type as an integer + */ +void usb_usual_set_present(int type) +{ + struct mod_status *st; + unsigned long flags; + + if (type <= 0 || type >= 3) + return; + st = &stat[type]; + spin_lock_irqsave(&usu_lock, flags); + st->fls |= USU_MOD_FL_PRESENT; + spin_unlock_irqrestore(&usu_lock, flags); +} +EXPORT_SYMBOL(usb_usual_set_present); + +void usb_usual_clear_present(int type) +{ + struct mod_status *st; + unsigned long flags; + + if (type <= 0 || type >= 3) + return; + st = &stat[type]; + spin_lock_irqsave(&usu_lock, flags); + st->fls &= ~USU_MOD_FL_PRESENT; + spin_unlock_irqrestore(&usu_lock, flags); +} +EXPORT_SYMBOL(usb_usual_clear_present); + +/* + * Match the calling driver type against the table. + * Returns: 0 if the device matches. + */ +int usb_usual_check_type(const struct usb_device_id *id, int caller_type) +{ + int id_type = USB_US_TYPE(id->driver_info); + + if (caller_type <= 0 || caller_type >= 3) + return -EINVAL; + + /* Drivers grab fixed assignment devices */ + if (id_type == caller_type) + return 0; + /* Drivers grab devices biased to them */ + if (id_type == USB_US_TYPE_NONE && caller_type == usb_usual_bias) + return 0; + return -ENODEV; +} +EXPORT_SYMBOL(usb_usual_check_type); + +/* + */ +static int usu_probe(struct usb_interface *intf, + const struct usb_device_id *id) +{ + int type; + int rc; + unsigned long flags; + + type = USB_US_TYPE(id->driver_info); + if (type == 0) + type = usb_usual_bias; + + spin_lock_irqsave(&usu_lock, flags); + if ((stat[type].fls & (USU_MOD_FL_THREAD|USU_MOD_FL_PRESENT)) != 0) { + spin_unlock_irqrestore(&usu_lock, flags); + return -ENXIO; + } + stat[type].fls |= USU_MOD_FL_THREAD; + spin_unlock_irqrestore(&usu_lock, flags); + + rc = kernel_thread(usu_probe_thread, (void*)type, CLONE_VM); + if (rc < 0) { + printk(KERN_WARNING "libusual: " + "Unable to start the thread for %s: %d\n", + bias_names[type], rc); + spin_lock_irqsave(&usu_lock, flags); + stat[type].fls &= ~USU_MOD_FL_THREAD; + spin_unlock_irqrestore(&usu_lock, flags); + return rc; /* Not being -ENXIO causes a message printed */ + } + atomic_inc(&total_threads); + + return -ENXIO; +} + +static void usu_disconnect(struct usb_interface *intf) +{ + ; /* We should not be here. */ +} + +static struct usb_driver usu_driver = { + .owner = THIS_MODULE, + .name = "libusual", + .probe = usu_probe, + .disconnect = usu_disconnect, + .id_table = storage_usb_ids, +}; + +/* + * A whole new thread for a purpose of request_module seems quite stupid. + * The request_module forks once inside again. However, if we attempt + * to load a storage module from our own modprobe thread, that module + * references our symbols, which cannot be resolved until our module is + * initialized. I wish there was a way to wait for the end of initialization. + * The module notifier reports MODULE_STATE_COMING only. + * So, we wait until module->init ends as the next best thing. + */ +static int usu_probe_thread(void *arg) +{ + int type = (unsigned long) arg; + struct mod_status *st = &stat[type]; + int rc; + unsigned long flags; + + daemonize("libusual_%d", type); /* "usb-storage" is kinda too long */ + + /* A completion does not work here because it's counted. */ + down(&usu_init_notify); + up(&usu_init_notify); + + rc = request_module(bias_names[type]); + spin_lock_irqsave(&usu_lock, flags); + if (rc == 0 && (st->fls & USU_MOD_FL_PRESENT) == 0) { + /* + * This should not happen, but let us keep tabs on it. + */ + printk(KERN_NOTICE "libusual: " + "modprobe for %s succeeded, but module is not present\n", + bias_names[type]); + } + st->fls &= ~USU_MOD_FL_THREAD; + spin_unlock_irqrestore(&usu_lock, flags); + + complete_and_exit(&usu_end_notify, 0); +} + +/* + */ +static int __init usb_usual_init(void) +{ + int rc; + + bias[BIAS_NAME_SIZE-1] = 0; + usb_usual_bias = parse_bias(bias); + + rc = usb_register(&usu_driver); + up(&usu_init_notify); + return rc; +} + +static void __exit usb_usual_exit(void) +{ + /* + * We do not check for any drivers present, because + * they keep us pinned with symbol references. + */ + + usb_deregister(&usu_driver); + + while (atomic_read(&total_threads) > 0) { + wait_for_completion(&usu_end_notify); + atomic_dec(&total_threads); + } +} + +/* + * Validate and accept the bias parameter. + * Maybe make an sysfs method later. XXX + */ +static int parse_bias(const char *bias_s) +{ + int i; + int bias_n = 0; + + if (bias_s[0] == 0 || bias_s[0] == ' ') { + bias_n = USB_US_DEFAULT_BIAS; + } else { + for (i = 1; i < 3; i++) { + if (strcmp(bias_s, bias_names[i]) == 0) { + bias_n = i; + break; + } + } + if (bias_n == 0) { + bias_n = USB_US_DEFAULT_BIAS; + printk(KERN_INFO + "libusual: unknown bias \"%s\", using \"%s\"\n", + bias_s, bias_names[bias_n]); + } + } + return bias_n; +} + +module_init(usb_usual_init); +module_exit(usb_usual_exit); + +module_param_string(bias, bias, BIAS_NAME_SIZE, S_IRUGO|S_IWUSR); +MODULE_PARM_DESC(bias, "Bias to usb-storage or ub"); + +MODULE_LICENSE("GPL"); diff -urpN -X dontdiff linux-2.6.14/drivers/usb/storage/Makefile linux-2.6.14-lem/drivers/usb/storage/Makefile --- linux-2.6.14/drivers/usb/storage/Makefile 2005-10-28 19:12:03.000000000 -0700 +++ linux-2.6.14-lem/drivers/usb/storage/Makefile 2005-10-28 23:10:23.000000000 -0700 @@ -22,3 +22,7 @@ usb-storage-obj-$(CONFIG_USB_STORAGE_ONE usb-storage-objs := scsiglue.o protocol.o transport.o usb.o \ initializers.o $(usb-storage-obj-y) + +ifneq ($(CONFIG_USB_LIBUSUAL),) + obj-$(CONFIG_USB) += libusual.o +endif diff -urpN -X dontdiff linux-2.6.14/drivers/usb/storage/protocol.h linux-2.6.14-lem/drivers/usb/storage/protocol.h --- linux-2.6.14/drivers/usb/storage/protocol.h 2005-06-17 12:48:29.000000000 -0700 +++ linux-2.6.14-lem/drivers/usb/storage/protocol.h 2005-10-28 23:10:23.000000000 -0700 @@ -41,20 +41,6 @@ #ifndef _PROTOCOL_H_ #define _PROTOCOL_H_ -/* Sub Classes */ - -#define US_SC_RBC 0x01 /* Typically, flash devices */ -#define US_SC_8020 0x02 /* CD-ROM */ -#define US_SC_QIC 0x03 /* QIC-157 Tapes */ -#define US_SC_UFI 0x04 /* Floppy */ -#define US_SC_8070 0x05 /* Removable media */ -#define US_SC_SCSI 0x06 /* Transparent */ -#define US_SC_ISD200 0x07 /* ISD200 ATA */ -#define US_SC_MIN US_SC_RBC -#define US_SC_MAX US_SC_ISD200 - -#define US_SC_DEVICE 0xff /* Use device's value */ - /* Protocol handling routines */ extern void usb_stor_ATAPI_command(struct scsi_cmnd*, struct us_data*); extern void usb_stor_qic157_command(struct scsi_cmnd*, struct us_data*); diff -urpN -X dontdiff linux-2.6.14/drivers/usb/storage/transport.h linux-2.6.14-lem/drivers/usb/storage/transport.h --- linux-2.6.14/drivers/usb/storage/transport.h 2005-09-13 01:06:21.000000000 -0700 +++ linux-2.6.14-lem/drivers/usb/storage/transport.h 2005-10-28 23:10:23.000000000 -0700 @@ -41,39 +41,8 @@ #ifndef _TRANSPORT_H_ #define _TRANSPORT_H_ -#include #include -/* Protocols */ - -#define US_PR_CBI 0x00 /* Control/Bulk/Interrupt */ -#define US_PR_CB 0x01 /* Control/Bulk w/o interrupt */ -#define US_PR_BULK 0x50 /* bulk only */ -#ifdef CONFIG_USB_STORAGE_USBAT -#define US_PR_SCM_ATAPI 0x80 /* SCM-ATAPI bridge */ -#endif -#ifdef CONFIG_USB_STORAGE_SDDR09 -#define US_PR_EUSB_SDDR09 0x81 /* SCM-SCSI bridge for SDDR-09 */ -#endif -#ifdef CONFIG_USB_STORAGE_SDDR55 -#define US_PR_SDDR55 0x82 /* SDDR-55 (made up) */ -#endif -#define US_PR_DPCM_USB 0xf0 /* Combination CB/SDDR09 */ - -#ifdef CONFIG_USB_STORAGE_FREECOM -#define US_PR_FREECOM 0xf1 /* Freecom */ -#endif - -#ifdef CONFIG_USB_STORAGE_DATAFAB -#define US_PR_DATAFAB 0xf2 /* Datafab chipsets */ -#endif - -#ifdef CONFIG_USB_STORAGE_JUMPSHOT -#define US_PR_JUMPSHOT 0xf3 /* Lexar Jumpshot */ -#endif - -#define US_PR_DEVICE 0xff /* Use device's value */ - /* * Bulk only data structures */ diff -urpN -X dontdiff linux-2.6.14/drivers/usb/storage/unusual_devs.h linux-2.6.14-lem/drivers/usb/storage/unusual_devs.h --- linux-2.6.14/drivers/usb/storage/unusual_devs.h 2005-10-28 19:12:04.000000000 -0700 +++ linux-2.6.14-lem/drivers/usb/storage/unusual_devs.h 2005-10-28 23:10:23.000000000 -0700 @@ -1093,3 +1113,27 @@ UNUSUAL_DEV( 0x55aa, 0xa103, 0x0000, 0x US_SC_SCSI, US_PR_SDDR55, NULL, US_FL_SINGLE_LUN), #endif + +/* Control/Bulk transport for all SubClass values */ +USUAL_DEV(US_SC_RBC, US_PR_CB, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_8020, US_PR_CB, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_QIC, US_PR_CB, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_UFI, US_PR_CB, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_8070, US_PR_CB, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_SCSI, US_PR_CB, USB_US_TYPE_STOR), + +/* Control/Bulk/Interrupt transport for all SubClass values */ +USUAL_DEV(US_SC_RBC, US_PR_CBI, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_8020, US_PR_CBI, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_QIC, US_PR_CBI, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_UFI, US_PR_CBI, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_8070, US_PR_CBI, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_SCSI, US_PR_CBI, USB_US_TYPE_STOR), + +/* Bulk-only transport for all SubClass values */ +USUAL_DEV(US_SC_RBC, US_PR_BULK, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_8020, US_PR_BULK, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_QIC, US_PR_BULK, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_UFI, US_PR_BULK, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_8070, US_PR_BULK, USB_US_TYPE_STOR), +USUAL_DEV(US_SC_SCSI, US_PR_BULK, 0), diff -urpN -X dontdiff linux-2.6.14/drivers/usb/storage/usb.c linux-2.6.14-lem/drivers/usb/storage/usb.c --- linux-2.6.14/drivers/usb/storage/usb.c 2005-10-28 19:12:04.000000000 -0700 +++ linux-2.6.14-lem/drivers/usb/storage/usb.c 2005-10-28 23:10:23.000000000 -0700 @@ -116,49 +116,33 @@ static int storage_probe(struct usb_inte static void storage_disconnect(struct usb_interface *iface); -/* The entries in this table, except for final ones here - * (USB_MASS_STORAGE_CLASS and the empty entry), correspond, - * line for line with the entries of us_unsuaul_dev_list[]. +/* + * The entries in this table correspond, line for line, + * with the entries of us_unusual_dev_list[]. */ +#ifndef CONFIG_USB_LIBUSUAL #define UNUSUAL_DEV(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, \ vendorName, productName,useProtocol, useTransport, \ initFunction, flags) \ -{ USB_DEVICE_VER(id_vendor, id_product, bcdDeviceMin,bcdDeviceMax) } +{ USB_DEVICE_VER(id_vendor, id_product, bcdDeviceMin,bcdDeviceMax), \ + .driver_info = (flags)|(USB_US_TYPE_STOR<<24) } + +#define USUAL_DEV(useProto, useTrans, useType) \ +{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, useProto, useTrans), \ + .driver_info = (USB_US_TYPE_STOR<<24) } static struct usb_device_id storage_usb_ids [] = { # include "unusual_devs.h" #undef UNUSUAL_DEV - /* Control/Bulk transport for all SubClass values */ - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_RBC, US_PR_CB) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_8020, US_PR_CB) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_QIC, US_PR_CB) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_UFI, US_PR_CB) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_8070, US_PR_CB) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_SCSI, US_PR_CB) }, - - /* Control/Bulk/Interrupt transport for all SubClass values */ - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_RBC, US_PR_CBI) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_8020, US_PR_CBI) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_QIC, US_PR_CBI) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_UFI, US_PR_CBI) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_8070, US_PR_CBI) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_SCSI, US_PR_CBI) }, - - /* Bulk-only transport for all SubClass values */ - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_RBC, US_PR_BULK) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_8020, US_PR_BULK) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_QIC, US_PR_BULK) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_UFI, US_PR_BULK) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_8070, US_PR_BULK) }, - { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_SCSI, US_PR_BULK) }, - +#undef USUAL_DEV /* Terminating entry */ { } }; MODULE_DEVICE_TABLE (usb, storage_usb_ids); +#endif /* CONFIG_USB_LIBUSUAL */ /* This is the list of devices we recognize, along with their flag data */ @@ -171,7 +155,6 @@ MODULE_DEVICE_TABLE (usb, storage_usb_id * are free to use as many characters as you like. */ -#undef UNUSUAL_DEV #define UNUSUAL_DEV(idVendor, idProduct, bcdDeviceMin, bcdDeviceMax, \ vendor_name, product_name, use_protocol, use_transport, \ init_function, Flags) \ @@ -181,53 +164,18 @@ MODULE_DEVICE_TABLE (usb, storage_usb_id .useProtocol = use_protocol, \ .useTransport = use_transport, \ .initFunction = init_function, \ - .flags = Flags, \ +} + +#define USUAL_DEV(use_protocol, use_transport, use_type) \ +{ \ + .useProtocol = use_protocol, \ + .useTransport = use_transport, \ } static struct us_unusual_dev us_unusual_dev_list[] = { # include "unusual_devs.h" # undef UNUSUAL_DEV - /* Control/Bulk transport for all SubClass values */ - { .useProtocol = US_SC_RBC, - .useTransport = US_PR_CB}, - { .useProtocol = US_SC_8020, - .useTransport = US_PR_CB}, - { .useProtocol = US_SC_QIC, - .useTransport = US_PR_CB}, - { .useProtocol = US_SC_UFI, - .useTransport = US_PR_CB}, - { .useProtocol = US_SC_8070, - .useTransport = US_PR_CB}, - { .useProtocol = US_SC_SCSI, - .useTransport = US_PR_CB}, - - /* Control/Bulk/Interrupt transport for all SubClass values */ - { .useProtocol = US_SC_RBC, - .useTransport = US_PR_CBI}, - { .useProtocol = US_SC_8020, - .useTransport = US_PR_CBI}, - { .useProtocol = US_SC_QIC, - .useTransport = US_PR_CBI}, - { .useProtocol = US_SC_UFI, - .useTransport = US_PR_CBI}, - { .useProtocol = US_SC_8070, - .useTransport = US_PR_CBI}, - { .useProtocol = US_SC_SCSI, - .useTransport = US_PR_CBI}, - - /* Bulk-only transport for all SubClass values */ - { .useProtocol = US_SC_RBC, - .useTransport = US_PR_BULK}, - { .useProtocol = US_SC_8020, - .useTransport = US_PR_BULK}, - { .useProtocol = US_SC_QIC, - .useTransport = US_PR_BULK}, - { .useProtocol = US_SC_UFI, - .useTransport = US_PR_BULK}, - { .useProtocol = US_SC_8070, - .useTransport = US_PR_BULK}, - { .useProtocol = US_SC_SCSI, - .useTransport = US_PR_BULK}, +# undef USUAL_DEV /* Terminating entry */ { NULL } @@ -469,15 +417,21 @@ static int associate_dev(struct us_data } return 0; } + +/* Find an unusual_dev descriptor (always succeeds in the current code) */ +static struct us_unusual_dev *find_unusual(const struct usb_device_id *id) +{ + const int id_index = id - storage_usb_ids; + return &us_unusual_dev_list[id_index]; +} /* Get the unusual_devs entries and the string descriptors */ -static void get_device_info(struct us_data *us, int id_index) +static void get_device_info(struct us_data *us, const struct usb_device_id *id) { struct usb_device *dev = us->pusb_dev; struct usb_interface_descriptor *idesc = &us->pusb_intf->cur_altsetting->desc; - struct us_unusual_dev *unusual_dev = &us_unusual_dev_list[id_index]; - struct usb_device_id *id = &storage_usb_ids[id_index]; + struct us_unusual_dev *unusual_dev = find_unusual(id); /* Store the entries */ us->unusual_dev = unusual_dev; @@ -487,7 +441,7 @@ static void get_device_info(struct us_da us->protocol = (unusual_dev->useTransport == US_PR_DEVICE) ? idesc->bInterfaceProtocol : unusual_dev->useTransport; - us->flags = unusual_dev->flags; + us->flags = USB_US_ORIG_FLAGS(id->driver_info); /* * This flag is only needed when we're in high-speed, so let's @@ -515,7 +469,7 @@ static void get_device_info(struct us_da if (unusual_dev->useTransport != US_PR_DEVICE && us->protocol == idesc->bInterfaceProtocol) msg += 2; - if (msg >= 0 && !(unusual_dev->flags & US_FL_NEED_OVERRIDE)) + if (msg >= 0 && !(us->flags & US_FL_NEED_OVERRIDE)) printk(KERN_NOTICE USB_STORAGE "This device " "(%04x,%04x,%04x S %02x P %02x)" " has %s in unusual_devs.h\n" @@ -921,9 +875,11 @@ static int storage_probe(struct usb_inte { struct Scsi_Host *host; struct us_data *us; - const int id_index = id - storage_usb_ids; int result; + if (usb_usual_check_type(id, USB_US_TYPE_STOR)) + return -ENXIO; + US_DEBUGP("USB Mass Storage device detected\n"); /* @@ -956,7 +912,7 @@ static int storage_probe(struct usb_inte * of the match from the usb_device_id table, so we can find the * corresponding entry in the private table. */ - get_device_info(us, id_index); + get_device_info(us, id); #ifdef CONFIG_USB_STORAGE_SDDR09 if (us->protocol == US_PR_EUSB_SDDR09 || @@ -1045,9 +1001,10 @@ static int __init usb_stor_init(void) /* register the driver, return usb_register return code if error */ retval = usb_register(&usb_storage_driver); - if (retval == 0) + if (retval == 0) { printk(KERN_INFO "USB Mass Storage support registered.\n"); - + usb_usual_set_present(USB_US_TYPE_STOR); + } return retval; } @@ -1071,6 +1028,8 @@ static void __exit usb_stor_exit(void) wait_for_completion(&threads_gone); atomic_dec(&total_threads); } + + usb_usual_clear_present(USB_US_TYPE_STOR); } module_init(usb_stor_init); diff -urpN -X dontdiff linux-2.6.14/drivers/usb/storage/usb.h linux-2.6.14-lem/drivers/usb/storage/usb.h --- linux-2.6.14/drivers/usb/storage/usb.h 2005-10-28 19:12:04.000000000 -0700 +++ linux-2.6.14-lem/drivers/usb/storage/usb.h 2005-10-28 23:10:23.000000000 -0700 @@ -45,6 +45,7 @@ #define _USB_H_ #include +#include #include #include #include @@ -63,38 +64,8 @@ struct us_unusual_dev { __u8 useProtocol; __u8 useTransport; int (*initFunction)(struct us_data *); - unsigned int flags; }; -/* - * Static flag definitions. We use this roundabout technique so that the - * proc_info() routine can automatically display a message for each flag. - */ -#define US_DO_ALL_FLAGS \ - US_FLAG(SINGLE_LUN, 0x00000001) \ - /* allow access to only LUN 0 */ \ - US_FLAG(NEED_OVERRIDE, 0x00000002) \ - /* unusual_devs entry is necessary */ \ - US_FLAG(SCM_MULT_TARG, 0x00000004) \ - /* supports multiple targets */ \ - US_FLAG(FIX_INQUIRY, 0x00000008) \ - /* INQUIRY response needs faking */ \ - US_FLAG(FIX_CAPACITY, 0x00000010) \ - /* READ CAPACITY response too big */ \ - US_FLAG(IGNORE_RESIDUE, 0x00000020) \ - /* reported residue is wrong */ \ - US_FLAG(BULK32, 0x00000040) \ - /* Uses 32-byte CBW length */ \ - US_FLAG(NOT_LOCKABLE, 0x00000080) \ - /* PREVENT/ALLOW not supported */ \ - US_FLAG(GO_SLOW, 0x00000100) \ - /* Need delay after Command phase */ \ - US_FLAG(NO_WP_DETECT, 0x00000200) \ - /* Don't check for write-protect */ \ - -#define US_FLAG(name, value) US_FL_##name = value , -enum { US_DO_ALL_FLAGS }; -#undef US_FLAG /* Dynamic flag definitions: used in set_bit() etc. */ #define US_FLIDX_URB_ACTIVE 18 /* 0x00040000 current_urb is in use */ diff -urpN -X dontdiff linux-2.6.14/include/linux/usb_usual.h linux-2.6.14-lem/include/linux/usb_usual.h --- linux-2.6.14/include/linux/usb_usual.h 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.14-lem/include/linux/usb_usual.h 2005-10-28 23:10:23.000000000 -0700 @@ -0,0 +1,123 @@ +/* + * Interface to the libusual. + * + * Copyright (c) 2005 Pete Zaitcev + * Copyright (c) 1999-2002 Matthew Dharm (mdharm-usb at one-eyed-alien.net) + * Copyright (c) 1999 Michael Gee (michael at linuxspecific.com) + */ + +#ifndef __LINUX_USB_USUAL_H +#define __LINUX_USB_USUAL_H + +#include + +/* We should do this for cleanliness... But other usb_foo.h do not do this. */ +/* #include */ + +/* + * The flags field, which we store in usb_device_id.driver_info. + * It is compatible with the old usb-storage flags in lower 24 bits. + */ + +/* + * Static flag definitions. We use this roundabout technique so that the + * proc_info() routine can automatically display a message for each flag. + */ +#define US_DO_ALL_FLAGS \ + US_FLAG(SINGLE_LUN, 0x00000001) \ + /* allow access to only LUN 0 */ \ + US_FLAG(NEED_OVERRIDE, 0x00000002) \ + /* unusual_devs entry is necessary */ \ + US_FLAG(SCM_MULT_TARG, 0x00000004) \ + /* supports multiple targets */ \ + US_FLAG(FIX_INQUIRY, 0x00000008) \ + /* INQUIRY response needs faking */ \ + US_FLAG(FIX_CAPACITY, 0x00000010) \ + /* READ CAPACITY response too big */ \ + US_FLAG(IGNORE_RESIDUE, 0x00000020) \ + /* reported residue is wrong */ \ + US_FLAG(BULK32, 0x00000040) \ + /* Uses 32-byte CBW length */ \ + US_FLAG(NOT_LOCKABLE, 0x00000080) \ + /* PREVENT/ALLOW not supported */ \ + US_FLAG(GO_SLOW, 0x00000100) \ + /* Need delay after Command phase */ \ + US_FLAG(NO_WP_DETECT, 0x00000200) \ + /* Don't check for write-protect */ \ + +#define US_FLAG(name, value) US_FL_##name = value , +enum { US_DO_ALL_FLAGS }; +#undef US_FLAG + +/* + * The bias field for libusual and friends. + */ +#define USB_US_TYPE_NONE 0 +#define USB_US_TYPE_STOR 1 /* usb-storage */ +#define USB_US_TYPE_UB 2 /* ub */ + +#define USB_US_TYPE(flags) (((flags) >> 24) & 0xFF) +#define USB_US_ORIG_FLAGS(flags) ((flags) & 0x00FFFFFF) + +/* + * This is probably not the best place to keep these constants, conceptually. + * But it's the only header included into all places which need them. + */ + +/* Sub Classes */ + +#define US_SC_RBC 0x01 /* Typically, flash devices */ +#define US_SC_8020 0x02 /* CD-ROM */ +#define US_SC_QIC 0x03 /* QIC-157 Tapes */ +#define US_SC_UFI 0x04 /* Floppy */ +#define US_SC_8070 0x05 /* Removable media */ +#define US_SC_SCSI 0x06 /* Transparent */ +#define US_SC_ISD200 0x07 /* ISD200 ATA */ +#define US_SC_MIN US_SC_RBC +#define US_SC_MAX US_SC_ISD200 + +#define US_SC_DEVICE 0xff /* Use device's value */ + +/* Protocols */ + +#define US_PR_CBI 0x00 /* Control/Bulk/Interrupt */ +#define US_PR_CB 0x01 /* Control/Bulk w/o interrupt */ +#define US_PR_BULK 0x50 /* bulk only */ +#ifdef CONFIG_USB_STORAGE_USBAT +#define US_PR_SCM_ATAPI 0x80 /* SCM-ATAPI bridge */ +#endif +#ifdef CONFIG_USB_STORAGE_SDDR09 +#define US_PR_EUSB_SDDR09 0x81 /* SCM-SCSI bridge for SDDR-09 */ +#endif +#ifdef CONFIG_USB_STORAGE_SDDR55 +#define US_PR_SDDR55 0x82 /* SDDR-55 (made up) */ +#endif +#define US_PR_DPCM_USB 0xf0 /* Combination CB/SDDR09 */ +#ifdef CONFIG_USB_STORAGE_FREECOM +#define US_PR_FREECOM 0xf1 /* Freecom */ +#endif +#ifdef CONFIG_USB_STORAGE_DATAFAB +#define US_PR_DATAFAB 0xf2 /* Datafab chipsets */ +#endif +#ifdef CONFIG_USB_STORAGE_JUMPSHOT +#define US_PR_JUMPSHOT 0xf3 /* Lexar Jumpshot */ +#endif + +#define US_PR_DEVICE 0xff /* Use device's value */ + +/* + */ +#ifdef CONFIG_USB_LIBUSUAL + +extern struct usb_device_id storage_usb_ids[]; +extern void usb_usual_set_present(int type); +extern void usb_usual_clear_present(int type); +extern int usb_usual_check_type(const struct usb_device_id *, int type); +#else + +#define usb_usual_set_present(t) do { } while(0) +#define usb_usual_clear_present(t) do { } while(0) +#define usb_usual_check_type(id, t) (0) +#endif /* CONFIG_USB_LIBUSUAL */ + +#endif /* __LINUX_USB_USUAL_H */ From buildsys at redhat.com Sun Oct 30 12:54:16 2005 From: buildsys at redhat.com (Build System) Date: Sun, 30 Oct 2005 07:54:16 -0500 Subject: rawhide report: 20051030 changes Message-ID: <200510301254.j9UCsGwQ001592@porkchop.devel.redhat.com> Updated Packages: avahi-0.5.2-4 ------------- * Sun Oct 30 2005 Florian La Roche - disable the Obsoletes: howl until the transition is complete kernel-xen-2.6.12-1.9_FC5 ------------------------- xorg-x11-6.8.2-57 ----------------- * Fri Oct 28 2005 Mike A. Harris 6.8.2-57 - Re-enable s390x arch From jorton at redhat.com Sun Oct 30 13:40:28 2005 From: jorton at redhat.com (Joe Orton) Date: Sun, 30 Oct 2005 13:40:28 +0000 Subject: [SM-I18N] UTF-8 & imap folder name handling In-Reply-To: <1130419190.7578.1.camel@rousalka.dyndns.org> References: <1130416681.32348.34.camel@rousalka.dyndns.org> <34845.217.77.18.193.1130417709.squirrel@internet.eik.lt> <1130419190.7578.1.camel@rousalka.dyndns.org> Message-ID: <20051030134028.GA25486@redhat.com> On Thu, Oct 27, 2005 at 03:19:49PM +0200, Nicolas Mailhot wrote: > Le jeudi 27 octobre 2005 ? 15:55 +0300, Tomas Kuliavas a ?crit : > > 1. Enable mbstring support in Fedora PHP package. > > > > SquirrelMail utf7 imap functions use php mbstring extension to convert > > from iso-8859-x and utf8 to utf7-imap. If mbstring extension is not > > present, interface reverts to simple iso-8859-1 conversion. > > Thanks for the info. With mbstring installed everything seems to work > now. Perhaps a warning in configtest if mbstring is not present would be > a good idea ? Or just have squirrelmail require php-mbstring if it's required for correct operation? joe From nicolas.mailhot at laposte.net Sun Oct 30 14:39:59 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 30 Oct 2005 15:39:59 +0100 Subject: [SM-I18N] UTF-8 & imap folder name handling In-Reply-To: <20051030134028.GA25486@redhat.com> References: <1130416681.32348.34.camel@rousalka.dyndns.org> <34845.217.77.18.193.1130417709.squirrel@internet.eik.lt> <1130419190.7578.1.camel@rousalka.dyndns.org> <20051030134028.GA25486@redhat.com> Message-ID: <1130683199.4654.3.camel@rousalka.dyndns.org> Le dimanche 30 octobre 2005 ? 13:40 +0000, Joe Orton a ?crit : > On Thu, Oct 27, 2005 at 03:19:49PM +0200, Nicolas Mailhot wrote: > > Le jeudi 27 octobre 2005 ? 15:55 +0300, Tomas Kuliavas a ?crit : > > > 1. Enable mbstring support in Fedora PHP package. > > > > > > SquirrelMail utf7 imap functions use php mbstring extension to convert > > > from iso-8859-x and utf8 to utf7-imap. If mbstring extension is not > > > present, interface reverts to simple iso-8859-1 conversion. > > > > Thanks for the info. With mbstring installed everything seems to work > > now. Perhaps a warning in configtest if mbstring is not present would be > > a good idea ? > > Or just have squirrelmail require php-mbstring if it's required for > correct operation? That's the Fedora part. I was grumbling the php-mbstring dep is not obvious, SM site says it's needed for japanese (when in fact it's needed for pretty much every single UTF-8 locale) and configtest puts it at the same level as optional/experimental stuff like recode I've rebuilt a package that works for me, the instructions to fix the Fedora one are in bugzilla (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162852) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ellson at research.att.com Sun Oct 30 16:56:36 2005 From: ellson at research.att.com (John Ellson) Date: Sun, 30 Oct 2005 11:56:36 -0500 Subject: WARNING: /usr/bin/sort breaks fonts, thunderbird, and autofs (Re: rawhide report: 20051029 changes) In-Reply-To: <200510291125.j9TBPLM3003235@porkchop.devel.redhat.com> References: <200510291125.j9TBPLM3003235@porkchop.devel.redhat.com> Message-ID: <4364FB44.2030607@research.att.com> Build System wrote: > coreutils-5.92-1 > ---------------- > * Fri Oct 28 2005 Tim Waugh 5.92-1 > - Finished porting i18n patch to sort.c. > - Fixed for sort-mb-tests (avoid +n syntax). > > The latest /usr/bin/sort is causing lots of damage. See bugs# 166328 and 172028 My suggestion is that you don't update to coreutils-5.92-1 or if you have, that you downgrade again and reinstall fontconfig to rebuild its caches that may have been broken: rpm -Uvh --oldpackage coreutils-5.2.1-56.i386.rpm rpm -Uvh --replacepkgs fontconfig-2.3.91.cvs20051017-1.i386.rpm Unfortunately, if you have been bitten by this problem, you may not be able to read this since it breaks thunderbird. John From ellson at research.att.com Sun Oct 30 16:56:36 2005 From: ellson at research.att.com (John Ellson) Date: Sun, 30 Oct 2005 11:56:36 -0500 Subject: WARNING: /usr/bin/sort breaks fonts, thunderbird, and autofs (Re: rawhide report: 20051029 changes) In-Reply-To: <200510291125.j9TBPLM3003235@porkchop.devel.redhat.com> References: <200510291125.j9TBPLM3003235@porkchop.devel.redhat.com> Message-ID: <4364FB44.2030607@research.att.com> Build System wrote: > coreutils-5.92-1 > ---------------- > * Fri Oct 28 2005 Tim Waugh 5.92-1 > - Finished porting i18n patch to sort.c. > - Fixed for sort-mb-tests (avoid +n syntax). > > The latest /usr/bin/sort is causing lots of damage. See bugs# 166328 and 172028 My suggestion is that you don't update to coreutils-5.92-1 or if you have, that you downgrade again and reinstall fontconfig to rebuild its caches that may have been broken: rpm -Uvh --oldpackage coreutils-5.2.1-56.i386.rpm rpm -Uvh --replacepkgs fontconfig-2.3.91.cvs20051017-1.i386.rpm Unfortunately, if you have been bitten by this problem, you may not be able to read this since it breaks thunderbird. John -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From alan at redhat.com Sun Oct 30 22:47:58 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 30 Oct 2005 17:47:58 -0500 Subject: libusual and ub In-Reply-To: <20051029193544.096d400e.zaitcev@redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> Message-ID: <20051030224758.GE12718@devserv.devel.redhat.com> On Sat, Oct 29, 2005 at 07:35:44PM -0700, Pete Zaitcev wrote: > The problem it is trying to address is to have fewer oopses and/or lockups > related to the usb-storage. I have to say, I do not see all that many > these days, but when they do happen, it always happens as if on purpose > to break our schedule. The only oopses I've seen for a very long time in usb-storage are those that came from lower level USB > with it. We are in Rawhide, and just coming up to Test 1, after all. > I reckoned it appropriate to give a kind of technology preview. I'd oppose changing. usb-storage finally works and changing it for something like ub which does not have the Fedora exposure or upstream exposure seems the wrong thing to do. Having the ability to switch over itself to ub if something doesn't work might be useful but lets face it the remaining big problems with usb storage are o The core block code can't handle EOF and the maintainer refuses to even answer my email on the subject. o A few early cards have 256byte sectors and Linux scsi has never supported this. Alan From zaitcev at redhat.com Mon Oct 31 01:01:35 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sun, 30 Oct 2005 17:01:35 -0800 Subject: libusual and ub In-Reply-To: <20051030224758.GE12718@devserv.devel.redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051030224758.GE12718@devserv.devel.redhat.com> Message-ID: <20051030170135.74fef3a2.zaitcev@redhat.com> On Sun, 30 Oct 2005 17:47:58 -0500, Alan Cox wrote: > I'd oppose changing. usb-storage finally works [...] This is exactly what I told myself for 3 long years. The ub consists of pure and distilled anger over oopses and lockups in usb-storage, which overflowed the cup. Essentially I wrote it when we betaed RHEL 4 with completely busted SCSI stack. Remember the "Illegal transition" oopses? I thought, why do I have to put up with this crap? Why did I do it for so long?! And the answer was, "because I did not want to rock the boat, because I wanted to play nicely with others", and not for any technical reason. I saw too many people who pushed their own code because they were too dumb to understand existing code, and I did not want to be like them. It took me the horrible disaster of 2.4.9 to realize my folly. That's how ub started. Then there was a period of calm, with some small problems like interaction with VM. No problem, I thought, just do not use ext3 with usb-storage and you're golden. So, ub went nowhere. Users complained of regressions and poorly made mechanism of sharing of devices (it required a kernel rebuild). Then came the 2.6.13. It's a release where you pull the USB key, you get an oops in khubd, no ifs or buts. It's as if nobody tests anything anymore. So I wrote libusual, which allows for perfect sharing. Now, if usb-storage works well for you, you can do this: echo 'options libusual bias="usb-storage"' >> /etc/modprobe.conf You'll never know that anything has changed. But honestly, I do not feel strongly about all this, not until someone assigns me next bug in usb-storage. It works, for now, and I do feel like arguing with you. Just wanted to let you know that I went through the same denial already and hoped that I would save you some disillusionment. Cheers, -- Pete P.S. Another e-mail from yesterday: http://marc.theaimsgroup.com/?l=linux-usb-devel&m=113070746401406&w=2 From wtogami at redhat.com Mon Oct 31 01:42:07 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 30 Oct 2005 20:42:07 -0500 Subject: libusual and ub In-Reply-To: <20051030224758.GE12718@devserv.devel.redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051030224758.GE12718@devserv.devel.redhat.com> Message-ID: <4365766F.1000306@redhat.com> Alan Cox wrote: > > I'd oppose changing. usb-storage finally works and changing it for something like > ub which does not have the Fedora exposure or upstream exposure seems the wrong thing > to do. Pete, can you confirm that it will work transparently as default with no manual reconfiguration needed? If it is a simple drop-in replacement as default, maybe is the time to force exposure of ub to Fedora rawhide? We can see how things are going and decide before November 15th whether we want to pull or keep it for test1. Warren Togami wtogami at redhat.com From david at lovesunix.net Mon Oct 31 07:33:47 2005 From: david at lovesunix.net (David Nielsen) Date: Mon, 31 Oct 2005 08:33:47 +0100 Subject: test1 slipping? [WAS: libusual and ub] In-Reply-To: <4365766F.1000306@redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051030224758.GE12718@devserv.devel.redhat.com> <4365766F.1000306@redhat.com> Message-ID: <1130744028.2476.3.camel@localhost.localdomain> s?n, 30 10 2005 kl. 20:42 -0500, skrev Warren Togami: > We can see how things are going and decide before November 15th whether > we want to pull or keep it for test1. Does this mean test1 will slip because the release schedule still says that freeze is set for the 31th (today) and release will then follow on the 7th. http://fedora.redhat.com/participate/schedule/ - David From alan at redhat.com Mon Oct 31 10:39:24 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 31 Oct 2005 05:39:24 -0500 Subject: libusual and ub In-Reply-To: <20051030170135.74fef3a2.zaitcev@redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051030224758.GE12718@devserv.devel.redhat.com> <20051030170135.74fef3a2.zaitcev@redhat.com> Message-ID: <20051031103924.GB21978@devserv.devel.redhat.com> On Sun, Oct 30, 2005 at 05:01:35PM -0800, Pete Zaitcev wrote: > But honestly, I do not feel strongly about all this, not until someone > assigns me next bug in usb-storage. It works, for now, and I do feel > like arguing with you. Just wanted to let you know that I went through > the same denial already and hoped that I would save you some > disillusionment. Well if you think its the right thing to do then beta1 is the right time to test it and we can always go back the other way if it underperforms or causes trouble anywhere. Alan From buildsys at redhat.com Mon Oct 31 12:38:33 2005 From: buildsys at redhat.com (Build System) Date: Mon, 31 Oct 2005 07:38:33 -0500 Subject: rawhide report: 20051031 changes Message-ID: <200510311238.j9VCcXXs018371@porkchop.devel.redhat.com> Updated Packages: anthy-7029-1 ------------ * Mon Oct 31 2005 Akira TAGOH - 7029-1 - New upstream snapshot release. cpio-2.6-9 ---------- * Mon Oct 31 2005 Peter Vrabec 2.6-9 - fix checksum error on 64-bit machines (#171649) file-4.16-2 ----------- * Mon Oct 31 2005 Radek Vokal - 4.16-2 - fix core files output, show "from" (#172015) kernel-2.6.14-1.1635_FC5 ------------------------ * Sun Oct 30 2005 Dave Jones - 2.6.14-git2 * Thu Oct 27 2005 Dave Jones - 2.6.14 * Thu Oct 27 2005 Dave Jones - 2.6.14-rc5-git7 lv-4.51-7 --------- * Mon Oct 31 2005 Akira TAGOH - 4.51-7 - lv-+num-option.patch: applied a patch to allow +num option to jump to the specific line. - lv-fastio.patch: applied a patch to improve the performance to read the files. - lv-lfs.patch: applied a patch for Lerge File Summit support. * Mon Jul 11 2005 Akira TAGOH - 4.51-6 - lv-4.51-162372.patch: silence gcc warning. (#162372) * Thu Mar 17 2005 Akira TAGOH - 4.51-5 - rebuilt ruby-1.8.4-0.1.preview1 ----------------------- * Mon Oct 31 2005 Akira TAGOH - 1.8.4-0.1.preview1 - New upstream release. - ruby-1.8.2-strscan-memset.patch: removed because it's no longer needed. scim-hangul-0.2.1-1.fc5 ----------------------- * Mon Oct 31 2005 Akira TAGOH - 0.2.1-1 - New upstream release. - scim-hangul-0.2.0-ignore-invisible-char.patch: removed. * Thu Oct 06 2005 Jens Petersen - 0.2.0-6 - require scim * Thu Aug 25 2005 Akira TAGOH - 0.2.0-5 - fixed the description of this package. (Ryo Dairiki) - scim-hangul-0.2.0-ignore-invisible-char.patch: applied to not commit any Hangul characters with the keys unrelated to Yetgeul. (#166138) From bojan at rexursive.com Mon Oct 31 22:03:09 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 01 Nov 2005 09:03:09 +1100 Subject: Suspend to disk with 2.6.14-1.1635_FC5 Message-ID: <1130796189.3690.3.camel@coyote.rexursive.com> Although I normally patch with suspend2, just wanted to try the status of suspend to disk in the regular FC5 kernels. The notebook (HP-ZE4201) wouldn't suspend at all. This is what I have in dmesg: ----------------------------------- Stopping tasks: ================================================================ ================ stopping tasks failed (1 tasks remaining) Restarting tasks...<6> Strange, kauditd not stopped done ----------------------------------- In some previous kernels it used to suspend and then crash on resume. -- Bojan